无主程序员组沟通路径

㈠ 程序员怎么更好的沟通

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#组的人员分配工作， 每人负责一个小模块， 数据库和需求文档已经提供有，但数据库的表字段有可能根据实现开发情况做少许改动，而且也给我们一个例子看， 可能参考该例子来做； 在统一讲需求时虽然听起来明白了，但做起来会发现很多关节的细节没考虑进去，而这些细节往往会影响到开发的速度， 甚至看骈符合了文档的需求，但却不符合负责人或者说是客户的实际需求;因为文字类型的需求是比较抽象，特别是要做用户界面， 虽然有例子，但也只能参考，不能照搬也做，这样做出来的程序很多情况下只符合程序员自己的需求； 已经花了很多时间去做一个可能不需要的功能，如我当时做一个日历控件来显示排班信息，且也接近交货日期了，到时交到负责人手里时才发现，这个日历控件不是必要的，选择的时间范围是在弹出窗口里，且不保存到数据...， 这时发现做了很多无用功，又要加班加点去赶进度了。虽然这只是一个小例子，但相似的例子在前几个月里已经发生过几次，为什么呢，因为表达能力差，也不善于与人沟通。可以利用日事清管理工具来沟通，把想法写出来。然后@给项目负责人。不用直接面对，效果不错。