最近都在忙別的，難得寫軟體文章。分享一下。
因為聊同儕表現，
https://www.facebook.com/tonylovejava/posts/10205414663711733
覺得有點感觸，來寫一下這幾年我對軟體專案的幾個看法，
軟體專案其中我自己認為最重要的部份。
我自己早期是 SOHO (一人獨立接案工程師) 出身，
有時候需要跟企業內部的既存團隊合作
（像我跟歐亞書局合作過線上原文書書目瀏覽網站），
有時候需要自己從案子自己談企劃、一起合作規劃案子。
接案的部份我差不多接過許多個人能做的小案子到一個極致，
畢竟跑三年，後來"從良" 。
覺得與其繼續作小案子，還是先到公司去跑跑比較大的專案。
然後後面的經歷隨便找都有，我就不說了。
總之就是大多就是企劃跟需求訪談佔比變少、多了技術執行的部份。
而企劃跟需求訪談大多體現在我自己的個人專案跟社群活動裡面。
因為我個性關係，我在過去的經驗而言，可以說是一個游牧民族。
SOHO 時代跟我合作過得廠商至少就超過十幾家，
工作時代也跟四五家公司合作過。
所以看過很多各種不同個性的專案，
從很有資源到很沒有資源，從很有錢到很沒錢，從團隊很強到團隊很弱都有。
我覺得對一個資訊團隊來講，最重要得幾個原則：
1. 決定目標是老闆跟領導者的責任，而達成目標是團隊的第一要務。
老闆不要要讓 RD 幫你想怎麼賺錢，那是不切實際的。
也不要想要靠 RD 幫你省錢，那都是多的。
該誰負的責任就誰去負責。
讓不該負責的人負起責任，只會壓垮他的角色與進度。
2. 延續第一點。
你企業想怎麼做，老闆心理一定要有底。要有明確的長期目標。
而執行就要找個能完全信任的團隊來"相信"他，
然後設定合理的 check point 。
這個 check point 至少應該用週當單位。
以天或小時為單位根本就是神經病。有達成就獎勵、沒達成就懲處。
然後應該要接受 argue ，接受辯論。
我們也不諱言很多企業圈的老闆很蠢，
他會用別人的估計或自己的想法來估 RD 的時間還不準 RD 反駁。
事實上你不可能比 RD 實作者自己還明白時間，
如果估計的時間有出入，通常都是 spec 的認知有出入，
那時候該釐清的是 spec 細節跟重新估算。
而不是在那邊「我覺得要一個月」、「但我覺得要一週」，
這種愚蠢的菜市場喊價。
只有把細節講清楚，模糊地帶確認完，才有機會估計正確的時間。
RD 自己你要帶種敢把自己想的細節講清楚，
老闆你要夠有 sense 去評估你的 RD。
如果老闆整天在砍時間，那你根本就不信任你的 RD，
為什麼不乾脆把 RD 砍了換一批覺得能達到你想要得時間的 RD。
3. 繼續延續第一點跟第二點，
老闆千萬不要覺得工程師的產能"每天"是固定的。
工程師的產能「每週」平均會差不多，但每天落差會很大。
你不要看他今天閒了就覺得「啊幹，我事情排得不夠多」，
要看他那週的產出是不是到定位。
對軟體工程師跟軟體專案來講，閒置是一種充電。
太閒的話，好的軟體工程師反而還會找你抱怨說他覺得不夠忙。
硬要把時間填滿的結果就是：
大家都在假加班、工作永遠的 delay、團隊對目標沒有信心（致命傷）。
因為永遠不知道作到哪理可以休息，乾脆慢慢做。
4. 有什麼團隊就吃什麼案，很多團隊根本沒有對應的執行力，
硬要執行畫很大的案子，最後的下場就是撐很多年、大家一起死。
其實只要降低一些規格，很多時候還是可以善終的。
如果完全沒辦法降低又沒有那種等級人手的，
那就要承認，這局你打不起.....
5. RD 自己要把自己設定到的目標做到定位，這是各自的義務與責任，
也是公司之所以僱用 RD 的理由。
不論公司給多少，拿了錢就該做自己認為做得到的事情，
拿錢還要計較事情作太多，建議早早跳槽比較好。