第一屆開發者寫作松，軟體工程師軟實力系列第一篇
曾經，前輩告訴我，工程師有分兩種：
- 把事情做完，但不會想要做更好。
- 把事情做完又做好，沒達到自己的標準就會很難過。
當時我傻傻的問前輩：那我是做完還是做好？
前輩回答我是做好那種時，還感到開心覺得被鼓勵，但過了兩年後才懂，其實做完跟做好並沒有分高低，就跟有人喜歡吃麵有人喜歡吃飯一樣正常。
既然有兩種，那在電腦前的工程師們，你是哪一種？ 這兩種能這麼明確的分類嗎？
我的回答是：不行，就跟你歸類一個人積極與否一樣不切實際，因為有些事情他很積極、但有些事情則很被動，原本很積極的人也可能被消磨，變得很被動。
既然無法明確分類，這篇文章豈不是廢文？當然不是。這篇文章的重點是：
認清自己和團隊夥伴的特質，才是個人和團隊成長的關鍵。
定義
先來詳細的了解怎樣是做好？怎樣是做完？
每個人心裡都有一把尺，超過某個刻度，就算是做好了，因此也會在不同的階段有不同的結果，也會因為能力成長和經驗累積，而有不同的影響。
影響自我評估的因素：
學習階段。初學者和老鳥的差異。
產品認同度。連自己都覺得沒意義的產品，很難會知道要怎麼做更好。
UI、UX專業能力。知道如何更貼近使用者需求是開發者做更好的關鍵技能之一。
自我期許。一個完美主義的人，這把尺肯定會比其他人還嚴格些。
團隊文化。想做好但沒人支持，也會變得力不從心。
知道這些影響因素後，就能更了解自己和團隊成員，為什麼要了解每個人對於做好和做完的定義？因為：
當一個心裡很想做好的人，遇到一個覺得他只想做完的團隊成員時，合作會變得很難過。
而當你覺得自己的團隊成員只想做好時，也許先溝通了解一下，是否是自我期許以外的原因造成？是否有改善方式？是否能提供他更多的資源和協助？
若很幸運的處理完"人的問題"之後，接著來了解經驗問題。
開發經驗
在開發過程中，什麼情況適合做好？什麼情況只要做完？除了軟體開發經驗的累積以外，下面列出幾個評估依據：
- 技術落差，或者是否有更好的處理方式
- dead line
- 這個功能在產品中的重要程度
- 未來發展性
在工程師群中最常發生的"我想做好但沒時間"這種情況，如果試過各種溝通方式了但仍然無效，那就自己看開些，了解這就是這個產品的既有條件，在條件下盡力，就問心無愧了，當然若有機會，實際了解產品經理以及業務顧慮，甚至實際走到現場了解使用者，也是一種很實際的解決方式。
那若都沒有想法怎麼辦？就去請教前輩吧～總是有一天要自己動腦想的。
專案特性
是不是所有專案都適合想做好的人？也不一定，開發新產品的人才需求，就會比維護來得高，提出自己的想法和意見，才能確保開發中的產品持續往更好的方向走，但當產品進入維護時，這麼多的"更好"，也有可能會造成更多的負擔和不符合成本效益的人力浪費。
若是兩個以上的成員共同開發或維護一個專案，那麼就能依照不同特質來做專案分工，以下依照想做好的類型人數列出不同情形，依照當前專案思考一下：
如果沒有這樣的工程師，專案會是什麼樣子？
每個專案都需要有這兩種類型的工程師嗎？
什麼樣的專案適合我這樣的工程師？
如果有兩個想做好的開發者，會發生什麼事？
以上答案都是因專案和環境而異，但了解這些就能知道團隊方向和人力缺口。
面試官的偏好
也算是我個人私心的偏好，認為當整個團隊都是想做好的人才時，團隊會更有凝聚力也更有發展性，但不可否認的是，的確每個團隊都需要兩種人才，只要互相理解並發揮專長，一樣可以和樂融融。
但是！以目前的觀察，在同一個團隊裡想做好的成員會比只做完的成員來的容易得到升遷機會，而若整個團隊有共識要做好，你卻只做完，就很容易被排擠或嫌棄。
還沒選邊站的新人們，請好好想清楚，而且到了新團隊，先搞清楚團隊的標準，免得不小心就黑掉了。
人是會改變的
曾經覺得只要把功能做完即可的人，也是有可能會隨著時間改變的。
例如當他為這個產品負責且感到驕傲的時候、或者當他意識到自己不敢跟別人說自己的專案產品時(有時會覺得自己開發了一個爛東西也是滿正常的)，或者當他開始跟使用者銜接，能夠更深入的評估是做好還是做完時。
軟體工程師真的不能一直把屁股黏在椅子上，要跟終端使用者有銜接。
當一個能夠身歷其境、感同身受的開發者，實際了解產品使用者的情況、痛點、需求時，就能提出方法驗證、突破盲點。
或許有些人覺得這些是ＰＭ或設計師的工作，但很多時候的細部實踐項目，仍然是由工程師決定，因此工程師是否有這部分的專業，就會影響產品。
如果一個工程師不懂業務，隨便就能被取代。
若一個團隊已經彈性疲乏，或從來沒想過這個問題，那可以參考下列幾個方法，來提高團隊的創造力和激發開發熱情：
創意思考
技術和非技術性議題討論
實際體驗產品和接觸使用者
結論
結論就是因材施教、適才適所，了解團隊成員和專案業務，都跟練技術一樣重要。
