最近作为项目 TO 在公司内完成了一个涉及面比较广的项目，对于如何推动项目上线有一些经验和大家分享。希望刚毕业几年、没有参与过大型项目的同学，从中能学到一些方法，为今后担任项目主力做一些准备。

所谓的 TO，是 Technical Owner 的缩写，是一个项目的技术负责人。互联网公司里，每个需求都需要确定一个 owner，他负责需求的方案评审、进度对齐、问题解决、整体上线。大一点的项目，就要强调 TO，PO（产品 owner）这些，当然这时一般会有 PMO 参与进来。TO 的职责包括但不限于分析业务需求和技术方案的可行性、确定开发所需的技术栈和工具链、制定系统架构和设计文档、跟进开发进度和质量、组织联调和测试，保证系统的稳定性和可靠性，以及跟进上线和后续维护工作。一个优秀的 TO 能够确保项目顺利进行，达成预期目标。

下面我从技术方案、进度管理两方面展开，总结从本次项目里积累的经验。

技术方案

一般大一点的需求都需要在开发前做技术方案评审，也就是所谓的 trd（Technical Requirements Document）评审，它为后续项目的顺利进行打下基础。在技术方案中，不仅要考虑到功能的正确实现，也要考虑非功能性需求，也就是稳定性需求。

业界经常谈的所谓的稳定性三板斧：可监控、可灰度、可应急，这几点一般要在方案中讨论到。

实现功能是最基本的要求，否则不可能上线。但是稳定性同样不可忽视，区别初级工程师和高级工程的一个很重要的点是：能否给出稳定性方案。

总体视角

总体视角对 TO 来说是很重要的。

在一个大项目里，如果只是负责其中的一小块，例如你的服务只是提供一个接口，那可以只关注自己的服务。作为 TO，即使你自身负责的服务改动比较小，也必须关注整体的改动点，将全链路串连起来，包括上下游的依赖关系、数据的流动方向。否则，一个小问题可能就会阻塞整个项目。

梳理项目全貌

写技术文档的时候，需要理清项目全貌。

从 APP/Web 端，到网关，到后续的服务，整个调用链路需要理清。谁调用谁、谁依赖谁，这些都需要摸清楚，后续发布计划会用到。

另外，数据链路也需要理清，从数据源到途经的服务，到最后的落库都需要理清。代码逻辑的回滚相对来说很好做，但涉及到数据的回滚是很难的。因为数据一旦落库，用户已经感知到，或者老数据被覆盖，是很难回滚的。因此梳理项目全貌，提前考虑回滚方案是很有必要的。

把握关键技术细节

如果只是粗浅的了解了项目全貌，其实是不够的。关键地方的细节还要深入研究一下，魔鬼都在细节里。

例如有的服务只是调用接口进行页面展示，那只用了解到这一程度就够了，至于接口字段和页面内容的对应关系就不用深究了。

但是有些服务调用接口后，会根据结果做进一步的计算，那就要多问一步：我们的服务这样改动后，对你的影响是什么？你要做的对应改动是什么？为什么？

题外话，我自己就遇到过一次细节不清导致的事故。我弄错了接口对于不同类型的账户（例如子母账户）的不同表现，据此写的代码的计算逻辑全错了。一个接口的逻辑实现有非常多的细节，但可能关键的就那么几个，我们要掌握它们。

梳理全系统的改动点

技术文档里的一个核心要点就是梳理全系统的改动点。作为项目 TO，有责任弄清所有改动点。虽然不可能每个细节都弄清楚，但大致的依赖关系，数据流向还是得弄清。

识别关键人

如果涉及的系统非常多，而我们又不可能了解所有的服务，那应该如何快速理清改动点？

一个好的办法是找到关键人。每个服务可能会涉及 PM、RD、QA，有些是真正写代码的，有些是合周报的……我们要定位到核心负责人，通常是写代码的那一位，然后向他请教。

我通常的做法是先自己根据已有的文档做出自己的理解，过程中提出一系列问题，列在文档上，再约相关的人语音会议，会上对着文档依次讨论。必要的话，还可对会议进行录屏，避免遗忘。

分析上下游依赖

分析服务间的依赖关系非常关键。一方面有助于我们理清全系统的改动点，另一方面，有助于我们制定发布计划。被依赖的服务应该先上线，依赖服务后上线。如果没有弄清依赖关系，很有可能导致事故。

梳理依赖关系时可以用架构图来表示，在图上的连线里用 1/2/3/4 标出请求或都数据流向的步骤。当然也应该用时序图来梳理业务流程。

制定发布计划

项目最终是要上线的，我们在写 trd 时，就应该考虑到上线方案要怎么做。

当整体进行提测后，我们就应该把精力全部放到发布计划上了。

发布计划通常包含：各系统的发布顺序、中间件变更（如数据库的变更、新 topic 申请）、发布关键节点、稳定性三板斧……

首先，我们依据服务间的依赖关系，列出各系统的发布顺序，在发布当天，严格按照顺序进行发布。

其次，一些中间件的变更应该提前一天完成。例如创建新表，增加表字段；申请新的 kafka topic 等等。

另外，发布计划还应该考虑到时间节点。当涉及到的服务变动特别多时，可以考虑分批发布，例如某些旁路的服务提前一天发布到线上，这样可以给关键的服务留下充足的变更时间，出了问题也能有更多时间处理。

发布计划通常也要包含关键节点，例如 XX 服务发布后，系统某些地方就能感知到部分变更，这时应该设置检查项，发布当天对照这些检查项进行检查，没有问题后，再进行之后的发布流程。

最后，稳定性相关的问题一定要着重考虑：可监控、可灰度、可应急。

我个人的习惯是每个新需求开发之前都先想一下与之对应的监控项应该怎么定义。通过监控项，我们才能在服务上线后方便地判断变更的逻辑是否正确。例如，上线了一项功能是过滤掉不合规的用户，那么这时就可以增加一个过滤掉的不合规用户的 QPS，如果上线后观察到 QPS 与预期的不符，就要去排查。另外，如果变更会对性能带来比较大的影响，那就应该增加性能监控项，发布时关注性能是否有问题。

灰度其实在互联网公司里是很常见的思想。通常我们发布时会按小流量、中流量、全量的顺序推进。而当我们发布一个新功能时，对于灰度就要考虑地更多了。

灰度是为了控制发布失败时影响的范围。通常的方案包括按用户 ID 的尾号、城市进行灰度。例如我们先让尾号为 0 的用户看到最新的变更，即使发布过程失败，影响的也只是这一部分用户，损失会降到最低。

可应急指的是一旦出现问题，应该如何处置。如果服务只有逻辑上的变更，直接回滚代码就好了。但是通常逻辑的变更会带来数据的变更，涉及到数据的变更就没那么方便回滚了。这一块要详细设计回滚的流程，最好是在预发环境进行充分地验证。

进度管理

一般而言，研发做项目 TO 时，技术方案上不太会有大问题，但进度管理可能就不太顺畅了。即使项目有 PMO 把控进度，我们也应该学习一些进度管理的方法。毕竟不是所有的项目都会有 PMO 参与，而且了解各方的资源和进度也是 TO 要做的事情。

协同管理

在 prd、trd 时期，我们应该与各业务方，各协作方进行良好的沟通，确保各方的目标一致。在项目进行的过程中，对于可能存在问题的地方，也需要与他们密切沟通。

这里还是要强调：识别关键人是非常有用的一招。涉及到很多业务方的需求，我们不一定记得住所有人，但是关键服务的关键人一定要记在文档里，遇到问题可以第一时间找到关键人。有时关键人不一定能处理，但是他一定能帮助 TO 找到对应的人。

排期与关键节点

在 trd 评审完成后，排期时间就应该全部确定，包括提测时间、测试时间、预发布时间、正式发布时间。有些倒排项目，排期是先于 trd 时间确定的，这时就应该倒排法确定各个节点的时间了。

排期需要得到各方的确认。每个改动方都应该知晓关键的时间节点，例如提测时间、正式发布时间等。有些服务方改动点比较小，手上还有其他优先级比较高的项目，提测时间不一定能赶上，但经过沟通，只要能赶上正式发布时间就可以，那也没问题。

对于非常大的项目，还需要设立多个交付节点，分阶段提交成果。否则，都积累到最后一批提交，很可能就是灾难了。

风险识别

对于一些倒排项目，trd 提出的方案不一定是最优，如果存在一定的风险，要提前指出来，并且要做好应对方案。

对于我做的这次项目而言，涉及到了数据的变更，在正式发布前，我们对生产数据进行了预计算，发现其中的某项数据有问题，不合预期。于是在发布前我们找到业务方、PM 进行协商，并对方案做了一定的更改，最终项目得以顺利上线。

当然，有同学可能会说，这应当是在项目初期就做的事情。具体到这一件事情确实是这样，但是有些倒排项目不一定给你留了足够的时间，所以最后一道关就是在正式发布前做一下验证，确保万无一失。

周会与日会

一旦项目进入正式开发后，应当召开周会或日会，及时同步各方进展、遇到的问题、风险。

作为 TO，在对齐进展的时候，应当化身 PMO，假装我们不知道任何项目的细节，只问进度。我自己的经验是，因为我不是一个能必安理得 push 别人的人，而且有时候会默认考虑到项目的细节，觉得他这块会比较麻烦，所以就不太好意思追问进度。但在会上，需要抛开自己的研发身份，纯粹以一个 PMO 的视角来问进度，如果进度不理想，那就要追问解决措施是什么。一旦“切换”了身份，会发现问进度是最简单的事情。

一个小细节是会前要准备好文档。不要直接上来就尬聊，当你有准备的时候，一定是会给其他人好印象的，对方大概率也会认真配合的。

其他

前不久，我在 Go 夜读分享了自己使用 things3 管理项目的经验，其中讲到的需求开发模板可能会对你有帮助：

最后

工作这几年下来，开发一个需求并推动上线早已不是问题，但涉及到众多合作方并作为项目技术 TO 的项目还是第一次。过程中，不仅要考虑自身所负责项目的开发，还需要整体考虑所有业务方的改动点，还是有一些挑战的。做完这个项目之后，自觉执行层面就没啥大问题了。