Max的敏捷想想(Thinking in Agile): 專案估算還是商業目標?

通常在討論專案時程時，經理和工程師想得有點不一樣：

場景一：

麥總(業務主管)：這一個專案你需要多久才能完成？我們需要在三個月內讓系統上線以便參加明年1月的CES。而且我們没有多餘的資源，所以你必須用目前的RD團隊來完成，這邊是要參展時我們系統需要有的功能清單。

小斯(Team Lead)：讓我回去跟團隊估算一下再跟你報告。

RD會議…

小斯：我們預估這個專案必須用到5個月的時間。

麥總：５個月！？你有聽到我說的話嗎？我之前跟你說的是我們需要這個系統在３個月內完成，這樣才能去CES參展！

在二人互動後，小斯心中可能在想：「麥總的要求真是不合理，怎麼要求我們Team用三個月的時間做5個月才能做完的事，說得比做得容易！」

而麥總心中則是在想：「這小斯完全不懂商業現實！他不能了解在系統在三個月準備好去參展是一件悠關公司生存的大事嗎？」

在這個例子中，我想麥總並不是真得要小斯去做專案的時程預估(estimate)；他其實是希望小斯擬定如何完成系統並準時參展的計畫(plan for a biz target)。

大部份的業務主管並没有足夠的技術背可以區分估算(estimates)、目標(targets)、承諾(commitments)跟計畫(plans)的差別。因此RD主管便有責任將業務主管需求轉譯成更特定的技術項目。

底下提供一個比較有效的互動方式

場景二：

麥總：這一個專案你需要多久才能完成？我們需要在三個月內讓系統上線以便參加明年1月的CES。而且我們没有多餘的資源，所以你必須用目前的RD團隊來完成，這邊是要參展時我們系統需要有的功能清單。

小斯：我想再跟您確認一下，是「所以需求都100%完成」還是「要有亮點可以參展比較重要」?

麥總：我們一定要去參展而且要有新的話題讓行銷部門可以做文章。當然如果可能，我也希望所列的需求能夠100%完成。

小斯：我們會依照您所定的優先順序全力以赴，但如果RD團隊估算之後沒有把握交付100%的需求功能，我們是否還是要將已完成的功能整合後交付，還是我們可以在CES在後再交付？

麥總：我們一定要有新功能新話題去參展，但若情況很緊急，即使不是100%完整，我們還是要將已完功能包裝好。

小斯：好的。我會擬出一個時程計畫讓RD Team在未來3個月儘可能地完成最多的功能。

—————
如果你是一個 Project Lead/Team Lead，下次當你被要求提出一個專案時程預估時，你可以注意以下幾件事