接續前一篇：專案開發的風險與應對 - 上
開案中階段
風險三
成員能執行工作的時間，遠比想像的少
可能造成的原因：
- 一般成員只有70%的時間可以執行工作
- 主管則只剩下30%
- 層級越高的主管，能執行工作的時間越少
- 時間的耗損：熟悉新工作、指導成員、討論、會議、行政、雜事、事病假
- 等待造成的閒置
建議解法：
- 主管需要學會放手，專心於制定方向與策略，以及把所有成員凝聚到同一個方向，讓手下的人去做執行工作。
新手主管常見的問題之一，會因為不習慣脫離第一線，或是覺得下面的人達不到自己的水準，而想要自己來執行。
別傻了，你沒有這個時間，而且這不是你的工作。
- 外科手術理論：讓最重要的人處理最重要的事情，其他事情要有別人接手。
一台手術，需要高效且精密的團隊配合，但是主治醫師醫師只負責下指示與操刀。
舉凡從術前準備、手術過程中燈光、麻醉、儀器監控，甚至連工具的傳遞與擦汗，都有專人處理。術後的病人恢復、廢棄物清理、病歷撰寫也都有他人負責。
主治醫師開完刀就走了，他可以把他的時間投入下一台手術，或是精進他的開刀技術。
如果上述所有開刀之外的其他工作，都要由主治醫師負責，那他可以處理的手術台數必定會減少，開刀的品質也會下降。
- 建議整個專案有專門處理雜事的人 (ex.助理製作人、助理企劃、行政助理)
小專案有難度，可能必須有人兼任，或是數個小專案共用一個助理。
但是談定某個成員的工作要包含處理雜事是必要的，雜事總是需要被處理的，
讓專案中相對較菜、產出重要度相對較低的人去處理雜事、跑流程，遠好過讓手上有重要開發工作的人去處理。
- 設法提昇會議效率
開會前相關人員應先做好功課，不要臨場才開始消化資料；
訂好會議題目與議事流程，會中主持人要注意討論不要偏離主題，若發生其他議題盡可能日後另會討論；
會後要有會議記錄，至少要記錄結論、to do事項、負責人員與應該要完成的時間；
盡可能準時開開始、準直結束，否則都不算是有效率的會議。
所有討論設計相關的會議，應該要在會前就準備好(數個)方案，會中僅依據現有方案來討論，若現有方案都不可行，應該讓負責人員回去準備新的方案後再來討論。
簡單來說，除了極少數本來目的就是brainstorm的會議外，應該要嚴禁到開會時大家再從0開始進行發想與討論。
如何有效率地開會是門藝術，除了上述提到的建議外，還有很多方法，建議大家可以參考坊間的專門書籍，並找出適合你們團隊的方案。
喔，對了，會議中主管要勇於作決定，追求絕對的民主和多數決會是個很糟糕的決策方式，也會大幅降低會議的效率。
- 預估時程時，單一任務的完成時間，通常是組員提出的1.5~2倍。
組員的經驗越淺，估出來的時間需要乘以的倍數越高。
- 訓練新人的成本，通常遠高於一般的預期。
除了新人本身的學習曲線外，還有因為對於專案的認知不足而造成的額外的溝通成本，以及主管花在指導的新人時間成本。
- 優化工作流程與任務分配，減少因為等待而造成的閒置。
情況有很多種，比如說開發過於偏向瀑布化；流程被拆得過碎，工作往返過多；製作單項功能/素材的人員很多，但整合人員過少....等。
針對不同情況，有不同的處理方式，這要看個案處理。
- 工作都要能互相代理/執行，避免出現「不可或缺的存在」。
如果有人是不可以被取代的，那該成員生病、請假或是離職的時候，專案就要開天窗了。
因此平常安排工作的時候，就應該盡量讓工作是處於可以相互代理/執行的狀況。
風險四
總有沒估到的工作陸續跑出來
可能造成的原因：
- 人不完美，因此人所編列的計畫也不會完美。
- 製作人不會知道每個工作執行的步驟與細節。
- 嘗試性的工作，結果沒出來前，較難預估後續情況。
- 技術障礙比原本預想的高。
- 工具或規格的缺漏。
- 來自主管或客戶的臨時需求。
- 製作人或企劃的暴走。
建議解法：
- 縮短迭代時間，增加迭迨頻率。
現在鮮少遊戲開發，可以採用完全的瀑布開發，大多都不同程度地混和了迭代開發或敏捷開發的概念。
以我自己的經驗，一個迭代的時間最好在4週左右，要看專案的規模。不過太短會很難做事，太長則缺乏應變的彈性。
但要確保每個迭代週期內，不要安排了過多的項目進行開發，不然這樣的短時間開發也只會造成milestone的爆炸。
- 每次迭代，都要重新處理任務的重要度，優先處理重要度高的工作。
因為開發過程中，總會產生插件或漏估的工作，導致於下個迭代開始時，總體工作項目會有變化。
加上市場與客戶需求也可能隨時間產生變化，因此每次迭代開始前，都需要重新安排任務的優先度，然後專心處理最重要的工作。
最重要的工作如果都做不完了，我們怎麼會有時間去做次重要的工作？
- 重要/緊急 > 重要/不緊急 > 不重要/緊急 > 不重要/不緊急
這是處理任務的優先順序判斷方法之一，把所有的任務都丟到重要與緊急的二維象限分類上，然後按這個順序處理。
我相信大家都會認同最前面和最後面任務的處理順序，但中間的部份會比較有爭議，我是傾向於重要 > 緊急。
因為隨著時間的流逝，不緊急的任務都會變成緊急，但是不重要的任務不會變成重要。
我們應該要優先處理重要的事情。
- 建立目標時，採用up > bottom；開立工作細項時，採用bottom > up
由最上面的人訂立目標，由第一線的人建立工作細節。
這兩個過程都應當有頻繁且密切的溝通。
- 適當的刪除/延後執行次要工作
還是那個老問題，之所以是次要工作，就表示他不影響產品的生死。
如果最重要的工作都已經做不完了，我們還去處理次要工作不是找死嗎？
- 如果是短時間的問題，盡量不要用加人處理
幾乎沒有多少人是真的可以隨插即用的，新的成員通常需要時間來熟悉專案，需要leader花時間來指導，並要重新溝通，凝聚對專案的共適。
這些通常都需要時間，因此對於專案短時間內的delay是沒有幫助的，而且通常加的新成員越多，專案會越混亂。
因此除非是長時間的需求，比如預期半年一年都會有需要，否則不建議用加人處理。
- 不是會致命的插件工作，就盡量放入下個迭代處理，要忍住....
這真的很難，有時是出於自主的慾望，有時是出於外部的壓力。
但其實，如果你正在處理致命(緊急且重要)的問題，那放下它去處理新的插件，通常也只是找死...
不過，插件的暫緩處理，需要耐性，也需要積極的溝通，不然很容易被上級誤會。
- 滿足客戶需求很重要，但照單全收通常都是悲劇
其實我們大部分的工作成果，都是為了滿足客戶需求，只是這個客戶是玩家、營運商還是上級主管而已。
無法滿足客戶需求的專案一點意義都沒有，但客戶真正的需求，通常不是這麼明確，甚至有時候客戶所表達出來的言詞，和他真正的需求完全是兩回事，也因此常常有人說，客戶其實不知道他們自己要什麼。
所以，我們應該要去瞭解與探索客戶真正的需求為何，而不要完全照著客戶說的話做，不然你很容易發現，客戶每次講的話都不太一樣，並且往往前後提出來的需求還會相互衝突，然後，你跟需求跟到半死，產品卻變成了你不認識的四不像。
但是，發掘客戶需求以及客戶溝通，真的是門藝術，尤其是當你面對強勢客戶的時候，通常是沒有多少轉圜空間的....(淚)
電影「狗狗心事」裡的這個小故事，就是對客戶需求照單全收後，悲劇的最佳寫照：
http://www.youtube.com/watch?v=XKnYv4OEXqE
風險五
做完不等於做好
可能造成的原因：
- 所有任務在完成後，還要經過優化的過程，才能達到預期的效果，才算是做好。
- 一般情況下，優化包含了整合、測試與調整等工作。
- 通常組員預估任務，都只估到單一功能完成的時間，沒有包含優化所需的時間。
- 成員能力的高低，影響第一次做完到做好之間的距離。 (包含執行能力、經驗與sense)
- 工具不夠友善的話，在優化上會花費比預期長的時間。
- 優化是必要的，但若因為展示或驗收的需求，導致於過早或過於頻繁地優化，容易造成開發負擔。
建議解法：
- 教育成員「整合、測試與調整」等工作的必要性，並拆開來列入計畫中。
把所有的工作列出來，可能會覺得很瑣碎，但這些都是必要執行的工作，也都會花費相當的時間。因此不列出來，並不代表這些工作不存在，只是會變成隱藏性的成本，然後在開發過程中慢慢跑出來，造成milestone執行上的delay而已。
如果真的覺得任務太瑣碎會很難維護，那每個任務至少要列出「製作」和「優化」兩個工作，並且記得要把優化的時間放長。
- 一般來說，健康的軟體開發，需要1/4的規劃期，1/4的製作期，1/2的優化期。
這個很理想，真的，大部分的專案都不會有這麼長的優化期，但事實上遊戲開發真的需要這些時間。如果一個遊戲的開發並沒有留足夠的優化時間，這個時間成本也只會以別種形式反映出來而已。
比如說前作成績不好，但是記取前作經驗的續作或換皮案成功了。
或是網路遊戲剛上線時成績慘澹，經歷一年，用了兩三個重大更新來調整後，賣相比當初好很多，重新包裝後在新市場取得成功。
- 減少開發內容，增加優化時間，內容可以等核心確定之後再陸續增加。
因為上述開發時程的理念的關係，加上我們通常不會有那麼多資源可以運用，因此最合理的方式，就是減少開發內容，來增加優化的時間。
如果有一年的開發時間，大部分的專案大概會是2個月的規劃期、8個月的製作期、2個月的優化時間，所以大部分的專案都做的很痛苦，然後一上市就死掉了(淚)。
如果按照上述的概念，應該要是3個月的規劃期(含Prototype)，3個月的製作期(量產)，以及6個月的優化時間。
3個月的量產期是很有限的，美術素材還可以用外包處理，但是功能開發勢必是有限的，因此減少開發內容，優先磨亮核心，是唯一可能達成的途徑。
- 提前優化時應注意規模與頻率的比例原則。
有些專案有定期展示或驗收的需求，此時，就意味著在前期的milestone，就要進行部分優化的工作，以確保功能與版本的穩定性。這類的提前優化工作，是必要的，但應該要控制其規模與頻率。
因為專案還在持續開發中，日後還會有新增的功能與素材會產生交互影響，這次優化的內容，有可能到了下個版本的時候，還要再來一次。
因此若再前期優化時要求除惡務盡，那成本會很高，也會造成許多重複的白工，建議以排除A bug為主，B bug個案判斷，C以下不修。
再來就是頻率的問題，因為之前也有說，應該要盡可能的縮短迭代的時間，在短時間開發的前提下，建議以每2次迭代為一個優化週期，再短很難做什麼新東西。
- 優化開發與測試工具，越是大型的專案越需要。
工欲善其事，必先利其器。遊戲開發70%以上的成本都是人力與時間，一個好用的工具不但可以節省開發的時間，大幅降低成本，並且可以讓使用的成員在開發的過程中較容易保持好心情(笑)。
但是優化工具本身也需要成本，要優化到什麼程度，應該要符合比例原則。
舉例來說，一個工具的優化要花20人天，聽起來很多；優化後每次執行該任務可以節省30秒，聽起來很少。但專案有40人需要用它，每個人每天需要使用4-5次，並且往後8個月都還會用到，這樣算一算，這個工具其實就很有優化的價值。
相反的，一個工具的優化只需要花3人天，聽起來很少；優化後每次執行該任務可以節省2小時，聽起來很多。但專案只有2個人需要用它，並且在使用2-3此以後，任務就結束了，往後也不會再需要用到它了。這樣的工具其實就不用去優化它了。
- 尋找天賦，把適當的人放到適當的位置上。
當你發現一個工作產出老是有問題，盯了半天也不見改善，如果不是成員專心與努力的問題的話，那就應該要考慮換人執行了。
每個人都有屬於自己的天賦，你讓一個對UI沒感覺的人，硬是要他去弄出一套兼顧視覺設計與使用者體驗的UI，只是因為他有空？還是因為他畢業的科系聽起來和UI有點關係？這是不是太緣木求魚了？
文章標籤
全站熱搜
