我平時很少寫部落格，我是個技術人員，一般來說技術人員的部落格應該以技術為主，但同時我又是一個懶人，對於技術我喜歡“親身體驗”而不喜歡“寫出來”，因為我覺得把技術對別人說清楚要比實現它更困難。實際上這段時間我都在看別人的部落格，所以一直以來我只是個吃白食的:)

為什麼現在我要跨界談一個偏重管理類的話題呢？因為過去經歷的一些事促使我對專案的流程管理進行一些思考，並形成了自己的一套看法和邏輯，而我也很願意將我的看法發表成文，不喜歡憋在腦海裡太久。至於能得到多少認同倒是並不在意，我覺得一個人觀念的形成源於他對事物本質的理解和認知，而這種理解和認知又同他過去的經歷有關。在此通報一下我過去的工作經歷，本人電氣專業出身，在一家臺資IC企業做過三年軟體工程師，無任何工程管理上的學位和經驗，所以題目定為“一個工程師的思考”以避免把話說太滿。但我不認為一個話題出自一個非專業人士之口就得貼上“瞎BB”的標籤，作為工程師的我好歹也是大工業時代整條生產鏈上的一顆“螺絲釘”，雖然專案流程不是我設計的，但身為一顆“螺絲釘”也有反饋一下的權利吧。何況我也不想洋洋萬言寫成精品，權當一家之言耳。

流程管理在生產上已被奉行多年，但圍繞它的爭議仍不停歇。有些人喜歡它，認為流程提升了生產效率，有利於培養企業文化；有些人排斥它，認為它束手束腳，僵化死板。前者大多出自管理層，後者大多出自工程師，他們都是站在自己的立場看問題的，能不能統一起來看呢？我們到底需不需要流程？或者多大程度上接受它？在闡述我的邏輯之前，先從我對流程的認知說起。

流程的本質是什麼？我的理解是流程是一種介入機制和託管機制。“介入”是指生產環節上多大程度讓外部勢力參與和干預，主要表現為人員分工；“託管”是指存在一種自動化工具幫你簡化一些步驟，表現為對工具的使用。它們的區別相當於載人飛船和無人飛船。當我們說“這個專案應該走個流程”實際上等價於“要讓外部人員參與進來”以及“你該試試這個工具”這些同義語。

讓我們以開源專案Linux為例深入解釋一下。在上世紀90年代初出現了Linux核心，是由芬蘭21歲的大學生Linus Torvalds開發的，他先是寫了一個多工的終端模擬程式來連線modem，又寫了一個磁碟驅動程式訪問硬碟，再寫了一個檔案系統管理資源，後來又移植了bash和gcc，一個作業系統雛形就這樣建立起來。在這個階段都是Linus一個人DIY，並沒有他人介入，頂多也就通過郵件同少量使用者交流一些需求。而且當時工具也不太發達，他甚至不得不手動修改gcc原始碼以實現核心自編譯。不管怎麼樣，個人專案還是釋出了。後來開始有人協助加入圖形、網路各種服務和模組，再後來就演變成一項聲勢浩大的開源運動，連商業公司都參與進來開發各種發行版。這是Linus意識到自己必須放手，因為隨著使用者需求的增多，程式碼量膨脹，版本釋出週期也在縮短，這也是為何Linus又發明了版本控制軟體git；社群發展壯大導致成千上萬開發者參與其中，不僅僅貢獻程式碼，測試、寫文件、打包、做網頁、翻譯、技術支援、售前售後……把整條生產線納進來了。這麼多人，這麼多活，沒有分工，沒有秩序顯然是行不通的，於是就像商業公司一樣，開源專案也要建立一套好流程，以便外部人員順利平滑地介入。

上面提到的“介入”和“託管”兩種機制，前者是參與分工，後者是工具使用，現在大多數開發者和管理層對工具使用都有某種共識，而且事實上實施很多年了。真正的分歧在於“介入”，這也是流程管理中最大的爭議，因為工具是可以替換的，而一旦“介入”是不可逆轉的，因為一旦介入，你很難把別人清退出去。何時介入，介入程度多深都會成為爭議焦點。一個工程師在專案早期的構思建模階段一般是不歡迎他人蔘與進來的，很多人說這會干擾他們的思路，頂多開放一些有限的口頭交流，但想要往我的程式碼中提交pull request（以下簡稱PR），沒門！這種情形不禁讓人聯想到家裡養的母貓在小貓尚未睜眼之前不允許任何人觸碰，就算自家主人也不行，不然就擺出一副凶巴巴要跟你拼命的架勢（狗媽媽可能無所謂，這也是為何有的程式設計師性格更像貓而不是狗一樣易於管教）。母貓的想法可能是這樣的：1.這是我親生的，憑什麼讓你碰？2.撫養的細節只有我最懂，獸醫也不行。這同一些主觀意識強烈的工程師心理如出一轍，這也解釋了他們同別的工程師甚至管理層在流程問題上發生爭執，說白了就是不想被介入。但隨著小貓的成長，母貓終究還是會允許主人幫忙照料養育自己的孩子，以分擔一些麻煩，如同工程師最終還是會與團隊一同坐下來商談軟體打包釋出等各種瑣事，以及放開並回應來自社群提交的PR。

如何看待流程早期介入的必要性？從工程師的角度看我更傾向於早期不介入為好，因為程式最初的構造是靠人的創造性思維，開發人員需要在腦海中（或紙上）精心構建一座模型大廈，這種思維具備某種獨立性和連貫性，最不希望被打斷或中途崩塌，否則情緒上無法接受。對專案主管來說，如果限定時間內一個人就能搞定的模組，就讓他放手去做好了；如果是幾個模組分工，就按照個人的專業水平安排各寫各的好了；時間允許的話，最好不要幾個人共寫一個模組，除非結對程式設計。用Linus的話來說“從一開始就告訴自己這份工作只有你一個人負責，並且做好完成它的準備。如果你一開始就認為全世界的人們都會聯合起來為你的專案工作，一起創造一個更美好的世界，那麼你可能不會走得很遠。”

這裡還有成員之間的信任問題，主管是否應該在背後監視每一行程式碼？這是值得討論的，我還是引用Linus那句話：“不要試圖控制別人和他們的程式碼。”有的主管提出程式碼質量的憂慮，但這引申出另外一個命題，如果程式碼質量可以衡量一個程式設計師個人能力，你擔心開發過程中的質量，那當初何必把他招進來呢？如果程式碼質量真出了問題，那就是招聘時埋下的隱患了，作為管理層自身也有責任的。

這裡還要說一下，不介入不等於成員之間不交流不討論了，不同意見的交換是有益的，但只是參考而不是強制性的，而且這種交流最好由工程師主動提出來，主管只負責調整專案進度。另外code review是十分必要的，但時間線最好授權給工程師自己把握，免得一個不成熟的構思匆忙提交下去一通review給提前定型了，何況開發人員在此期間還會私下裡覺得不滿還會推翻重來，搞得其他成員浪費時間白白折騰。當然我相信一個好的工程師也應該有良好的自覺性和自律性，在招人的時候成為考察重點，要勝過在開發過程中背後另外搞一套監控。

以上討論的主要是流程管理早期介入的問題，中後期的介入機制會比較複雜比較細節化，由於筆者經驗水平所限不便多談。個人覺得介入也需要同項目團隊的規模匹配，根據現狀和進度因勢導利，逐步介入，而非開閘洩洪，一口一個胖子。另外不同公司的流程制度照搬要謹慎，如同協議那樣，如果達不成共識而強行介入，反而對團隊不利。

下面談談託管機制，也就是工具的使用。其實比起介入沒啥好談的，因為無論是管理層還是工程師都認同工具在流程效率上的重要性，事實上早已使用很多年了。就我個人而言，版本控制用過perforce和git，專案管理用過redmine和trello，各有各的特色。工具也不限於軟體，開發語言本身也是一種工具，比如一些高階語言實際上也提供了“託管”功能，幫程式設計師管理記憶體、實現併發之類的。工具的一個優勢在於將一些重複低效的勞動從流程中剝離出來，簡化為開發人員對工具的使用技能，比如面試官在招人時只需要問你會不會使用git而不會讓你自己手動merge程式碼。另一個優勢就是講流程中的操作規範化、標準化，比如git的成功在於它借鑑了Unix的KISS原則設計了一套簡單命令介面：clone、add、reset、rm、commit、checkout、push、pull等，這麼幾個命令足以滿足全球最大開源專案Linux的日常程式碼託管需求了，難怪後來衍生出github、gitlab各種git家族都遵循同一套命令介面，如同達成默契的協議，你只要會用git，就可以在所有開源託管平臺上來去自如，讓流程簡化效率提升。好的工具使得全球範圍內的協作專案成為可能，事實也證明了Linux社群所取得的成功。

與此同時我也思考過這兩種機制之間的辯證關係，因為一個是“載人”的，一個是“無人”的，我曾懷疑過當管理工具日益強大時，來自外部勢力的介入需求會否因而減少，也就是說介入和託管在流程管理中的比重是否是此消彼長的？如果是，這個世界的生產鏈條上人是否終將被工具取代呢？過剩的人力資源是否使得未來工程師失業呢？在現實世界中的確看到大量個人專案，只要憑藉個人對工具技能的掌握，完全不需要外人介入就能完成整個專案流程。然而答案是否定的。因為託管工具僅僅是將低效重複的勞動從流程中剝離，並未滿足全球科技行業日益增長的創造性需求。也許以前那些從事手工merge程式碼的專職人員因此失業，但從全域性來看是好事，那就是將開發人員從日常繁雜事物中解放出來，投入到更激動人心的創造性活動中去。只要人的腦容量增長速率追不上人類社會發展出現的各種變動，市場仍需要更多工程師投身其中，協同參與。現實世界也並未印證這種擔憂，開源專案的程式碼量和參與人數都在逐年上升中。

如果你的團隊在專案開發上進展不順，不妨回過頭來看看自己的流程管理，當初在人才選拔和介入機制上是否需要整改，亦或是換一個更先進的工具。

參考：