在本文中，主要讲述在软件开发项目里，项目经理–开发者–测试者–客户之间的微妙而又重要的关系。产品的质量需要开发团队和客户双方协作才能完成。

经常遇到在软件开发里各种各样的误解所导致的奇怪事情。不过说来也很费解：对于这样不正常的待遇，尽然很少有人提出质疑，也没有人问开发者是什么导致了误解和交流上的障碍。可能大部分人都觉得问这样的问题为时已晚或者没人关心这样的问题。所以，跟踪调查软件开发里开发者之间引起误解的来龙去脉是一件很有趣的事情。

因此，下面就围绕对开发者和项目经理的采访来探讨在开发项目里导致误解的普遍性原因所在。根据这些经验丰富的IT技术人员所说的，一起来学习并避免这样的事情出现在自己的开发团队里。

和客户端：交流没有最多，只有更多。

文档和记录

能够说客户的语言并理解客户的意思其实是特别重要的，理解不一致难免会出现问题。比如：因为语言不一致，导致双方的程序员在技术层面上无法完全理解使用说明规范。

有的时候客户拒绝编写任何文档也会引起开发者的误解。因为我们的开发团队要对产品的功能性进行多个测试、评估，还要不断地多次重写功能代码，团队里每个人对产品功能都有自己的见解，因此，花费在迷茫上的时间不在少数。其次，没有功能说明书的前提下测试人员也很束手无策，根本不了解这些功能是怎样运行的，也没有文档可参考。这些都难免会引起误解。

另一个产生误解的源头是信息不完全。例如：客户和开发团队的成员交流产品细节，客户希望开发人员将数据分类，而不是在Skype上进行群组交流。有经验的人都会知道，客户在和开发者之间的误解肯定会涉及到工作完成的标准与否。这也就是为什么有人觉得定价的服务项目对双方都不利。因为它是不可能将所有可能的产品描述写入产品验证的。对于这类问题，解决办法总是有的。

信任、开放的态度

当客户不信任开发团队的时候，采取闭门会议、给出一小部分信息的话，那障碍就会出现，最终的结果只能是重写代码，重设架构。在一个团队里，如果没有信心，即使是正常的开放式交流也对高效率和创新性毫无裨益。没有一个团队会把于己无关的项目放在心上。有的时候，客户只给出模糊不清的需求，任何人都可以想象得到，开发团队为了获得更详细的信息多多少少都会和客户产生一点小分歧乃至是小冲突，直至造成更大的误解。

目标清晰、详细阐述

当交流进程失败了，只能面对下面的情形：

客户会给出一个评估任务并找到一个实现方法，但团队开始开发而不是仅仅发送一个报告而已。
开发团队在实现阶段也要和客户进行协作，可能会出现的情况是客户根本不选择你所提供的解决方案。
有的时候开发者开始处理一个指定的bug，即使严重的功能改变可以保证性能的提升，但是客户还是不同意你的做法。

个人认为，误解的出现主要是对问题没有做充分的讨论，懒惰、时间紧、外语障碍都是阻止寻求建议的主要因素。所以，解决误解的关键就是不管什么事都要和你的团队、项目经理、客户进行讨论。

及时反馈信息

有时候客户不重视用户评论，或者是忘记将这些用户评论传递给开发团队，这也就导致开发者没办法即使关注产品的反馈信息。误解就这样产生了——因为在项目结束之后，客户需要重新开发/调整项目，是的双方都不是很满意。

不同的加班理念

也许客户和开发团队在加班这件事上会存在理念上的不同，客户需要开发团队在没有真正必要性的事情上加班，例如：

客户：在产品发布之前，我们每周都会加班一次，所以希望开发团队也尽可能的抓紧时间按时完成任务。
开发：长时间的加班会打击团队的积极性，降低工作效率。

对于加班这样的误解，最简单实效的办法就是双方之间做出真诚的协商，给对方吃一颗定心丸：绝不会延缓进程、影响产品质量。

小结

交流，交流，再交流，而且是双向交流！客户尽可能多的列举细节，开发团队得到的完整而清晰的信息有助于更好的理解项目的目标，对项目的圆满完成不无益处。通常情况下，为开发团队提供全面的反馈信息，也不滥用不必要的加班时间，有利于双方创造一个和睦的工作氛围。

团队VS.项目经理

在有的开发团队里项目经理根本不会就客户的需求去和团队进行有效的沟通。例如，有可能会出现这样的情形：项目经理在和客户主导一个讨论会议，而团队里的主要人员却在蛮干，这就是为什么信息最终不能被团队全面接收的原因。

首先呢，交流误解出现在项目经理和他的团队之间，这的确是一个让人失望的案例，因为项目的日程安排、截止日期、和客户的信息传递都是由项目经理定义的，目前这样的问题带有个人原因，所以解决方法就是项目经理需要更多的自我反思，寻求出路。

小结

努力遵循敏捷开发的方法，千万不要忽略常识和人性特点。

开发者VS.测试员

世上没有相同的两个东西，所以出现在开发团队和测试团队之间的误解，大部分是原因是需求过于模糊。为了克服这样的难点，建议两个团队需要加强更加紧密的协作：

在文档开发过程里
在架构/数据库工程里使用QA环节
在测试案例开发中邀请开发人员加入

通常情况下，在开发项目里任何形式的误解都是一个大麻烦。它可能是缺乏良好的管理、缺乏团队建设、失效的软件开发方法、未定义标准等等。每个交流误解案例都应该仔细分析，并单独处理。

小结

在开发者和测试者之间的误解代价是最高的，所以避免这样的误解需要双方之间透明工作细节以及有规律的刷新文档，或者是双方之间更亲密、永久性的交流沟通。尤其是在项目计划的后期。除此之外，开发团队必须清晰地意识到QA环节的重要性，还要考虑到和测试者是一个整体团队，对产品负有共同的责任。

沟通工具：语音聊天工具（Skype）VS. E-mail

考虑到敏捷开发方法里所追求的速度与效率，E-mail的特点是有较高的延迟性，所以不可取。所以对于集思广益的讨论需要向Skype或其他的多媒体工具。但是，我建议项目经理能够鼓励开发者多写邮件，这样可以锻炼他们用一个干净和简洁的方式表达自己的想法，所以很多事情通过他们的邮件就可以解决了。不过在开始Skype会议之前最好是通过E-mail将要讨论的话题发给大家，包括客户。

毫无疑问Skype能够确保即时沟通紧急情况/议题，而E-mail是储存历史记录的最好工具。这两个沟通工具各有利弊，只需要遵循合理的使用，减少团队误解几率是毋庸置疑的。

总结

在软件开发项目里，对于交流标准需要强调五条规则：

每个环节都要沟通：业务计划、项目目标、财务问题、交付模型等等。每一个技术性能都要彻底的讨论。如果你想呈现什么样的想法，那就通过E-mail文档的方式来证明它。
个性化你的工作。和团队成员交流的时候尽量鼓励大家表现出自己真实的一面，这样有助于激发队员的创造力，做出更出色完美的结果。

持续提供反馈。反馈信息就相当于一面镜子，时刻反映工作成果的好坏。作为项目经理，一定要避免一个现象，那就是责怪队员，因为所有的人都只有一个目标——好产品。
在问题变质之前解决它。突出强调你很想知道摆在面前的所有狭窄的地带。鼓励大家提出疑问！

使用E-mail解决真正重要的问题，这样有助于避免在无关紧要会议上浪费开发者和自己的时间。

作为一名工作经验丰富的管理者，希望以上的内容对IT工作者有用。