合理的进度安排--人月
目錄
1、首先，沒有一個很有效的估算方法。
2、我們采用的估算技術隱含的假設人和月都可以互換，錯誤的將進度與工作量相互混淆。
3、由于對自己的估算缺乏信心，軟件經理通常不會有耐心持續的估算這項工作。
4、對進度缺少跟蹤和監督。
5、當意識到進度的偏移時，下意識的反應是增加人力。
????
? 在眾多的項目軟件中，缺乏合理的進度安排是造成項目滯后的最主要原因，它比其他所有因素加起來的影響還要大。
1、首先，沒有一個很有效的估算方法。
????? 在項目安排的初期，項目管理人員大多數都會秉持一種樂觀的態度：一切都將運作良好，每一項任務僅花費它所“應該”花費的時間。但在很多時候這只是一個錯誤的假設，畢竟項目初期的安排是在信息比較缺乏的時候做出的，帶有嚴重的主觀主義色彩。導致項目計劃變更的因素有很多。在單個的任務中，“一切都將運轉正常”的假設具有可實現性，因為所遇到的延遲是一個概率分布曲線，“不會延遲”具有限定的概率，所以現實情況可能會像計劃安排的那樣順利。然而大型的編程工作，或多或少包含了很多任務，某些任務間還有前后的次序，從而一切正常的概率變得非常小，甚至接近于零。
?
2、我們采用的估算技術隱含的假設人和月都可以互換，錯誤的將進度與工作量相互混淆。
???? 第二種謬誤的思考方式是：用人月作為衡量一項工作的規模是一個危險和帶有欺騙性的神話。它暗示著人員數量很時間是可以互相替換的。 人員和時間的互換僅僅適用于以下情況：某個任務可以分解給參與人員，并且他們之間不需要相互的交流。比如CRUD等一些簡單重復的工作。
?? 絕大部分情況下，任務之間是需要協作的，所以我們需要考慮溝通成本。溝通所增加的負擔有兩部分組成：培訓和相互的交流。如果使用成熟的微服務技術，那么業務培訓相對于技術培訓會花費較多的時間，而從需求梳理到概念設計，再到系統設計，再到編碼，再到測試，這整個流程在溝通上花費的時間更多，并很快會消耗任務分解所節省下來的個人時間。這時項目管理人員會考慮添加更多的人手，但實際上有可能會延長了而不是縮短了時間進度。
? 對于測試人員而言， 由于系統的復雜程度不斷增加，以及我們的樂觀主義，每迭代一個大的版本（小版本更容易控制，所以提倡敏捷開發），通常實際出現的缺陷數量比預料的要多得多，因此，測試進度的安排常常是編程中最不合理的部分。
3、由于對自己的估算缺乏信心，軟件經理通常不會有耐心持續的估算這項工作。
????? 受限于客戶的需求緊迫程度，會不斷的調整任務的優先級（尤其是純外包類的項目，公司內部平臺類型項目相對變化較小），導致項目計劃不斷變更。
????? 這時有兩種解決方案。
?（1）開發并推行生產率圖表、缺陷率圖表、估算規則等，而整個組織最終會從這些數據的共享上獲益。
?（2）或者，在基于可靠的基礎的估算出現之前，項目經理需要挺直腰桿，堅持他們的估計，確信自己的經驗和直覺總比從期望派生出的結果要強的多。
但是無論怎樣項目經理都會疲于應對，需要極強的耐心和勇氣。
?
?
4、對進度缺少跟蹤和監督。
?
5、當意識到進度的偏移時，下意識的反應是增加人力。
? 項目進度嚴重落后的情況下，增加人手需要慎重。很多時候向進度落后的項目中增加人手，只會使進度更加落后。首先應該考慮的解決方法是
? （1）重新安排進度。在新的進度中分配充分的時間（通常加班是一個選項）以確保工作能仔細、徹底完成，從而無需重新確定時間進度表，這要求項目經理有非常豐富經驗的項目管理經驗。
??? (2）消減任務。根據優先級或者重要程度調整項目計劃，是一個簡單且可操作性非常強的選項。
?最后 ，如果項目進度嚴重落后是因為需求增加，任務模塊變多，那么就非常需要添加響應的人手。
?
?
?
?
總結
以上是生活随笔為你收集整理的合理的进度安排--人月的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 基于java+springboot+my
- 下一篇： 【演示工具】Focusky教程 | 添加