智能手表，一个新兴的领域，充满了无限的可能，也许有，我们随处可见，像当今的智能手机一样。作为一类新兴的产品，市场上缺乏成熟的开发经验，我们摸着石头过河，不断的尝试，不断的改进，不断的提升。
　　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.矛盾与取舍
　　虽然大方向来说，需求提前才是促使新品上市的主要方式。但是，实际研发过程中，尤其是在迭代开发中，需求已经做到了提前，后端迭代速度偏慢，成了一个比较凸显的问题。多少人能做多少事，增加人员能否提高生产力，迭代速度是否存在极限，这些问题都有待研究和解决。
　　像爱因斯坦的相对论，人类无法突破光速有一个制约的因素，是速度越快，质量越大，接近光速时，质量趋于无穷大，也是说速度越快，加速的成本越高。一个软件开发的速度也许也受到其固有的软件复杂度等因素影响，存在一个迭代速度极限值，例如：一个功能点由一个人变为两个人来做，那么多一个人多了沟通成本，那么随着人数的激增，超过某个临界值时，增加人数反而会降低研发速度。