熱狗攤與專案管理

上圖為加拿大熱狗名店Japadog的hot & spicy,我是覺得不怎麼辣,倒是薯條鹹到我快中風;整家店就看我一個人拿著張餐巾在那邊邊帶著複雜的表情邊對薯條不知道磨蹭些什麼,想來畫面應該挺微妙的 …

好啦,言歸正傳,這篇的重點不是熱狗,我們來想想一個問題:

『如果要經營一個超棒的熱狗攤,最重要的要素是什麼?』

這個問題並非我原創,是我在Rapid Development一書中讀到的,作者Steve McConnell試圖用貼近生活的問題來帶領讀者思考專案開發中最核心的問題。

那答案是什麼呢?

鏘鏘~答案是:超棒的熱狗。

很顯而易見不是嗎?如果經營一間熱狗攤,熱狗本身乏善可陳,不管你如何行銷、店面如何地酷炫,大家不想一再回來吃,終究是棒不起來的。

通常我說到這裡,大家都能夠同意,或許是因為吃這件事與生活息息相關吧?但今天如果換成這個問題如何呢:

『如果要開發一個超棒的X專案,最重要的要素是什麼?』

這時答案就會變得五花八門了,我甚至不需要知道X是什麼就能預期下列答案會出現:

  • 社群
  • 大數據
  • 運用deep learning技術學習使用者習慣
  • 提供web、mobile、desktop整合式使用者體驗
  • business model
  • 廣告投放

如果有軟硬整合,別忘了IoT喔!再來個內建商城怎麼樣呢,賣賣貼紙大家都最喜歡了不是嗎?或許是因為軟體比起熱狗實在是複雜太多、又變遷得太快速了,現實的軟體專案開發就是一件這麼容易失焦的事情,個人相當敬佩Steve McConnell言簡意賅的比喻。

身為PM,知道你專案的『熱狗』是什麼是最基礎也是最重要的事。換句話說,如果不知道,不管用的是多先進的管理工具、管理方法,最終都是災難一場。

去蕪存菁找熱狗

那麼該怎麼找到自己的熱狗在哪?我個人覺得遊戲業有許多經驗值得借鏡。遊戲業的加班爆肝、時程拖延情形不但惡名昭彰,還舉世皆然。究其原因,通常就是要素過多、功能發散。因此GDC每當有製作人分享,講的多半是如何避免發散,幫助團隊集中火力,這跟Steve McConnell強調的重點不謀而合。

舉個例,Rod Fergusson是Gears of War系列製作人,他在GDC 2009的Producer bootcamp有一個很棒的講題:『He who ships, wins』 當時我有幸在現場聽,對我日後規劃專案的影響很深。有興趣的人可以在GDC Vault上看Flash影片,或是下載投影片來讀。

在這個講題中,Rod Fergusson提到製作遊戲令人興奮的點子簡直多如繁星,但實務上打磨一個要素很花時間,而且最後整體調整至平衡的花費更是無法估算。因此,製作人最重要工作,就是要從中找出真正支撐起整個作品的『支柱』( pillar ),與之不相關者都應早期剔除;他將之稱為『Pillars method』。投影片中有以Gears of War 2在初期規劃出的"Pillars"舉例,建議可以下載來看一看,如果有實際玩過必定會很有感覺。

過去還有Game Developer Magazine的時候,還曾經有一篇『Design by reduction』也很棒,可惜雜誌停刊後,似乎也找不到這篇文章了。該文搜集了一些經典案例,描述它們如何透過刪減『未直接支持核心』的要素,最終達到遊戲本身更臻完備、開發時程縮短的雙贏。例如ICO本來打算配許多音樂,但後來檢討認為並未真正強化遊戲體驗,反而有種『因為RPG都有所以我們也要有』的感覺,所以就大刀一砍。Team Fortress 2剛上市時只有一張地圖,因為Valve團隊希望提供玩家豐富的選擇與深度策略的體驗,所以乾脆專心先把一張地圖做到最好。

這邊請容我再盜Rod Fergusson的一句話:Prune early,keep pruning。持續不斷的去蕪存菁,或許是最好的方式。

歸納為三

『三』對我來說是個有魔力的數字。三點可以定出唯一平面,因著這幾何上單純的事實,我們的3D computer graphics得以選用三角形作為基本元素,從而解決浮點數誤差可能導致的破面情形 — 因為就算有誤差,也沒辦法改變幾何。這種感覺我覺得很棒,1太少,2容易偏,3感覺就張開了個較全面的平面了。因此在專案規劃的初期,我會要求自己要歸納出這個專案的三項核心要素。這剛好跟熱狗堡很像吧?熱狗腸、熱狗包,再加上把一切結合在一起的醬汁,好吃,太好吃了 …

我剛加入a8c的時候,第一個專案是一個供Happiness engineers們共同規劃上線支援的種類與時程的web app,code name為Delorean (對,就是回到未來的那台車)。在我加入前,這其實是一個hackday的產品,後來卻出乎意料地被HE用做最佳化人力配置的工具。但隨著人愈來愈多、支援的產品、方式愈來愈多,便到了要打掉重練的階段。在來回討論後,我在專案規格草稿中寫下:

Delorean – The Hotdog:

  • 視覺化日/週/月HE配置務求一目瞭然
  • 優化時程編輯UX
  • 泛用化:全公司的人與產品均能使用

我一開始交出去忘了把The Hotdog拿掉,還讓大夥疑惑了一下 XD

在大家都同意後,我就經常拿著這三點去砍feature;很感謝我的leader Daryl很尊重我的想法,該砍就砍。雖然沒有如期完成,但在開發能量不發散的情況下,最終核心的部分品質相當優良,這個工具現在也持續在使用。

總結

嗯…講這麼多,大概就跟琦玉老師罵的一樣吧 …

螢幕快照 2017-06-11 下午10.26.45

成大蘇文鈺教授曾說,如果你無法用簡單的言語解釋,那代表你的理解根本不夠。專案開發也不例外吧?如果無法精要描述需求,那代表你並不清楚這專案到底要往哪裡去—— 這對團隊來說可不是好消息,個人認為,最消磨團隊的莫過於來來回回虛耗了。

如果在看這篇文章的你手上有在進行的專案,不妨試著寫下吧!你的熱狗是什麼樣呢?

發表留言

Please log in using one of these methods to post your comment:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.