基本沟通模型包含五个基本状态：已发送，已收到，已理解，已认可，已转化为积极的行动。这中间每个状态都比前一个更难。
　　1.已发送（Transmitted）：当你发送一封电子邮件或者留下一个语音电话留言，你正在传送信息给他人。这并不表示对方已经读取或听到了，电子邮件和电话也只是帮助我们快速传递信息却不能保证对方准备读取它。这仅仅是信息已发送的状态。
　　2.已收到（Received）：当对方检查新邮件或者打开语言留言的时候，信息已收到。但这并不表示对方有任何意图去读取、理解或解决电子邮件中的问题。换句话说，对方收到电子邮件，仅此而已，没有任何问题已得到对方确认。
　　3.已理解（Understood）：正确的消化和理解信息中的内容是简单接收信息中关键的一环，通常理解需要一定的上下文背景知识，需要对其中某些内容提出问题，或向发送者进行确认或澄清等步骤。
　　4.已认可（Agreed）：理解了传达的信息并不代表对方已同意这个观点。或许对方明白了你的意思，但完全不同意或者认为这是个糟糕的主意。所以在两个聪明的有主见的人之间达成一致是一项复杂而又消耗时间的事情，尤其是两个人的观点又都不能非常明白清晰的向对方阐述的时候。尽管如此，达成一致仍然是做出项目决策和有效沟通的关键一环。
　　5.已转化为积极的行动（Convertedtousefulaction）：尽管正确的理解和达成一致的认可是多么的困难，更加困难的是让对方转化为实际的积极的行动，而且是方向正确无误的行动。这是整个过程中最难的一环，通常需要反复的沟通、一定的监督或帮助下才能较好的完成。
　　所以每次当你发一封电子邮件，或来到某个组员旁边谈话的时候，这只是一个沟通的开始，你可以使用这个沟通模型来帮助诊断为何你想要组员做的和组员实际做的不一致，沟通中出现了什么问题，都可以参考检查这个模型的哪一步出现了问题。
　　项目经理常见的沟通坏习惯
　　　沟通失败有很多原因，每个项目经理都必须熟悉这些原因、了解其中的行为、并且有责任避免沟通失败的发生。在一些团队中，会产生失败的沟通、失败的项目是因为团队经理本身的坏习惯行为或者他本人容忍组员有些行为，而这些行为和坏习惯无意中会导致沟通的失败。直到某一天，上层介入并把项目失败的原因定格为隐性的沟通失败的原因，才会发现这些导致失败沟通的坏习惯。下面列出一些项目经理常见的沟通坏习惯并给出了一些建议：
　　1.假设（Assumption）：当你来到某个组员的桌子旁边并问他为什么还没有发那份重要的E-mail的时候，你已经假设：a）他知道他应该要发；b）他知道什么时候他应该要发；c）他理解应该要发什么内容；d）他知道他发了以后要通知你。在你质问这个组员为何没有发那份E-mail之前，如果是良好的沟通你首先应该澄清这些假设：“小王，那封E-mail你发了吗？”“哪封？”“小王，记得昨天我们在大厅谈论的事情然后你确认你会做这个事情的吗？”“哦，是的，我刚刚在一分钟之前发了。”良好的沟通习惯需要首先澄清对沟通关键点的假设，比如上次沟通时间地点内容，以及再次和对方确认期限等。
　　2.缺乏澄清（Lackofclarity）：你自己已经理解的东西并不能代表对方就能马上理解，或完全透彻的理解，认知需要建立在实践基础上，并且需要一个过程。比如你已经研究了一份文档一个礼拜，然后和一个组员去讲里面的东西，组员不大可能理解你所要表达的东西。因此，失败的沟通往往想当然的认为对方应该会很容易理解自己的意思。良好的沟通习惯是首先注意到这个认知的差异，注意在沟通中把自己的意思分段、慢慢的、浅显的表达给对方，或者利用示意图进行阐述，理解了第一段再进入第二段，直到对方粗略的理解了你要表达的大概意思为止。
　　3.没有倾听（Notlistening）：不善于倾听是一个坏的沟通习惯，你往往比较喜欢讲话，或者喜欢听自己的意见，或者假装倾听，其实根本不想听对方在讲什么，而在准备下句话如何驳倒对方的话！良好的沟通习惯是善于倾听，给对方双向沟通的机会，而不是不让对方发言，有时候组员不是不想讲项目中的问题，而且没机会讲。你应该真正的倾听，而不是心不在焉，对方和你讲问题，你一边在低头看电子邮件，等于是和对方讲：“你现在和我谈论的问题对我根本不重要”，这样下次对方就不会把问题反馈给你了。这其中的关键点是：作为项目经理，你必须承认和意识到这样一种可能性，那就是有些重要的问题可能别人知道了，而你不知道，你的目标不是把你的意志强加给组员，而是实现整个项目的成功。
　　4.下命令（Order）：下令式的沟通不是沟通，比没有倾听更糟糕，根本不给属下质疑或提问的机会，或者你的表情和神态表现的让属下以为：“我如果提问肯定被认为是愚蠢的。”这种命令的做法完全违反了沟通模型，根本无有益与属下对沟通内容的理解和认同，其结果只能让属下无所适从的就去做事了。即使属下明白工作内容，对下命令的做法也会产生抵触情绪，因为不是很服气；要让员工佩服，除了需要丰富的资历和技术和能力以外，还需要诚信和人格魅力，所谓用人的关键是育人，用人之长，容人之短，用人不疑，疑人不用，其关键是要有容人和培养下属的胸怀，给下属不遗余力的帮助其成长，而不要害怕被取代，在信任的前提下放权和育人，这样才会收到最佳的沟通效果。从技术角度来说，如果项目经理技术不精通、资历不丰富、业务不熟悉的情况下，没有convince下属却用职位来压人，这种下命令的做法员工忍得了一时，忍不了长久。从管理角度来说，项目经理的主要工作不是下命令，而是通过沟通协调获得问题的解决。当然，不是不可以命令，命令可以用在特殊的场合和例外情况。
　　5.对人不对事（Personalhominemattacks）：通常我们应当遵循对事不对人的原则，相反则是不良的沟通习惯。例如，一个组员对分配的任务可能会说：“我没时间。”然后项目经理说：“这就是你的问题了，我怎么感觉你从来都没有时间呢”。听到这句这个组员肯定要反驳，因为他不仅要解释项目上的事情为何导致他没有时间，还要解释他的个人行为的问题，并且还会产生抵触情绪。因此，项目管理中尽量遵循对事不对人的原则，不针对个人说三道四，时刻记得项目经理的目标是要事情的最终解决和项目的圆满完成。　　
　　6.动机不正确（Wrongintention）：不是为了关心下属，了解下属而去沟通，而是“为了沟通而沟通”，为了施加个人影响力而沟通。这是最后一点，也是最致命的一点。管理中讲究“知人善用”，“知人”是指领导应当非常了解团队成员，从能力、技能、性格甚至到家庭和爱好等等；”知人“才能发现人才，发现人才比培养人才（育人）重要十倍乃至一百倍；“善用“是指要使团队成员扬长避短，相互协作，并通过激励方法使得达到团队最大战斗力。所有这些管理的行为和目的的达到都离不开行之有效的沟通，而真正有效的沟通是建立在真正关心的基础上。比如了解团队成员，只有你沟通的出发点是真正关心和为成员着想，建立友谊和信任，才会真正了解一个人。再比如激励，只有你真正想到这位成员现在要的是什么，是利益驱动的物质激励、还是个人能力提升的期望、或是想获得更多的机会，只有想之所想，才会获得沟通和激励的最佳效果。管理的关键在管人，而管人在用人，用人的关键在育人，育人就是要善于发现，倾情呵护，从容包容，慷慨使用，育人除了要有容人的胸怀以外，还要有助人的品行，这是属于做人、道德和人格魅力的范畴。所以沟通中最难做到的一点就是沟通的动机本身不正确，这是超越沟通技巧的东西，好比一种病是不能够用药来医的，那就是心病。沟通中需要大家特别注意。
　　7.项目经理自己不爱沟通（Notleadingbysample）：项目经理自己不爱沟通，喜欢埋头干活，遇到状况了才沟通，而不是主动沟通或走动沟通管理，这样会给团队成员构成很不好的沟通榜样。项目经理应该在沟通方面起到表率作用，项目经理一定要有积极的沟通欲望，从而才有可能带动团队的沟通，如果项目经理不渴望沟通协调，遇到问题也自行解决，那这个问题就比较严重了。
　　增强沟通质量的方法
　　精简团队规模
　　在《人月神化》中提到，需要协作沟通的人员的数量严重影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果。人与人之间必需通过沟通来解决各自承担任务之间的接口问题，如果项目有n个工作人员，则有n×（n-1）/2个相互沟通的路径，沟通消耗相应大幅增加。
　　由此可知，一个人单独开发一个软件，人均效率最高，只可惜大部分软件规模和时间要求都不允许一个人单独开发，而团队开发的沟通消耗却呈二次方增长。所以，项目团队应该尽可能精简，以较少的人在最可能允许的时间内完成任务是相对高效的。
　　提升团队人际关系和默契程度
　　一个经过长期磨合、相互信任、形成一套达默契的做事方法和风格的团队，可能省掉很多不必要的沟通，相反，初次合作的团队因为团队成员各自的背景和风格不同、成员间相互信任度不高等原因，要充分考虑沟通消耗。软件企业人员流动率高的特点导致团队凝聚力和默契度的锤炼比较困难。而凝聚力和默契度的需要长期的、大量的内部沟通和交流才能逐步形成，由此不难理解持续良好的沟通和交流是一个团队的无形资产，自然，稳定、默契的开发团队形成一个软件企业的核心竞争力的道理。
　　提升员工的积极性，加强团队文化建设对增强沟通质量也非常有效。在上下级之间，如果只有命令，没有交流，必然导致领导者的独裁和团队成员积极性的丧失。糟糕的团队沟通就像宇宙的“黑洞”一样，会将团队成员的能量和热情吞噬殆尽。与之相反，顺畅的团队沟通则有如温暖人心的艳阳，为团队成员提供源源不断的能量，帮助他们高效地完成工作。
　　明确角色分工和接口定义
　　上节说到，良好的团队关系和默契程度能大大提升团队沟通质量，而明确清晰的角色分工是最简单的方法来提升人际关系。《高效人士的7个习惯》作者StephenCovey认为：“几乎所有的团队关系紧张源自对角色或目标的模糊期望。”
　　明确的个人分工和接口定义可以减少交流。卡内基-梅隆大学的D.L.Parnas认为，编程人员仅了解自己负责的部分，而不是整个系统的开发细节时，工作效率最高。一种行之有效的方法是改变沟通的结构和方式。可以参考微软的MSFTeammodel。