老曹眼中的研发管理二三事

这是在gitchat上的第一次分享，中生代联手gitchat在做研发管理的专题活动，作为先锋，抛砖引玉。

管理就是界定企业的使命，并激励和组织人力资源去实现这个使命。界定使命是企业家的任务，而激励与组织人力资源是领导力的范畴，二者的结合就是管理。

这是对企业管理的阐述，管理是一种实践，其本质不在于’知’而在于’行’；其验证不在于逻辑，而在于成果；其唯一权威就是成就。

而我们多数人不是企业家，更多是基层的管理者，面对的一个或几个小型的组织。尤其是研发管理，这里主要是讨论互联网及移动互联网领域的研发管理。

关于研发管理

什么是研发管理呢？ 研发管理有着广义和狭义的定义，总的来说，研发管理就是在研发体系基础之上，借助信息平台进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等活动。

大道易得，小术难求。 论道容易务虚，谈术又往往让人有支离破碎的感觉。这里只从老曹的亲身感受出发，希望可以做到抛砖引玉。

老曹眼中的研发管理，首先是管理，是在研发领域的管理。管理的是什么？管理的并不是研发，通俗的说，研发管理就是管人和理事。也就是说，是面向人的管理，和面向事的管理， 并且是二者的有机结合。大家经常接触到的是“管理就是管人“，可见人是研发管理中的核心要素。但是研发的目标是“成事“，在于做事的结果。结果导向是一种共识，老板们经常说的就是“我只要一个好的结果“，但是对于基层管理者而言，没有过程何来结果呢？与组织匹配的实践流程可能更容易产生良好的结果。

面向人的研发管理——管人

人不仅是团队中的关键资源，更是组织中的核心竞争力。面向人的研发管理主要指人才培养，管理自己的老板，以及保持团队的新陈代谢。

人才培养的ABC

人是社会中的人，组织是学习型的组织。培养团队中的每个人都要具备ABC。

A＝Attitude，态度

唯一一次带我们闯进世界杯的米卢说过，“态度决定一切”。proactive 是态度的第一要务，不需扬鞭自奋蹄。积极的态度，才能更加主动，内驱力是最重要的特质。拥有遇事积极主动，勤于思考和积极思考的员工，是企业的财富。

“阳光心态”是一种态度，正能量可以使问题简单，使做法纯粹，使我们的产品做到极致。正能量不但可以帮助融化蓝冰，而且可以使我们的团队充满阳光。

B＝Behaviour ，行为

把优秀当成一种习惯，是行为方式的养成。《7 habits of highly effective people》一书中指出“First thing，First“，把“要事优先“放到了相当高的位置。要事优先是一种结果导向，要事优先是过程正确的前提。通过要事优先才能使自己专注起来，通过要事优先来明确规则，进而遵守规则。

勇于将自己的后背留给自己的战友，是出于信任，更是一种勇敢的行为。在应当互相帮助的时候，选择当将军还是选择当烈士，完全取决于自己。有无自我调适的能力，同样重要。

持之以恒是一种行为方式。都知道一万小时天才理论，而真正坚持一万小时需要勤耕不辍的行动。

C＝Capability，能力

学习的能力是最重要的一种能力，建立学习型组织，可以不断地提升个人与组织的素质能力。

胜任力是各种能力的一个综合体现。把握产品的能力，协作技巧，行业知识，专业能力，形成了核心胜任力。能干的人，不在情绪上计较，只在做事上认真；无能的人，不在做事上认真，只在情绪上计较。

管理自己的老板

我们提倡“敢于质疑，独立思考的自由精神“，老板的话不一定都是对的。但是，敢于质疑并不是一味地顶撞你的老板，而是以如何让产品或者服务给客户带来更大价值的角度出发的。

作为基层研发管理者，如何管理你的老板？

首先，出发点一定要正确，就事论事，别有负能量和情绪色彩。目标和初衷一定是为了把这一产品做好。不能只提问题，没有解决方案。这样的方式可能要好一点：

“如果问题是这样的XXX，那么存在如下几种解决方案： A xxxx； B xxxx；C xxx。 各种方案的利弊如下：A yyy；B yyy； C yyy。您看哪一种方案最好呢？“ 

老板不是来听你说问题的，老板更希望听到你对问题的看法，看到你解决问题的可能路径，从而给出决策。

明确问题非常重要， 你和老板对问题看法的不同，很多是因为双方的信息不对称。通常地，老板所了解的信息更加全面，所以，管理你的老板，就是更多地换位思考，站在老板的角度思考问题。

然而，组织的存在以及组织内外的分工不同，天然导致了一定程度的信息不对称。你有时无法获得和老板类似的信息的，这时需要做到的就是期望值管理。要真正了解老板的期望是什么，背后真正的价值是什么。期望值管理的要诀就是不要给老板"吃惊的瞬间"，一定不能让他感觉到"突如其来"， 老板最不能容忍的是，自己是到了最后一分钟才知道"事情发生了重要的变化"的人。

所以，管理老板在于明确问题和期望，敢于质疑和独立思考，同时在行动上要执行坚决。

裁员和新陈代谢

在研发团队中，根据木桶原理，真正体现团队技术能力的人是团队中力量最弱的开发者。不怕神一样的对手，就怕猪一样的队友，说的就是如此。

但是，打造精英团队往往是个伪命题。对很多团队而言，薪酬，待遇，福利等诸多局限，使得我们很难与那些顶尖或准顶尖的公司竞争。我们往往是二三流的团队来完成一流的事情。但是，人才是可以培养的，团队也是可以转变的。

如何转变？除了前面谈到的ABC之外，就是团队的新陈代谢了。在战场上，一个战士的受伤往往意味着损失2～3个战斗力。在开发过程中，一个人挖的坑，恐怕两个人可以填干净就不错了。劝退有可能是一种对双方都好的结果。末位淘汰尽管有些残忍，但往往是对双方的负责。

引进高手的直接手段就是招聘了。当你向HR提招聘需求的时候，不要仅仅给出一个JD，应该有更清楚的目标画像，例如毕业于怎样的院校，最好在哪些公司工作等等。这样，HR的伙伴才能够有的放矢，甚至通过猎头完成定向招聘。

总之，研发管理要具备人才培养和人才引进的能力，一切的竞争，归根到底都是人的竞争。

面向事的研发管理——理事

拥有了良好团队，并不一定达到预期的目标。这就是研发管理的另一方面，面向事情的研发管理。 事情成功的显性指标是结果和目标的达成，隐性指标是过程是否平滑高效。通俗地说，面向事的研发管理包括两个部分：结果导向和过程敏捷。

结果导向

每个管理者都知道以结果为导向，即以终为始。但关键问题是什么是结果？当前得到的的结果往往不是最终的结果，而是一个个阶段性的结果。难点在于保证目标结果的连续性。

产品和项目

互联网中往往涉及的都是产品，产品和项目又着很大的差别。

首先，二者的生存周期不同。项目的生存周期包括项目的启动、策划、执行，验收等，并在结项后，项目生存周期结束。产品的生存周期是从产品构思，到产品的版本更新，到产品中止的过程。产品不存在完成的说法，因为产品是不断更新的，直到被新产品替代，生存周期才结束。

另外，二者的目标不同。项目的目标是在规定的时间内，利用有限的资源，高质量的完成某个特定用户的需求。而产品的目标是满足一些用户的通用需求。

很多公司的情况是：首先销售拿下一个项目，在做完项目后，发现还有其他客户有类似的需求，于是进行产品化。这时产品化往往很难，因为在项目驱使下，技术架构、产品功能方面往往有先天缺陷。想要产品化，就需要重新进行产品规划和技术架构设计，这样成本很高。还有就是互联网产品的形式，是先有产品，再有项目，然后在项目中不断获取需求，完善产品。这种情况就要求首先对产品未来的发展趋势有很好的研究和预测，也是产品经理在互联网企业中地位很高并且紧缺的原因。

产品和项目是相辅相成的关系，产品的开发是通过一个个项目去完成的。将产品的需求，通过项目去实现，完成产品的一个版本。不断迭代进行，进而推动产品的版本更新。

结果的连续性

为了成就一个优秀的产品，需要保持各个阶段的连续性。

面向结果的连续性，可以借用数据中连续和可导的概念。可导的函数一定是连续的，高阶导数表明了函数曲线更加光滑。函数中的某点可导表明了这个点的斜率，即这个点的趋势和方向性。对于研发管理而言，鉴于时间的连续性，可以天然的看成连续函数。但是一个函数处处连续，处处不可导是怎样的一种情形呢？

上图是一个处处连续，处处不可导的函数示例。该函数图像没有“曲“，在任何一点上都没有斜率，你无法一笔画出函数的曲线。在研发管理中，这是一种非常可怕的状态，在任何一个时间点，都不知道下一个点的方向在哪里，存在着盲目的试错。

研发管理中很重要的一点，就是消除不确定性，可以一笔画出一条光滑的曲线。具体的方式可以通过关注兼容性和可扩展性的方式使结果连续并可导。

方便起见，这里的兼容性主要是指同一产品新旧两个版本A和B的兼容。A是旧版本，B是新版本。新版本B对A的兼容一般叫前向兼容，这是大家所熟知的。接口的兼容并不是非常复杂，但是数据层面的兼容要特别关注。A对B的兼容则一般叫后向兼容。A 很难知道B做了什么事情，但是B产品的上线不要导致A的客户端正常工作，这就需要A要对特殊的情况做合适的处理。

可扩展性是系统架构的一个关键约束条件。在任何时间都保持对产品或项目的恰如其分是非常困难的，因为社会环境在变，客户的行为方式和产品的使用方式也在变，唯一不变的就是变化。可扩展性的实践和度量也多种多样，服务平台的微服务化架构，客户的插件式开发等等都是对可扩展性的有益尝试。

过程敏捷

一旦明确了目标，一切以结果为导向， 接下来团队比拼的就是效率了。

我们知道，世界上不存在这样一种方法：只要套用，就可以写出完美的软件，无论使用的哪种设计模式；但确实可能存在一种开发方式，可以帮助我们一步步构造出需要的软件和架构——这有可能就是敏捷开发。

敏捷开发主要是通过高透明性、可检验性和适应性来管理复杂性、不可预测性和变化。

一个Sprint周期的长度要依赖于你能在多长时间内保证在Sprint期间的需求不发生变更。

敏捷个人

敏捷开发乃至一般的开发过程都会涉及到一件事，就是任务估点，就是如何见招拆招。个人觉得，一个task 最好以2个小时为单位，半小时设计，半小时编码，半小时测试，半小时文档、注释以及重构。

原因可能是这样的，互联网上流传着一句名言——3个月就是一年，也就是1周相当于1个月。那么，2个小时就相当于1天了，也就是说，我们的团队要将每两个小时当成一天来计算。众所周知，所有的估算都是不准确的，以2小时为单位是为了降低误差。就像我们度量的时候，以米为单位度量，误差就是米，以毫米来量，误差就是毫米。2个小时一个task，就相当于开发中的“毫米”。

敏捷开发中最重要的还是代码，优秀的代码质量决定着产品或者服务的质量。个人以为，有四种手段可以提升一下代码质量：

1）意图导向编程，简单地说，就是把注释变成代码，让代码拥有自解释性

2）测试驱动开发，尤其是对后端而言更为重要，可以结合日志系统可以更快捷定位问题

3）创建和使用分离，这就是大家常说的“高内聚 低耦合”了

4）单点修改原则，单点修改可能只是一种理想状态，但应该铭记在心

敏捷团队的4个会议

敏捷是一种方式，不是单纯的方法，是通过各种的行为方式来实现目标。在实施敏捷开发过程中，值得关注的有4个会议。

1）Sprint 计划会议。计划会议要有足够的时间，最好至少8个小时。取出部分产品需求做成sprint需求，并写成索引卡。确定并细分每一个索引卡的故事（User Story）, 然后进行工作认领（不是分配）。同时，确定每日站立会议的时间和地点，确定好演示会议和回顾会议的日期。

2）站会是敏捷中的一个显著特点，每次10-15分钟，迟到将接受惩罚，每个成员自问自答三个问题：昨天做了什么，今天要做什么和遇到了什么问题，会后再沟通问题的解决方案，最重要的是更新燃尽图。

3）演示会议是至关重要的。演示是跨团队的，会产生不同团队之间的交流。不要关注太多的细节，以主要的功能为主，一定要让老板或者客户看到。演示会议 非常的重要，绝对不可以被忽略。

4）回顾会议的时间一般在1-3个小时，要找最舒适的地方（最好有回顾看板）。开始的时候轮流发言，而不是主动发言。记录问题并总结，并讨论改进的方法，放在回顾看板上。每人将最重要的2-3个改进点，成为下一轮产品需求的一部分。

小结

老曹眼中的研发管理既需要道的指引，又需要实战的方法，以及那些看似微不足道的雕虫小技。作为一名基层管理者，既需要培养团队的ABC，又需要管理你的老板，保持团队的新陈代谢，因为一切都是人的竞争。 总之，研发管理是面向结果，过程敏捷的一种实践。

2017年1月10日周二晚8点30分，“中生代技术”社区老曹带来了主题为“老曹眼中的研发管理二三事”的交流。以下是主持人赫阳整理的问题精华，记录了老曹和读者间问答的精彩片段。

答：这是基层管理者的一个困境，既要协调团队，又要持刀上阵。在时间安排上，一线员工一般是8小时4个task， 基层管理者的task 一般是2～3个，有1/4～1/3 的时间用到团队内外协调沟通上。就敏捷流程而言，做好那4个会（规划，立会，演示，回顾），对于团队外的非紧急问题或者非规划讨论而言，可以回答半小时之后再讨论处理，这样既可以让问题发起者将问题梳理明晰，又可以让自己处理好手头的工作，尤其是在coding的阶段。

答： 研发是一件创造性活动，我讨厌KPI，提倡团队的结果导向和过程敏捷。

激励分为物质激励和非物质激励两种， 基层管理者很难实现物质激励（例如发奖金），需要相关激励机制的配合。对于非物质激励，关键是价值观认同，说白了就是洗脑。另外，技术提升也是激励的一种形态，让团队真的有成就感。

答：对于聪明的员工，给予认可，并提供更多具有挑战性的工作，包括技术的预研和分享。

对于所谓服管的员工，关键在于质量和效率的匹配程度，衡量一下他／她对团队的价值贡献，如果ABC中的C即成长空间有限的话，将被列入新陈代谢的名单，小白兔对团队而言是危险的。

答：产品经理 一般作为product owner， 而所谓的项目经理更像scrum master，product owner 如果兼作 scrum master，这是一个好事情。产品经理不要期待lead 技术，而是要结果导向，能否按时完成产品功能和目标，演示成果才是所需要关注的。 产品经理和技术人员之间不要“撕”， 不是纠缠在是否听谁的上面，而是本着相互帮助共同完成目标的态度，确定目标，积极协作。

答：一个技术管理者的职业发展是因人而已的，一句话，follow your heart， 你的初心是什么？什么能够给你带来更多的乐趣。 我见过转型为产品总监，产品VP的技术管理者， 也见过走上CTO岗位的，还可以持续的热爱代码，既是某方面的专家，又是一个全栈工程师甚至全栈架构师。关于全栈架构师的描述，可参看我的两篇旧文：

• 《全栈的技术栈设想》
• 《再谈《全栈架构师》一文》

答：雕虫小技相当于编程时的tips，都有有典型的使用场景和适用范围，例如 面对站会迟到 的童鞋，有多种办法：

1. 冷处理，大家静止沉默等他到来，让他意识到在浪费大家的时间。
2. 热处理，他到了，鼓掌，罚10*2^(n-1)元红包，即10，20，40 等等，将红包用于团队建设。

答：组织结构决定系统架构，这是康威定律的简明说法。关于组织结构与研发的关系，大家可以听一下中生代的另一位朋友——右军给大家带来的一场Chat：《从康威定律和技术债看研发之痛》。

如果产品和研发是分开的，是一个比较难受的事，但通过敏捷的方式还是可以改善的。敏捷的本质是通过信息的透明性，产品的可验证性和适应性来来管理复杂性、不可预测性和变化。 团队间需要信息共享协同工作的工具，例如trello，worktile，slack等。 产品经理对产品生命周期的跟踪通过信息共享实现。

问：测试团队和研发团队一般的配比是多少，如何对测试团队进行绩效跟踪？

答：测试与研发的配比一般不要低于1:7，建议QA入团队，QA的绩效是在团队绩效的约束下的。绩效跟踪同样可以通过协同工具实现，对于绩效考核，可以在QA和研发之间做绩效互评，然后取正态分布的期望，或者简单的加权平均。

问：测试用例的管理有什么好的建议么？

答：文档的管理，包括测试用例的管理，推荐使用 confluence，它可以记录文档的变更状态。

答：创业团队还是成熟公司？人员和开发项目几乎1:1 几乎没怎么见过，开发项目都是微型么？

正像我文中解释的， first thing，first。 最重要的事情只有一件（推荐阅读）， 应该集中优势兵力打一点的。跟踪进度，推荐使用问题7中所谈到的协同工具。如果是外包的话，那是另一种做法了。

答：个人认为，敏捷状态下的周期性绩效考核可能存在如下几点：

1. 周期：一般以3个sprint为宜 ，但需要关注每个sprint的回顾会。
2. 任务量： 关注燃尽图，借助工具了解伙伴的工作状态。
3. 绩效考核体系： 主要是promotion 的机制和 carreer development 的结合。
4. 评价方式： 多角度，但未必是360度评价， 面谈必不可少，明确进步与不足。

答： 0 bug is a dream。 代码质量是第一位，可以尝试文中谈到的四种方式和原则。

敏捷质量管理的要点，个人认为，是如何快速发现和修复问题，更多是对架构和技术能力的考量，例如：

1. 灰度升级的方式和体系架构。
2. APP端的热补技术，例如Tinker 和 JSpatch 的应用。

答：过犹不及。在敏捷过程中，我遇到的更多是设计不足，只有在大企业和大团队才有可能出现过度设计的问题。对于过度设计，更多原因可能是在杜撰需求，需求的界定可以使用User Story 和 UML 中的Use Case 相结合。 扩展性最好也从结果的连续性上考虑。

答：技术总监也是有类别的，客户端总监，服务端总监，中间件总监，解决方案总监等等，这是与不同公司的产品形态和商业模式有关的。 对技术总监的具体技术能力要求也是因岗位而定，阿朱曾经写过一篇《CTO、技术总监、首席架构师的区别》的短文，可以参考一下。

面试中可能除了技术能力外，还需要面试例如沟通，抗压，应变等能力即软技能。

答：个人觉得， 对于初入职场的年轻人而言，前两份工作，尤其是第一份工作，最好在3年以上， 至少也要9个月以上，要逐渐学会看别人的优点，没有垃圾的老板，只有狭隘的视角。

对于年轻人，管理者可以尝试帮助他思考职业规划，提升的方向和路径，没有人能够随随便便成功的。

答：敏捷开发主要是通过高透明性、可检验性和适应性来管理复杂性、不可预测性和变化。 首先是结果导向，一定要让老板知道结果，尤其是在演示会议中。 在老板不知情或者自己权力有限时，敏捷要从低调做起, 但是要让管理团队体会到变化。

答：敏捷需要组织结构上的支持的。组织机构决定了系统架构，也决定了研发流程。 敏捷导入前，要有相应的技术准备和预热，比如请敏捷教练外训，相关工具的熟悉等等。

就技术而言，没有最好的技术，只有相对适合的技术。 结果导向，让团队有成就感。

敏捷是个面向结果的过程，都是可以做到的。个人敏捷，团队敏捷，项目敏捷等等，现在还出现了数据敏捷，关键是观念的转变，辅助以技术的支撑。

答：很幸运，本人有过亲身经历。

首先，架构是第一位的，尤其是面向云服务的架构，利用公有云服务，以及各种XaaS，使小团队做大事情成为可能。另外编程语言的选择也是一个因素，决定了技术栈的构成。小作坊更适用于结果导向，过程敏捷的。

带初级工程是要有耐心的，条件允许的情况下，花时间结对编程是值得的。

答：对于核心员工，要防患未然。 核心员工应该在人才矩阵中的， 每月最好都给予关注，及时把握动向，往往他提出离职的时候，就已经晚了。

对问题员工，要霹雳手段，菩萨心肠，长痛不如短痛，直接办离职。

答：管理是管人，理事。管人中很重要的一项就是 才管理ABC， C中重要的一点就是学习能力，保证组织是学习型的。 哪些工作习惯是好的工作习惯么？是提高生产率的习惯么？

另外，技术的预研很重要，尤其是和团队中当前技术的对比，分享要透明，是共同决策的结果。

答：sprint 的周期 是以需求不改变为依据的。什么是意想不到的东西？老板发现的bug，还是？

对于新技术可以关注，gitchat，中生代等等都是学习新技术讨论技术痛点的好场所。

答：这时，一定要明确团队的目标和资源，包括时间的限制，全面比较两个或多个方案，关键是找到最优路径，而不是单纯的技术最优，可以采用集体智慧的。 如果无法说服，不要影响团队，可以调离他。

答：业务和研发最好在一个team，这样目标一致，规划会要充分一点，可以尝试用UML中的相关界定需求的边界。其实，定义需求是研发的起点，也是第一个关键点。

问：如何把政治因素的影响降到最低？

答：有人的地方就有政治，最好把政治斗争归结为为经济服务， 用利益来绑定双方，可以降低政治因素的影响。

问：我们几个项目的回顾产品问题总结如下，能否指教解决的思路？

答：粗略看了一下，一半以上都是和需求相关的。 需求的界定需要花时间的，所花费的时间是整个 sprint 中 最耗时的，推荐不少于1天的。如果要启动研发，至少要明确MVP 最小可运行的产品。如果产品经理有缺憾需要技术侧提前介入。

例如 “希望能更深入的了解，这个需求的目的是什么，不是纯……”这说明了产品经理并没有把需求讲清楚， 为什么做？很容易调动不了研发人员的主观能动性。另外，对需求的描述有数据支撑么？如果方向错了，停止就是进步。

答：自己的预期要和团队的目标，甚至部门乃至公司的目标相匹配。成长的目标确定也要做到与组织目标的吻合， 另外就是 follow you heart。管理是一种实践，以结果为验证，是需要尝试和实践的，实践本身就是与时俱进的。

技术上的与时俱进好像只有勤奋二字了，像《卖油翁》中所说，“无他，惟手熟尔”。

答：就代码整洁而言， 建议在git侧安装sonar 之类的插件，以代码规范在提交时做检查，不符合要求的，直接提交失败。至于封装复用等，可以参考文中个人敏捷的4种方式。需求是有约束的，产品经理给出的feature 理由要充分， 技术在设计的时候考虑要全面。如果以工匠精神作为一种价值观，并且在一定时间内无法得到某些员工的认同，可以考虑团队的新陈代谢。

答：可以不贡献代码，但最好懂技术。阿里的王坚博士好像也不码代码吧，同样可以做杰出的CTO。

答：树立标杆，优秀选能。在绩效，奖项和宣传方面都要提倡。设计模式，代码规范，checkstyle是一些范式。一个池塘的荷花，总有早开的，让早开的影响晚开的，最后一溏荷花。少数始终不开的，问题就出在他们自身了。解铃还需系铃人，对于浪费时间的人，考虑淘汰出团队。

微信扫一扫
关注该公众号