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控制，它根据当前实际值与期望值的误差计算，利用比例、积分、微分三个方面的反馈控制，使系统终在期望值上下浮动，趋于相对稳定。对于我们的产品研发，同样需要类似的反馈系统形成闭环，这样我们的研发体系才能有预期，研发进度才可控，做到心中有数，百战不殆。