項目經理需要了解的開發經驗

原文  http://www.infoq.com/cn/news/2014/04/pm-dev-knowledge

在IT公司中，管理層和“自命清高”的技術人員之間的溝通和協調永遠是一個值得讨論的話題，先後從事過技術和管理工作的資深産品經理韓偉 分析 了技術人員的管理之道，包括何時以及如何評審、分層開發、盡快運作、追求代碼品質等。

韓偉首先分析了管理層和技術人員之間的代溝：

在網際網路項目當中，相信每一個項目經理或者制作人，最頭疼的就是技術部的管理。因為技術工作看起來是那麼的棘手，一般人難以了解，而且技術人員大多數都似乎情商不高。管理人員既不能輕易了解技術工作的内涵，技術人員也覺得很難和管理人員溝通。特别是技術工作，難以在不同人之間交接，很多技術人員都聲稱無法繼續别人做過的項目……要管理好技術人員，就一定要懂技術。這是任何一種其他号稱完美的管理方法都無法替代的。

開發文檔的問題是一個老問題，韓偉根據文檔的不同類型談了自己的看法：

• 設計類文檔：這類文檔往往在項目、子產品啟動的時候，大家都會想到要去寫，作為讨論和最後決議的成果，顯然是很自然的。然而在項目進入開發之後，碰到實際問題時，往往就不能完全按照設計的初衷去做了，是以通常設計文檔就在這個時候和代碼脫離了聯系。但有一點是絕對可以做的，就是在重構的時候，按照現有狀況，重新增加重構前的系統狀況說明，然後再添加上重構後的設計。這樣就把重構的設計和文檔的更新結合到一起了。
• API(應用程式設計接口)文檔：現代軟體都希望能提高重用的程度，是以很多程式員都會自己構造自己的業務API，以便在之後的開發中使用。而這種業務API，也是很多分工合作的基礎。這種代碼的說明，會直接影響日常的開發，是以非常有必要保證和代碼的高度一緻性。
• 使用文檔：一般來說，一個軟體的使用文檔必須包含以下幾個：《産品版本說明》、《産品安裝和部署文檔》、《産品使用教程以及例程》、《産品FAQ文檔》。這裡面的《産品版本說明》應該在每次發版的時候，作為釋出流程的一個固有環節來設計。《産品使用教程以及例程》是我認為所有文檔中，最值得花大力氣去寫好的。《産品安裝和部署文檔》内容越少越好，應該讓安裝部署盡量智能化、自動化。

其次，韓偉認為，了解軟體架構的範疇，才能有針對性地去把握軟體開發中的風險，進而管理好軟體開發的過程。根據軟體需要應對的需求，軟體架構一般包含以下幾個部分：

• 邏輯架構：主要是為了明确“功能性需求”而做的設計，針對需求以及需求變化作為架構目标所做出的關于代碼之間的劃分、耦合、關聯的決定。采用合理的邏輯架構，将會大大降低需求變更對開發的延遲作用。邏輯架構最直接指導代碼中互相耦合的情況，仔細設計好耦合的規則，會讓後續開發事半功倍。
• 運作時架構：運作時架構是為了滿足運作期的品質需求，所做出的關于對象行文、程序結構、通信協定、資料結構等方面的決定。運作架構一旦确定，等于大部分的“實作”代碼都确定了，設計有足夠擴充性和可用性的運作架構，可以為後續工作節省時間，也降低了系統在運作期對開發工作的幹擾。
• 開發架構：為了滿足開發時的需求所做的決定，主要是軟體根據分工開發、測試驗證流程等需求劃分的軟體層次和區域以及各種接口設計，也包含使用的軟體包、元件庫、開發工具，以及編譯建構的方法。一個好的開發架構，可以讓溝通成本降低，開發速度提高。
• 部署架構：現代軟體系統，基本上都包括了用戶端和服務端程式，如何快速、高效、穩定地部署和釋出這些程式，如網絡機房的分布、伺服器硬體的搭配、監控和維護工具軟體的安裝、開發測試網絡和營運網絡的設定。可以獲得安全性的配置，良好的部署能力，能推動軟體進行更頻繁、更全面的測試，進而提高軟體品質和開發效率。
• 資料架構：資料是軟體項目的核心财富，關于資料的結構，資料的存放、備份、傳輸會直接影響到運作性能、業務功能、部署、安全等需求。在面向對象的開發模式下，資料到對象的ORM架構也是很重要的設計。一個完整的資料架構包括了資料流圖、資料字典、ORM結構(如果需要的話)、資料索引和備份機制等幾個方面。

相信大部分公司都有評審這個環節，評審可以包括方案評審、代碼評審、項目專項議題的評審，比如對存留Bug的處理評審等。而這些評審，常常會變成一個挑毛病的會議。要解決評審給産品帶來的負面影響，同時發揮這個活動的優點，韓偉指出，需要注意以下幾個方面：

• 評審由誰發起：相對比較好的是，由負責此項目的“上司”來召集人員評審，并且一定要有負責開發的人員參加評審。參與評審的受邀請人員可能會與方案送出者就一些問題有分歧，但送出者有最終決定權。要把權力給有能力承擔它的人。這樣做可以讓“防止風險”的一部分人和“注重效率”的開發人員形成平等的意見交換。
• 什麼時候做評審：應該在每個疊代、每個較大的版本開工前，或者僅僅是某個認為比較重要的決定做出前，都來一次簡短的評審。如果開始時隻是做一個DEMO，那麼需要評審的東西也比較少，而随着不斷的開發，評審也能周遊所有的開發。
• 做評審的方法：真正對項目有幫助的，是了解項目的需求，分析面臨的難點，思考方案為何這樣做，提出自己的解決方案，給項目開發者以建議和啟發。多說“我建議這樣解決這個問題”，而不要僅僅去說“這樣做可能有問題，應該添補這樣的功能”。以建設性的心态和思路去做評審，而不是以找問題的思路去做，這就是兩種做法的最大差別。

除此之外，韓偉還讨論了分層開發、盡快運作、非功能需求決定成敗、追求代碼品質、搭好測試這個安全網、自己掌控開發方向、告别救火隊員、績效評估等問題，管理層在了解這些知識之後，可以更加得心應手地管理技術人員。