專案管理
現代的專案管理通常是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
