無主程序員組溝通路徑

㈠ 程序員怎麼更好的溝通

1：相信他們
2：給出足夠的時間
3：尊重他們的勞動

㈡ 你如何認識沖突、溝通與協調在當前我國企業的現狀你認為應當如何改造

論著選摘

軟體開發組織的溝通與協調

楊昆 王二平

中國科學院心理研究所 北京 100101

中國科學院研究生院 北京 100015

【摘要】在對軟體開發中人員與組織問題進行回顧的基礎上，該文首先就軟體開發組織溝通與協調的重要性進行分析，然後對軟體開發組織中的溝通與團隊結構、溝通與項目成員、溝通頻次分布、溝通方式等問題，以及整體協調、外部協調、內部協調等問題進行闡述。最後就今後軟體開發組織溝通與協調問題可拓展的研究方向進行了討論。

【關鍵詞】溝通，協調，軟體開發，組織心理學

1人員與組織因素

計算機軟體產品的開發是信息技術的一個重要方面，也是構成信息產業的主要部分之一。隨著軟體產品的規模不斷擴大，復雜程度不斷提高，軟體開發出現了大量問題，被稱為「軟體危機」(software crisis)。從組織心理學的角度來看，軟體開發是一種典型的聚合型作業——成員雖然形式上獨立完成分配的作業，但最後聚合為完整的作業。最終作業對各部分作業的技術標准和完成時限有要求，形成成員活動的相互制約。因此，軟體開發的組織心理因素顯得尤為重要。Ewusi-Mensah和Przasanyskid對開發失敗的軟體項目進行研究表明，管理是影響軟體研發項目全局的因素，而技術隻影響局部。Doherty和King等人在對大型軟體組織的調查中發現，軟體開發中的組織問題甚至比技術問題更為重要。

軟體開發人員與組織因素的研究始於20世紀70年代。Weinberg認為軟體編程既是個體活動也是社會活動。作為個體活動的編程行為包括：智力、問題解決能力、動機、經驗等問題；作為社會活動的編程行為包括編程群體、團隊和項目的組成與協調溝通等問題。Brooks認為軟體的復雜度、不一致性、可變性和不可見性是軟體的本質困難，導致人員溝通困難、產品瑕疵、成本超支和進度延遲。鑒於此Boehm提出「軟體生產率改進機會樹」(software proctivity improvement opportunity tree)，將人員和組織因素列為提高軟體生產率的首要機會，包括人事安排、工具配備和管理三個要素。1976年Newman以《人件系統》為名探討了軟體開發中的人員風險，第一次提出與軟體、硬體相對應的「人件」(Peopleware)概念。1987年DeMarco和Lister出版了《人件：富有成果的項目和團隊》，引起業界對這一概念的重視。作者指出，知識工人需要思考，每個人都是獨特的和不可替代的；強調工作環境對軟體生產率有重大影響；提倡團隊成員的互補性，認為給知識工作者以自由和信任最有可能形成優秀的團隊。此後，Constantine擴大了「人件」概念，將軟體的使用者也包括進來。卡內基梅隆大學軟體工程研究所(SEI／CMU)綜合軟體開發人員與組織問題研究成果，推出軟體能力成熟度模型(Software Capability Maturity Model，SW-CMM)和人員能力成熟度模型(People Capability Maturity Model，P-CMM)[13,14]對軟體開發過程和人員管理活動進行規范。

2溝通與協調的重要性

在軟體開發的各人員與組織因素中溝通與協調問題是影響軟體生產效率和可用性的重要問題。溝通(Communication)是指人們分享信息、思想和感情的任何過程。狹義的溝通僅指信息的交流，是使信息發揮積極作用和達到目標的手段。Brooks指出溝通是軟體開發計劃中必須考慮的工作量：人數n的變化，將引起溝通路徑n×(n-1)／2倍的變化。這使得軟體開發中人員與時間兩個要素不能進行線性變換而是呈現出錯綜復雜的關系。此後，一些實證研究也說明了溝通對軟體開發的重要性。Curtis用訪談法研究了17個大型軟體開發項目，溝通和協調中斷是導致軟體項目失敗的主要原因之一。McConnell通過文獻分析，總結出軟體開發的12項典型錯誤，其中和溝通問題相關的有4項：(1)嘈雜的辦公環境不利於溝通，(2)領導與問題雇員溝通不暢，(3)用戶信息輸入不足(4)項目後期加入人員，增加了明確共同目標和知識所需的溝通成本。Sonnentag對德國29個軟體項目中優秀人員的必備要素進行調查，發現社會技能(主要指溝通能力)僅次於專業技能成為優秀軟體人員必備的第二大要素。在隨後的研究中，Sonnentag對優秀軟體人員的行為特徵進行分析，結果表明：優秀軟體人員的績效與對溝通活動的投入程度有顯著相關。在同事的表述中，優秀軟體人員有較高的社交能力；優秀的軟體人員自身也把溝通作為完成任務的重要策略；他們投入團隊磋商和評審會並且積極從同事那裡獲得反饋的實際行為也比一般人員要多。

協調(Coordination)是指「對相繼的和同時的互依活動進行調和的過程」。狹義的協調僅指「對完成目標各活動間的相互依賴關系進行管理」。通用領域常見的依賴關系有以下幾種：先決條件；資源共享；同時性。Toffolon和Dakhli從 軟體開發活動復雜的背景分析其協調的重要性，認為：首先，軟體開發組織從事的商業活動是持續變化的；其次，軟體開發活動是在一個包含技術、經濟、人員和組織等因素的大型環境中進行的；再者，軟體開發活動本身是在一系列相互依賴過程的基礎上進行的。McConnen通過文獻分析總結出的12項軟體開發典型錯誤中，與協調問題相關的有3項：(1)軟體開發沒有明確的目標和動機(2)隨意取消開發的上游活動，如為了增加編碼時間而壓縮甚至取消設計活動(3)軟體質量保證(SQA)部門協調能力薄弱。Brooks指出，軟體開發過程是一個熵不斷增加的過程。因此，軟體開發需要大量的協調活動，從外界導入負熵流。

3溝通問題

3.1溝通與團隊組織結構

Schneider man將軟體開發團隊概括為三種類型：傳統團隊、無我開發團隊和主程序員制團隊。這三種團隊的溝通形式如圖1所示(雙向箭頭表示信息的溝通)。Schneiderman認為，上述三種開發團隊結構在溝通方面各有千秋。傳統團隊只允許必要的人際溝通，比較適合於項目本身就是層次結構的大型開發項目。無我的團隊成員溝通十分充分，這種團隊被認為適合於研製時間長、開發難度大的項目。而主程序員制團隊突出主程序員的領導，屬於集中領導形式，主程序員是溝通的核心，能否取得好的效果，很大程度上取決於主程序員的技術水平和管理才能。

隨著對軟體產品可用性(Usability)的重視，用戶成為日益受到關注的信息源。Castka和Bamber在總結軟體開發的團隊策略時指出最好的創意通常來自客戶或用戶，他們認為Kidd在1994年提出的「人機綜合製造」結構(Human And Computer Integrated Manufacturing，HCIM)，正是考慮了與客戶溝通的因素實現快速製造範例的團隊策略。「人機綜合製造」結構如圖2所示，這樣的結構能夠使企業實現組織內部圍繞流程形成自然群體，並提供了將企業外部的用戶、客戶、供貨商包含進來的空間。HICM結構強調了這些群體之間的溝通(人員和技術溝通匯流排)，同時描繪了人員與技術之間的介面。

3．2溝通與項目成員

Brooks認為「向進度落後的項目增加人手，只會使進度更加落後」，增加的溝通工作量可能完全抵消任務分解所產生的效率。Curtis通過對某個開發項目19次項目會議的持續觀察，發現了符合「Brooks法則」的現象。該項目開發的後期，有兩位分析員加入到被研究的項目中來，但對團隊的績效沒有起到明顯的效果，也沒有提出新的設計方法。Curtis認為，在項目之初團隊處於學習階段，溝通和協調較活躍。如果一個新成員在項目的學習期結束後才加入團隊，他帶入的新知識對團隊產生的作用是十分有限的。如果這些新的成員必須加入團隊，項目經理應當更多地加強團隊內部的溝通，確保新成員帶入的知識能夠與團隊現有的想法綜合在一起。

Curtis還發現，在開發團隊中各成員對溝通活動的參與程度是不同的。在對17個大型項目的研究中發現項目早期的溝通是由少數個體占踞的，而對某個開發項目19次會議的持續觀察也發現10個團隊成員中有3人(一個客戶代表，兩個設計人員)似乎支配著整個項目，成為溝通的中樞。Curtis對這些項目的實際領導者的背景進行分析發現，這些人員同其他人員相比擁有更廣的知識和經驗領域，而不是在某個領域經歷的時間更長。Sonnentag對德國和瑞士的29個軟體開發項目的研究也發現類似的現象，積極溝通、績效優秀的項目成員比平庸者從事過更多項目，掌握更多種開發語言，而不是有更長的工作年限。這表明，知識和經驗的廣度比資歷更能預測成員在團隊溝通中實際扮演的角色和他的績效。

Clegg通過訪談研究發現，最終用戶和項目經理這兩個角色在軟體開發溝通中的作用未得到發揮。大部分受訪者強調，最終用戶是系統開發的關鍵性角色，尤其在需求分析和應用領域知識的溝通方面。但在傳統的開發過程中，最終用戶只是參與需求獲取和確認測試階段，結構化方法和工具限制了用戶專家發揮其角色的作用。在大部分訪談中，開發人員仍然被認為是軟體開發的主體力量，即使對管理和新系統運行負責的客戶經理也經常被認為缺少對項目的影響力。大部分受訪者還強調，高層經理較缺乏對新技術及其長遠影響的理解，成為技術溝通的瓶頸；項目經理缺乏對系統中人員和組織方面的重視，導致內部溝通不暢。

Steven和Henry根據Belbin的團隊角色模型，對軟體開發團隊中「培養者」角色進行了實驗研究。Belbin曾經提出，有效決策團隊的核心由八個重要角色組成，其中「培養者」(Plant)角色是指團隊中能夠洞察行為過程、提出進一步建議和新思維的角色，其特點在於個人主義、思考嚴肅、有見識、非正統、智慧。Steven和Henry的結果表明，全部由「培養者」組成的團隊在完成軟體開發任務的時間上明顯少於對照組。同時，通過觀察發現，這樣的團隊有較強的溝通能力，他們不但自己能夠產生創新的思想，而且能夠很快理解隊友的新想法。

3．3溝通的頻次分布

軟體開發中的溝通不僅限於團隊內部，而是涉及整個組織內部和外部。Curtis通過現場研究，給出一個軟體組織溝通的分層結構。如圖3所示，共有五個層面：(1)個人層面(2)團隊層面(3)項目層面(4)公司層面(5)商業環境層面。

該模型指出，軟體開發的正式溝通最常發生在團隊成員之間；同一項目的不同團隊之間溝通相對較少，有一定合作關系的群體之間溝通更少，群體與外界的溝通最少。跨越不同層面之間的溝通渠道經常會過濾掉很多信息或對所傳遞的信息的意義產生曲解。除了正式的溝通結構引起的障礙，溝通的困難還在於地理上的分隔，文化差異和環境因素等。

Dutoit和Bruegge通過現場觀察發現，成效良好的軟體開發組織，其團隊之間的溝通頻次高於團隊內部的溝通頻次。另一方面，從時間坐標上來看，開發成效良好的團隊在需求和聯機調試兩個階段的溝通頻次明顯高於開發效果不佳的團隊。Gopal，Mukhopadhyay和Krishnan對離岸軟體開發的溝通問題進行了研究。離岸開發(offshore development)是指不在美國本土進行的軟體開發。印度目前是美國最大的離岸軟體開發承接國。研究者對34個在印度開發的軟體項目進行問卷調查，結果表明成功的項目經理與軟體提供商的溝通頻次和與最終用戶的溝通頻次保持平衡。

3．4溝通的方式

在軟體開發項目中，溝通的方式因溝通者處於軟體組織的不同層面，開發項目處於不同階段以及開發採用不同的方法而各不相同。Curtis在軟體組織溝通分層結構中(圖3)指出，不同層面的內部和群體之間的具有不同的溝通方式。(1)個人層面，正式溝通主要靠文檔，並存在多個跨越組織邊界的個人網路。(2)團隊層面，文檔溝通效果不佳，經常靠建立一種正規程序來促進溝通。(3)項目層面，最有效的溝通手段是正式評審，一個或多個項目成員橫跨幾個團隊也有助於項目團隊的溝通。(4)公司層面，非正式的人員接觸比公司的評審程序更有利於溝通。(5)商業環境層面，最重要的是與各個客戶洽談，開發出一致認可的需求。

Kraul和Streeler對65個軟體項目群體內部的溝通實踐進行調查，從使用頻率和價值評價兩個維度考察常用的溝通技術。調查結果表明，由於需求評審、設計評審和客戶測試等溝通方式允許擔負不同職責的個人(需求分析員、系統工程師、構架師、程序員、測試員和客戶)通過結構化的方式，對相互的工作發表各種不同的意見，因此其價值評價明顯高於其使用頻率所暗示的價值，其中同行討論是最常用且評價最好的溝通技術。根據統計數據，被調查者對正式溝通的評價顯著低於其使用頻率所暗示的價值。這里所說的正式溝通既包括規范化的當面人際交往進行信息傳遞(代碼檢測、狀態審查)也包括非當面的溝通(項目文檔、源代碼檢查、里程碑時間表、錯誤跟蹤等)。計算機輔助開發管理工具(CASE)則是使用頻率最少且評價最低的溝通技術。

4協調問題

4.1整體協調

Toffolon和Dakhli指出軟體開發活動要協調四個方面的依賴關系：股東／客戶(S)、使用者(U)、軟體構架師(A)和開發人員(D)，並提出全局軟體模型(global soft waremodel)，如圖4所示。研究者認為軟體開發活動由四個空間組成的：問題空間、方案空間、建造空間和操作空間。問題空間(problem space)主要是定義股東／客戶需要解決的問題及其組織解決方案，對股東／客戶、使用者和構架師進行協調；方案空間(solution space)主要是針對問題的計算機解決方案，對軟體構架師、股東／客戶和開發人員進行協調；建造空間(construction space)主要是解決方案的實現，對開發人員、構架師和使用者進行協調；操作空間(operation space)主要是從最終用戶的角度評價軟體的可用性，從而也驗證產品競爭力，對使用者、開發人員和股東／客戶進行協調。

4.2外部協調

Toffolon和Dakhli還指出，軟體開發的依賴關系可分為兩類：外部依賴(又稱為縱向依賴)和內部依賴(又稱為橫向依賴)。對應這些依賴關系的協調也可分為兩類，即外部協調和內部協調。

軟體開發的需求分析階段是外部協調出現頻次較高的階段。Curtis等人在對大型開發項目的現場研究中發現，確定需求的過程中，需要對外部的市場影響和公司自身的實力進行協調，同時還要考慮一些潛在的影響，如圖5所示。

Crowston和Kanunerer在對需求過程中協調與信息搜集活動的研究中指出，需求分析包含四種相互依賴關系：生產者—客戶依賴、任務—子任務依賴、任務-成員依賴和需求之間的依賴。針對生產者-客戶依賴的協調，研究者建議採用原型產品標准化、詢問客戶輸入信息和使用者捲入開發等協調方式。針對任務—子任務依賴的協調，研究者指出，需求分析實質上是一項任務計劃活動，分析人員必須了解哪些任務已完成，並選擇那些已經完成或已存在的低端任務來實現高端任務。針對任務—成員依賴的協調，研究者指出，需求分析階段的協調應當更側重於明確執行特定任務所需資源的類型，從而協調任務與人員的關系。針對需求之間依賴的協調，研究者指出應當對這種依賴進行分類，採取措施針對可能對開發活動產生不良影響的依賴進行抑制。

4.3內部協調

研究者還對軟體開發團隊內部結構的協調職責進行了分析。傳統的開發團隊是由一個高級程序員指導若干初級程序員的工作，有經驗的高級程序員作成項目領導者，指導若干成員或團隊，而初級程序員對其編程軟體負責，報酬是通過提升體現出來的。在這樣一種層峰結構的開發隊伍中，協調的工作量非常大，成本非常高。針對傳統開發團隊中程序員對其編程產品高度捲入和以提升作為承認程序員工作價值的唯一方式的狀況，Weinberg提出「無我編程」(Egoless programming)的概念。他根據Festinger的認知失調理論，認為程序員由於對自己的編程產品高度捲入，會認為編出的程序是自己個人的產品，從而害怕別人發現其中的缺陷和錯誤，害怕暴露自己對任務的不勝任，不願接受對其程序的改進建議。這不利於軟體開發中的協調活動。因此，Weinberg建議成立「無我開發團隊」(Egolessteam)，強調個人的成功和失敗都被看作是團隊共同努力的結果，鼓勵合作而不是競爭。如果一個團隊成員執行任務遇到困難，提倡其他成員貢獻出自己的力量。Baker提出主程序員團隊的模式。這種模式類似於外科手術的團隊，主程序員是主要的設計者，編寫重要的代碼段落；後援程序員實施重要的操作，並為必要時接替主程序員做好准備；程序員在設計規范可實施的階段加入團隊。主程序員團隊協調團隊成員間的合作，提供了一個與醫療行業中圍繞主治醫師進行協調的相同的工作模式。

Levesque, Wilson和Wholey等人對軟體團隊是否會形成共同心智模式(shared mental model)的問題進行了實驗研究。結果表明，並不是所有開發團隊都會隨著時間的推移形成共同心智模式。復雜項目的不同分工將導致成員和群體在知識上的差異。這種差異有時是功能上的，因此通過召開會議建立團隊的共同心智模式成本很高。以共同心智模式作為協調手段所獲得的效益將隨項目規模的增加而不斷降低。研究者同時指出，以共同心智模式作為協調手段最適合於團隊成員具有相近技巧和能力的情況；而團隊中某些成員的技巧和能力高於其他成員的情況下，更適合通過項目經理的工作進行協調；對於任務簡單明確的情況，更適合把其他成員的工作視為黑盒，採用嚴格的規范進行協調。

5今後研究可拓展的方向

綜上所述，西方學者對軟體開發的溝通與協調問題進行了較為深入的研究。這些研究使 我們對軟體開發中溝通的組織結構、頻次分布、溝通方式等問題，以及軟體開發組織的整體 協調和外部內部協調等問題有了一定的了解。今後研究可拓展的方向主要包括：

(1)軟體開發組織的溝通協調行為與軟體生命周期關系的研究。軟體從孕育到衰亡的 生存過程稱為生命周期(1ife cycle)。一般把軟體生命周期分為：軟體計劃、需求分析、軟 件設計、軟體編碼、軟體測試和運行維護等六個階段。不同的開發框架又可形成不同的生命 周期模型。以往涉及軟體生命周期的溝通與協調行為研究多集中在前期的幾個階段。既然軟 件開發活動是隨生命周期的增長而熵不斷增加的過程，今後的研究應當拓展到軟體生命周期 的全程，尤其應加強對軟體生命周期後期的溝通與協調問題研究。

(2)軟體開發組織與用戶的溝通與協調研究。以往對用戶這一角色的溝通協調研究僅局限於需求分析階段，隨著市場對軟體產品可用性的重視，開發過程日益強調全程的用戶參 與(user involved)，今後應當對軟體組織與用戶的溝通與協調行為在軟體生命周期各個階段 的方式和作用進行更為廣泛的研究。

(3)虛擬開發環境下的溝通與協調行為研究。技術的進步使得以虛擬團隊的形式進行 軟體開發成為可能。在虛擬環境下，軟體開發組織中溝通與協調的動機、認知過程以及行為 過程會發生哪些改變是一個需要深入探討的問題。

(4)西方溝通與協調問題研究成果對我國軟體開發組織的適用性的研究。我國軟體組織規模較小，管理水平相對較低，開發過程缺乏層次較為混亂。我國對軟體開發的人員與組 織因素重視程度不足，目前僅有少量規范研究，尤其缺乏對軟體開發組織溝通與協調問題的 實證研究。我國學者除了需要關註上述的研究拓展方向，還需要考察西方已有的軟體組織溝 通與協調問題研究成果(如SW—CMM模型、P—CMM模型中關於溝通與協調的規范)是否 適合我國軟體開發的組織環境。從而盡快形成適合我國軟體開發組織的溝通與協調規范，促 進軟體開發生產率和產品可用性。

【參考文獻】（略）

文章選自《心理科學進展》（2004.6）

㈢ 各位親，一般怎麼跟程序員溝通的

少數程序員是那樣的，經驗不足，或者性格原因，或者疏忽，程序在設計和編寫的過程會出現一些與事先預期不一樣的結果，或者根本沒有考慮到這些情況。

他們已經夠累了，面對重復的更改有時很無奈。對於他們除了要把本職工作處理玩，還要學習新東西，以後不做這個了怎麼辦，自己只對這門語言比較熟，將來出來更新的怎麼辦。對於做網站那種處理界面的繁瑣工作，我想沒有幾個程序員會不煩躁。

眾所周知，程序員學的多，乾的多，掙的少。如果你正在做項目管理或者產品管理，你要懂的第一件事就是與他們溝通，我想沒有幾個程序員是固執己見的，程序員們都明白個道理，在技術行業里，一個人走不了多遠。

與他們溝通很簡單，把他當成朋友，而不是下屬。

㈣ 程序員工作中的溝通小技巧

程序員，是互聯網公司的一筆資產，也是產品經理等沖突的主要對象，如何提高與程序員之間的有效溝通，請看下文：

心態平和——程序員的內心世界是很豐富，在經歷了各種需求修改、bug修復後，相對而言與人交流的能力要明顯弱於與計算機的交流能力。因此一定要心態平和的與程序員進行溝通。

希望以上幾點建議，能夠幫助提升你與程序員之間的溝通效率。

㈤ 包含8個成員的開發小組的溝通路徑最多有多少條 答案是 28 這個是怎麼算出來的還有題

組合問題，C8,2=28
PS： 我明天也軟考！呵呵！
Schneider man將軟體開發團隊概括為三種類型：傳統團隊、無我開發團隊和主程序員制團隊。這三種團隊的溝通形式如圖1所示(雙向箭頭表示信息的溝通)。Schneiderman認為，上述三種開發團隊結構在溝通方面各有千秋。傳統團隊只允許必要的人際溝通，比較適合於項目本身就是層次結構的大型開發項目。無我的團隊成員溝通十分充分，這種團隊被認為適合於研製時間長、開發難度大的項目。而主程序員制團隊突出主程序員的領導，屬於集中領導形式，主程序員是溝通的核心，能否取得好的效果，很大程度上取決於主程序員的技術水平和管理才能。

隨著對軟體產品可用性(Usability)的重視，用戶成為日益受到關注的信息源。Castka和Bamber在總結軟體開發的團隊策略時指出最好的創意通常來自客戶或用戶，他們認為Kidd在1994年提出的「人機綜合製造」結構(Human And Computer Integrated Manufacturing，HCIM)，正是考慮了與客戶溝通的因素實現快速製造範例的團隊策略。「人機綜合製造」結構如圖2所示，這樣的結構能夠使企業實現組織內部圍繞流程形成自然群體，並提供了將企業外部的用戶、客戶、供貨商包含進來的空間。HICM結構強調了這些群體之間的溝通(人員和技術溝通匯流排)，同時描繪了人員與技術之間的介面。

㈥ 程序員怎樣和別人溝通

和客戶溝通不是程序員的問題
雖然他們很郁悶但他們還是有少數朋友的!
只是不太愛說話!!!可能是心理問題吧!

㈦ 視覺設計師如何高效率地和程序員溝通

彼此尊重對方，尤其是不要彼此稱呼對方為「美工」「寫代碼的」，尊重是良好配合的開始。
詢問原因，提出意見的時候一定要專業，否則就不要說。比如coding的同學如果覺得顏色不好看，請明確指出希望是什麼顏色，原因是什麼，而不是單純的說我感覺很不好。設計的同學如果用起來demo難用，記得詢問為什麼沒有實現出來，而不是一直說「這傢伙水平太差」，畢竟除了界面還有很多底層的東西需要實現，只是一個華麗的空架子也是白搭的。如果希望實現什麼效果但是自己不知道怎麼做到，最好去找一個現成的例子給coding的同學瞅瞅。
設計師請不要「超設計」，作為一個設計師（而不是單純的視覺設計師），應該更多的關心是如何能讓用戶使用起來更加方便快捷，如何coding上面實現成本最小，而不是各種show自己的技術。就拿iOS設備舉例，固然能實現很多自定義的功能，但是用戶是否需要？僅僅是為了設計的好看么？是否考慮coding的同學的工作量呢？如果不這么做用戶會不會不用這個軟體？
從設計草圖開始就要和coding的同學溝通，詢問實現的可能性，如何實現成本最低。當然對於自己某些設計的堅持還是要的，但是一定要站在用戶的角度來想。

設計師自己最好懂一些coding，可以不會重頭寫，但是至少知道現有技術能實現到什麼地步，有什麼方法coding不好實現的可以用視覺設計補足，出了問題自己能小修小補（ 你不能指望每個px都讓別人來幫你修改）
設計稿盡量標記仔細，比如寬度高度間距顏色等，最好都在設計稿上面標記清楚，這樣coding的同學才能更高效率。對於每個尺寸盡量都是測量好的，而不是隨手拉出來的圖形，因為在代碼裡面是不能「隨手拉」的，一定要有一個數值；而且coding的同學機器上一般沒有ps，不要讓他們自己去「吸」顏色
交付的文件盡量整理清楚，不要丟過去的PSD有200多層且沒有分組。這裡面要說的是coding的同學不需要原始的PSD，最好能幫忙輸出為各種切圖最好。
coding的同學最好在有大概框架之後，告訴設計的同學產品大概分幾個部分，每個部分需要什麼樣的圖片，這樣設計的同學才能更快的輸出素材。
記得項目完成後，拉著coding的同學，一起吃個飯吧～

㈧ 程序員怎樣提高自己的溝通能力

我是一個C#程序員……程序員的世界是成就的世界！～追求的成就感！所以頑強的戰鬥力是必須的……
所以我個人認為要想能成為一個優秀的程序員：
1、需要的最基本的條件是不煩不燥的耐心和一顆平常心態！
2、知識的進階在於經驗的積累！同時虛心接受別人的意見……
3、有著對於事物永不放棄的恆心和自信心、遇到困難在所難免的。
一個程序員並不代表了代碼的書寫能力，更體現了項目開發的系統架構能力，如果沒有好的架構思想，在強的程序也沒有質的超越，上面只是我工作以後的一點點淺薄認識……

㈨ 作為一名程序員，如何在職場中提升溝通效果

我覺得單純從程序員的角度來看的話，他們在溝通上面已經做得非常的精簡了，基本上是沒有什麼廢話的，舉個簡單的例子，就比如說某個程序員要去別的部門借某個東西，他們不會跟你拐彎抹角的，都是直接拿的，而且拿完之後，有的放回來也不知會一聲，因為在他們看來，這樣會更加的高效省時間，但是從普通人的角度來看的話，就缺少一點人情味。

所以我覺得這種人就應該改變一下自己和別人的溝通方式，當別人指出你錯誤的時候，你就應該虛心地接受，然後去檢查一下是不是自己真的出錯了，而不是和別人爭論，畢竟你的錯誤有可能會導致整個項目的崩潰。

㈩ 項目負責人如何和程序員溝通

做一名程序員，雖然好的口才不是必要條件， 但不善於表達自己想法以及與上司同事溝通，吃虧的是自己；

最近做一個項目，與項目的負責人出現一些不愉快的事情,出現這種情況雖然與其它雜七雜八的事情有點關聯， 但最重要的原因還是在工作上缺乏溝通； 例如， 上周他給我們C#組的人員分配工作， 每人負責一個小模塊， 資料庫和需求文檔已經提供有，但資料庫的表欄位有可能根據實現開發情況做少許改動，而且也給我們一個例子看， 可能參考該例子來做； 在統一講需求時雖然聽起來明白了，但做起來會發現很多關節的細節沒考慮進去，而這些細節往往會影響到開發的速度， 甚至看駢符合了文檔的需求，但卻不符合負責人或者說是客戶的實際需求;因為文字類型的需求是比較抽象，特別是要做用戶界面， 雖然有例子，但也只能參考，不能照搬也做，這樣做出來的程序很多情況下只符合程序員自己的需求； 已經花了很多時間去做一個可能不需要的功能，如我當時做一個日歷控制項來顯示排班信息，且也接近交貨日期了，到時交到負責人手裡時才發現，這個日歷控制項不是必要的，選擇的時間范圍是在彈出窗口裡，且不保存到數據...， 這時發現做了很多無用功，又要加班加點去趕進度了。雖然這只是一個小例子，但相似的例子在前幾個月里已經發生過幾次，為什麼呢，因為表達能力差，也不善於與人溝通。可以利用日事清管理工具來溝通，把想法寫出來。然後@給項目負責人。不用直接面對，效果不錯。