一個工程師對流程管理的思考
我平時很少寫博客，我是個技術(shù)人員，一般來說技術(shù)人員的博客應(yīng)該以技術(shù)為主，但同時我又是一個懶人，對于技術(shù)我喜歡“親身體驗”而不喜歡“寫出來”，因為我覺得把技術(shù)對別人說清楚要比實現(xiàn)它更困難。實際上這段時間我都在看別人的博客，所以一直以來我只是個吃白食的:)
為什么現(xiàn)在我要跨界談一個偏重管理類的話題呢？因為過去經(jīng)歷的一些事促使我對項目的流程管理進(jìn)行一些思考，并形成了自己的一套看法和邏輯，而我也很愿意將我的看法發(fā)表成文，不喜歡憋在腦海里太久。至于能得到多少認(rèn)同倒是并不在意，我覺得一個人觀念的形成源于他對事物本質(zhì)的理解和認(rèn)知，而這種理解和認(rèn)知又同他過去的經(jīng)歷有關(guān)。在此通報一下我過去的工作經(jīng)歷，本人電氣專業(yè)出身，在一家臺資IC企業(yè)做過三年軟件工程師，無任何工程管理上的學(xué)位和經(jīng)驗，所以題目定為“一個工程師的思考”以避免把話說太滿。但我不認(rèn)為一個話題出自一個非專業(yè)人士之口就得貼上“瞎BB”的標(biāo)簽，作為工程師的我好歹也是大工業(yè)時代整條生產(chǎn)鏈上的一顆“螺絲釘”，雖然項目流程不是我設(shè)計的，但身為一顆“螺絲釘”也有反饋一下的權(quán)利吧。何況我也不想洋洋萬言寫成精品，權(quán)當(dāng)一家之言耳。
流程管理在生產(chǎn)上已被奉行多年，但圍繞它的爭議仍不停歇。有些人喜歡它，認(rèn)為流程提升了生產(chǎn)效率，有利于培養(yǎng)企業(yè)文化；有些人排斥它，認(rèn)為它束手束腳，僵化死板。前者大多出自管理層，后者大多出自工程師，他們都是站在自己的立場看問題的，能不能統(tǒng)一起來看呢？我們到底需不需要流程？或者多大程度上接受它？在闡述我的邏輯之前，先從我對流程的認(rèn)知說起。
流程的本質(zhì)是什么？我的理解是流程是一種介入機(jī)制和托管機(jī)制。“介入”是指生產(chǎn)環(huán)節(jié)上多大程度讓外部勢力參與和干預(yù)，主要表現(xiàn)為人員分工；“托管”是指存在一種自動化工具幫你簡化一些步驟，表現(xiàn)為對工具的使用。它們的區(qū)別相當(dāng)于載人飛船和無人飛船。當(dāng)我們說“這個項目應(yīng)該走個流程”實際上等價于“要讓外部人員參與進(jìn)來”以及“你該試試這個工具”這些同義語。
讓我們以開源項目Linux為例深入解釋一下。在上世紀(jì)90年代初出現(xiàn)了Linux內(nèi)核，是由芬蘭21歲的大學(xué)生Linus Torvalds開發(fā)的，他先是寫了一個多任務(wù)的終端仿真程序來連接modem，又寫了一個磁盤驅(qū)動程序訪問硬盤，再寫了一個文件系統(tǒng)管理資源，后來又移植了bash和gcc，一個操作系統(tǒng)雛形就這樣建立起來。在這個階段都是Linus一個人DIY，并沒有他人介入，頂多也就通過郵件同少量用戶交流一些需求。而且當(dāng)時工具也不太發(fā)達(dá)，他甚至不得不手動修改gcc源代碼以實現(xiàn)內(nèi)核自編譯。不管怎么樣，個人項目還是發(fā)布了。后來開始有人協(xié)助加入圖形、網(wǎng)絡(luò)各種服務(wù)和模塊，再后來就演變成一項聲勢浩大的開源運動，連商業(yè)公司都參與進(jìn)來開發(fā)各種發(fā)行版。這是Linus意識到自己必須放手，因為隨著用戶需求的增多，代碼量膨脹，版本發(fā)布周期也在縮短，這也是為何Linus又發(fā)明了版本控制軟件git；社區(qū)發(fā)展壯大導(dǎo)致成千上萬開發(fā)者參與其中，不僅僅貢獻(xiàn)代碼，測試、寫文檔、打包、做網(wǎng)頁、翻譯、技術(shù)支持、售前售后……把整條生產(chǎn)線納進(jìn)來了。這么多人，這么多活，沒有分工，沒有秩序顯然是行不通的，于是就像商業(yè)公司一樣，開源項目也要建立一套好流程，以便外部人員順利平滑地介入。
上面提到的“介入”和“托管”兩種機(jī)制，前者是參與分工，后者是工具使用，現(xiàn)在大多數(shù)開發(fā)者和管理層對工具使用都有某種共識，而且事實上實施很多年了。真正的分歧在于“介入”，這也是流程管理中最大的爭議，因為工具是可以替換的，而一旦“介入”是不可逆轉(zhuǎn)的，因為一旦介入，你很難把別人清退出去。何時介入，介入程度多深都會成為爭議焦點。一個工程師在項目早期的構(gòu)思建模階段一般是不歡迎他人參與進(jìn)來的，很多人說這會干擾他們的思路，頂多開放一些有限的口頭交流，但想要往我的代碼中提交pull request（以下簡稱PR），沒門！這種情形不禁讓人聯(lián)想到家里養(yǎng)的母貓在小貓尚未睜眼之前不允許任何人觸碰，就算自家主人也不行，不然就擺出一副兇巴巴要跟你拼命的架勢（狗媽媽可能無所謂，這也是為何有的程序員性格更像貓而不是狗一樣易于管教）。母貓的想法可能是這樣的：1.這是我親生的，憑什么讓你碰？2.撫養(yǎng)的細(xì)節(jié)只有我最懂，獸醫(yī)也不行。這同一些主觀意識強(qiáng)烈的工程師心理如出一轍，這也解釋了他們同別的工程師甚至管理層在流程問題上發(fā)生爭執(zhí)，說白了就是不想被介入。但隨著小貓的成長，母貓終究還是會允許主人幫忙照料養(yǎng)育自己的孩子，以分擔(dān)一些麻煩，如同工程師最終還是會與團(tuán)隊一同坐下來商談軟件打包發(fā)布等各種瑣事，以及放開并回應(yīng)來自社區(qū)提交的PR。
如何看待流程早期介入的必要性？從工程師的角度看我更傾向于早期不介入為好，因為程序最初的構(gòu)造是靠人的創(chuàng)造性思維，開發(fā)人員需要在腦海中（或紙上）精心構(gòu)建一座模型大廈，這種思維具備某種獨立性和連貫性，最不希望被打斷或中途崩塌，否則情緒上無法接受。對項目主管來說，如果限定時間內(nèi)一個人就能搞定的模塊，就讓他放手去做好了；如果是幾個模塊分工，就按照個人的專業(yè)水平安排各寫各的好了；時間允許的話，最好不要幾個人共寫一個模塊，除非結(jié)對編程。用Linus的話來說“從一開始就告訴自己這份工作只有你一個人負(fù)責(zé)，并且做好完成它的準(zhǔn)備。如果你一開始就認(rèn)為全世界的人們都會聯(lián)合起來為你的項目工作，一起創(chuàng)造一個更美好的世界，那么你可能不會走得很遠(yuǎn)。”
這里還有成員之間的信任問題，主管是否應(yīng)該在背后監(jiān)視每一行代碼？這是值得討論的，我還是引用Linus那句話：“不要試圖控制別人和他們的代碼。”有的主管提出代碼質(zhì)量的憂慮，但這引申出另外一個命題，如果代碼質(zhì)量可以衡量一個程序員個人能力，你擔(dān)心開發(fā)過程中的質(zhì)量，那當(dāng)初何必把他招進(jìn)來呢？如果代碼質(zhì)量真出了問題，那就是招聘時埋下的隱患了，作為管理層自身也有責(zé)任的。
這里還要說一下，不介入不等于成員之間不交流不討論了，不同意見的交換是有益的，但只是參考而不是強(qiáng)制性的，而且這種交流最好由工程師主動提出來，主管只負(fù)責(zé)調(diào)整項目進(jìn)度。另外code review是十分必要的，但時間線最好授權(quán)給工程師自己把握，免得一個不成熟的構(gòu)思匆忙提交下去一通review給提前定型了，何況開發(fā)人員在此期間還會私下里覺得不滿還會推翻重來，搞得其他成員浪費時間白白折騰。當(dāng)然我相信一個好的工程師也應(yīng)該有良好的自覺性和自律性，在招人的時候成為考察重點，要勝過在開發(fā)過程中背后另外搞一套監(jiān)控。
以上討論的主要是流程管理早期介入的問題，中后期的介入機(jī)制會比較復(fù)雜比較細(xì)節(jié)化，由于筆者經(jīng)驗水平所限不便多談。個人覺得介入也需要同項目團(tuán)隊的規(guī)模匹配，根據(jù)現(xiàn)狀和進(jìn)度因勢導(dǎo)利，逐步介入，而非開閘泄洪，一口一個胖子。另外不同公司的流程制度照搬要謹(jǐn)慎，如同協(xié)議那樣，如果達(dá)不成共識而強(qiáng)行介入，反而對團(tuán)隊不利。
下面談?wù)勍泄軝C(jī)制，也就是工具的使用。其實比起介入沒啥好談的，因為無論是管理層還是工程師都認(rèn)同工具在流程效率上的重要性，事實上早已使用很多年了。就我個人而言，版本控制用過perforce和git，項目管理用過redmine和trello，各有各的特色。工具也不限于軟件，開發(fā)語言本身也是一種工具，比如一些高級語言實際上也提供了“托管”功能，幫程序員管理內(nèi)存、實現(xiàn)并發(fā)之類的。工具的一個優(yōu)勢在于將一些重復(fù)低效的勞動從流程中剝離出來，簡化為開發(fā)人員對工具的使用技能，比如面試官在招人時只需要問你會不會使用git而不會讓你自己手動merge代碼。另一個優(yōu)勢就是講流程中的操作規(guī)范化、標(biāo)準(zhǔn)化，比如git的成功在于它借鑒了Unix的KISS原則設(shè)計了一套簡單命令接口：clone、add、reset、rm、commit、checkout、push、pull等，這么幾個命令足以滿足全球最大開源項目Linux的日常代碼托管需求了，難怪后來衍生出github、gitlab各種git家族都遵循同一套命令接口，如同達(dá)成默契的協(xié)議，你只要會用git，就可以在所有開源托管平臺上來去自如，讓流程簡化效率提升。好的工具使得全球范圍內(nèi)的協(xié)作項目成為可能，事實也證明了Linux社區(qū)所取得的成功。
與此同時我也思考過這兩種機(jī)制之間的辯證關(guān)系，因為一個是“載人”的，一個是“無人”的，我曾懷疑過當(dāng)管理工具日益強(qiáng)大時，來自外部勢力的介入需求會否因而減少，也就是說介入和托管在流程管理中的比重是否是此消彼長的？如果是，這個世界的生產(chǎn)鏈條上人是否終將被工具取代呢？過剩的人力資源是否使得未來工程師失業(yè)呢？在現(xiàn)實世界中的確看到大量個人項目，只要憑借個人對工具技能的掌握，完全不需要外人介入就能完成整個項目流程。然而答案是否定的。因為托管工具僅僅是將低效重復(fù)的勞動從流程中剝離，并未滿足全球科技行業(yè)日益增長的創(chuàng)造性需求。也許以前那些從事手工merge代碼的專職人員因此失業(yè)，但從全局來看是好事，那就是將開發(fā)人員從日常繁雜事物中解放出來，投入到更激動人心的創(chuàng)造性活動中去。只要人的腦容量增長速率追不上人類社會發(fā)展出現(xiàn)的各種變動，市場仍需要更多工程師投身其中，協(xié)同參與。現(xiàn)實世界也并未印證這種擔(dān)憂，開源項目的代碼量和參與人數(shù)都在逐年上升中。
如果你的團(tuán)隊在項目開發(fā)上進(jìn)展不順，不妨回過頭來看看自己的流程管理，當(dāng)初在人才選拔和介入機(jī)制上是否需要整改，亦或是換一個更先進(jìn)的工具。
