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