效率之战如何提升智能手表开发团队效率

　　在控制领域，闭环是我们是系统达到稳定的一个有效方案，对于我们的产品研发，同样需要类似的反馈系统形成闭环，这样我们的研发体系才能有预期，研发进度才可控，做到心中有数，百战不殆。
　　智能手表，一个新兴的领域，充满了无限的可能，也许有一天，我们随处可见，就像当今的智能手机一样。作为一类新兴的产品，市场上缺乏成熟的开发经验，我们摸着石头过河，不断的尝试，不断的改进，不断的提升。
　　1.困境
　　作为一家成熟的消费类产品公司，产品仅仅在软件研发领域一般包括下图的各类人员：
　　简单的分析上图中的结构，智能手表的开发貌似和常规的互联网产品类似，然而它的复杂性却没有看上去那么简单，我们先简单分析一下上图：
　　软件与4类人员有关联，两个强关联，两个弱关联。
　　交互与4类人员有关联，两个强关联，两个弱关联。
　　其他职能人员关联性都相对较少。
　　这里有一个实践的经验，强关联性的增加导致沟通成本以指数性的上升，弱关联的增加导致沟通成本以简单+1的形式上升。基于此，我们假设强关联的增加的指数上升为2的倍数（该值不一定合理，需要实际研发数据进行匹配调整），建立对应的沟通成本计算数学模型：强关联（2的n次方） + 弱关联数。使用该数学模型，我们计算出各个领域在软件研发领域的沟通成本：
　　运营：1+1=2
　　视觉：1+1=2
　　测试：2的1次方+1 = 3
　　规划：2的1次方+1 = 3
　　交互：2的2次方+2 = 6
　　软件：2的2次方+2 = 6
　　备注：部分领域也许还有其他的关联度，这里仅仅只考虑产品研发的主要场景。
　　基于该数学模型，我们基本上可以得出，交互和软件将是整个研发流程沟通过程中的核心瓶颈，然而这样计算就正确了吗？交互和软件在沟通成本上就只比其他领域多这么一点点吗？我们再把问题拆解得更细一些。
　　1.1.领域细分的副作用
　　软件技术的不断革新，促使软件领域增多，针对智能手表领域，它涉及到的软件领域包括：智能手表端、服务器端、android应用端、ios应用端、H5网页端。以下，是它们之间的沟通关系图：
　　备注：智能手表并不是所有的功能都涉及到上图的所有软件领域，上图仅仅列举了最复杂时的情况。
　　基于上图，我们需要重新计算一下软件、交互与测试在最复杂的情况下的沟通复杂度：
　　交互：2的6次方+2 = 66
　　测试：2的5次方+1 = 33
　　软件（watch）：2的5次方+2 = 34
　　软件（server）：2的6次方+2 = 66
　　软件（h5）：2的3次方+4 = 12
　　软件（android）：2的5次方+3 = 35
　　软件（ios）：2的5次方+3 = 35
　　因此，软件、交互、测试在日常工作过程中，沟通成非常高。如此高的沟通成本，意味着研发效率的下降，产品复杂度的上升，以及信息不一致情况发生的概率增高。
　　1.2.总结
　　从本章的分析结果得出，仅仅在沟通成本这个层面上，智能手表的复杂度就非常的高。即使与当下常见的互联网产品相比，在多引入了一个手表端的情况下，其复杂度指数性的提升一倍，也是不可估量的。从直观上看，它仅仅是多了一个手表端，应该和传统互联网产品功能复杂度差不多，但是却事与愿违。如果《最后期限》一书中所说，我们需要将自身的经验模型化，这样才能更准确的评估软件开发情况。有的事情，还是需要严密的理论逻辑分析才能得出正确结论。
　　直觉总是告诉我们下面一根线被上面那根短一些，可以它们却实实在在是一样长。
　　2.个体效率与团队效率的纠缠
　　直觉告诉我们个体效率提高，团队效率就会提高。人员的增多，团队效率也会提高。但是在没有背景前提下，这样的结论没有任何意义，如果我们所做的事情可以拆分成多个基本互不关联的事情，那么，这个结论基本成立。
　　例如：我们都听说过和尚挑水喝的故事，1个和尚挑水喝，2个和尚抬水喝，3个和尚没水喝，改为3个和尚都分别自己挑水。那么相对于1个和尚，效率提高三倍，如果单个和尚每天挑水的效率提高1.5倍，那么3个和尚相对于最开始的一个和尚效率提高3*1.5=4.5倍，是不是很激动人心。
　　理想很丰满的，现实很骨感，软件行业可不能用和尚挑水来简单类比。这样的直觉错误，我们却经常再犯。原因在于我们在分析任何事情时，都是先由系统1（简单理解为直觉系统）处理，在系统1无法给出合理的解释时，系统2（简单理解为思维系统，可是它很懒）才会介入。软件行业的著作《人月神话》全面的阐释了软件不能简单增加开发人员来解决问题。因此，针对智能手表的研发，取得个体效率与团队效率的平衡至关重要。
　　产品研发就像种果树，必须经历播种、施肥、灌溉等一天天逐渐的长大，不要企图通过多施肥等手段提前收获果实。种一个棵树最好的时间是十年前，其次才是现在，所以想要新品早点上市，那么就需要将需求整理提前，而不是过多的希望研发后端流程能更有效率。
　　2.1.如何提高个体效率
　　尽量减少被打扰的次数。
　　让个体身处于所在专业领域的团队中。
　　持续进行某个特定领域的研究。
　　同领域人员集中地点办公。
　　2.2.如何提高团队效率
　　加强团队成员沟通。
　　项目组成员集中成一个团队。
　　团队成员为多领域复合型人才。
　　同项目组成员集中地点办公。
　　2.3.矛盾与取舍
　　虽然大方向来说，需求提前才是促使新品上市的主要方式。但是，实际研发过程中，尤其是在迭代开发中，需求已经做到了提前，后端迭代速度偏慢，就成了一个比较凸显的问题。多少人能做多少事，增加人员能否提高生产力，迭代速度是否存在极限，这些问题都有待研究和解决。
　　就像爱因斯坦的相对论，人类无法突破光速有一个制约的因素，就是速度越快，质量越大，接近光速时，质量趋于无穷大，也就是说速度越快，加速的成本就越高。一个软件开发的速度也许也受到其固有的软件复杂度等因素影响，存在一个迭代速度极限值，例如：一个功能点由一个人变为两个人来做，那么多一个人就多了沟通成本，那么随着人数的激增，超过某个临界值时，增加人数反而会降低研发速度。
　　2.3.1. 个体效率与团队的矛盾点
　　团队的沟通与减少打扰互相矛盾。
　　专业团队与敏捷团队矛盾。
　　持续研究某个领域与多领域复合矛盾。
　　专业团队集中办公与敏捷团队集中办公矛盾。
　　以上矛盾简直是要逼死＂处女座＂，本人就是＂处女座＂。所以，现阶段根本就不存在个人效率与团队效率双赢的方案，必须有所取所，取长补短。刚开始接触敏捷开发，要做的事情就是熟悉敏捷开发中的各个流程，以及如何操作，解决我们现有的问题。现在回过头来分析，敏捷开发中设立的每个环节，在解决以上矛盾问题上都提出了相应的方案。
　　2.3.2. 团队的沟通与减少打扰互相矛盾
　　不管是敏捷团队还是专业领域团队，沟通都不可避免，因为产品是由整个团队开发出来的，即使是某个交互方案、软件组件、策划方案往往都由多人参与。然而，频繁的沟通必然影响个人的开发效率，因此在敏捷的团队里，每日有固定的晨会、每周有固定的迭代计划与总结会等。是的，这就是敏捷开发在个人效率与沟通的矛盾上的取舍。
　　同样的，在专业领域团队中，我们尝试每周做固定的交流会，以软件为例：每周固定代码交流会，以某位软件同事的作品为主线，引导专业领域团队内成员交流。这是一个很好的取舍，让整个团队有自己固定的节奏。
　　收益
　　这样的方式，极大的改善了团队内信息不对称的问题，在专业领域团队有效的改善设计方案，规章制度的实际执行，同时提高了整个团队的能力等。在敏捷团队中，有效的避免因信息不一致导致前端设计与后端实现不一致，测试理解偏差等问题。
　　损失
　　每天都有会议，对于工作有一定的打断影响，部分人员参与会议时，会议参与度低，实际收益甚微，会议的整体节奏需要成员逐步适应，弱一个人同时处于多个敏捷团队中，会议数量会严重影响该成员的工作（这种情况需要尽量避免）。
　　2.3.3. 专业团队与敏捷团队矛盾
　　在这个问题上，个人比较趋向选择专业团队为主，敏捷团队为辅的方式，不一定正确，也不一定适用于各类场景，这个决定是站在我现在所处的环境得出来的，理由如下：
　　敏捷团队已经有足够多的会议，足以达到信息对称的效果。
　　敏捷团队为主，会导致各个人员专业领域薄弱，专业上缺乏积累，重复开发的风险增大。
　　敏捷团队为主，会导致人员复用性降低，调配难度增大，资源独占。
　　专业团队为主，能有效的积累专业领域知识，设计整体方案，提高生产率。
　　专业团队为主，对于技术方案的评估会更加全面和准确。
　　但是，这样的选择也有它存在的问题：
　　专业团队为主，敏捷团队缺乏足够的独立性，人员变动可能性增大。
　　专业团队为主，敏捷团队缺乏明确的目标，难以在迭代过程中找到成就感。
　　专业团队为主相比于敏捷团队为主，在产品开发期间沟通效率偏低。
　　2.3.4. 持续研究某个领域与多领域复合矛盾
　　如今，各类技术纷繁复杂，各类想法如雨后春笋般冒出，要跟上市场的节奏，要求我们必须有足够的反应速度和研究深度。在产品初期，我们往往需要的是快速实现基本功能，产品的上市后，我们需要不断的优化用户体验，这个时候需要我们在需求、交互、软件方案进行深入研究改善。因此，从需求出发，两者都不能少。
　　识别独立的核心领域，专人跟进研究，不参与敏捷迭代。
　　丰富领域内文档沉淀，提高新手上手速度，避免踩同样的坑。
　　团队内在迭代开发过程中，根据人员特点，重点培养其核心领域，促使团队在整体上各项领域均研究深入。
　　逐步识别细分领域，将各项细分领域专业化，系统化，模块化。
　　2.3.5. 专业团队集中办公与敏捷团队集中办公矛盾
　　这个问题其实与＂专业团队与敏捷团队矛盾＂类似，这里的意见和之前的一致。
　　2.4.总结
　　在个人效率与团队效率上，没有绝对正确的方案，在智能手表这个产品领域，我们现在采用本章描述的方式进行取舍。它还有很多问题，并且存在一定的改善空间，但是这些问题，不能简单的根据我们的经验得出结论，需要相关的数据支持以及对应的方案实施验证。因此，需要不断的思考和尝试，也需要下一章节的研发闭环来有效的衡量和评估方案的有效性和其带来的实际效益。
　　3.研发闭环
　　谈到闭环，我们往往会想到大数据，因为现在人人都谈大数据。不谈它，感觉自己都不是做产品的人一样。说得好，不如做得到，相比于产品级的大数据研究，在整个研发流程中，记录好各个节点的情况，识别出研发过程中的各项瓶颈和问题，做到可追溯，可分析，也显得十分的重要。
　　但是在开始记录数据之前，我需要着重声明一下：我们一定要避免什么数据都记录，因为我们总感觉每一项数据都有它的意义。让数据产生它应有的价值才更重要，数据驱动改善研发流程，需要以迭代的思想逐步优化，不能一蹴而就。
　　3.1.瓶颈识别
　　每个专业领域都有它固有的研发效率，产品研发就像多条并行生产的流水线，需要经历一个又一个的环节，如果每个环节都保持着忙碌，那么效率最低的环节决定了整个研发团队效率。尤其是上下衔接的两个环节，如果的生产与消费不匹配，就是导致资源不足或者资源浪费问题。
　　生产和消费必然不可能完全匹配，因此在软件领域有队列，在迭代领域有需求池，这些措施能解决一定的冲突。但是如果严重不匹配，例如生产者太强，那么最后任务就得不到及时的响应，尤其是产品研发领域，时机有时候很重要。如果消费者太强，又导致一定的资源浪费。因此，我们想要什么？快速，还是省资源？这决定了在整个团队组建过程中人员的配比情况。
　　那么如何识别瓶颈？在产品研发领域主要包括以下流程：
　　识别瓶颈的核心思想在于评估相互连接着的两个环节的匹配度和处理能力，因此我们需要任何一个功能在每个节点上的完成时间，当我们想识别在整个项目周期，各个领域的瓶颈问题时，我们只需要选取按照一周为一个节点进行计算分析，就能得出对应的上下两个环节生产与消费是否匹配，从而识别瓶颈领域。
　　3.2. 研发效率量化
　　在3.1中，我们记录了每个功能在每个环节上完成的时间，基于该数据，我们可以做以下这些事情：
　　寻找生产大于消费的时间区间，计算此时消费者的效率，该效率基本能代表该专业领域的实际研发效率。
　　基于得出来的实际研发效率，对比每月的实际生产率，分析当前是否存在人员闲置，或者利用不足。
　　对比多月的实际研发效率，用于评估在领域优化，或者敏捷流程优化等方面的方案尝试中，是否取得实际效果。
　　3.3. 定位问题点，针对性总结优化
　　根据各个节点的数据，识别出在项目过程中开发进度不合理的功能，并进行阶段性的总结分析，针对遇到的问题，制定对应的改善方案，持续优化项目研发流程，在流程优化过程中做到有理可依，有数据可以证明。
　　3.4. 总结
　　在控制领域，闭环是我们是系统达到稳定的一个有效方案，例如在自动化原理里面提到的PID控制，它根据当前实际值与期望值的误差计算，利用比例、积分、微分三个方面的反馈控制，使系统最终在期望值上下浮动，趋于相对稳定。对于我们的产品研发，同样需要类似的反馈系统形成闭环，这样我们的研发体系才能有预期，研发进度才可控，做到心中有数，百战不殆。