我平時很少寫博客,我是個技術人員,一般來說技術人員的博客應該以技術為主,但同時我又是一個懶人,對于技術我喜歡“親身體驗”而不喜歡“寫出來”,因為我覺得把技術對別人說清楚要比實現它更困難。實際上這段時間我都在看別人的博客,所以一直以來我只是個吃白食的。
為什么現在我要跨界談一個偏重管理類的話題呢?因為過去經歷的一些事促使我對項目的流程管理進行一些思考,并形成了自己的一套看法和邏輯,而我也很愿意將我的看法發表成文,不喜歡憋在腦海里太久。至于能得到多少認同倒是并不在意,我覺得一個人觀念的形成源于他對事物本質的理解和認知,而這種理解和認知又同他過去的經歷有關。在此通報一下我過去的工作經歷,本人電氣專業出身,在一家臺資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代碼的專職人員因此失業,但從全局來看是好事,那就是將開發人員從日常繁雜事物中解放出來,投入到更激動人心的創造性活動中去。只要人的腦容量增長速率追不上人類社會發展出現的各種變動,市場仍需要更多工程師投身其中,協同參與。現實世界也并未印證這種擔憂,開源項目的代碼量和參與人數都在逐年上升中。
如果你的團隊在項目開發上進展不順,不妨回過頭來看看自己的流程管理,當初在人才選拔和介入機制上是否需要整改,亦或是換一個更先進的工具。
核心關注:拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業務管理理念,功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理,全面涵蓋了企業關注ERP管理系統的核心領域,是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處:拓步ERP資訊網http://www.guhuozai8.cn/
本文標題:一個工程師在企業中對流程管理的思考
本文網址:http://www.guhuozai8.cn/html/consultation/10819620453.html