## 2.2　与你的团队沟通 成功的沟通需要你考虑讨论内容以及在开始谈话以前怎样去说。你所做的沟通应该针对每一种情形做相应调整：要知道在一个环境中奏效的事情未必能在另外一种情形中起作用。 与你的团队沟通时，要计划涵盖项目工作与人员方面的话题。项目工作要包括增加收入、降低项目风险、提升生产率的策略等开发涉及的方面。人员方面的话题应包括指导、培训、矫正错误、答复问题、化解忧虑、讨论长期问题和新观念、工作上所需的帮助以及职业规划帮助等。 通常，管理人员只侧重项目工作，针对当前那些推动公司短期成功的实际问题。然而，沟通时不能不涉及其他可能会导致降低生产效率、增加人员流动、质量问题、失去机会以及降低积极性等问题。至少要花1/5以上的沟通时间跳出当前项目来谈问题。要考虑到项目相关问题与员工个人相关问题间沟通方法的不同；每一种沟通方式都需要相对应的场合以确保沟通能正确解决相关问题。下面的章节讨论了与你的团队沟通的方法，包括一对一、项目沟通、团队会议以及非正式谈话。 ### 2.2.1　一对一 一周一次与个别开发人员举行一对一例会给经理们提供了最好的机会来讨论大部分人员问题。（相对而言，团队建设则需要通过团队会议来发展员工间友好关系并增强相互配合。）如果你的团队多于6人，鉴于时间关系，你可以隔周搞一次一对一例会。 一对一例会提供了建立信任感及倾听个人观点的机会。让员工来引导最初的讨论。交谈初始避免讨论当前任务及所面对的问题。有时，开发人员并不知道如何开头，你可以通过询问如下问题作为开始。 * 你对你的工作有何忧虑？ * 近来遇到问题了么？ * 你有改进想法么？ * 你需要增加设备和软件么？ * 你的长期职业规划是什么？ * 你有可分享的想法么？ 一对一的会议非常适合讨论问题、提供建议、商定问题的解决方案以及分配任务或要求针对某一问题提供解决方案。任务分工要明确，但是要避免对解决方案阐述得过于详细。相反，应该像这样成功地达成一致意见：给员工解决问题的授权，并提供建议。总的来说，不要立即将解决问题的任务分给提出问题的人。如果你习惯这样做，你的员工将不会再提问题来引起你的注意。 > 不去倾听 > 在我职业生涯的早期，我的老板是一个不愿意倾听的人。当我带着问题找他想知道下一步如何处理时，他会打断讨论并开始给我下指示。他总是在我说清楚我能解决的问题之前发布命令。我后来就不再跟他讨论问题了。 > ——软件经理 如果你想利用一对一会议推进项目进程，就要等到把别的话题讨论完再进行项目状态讨论。如果你开始讨论项目情况，将会耗费你全部的会议时间而其他问题不再会引起你的注意。 ### 2.2.2　项目沟通 你如何举办项目沟通取决于项目规模以及发布周期。项目发布周期较短时，每日站立例会——所有参会者站着开15～20分钟会议——可能比较合适。经理每天同一时间安排会议，要求参会者就前一天的进展、今天的计划以及需要的紧急求助做简短陈述。站着开会不是为了解决问题或讨论话题。相反，任何发现的问题可以落实到具体人员去解决跟踪。 对于发布周期较长的项目，每周一次的项目状态例会，同时结合走到同事的办公桌前与他们交流讨论的方式，可能比较有用。这个周例会通常30分钟～1小时。项目状态以及日程安排会议通常要包含一些细节讨论，除此之外还应包括下几周的计划。也应包括团队发现的一些风险以及项目经理指派一些人共同来应对并减缓那些风险。 你也可以凭借企业内网/维基（intranet/wiki）发布通告、电子邮件、白板通知或正式评审会等方式与你的团队进行项目沟通。一些项目成员不是总会知道整体项目状态或最近的项目或时间表变化。不与团队沟通整体状态可能导致混乱，而清楚地传达这一信息不仅可提升工作积极性还可以提高项目成功的可能性。如果你为你的团队提供正式的项目进展信息，他们会更愿意在早期指出问题和差异，而且他们也愿意把他们的进展状态报告给你。 与团队进行进展状态沟通时，要根据工作量的大小规范报告的内容和频率。项目进展状态描述应该包括近期已完成的工作、下一阶段要解决的问题、产品已修改的功能、截止到今天的完成状态、遇到的问题以及当前存在的风险。 按时完成项目依赖于准确的进展状态信息，这些状态信息中应包括为项目中途更正留有的时间。 ### 2.2.3　团队会议 定期安排项目会议将增强团队凝聚力并提升团队业绩。团队会议可根据团队的大小每周或每两周举行一次。会议可办成论坛形式用以讨论总体问题或为新流程和政策提供培训机会。团队会议也可以允许团队成员们讨论相关内容或提出问题。 会议不应该是即兴活动，不管怎样，你应该事先准备一个议事日程或主题列表。在你桌面上打开一个文件并保持打开状态，根据大家提到的内容随时增加信息要点条目；这个文件将是下一次会议议事日程的基础。一个确定的议事日程将有助于会议短小并且避免漫无边际的讨论。事先分发议事日程将使会议更有效率。 过长的会议会消耗精力并影响你们的成本底线，所以要尽可能把会议开得短小。长时间的会议也是代价高昂的——如一个12个人的团队耗时2小时的会议等同于3个工程人日（24小时）。 要允许工程师们说出对诸如政策以及高层管理人员决策等问题的忧虑。跟踪这些问题并且每周和团队一起对它们进行评审，即使你们还没有答案。要确认提供了相关问题的进展状态并进行相应的补充，这些问题中既包括先前会议提出的那些公开议题，也要包含正致力于关闭的问题。 有时候，一个有不满情绪的工程师也可能利用团队会议去抱怨诉苦。如果这个工程师跨越了从建设性建议到破坏性抱怨的底线，那么就简短地打断谈话并让他单独和你会面一起讨论他的困惑。 规范的开发小组会议不适合进行细节技术讨论。建立单独的技术会议机制，这样可以把重点放在特定的话题，并使得大多数会议开得比较随意，以便人们不需要都出席并随时可以退出。否则，那些与特定技术主题不相关的工程师们就要花费时间自始至终地来听取对他们没有意义的讨论。