过去的几天一直在回顾整个产品团队过去一年所做的工作，有的工作有亮点，有的工作可以说是乏善可陈。对于不好的，发现其中的一个核心原因就是没有坚持“以终为始”的原则。现将我2021年10月写的一篇公司内部博客再次分享给团队，也分享给所有关心TDengine发展的开发者和朋友们。
亚马逊的两位前高管Colin Bryar与Bill Carr离开亚马逊后，前不久出版了一本书："Working Backwards: Insights, Stories, and Secrets from Inside Amazon", 让大家对亚马逊的工作原则之一”Working Backwards"有了更多了解。按照中国人的说法，亚马逊的这条工作原则其实就是“以终为始”。做任何事情，先想到结果和目标，然后倒推怎么达到这个目标，之后再启动执行。
Working Backwords是一提高工作效率的极为有效的方法，因为几点：
做任何事情，我们一定要先清楚目的和目标；
很多时候，我们对问题或任务只有一个模糊而不清晰的了解；
如果对要解决的问题和任务有清晰的描述，其实问题已经解决了一半；
不仅问题很清晰，而且解决的步骤、计划反复推演了，问题已经解决了大半；
初期的投入时间多，都大大节省了后续的时间，而且让任务的完成时间可预期。
细看涛思数据过去4年多的发展历史，如果仔细分析，我们所有高效完成的任务一定是有意或无意中执行了“Working Backwards"的原则。对于效率差的，一定是偏离了这条原则。大道理一听就明白，落实到我们具体工作上，特别是产品的研发上，我们要怎么做呢？对于任何一项新功能，大版本的开发，我们应该有一个什么样的工作流程呢？按照这条原则，我们做事的先后顺序是：
1：起草新功能、大版本的宣传稿
这个新闻稿不能太长，原则上不能超过一页。在这个简短的宣传稿里，我们需要给用户清晰的介绍：
新的功能和特性；
这些功能和特性能给用户解决什么问题；
这些功能和特性能给用户带来的价值，列出三点而且至多三点；
这些功能和特性与竞品相比，好在哪里，列出三点而且至多三点；
这个新闻稿，不仅自己看，还要给销售、BD同学看，给潜在的客户看，看是否能打动他们体验一下产品。如果没人动心，说明工作的价值不够，或者是亮点没有突显出来，让大家意识到它的价值。
2：起草好用户手册
用户怎么使用这个产品至关重要，具体而言，用户手册需要包含：
用户有那些方式使用，SQL的支持, connector, API, 编程语言等；
用户如何配置进行个性化设置；
用户如何监测产品的运行；
用户如何从老版本升级；
用户如何从其他系统迁移；
用户如何快速验证性能指标
只有起草好用户手册，我们才真正的将需求细化、落实，才能与需求方完全确认是否满足需求。也只有起草好用户手册，测试团队才能尽早介入。
3：模块划分，定义模块API
产品定义清晰了，就需要真正做设计了，进行模块划分。怎么划分模块，包括源文件的目录结构，有自己的规则。但无论如何划分，我们需要做到：
模块对外服务的API有清晰的定义，输入参数、输出参数，是否线程安全等，都有清晰说明
模块的性能预期，验证工具
模块对外的依赖很清晰
划分了模块，而且定义了模块的API，实际上就是将模块的功能完全确定了，也就是对模块的需求完全确定了。更进一步，我们需要马上将所有模块集成，所有模块的API都可以是一个dummy的实现，而且马上将整个系统纳入到公司的CI/CD流程，要让它跑起来。这样做，有几个明显的好处:
如果测试组人手宽裕，这个时候就可以介入模块的功能测试和性能测试了;
任何人都不能随意修改API，而影响依赖它的模块；
人手不够，可以将某个模块外包，或先用第三方软件代替；
对于极为关键的模块，可以启用两个team并行开发；
4：模块本身的设计
定义好模块对外服务的API后，我们就可以着手模块本身的设计了。模块设计的原则在本博客不做讨论。
5：编码、测试，不断迭代
在模块设计定稿后，就可以开始编码，进行模块测试了。而且由于CI/CD已经跑通，随时可以跑整个系统的测试，每天都会看到有新的PR，有功能在实现。
以上五步，其先后顺序极其关键，必须按照顺序执行。表面上看，这个流程与我们倡导的敏捷流程有矛盾，但其实不是。敏捷流程强调的是一个一个Sprint完成工作，是小步快跑。上述流程是更大的产品开发流程。
在我们以前的产品研发过程中，我们都没有主观意愿按照这个顺序进行，必须纠正过来。
除产品研发工作之外，我们在销售、市场的工作也应该执行这个工作原则，而且这个工作原则与我倡导的《做事的四个原则》是完全一致的。可以说，"Working Backwards"这个原则在销售、市场工作的更具体的执行，是《做事的四个原则》。
陶建辉
2021年10月3日于北京望京
👇 点击“阅读原文”，体验 TDengine 3.0！
