專案經理值得一試的思維方式：專案成功方程式

“有沒有一個一勞永逸的專案管理實踐？”
“我怎樣才能找到一個能夠解決所有問題的方法？”
“為什麼我用的都是同樣的方法，但有的專案延期了？”
……
在很多敏捷群中，經常會有人問這些問題。那有沒有一個可以解決所有問題的方法呢？答案是：沒有，因為沒有銀彈。

早在1986年，弗雷德·布魯克斯就曾在學術角度提出：沒有能解決軟體危機的銀彈。為什麼呢？其最根本的原因在於，軟體本身有以下固有特性：

• 複雜度：軟體複雜度會隨著規模呈現非線性增長，出現專案成本超支、人員狀態不同步、功能可用性差、結構複雜等問題；
• 一致性：軟體系統需要與現有系統進行互動，這就需要讓新軟體系統的介面與原有軟體系統保持一致；
• 可變性：由於使用者需求、市場等外在因素是持續變化的，這要求軟體需要具備可變性；
• 不可見性：每個人對軟體、需求或任務都有不同的理解，這會讓溝通變得異常困難。

這些特性在軟體交付專案中會產生諸多挑戰，降低團隊效能，甚至會導致專案失敗。

面對這些挑戰，我們並非沒有辦法。雖然在軟體交付專案中沒有銀彈，但專案成功是一系列因素共同作用的結果。我們只要找出能夠影響專案過程的因素，並立刻行動，就能推動專案成功率提高。我們可以通過一個思維方式——打造團隊的專案成功方程式來推動專案成功：

從上面這個專案成功方程式，我們可以得知，專案是否成功交付，取決於各個因素的界限值。在專案中，低界限的因素將決定整個專案的上限。也就是說，如果將專案中每一個因素都能從1提升到1.01，多項的相乘也將產生巨大的成果。相對應的，如果將每一項都降低為0.99，比如管理粗糙“一點”、價值降低“一點”、行動慢“一點”……這樣的專案就會漏洞百出。

那如何將專案中的因素從1提升到1.01呢？以下行動路徑可以給大家一些幫助：

項 目因素		具體行動措施	要求
立即行動		Plan-Do-Check-Action	Talk is cheap. Show me the code.
專案管理過程	需求階段	規範使用者故事 進行需求評審 確認需求優先順序 縮短迭代週期 合理估算規模	合理把控產品交付計劃。
	開發階段	程式碼規範 程式碼集體所有 原始碼管理 程式碼評審 重構 現場客戶	通過眾多工程實踐提高專案成功率。
	測試階段	儘早測試 自動化測試 為測試人員賦權	通過提高測試質量，加速專案成功。
	過程改進	回顧會議	不斷優化整個專案過程，實現過程改進。
團隊		避免分散式團隊 組建跨職能團隊 每日站會或看板	與團隊中其他成員及時同步自己的任務狀態，及時發現並解決日常問題。
工具		通用的禪道專案管理工具 Axure、墨刀等原型製作工具 XMind、FreeMind等思維導圖 GitHub、GitLab等原始碼管理工具 Selenium等自動化測試工具 ZenData等測試資料生成工具	藉助工具，提升工作效率。
時商		在熱門與價值中間做出選擇 保持自律 奉行長期主義	合理運用時間，創造更大價值。
管理方式		學會傾聽 向下放權 擁有同理心 正確的價值觀 樹立全域性觀	通過打造服務型領導，鼓勵團隊之間的信任與合作，充分調動團隊成員的主動性與積極性。
產品價值		使用者價值 商業價值 社會價值	產品價值在整個專案成功方程式中是最特殊的一環：只有產品產生了價值，專案成功才會有意義。

專案成功方程式只是幫助專案經理們更好地思考問題的一種方式，專案成功受多方因素影響，上面列舉出來的並非影響專案成功的全部因素，因此專案相關成員可以根據自己的經驗和教訓，不斷地擴充這一專案成功方程式，改進團隊專案管理方式。和我們一起來尋找每個專案的最佳實踐吧。