規(guī)劃師也必須要會編寫代碼

做現(xiàn)實可行的規(guī)劃

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

使溝通更輕松

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

便利的迭代開發(fā)進程

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

更好更調和的成果

我常常喜歡把軟件，網絡或是游戲開發(fā)想成是管弦樂，而規(guī)劃師是作曲家，開發(fā)者是樂團的指揮家。幻想一下二者是同一個人將會怎樣？交響曲將會是令人驚嘆的，迷人的，純正的！不僅是大師的神作，而且仍是其本人親身指揮的！

縮短開發(fā)時刻

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

規(guī)劃師愈加市場化

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

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

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

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

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

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

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

寫在最終

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

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

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

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