文/阿朱

我们工作当中处处需要协作，协作必然需要沟通。沟通和协作的重要性大家都知道，我在这里就不赘述了，直接切入主题。我就给大家讲几个团队协作沟通过程中的常见问题与解决方法。

如何带新人

老板不可能让一个团队都是熟练手和高手。那样成本高，而且这些成熟手工作资历都差不多，凝聚在一起是一股很有实力的团队，但一旦土崩瓦解也是相当快的，这样就会对公司正常运营带来很大的影响。

所以，我们每年都会扩招应届毕业生，让团队呈阶梯状。这样在管理上也容易。试想，如果呼拉一下子涌入一大批应届毕业生，大家刚开始都一个职位差不多的工资，但是过了一年，肯定要有一些人升上去、一些人原地踏步。在企业，特别出众、大家都很心服口服的人算是比较特异，这类人也比较少。大部分人都是差不多能力。可能有人更细心一些，更刻苦一些，更负责任一些，于是就升上去了。但是，过去同一级别一起来的，这时候就有人埋怨：“他何德何能就比我们工资多职位高，还管我们？肯定是人家会拍领导的马屁合领导的胃口”。很多流言都有，工作自然难以开展。

所以，我建议大家在招聘的时候，年龄、资历阶梯化一些。新人不要进得太多，或者新人不要过于集中在同一部门，否则隐藏的危机很大。业务扩展实在太快，也得掌握一下节奏，少量多批次的入职。阶梯化后，老人走，新人来，企业才会持续经营。

新人来了，我们是师傅制的引导。师傅不是一个职位，和工资也不挂钩。以后也不一定一直会是这个师傅领导这个新人。这个道理一定要提前和即将当师傅的员工说清楚。否则员工以为他成了小组长了。

师傅要负责新人在试用期的工作安排、学习、代码检查、开发中使用的框架讲解，还包括公司的行政人事财务等规章制度、企业文化、公司注意事项，以及试用期结束时对新人的评价。

一个新人，来到陌生的新环境，企业真实是什么样子，到底是怎么个工作方法，怎么快速融入现在的工作内容中，怎么和现有团队快速磨合，人力资源部门是不可能做到这么深入和细致的。每个公司都有挂在墙上的制度，也有行走在日常行为中的潜规则，有个师傅带着，新人就不觉得孤单茫然，而能很快融入。没有师傅带着，新人们会自然集结成一团，那么每进入一批新人，新人就抱成一个团，那公司就成了一个个的利益团伙，真成乌合之众了。

如何与高手打交道

这个也是很常见的一个问题。一个团队肯定会有一个或几个出众的技术能手，承担着软件开发的核心编码。最常出现的问题就是高手因资历和能力强，觉得自己很可以了、自己是不可或缺的，所以对其他团队成员脾气暴躁、傲慢、训斥、耻笑。但{jd1}不能纵容这种情况的发生。因为大家都在一个团队工作，大家都是员工，凭什么就要听你这个所谓的大牛吆五喝六的？如果团队主管睁一只眼闭一只眼，一味捧着，每每开绿灯，而大牛还觉得自己是应该得到的，那其他员工就会觉得太不公平。如此一来，这个主管就连一个支持者都没有了。

不管是有人问我如何管理现在已经牛气冲天的大牛，还是如何除掉手持核心整天哼哼唧唧的大牛，我想说的方法就是一个：分工。

一个软件的开发，功能设计谁来做？整个过程的计划、分配、推进、异常解决、报告谁来负责？数据库设计谁来做？UI设计谁来做？质量谁来保证？文档谁来做？……只要把软件生产整个链条分解成若干个环节（当然需要根据手头的人数和人的能力来划分需要多少个环节），每个人负责自己其中的一环，项目经理主管计划与推进，那么每个环节都是成功的必备环节，但又不至于成为生死悬于一线的环节。

这样，才能成为团队。就如同CS游戏一样，有人掩护，有人冲锋，有人扔雷，有人守卫。团队就是这么来的。

如何与上层沟通

与上层沟通不难。难的是，上层如果是老板，那就比较难。因为如果上层也是职业经理人，反正大家都是打工，从老板意义上来说都是公司员工而已。那这样的沟通大家都没有多大问题。大家最头疼的，也都是和老板的沟通，而且老板很有可能还是你的直接上级，但老板基于客户、销售、工资、公司流动现金压力、“画大饼”、士气、老板自己的小算盘等等很多因素，老板不会全盘托出。当然，老板决定一个人的去留，一个人的职位升迁和工资增降，员工也拿不准如何和老板通畅沟通。于是，察言观色成了必修课。有的人还觉悟不高，观察不出来，琢磨不透老板到底想要什么，那工作就被动了。

这是很多技术出身升为管理职位后的经理们面临的{zd0}问题。我也处理得不是特别好。但我有几个感悟和大家分享一下：

1.老板也是人。这个心态大家得理解。老板不是英明神武。他也有许多事情判断不准确，他也有他的孩子老婆老爹老妈，他也是从上大学给人打工出来的，他也在Down电影聊QQ，只不过不让你看见而已。如果你心态能这么放，那就比较好互相谅解了。有的人，一见到老板就不知道手该放哪里，蹭地站起来，惶恐地看着等待吩咐。这种心态很容易露怯。管理者要在危难之际显身手，现在面对老板都诚惶诚恐，有了突发事件还不得脑袋空白？

2.老板是用人也疑、疑人也用。首先把自己的心态降一降，别期望你用我就得用人不疑。这样的期望值就太高了。俗话说千里马常有而伯乐不常有。在一个公司，你尽管有抱怨，但你毕竟现在没有离职，那必然有你留下的原因。既然在，就要面对，要接受，不接受也得接受，否则你走。可能走的地方多了，你也会接受这就是现实，只不过我们不甘心接受而已。既然如此，那么我们就做好计划、做好报告、勤报告、说明来龙去脉。你越不让老板放心，你就越得不到资源。越得不到资源，做事越困难，显得你也越没本事。所以，得主动让老板放心。老板看不看是老板的事，你写不写是你自己的事。孰重孰轻，咱们都知道。

3.不要把问题推给老板。老板不是救火队员，人家是老板。人家找你来给你工资就是让你解决问题的。你把问题报告给老板然后等着老板解决，这就是你的能力问题。正确的方法是把下列细节说清楚：事情原委；你的担心；你分析后认为可能会出现哪几种结果，哪种对我们有利，我们如何做，需要什么资源做，需要什么其他部门配合做比较合适？老板要的是决策与重组资源，而不是老板自己想着怎么解决。不要给老板问答题，要给老板选择题。

如何做好售前与售后的协作沟通

研发和销售的矛盾历来已久。销售为了签单，不能做的经常都答应。但研发是执行落实部门，做不了的肯定不能嘴上过过瘾就OK的。怎么办？

为了让售前与售后不至于落差太大，就必须有研发人员参与到跟单过程中。

研发人员一般在售前会参与这几方面事情：

1.客户需求讨论。

2.客户方案——技术方案部分制作、开发工作量与开发计划部分制作。

3.客户软件演示与问答讨论。

研发部门派出的人员一般都是项目经理，未来会接手这个项目的开发工作。客户到底想要什么？什么业务问题适合用软件解决？什么业务问题用什么方法能够比较好地解决？解决周期大概多长？解决复杂度、难度、成本、人力到底多大？

只有商务经理和项目开发经理一起从头到尾的参与，双方才能达成一致，评估出这个项目的真正难度、周期、所需人工。而最终的报价，就是建立在这种综合考量基础上的。

而售后部门，一般会抱怨软件怎么这么难用，怎么这么多Bug。所以，研发部门会有两个角色来对售后部门进行支持。一个是测试兼技术支持，另一个是文档员。

原因是版本在不断升级。版本的特性来自于很多部门，有的来自于客户，有的来自于客服支持，有的来自于销售，有的甚至直接来自于老板。为什么要这样设计这个功能，是为了满足谁的需求？特性多了，版本多了，连售后实施部门的人也不清楚了。

谁能对软件现有版本有比较深刻的理解，那肯定是研发部的人。而研发部一般不想打乱程序员的开发进程，而且程序员的思维风格和实施人员差异挺大，所以研发部门就派出文档人员在每个版本发布之后，进行版本新功能的培训。而且软件文档写得实用不实用，阅读习惯是否容易理解，在这一环节都会得到检验。所以，研发部门文档人员来做新版本内部推广与培训是{zh0}不过了。一方面校验了文档的质量与水平，另一方面更能加深文档人员对产品细节的理解，从而写出更实用的文档。

技术支持也同样。一般服务部门解决不了的问题，属于深层次的技术问题，需要求助于开发人员。这也会打扰到开发正常计划进程。那么由测试人员兼任技术支持。一方面，测试人员为了深度测试，他熟悉产品的很多细微之处，解决问题就快。另一方面，在实施阶段或客户使用阶段才暴露出问题，说明是当初测试的不严格，到底为什么会出现这样的情况，测试人员通过这种支持也会得到反思，以利于后续做更专业的测试。

如何与客户做好协作沟通

客户往往是业务人员，不了解IT，也不了解问题的解决成本。他只想完成他的工作，其余的他一概不想知道，你给他的解释他也听不懂，只是催促你赶快做完。这种状况下如何做好沟通？

我们仍然要使用专职的项目经理来解决这个问题。在项目启动会上，项目经理要说明这个项目的目标、周期、难点、我们的工作方法、双方各自的配合角色、容易出现的风险。这就让客户有了一个预期。原来软件不是安装后就用这么简单，有这么多复杂辛苦的事情要做。而且大家也有了共识的工作方法。大家方法一致，才不会出现鸡同鸭讲。

在这样的基础共识上，每周的工作计划，细化到每半天，落实到每个人，包括客户方的每个人的工作责任、事情。每天日报、每周总结与检查、微调、下周计划等。

每次开会，我们都要留下会议纪要。会议的主题是什么，参与人是哪些人？每个分主题，每个人的观点是什么，{zh1}大家的讨论结果是什么？这都要记下来，否则极容易出现说了不算、算了不说的扯皮事情。

有了这么多过程文档，就要及时群发邮件给项目组的各个人，尤其是双方的老板。做项目，我们往往称为一把手工程。没有{zd0}领导方的支持，项目中出现的客户内部各个业务部门互相斗争扯皮，经常会影响业务功能假需求、软件不修改完不能上线、软件流程被修改得面目全非十分怪异、反复培训都不会的难题现象。

虽然每个项目都会有许多异常和磕磕碰碰，但大家都是一路走过来的，理解了整个来龙去脉，大家都知道已经尽力了。这就OK了。

我在这篇文章中只是以研发部门为中心，上下左右，介绍了与内部、与老板、与销售、与售后、与客户各个利益方的协作方法。其实是有一整套组织结构、职能分工、过程管理、考核监督的方法论的，限于篇幅这里只能点到为止，详细细节大家可看《走出软件作坊》。

作者简介：

阿朱，本名吕建伟。《走出软件作坊》一书作者。10年以上商业软件从业经验，10余年来一直专注行业管理信息化领域，7年职业经理人生涯，在商业分析、产品体系规划、研发人才体系搭建、研发过程管理、技术架构、贯通售前\研发\售后方面有多年经验。