Managertoday 經理人

專案計畫愈詳細愈好?想當高效工作者,你應該學會放棄「這件事」

2020-06-01 16:39:06
Managertoday
https://bnextmedia.s3.hicloud.net.tw/image/album/2020-04/img-1586486587-77327@900.jpg
在市場瞬息萬變的當下,要當有效率的工作者,最好一開始就放棄「做出完美的計畫」,如果要等拿到計畫表才做得出東西,對公司或團隊而言,無疑是浪費時間。

所謂「敏捷式開發」就是不需寫規格表和事業計畫書,想當有效率的工作者,最好放棄一開始就做出「完美的規格表」(除了軟體工程師之外,企劃書或許也可算在此列)。如果要拿到規格表才能做出東西的話,在等待規格表完成前,工程師就無所事事。對整個計畫來說,這顯然是浪費時間。

推薦閱讀:傳統的專案管理方法不管用了!Google、Apple、FBI 都在用「Scrum」工作法

專案計畫書:重點在於內容的傳遞,視進度需求而調整

在市場瞬息萬變的現在,最重要的是,比其他公司更早判讀出商品流行的走勢,迅速採取下一步行動。計畫領導人最該優先重視的是,「讓商品愈早上市愈好」。晚一天、一星期或一個月,很可能都會成為計畫失敗的主要原因。

真要說的話,就算一開始開發產品就給出一份精美的規格表,充其量也只不過是一份關於產品的「假設」。往往必須等使用者實際接觸過產品後,才會陸續得到「不需要這種機能」、「看不懂怎麼操作」、「要是有某某機能就好了」的意見回饋。

這時,最重要的當然是,立刻將使用者意見回饋給公司內部或外包合作的工程師,請對方快速針對使用者意見做出改善、修正。然而,若是先前已給出一份精美的規格表,就非常可能引起負責人的不滿,表示「我可是按照規格表做的,可以不要動不動就改來改去嗎?」這種內部衝突其實也是無謂的時間浪費。

與其如此,倒不如從最初商品企畫會議的階段就請工程師一起參加,若是一開始不須確定所有細節,就要告訴工程師:「目前先按照這種感覺做做看」,一邊進行,一邊改善,這樣可能還會完成得比較快。

對工程師來說,只能單方面接受指示或許是很大的挑戰,但是有很多產品都是得先做出雛型才看得出問題。將這個過程視為做白工的人,就非常不適合在新創企業工作,其市場價值也只會愈來愈低。

規格表主要在於預防確定事項的遺漏,實際上需要的不是規格表,而是計畫內容的傳遞。 換句話說,只要最後商品開發到符合需要就夠了,開發過程中無論以口頭或是備忘錄的方式進行工作,大概都不會有太大的遺漏。

事業計畫書:方向指南,列出「最壞的狀況」預先做準備

與規格表作用類似的是「事業計畫書」。絕不可能有人可以準確預測 5 年後的商業環境,計畫書可以當做方向指南,但若將它看得過於重要,就會破壞組織的彈性。

經營事業的目的是「讓事業成功」,製作事業計畫書不過是朝目標前進時的工具罷了(不過,有些大型組織職務畫分較細,像是經營企畫部的工作目標,就是製作一份完美的事業計畫書)。當然,製作事業計畫書也有它的好處。但我重視的是,事業計畫書中是否確實預測了「最壞的狀況」

預測未來不是一件容易的事,擬定計畫時的前提條件(例如特定市場的成長率等等)其實很有限,用這些有限的前提條件互換組合,大概可以勾勒出 20 種左右的藍圖。

事業計畫的焦點要放在最壞狀況的藍圖上,擬定即使遇到各種狀況也不會使組織陷入危機的風險分散策略,預先做好準備,一旦真正遇到問題,才能迅速做出決策,這才是製作事業計畫書的目的所在。

(本文整理、摘錄自《10 分鐘完成每件工作》,天下文化出版)