一線架構師的一些項目管理心得

項目管理

現代的項目管理一般是4個部分：需求、軟件設計、軟件開發、產品交付與維護。一般狀況下，整個過程是中間重兩頭輕。

1，需求

每一個項目都是要明確需求的，由於沒有明確的需求，就沒有項目結束的時間。

需求須要分享

在項目的初始階段，是進行需求整理和需求分析，把需求整理和分析的結果分享給團隊，可使團隊對產品的願景擁有清晰的認識，同時，由於有明確的需求，團隊成員會對產品有更高的認同感。

需求須要管理

在項目中，需求常常是不斷變化的，或增長、或改動，而溝通需求的時間一般是不充分的。因此，須要對需求進行等級規劃，等級高的優先處理，進而造成階段性開發，造成開發節點，即里程碑。這樣能夠在不一樣的階段結束時，對需求進行再討論，使交付產品更接近客戶需求，同時規避需求頻繁改動帶來的風險。

2，軟件設計

軟件開發前，一般須要進行軟件的概要設計，經過概要設計來指定開發，從而能夠提升開發效率。

軟件設計時一般會參考一些設計標準，好比ADMEMS設計方法。

ADMEMS矩陣以下圖，理論上是先上後下，先左後右。

除了設計架構理論外，還要思考三個W。

Who：爲誰設計？What：要解決用戶的什麼問題？Why：爲何要解決這些用戶問題？

一般在項目啓動前是沒有成功的設計模式的，成功的設計模式都是完成後，回頭總結的，即，實際開發過程當中也都是靠摸着石頭過河的。不過有些經驗能夠借鑑。

3，軟件開發

在資源充分的狀況下，軟件開發是依託於概要設計拓展出來的詳細設計來指定代碼編寫的。不過，資源充分狀況相對較少，因此，多數狀況會取消詳細設計階段，直接代碼編寫。這樣，就須要良好的框架予以支撐。一般軟件開發進度隨着項目越大越完整，而變的越慢，良好的框架也不能解決這個問題，不過它能夠延緩研發效率變慢的出現時間。

在具體的代碼編寫實施中，有不少規則能夠參考，如ABSD（基於體系結構的軟件設計）、XP（極限編程）。一般來說，軟件開發方法就是指資源的合理調配。好比，項目功能分配，項目功能工時決策權分配，項目需求決策權分配等。

舉個敏捷開發的需求決策權分配方法，該方法的好處是研發人員即項目經理，能夠減小人員投入。

具體實施以下：

需求具體分爲【常規需求】和【審覈需求】

【常規需求】：【常規需求】由研發人員直接對接，研發人員擁有需求否決權。

當研發人員接到需求超出常規需求要求，則將【常規需求】轉爲【審覈需求】，轉交給項目負責人，由項目負責人審覈後，從新分配任務。研發人員擁有需求升級權。

【審覈需求】有項目負責人進行審覈、或組織會議審覈，最後將其量化，從新分配。

流程圖以下：

4，產品交付與維護

產品交付後，軟件的生命週期正式結束，一般，維護工做會轉交給運維部門負責，研發人員轉投下一個項目。運維部門對交付後的需求進行整理，統一轉交研發負責人，由研發負責人調整工期，統一應對產品交付後的需求。

團隊管理

常規團隊中一般包含四個角色：架構師、項目經理、組長、組員。其中架構師、項目經理、組長爲管理者或協助管理者。現實中，因爲資源緊缺，一人身兼多角色的狀況也很常見。對這個四個角色進行管理，就是團隊管理了。

團隊管理是爲了提升團隊效率，所以不少公司會對團隊成員使用KPI(關鍵績效指標法)來進行績效考覈，KPI遵循二八原則，重點關注關鍵任務，對普通任務進行取樣計算，這樣就對一些不可量化的任務作出了很好的考量標準。

不過現實中，KPI最好的應用，一般是在中小型團隊，而在微型團隊和大型團隊中，常常會出現反效果。

對微小團隊管理起最大做用的一般是領導力，而不是績效。對大規模團隊管理起最大做用的，一般是流程。不過，如今主流公司也常常採起團隊切割的模式，將大團隊切換爲更靈活的多個小團隊，來提升效率。

團隊管理中，除了績效考覈外，還有一個重要部分是團隊建設。

團隊建設是爲了實現團隊最大化產出而進行的一系列結構設計及人員激勵等行爲。

合理的結構設計一般會讓團隊變的更加穩定。

好比當下流行的魚羣管理。

魚羣自己就是一個複雜的體系，是一個沒有核心管理的自組織，但規則簡單清晰。

魚羣的基礎規則。

1，與其餘魚保持距離。

2，跟上週圍魚的速度。

3，5%的魚受到獎勵，能激發整個魚羣的強烈反應。

即，管理者利用簡單清晰的規則，讓高度複雜的龐大魚羣得被管理。

----------------------------------------------------------

注：此文章爲原創，任何形式的轉載都請聯繫做者得到受權並註明出處！
若您以爲這篇文章還不錯，請點擊下方的【推薦】，很是感謝！

http://www.javashuo.com/article/p-vpibtaqx-nh.html