2012年2月23日 星期四

避免「削足適履」的企劃設計

過去在學習做系統設計時,前輩曾告訴我:「先把規格盡量開出來,然後跟程式確認過後,再依實際情形做刪減。」

當初在學習的時候,我覺得這個方式是沒有錯的,但隨著開發過程中逐漸浮現的問題,以及系統完成後所產生的效果,讓我逐漸對此方式產生懷疑。

這個方式乍看之下是相當正常的企劃流程,那是哪裡出了問題?

想要翻筋斗前,先注意籠子的大小。
---某位資深的美術如是說

先設計好一個幾近完善(甚至膨脹到醜惡)的系統,然後再因為技術水準、引擎框架、人力配置,或者製作時程的限制而逐步修改、刪減功能,就像是為了讓腳穿上不合適的鞋子,結果硬把自己腳上的肉削掉一樣。

只按照單方面的想法撰寫,程式告知執行製作上會有問題(通常來說,程式也不會花那麼多時間去告訴規劃者為什麼不行),然後再重複前一步驟。這樣來來回回,要消耗多少溝通的時間?

在系統開發之前,先瞭解使用的引擎和框架限制所在,再針對規格與可以突破的部份來做設計,是不是比較好些?更進一步地,一開始就先與程式人員溝通概念,瞭解對方的想法,共同規劃出一個理想的執行製作方式,是不是彼此更能有同樣的理念和方向?

開發是團隊工作,不是企劃某方面的單純下令背後遙控,就要程式畫押替這些大餅背書,出了事情就說是程式技術力不足。這只會加深雙方的裂痕,更加速團隊的崩潰。

身為企劃人,可能沒辦法對程式技術有全盤瞭解,但是最基本的,千萬不要以為程式製作很簡單,說什麼「我覺得這不會很難,他們一定會寫」的鬼話。要成為一名優秀的企劃,必須具有全方位思考的意識,不要認為企劃高高在上,程式跟美術,都只是用來展現企劃天才的執行者。

想要不做出削足適履、綁手綁腳的跛腳企劃案,第一件事,起身去跟技術人員溝通,看看他們在做什麼,聽聽他們的想法。

沒有留言:

張貼留言