用 Tech Plan 来为开发提速
在软件开发行业中，如何更好、更快、更高效地完成一个项目，是一个永恒不变的话题。即便经过了几十年的讨论和发展，软件工程领域也依然没能给出一个很好的答案。很多软件开发团队的产出依然不尽如人意。大概半年前，我们的团队就经历了两次「开发事故」：
预计只要一个月开发的功能，半年过去了依然看不到头
在开始计划一个重要功能的时候，团队里的程序员看过设计，想了一下工作量，预计只需要一个月就能完成这个功能。
然而，在接下来的半年里，原本看似简单的需求里加入了更多的细节；在迁移老系统时，又发现了一些旧有的限制，花了更多的时间；完成功能之后，又有数不清的 bug 出现，经过反复修改才部署到 staging 服务器上；客户测试之后，又提出更多的 feedback。
六个月的时间就这么过去了，这个重要的功能却依然看不到能够上线的曙光。
团队里有足够多的开发者，却花了很多时间开发重复的功能
有一个项目有着比别的项目更多的前端开发，但是产出却并不比其他项目更快，更好。在回顾的时候，我们发现，有好多功能都被不同的人重复实现了一遍。这些重复劳动，直接导致了团队效率的下降。
总结了这两起「开发事故」的经验教训，我们开始在团队内部推行 Tech Plan。希望通过更多的计划，和围绕计划的即时沟通、及时反馈，来提高团队效率，防止类似的「事故」再次发生。
这篇文章就是我们对 Tech Plan 的理解的一个总结：对我们这样的开发团队来说，什么是 Tech Plan？这样去做 Tech Plan 有哪些利弊？我们要怎么去做 Tech Plan？希望看过这些问题的答案之后，你也能学到一些经验，应用到你的团队中去。
什么是 Tech Plan？
首先，我相信所有程序员都已经在做 Tech Plan 了。至少在我们敲下每一个字符，写下每一行代码，做出每一处修改之前，我们的脑海里或多或少都已经有了一个 Plan：
- 为什么要做这个修改？
- 要怎么修改这些代码？
- 这样修改有什么效果？
写代码，只不过是执行这一计划的过程。写好代码之后，我们通过测试、运行等方式收集对我们这一计划实行情况的反馈，再进行新一轮的计划，或者完成一个功能。我们日常的开发过程就是这么一系列的「计划-执行-反馈」的反复。因此，本文探讨的 Tech Plan 也恰恰包含了上述的三点：为什么，怎么做，期望的结果。
但是，Tech Plan 的重点并不是 Tech Plan 这一文档本身，而是 整个团队一起去做 Tech Plan，一起讨论，一起计划的过程 。一个写得很好看、很工整的 Tech Plan，如果不是整个团队一起商讨的结果，也很可能只是徒增了前期的工作量，并不能帮我们解决开发周期变长，大量重复劳动等问题。而如果团队全体成员一起讨论过，达成了一个最佳方案的共识，即使没有把这个方案写得很好，只要能顺利施行，也是一次成功的 Tech Plan。
为什么要做 Tech Plan？
讨论 Tech Plan 的过程为什么能够帮我们提高开发效率呢？因为这个讨论是开发者收集对实现方案的反馈的过程，而这个过程对比通过代码实现完功能之后再收集反馈的方式，成本更低，更及时快速。
一起讨论修改代码的原因，是整个团队一起明确需求的过程。而这个过程，能够帮助我们补充 PM 和 Designer 可能无法想到的细节。这是从开发团队给到 PM 和 Design Team 的反馈。可以有效地减少「功能实现了一半，再去补充需求细节」的情况发生。
一起讨论实现方案，是为了让我们充分发挥团队成员的能力，提出尽可能多的方案，并进行分析对比。这是开发团队内部的反馈。这样即时的反馈可以避免很多重复的工作，也能减少在 Code Review 环节中发现代码架构实现不对，却来不及返工修改的情况。
一起讨论修改可能导致的效果，一来可以快速验证实现方案的正确性，减少 bug；二则可以及时发现要做的改动对已有功能的影响，避免破坏已有的系统。
怎么做 Tech Plan？
明确了「一起讨论的过程」才是 Tech Plan 的价值所在之后，我们需要知道该如何去组织、引导这个过程。
明确需求
首先，我们要明确来自客户的需求到底是什么。我们可以阅读需求文档来总结、消化需求。但也不仅仅局限于这一种方式。更好的情况可能是直接参与到用户、客户、PM、Designer 的讨论中去，一同确定需求，及时地把来自开发的角度的反馈给到他们。
讨论方案
需求明确了之后，我们就可以开始讨论方案了。每个团队成员都可以先给出自己的方案，然后一同讨论各个方案的优缺点，最终得到一个最优、最适合这个项目的解决方案。
及时记录
有了需求和方案之后，我们可能还要将它们记录下来，以供之后查阅。虽说讨论的过程是最重要的，但如果讨论的结果不记录下来，也会影响到之后的实现。这些记录可以保存在 issue 里，wiki 里，或者代码库的文档中，每个团队有最适合自己的记录媒介。
当然，这些过程都不一定要通过会议的形式完成。结对编程（Pair Programming）的时候也能采用类似的方式：先讨论需求，然后讨论实现方案，确定方案后进行简单记录，就可以直接实现，快速迭代。这也是 Tech Plan 思想的体现。
Tech Plan 的弊端
当然，施行 Tech Plan 也不是没有它的坏处的。
首先，做 Tech Plan 的过程会花去大量的讨论时间，对整个团队的规划、时间分配的合理性要求更高。如果规划不当，很容易花大量时间讨论不同的方案，却无法讨论出结果，无法将讨论变成成果产出，得不偿失。这种时候，可能要先决定一个方案施行，再看效果来决定。
其次，难以把握 Plan 的尺度，对开发人员的水平要求更高。好的 Plan 能够用最小的成本获得足够的反馈。过度的 Plan 就几乎等同于将方案实现一遍，也就失去了低成本获取反馈的意义了。
因此，要明确讨论 Tech Plan 的目标：「低成本获得反馈」，再不断练习，才能找到最适合项目、团队的解决方案。