在互聯(lián)網(wǎng)項目當中，相信每一個(gè)項目經(jīng)理或者制作人，最頭疼的就是技術(shù)部的管理。因為技術(shù)工作看起來(lái)是那么的棘手，一般人難以理解，而且技術(shù)人員大多數都似乎情商不高。管理人員既不能輕易了解技術(shù)工作的內涵，技術(shù)人員也覺(jué)得很難和管理人員溝通。特別是技術(shù)工作，難以在不同人之間交接，很多技術(shù)人員都聲稱(chēng)無(wú)法繼續別人做過(guò)的項目。這讓管理者覺(jué)得技術(shù)人員特別喜歡耍大牌，而且他們要偷懶也非常容易。但正如軍事中的定理，對付坦克最好的武器就是坦克，對付航母最好的武器也是航母，這條理論是通用的。要管理好技術(shù)人員，就一定要懂技術(shù)。這是任何一種其他號稱(chēng)完美的管理方法都無(wú)法替代的。

開(kāi)發(fā)是一切——何時(shí)寫(xiě)文檔

對于技術(shù)管理來(lái)說(shuō)，很多公司會(huì )非常注重文檔。雖然開(kāi)發(fā)的結果是代碼，但對于管理來(lái)說(shuō)，代碼往往難以閱讀，也很少有人擅長(cháng)接手別人的系統。為了讓代碼不至于被丟棄，公司管理人員就祭起文檔這個(gè)法寶。我認為文檔是很重要的，但也發(fā)現這些文檔中很典型地存在幾個(gè)問(wèn)題：文檔和代碼不同步;文檔的可讀性差，需要的文檔沒(méi)寫(xiě)，不需要的文檔寫(xiě)了一大堆;文檔和代碼脫節，文檔很多，開(kāi)發(fā)出來(lái)的成果很少。

我們應該何時(shí)寫(xiě)什么文檔，這是需要有嚴格定義，并且有檢查過(guò)程的，而不是任由大家自然發(fā)展就可以完善的。代碼的編寫(xiě)需要按不同類(lèi)型，定義好在各個(gè)階段中所需要完成的部分。

設計類(lèi)文檔—— 這類(lèi)文檔往往在項目、模塊啟動(dòng)的時(shí)候，大家都會(huì )想到要去寫(xiě)，作為討論和最后決議的成果，顯然是很自然的。然而在項目進(jìn)入開(kāi)發(fā)之后，碰到實(shí)際問(wèn)題時(shí)，往往就不能完全按照設計的初衷去做了，所以通常設計文檔就在這個(gè)時(shí)候和代碼脫離了聯(lián)系。但有一點(diǎn)是絕對可以做的，就是在重構的時(shí)候，按照現有狀況，重新增加重構前的系統狀況說(shuō)明，然后再添加上重構后的設計。這樣就把重構的設計和文檔的更新結合到一起了。

API(應用編程接口)文檔——現代軟件都希望能提高重用的程度，因此很多程序員都會(huì )自己構造自己的業(yè)務(wù)API，以便在之后的開(kāi)發(fā)中使用。而這種業(yè)務(wù)API，也是很多分工合作的基礎。這種代碼的說(shuō)明，會(huì )直接影響日常的開(kāi)發(fā)，因此非常有必要保證和代碼的高度一致性。

使用文檔—— 一般來(lái)說(shuō)，一個(gè)軟件的使用文檔必須包含以下幾個(gè)：《產(chǎn)品版本說(shuō)明》、《產(chǎn)品安裝和部署文檔》、《產(chǎn)品使用教程以及例程》、《產(chǎn)品FAQ文檔》。這里面的《產(chǎn)品版本說(shuō)明》應該在每次發(fā)版的時(shí)候，作為發(fā)布流程的一個(gè)固有環(huán)節來(lái)設計?！懂a(chǎn)品使用教程以及例程》是我認為所有文檔中，最值得花大力氣去寫(xiě)好的?！懂a(chǎn)品安裝和部署文檔》內容越少越好，應該讓安裝部署盡量智能化、自動(dòng)化。

了解什么是軟件架構

了解軟件架構的范疇，才能有針對性地去把握軟件開(kāi)發(fā)中的風(fēng)險，從而管理好軟件開(kāi)發(fā)的過(guò)程。簡(jiǎn)單來(lái)說(shuō)，軟件架構就是應對需求所產(chǎn)生的“一系列決定”。軟件會(huì )根據這些決定來(lái)開(kāi)發(fā)。根據軟件需要應對的需求，軟件架構一般包含以下幾個(gè)部分。

邏輯架構 主要是為了明確“功能性需求”而做的設計，針對需求以及需求變化作為架構目標所做出的關(guān)于代碼之間的劃分、耦合、關(guān)聯(lián)的決定。采用合理的邏輯架構，將會(huì )大大降低需求變更對開(kāi)發(fā)的延遲作用。邏輯架構最直接指導代碼中互相耦合的情況，仔細設計好耦合的規則，會(huì )讓后續開(kāi)發(fā)事半功倍。

運行時(shí)架構 運行時(shí)架構是為了滿(mǎn)足運行期的質(zhì)量需求，所做出的關(guān)于對象行文、進(jìn)程結構、通信協(xié)議、數據結構等方面的決定。運行架構一旦確定，等于大部分的“實(shí)現”代碼都確定了，設計有足夠擴展性和可用性的運行架構，可以為后續工作節省時(shí)間，也降低了系統在運行期對開(kāi)發(fā)工作的干擾。

開(kāi)發(fā)架構 為了滿(mǎn)足開(kāi)發(fā)時(shí)的需求所做的決定，主要是軟件根據分工開(kāi)發(fā)、測試驗證流程等需求劃分的軟件層次和區域以及各種接口設計，也包含使用的軟件包、組件庫、開(kāi)發(fā)工具，以及編譯構建的方法。一個(gè)好的開(kāi)發(fā)架構，可以讓溝通成本降低，開(kāi)發(fā)速度提高。

部署架構 現代軟件系統，基本上都包括了客戶(hù)端和服務(wù)端程序，如何快速、高效、穩定地部署和發(fā)布這些程序，如網(wǎng)絡(luò )機房的分布、服務(wù)器硬件的搭配、監控和維護工具軟件的安裝、開(kāi)發(fā)測試網(wǎng)絡(luò )和運營(yíng)網(wǎng)絡(luò )的設置?？梢垣@得安全性的配置，良好的部署能力，能推動(dòng)軟件進(jìn)行更頻繁、更全面的測試，從而提高軟件質(zhì)量和開(kāi)發(fā)效率。

數據架構 數據是軟件項目的核心財富，關(guān)于數據的結構，數據的存放、備份、傳輸會(huì )直接影響到運行性能、業(yè)務(wù)功能、部署、安全等需求。在面向對象的開(kāi)發(fā)模式下，數據到對象的ORM架構也是很重要的設計。一個(gè)完整的數據架構包括了數據流圖、數據字典、ORM結構(如果需要的話(huà))、數據索引和備份機制等幾個(gè)方面。

何時(shí)以及如何評審

相信大部分公司都有評審這個(gè)環(huán)節，評審可以包括方案評審、代碼評審、項目專(zhuān)項議題的評審，比如對存留Bug的處理評審等。而這些評審，常常會(huì )變成一個(gè)挑毛病的會(huì )議。要解決評審給產(chǎn)品帶來(lái)的負面影響，同時(shí)發(fā)揮這個(gè)活動(dòng)的優(yōu)點(diǎn)，我們需要關(guān)注以下幾個(gè)方面。

評審由誰(shuí)發(fā)起 相對比較好的是，由負責此項目的“領(lǐng)導”來(lái)召集人員評審，并且一定要有負責開(kāi)發(fā)的人員參加評審。參與評審的受邀請人員可能會(huì )與方案提交者就一些問(wèn)題有分歧，但提交者有最終決定權。要把權力給有能力承擔它的人。這樣做可以讓“防止風(fēng)險”的一部分人和“注重效率”的開(kāi)發(fā)人員形成平等的意見(jiàn)交換。

什么時(shí)候做評審 應該在每個(gè)迭代、每個(gè)較大的版本開(kāi)工前，或者僅僅是某個(gè)認為比較重要的決定做出前，都來(lái)一次簡(jiǎn)短的評審。如果開(kāi)始時(shí)只是做一個(gè)DEMO，那么需要評審的東西也比較少，而隨著(zhù)不斷的開(kāi)發(fā)，評審也能遍歷所有的開(kāi)發(fā)。

做評審的方法 真正對項目有幫助的，是了解項目的需求，分析面臨的難點(diǎn)，思考方案為何這樣做，提出自己的解決方案，給項目開(kāi)發(fā)者以建議和啟發(fā)。多說(shuō)“我建議這樣解決這個(gè)問(wèn)題”，而不要僅僅去說(shuō)“這樣做可能有問(wèn)題，應該添補這樣的功能”。以建設性的心態(tài)和思路去做評審，而不是以找問(wèn)題的思路去做，這就是兩種做法的最大區別。

分層開(kāi)發(fā)，盡快運行

為了降低軟件耦合給開(kāi)發(fā)帶來(lái)的負面影響，正確的做法是要高度重視軟件開(kāi)發(fā)方法，從代碼風(fēng)格、軟件架構、設計模式、開(kāi)發(fā)模式方面來(lái)提高水平。其中一個(gè)最簡(jiǎn)單有效的做法，就是分層。在經(jīng)典的架構模式中，分層模式幾乎是所有模式的基本模式：把代碼按照你所需的范圍劃分層次，然后規定層次之間的耦合接口，層次之間只可單向依賴(lài)，而且盡量減少跨層耦合。劃分層次的范圍，由你的開(kāi)發(fā)團隊水平和項目的復雜程度決定。

非功能需求決定成敗

世界上類(lèi)似的項目非常多，但成功的占少數，失敗的占多數，這種現象的背后有一個(gè)重要的原因，就是非功能需求。非功能需求具體包括：軟件開(kāi)發(fā)效率的相關(guān)需求，比如代碼結構、代碼風(fēng)格、內容開(kāi)發(fā)工具、自動(dòng)構建部署工具;軟件的質(zhì)量穩定性的需求，如測試方面的需求，產(chǎn)品結構對于缺陷的防范，代碼質(zhì)量;軟件的運行承載力需求，包括可用性、容災性、可維護性、承載力、運行性能和成本需求;軟件的信息搜集方面的需求，如故障上報、數據統計和挖掘。

如何才能做好這些非功能需求呢?

首先是在項目成本規劃時(shí)，分配足夠多的資源，比如人力和時(shí)間，去做好這個(gè)事情;其次是要盡量合理地規劃和設計這些非功能需求，既不能貪多求全，也不能無(wú)所作為。

追求代碼質(zhì)量

代碼質(zhì)量不高帶來(lái)的危害包括人員流動(dòng)后沒(méi)法接手、Bug頻繁出現、效率問(wèn)題難以定位、開(kāi)發(fā)速度慢等。

什么樣的代碼才叫高質(zhì)量的代碼?代碼質(zhì)量存在一個(gè)唯一標準，就是可閱讀性?？勺x性好的代碼，結構通常更簡(jiǎn)單清晰，Bug也少;更多人愿意去閱讀的代碼，也會(huì )有更多的機會(huì )去改正Bug以及其他的缺陷?？勺x性好，也意味著(zhù)你能更簡(jiǎn)單地去找到改進(jìn)性能的方法，減少修改代碼帶來(lái)的風(fēng)險。

提高代碼質(zhì)量的手段，最簡(jiǎn)單的兩條，一是執行代碼規范，二是進(jìn)行代碼評審。除了規范制定和評審外，組織學(xué)習代碼質(zhì)量的知識，提倡并獎勵高質(zhì)量代碼的人員，也是提高代碼質(zhì)量的有效手段。

搭好測試這個(gè)安全網(wǎng)

單元測試是最原始的工程概念之一。單元測試對于互聯(lián)網(wǎng)應用來(lái)說(shuō)，一般會(huì )有一個(gè)困難，就是需要大量的“腳手架”，比如為了測試數據庫操作，必須要有一段代碼 “重置”數據庫的狀態(tài);為了測試網(wǎng)絡(luò )打包解包，則需要用一個(gè)程序向某個(gè)網(wǎng)絡(luò )端口發(fā)數據。而準備這些測試工具代碼的時(shí)間往往會(huì )比較長(cháng)，需要有足夠的耐心去做，但一旦做好了，往往能讓開(kāi)發(fā)風(fēng)險大大降低。

對于單元測試，我認為最少應該覆蓋所有正確的路徑，以及重點(diǎn)防御的錯誤路徑。覆蓋了這些重點(diǎn)關(guān)注的地方之后，放手重構代碼就很方便了。

單元測試應該是屬于代碼的一部分，和源代碼一起存放。自動(dòng)構建時(shí)也應該進(jìn)行檢查輸出結果。提交代碼時(shí)都會(huì )自動(dòng)運行單元測試，當“版本樹(shù)”需要合并“分支” 時(shí)，單元測試尤為重要，而最重要的是在分支上建立的單元測試。這些測試會(huì )大大加強系統的穩定性，因為檢驗了“合并”功能產(chǎn)生的代碼—這些代碼是最容易出錯的。

自己掌控開(kāi)發(fā)方向

開(kāi)發(fā)工作往往被需求變化“牽著(zhù)鼻子走”，需求往往會(huì )有很多來(lái)源：產(chǎn)品策劃的想法、老板的意見(jiàn)、用戶(hù)的反饋、數據統計的結論等。提出的各種需求，往往會(huì )對開(kāi)發(fā)團隊造成很大壓力。這些問(wèn)題都需要我們對需求做出有效的管理。然而我們應該如何去搜集、記錄、過(guò)濾、實(shí)現這些需求呢?

我們需要很好地搜集記錄需求。有的團隊會(huì )設立兩面故事墻，任何方面的需求，都可以減縮成一個(gè)故事，寫(xiě)到一張便簽紙上，貼到故事墻上，專(zhuān)人處理，而不會(huì )石沉大海。

有的公司會(huì )試圖把這個(gè)事情用電子化流程來(lái)做，但電子化流程有個(gè)顯著(zhù)的缺點(diǎn)，就是為了更多地自動(dòng)化處理，會(huì )加入大量的字段，對于故事這種還未謹慎定義過(guò)的東西，要認真填寫(xiě)太多的資料，無(wú)疑會(huì )給使用者造成額外的負擔。

告別救火隊員

在產(chǎn)品進(jìn)入運營(yíng)期間，最牛的程序員似乎總是在充當救火員，各種各樣的突發(fā)事件、棘手問(wèn)題中，我們的“高手”往往疲于奔命，永遠都在做一些補救的措施。有經(jīng)驗的人員一直沒(méi)空做開(kāi)發(fā)，因此大量的代碼由那些水平較差的人來(lái)完成，反過(guò)來(lái)埋下了更多的問(wèn)題。然而，如果不是忙著(zhù)亡羊補牢，我們的資深程序員就可以把更多的精力放在開(kāi)發(fā)上，這些有經(jīng)驗的程序員所生產(chǎn)的代碼，又會(huì )進(jìn)一步降低出故障的概率，這才是走向良性循環(huán)的方法。

為了減少運營(yíng)期間的壓力，在系統設計時(shí)，就要特別注意關(guān)于可維護性的非功能需求。運營(yíng)事故當中，因為部署錯誤所導致的占很大一部分，因此降低部署錯誤需要做到：全代碼包發(fā)布，每個(gè)發(fā)布版本要包含所有的可執行文件;所有的服務(wù)器上部署的配置文件和數據文件都必須做到完全一致，降低更新文件的復雜度。本機IP地址應該用代碼從網(wǎng)卡上直接讀取，但應該提供可以配置的選擇，預備多個(gè)IP的服務(wù)器使用;只使用命令行方式來(lái)啟動(dòng)不同功能，如選擇配置文件路徑、輸入不同功能進(jìn)程或服務(wù)器的配置;程序支持關(guān)閉、重載配置這兩個(gè)信號。在處理這兩個(gè)信號時(shí)，都不應該讓使用者感覺(jué)突然“掉線(xiàn)”;開(kāi)發(fā)用于安全關(guān)閉程序、重載配置的腳本或功能;開(kāi)發(fā)用戶(hù)自動(dòng)重啟所部署進(jìn)程的腳本，以及配置開(kāi)機自動(dòng)啟動(dòng)所部署的進(jìn)程;每個(gè)進(jìn)程都不應該強行鎖定某資源，必須要能做到一份安裝復制多進(jìn)程并行運行等。

每天發(fā)版

如果你想知道項目每一天的開(kāi)發(fā)進(jìn)度，你就必須要做到每天發(fā)版，測試每天的工作進(jìn)度，如果要順利地每天發(fā)版，就必須建立一個(gè)持續集成的系統。一般來(lái)說(shuō)持續集成系統會(huì )有以下的先后步驟：?jiǎn)卧獪y試—自動(dòng)構建—自動(dòng)部署—集成測試—自動(dòng)發(fā)布。

單元測試關(guān)鍵是要能堅持覆蓋所有新加入的代碼;自動(dòng)構建是由構建腳本、構建服務(wù)器、持續集成系統幾部分組成。

對于美術(shù)、產(chǎn)品或者別的非技術(shù)人員，添加的數據往往也需要有自動(dòng)部署的工具，而且因為通常他們產(chǎn)生的文件比較大，每次的全體打包然后覆蓋，可能會(huì )非常沒(méi)效率。雖然事情要做得完美不是很容易，但絕對是物有所值。

版本列車(chē)

我們時(shí)常只是對技術(shù)工作有版本管理的過(guò)程，而對于其他環(huán)節，常常停留在最原始的狀態(tài)。我們需要在整個(gè)項目開(kāi)發(fā)的每個(gè)環(huán)節，都進(jìn)行合理的項目管理。在多個(gè)項目的經(jīng)驗積累之后，提出了全過(guò)程的項目管理的概念：版本列車(chē)。

版本列車(chē)的含義是按照項目的工作流程，為每個(gè)有產(chǎn)出的環(huán)節都定義一個(gè)版本“車(chē)廂”，然后按照工作流程的先后依賴(lài)順序，形成一個(gè)完整的“版本列車(chē)”。第一個(gè)工作環(huán)節負責版本號，然后在這個(gè)版本號之下填充版本內容。當工作完成，此版本的工作內容則帶著(zhù)版本號進(jìn)入下一個(gè)“車(chē)廂”，依此類(lèi)推。

這樣做的好處是，每個(gè)環(huán)節的每份產(chǎn)出都可以明確地知道其進(jìn)度位置，安排在什么時(shí)候做。對于需要提前準備市場(chǎng)推廣或者別的工作部門(mén)，有一個(gè)非常明確的長(cháng)期計劃。對于進(jìn)度管理來(lái)說(shuō)，各個(gè)部門(mén)也能知道整個(gè)項目的當前狀態(tài)。

論功行賞(績(jì)效評估)

不管是對被評的人，還是對評價(jià)別人的來(lái)說(shuō)，績(jì)效評估都非常難做。因為很多工作并非能很準確地列舉出一二三來(lái)，工作任務(wù)也可能有大量臨時(shí)變更。太過(guò)主觀(guān)會(huì )讓人覺(jué)得草率;非要去依據可量化的數據，又過(guò)于死板和片面。但沒(méi)有一個(gè)公司敢不做考核，所以說(shuō)績(jì)效評估是“明知山有虎，偏向虎山行”。

績(jì)效考核應該重點(diǎn)關(guān)注的是做了什么事，而不是做得怎么樣。這個(gè)讓很多按“結果”管理的老板很不接受?？?jì)效考核應該是推動(dòng)別人去做某件事的工具。對于已經(jīng)明確的方法或者子目標，通過(guò)這種細化的方式去指導下屬工作。因為是需要事后算賬的，而且是量化的，所以下屬會(huì )對這個(gè)事情很認真，同時(shí)那些不好量化的事情，管理者也很難執行績(jì)效考核。所以“去做某些事”，是績(jì)效考核最好的目標。

通過(guò)考核結果提供正式的工作方法意見(jiàn)?？?jì)效考核本身有個(gè)反饋的過(guò)程，這個(gè)反饋的過(guò)程應該提供給下屬針對每個(gè)具體事情的建議。這種具體地，單獨地，一對一地指導，會(huì )提高團隊的穩定性，而且也讓團隊成員獲得“受關(guān)注”的感覺(jué)，這種感覺(jué)是形成高效團隊的重要工具。

考核不能代替目標，不能阻礙目標，而應該是一個(gè)溝通工具。目標達成情況是考核的客觀(guān)指標，但不應該作為主要績(jì)效考核指標。最簡(jiǎn)單的績(jì)效考核指標就是收入或者利潤率。但這種簡(jiǎn)單指標除了在動(dòng)機上提高下屬的工作熱情外，并沒(méi)有從方法和經(jīng)驗上幫助團隊成員。有效的考核應該是引導下屬按照更有經(jīng)驗的方法去實(shí)現目標。

本文節選自《世界500強互聯(lián)網(wǎng)產(chǎn)品經(jīng)理管理筆記》一書(shū)，刊登時(shí)內容有修改。作者先后就職于多家互聯(lián)網(wǎng)公司，經(jīng)歷橫跨技術(shù)開(kāi)發(fā)、產(chǎn)品設計、團隊管理。通過(guò)梳理十年多從業(yè)經(jīng)歷，將大型團隊管理和產(chǎn)品開(kāi)發(fā)領(lǐng)域實(shí)踐經(jīng)驗與讀者分享。電子工業(yè)出版社授權刊發(fā)。