最近的項目由于是新客戶的原因,客戶對我們團隊是沒有太多信心的。在接到項目的初期,客戶只表示,他們其中一個關鍵的OKR是9月底要完成XXX,能將該功能交給用戶使用,占領市場先機。
那客戶側對接的PO在我們開始進入交付之后,就開始一再詢問交付進度預測。他們需要看到目前團隊能到什么時候完成既定的功能需求。其實作為長期服務海外客戶的我來說,我又一次看到了海外客戶的人性化和講道理,哈哈哈哈。如果換做國內客戶,估計不會問你要預測,而是你作為一個乙方公司必須在他們需要的業務時間點上做完。通常這種情況,除了加人,就只剩加班。
為了完成這個預測,需要把目前計劃在上線范圍內的特性或者說故事卡整理出來,并且每個故事卡都有相應的估點,即團隊基于目前的技術棧和特性復雜度給出了相應的評估。那么你會得到一個總的點數,例如第一次上線的內容,55個點。
根據這個點數,我們需要考慮一下點來做大概的上線時間點:
- 團隊的請假概率,反面會得到團隊的可用時間
- 團隊里面TL寫代碼的時間分配,例如每天TL有很多技術的會議需要參加,也許只能花他個人時間的50%用來寫代碼。對于比較大的團隊,TL有可能完全沒精力寫代碼,時間都花在和比較Junior的dev進行結對,做分享,參與產品架構,方案討論等等。
- 團隊在初期估計的點數,隨著后期對業務和技術棧的進一步了解,會有一定數量的膨脹,不能指望團隊在初期就能考慮到實現層面的方方面面,做到全面估計。所以我們通常會根據最初的估算乘以20%左右的緩沖。這樣得到一個更合理的工作量。
- 團隊的人員數量,這個主要指團隊中直接貢獻進度的Dev數量。
- 根據團隊對新項目的了解和熟悉程度,會有一個漸進提升速率的過程,我目前所在的組織,會認為,第一個迭代團隊能拿出25%的時間進行實現,第二個迭代能到50%,第三個迭代75%,第四個迭代能全面開掛。作為任何一支新團隊,比較理想的是技術棧都非常熟練,不用花額外的時間學習,業務也是100%理解清楚,不用額外時間溝通。但現實經常是,團隊技術棧不熟練,業務也在持續熟悉中。因此這個百分比也是合理的。
有了以上的因素和變量,基本能得出團隊各個迭代的累積消耗量,便能得到累積的burnup 圖,也就得到了你的上線日期。
image.png