2017 年 Q2 即将结束。回想上半年，可以说是从一次又一次的项目上线中走过来的。从首当其冲的来问丁香医生重构版到丁香医生 App v6.0，再到丁香医生小程序，以及最近的丁香医联体（D2D）。

周五的时候和研发相关的同事们一起开了一个 D2D 的总结会，个人认为这个会很有价值，下面将其中的一些内容记录下来。

项目周期

任何一个产品的研发都可以分为 从0到1 和 产品上线后的迭代 两个阶段。无论哪个阶段，都不应该把项目的周期拉的太长。无论是产品还是研发，都要尽量去避免这个情况的发生。周期越长，遇到不可控因素的风险就越大（比如其他项目的优先级被提高、项目的开发人员由于某些原因的变动）。项目成员久久看不到胜利的曙光，可能会导致士气低落，也可能会导致项目成员开始疲劳战（希望通过更多的时间投入换取项目的早日上线）。如果由于种种原因，周期很长在所难免，那么应该考虑如何在整个周期中划出几个时间节点，让参与项目的人在每个节点之间都品尝到收获的快感。

项目排期

这里的排期是指需求文档和设计稿明确后，研发人员对完成产品需求的时间评估。这是每一个开发人员都会面临的问题，这也是开发人员最容易翻船的地方。项目排期出现严重偏差可以大致分为内因和外因两种。

内因是对于开发者来说的。开发者总是会过于乐观的给出项目的完成时间。这个问题上经验丰富的开发犯错的几率会小一些，但也难说永远不会犯错。解决这个问题一方面是靠一线开发者自身的经验的提升，另一方面也需要项目的研发负责人在全局有一个把控。

外因可以有很多。常见的是来自需求方的压力：期望/要求项目在某个时间节点上线。如果公司的发展确实需要在特定的节点上线某一款产品/更新某个功能，那么把开发人员评估出来的时间点稍微提前一点点，通过加班等方式保证项目上线，是一种可选的方案。但是从工程的角度来说，这种要求对项目的潜在伤害挺大的。对于整个研发团队来说，长期的压缩研发周期也不是一件利大于弊的事情。目前我的观点是：减少外因对于排期的干扰，核心的办法是沟通。可能会比较难沟通，但沟通了总会比把巨大的压力丢给一线研发人员好。

项目文档

项目文档是指：需求文档、后端接口文档、项目的README、代码提交记录等所有项目相关的文字描述。团队合作的项目，实在找不到一个合适的理由不去把项目文档写好。不多说了。

后端接口规范

这一点同样可以展开说很多。总结起来就一句话：需要一个良好的规范并去遵守它。

新增需求

产品开发过程中，可能会新增需求。出现这种情况是正常的，但是需要开发人员灵活的去应对。小的需求可以考虑顺手做掉，大的改动/新增则需要叫上相关的同事一起讨论一下，看看是否有必要对项目的上线时间进行重新的评审。重新评审倒不是说项目上线一定要延期，而是为了大家一起把项目的风险降到最低。再开一次需求评审的另一个好处是，可以推动产品同事后续的需求考虑的更完善。

测试环境

在立项之初，项目开发完成后测试环境、测试账号、测试用例等事情要准备好。其中细节会牵扯到很多，比如：如何保证测试环境和生产环境是一致的？是否有必要有了测试环境再去新增一个预发布环境？测试环境如果涉及到支付、依赖于特定环境（比如：微信）的文件上传该去如何测试？

前端的工程化

最后一点试会上没有提到的，但是我认为是有利于今后项目研发效率提升的。比如：同一个产品线设计规范的沉淀和输出（有了设计师的规范，前端可以去做 UI 库）、基础组件/业务组件的复用、开发工作流的完全自动化、前后端的完全分离等。

最后

以上这些思考的角度并不新颖，毕竟太阳底下没有新鲜事。可能很多做软件开发的同学或多或少都有接触过这些事情，但是接触过、了解过、做过不代表做的足够好。每每遇到这种类似于“道理听过许多，却依旧过不好这一生”的情形时，我总是能想起于四个字：知行合一，然后会更深层次的理解这四个字。

修行在路上。Peace。