項目管理的黑洞
有不少非軟件工程科班專業的老闆表示，真的不知道如何管理和把控軟件項目的管理，因爲那些編程的專業和編程語言他又不懂。
也有不少新晉的開發管理者，從以前負責系統的核心開發人員晉升到團隊管理者，剛開始對項目管理、向上彙報、跨部門溝通也表示有點力不從心，不知從何處入手。
軟件工程，是一門工程，也是一門藝術。研發管理不應該是黑洞，應該是有科學、有條理、有工具、有流程的。本次來分享下，如何更清晰地洞悉自己的項目狀態，從而進行更好的項目把控。
如何看懂你的項目健康狀態和完整度
軟件項目是指在一定時間段內需要完成的有限需求集合。
從需求被提出開始，到最終發佈上線，中間的協作流程，根據敏捷開發、Scrum、瀑布流程，各有各的不同。但對於中間的輸出物和協作環節，大同小異。
瞭解了軟件項目的定義和協作流程後，我們就可以在過程中進行實時的把控，而不是在項目最後交付和衝刺的階段才發現進度風險問題，再遲遲做出反應。
爲此，我們需要一個概念，一個統一的通用語言，一個工具。
概念是指我們大家都能理解這個概念是有助於我們每個從整體上把控項目的進度；通用語言是方便開發人員、項目干係人、老闆、和非專業的業務部門人員都能通俗易懂地瞭解，不需要過多解釋；工具是藉助於在線的圖形化工具進行恰當的表達。
巧用項目地圖
借鑑於建築學的經驗，結合在買房時銷售人員都會通過沙盤圖進行講解、形象生動的介紹。
（圖片來自網絡）
這裏，我們使用【項目地圖】這一概念來整體概括和表達項目的整體進度和協作情況。它是一個動態、形象、概要的流程統計圖。
從上往下，由淺入深，項目地圖分別依次從產品、項目、研發和測試四個層面進行了剖析。
在產品側，我們關注需求提供的質量，重點關注PRD（即產品需求原型的梳理），拒絕口頭上的一句話需求。凌亂的需求是“萬惡”之源。一開始的需求定義有多隨意，後續的研發就會有多痛苦，因爲需求不明確，開發很痛苦。在產品側的最後，我們關注已完成和已上線的需求，從而構成需求交付的最核心把控。如果一個項目迭代中，有10個需求，這10個需求都完成了，那麼此項目也就結束了。
第二層，在項目側，是由項目負責人、或者技術經理、或產品Manager把控的。他們更多是關心項目的進度、項目風險、項目的整體資源安排。其中，最核心則是關注項目工時的開發進度。從最開始的項目總工時開始，到項目的燃盡圖、項目的甘特圖、項目的排期表、項目里程碑，到最後的項目整體進度。
第三層，在一線研發執行層面，關心的維度是：項目工時、代碼提交、開發文檔和發佈次數。項目工時方便我們知道項目的規模和側面的複雜度（一般而言，工時越大，項目複雜度越高，風險越大）；代碼提交方便我們及時知道最真實的代碼提交情況（可以通過和Git代碼託管平臺的web hook自動對接和集成）；開發文檔是當前開發最爲缺失但又是很重要的一環，好的開發文檔有利於核通複雜需求的設計思路、技術評審和日後的低成本維護；發佈次數是指真實的上線發佈次數（通過接入YesDev的一鍵發佈後系統會自動記錄）。
最後，在測試層面，關注的是項目質量，通過測試用例、測試計劃、Bug修復的進度來體現。
來看看你的項目協作評分
爲了方便團隊每個人清晰地知道當前迭代項目的協作情況和整體情況，我們設計並提供了項目協作評分，滿分是120分。如果協作下來，你的項目協作評分在80分及以上，則是良好的，在100分及以上則是優秀的，如果低於80分，則表示內部的協作不順暢、或缺乏、或未使用此工具進行協作。
整體上看，項目地圖，使用了單向有向圖，如果圖中的節點未被點亮，則表示這個協作環節是缺失的。至於是否對項目協作和團隊的管理來說是必須的，則需要自己來判斷。
關注項目的收入/預算、成本和ROI
最後，作爲老闆或經營者或管理層，可以關注項目的收入/預算、成本和ROI。
在開發項目的同時，也要留意項目預算的消耗，項目不延期、項目不虧本、項目無風險，內部協作順暢、高效又士氣高昂，便是人間好時節。