項目管理
現代的項目管理通常是4個部分：需求、軟件設計、軟件開發、產品交付與維護。通常情況下，整個過程是中間重兩頭輕。
1，需求
每個項目都是要明確需求的，因為沒有明確的需求，就沒有項目結束的時間。
需求需要分享
需求需要管理
在項目中，需求經常是不斷變化的，或增加、或改動，而溝通需求的時間通常是不充分的。所以，需要對需求進行等級規划，等級高的優先處理，進而形成階段性開發，形成開發節點，即里程碑。這樣可以在不同的階段結束時，對需求進行再討論，使交付產品更接近客戶需求，同時規避需求頻繁改動帶來的風險。
2，軟件設計
軟件開發前，通常需要進行軟件的概要設計，通過概要設計來指定開發，從而可以提高開發效率。
軟件設計時通常會參考一些設計標准，比如ADMEMS設計方法。
ADMEMS矩陣如下圖，理論上是先上后下，先左后右。
除了設計架構理論外，還要思考三個W。
Who：為誰設計？What：要解決用戶的什么問題？Why：為什么要解決這些用戶問題？
通常在項目啟動前是沒有成功的設計模式的，成功的設計模式都是完成后，回頭總結的，即，實際開發過程中也都是靠摸着石頭過河的。不過有些經驗可以借鑒。
3，軟件開發
在資源充分的情況下，軟件開發是依托於概要設計拓展出來的詳細設計來指定代碼編寫的。不過，資源充分情況相對較少，所以，多數情況會取消詳細設計階段，直接代碼編寫。這樣，就需要良好的框架予以支撐。通常軟件開發進度隨着項目越大越完整，而變的越慢，良好的框架也不能解決這個問題，不過它可以延緩研發效率變慢的出現時間。
在具體的代碼編寫實施中，有很多規則可以參考，如ABSD（基於體系結構的軟件設計）、XP（極限編程）。通常來講，軟件開發方法就是指資源的合理調配。比如，項目功能分配，項目功能工時決策權分配，項目需求決策權分配等。
舉個敏捷開發的需求決策權分配方法，該方法的好處是研發人員即項目經理，可以減少人員投入。
具體實施如下：
需求具體分為【常規需求】和【審核需求】
【常規需求】：【常規需求】由研發人員直接對接，研發人員擁有需求否決權。
當研發人員接到需求超出常規需求要求，則將【常規需求】轉為【審核需求】，轉交給項目負責人，由項目負責人審核后，重新分配任務。研發人員擁有需求升級權。
【審核需求】有項目負責人進行審核、或組織會議審核，最后將其量化，重新分配。
流程圖如下：
4，產品交付與維護
產品交付后，軟件的生命周期正式結束，通常，維護工作會轉交給運維部門負責，研發人員轉投下一個項目。運維部門對交付后的需求進行整理，統一轉交研發負責人，由研發負責人調整工期，統一應對產品交付后的需求。
團隊管理
常規團隊中通常包含四個角色：架構師、項目經理、組長、組員。其中架構師、項目經理、組長為管理者或協助管理者。現實中，由於資源緊缺，一人身兼多角色的情況也很常見。對這個四個角色進行管理，就是團隊管理了。
團隊管理是為了提高團隊效率，因此很多公司會對團隊成員使用KPI(關鍵績效指標法)來進行績效考核，KPI遵循二八原則，重點關注關鍵任務，對普通任務進行取樣計算，這樣就對一些不可量化的任務做出了很好的考量標准。
不過現實中，KPI最好的應用，通常是在中小型團隊，而在微型團隊和大型團隊中，經常會出現反效果。
對微小團隊管理起最大作用的通常是領導力，而不是績效。對大規模團隊管理起最大作用的，通常是流程。不過，現在主流公司也經常采取團隊切割的模式，將大團隊切換為更靈活的多個小團隊，來提高效率。
團隊管理中，除了績效考核外，還有一個重要部分是團隊建設。
團隊建設是為了實現團隊最大化產出而進行的一系列結構設計及人員激勵等行為。
合理的結構設計通常會讓團隊變的更加穩定。
比如當下流行的魚群管理。
魚群本身就是一個復雜的體系，是一個沒有核心管理的自組織，但規則簡單清晰。
魚群的基礎規則。
1，與其他魚保持距離。
2，跟上周圍魚的速度。
3，5%的魚受到獎勵，能激發整個魚群的強烈反應。
即，管理者利用簡單清晰的規則，讓高度復雜的龐大魚群得被管理。
----------------------------------------------------------
注：此文章為原創，任何形式的轉載都請聯系作者獲得授權並注明出處！
若您覺得這篇文章還不錯，請點擊下方的【推薦】，非常感謝！
https://www.cnblogs.com/kiba/p/13596436.html
