我在中关村的小巷子里开了一家茶馆，但生意甚是冷清。每天太阳一下山我都会关店回家，偏巧要关张时进来了两个儒雅的中年人。我给两人泡了一壶茶，顺耳就听他们聊起了开发管理，听他们说的倒也有理，就记在了自己的小本本儿上。
这两个茶客，一个叫大志，一个叫李铮。大志是个十年开发经验的老工程师，现在管理一个50人的开发团队。李铮也是类似的工作经历，但两年不见，他已经是某个知名公司的CTO了。
两人似乎几年没见，但男人的交情跟见不见面关系不大。双方通报了一下自己的现状，李铮恭喜大志有了个儿子，大志祝贺李铮步步高升。
本来我听着这些俗套想赶他们离开好休业走人，但大志接下来的抱怨让我又有了兴趣。
大志说带50人的开发团队好累，自己一直在努力但总感觉有缺憾。李铮自然要问，现在带团队累在哪里。大志说来自产品部门的需求多的堆积如山，而且做出来的效果和产品需求相差甚远，部门内部也不好管理，每个员工都很尊重自己，但干活的速度忽快忽慢，质量也参差不齐。
李铮又让泡了一壶碧螺春，品着香茗开始和老朋友探讨问题了。
“首先说，活干不完是没搞定需求方，活干不好是没搞好内部”，李铮开宗明义的列出大纲，“接下来的事情很复杂，让我们来画一个流程简图。”
首先，我们来看看需求确认。
大志不是那种强硬的开发经理，于是他的问题就是对产品部门的需求有求必应，好似一个活菩萨了。但大志毕竟不是千手观音，当他手头有一千个需求的时候，他就抓不过来了。所以开发总监第一个要做的是确认产品需求是否合理，合理性包括方案自身的可行性，以及技术团队有没有能力执行这个计划。
先说从可行性上拒绝需求，这个时候我们的角色不是一个开发者，而一个冷静的旁观者。如果没有用户会用这种产品，或者这个产品是一个灾难性设计，那我们应该请产品总监或者公司高管把这个创意直接毙掉。
再就是从本部门的角度拒绝需求。你是开发经理，你最了解本团队能胜任什么工作。如果公司的需求过于苛刻，让我们在资源/规划上无法完成工作，那我们也必须将需求顶回去。
比如说你带领一个通讯开发团队，某天有个客户有需求要求在语音通话过程中混入电子提示音，比如说“您的电话已经拨打了20分钟，请注意休息”。在产品和销售看来，你可以把电话想接通就接通，想挂断就挂断，想监听就监听，想降噪就降噪，这应该不是难事吧。
但你自己知道，接通挂断都是事件性操作，监听是单向复制语音内容，降噪已经有很成熟的技术方案。偏偏这个插入语音提示的需求，看起来很简单，却会涉及事件触发、双方通话变三方通话再切回双方通话、录音合成时去除电子提示音等多个复杂而且生僻的操作。
最后我们拒掉这个需求的理由是技术实现复杂、没足够的人手、会改变现有的稳定结构、市场需求暂不强烈，然后专心致志的去完成那些更迫切的需求了。
第二，我们来看看沟通环节
李铮又提到，就算合理的、在处理中的需求，也经常因为双方沟通不到位而发生南辕北辙的情况。产品人员经常和开发人员说的一句话就是“这不是我想要的”，这话并不是刁难人，我们应该想办法解决这个沟通问题。
首先，我们要让需求提出有一个合理和可靠的流程。如果一个产品经理QQ上一个留言就可以直接调动一个开发小组埋头干活，或者某个开发小组自己就能代表开发部门推掉一个产品需求，那这个公司的管理就太乱了。我们应该让产品部门提交需求时坚持走一套审核流程，保证产品总监、公司高层（可选）、开发总监都审核过才能进行开发；而这个开发需求经过开发总监审核和分配工作以后开发人员就必须能按时保质量的完成。
流程上正确了，剩下的就算沟通问题了。首先产品经理们提的需求要先自己想的清楚写的明白，就是审核需求时能跟公司写清楚这个产品的目的和特点，实施需求的时候能尽量详细的写清楚自己要实现的每个小细节。通篇必须用写作来完成，因为下笔之时人能三思，而脱口而出是不会思考且容易淡忘的。
产品人员写个百万字的说明文档，然后开发照着文档做就行了？开玩笑，新华字典上所有字都是对的，你背过字典就算学会中文了？产品写的说明文档是对自己思路的文字呈现，但他写的东西并不能保证别人能不误解。最常见的举例就算“舟已行二日即到”这个电报了。我们甚至可以说，产品的设计说明我们读的时候必然会有误解！
要避免单项沟通的信息丢失，我们就做信息校验吧。在正式开发之前，开发人员和产品人员要反复开两次碰头会，既要做开发工期规划，也要让产品有时间精修产品计划。最重要的就是双方要相互向对方说明自己听到了什么，开发人员要把产品的需求复述给产品人员去听，双方肯定能发现彼此认知的分歧。
这样的沟通可能要往返三五次，虽然会消耗一两周的时间，但开发能彻底弄清除了产品的需求，产品也认可了开发人员的沟通习惯和职业态度，这样可以节省下好几周给产品修复bug的时间。
大志连声收佩服，原先自己总是想节省时间尽快搞定产品需求，结果每次不是开发方向错了耽搁了工期，就是一周赶工做项目，俩月不停修漏洞。
第三，实施过程中的内部管理
接下来李铮又说起了部门内部管理。李铮认为研发分为三种员工：开发组长、技术牛人和普通开发人员，三类人员的使用方法完全不同。
|
员工类型 |
技术水平 |
责任心 |
执行力 |
沟通能力 |
管理难度 |
支持他人能力 |
对工作要求 |
代表团队负责 |
|
普通开发 |
差 |
待定 |
高 |
未知 |
态度好但能力差 |
无 |
学习机会/团队氛围 |
无需求 |
|
技术牛人 |
高 |
中 |
中 |
未知 |
能力好但有性格 |
中等 |
尊严/待遇/个人价值 |
无需求 |
|
开发组长 |
中 |
高 |
中 |
高 |
既是管理也是被管理者 |
高 |
升迁机会 |
必须 |
现在最大的问题是这些开发组长没当小队长的觉悟，却更愿意当排头兵，经常亲自上阵写大量的代码，结果把普通开发甚至是技术牛人都晾起来了。最后牛人觉得自己不被重视，新员工觉得没什么提升，他自己也在繁杂的开发工作和小队内部管理上累的焦头烂额。我们要引导这些技术带头人将大部分工作量交出去，重点做小团队的负责人。
有了工作分派，我们还要有制度来督促和奖惩员工，监督员工很容易存在公平性疑虑，我们都喜欢正向激励员工但经常苦于权限不够，惩罚员工则大多抹不开面子。
李铮的建议是做一个巨大的白板，上面写上每个员工要在几月几日完成什么工作，能完成就算合格，完不成工作也是任何人都看到的。这个监督机制是公开透明的，是该奖励还是惩罚是显而易见的。
接下来要奖励员工，李铮和大志都申请到了季度奖金，但大志手下鲜有拿不到全额奖金的职工，个别职工拿不到奖金立刻就会认为自己受到了歧视；而李铮的团队只有七成的人能拿到季度奖，还只有少数几个人是全额奖金，整个团队反而没有抱怨奖金的多少。除了季度奖之外，培训、职位升迁、正式表彰、组织业余活动都能很有效的激励员工。
做管理的可以宽容但不可以和稀泥，盲目的一团和气并不会让懈怠的员工心存感激，反而会让积极的员工心怀不满。每个公司可以制定不同的管理制度，但记住有时候惩罚坏员工是为了给好员工一个交代。无论是奖惩都要切记不能做滥好人，奖惩力度太轻会让大家看轻奖惩制度，人人有奖或法不责众也会让制度变成笑话。
第四，不要忽视运维
说到这里大志恍然大悟，激动的要以茶代酒敬李铮三杯，李铮却没着急，他说“我还没说完哪，你们公司的运维人员现在怎么样？”
大志对运维很满意，他说：“我们现在的运维人员就五个人，归我统一管理，有故障总能及时处理，对开发工作也很配合，基本没有提过什么需求……”
“没提过什么需求，那你们的运维也做不了什么事情吧。”李铮抢过话头，“运维太弱势的公司是没有多少运维能力的。”
大志想了想也对，貌似现在的运维只能检查监控、处理硬件和网络故障，真要是应用服务器有什么问题还要靠开发人员提供解决方案。
李铮又谈起了运维和开发的关系，运维人员要对平台稳定性负责，开发人员的每次变更程序都会影响平台稳定性。如果运维太过弱势没有话语权，那就像一个胆怯的卫兵不敢查访客证件一样，根本无法胜任工作。因开发的程序变动导致平台宕机，因程序生僻导致无法监控或很难恢复，因新手程序员的不规范操作导致意外……这些平台稳定性事件一旦出现，运维都可以把责任推给研发，公司也可能会原谅运维和开发。
但是，你是一个管理人员，必须想到在公司看来业务已经中断了。要让运维把工作做好，只有让他们变得强势，这样他们才能担当起自己的责任来；在开发阴影下的运维人员只能做监控值班人员，无法为自己的工作负责。
两个人又聊了一会风月琐事，再也没提和部门管理的事情。等到他们离开茶馆以后，我就把他们说的话都记下来了，原来带好开发团队是这么简单，明天我就把茶馆关了，我也去应聘开发总监去。
本文出自 “让技术做的更清晰” 博客，请务必保留此出处http://caoyameng.blog.51cto.com/4975863/854550