完美主義的悲哀:放下就不再煩惱


第一屆開發者寫作松,軟體工程師軟實力系列第二篇

第一篇文章提到,完美主義的人心中那把尺,會比其他人來的嚴厲些。這篇文章要延伸探討的是,那把尺的標準有哪些?如果想要提高對自己的要求,有哪些層面?太過講究完美的工程師,是會累死自己還是做出品質優良的產品?

完美的定義

完美來自個人的刻板印象和價值觀,以及對產品原型設計的解讀。
APP開發的完美有分很多面向和角色:
1.看得到的完美,例如符合使用者習慣、流程順暢不卡關,滿足所有需求
2.看不到的完美,例如乾淨的程式碼、架構完整、易於維護擴充的設計

使用者的完美

例如下圖的貓咪夜燈,看到圖一就很容易會認為這是有缺陷的產品,因為圓滑的外框就會引導使用者認為整體都會是圓滑的,而圖二則是使用者認為這個產品原有的樣子。

也就是說:

符合使用者認為這個產品應該有的樣子,就是完美。

這是APP完美的第一關:滿足需求及市場價值。如何提升呢?
隨時隨地看看APP商店上有哪些產品,好的看優點、壞的引以為戒,自己就是使用者,才會了解普遍使用者的需求,這就是為什麼在我剛進入iOS開發時,前輩告訴我:

要當一個優秀的iOS工程師,就一定要有自己的iPhone。

產品經理的完美

對一個產品經理來講,無論這個產品經理重視的是品質還是業績,幾乎所有產品經理要的都是:快速有效率少BUG的穩定產出。
而大部分的工程師都會回應:那是不可能的。

那在不可能的國度中,工程師到底要怎麼生存?
首先要有一個認知:品質和時間不一定永遠選同一個,通常都有順序和嚴重程度的差異,因此排緊急優先度就是開發順暢的關鍵,但這通常都是產品經理在排的,開發者能做的,是讓產品經理了解任何決定背後的影響和成本,以及未來潛在問題,最後溝通出開發順序及相關應變配套措施,就自己能力所及達成產品經理需求,就成為不完美中的完美法則。

每個人的需求都不一樣。

團隊的完美

每個團隊有各自的文化和習慣,也有各自的盲點和問題,所謂的完美,就是在現有條件下達成平衡並且隨著時間進步。
無論是對外部或高層能交出漂亮的績效,還是對內部有高度凝聚力和應變能力,團隊氣氛的營造都是不可或缺的,但既然是科技人,就用科技解決人的問題!以下是過往團隊嘗試過的幾個方式:
1.用看板簡化開發以外的瑣事及會議紀錄。
2.編寫團隊開發規範,包含CodeReview、CodeStyle、相關教程。
3.不定期討論科技產品、應用、議題。
4.參與外部活動並與團隊成員分享。
5.與其他部門共同協辦讀書會,例如UX、QA等等。

除了管理的範疇,技術交流成為開發團隊優劣的關鍵,除非面試官有把握每一個錄取的人都是高手且技術水平相當。

能有技術交流的團隊,才有前瞻性,而不是一群外包工程師坐在同一個辦公室裡。

開發者的完美

當年同事笑我說:開發iOS的毛都很多。
但現在我必須承認,隨著開發經驗增加毛會越來越多……
在學習過程中,經歷了幾個階段:
1.剛入行的菜逼八,每天提心吊膽怕自己做不出功能,能完成就已經不錯了,De一個BUG生四個都是家常便飯,就靠毅力和不服輸撐下去。
2.熟能生巧後效率提升,開始思考如何提升品質減少BUG。
3.功能產出已經不太是煩惱後,就能深入學習程式架構和設計模式。
4.自己專案已經沒什麼大礙後,開始往Library或UI、UX延伸。

但寫乾淨的程式碼,是打一開始就必須有的認知,就算永遠一個人開發,看到一堆垃圾也會增加維護成本,千萬不要覺得自己不會寫出沒有用的程式碼,過了一年回頭看自己Code覺得寫很爛的大有人在。

生命是長期而持續的累積,程式碼也是。

完美的過程

毛這麼多,中間不會遇到什麼障礙嗎?事實是我遇到的心理障礙比技術障礙還要多很多……
菜鳥階段,通常都會有幾個共同的問題:
1.我無法解決,但前輩很忙不知道該不該問?
2.想寫的更好但一直優化就無法有實質產出。

如何提問

首先針對問問題這件事來講,先確定前輩是給問的,不要一道牆在那卻偏要去撞,有些人就真的不喜歡跟別人互動,但那真的是少數,大部分的情況是他也不知道要怎麼跟你互動。

不是因為面對電腦而對社交生疏,而是因為沒有社交機會所以生疏。

曾有個PM把開發工程師形容成一群老實天真又聰明的小動物,心中沒有太多心機,眼裡只有程式碼。無論原本什麼科系背景,能在這個職業穩穩待著的肯定有兩把刷子:能忍受坐在電腦前面至少八小時、能不斷的學習新知。
因此無論是新的舊的團隊成員,都要把交際這件事情考慮進去,不是有問題就問或因為怕碰壁就完全不問。
三個重點:
1.適當的提問,不要什麼都沒試過沒準備就問,同事不是你的Google大神,但也不要跟悶燒鍋一樣悶著,爆炸了讓別人收攤,通常我建議的範圍是半天到一天,同一個問題解決不了就去問。
2.挑對時間問,例如知道前輩準時下班就不要下班前問,提問前先問一下有沒有空是基本禮貌。
3.挑對問題問,通常會有一段問問題訓練期,如何精確地表達過程和重點,真的是一項必備技能。

提問真的是一門藝術,跟溝通一樣。

我原本就是個問題兒童,不過也因為就是有太多問題了,所以也連帶訓練出解決問題的能力,也就是工程師的本質。問問題絕對沒有錯,前提是問對了問題,但最差的情況是新人都沒有問題,就算他天資聰穎也不會完全了解專案需求和過往紀錄。

黃金Coding期

真的很有意思,就像寫作需要靈感,寫程式碼似乎也需要有Fu,在走向完美的路上,碰壁了怎麼辦?
1.先不要寫,離開當前環境和狀態(喝個水上廁所),有助於跳脫盲點。
2.找個人聊聊。
3.靠自己判斷是否缺乏資源,先補強缺乏的部分。

延伸:小黃鴨偵錯法
這真的是一個認識自己的過程,知道自己卡住時該怎麼辦?哪時特別容易卡?哪時思緒特別順暢?順的時候要如何避免被別人打斷?

優化和功能產出不是二擇一

就跟品質和業績共存的道理一樣,因此我才會特別強調clean code,在寫下的那剎那就確保是乾淨的,比事後檢查修改來得更有效率,但要做到就必須要刻意練習。
當每次寫的Code都是當時能力所及最好的品質時,就能提高進步速度,過了一個門檻後,這種落差就會逐漸減少,但一樣是靠溝通,或是需要團隊支援,這都沒有絕對的答案。

不完美才是最完美?!

回到完美主義的問題,當過了新人期後,仍然追求完美卻無法如願時,怎麼辦?

一個產品的成敗,不是技術決定一切。

從產品的產出過程:解決問題的初衷、外觀設計、使用流程設計、各種軟硬體技術克服、各種前後端資料串接、行銷推廣、商業模式等等各種面向。即便有了極為優秀的技術團隊,但產品無法被大眾接受,仍然會是失敗收場。

產品核心概念也決定著成敗,有些產品每個方面都看似平庸但卻被市場接受,有些產品有非常突出的亮點但卻是小眾需求,創新的設計往往需要時間被習慣和在地化。
有些情況在業務與專案管理的立場,沒有完成的產品基於各種考量上線,可能更優於完成所有功能後才進入市場,但這些都不是一個技術職原本在意的事。
了解除了技術以外的各種面向後,就會發現原本的不完美,似乎也沒那麼糟?

完美的副作用

工程師容易有強迫症?

這絕對是因人而異,但一個長期訓練專門挑問題毛病並負責解決的職業,肯定比其他職業有更高的機率有相關的職業病,由於我不是本科系,因此在工作幾年後就能看出跟同學間有明顯的差異和變化。
發現自己有傾向時怎麼辦?只能不斷告訴自己工作以外的地方不要那麼執著,執著也沒錢賺。但一個高壓力久坐的工作,心理健康和身體健康都顯得非常重要,有正確的心態和健康的身體,才能穩定的發揮自身價值。

吃得很隨便、穿得很隨便,寫出來的程式碼卻一點也不隨便。

放下還是理解?

生活上沒啥問題,但工作也很強迫怎麼辦?也許對專案有更多層面的了解,會有所幫助,例如去了解產品經理怎麼看?有些時候其實沒那麼完美也沒關係。畢竟在團隊中,產品不是屬於自己而是團隊的,很多時候溝通比成果重要,過猶不及。當別人都要你放下而你卻放不下時,有更多的理解才有助於突破瓶頸。

佛祖給的答案都相同:「只要放下,你就能不再煩惱。」

結論:放下屠刀立地成佛。

#APP #iOS
APP工程師軟實力
工程師有很多新技術要學、舊技術要補,但在軟體開發過程中,有更多的是軟實力和經驗累積。 希望可以藉由文字傳遞,讓團隊學習沒有斷層,自我學習更加突破。






Related Posts

[Day07] Monad

[Day07] Monad

[MTR04] W2 D12 練習三

[MTR04] W2 D12 練習三

Day07:V8 bytecode 系列文總結

Day07:V8 bytecode 系列文總結



Comments