本文章感謝 Oursky 提供本 PM Blog 專欄共同公佈。
原文: How project managers and developers can both (happily!) give realistic ship dates
作者：Ben Cheng, Oursky 創辦人
翻譯者：Queenie So
圖片來源: Fog Cree
如果專案經理只站在客戶的角度思考，有時難免會陷入迷思。為了幫客戶降低成本，努力追趕 deadline，務求在最短的時程裡交付產品。其實客人真正追求的，首先是最好的產品，然後才是盡早的交付日期。
精心編寫的程式碼是創造高品質產品的基礎。軟體開發者應該按照約耳測試 ( Joel Test ) 裡提到邁向高品質軟體開發的12道法則來做好版本管理、鼓勵每日編譯 ( daily builds ) 或善用品管測試 ( QA )。
) 兩個月後，我想與大家分享一些心得。
沒有強迫症也可以進行 EBS
我們使用 Fog Creek 的 EBS 去追蹤和比對開發工程師預期和實際花在專案上的時間。這些數據幫助我們編制更切合的專案時程，並且提供一個反饋循環，促進 PM 和工程師改進他們為個別任務制訂的需時預測。
但重點並不在這些近乎強迫症的計時上 — 我們信任我們的工程師和 PM，當然也包括他們在專案檢查表上自主填寫的時間。
提到的要點外，我們在實際應用上也有一些體驗。
確保 Issues 都能在兩天以內解決
我們的 EBS Google 試算表範本
如前所述，我們透過 EBS 追蹤預估和實際耗費在撰寫 user stories 和開發各個功能的時間。個別的功能都被切分為理應在兩天以內可以被完成的 GitHub Issues。
開發工程師仍然需要創建許多足夠小的任務，再梳理和整合每項功能的架構。比如說，與其很概括地表示「建立購物車功能」，我們可以把它切割成很多細項，譬如「以列表形式清楚地展示購物車內的產品」。
這個追蹤過程同時讓我們的客戶獲益，因為他們能清楚掌握我們在每兩週一次的 sprint 裡正專注在什麼項目。如果某些功能超前或落後進度了，他們都能及時收到通知而避免意料之外的「驚喜」。
我們同樣會追蹤我們 PM 的預計時程，因為他們不只擔任客戶經理的角色。他們某種程度上必須具備技術層面的基礎和理解，並從錯誤學習，將來才能做出更準確的判斷，優化他們的時程規劃。這對 PM 來說是很重要的一環。
當他們發現和工程師針對開發相同功能預計的所需時間存在巨大誤差時，他們可以提問並從中學習什麼環節比較耗時，技術債會如何影響一個專案的進行，還有所有事情如何安排才會進展得比較順利。
我們的 PM 努力尋找商業獲利點：他們提供足夠時間予工程師去好好建構和編寫程式碼，同時給客戶建議一個合理的時間框架（還有成本）。
追蹤實耗時間
圖片來源: Toggl
我們的公司奉行彈性上班時間，很多同事可能會忙裡偷閒去喝杯咖啡或聊天放鬆一下。 EBS 會把這些休息時間都算進該功能的總開發時數裡。有些工程師可能會頻繁休息但在短時間裡一氣呵成快速衝刺，而其他人則可能選擇持續而穩定地埋頭工作。
說到底，假如預計的時間與實際花費的時間是一樣的話，這兩種工作模式底下的工程師都是預算準確的。你可以利用 Toggl 應用程式來檢查自己的預估時程，只需在開發某一個特定功能時打開計時器直至開發完成為止（包含休息，不管那些休息時間有多長或有多頻繁）。
不過，其實你不一定需要這樣精細的追蹤檢查。
因為有很多任務要被完成至少也得固定花幾個小時，工程師可以在每天完結前快速紀綠當天完成的 issues。像「 0.25天 」這樣的概估就已經足夠了，也就是說為什麼我們不是非要用到計時工具不可。
我們使用「 velocity 」（速度）作為測量預計花費和實際花費時間的量度單位。如果預測時間和追蹤到的耗時是一樣的話，我們判定為「 1 ｣。如果工程師在兩天內完成一個任務，但當初預期需要 2.5 天的話，速度就是 1.25，意味著他們低估了自己的速度。
一致性代表團隊成員能根據以往的表現預測各自的 deadline，而準確度則是把 velocity 盡可能持續地控制到貼近 1 的範圍（或最低限度的誤差）。
將工程師的預算時程慎重納入專案時程的考慮因素之中
我們的 EBS Google 試算表範本
客人委託專案的時候，我們的 PM 會分析所需功能並推算各項功能的開發時間。把所有的功能組合加總，再加上審閱編碼和品質管理的時間，我們就能向客戶提供一個標準的專案時程。
EBS 幫助我們審視個別工程師如何影響整體專案的進行。在我們開始追蹤時效後，我們發現一些有趣的現象。例如有些工程師可能持續地高估他們的速度，所以永遠落後於預計進度。但是，他們可能最終仍然以快於平均值的速度完成開發，而且還能配合整個專案的進度。
因為這些行為是可以預測的，我們的 PM 現在學會了如何在提供預計時程給客人參考時做出適當的調整。相反地，假如我們某位工程師長期超前完成任務提早交付，我們的 PM 也能有把握判斷可能可以向客人建議一個更緊湊的時間表。
比起經驗，實證數據甚至更為可靠。
有關 EBS 的觀察與省思
我們的目標，是讓工程師與 PM 在面對一些無法完全掌握藍圖的情況時，有足夠的緩衝時間去完成任務；同時利用現有的預計時程，去判斷一些常見基本工作所需的時間（譬如登入頁面）。
我們另外發現，即使工程師富有開發經驗，也不代表能加速完成開發一些常見功能。因為不管開發者有沒有經驗，某些功能的開發本來就需要花費固定的時間。我們不應該為了節省成本，就以優化為名，試圖追趕或縮短預計的時程。
以試算表進行 EBS 和任務追蹤也幫助了我們快速判別出哪一種特定功能將重覆導致延誤。
實證的數據有助我們追蹤行為模式和其引致的現象，讓我們更深入認識自己的工作方式。但是，這也不代表我們就能完全依靠數據，因為每一個專案都是一個全新的計劃，都有變化的可能。
Joel已展示過應該如何在專案管理上應用蒙地卡羅模擬法（ Monte Carlo simulation )，模擬 100 種可能發生的情景、每個場景搭配 1% 的機率進行演算。根據隨機抽取有關工程師工作速度的歷史數據，可以完整地展現一個專案中所有可能發生的面貌。演算的目的在於縮小產品交付日期的變化範圍，而不是期望能指定某一個日子交付，或假設每一次都能達到 100% 準確度。
EBS 已證實了軟體開發也是機率的一種。( Software development is a probability. )
最後的反思
Photo by Felix Plakolb via Unsplash
基於現實考量，我們仍然為客人的專案提供一個預計的 deadline。我們同時邀請客人參與 Basecamp 計劃，讓他們清楚了解我們每週的工作進度。
當一家公司或一個工程師（包括你的同事！）提供一個專案預測時程給你時，嘗試不要只專注在總天數上。不論專案長短，請向對方要求各項功能分配的時程，還有他們過往完成專案的時程紀錄。先了解對方的團隊如何制訂預計時程，再把那些背後的因素納入你編制長期預算的考慮範圍內。
你喜歡這篇文章嗎？請按讚或分享給更多朋友看到。謝謝！
