美工跟程式員合作應該注意哪些問題?

 在做ASP.NET程式時，思考了一下美工與程式員如何較好得配合，于是搜尋了CSDN裡關于美工與程式員配合得文章，下面是一些觀點及經驗的轉貼。

  編碼人員和美工的配合問題 

公司的項目都是基于B/S結構的，絕大多數操作界面都是通過網頁的形式展現在使用者面前的，頁面的美觀就成了非常重要的問題。記得去年的這個時候公司迎來了它曆史上的第一個專職美工。同時到來的就是程式員與美工的合作問題。

沖突篇：

公司以前的系統都是由程式員來編寫界面的，美觀與否先不必說，單從效率上講就是一個很大的問題。大部分時間都花在了界面的編寫上，嚴重影響了項目的進展速度。美工到來以後，頁面的美觀程度和制作速度都有了很大提高，随之而來的程式員與美工的配合問題又成了一個新的問題。其中主要的問題、沖突有以下幾點：

1．        1. 美工何時參與到項目中來

2．        2. 程式員不懂如何将頁面弄得美觀，美工也不懂如何向頁面中添加代碼（即使是使用了Velocity）

3．        3. 程式員和美工是兩種完全不同的人，他們關心的事情也完全不同，這就導緻兩種人對頁面代碼（html）風格的要求大相徑庭——程式員要得是簡單易懂，美工要得是美觀漂亮

4．        4. 程式員要做的是将資料展現在頁面上（使用簡單的條件、循環語句），美工要做的是将美麗充滿整個螢幕（程式員會叫道：天哪！這麼複雜，我怎麼用if、else、for來實作）

解決篇：

上面的這幾點問題和沖突從關系上來講是層層遞進的，要一個一個依次解決。先來說說美工何時介入到項目中來，在公司做過的這些項目以及我聽說過的項目看，大緻有以下幾種：1）先有美工制作靜态頁面，完成後程式員直接向頁面中添加程式代碼；2）程式員随時和美工溝通，向美工描述頁面需求，随要随做；3）程式員自己編寫測試頁面，然後讓美工進行美化。

這3種方式可以說是個有利弊。方式1）對程式員來說絕對是個喜訊，它能使程式員最大限度的遠離那些煩人的頁面編碼，提高程式員工作的含金量。同時，一套完整的頁面可以展現全部業務的流程，對程式員開發也起到了規範的作用。但這種方式對美工的要求極高，美工要了解項目的需求，而這一般是達不到的。但可以讓了解需求的人為其講解，或是描繪出希望的頁面的樣式。這樣雖然可以彌補美工對業務了解的不足，但也确實花掉了很多時間（而且是花掉了比較重要的人物的時間，因為了解整體業務的一般都是公司的牛人，他們的時間可是一刻千金呀）。方式2）是一個比較折中的方法，這樣做無需太多的準備就可開始編碼工作，程式員把握頁面内容和樣式，向美工較長的描述，美工再根據描述設計頁面，最後傳回給程式員添加代碼。這個回報的過程一般比較迅速，效果也不錯，可以達到程式員預期的效果，适用于項目時間要求比較緊的情況。該方式的問題在于沒有一個形象化的完整的流程可供程式員參考，一切掌握在程式員手中，容易造成對需求的A錢和系統整體風格的不統一。方式3）一般用于對已有項目的美化上，對美工的要求也很高，她們需要具備在html和其他代碼混合體的環境下工作的能力。而且修改的效果一般不是很佳，不到萬不得已不推薦使用。

問題2.3.4.雖然表現出來的問題各不相同，但解決的方法卻很相似。首先，美工要養成一些程式員編碼時慣有的習慣，比如：檔案命名要有意義、html代碼要根據層次進行縮進等。其次，頁面代碼的一些細節也要注意，比如，使用居中或右對齊标簽來取代空格，必須使用空格時也要用“ ”，不使用<p>标簽，盡量使用表格等。再次，如果在條件允許的情況下，美工也可以學習一下夾雜在頁面中的各種程式代碼，了解其語義和工作原理，這将對與程式員的合作起到很大的幫助的。最後，就是程式員要在向頁面檔案中添加代碼前先對頁面代碼做一下稽核工作，在這裡并不是看美工的頁面是否美觀，而是看在原有頁面代碼的基礎上是否能夠使用簡單的條件、循環語句來顯示資料（比如，頁面布局過于複雜，不能通過簡單的循環來顯示所有資料），否則就需要修改頁面代碼直到能滿足要求為止。

做網站背景的流程一般是這樣的：

一、網站規劃階段

　　這個階段主要是對網站的功能、目标閱聽人、内容、欄目進行規劃。這期間會經常性地和有關上司進行溝通。首先，自己一定要對網站的整體規劃清清楚楚，然後要吸收别人的建議。吸收别人的建議的過程，可以認認真真地做，也可以走過場，但是有這個過程以後，别人才不會對你的規劃說三道四。

至于上司的意願，和你的規劃靠得上邊的，你一定要讓上司明白，他們的設想已經在你的規劃中被考慮進去了。

項目的大緻進度，要在這個階段結束的時候确定下來。

二、背景子產品劃分和版面設計

　　這個階段，程式員要和美工兵分兩路分頭行動。

背景子產品劃分如果做好了，後面的效率會高一些。這個過程不能省。

版面設計，美工既要考慮網站整體規劃，又要考慮大家的建議，尤其是不能忽視上司們的觀點（雖然大多數情況下上司的美術細胞少得可憐）。在這個大前提下，再兼顧美觀、合理。一個好的美工，不僅僅能做出漂亮的頁面，還要能迎合一下客戶或者公司上司的意願，而且能和程式員進行溝通。

在這個階段，程式員和項目經理（項目負責人）要拿出一個可操作的子產品劃分方案，而美工要确定網站的版面架構、美術風格，做出網站首頁和二級頁面。

實際上，在第一個階段（網站規劃階段），美工就應該開始思考網站的風格了。在第二個階段，則需要把比較抽象的初級設想變成具體的頁面。基本上，首頁定了，整個網站的頁面就定了一大半了。

在這個階段結束的時候，要将項目的進度計劃進一步具體化。

三、資料庫設計

　　這項工作很重要。但是程式員應該知道怎麼去做。而且資料庫設計是和一個人的理論水準、實際經驗息息相關的，不是幾句話能說明白的。大的、複雜的站點，資料庫規劃可能要用一周左右的時間，小的、簡單的站點，資料庫設計也需要2到3天。

在這個階段，美工最好别閑着，繼續完成頁面設計。要知道下一個階段，程式員可就要用到美工的頁面了。最好别出現這樣的情況：程式員要用到某個頁面，而美工還沒有把那個頁面确定下來。

四、背景程式編碼

　　這個階段，程式員要緊張工作，會比較辛苦的。

程式員需要遵守的三個原則：

1、團隊合作；

2、保證進度；

3、保證品質。

美工這個時候要輔助程式員做頁面。這個階段美工可能比較閑，但是一定要稱職。

　　項目經理該和客戶或者上司溝通的時候，一定要溝通。

五、除錯、改進、頁面美化

　　這個階段，不多說了。項目經理和客戶、上司的溝通，仍然是很重要的。

經驗之談

我自己摸索下來感覺小山之方式2将來更能使團隊發揮好，但需要更科學合理地來分角色，做到各司其職，才能避免陷入作坊式開發。

我就大緻描述一下我的項目團隊（算上美工5人）在這方面的情況：

首先，介紹角色：

 １．項目組長：相當于項目經理吧，主要職責我就不多說了。

 2.界面工程師：是使用者界面互動方面的專家，決定與使用者互動的方式，當然很大程度也影響着界面

 3.美工：設計和美化界面

 4.進階程式員：設計總體程式結構，制定技術上的規範，并為小組解決各種難題，幫助項目組長分解每日程式員任務

 5.程式員：編寫代碼，實作功能

 6.需求人員：與本話題無關，我就不介紹了

 7.公關人員：雖然與本話題無關，但我就想在這裡突出其對項目組的重要性，是以順便提一下。至于要攻什麼關大家一定都能猜得出來。

 8.其他，如測試人員、文檔管理人員等(想象能有plmm角色)：都很重要，但也與本話題無關。

工作流程：

 1.公關人員和需求人員獲得使用者需求，并制定需求文檔。

   需求的正确與否是項目成功的首要關鍵環節，這個我就不多說了，和本主題相關的就是他們需要擷取到使用者的各種習慣層次上，主要分為兩種思路來整理，一種是之前用過軟體系統的考慮如何延續他們的習慣，另一種是之前沒有用過軟體系統的考慮如何适應他們原有手工的工作流程，并作出合理化的改進。

 2.項目組長和需求人員以及進階程式員共同根據需求制定大體的設計方案，包括總體子產品和各個可行性功能。

  在這裡，項目組長會根據需求人員和進階程式員的意見來合理安排出一個基本雛形，然後去寫Project2003（我覺得這個蠻不錯）...後面還有反複交複雛形給使用者确認等等我就不介紹了。有一點值得注意的是，項目組長除了需要具備一定的人員管理方法以外，最好還是要懂得技術，這樣能夠制定出更合理、更準确的項目進度，也能帶動團隊工作的士氣。個人認為項目經理的技術水準應該在進階程式員之上，不然在這個環節中就隻能聽取進階程式員的意見了，相信大家如果遇到個不懂技術的項目經理，而他又指責你技術水準有問題時，一定都會自然而然地産生想K他一把的沖動，這樣的團隊還能保持好的士氣麼？技術人畢竟還是需要以能耐服人來得好。

3.開工，項目組長在進階程式員配合下根據預先計劃開始推動項目進展。

  這裡是關于本主題的主要環節，首先由項目組長和進階程式員在上一環節設計的雛形的基礎上按照計劃規劃架設各子產品的基本結構。然後以子產品為機關，我這邊團隊喜歡采用我們稱之為狼群戰術的方法來逐漸蠶食各個子產品，每個子產品的流程分為如下幾個步驟

   a.進階程式員詳細化拆分該子產品的各個界面和功能，包括前台和背景等。需要需求人員給出參考

   b.在進階程式員的配置設定下，界面工程師對目前子子產品制定界面使用者互動的基本方案，也需要需求人員給參考，美勞工員則給出美學方面的建議，并達成一緻。在這裡，界面工程師會将決定界面的大緻架構，并将界面相應的功能描述成文以用于給程式員，一個子子產品界面的雛形在這裡已經誕生，生成的程式檔案有aspx和(vb或cs)，建議界面結構最好用表格來設計。

   c.美工去做界面，對界面工程師所搭建的界面架構aspx或ascx檔案進行處理，如背景、需要配合的圖檔圖示及flash等。在這裡環節上，美工已和界面工程師已經在明确需求人員的指導下達成對界面統一風格的一緻。因為界面工程師在之前已經在頁面中制定好标記，是以美工可以忽略有腳本标記的地方。而且，總的來說這一環節上美工主要是預先為界面定義好各種素材。

  d.與美工并發執行的是進階程式員與程式員對功能的實作。程式員們在界面工程師的指導下将功能實作，其間包括滿足互動功能所需的控件、業務規則層、資料通路層，等等的實作，所涉及編寫的檔案則為界面檔案(ascx等)和程式檔案(vb或cs)。這裡需要說明的是在實作功能時程式員隻要把滿足功能的控件拖到大緻位置就可以，然後就關注功能的實作。而此時美工也在設計該界面，但因為隻是設計素材，是以根本不與程式員沖突，在後面的環節中始終以程式員完成的程式文檔為準。

  e.程式員完成功能後，轉交測試人員進行功能測試。。。

  f.基本測試通過後，又回到界面工程師手裡，在不改動程式檔案(vb或cs)檔案的前提下，界面工程師隻對界面檔案中的各種控件、結構等進行調整。達到滿意的效果為止。

  g.界面基本已經誕生，隻是全裸不太文雅，是以這時回到美工手上，給其穿上美工設計的靓裝，加上各種圖檔背景等就ok了

  h.補充一下項目組長，貫穿整個過程，負責團隊人員之間的協調，監督項目進度，合理配置設定任務，看誰不幹活就。。。

 4.所有子產品都完工後，就是整體的銜接和測試，然後反複交複使用者征求意見，這裡參與的是團隊所有的人馬，一直忙到最後期限為止，然後再延期，直到使用者滿意。

  以上是我所在團隊的大緻工作流程，大家看了後一定會提出如此分角色人手資源一定不夠的問題。确實，通常來說小公司的開發團隊就幾個人，是以通常很容易做着做着就陷入作坊式做法，大家角色不明确，各自包辦各自的子產品，導緻之後程式維護非常困難。我上面所述的工作流程中每個環節都明确指出了每個角色的出現場合，是以我是很強調以角色來分工。但如我前面所提到的，我這邊的團隊也不過5個人，是以，雖然角色衆多，但我們還是可以根據各自的團隊實際情況來分擔這些角色，隻要記住一個原則，找合适的人去做合适的角色，即擔當某一角色的人是對該角色領域感興趣的人。比如在我的團隊中，美工是對藝術美感感興趣，我團隊的美工是plmm，可惜隻是兼職，沒太多機會，建議大家有條件就找plmm來擔任。需求人員是對整體業務有興趣的人，我這裡的需求人員是辦公室頭，是以向上和外界的公關都是由他搞定。還有兩個是程式員角色，一個偏向于底層資料庫的實作，另一個偏向于邏輯層的實作，而最後我則是很痛苦地擔當了項目組長、界面工程師、進階程式員的角色。之是以這樣，也是無奈，因為團隊組建才半年不到，兩個程式員尚不能勝任更進階的角色，期望其中一個人能盡快勝任界面工程師角色，那樣就能做到更合理化的角色配置設定，是理想的團隊結構。