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