如何做計劃

如何做計劃，通常不是技術團隊自己的問題，而是整個公司的問題。常見情況是，一家業務驅動的公司，技術團隊是沒有什麼話語權的，大的需求計劃由銷售、運營或者管理層確定，技術團隊只負責執行，有時候中間還隔着一層產品經理。這種情況下想制定嚴密周到的計劃就是奢談，可能連合理都做不到。

我聽説過最誇張的公司，今天定需求，明天就要求上線，並且上線以後如果出現bug，按數量罰款，數額從數百到數千不等，如果bug給公司造成了損失，就按等額的損失金額賠償。。。不用説，這家公司的程序員離職率高得驚人，大概每3個月會重新換一批。

幸運的是，作為合夥人，我還是得到了創業夥伴的充分支持和信任，計劃制定過程，基本上可以做到良性互動：業務和運營部門提需求，技術部門評估工作量，最終管理層會議決策優先級和時間點。在過程中，大家當然免不了爭吵、辯論和討價還價，但爭論的內容是理性的，可以相互理解。

有人可能會想，讓技術部門自己評估工作量，難道不會故意多報麼？説實話，在大公司裏，這種情況還真不少，本來3天能完成的，説3周，1個月也不是新鮮事兒。因為每個部門有自己的利益麼，跟公司的整體利益並不一致，信息溝通也不那麼順暢，浪費隨處可見，同時又視而不見。而小公司一個最大的優勢就是內部損耗低，效率高，這個優勢是建立在信任基礎上的：業務團隊必須信任技術團隊的誠實和能力，就像技術團隊也要相信業務團隊的開拓和判斷一樣。實際上，我在評估工作量的時候，會真誠的想為公司節省每一個人天：因為小公司經不起失敗，任何浪費都可能導致毀滅。

如何分解任務

具體的計劃應該怎麼做？一句話總結就是任務細分：把總體任務分解為可獨立發佈、可專人負責的小模塊。注意每個模塊一定只有1個負責人，這樣才責權清晰（當然在有Teamleader的情況下，分解的職責又可以下放給Team了）。

之後每個模塊負責人還要自己評估工作時間，這是個技術活兒，很多人程序員不想做，或者做不好，但一定要敢於放手，也要提出要求——做不好時間評估，就不是合格的程序員。

新手經常犯兩個錯誤：其一是一頭霧水，不知從何做起。這就需要管理者來指導：如果是前端模塊，通常可以按頁面分解，然後每個頁面裏再觀察複雜度：有沒有交互？有沒有需要計算的邏輯？有沒有需要探索的新技術點？；如果是後端模塊，那麼就可以按接口分解，每個接口獨立觀察複雜度：需要用到多少獨立服務？有多少關聯業務實體？涉及什麼算法？以及有沒有要探索的技術點？其中新技術點對評估準確性有最大的影響。

另外一種過分樂觀，時間預留不足。這時管理者要把好關：千萬別覺得預估時間短就很開心，計劃短不是真的短：到時候完不成，或者代碼千瘡百孔，哭都來不及。首先根據經驗判斷估時是否明顯不足，如果是，那麼跟他一起過細分項。新手經常把寫完代碼的時長，就當成完成功能的時長了，殊不知後面的調試修改可能還要多花一倍時間（如果有單元測試的習慣當然好，那麼寫測試的時間也要算上）。

最後補充一點：同一個功能，不同的人需要的開發時間就是不一樣（人不是可互換的資源）。管理層通常希望所有的資源都是標準化的，完成任務的時間是明確固定的，甚至是可以對照手冊查出來的——這對於軟件開發，是不可能完成的任務。寫代碼和其他工作最大的不同在於：沒有任何工作是重複上一次的！如果可以，那麼它就應該被封裝起來（這個以後説到代碼質量的時候再展開聊）。所以它是真正創造性的工作，無法標準化，也無法徹底的量化，但是一個特定的團隊，是可以有相對穩定的產出效率的。作為技術管理者，要打破標準量化的執念，同時也要在公司業務需求和團隊生產力之間起到橋樑的作用。