“这个软件要开发多久？” 

这对所有软件开发者来说都是灵魂之问。那么，软件开发工期到底取决于什么呢？

（1）团队人数？

人数确实是一个看起来直接相关的因素，那么是不是人数越多，需要的天数就越少？比如一个预估1000人天工作量的软件开发项目，那么1000个人花 1 天就能搞定了。

这显然是不可能的，光这 1000 个人的沟通和工作分配都是一个大工程。在软件开发的过程中，人与人之间的协作并不能完全并行，很多时候是有相互依赖的，比如产品、研发、测试之间的依赖。就算是研发内部，也没法完全并行，而且这些依赖关系错综复杂，需要各个层面的协调，这时候就涉及到项目管理了。

（2）项目管理水平的高低？

说到大型项目管理，既然人员准备好了，那么我们干脆就把软件工程当做一个普通的工程项目，就像盖楼一样来进行项目管理。按功能设计、技术设计、开发、测试来进行逐步排期，每到一个新的阶段，就进行一次预估。

从软件工程管理角度，这样做没啥问题的，但是，如果这样就能搞定，那就谢天谢地了。在实际过程中，会出现各种幺蛾子，比如研发在接近提测时说某个功能定义有问题，实现不了，或者和另外一个模块联调不通时发现某个底层设计有问题，或者测试测着测着发现有的重要场景没被定义。

（3）负责人技术水平的高低？

讲到这，大家可能觉得，听起来好像都是具体技术问题了，是不是有一个高水平的技术负责人就可以了？

听起来也很合理。一个高水平的技术负责人，通常在架构设计、大的组件选型方面会进行把关，可以一定程度避免大方向的错误。但是，架构就像一个人的骨架，只有骨架还远远不够。除了骨架之外，还有器官、血肉、外观，甚至表情管理和性格等。

那么，技术负责人能不能把这些细节都把控住？对于数据库来说，不能，累死也不能。大概在2020年左右，我被任命为代码总师，要熟悉每一行代码，审阅和把控进入系统的每一个 PR，但是在系统功能模块逐渐变多后，代码开发和审阅 PR 是我最先放手的工作内容。

一个软件需要做多久，也就是估计人天，或者人月，是一个世纪难题。关于这个问题，有一本经典的软件工程书籍《人月神话》进行了深入讨论，作者的结论是没有“银弹”。

如果让我来回答这个问题，一个软件的开发周期取决于团队一致性。

大家可能玩过传话游戏，人员两两沟通，传递信息，看最后一个人获得的信息和第一个人相差有多大。往往人越多，越难以保持信息的一致。

数据库是个高复杂度的系统，一个高质量的数据库产品，对外一定是一个整体，无论是从架构设计、还是功能细节，都应该看起来像出自一人之手。如果不同功能的设计出自不同理念的人，甚至同一个人不能保持一致的设计理念，都会让用户的使用体验变差。

数据库的研发过程也面临同样的问题，在迭代过程中，涉及多种角色、很多人员之间的信息传递。有的信息应该全员广播，有的信息需要跨模块沟通，有的信息只需要小范围知晓即可。这本身就是沟通效率和效果的权衡。

最激进的做法，就是两两传递，类似传话游戏，效率高，但是有可能会收获“惊喜”。最保守的做法，就是全员开大会，确保每条信息都传递到了每个人，但是可能又会发现，团队整天没干啥事，天天开会了。

一个团队的能力提升，就是信息传递方式从保守到激进的过程，这一点就可以称为团队的一致性。

一致性体现在哪些方面？

体现在沟通效率。有的人说了一堆，都是废话。有的人言简意赅的说了重点，但是别人理解不了。

那么，团队的一致性是否就等同于沟通效率？是否定的。

在数据库的开发过程中，有大大小小的信息会在各个时间、各个地方产生，小到一个变量的命名，中到一段代码是否要进行复用还是再写一套，大到发现一个功能没法实现，是否要进行取舍。

不一定所有信息都会被传递到所有适合的相关人员进行联合决策，而且一定不会。世界上没有两片完全相同的树叶，每个人的观念也都不会完全一致。这取决于每个人对以下几个问题的判断：

1. 这条信息是否需要拉相关人员讨论？还是自己就可以处理？

2. 这条信息的相关人员有哪些？两两传递还是拉多人一起？

3. 联合决策是否会增加自己的工作量？或者导致无法按期交付？

数据库的开发是一个团队协作的过程，不管是功能定义、架构设计、代码开发、代码审阅，每个人能覆盖的范围总是有限的，一定会两两之间相互有部分重叠，另一部分工作还需要独立完成。

因此，团队成员独自面对一个问题的处理态度和方式，就体现了团队的一致性。一致性强，效率就高，一致性弱，内耗就多。

如何培养一致性？

先举两个例子，再聊聊可能的方法。

第一个例子是我的大师兄黄向东。

从我博一开始，东哥就作为大师兄手把手带我读一致性的论文，带我做IoTDB，给我讲大型系统设计的原则和经验。我遇到问题，卡个一段时间没有思路就会第一时间去问东哥，当然也会经历无数次被教育的过程，但头再铁也得学习和接受。

经历了几年的配合，在面对一个问题时的解决思路，我们基本能达成90%以上的一致性，因此我俩一般不需要一起开大会，十分钟就能快速同步一天的有效信息，因为知道对方关心哪些内容。

第二个例子是我的师弟田原。

我的原是19年清华入学，22年毕业就加入天谋，现在是 IoTDB 研发负责人。一个大的功能交给他，对好大概思路后，几乎就不需要我再操心了，总能按时高质完成。我们一致性的培养是来自研究生三年密切的配合，除了每天在实验室的频繁讨论外，几乎每天午饭和晚饭，我们都会一起走着去离实验室最近的食堂吃饭，总能见到去食堂路上激烈讨论的场景。

经过常年的磨合，现在一个很经典的场景就是：当我说做一件事时，其他人可能没太理解，田原则会直接说出来我的目的，然后问我，是这个意思吧乔老师？那种感觉就是：知我者，原也！

那么，怎么培养一致性？抛三个观点。

（1）一致性的培养离不开时间的投入，这里的投入是指思想的交锋，是吾爱吾师、吾更爱真理、有话直说的态度。

（2）思想大于结论。在讨论时，除了聊具体决策外，还要多聊背后的思想，让别人能够理解你的思维链。只要思维链和原则保持高度统一，做出来的决策就不会偏差过多。

（3）选择大于努力。思想的统一也是最难的，只能选择那些和你思想一致、志同道合的人，能长期一起走过来的，一定是最好的战友。人不在多，一致则灵。

我常用一个比喻，一个好的团队就像一个特种部队，大家的配合应该非常默契，面对任何情况，通过手势，甚至眼神就能快速完成目标统一和任务分工。

所以，IoTDB 的团队才是 IoTDB 的核心生命力，找到一个与自己合拍的团队是工作中最大的快乐。

最后，也祝大家都能找到适合自己的团队。