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

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

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

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

想要翻筋斗前，先注意籠子的大小。

---某位資深的美術如是說

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

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

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

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

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

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