規劃師也必須要會編寫代碼

做現實可行的規劃

有了一個終究產品將怎么完成的明確形象，規劃師將拿出更多實踐可行的概念。作為開發進程中不可或缺的一份子，規劃師肩負著確保他們的規劃可以順暢轉移到網絡介質上，一起還要考慮其可用性，網頁易讀性和可完成性。一個對用戶友愛的網站不僅有簡練明晰的閱讀次序邏輯，還向用戶提供一切所需的信息而不會顯得咄咄逼人或是雜亂無章。想要知道一種 Web 布局是否可行的唯一途徑便是親身去了解怎么樹立一個網頁。

使溝通更輕松

在簡直所有的規劃與完成各自獨立的產品中，規劃組和完成組從沒有滿足過對方的期望，尤其是那些無形的產品，比如網站，軟件和游戲。這一般歸結于產品的期望和產品可行性的彼此退讓，目前看來，這是難以完美一致的。解決之道是：規劃師應該親身測驗規劃作品的完成，以防止溝通中的混淆，誤解和誤傳。

便利的迭代開發進程

一個實踐中的規劃不應是絕對的。我的意思是，規劃應該是靈活友愛的，可以在修改以投合體系技能約束的一起不歪曲其原有內在。這些重復但必要的改動只能由原規劃師來完成。一個規劃師/開發者可以比開發人員把規劃重提到規劃師手里進行改動愈加高效。而且規劃師和開發者之間——事實上常常如此——會產生沖突。

更好更調和的成果

我常常喜歡把軟件，網絡或是游戲開發想成是管弦樂，而規劃師是作曲家，開發者是樂團的指揮家?；孟胍幌露�者是同一個人將會怎樣？交響曲將會是令人驚嘆的，迷人的，純正的！不僅是大師的神作，而且仍是其本人親身指揮的！

縮短開發時刻

規劃師一起充當程序員的人物意味著規劃和編碼的進度即便不是一起的也是接連的。成果便是開發周期的縮短——誰會不關心功率呢？

規劃師愈加市場化

現代的規劃師需求提高本身的能力以保持個人價值，有一套技能是遠遠不夠的，我們往往需求戴著不同的頭銜：規劃師，前端開發者，文章作者和項目經理。

通過學習完成你自己的規劃，而不是讓規劃成為開發者手中的孤兒——你提高了本身價值。究竟，在簡歷中提到規劃和編碼技能不會有害處。相反，在這個金融危機年代的企業重組（拜見：大規劃裁人）和減縮開支的環境下，還可以著重一個人的重要性而免遭辭退。

然而，即便有這么多的理由支撐規劃師學習編寫代碼，這里仍是有反對的聲音。

引用 Lukas Mathis 的一篇有爭議性的文章“規劃師不是程序員”（注1）

假如規劃師完成自己的規劃，他會受制于兩個不同的方針：代碼的整潔和杰出的用戶體會。這兩個方針是彼此矛盾的。假如你要完成你自己的規劃，你必定會為了代碼的質量而退讓，這是不利于交互規劃的。

完成自己規劃的規劃師面臨著兩個問題：他們知道一個很棒的新思路會樹立紊亂的代碼，他們也知道假如改進用戶體會，現有的代碼會被打亂。這兩者彼此矛盾，由于用戶體會都在于小的細節，而這些小細節終究毀于他們的不忍心使代碼變得紊亂。

這恰如其分的總結了“Web 開發純化者”們所采取的強硬立場。他們是守舊派，倡導在規劃和開發之間劃清界限。明顯，規劃師為人類創造，開發者為機器創造。因而，用戶體會規劃師們應該規劃出最可行的用戶界面并讓開發者做出最可行的編程決策。盡管這有必定的道理，但當我研討一個用戶界面的時分，我從代碼中尋找創意的努力卻以失敗而告終?？倸w，在頭腦中有一個技能及可用性約束的正確觀念仍是更有好處。

寫在最終

歸根結底，所開發項目的規劃可能終究決定著規劃師和開發者的人物。一個小型的應用可以由一個項目經理（注2）一手掌控，而一個大型的體系必定需求不同的專業人才！

注1 Mathis-Lukas——“Designers are not Programmers”——ignore the code

注2 Spolsky-Joel——描繪了一個叫做“規劃師兼程序員”的職位——“How to be a program manager”——Joel on Software

作者 John Urban 是加州大學的大二學生，主修計算機科學