作為一個(gè)技術(shù)人員，你也不可避免地會遇到職場上的管理和流程問題，而且隨著工作年限的提高，你可能早晚都要做一個(gè)純管理者或者技術(shù)管理者，或者是一個(gè)被別人經(jīng)常請教技術(shù)方案的人。本文我就說一些在工作中的項(xiàng)目管理經(jīng)驗(yàn)。
技術(shù)管理人員在設(shè)計(jì)技術(shù)架構(gòu)及人員管理的時(shí)候，往往會有兩種風(fēng)格——激進(jìn)派和保守派。下面我來說說這兩種風(fēng)格的特點(diǎn)，以及作為技術(shù)管理人員，如何針對具體的項(xiàng)目，用不同的風(fēng)格來揚(yáng)長避短。
這種風(fēng)格表現(xiàn)在：項(xiàng)目上追求快速完成，不太注重項(xiàng)目持久性。這種風(fēng)格的優(yōu)點(diǎn)是，一個(gè)新點(diǎn)子往往能迅速上線，但弊端更多。
這樣的管理者開頭和分配任務(wù)的方式往往是一樣的：
“小A，小B，小C，快快快，在這兒開個(gè)會。我們要做一個(gè)xxx，就是實(shí)現(xiàn)個(gè)xxx，小A，你做A部分，小B你做B部分，小C你做C部分。我們這個(gè)項(xiàng)目，兩周開發(fā)完，交給測試。測試一兩天就應(yīng)該能測完。10 月底上線?！?/span>
然后，小A、小B、小C回到工位，開始火急火燎地開發(fā)。不，開始火急火燎地研究需求，設(shè)計(jì)系統(tǒng)方案，最后開始編碼。
然后，真正到兩周了，其實(shí)也開發(fā)完了，交付給測試后，會出現(xiàn)很多問題，然后他們分別拼命改。終于在最后期限—— 10 月底上線了?？墒墙o用戶一用，發(fā)現(xiàn)好多問題，立刻緊急修復(fù)，緊急！緊急！身后一背虛汗。
這樣的開發(fā)方式，弊端在哪里呢？
首先，因?yàn)榱艚o基層開發(fā)人員的時(shí)間很短，所以開發(fā)人員在開發(fā)時(shí)無法深入地對系統(tǒng)架構(gòu)有整體的思考，并且因?yàn)闀r(shí)間緊迫，開發(fā)人員都是“吃技術(shù)老本”來完成這個(gè)項(xiàng)目，沒有從項(xiàng)目中學(xué)到新東西，也沒有獲得太大的成長。比如，之所以讓小A負(fù)責(zé)A，小B負(fù)責(zé)B，小C負(fù)責(zé)C，是因?yàn)檫@部分是他們各自的擅長領(lǐng)域，開發(fā)人員在技術(shù)上做的是“重復(fù)的、機(jī)械性的”工作。
其次，上線后會有各種詭異問題。這是因?yàn)?，開發(fā)時(shí)對所有的邏輯沒有想全，項(xiàng)目周期緊張，測試人員也是在測試當(dāng)天前后才了解到這個(gè)項(xiàng)目，對項(xiàng)目的整體功能把握不透徹，就完全依賴開發(fā)人員的描述進(jìn)行測試。一些異常狀態(tài)以及跟之前系統(tǒng)可能有的交互的影響未考慮到，導(dǎo)致很多不易察覺的錯(cuò)誤上線后才發(fā)現(xiàn)。這時(shí)，留給開發(fā)人員的活兒就是在線上定位和修改bug。因?yàn)檫@種問題往往是沒有很明顯復(fù)現(xiàn)條件的，所以定位問題的難度很大。這時(shí)開發(fā)人員就要重新梳理一遍自己的開發(fā)邏輯，從中發(fā)現(xiàn)可能的問題。
再次，由于時(shí)間緊張，開發(fā)人員往往不寫“設(shè)計(jì)文檔”，這對后期接手人員的工作帶來很大困難。萬一開發(fā)人員變動或者離職，接手人員有時(shí)就得從頭“啃”代碼，或者自己另寫一套代碼維護(hù)。
我稱這種項(xiàng)目管理方式叫作“走 2 步，退 1 步半”。因此，開發(fā)的時(shí)候，好像很迅速，一個(gè)系統(tǒng)可能 2 周左右就開發(fā)完成，然后上線，管理人員和一線開發(fā)人員都皆大歡喜，發(fā)郵件抄送全組祝賀?？墒?，后續(xù)發(fā)現(xiàn)，問題維護(hù)成本也很高，大概也需要 1 周半的時(shí)間去維護(hù)系統(tǒng)的遺留問題，這些遺留問題被測試人員或者用戶發(fā)現(xiàn)后，往往也需要一定的溝通成本來描述和定位。最重要的是，問題發(fā)生在上線后，影響了公司的品牌和聲譽(yù)。
這種開發(fā)模式對“熟手”工程師來說可能成長不大，而對“生手”工程師來說，這會倒逼他在某個(gè)時(shí)間點(diǎn)完成一項(xiàng)任務(wù)，在技術(shù)應(yīng)用上學(xué)習(xí)和成長是很快的。但即使“熟手”也會出現(xiàn)上述問題，是因?yàn)榧夹g(shù)本領(lǐng)的熟練，不足以應(yīng)對開發(fā)這個(gè)系統(tǒng)時(shí)需要的團(tuán)隊(duì)配合以及考慮系統(tǒng)上下游的關(guān)系的問題，因?yàn)槟阕龅暮芏嘣O(shè)計(jì)，可能和你搭檔的工程師并不知道，或者在整個(gè)系統(tǒng)中并不必要。因此，有的時(shí)候你不能走得太快，否則會遺失很多東西，到時(shí)候還得補(bǔ)回來。
保守派和激進(jìn)派的做法幾乎完全相反。下面我就舉個(gè)例子來描述保守派項(xiàng)目管理的開發(fā)流程。例如，產(chǎn)品經(jīng)理想給產(chǎn)品新加一個(gè)功能，他可能面臨如下步驟。
（1）直接找到對應(yīng)的技術(shù)人員去溝通。
（2）技術(shù)人員同意添加，并有能夠解決問題的技術(shù)方案。但是，不要以為技術(shù)人員就可以直接干活寫代碼了，因?yàn)榧夹g(shù)人員的上級還不知道這件事情，所以這個(gè)技術(shù)人員還沒有相應(yīng)的時(shí)間資源（即排期）去做。因此，需要再向技術(shù)主管確認(rèn)這個(gè)功能是否要添加，以及主管安排這個(gè)技術(shù)人員的工作排期。隨后，需要產(chǎn)品經(jīng)理發(fā)出郵件，抄送對應(yīng)的技術(shù)人員和雙方主管，確認(rèn)溝通內(nèi)容，這樣，溝通圓滿完成。
（3）若技術(shù)人員認(rèn)為這個(gè)功能沒有必要，或者添加這個(gè)功能的技術(shù)復(fù)雜度很高。他們就需要上報(bào)到雙方經(jīng)理處進(jìn)行協(xié)商，而協(xié)商的結(jié)果則要視問題的復(fù)雜度及各自的KPI來定。有可能問題太復(fù)雜，這個(gè)功能就暫時(shí)被擱置了，也有可能產(chǎn)品和技術(shù)雖然都負(fù)責(zé)一個(gè)項(xiàng)目，但是兩邊的KPI導(dǎo)向可能不一致，這也可能會導(dǎo)致新功能被擱置。
而到了真正開始項(xiàng)目開發(fā)的時(shí)候，保守派一般會有 1 ～ 2 個(gè)工程師參與，詳細(xì)寫出“設(shè)計(jì)文檔”，和項(xiàng)目經(jīng)理一起開會，對設(shè)計(jì)文檔的實(shí)現(xiàn)點(diǎn)逐個(gè)討論，逐個(gè)達(dá)成一致，然后確保在考慮上沒有疏忽和遺漏，才開始寫代碼。
保守派和激進(jìn)派最大的區(qū)別在于，保守派在向前推進(jìn)項(xiàng)目的每一步，都傾向以“郵件”的方式傳達(dá)給合作方，包括每一次溝通的內(nèi)容及溝通的結(jié)論，并且傾向于在開發(fā)前就把完整的設(shè)計(jì)方案全部整理好，細(xì)化到任何一個(gè)步驟，并且讓參與的工程師都知曉。而激進(jìn)派則不同，他比較傾向于口頭和對方討論和溝通，并立刻投入功能實(shí)現(xiàn)中，在最后上線時(shí)發(fā)郵件慶賀，并且傾向于每個(gè)人獨(dú)立負(fù)責(zé)自己的那一部分，需要部分之間銜接時(shí)，才去兩人私下討論，因?yàn)椴徽?，所以常常也考慮不到對整個(gè)系統(tǒng)或者其他工程師手頭工作的影響。
這兩種管理方式我們在同一家公司的不同項(xiàng)目管理者身上經(jīng)常能看到。但本質(zhì)上，這兩種方式都一定程度上損失了公司效率。其實(shí)，稍微理想一些的方式應(yīng)該是下面這樣的。
技術(shù)經(jīng)理在平時(shí)的工作中，就對自己負(fù)責(zé)的產(chǎn)品有深刻的理解，能夠主動提出需要改進(jìn)的功能，并且對系統(tǒng)架構(gòu)有深刻的了解，能夠知道自己目前維護(hù)的系統(tǒng)的優(yōu)勢和不足在哪里，平時(shí)就督促一線開發(fā)人員做好系統(tǒng)優(yōu)化。在面對新需求時(shí)，能從產(chǎn)品角度給出新需求的建議，能從技術(shù)角度給出技術(shù)選型和實(shí)現(xiàn)方案，并能拉上測試人員及早接入了解項(xiàng)目。這樣，就能做到對這個(gè)項(xiàng)目有全局的把控，對開發(fā)節(jié)奏就有合理的排期，選擇適當(dāng)?shù)膱F(tuán)隊(duì)成員進(jìn)行開發(fā)，并且上線之后“坑”也很少。同時(shí)，能夠分辨出哪些項(xiàng)目是可以很快完成的，哪些項(xiàng)目是需要一起討論設(shè)計(jì)方案的，做項(xiàng)目的步驟中出現(xiàn)問題，及時(shí)與開發(fā)人員溝通，而不是總看著開發(fā)人員，讓他們自己溝通解決。
這就對技術(shù)管理人員的要求很高，需要技術(shù)管理人員不斷地鉆研業(yè)務(wù)和團(tuán)隊(duì)的技術(shù)?！凹みM(jìn)型”和“保守型”的管理風(fēng)格相互融合，團(tuán)隊(duì)的領(lǐng)導(dǎo)者應(yīng)該兼具這兩種風(fēng)格，這對技術(shù)方案的選擇和規(guī)劃開發(fā)計(jì)劃能夠提供很好的合理保證。因此，實(shí)際上，技術(shù)管理者的門檻應(yīng)該是很高的，他除了技術(shù)過硬外，還需要足夠了解業(yè)務(wù)本質(zhì)，足夠了解手頭的技術(shù)架構(gòu)的重點(diǎn)和難點(diǎn)，知道將來的部署方向，掌握每一個(gè)技術(shù)人員的技術(shù)本領(lǐng)以及期望的發(fā)展方向。
另外，談?wù)劥蠊竞蛣?chuàng)業(yè)公司的區(qū)別，他們最大的區(qū)別就在于溝通的成本，以及由此決定的員工工作時(shí)的心態(tài)和狀態(tài)。
對于BAT之類的大公司，犯錯(cuò)誤的成本是很高的。因此，在開發(fā)過程中，溝通的成本非常高。大公司的流程管理相對比較規(guī)范和嚴(yán)格，有些是以KPI為導(dǎo)向的，團(tuán)隊(duì)里的技術(shù)、產(chǎn)品、運(yùn)營都有專門的負(fù)責(zé)人，他們都有自己獨(dú)立的KPI，即使這些不同角色的人都是負(fù)責(zé)同一個(gè)項(xiàng)目也是如此。因此，在做項(xiàng)目時(shí)，一個(gè)很小的改動，或者一次很小的溝通，甚至是一次很平常的溝通的結(jié)論，大都需要發(fā)出郵件讓雙方的領(lǐng)導(dǎo)知情，很多效率會損失在這里。因此，這種管理風(fēng)格多是“保守”的。
而創(chuàng)業(yè)公司一般是，想到一個(gè)好點(diǎn)子就立即安排去實(shí)現(xiàn)，或者遇到競品上線了一個(gè)新功能也立刻實(shí)現(xiàn)相應(yīng)的功能。因此，開發(fā)周期相對都很快，管理方式也略微“激進(jìn)”些。
管理方式的不同事關(guān)公司，也事關(guān)管理者。也有一些公司在這個(gè)層面做得很好，他們的管理者在決策上比較有經(jīng)驗(yàn)，既不盲目追溯，也不大跨步冒進(jìn)，他們的技術(shù)管理人員承擔(dān)了很大的決策壓力，因此非常有膽識。
有些年輕人以在大公司工作為驕傲，也有些職場新手羨慕和敬仰大公司。這里，我借用喬布斯說的一段話來與讀者共勉：“公司規(guī)模擴(kuò)大之后，就會變得因循守舊，員工們覺得只要遵守流程，就能奇跡般地繼續(xù)成功，于是開始推行嚴(yán)格的流程制度，很快員工就把遵守流程和紀(jì)律當(dāng)作工作本身?！币虼?，無論在哪里，我們都應(yīng)該實(shí)現(xiàn)的是在工作目標(biāo)本身上的突破，而不是拘泥于流程本身。
很多情況下，公司效率往往損失在細(xì)微末節(jié)的小事上。比如，某個(gè)技術(shù)人員的代碼沒有通過運(yùn)行就提交了，不慎被發(fā)布到線上，然后為這件事需要耽誤好幾天的時(shí)間來修復(fù)和后續(xù)案例分析；再如，同事之間對同一個(gè)文件的代碼進(jìn)行修改后，合并后沒有正確解決沖突。這種錯(cuò)誤雖然很小，但是也極大地影響了團(tuán)隊(duì)的工作效率，往往要牽扯到好幾個(gè)人去處理。這種錯(cuò)誤往往發(fā)生在比較“激進(jìn)”的團(tuán)隊(duì)中，這時(shí)，一些開發(fā)流程對出現(xiàn)這些錯(cuò)誤就有了規(guī)避的作用。
（1）代碼需要經(jīng)過代碼評審（code review，CR）。代碼評審的重要性不言自明，對于被評審者，他可以學(xué)到很多現(xiàn)成的編碼經(jīng)驗(yàn)；而對于評審人員，他可以看看新手有哪些新的設(shè)計(jì)思路，給自己以啟發(fā)，并且能知道系統(tǒng)中常犯的錯(cuò)誤和問題，對高屋建瓴地理解系統(tǒng)非常重要。但是，現(xiàn)在代碼評審?fù)缓芏喙竞鲆暋Ｋ€是一道心里防線，能夠防止未運(yùn)行通過的代碼被提交。
（2）即使是簡單的一次代碼上線，也需要測試人員和運(yùn)維人員去驗(yàn)證。很多情況下，開發(fā)人員認(rèn)為修改量很小，影響范圍有限，因此直接上線了，這往往會導(dǎo)致問題出現(xiàn)，在我周圍也聽說過很多例。因此，無論修改范圍大小，都需要經(jīng)過驗(yàn)證的流程。
（3）慎重使用root權(quán)限。運(yùn)維人員往往有很多機(jī)器的最高權(quán)限，但人畢竟不是機(jī)器，有累、困、餓、煩的時(shí)候，有很多誤操作就來源于這種情況下的“rm -rf”。因此，一些解決經(jīng)驗(yàn)就是：重新編譯或者自己實(shí)現(xiàn)rm命令的源代碼，進(jìn)入重要目錄后，執(zhí)行這個(gè)操作時(shí)，需要輸入密碼，這個(gè)密碼可以是“當(dāng)天的0點(diǎn)時(shí)間戳加上當(dāng)天的星期序號的md5值”等。嚴(yán)格執(zhí)行根據(jù)運(yùn)維級別給予操作權(quán)限，對應(yīng)重要目錄的權(quán)限，即使很高級別的人，也不能隨意切換到root用戶，執(zhí)行rm -rf操作。
聯(lián)系客服
