老曹眼中研发管理二三事
这是在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作者是怎么看的？如何做到正向的激励，又不会慢慢使团体过于功利化呢？
答： 研发是一件创造性活动，我讨厌KPI，提倡团队的结果导向和过程敏捷。
激励分为物质激励和非物质激励两种， 基层管理者很难实现物质激励（例如发奖金），需要相关激励机制的配合。对于非物质激励，关键是价值观认同，说白了就是洗脑。另外，技术提升也是激励的一种形态，让团队真的有成就感。
问：工作中会碰到两种成员：一种聪明不是很服管，态度一般，但完成效率很高，能单独完成复杂事物，另一种是不聪明但服管，态度很认真，但效率不是很高，经常需要指导。请问这两种成员应该怎么培养？怎么管理？
答：对于聪明的员工，给予认可，并提供更多具有挑战性的工作，包括技术的预研和分享。
对于所谓服管的员工，关键在于质量和效率的匹配程度，衡量一下他／她对团队的价值贡献，如果ABC中的C即成长空间有限的话，将被列入新陈代谢的名单，小白兔对团队而言是危险的。
问：产品作为项目经理如何lead技术？
答：产品经理 一般作为product owner， 而所谓的项目经理更像scrum master，product owner 如果兼作 scrum master，这是一个好事情。产品经理不要期待lead 技术，而是要结果导向，能否按时完成产品功能和目标，演示成果才是所需要关注的。 产品经理和技术人员之间不要“撕”， 不是纠缠在是否听谁的上面，而是本着相互帮助共同完成目标的态度，确定目标，积极协作。
问：作为一个技术管理者，自身的职业发展路径如何规划？如何不断培养自己的技术领导力？
答：
一个技术管理者的职业发展是因人而已的，一句话，follow your heart， 你的初心是什么？什么能够给你带来更多的乐趣。 我见过转型为产品总监，产品VP的技术管理者， 也见过走上CTO岗位的，还可以持续的热爱代码，既是某方面的专家，又是一个全栈工程师甚至全栈架构师。关于全栈架构师的描述，可参看我的两篇旧文：
问：都有哪些管理雕虫小技可以直接使用？
答：
雕虫小技相当于编程时的tips，都有有典型的使用场景和适用范围，例如 面对站会迟到 的童鞋，有多种办法：
- 冷处理，大家静止沉默等他到来，让他意识到在浪费大家的时间。
- 热处理，他到了，鼓掌，罚10*2^(n-1)元红包，即10，20，40 等等，将红包用于团队建设。
问：针对产品规划团队和研发团队是两个部门的情况，如何落实产品经理对产品的生命周期跟踪？
答：组织结构决定系统架构，这是康威定律的简明说法。关于组织结构与研发的关系，大家可以听一下中生代的另一位朋友——右军给大家带来的一场Chat：《从康威定律和技术债看研发之痛》。
如果产品和研发是分开的，是一个比较难受的事，但通过敏捷的方式还是可以改善的。敏捷的本质是通过信息的透明性，产品的可验证性和适应性来来管理复杂性、不可预测性和变化。 团队间需要信息共享协同工作的工具，例如trello，worktile，slack等。 产品经理对产品生命周期的跟踪通过信息共享实现。
问：测试团队和研发团队一般的配比是多少，如何对测试团队进行绩效跟踪？
答：
测试与研发的配比一般不要低于1:7，建议QA入团队，QA的绩效是在团队绩效的约束下的。绩效跟踪同样可以通过协同工具实现，对于绩效考核，可以在QA和研发之间做绩效互评，然后取正态分布的期望，或者简单的加权平均。
问：测试用例的管理有什么好的建议么？
答：文档的管理，包括测试用例的管理，推荐使用 confluence，它可以记录文档的变更状态。
问：公司有多个产品同时开发，人员和开发项目几乎1:1，有什么好办法合理安排人员？怎么有效跟踪推进进度？（背景：12个开发，大大小小的产品有10个。）
答：
创业团队还是成熟公司？人员和开发项目几乎1:1 几乎没怎么见过，开发项目都是微型么？
正像我文中解释的， first thing，first。 最重要的事情只有一件（
