上文講到過分工不合適的原因，這次想和大家探討一下我的一些關(guān)于如何解決問題的想法：

　　1. “架構(gòu)＋設(shè)計＋研究”的分工
　　簡單地說，就是架構(gòu)組負責底層建設(shè)和方向引領(lǐng)，設(shè)計組負責設(shè)計和實現(xiàn)，研究組負責（部分的）用戶研究和可用性測試。詳細介紹可查看以前寫的《說說互聯(lián)網(wǎng)公司內(nèi)設(shè)計師的分工》。這種分工能夠解決上述的大部分問題。

　　此外，正如jean.ma所說，在項目內(nèi)的分工，應(yīng)遵循“按模塊而非角色”的方式來進行（這點我在《說說互聯(lián)網(wǎng)公司內(nèi)設(shè)計師的分工》也說過），就是不同的設(shè)計師負責產(chǎn)品不同的部分，然后由一名總設(shè)計師來統(tǒng)籌兼顧。

　　2. 知識管理、文檔管理和版本控制
　　專門設(shè)立一臺服務(wù)器，使用開源工具（比如Drupal），將所有的項目相關(guān)文檔都進行集中的統(tǒng)一存放和管理，使任何事情有據(jù)可查，減少溝通成本，消滅“產(chǎn)出物發(fā)給了A部門，忘了發(fā)B部門”，或是某人說“我找不到你發(fā)的Demo了再發(fā)一次”的問題。

　　如果你的部門使用Dreamweaver作為設(shè)計和開發(fā)工具，那就更好了！讓架構(gòu)組把最新的Dreamweaver模板和代碼片斷上傳到服務(wù)器上，然后每個人打開Dreamweaver時第一件事情就是更新本地模板和代碼片斷（DW早就有此功能），這樣不僅協(xié)同起來效率很高，而且質(zhì)量可控性很好?？梢哉f，這在一定程度上實現(xiàn)了開發(fā)使用Eclipse+SVN進行協(xié)同工作的效果。

　　至于版本控制，一方面，給每一份產(chǎn)出指定一個唯一且明確的版本號，所有項目組成員交流時以版本號而不是“最新”一詞為準，消滅歧義和不確定性。

　　另一方面，如果你使用CVS或SVN進行版本控制，一定要把我們設(shè)計或開發(fā)的版本（也就是使用CVS或SVN進行版本控制的版本，以下簡稱trunk版）和給項目組演示的版本（采取手工方式進行版本控制，以下簡稱milestone版）分開，這樣不僅可以加快我們的開發(fā)效率，更重要之處在于減少許多溝通成本。

　　比如，假設(shè)你上午9點通知業(yè)務(wù)部門及開發(fā)部門，說某項目的Demo已經(jīng)做好，訪問服務(wù)器即可查看，一般情況下你并不能保證所有人都在接到你的通知后立即查看 Demo，很可能有的人是在9：30分看到，有的在10：00看到，甚至有的在第二天才看到。這期間你很可能會根據(jù)業(yè)務(wù)部門或是開發(fā)部門的反饋對Demo 進行了修改（哪怕是小修小補），那么這樣一來，大家討論的基礎(chǔ) - 統(tǒng)一的版本就不復存在了。

　　我們可以借鑒程序員的做法，將trunk和milestone分開：平時在trunk上提交各類修改，如果需要展示給他人，則另外拷貝一份milestone版本（或新打一個分支，但此時意義不大）。比如你調(diào)試和預覽的地址為 http://ued-server/demo/project-a/ ，當需要展示時，將project-a目錄復制一份到 http://ued-server/demo/project-a/milestones/1 ，并以此作為第一個milestone。項目組成員在溝通時，都以milestone為基礎(chǔ)。

　　3. 把視圖（view）交給它本來的主人－前端開發(fā)（甚至設(shè)計師）－去處理
　　由于模板里常?；祀s著HTML和程序語言（暫且以PHP為例），而這兩種東西又分別來自于UED和開發(fā)兩個部門，因此無論是編寫還是調(diào)試模板，都要牽涉前端開發(fā)和程序員的精力。工作職責模糊不清，權(quán)責也很難界定。關(guān)系好的程序員曾私底下和我報怨說“如果連HTML/CSS/Javascript這些東西我們都寫了，還要UED的人干嗎”，雖然HTML/CSS/Javascript我都是盡可能完整產(chǎn)出，并且這句話也有其偏頗之處，但我仍對此深覺慚愧。

　　“模型（model）－視圖（view）－控制器（controller）”架構(gòu)的重要目的之一，就是把視圖盡可能與邏輯和數(shù)據(jù)分開。當以模板的形式把視圖分出來以后，為了盡可能地降低模板的復雜性、又同時保持模板具有一定的邏輯和數(shù)據(jù)處理能力，讓不那么熟悉程序的人也能夠控制如何顯示，人們才開發(fā)了各種模板語言，比如PHP中的Smarty和Java中的Velocity。也就是說，這種極度簡化的模板語言就是專門給設(shè)計人員提供的，它甚至不會比Javascript更復雜！

　　當把視圖部分的工作完全交給UED后，開發(fā)和UED的合作可以以這樣的方式進行：1）UED提供原型；2）開發(fā)按照原型提供所需的邏輯和數(shù)據(jù)（通常是一大堆if...else...和$username等變量）；3）如果有必要，可以要開發(fā)按原型來寫一個不考慮內(nèi)容及樣式的模板，模板里包含了所有必須的邏輯和數(shù)據(jù)；4）UED將邏輯、數(shù)據(jù)和各種前端代碼編寫進模板。

　　這個方案我曾和系分及程序員討論過幾次，我們都認為它是可行的。出于可維護的角度考慮，他們其實也愿意將模板的編寫工作交給UED。

　　此方案的優(yōu)點是顯而易見的：開發(fā)和UED終于可以真正地各司其職，大家權(quán)責明確，從項目管理的角度來說，UED的工作時間計算也更為準確，以前那種“UED協(xié)助調(diào)試模板，花了大量時間卻沒有被記錄進項目”的情況不會出現(xiàn)。

　　缺點當然也不是沒有，在方案實施初期，UED一定會有陣痛，尤其是對那些從沒有接觸過后臺編程的設(shè)計師。

　　4. 強調(diào)工具和規(guī)范的重要性，而非某個人的聰明才智
　　天涯上前段時間流行一篇名為《做單》的小說，里面有一句話印象很深：

　　“外企更像是一個集團軍……民營企業(yè)都像是個游擊隊或者是特種部隊……集團軍最大的特點就是隨便換掉某個人或者某幾個人對整個軍隊沒有任何影響，游擊隊就不能承受這種變化。

　　國內(nèi)的企業(yè)面臨最大的問題就是從游擊隊向集團軍的轉(zhuǎn)變中，因為人意識的轉(zhuǎn)變跟不上，而導致轉(zhuǎn)型失敗……一個民營企業(yè)要想做大，必須經(jīng)歷這種從游擊隊向集團軍的轉(zhuǎn)變。”

　　關(guān)于規(guī)范說得夠多了，還是說說工具吧。

　　從團隊的角度來說，工具主要的目的就是最大限度地統(tǒng)一和標準化產(chǎn)出物，提升團隊的工作效率和質(zhì)量。因此以下提及的工具都是與這個目的相關(guān)：

　　Dreamweaver。它內(nèi)建Templates和Code snippets功能，并支持從服務(wù)器上同步，如果整個部門都使用Dreamweaver的話，那么大家的Templates和Code snippets就全是規(guī)范的；
框架。無須贅言，好的框架可以讓你3分鐘做完原本需要10分鐘的事情，并且產(chǎn)出物（典型如代碼）高度規(guī)范；
文檔庫。比如前文提到的VelocityDoc，有了這東西，設(shè)計師可以在短時間內(nèi)了解整個網(wǎng)站的模板，包括模板整體的結(jié)構(gòu)、每個模板的作者、功用、所引用的CSS/Javascript，以及它所屬的layout和所包含的control/element等等。對于新同事來說，文檔是最好的老師；
封裝。努力地將常用的東西封裝成模塊，避免重復勞動，同時也能降低對設(shè)計師的技能要求。比如說對于表單界面，交互設(shè)計師根據(jù)不同的錯誤情況，需要制作出不同的原型，費時費力，還容易出錯，如果封裝一下，設(shè)計師只按照一定格式提供錯誤提示的內(nèi)容就好了，剩下的什么都不用管，全交給系統(tǒng)自動處理。
上面講得有點太干巴巴了，這里有一個06年做的東西－代碼助手－算是上述思想的一個集中體現(xiàn)吧。

　　關(guān)于分工的話題暫且到此為止吧，這么枯燥冗長的內(nèi)容不知有多少人可以堅持讀完，呵呵。

　　原文：http://heartstringz.net/blog/posts/view/why-no-division-in-web-design-2