我们工作当中处处需要协作,协作必然需要沟通。沟通和协作的重要性大家都知道,我在这里就不赘述了,直接切入主题。我就给大家讲几个团队协作沟通过程中的常见问题与解决方法。
如何带新人
老板不可能让一个团队都是熟练手和高手。那样成本高,而且这些成熟手工作资历都差不多,凝聚在一起是一股很有实力的团队,但一旦土崩瓦解也是相当快的,这样就会对公司正常运营带来很大的影响。
所以,我们每年都会扩招应届毕业生,让团队呈阶梯状。这样在管理上也容易。试想,如果呼拉一下子涌入一大批应届毕业生,大家刚开始都一个职位差不多的工资,但是过了一年,肯定要有一些人升上去、一些人原地踏步。在企业,特别出众、大家都很心服口服的人算是比较特异,这类人也比较少。大部分人都是差不多能力。可能有人更细心一些,更刻苦一些,更负责任一些,于是就升上去了。但是,过去同一级别一起来的,这时候就有人埋怨:“他何德何能就比我们工资多职位高,还管我们?肯定是人家会拍领导的马屁合领导的胃口”。很多流言都有,工作自然难以开展。
所以,我建议大家在招聘的时候,年龄、资历阶梯化一些。新人不要进得太多,或者新人不要过于集中在同一部门,否则隐藏的危机很大。业务扩展实在太快,也得掌握一下节奏,少量多批次的入职。阶梯化后,老人走,新人来,企业才会持续经营。
新人来了,我们是师傅制的引导。师傅不是一个职位,和工资也不挂钩。以后也不一定一直会是这个师傅领导这个新人。这个道理一定要提前和即将当师傅的员工说清楚。否则员工以为他成了小组长了。
师傅要负责新人在试用期的工作安排、学习、代码检查、开发中使用的框架讲解,还包括公司的行政人事财务等规章制度、企业文化、公司注意事项,以及试用期结束时对新人的评价。
一个新人,来到陌生的新环境,企业真实是什么样子,到底是怎么个工作方法,怎么快速融入现在的工作内容中,怎么和现有团队快速磨合,人力资源部门是不可能做到这么深入和细致的。每个公司都有挂在墙上的制度,也有行走在日常行为中的潜规则,有个师傅带着,新人就不觉得孤单茫然,而能很快融入。没有师傅带着,新人们会自然集结成一团,那么每进入一批新人,新人就抱成一个团,那公司就成了一个个的利益团伙,真成乌合之众了。
如何与高手打交道
这个也是很常见的一个问题。一个团队肯定会有一个或几个出众的技术能手,承担着软件开发的核心编码。最常出现的问题就是高手因资历和能力强,觉得自己很可以了、自己是不可或缺的,所以对其他团队成员脾气暴躁、傲慢、训斥、耻笑。但绝对不能纵容这种情况的发生。因为大家都在一个团队工作,大家都是员工,凭什么就要听你这个所谓的大牛吆五喝六的?如果团队主管睁一只眼闭一只眼,一味捧着,每每开绿灯,而大牛还觉得自己是应该得到的,那其他员工就会觉得太不公平。如此一来,这个主管就连一个支持者都没有了。
不管是有人问我如何管理现在已经牛气冲天的大牛,还是如何除掉手持核心整天哼哼唧唧的大牛,我想说的方法就是一个:分工。
一个软件的开发,功能设计谁来做?整个过程的计划、分配、推进、异常解决、报告谁来负责?数据库设计谁来做?UI设计谁来做?质量谁来保证?文档谁来做?……只要把软件生产整个链条分解成若干个环节(当然需要根据手头的人数和人的能力来划分需要多少个环节),每个人负责自己其中的一环,项目经理主管计划与推进,那么每个环节都是成功的必备环节,但又不至于成为生死悬于一线的环节。
这样,才能成为团队。就如同CS游戏一样,有人掩护,有人冲锋,有人扔雷,有人守卫。团队就是这么来的。
如何与上层沟通
与上层沟通不难。难的是,上层如果是老板,那就比较难。因为如果上层也是职业经理人,反正大家都是打工,从老板意义上来说都是公司员工而已。那这样的沟通大家都没有多大问题。大家最头疼的,也都是和老板的沟通,而且老板很有可能还是你的直接上级,但老板基于客户、销售、工资、公司流动现金压力、“画大饼”、士气、老板自己的小算盘等等很多因素,老板不会全盘托出。当然,老板决定一个人的去留,一个人的职位升迁和工资增降,员工也拿不准如何和老板通畅沟通。于是,察言观色成了必修课。有的人还觉悟不高,观察不出来,琢磨不透老板到底想要什么,那工作就被动了。
这是很多技术出身升为管理职位后的经理们面临的最大问题。我也处理得不是特别好。但我有几个感悟和大家分享一下:
1.老板也是人。这个心态大家得理解。老板不是英明神武。他也有许多事情判断不准确,他也有他的孩子老婆老爹老妈,他也是从上大学给人打工出来的,他也在Down电影聊QQ,只不过不让你看见而已。如果你心态能这么放,那就比较好互相谅解了。有的人,一见到老板就不知道手该放哪里,蹭地站起来,惶恐地看着等待吩咐。这种心态很容易露怯。管理者要在危难之际显身手,现在面对老板都诚惶诚恐,有了突发事件还不得脑袋空白?
2.老板是用人也疑、疑人也用。首先把自己的心态降一降,别期望你用我就得用人不疑。这样的期望值就太高了。俗话说千里马常有而伯乐不常有。在一个公司,你尽管有抱怨,但你毕竟现在没有离职,那必然有你留下的原因。既然在,就要面对,要接受,不接受也得接受,否则你走。可能走的地方多了,你也会接受这就是现实,只不过我们不甘心接受而已。既然如此,那么我们就做好计划、做好报告、勤报告、说明来龙去脉。你越不让老板放心,你就越得不到资源。越得不到资源,做事越困难,显得你也越没本事。所以,得主动让老板放心。老板看不看是老板的事,你写不写是你自己的事。孰重孰轻,咱们都知道。
3.不要把问题推给老板。老板不是救火队员,人家是老板。人家找你来给你工资就是让你解决问题的。你把问题报告给老板然后等着老板解决,这就是你的能力问题。正确的方法是把下列细节说清楚:事情原委;你的担心;你分析后认为可能会出现哪几种结果,哪种对我们有利,我们如何做,需要什么资源做,需要什么其他部门配合做比较合适?老板要的是决策与重组资源,而不是老板自己想着怎么解决。不要给老板问答题,要给老板选择题。
如何做好售前与售后的协作沟通
研发和销售的矛盾历来已久。销售为了签单,不能做的经常都答应。但研发是执行落实部门,做不了的肯定不能嘴上过过瘾就OK的。怎么办?
为了让售前与售后不至于落差太大,就必须有研发人员参与到跟单过程中。
研发人员一般在售前会参与这几方面事情:
1.客户需求讨论。
2.客户方案——技术方案部分制作、开发工作量与开发计划部分制作。
3.客户软件演示与问答讨论。
研发部门派出的人员一般都是项目经理,未来会接手这个项目的开发工作。客户到底想要什么?什么业务问题适合用软件解决?什么业务问题用什么方法能够比较好地解决?解决周期大概多长?解决复杂度、难度、成本、人力到底多大?
只有商务经理和项目开发经理一起从头到尾的参与,双方才能达成一致,评估出这个项目的真正难度、周期、所需人工。而最终的报价,就是建立在这种综合考量基础上的。
而售后部门,一般会抱怨软件怎么这么难用,怎么这么多Bug。所以,研发部门会有两个角色来对售后部门进行支持。一个是测试兼技术支持,另一个是文档员。
原因是版本在不断升级。版本的特性来自于很多部门,有的来自于客户,有的来自于客服支持,有的来自于销售,有的甚至直接来自于老板。为什么要这样设计这个功能,是为了满足谁的需求?特性多了,版本多了,连售后实施部门的人也不清楚了。
谁能对软件现有版本有比较深刻的理解,那肯定是研发部的人。而研发部一般不想打乱程序员的开发进程,而且程序员的思维风格和实施人员差异挺大,所以研发部门就派出文档人员在每个版本发布之后,进行版本新功能的培训。而且软件文档写得实用不实用,阅读习惯是否容易理解,在这一环节都会得到检验。所以,研发部门文档人员来做新版本内部推广与培训是最好不过了。一方面校验了文档的质量与水平,另一方面更能加深文档人员对产品细节的理解,从而写出更实用的文档。
技术支持也同样。一般服务部门解决不了的问题,属于深层次的技术问题,需要求助于开发人员。这也会打扰到开发正常计划进程。那么由测试人员兼任技术支持。一方面,测试人员为了深度测试,他熟悉产品的很多细微之处,解决问题就快。另一方面,在实施阶段或客户使用阶段才暴露出问题,说明是当初测试的不严格,到底为什么会出现这样的情况,测试人员通过这种支持也会得到反思,以利于后续做更专业的测试。
如何与客户做好协作沟通
客户往往是业务人员,不了解IT,也不了解问题的解决成本。他只想完成他的工作,其余的他一概不想知道,你给他的解释他也听不懂,只是催促你赶快做完。这种状况下如何做好沟通?
我们仍然要使用专职的项目经理来解决这个问题。在项目启动会上,项目经理要说明这个项目的目标、周期、难点、我们的工作方法、双方各自的配合角色、容易出现的风险。这就让客户有了一个预期。原来软件不是安装后就用这么简单,有这么多复杂辛苦的事情要做。而且大家也有了共识的工作方法。大家方法一致,才不会出现鸡同鸭讲。
在这样的基础共识上,每周的工作计划,细化到每半天,落实到每个人,包括客户方的每个人的工作责任、事情。每天日报、每周总结与检查、微调、下周计划等。
每次开会,我们都要留下会议纪要。会议的主题是什么,参与人是哪些人?每个分主题,每个人的观点是什么,最后大家的讨论结果是什么?这都要记下来,否则极容易出现说了不算、算了不说的扯皮事情。
有了这么多过程文档,就要及时群发邮件给项目组的各个人,尤其是双方的老板。做项目,我们往往称为一把手工程。没有最大领导方的支持,项目中出现的客户内部各个业务部门互相斗争扯皮,经常会影响业务功能假需求、软件不修改完不能上线、软件流程被修改得面目全非十分怪异、反复培训都不会的难题现象。
虽然每个项目都会有许多异常和磕磕碰碰,但大家都是一路走过来的,理解了整个来龙去脉,大家都知道已经尽力了。这就OK了。
我在这篇文章中只是以研发部门为中心,上下左右,介绍了与内部、与老板、与销售、与售后、与客户各个利益方的协作方法。其实是有一整套组织结构、职能分工、过程管理、考核监督的方法论的,限于篇幅这里只能点到为止,详细细节大家可看《走出软件作坊》。