技术管理 之 生产之路（Path to Production)

原文参见本人博客：https://www.maguangguang.xyz/path-to-production

在各种场合，经常听到新晋的 Tech Lead 抱怨大部分时间都淹没在各种事情的海洋里，每天都很忙碌，需要参加很多会议，有各种问题需要处理，早晨的日历上还有很多时间可以安排，转眼间就被一堆突发的事情占满了：

CI 流水线挂了，需要有人去修复。

技术方案漏了个边界场景，产品无法上线。

生产环境的基础设施有问题，没法部署新的代码。

积压了好多卡等待测试，测试资源不足，按时上线有风险。

……

作为 Tech Lead，总感觉一切都不太受控制，每天都做着似乎跟技术无关的事情，逐渐从一个编码工程师向 PPT 工程师转变，没有成就感不说，每天被突发的问题包围，一团乱麻，理不出个头绪。回想自己作为开发的时候，只需要专心于编码，其他事情都有人在处理，为什么现在大家都很忙，但仍然还有好多事情没有人在处理。

在这种情况下，相信会有人说 Tech Lead 的时间管理没有做好，导致很多事情没有时间处理。时间管理确实是摆在 Tech Lead 面前的一座大山，然而，我认为 Tech Lead 首先需要对团队中出现的问题有一个整体的认知，厘清问题根源所在，排列优先级，让问题得到解决，才能给自己腾出更多的时间来。

Tech Lead 需要一个抓手，一个能够厘清团队现状的抓手，可视化通常是一个非常有效的手段。在软件开发这个上下文中，将软件开发整个生命周期中的关键环节尽可能详细地可视化出来，列出每个环节存在的问题，不仅能够帮助 Tech Lead 掌握当前项目的技术、流程全貌，也能帮助 Tech Lead 分析出团队在整个过程中的瓶颈点。

什么是 Path to Production

Path to Production 就是这样一种可视化手段，它是 Value-Stream Mapping (VSM，价值流图) 在软件开发上的应用。Path to Production 将软件产品开发类比为传统制造工厂中的流水线，并将这条流水线上的必要信息可视化出来，通过梳理软件开发生命周期中每个阶段的内容，找到瓶颈点。

为了有效识别问题，Path to Production 通常需要可视化如下信息：

• Process 流程：从产品需求定义到编码开发，到验收测试，最后发布到生产环境给用户使用，尽可能详细地列出软件开发中的每个关键步骤。

• People 参与者：哪些关键角色触发/参与到这个步骤中。

• Tool 工具：该步骤具体用到了什么工具。

• Artifact 产出物：该步骤有哪些约定的产出物。

• Duration 时间：该步骤实际花费了多长时间，是否存在优化空间。

上图是 Path to Production 的一个简单例子，通常实际的图会远比这个复杂，应该尽可能把关键的步骤都列出来，更详细地展开，才能更直观看到问题。

Path to Production 要点

Path to Production 实施通常需要一个 Workshop，Tech Lead 组织团队中关键角色代表（如果人数不多，团队成员可以都参与进来），集体协作产出如上图的 Path to Production。

过程中可以通过下面的要点对 Path to Production 进行完善：

1. 流程需要包含所有步骤，尽量详细，不确定的步骤可以进一步找到对应的干系人进行确认，明确每个步骤存在的价值。

2. 要明确所有的参与者对自己的职责是否清楚，是否有沟通计划保证各角色之间的信息传递是高效的。

3. 工具的使用是否符合规范，是否有 license 和权限的问题，工具是否高效，有没有更好的工具。

4. 产出物是否有清晰定义，是否和关键干系人有时间上的约定，实际操作中是否按预期产出，如果没有产出，是否能够重复生成。

5. 有哪些浪费时间的步骤，是否有工作积压或等待的情况发生，是否有更好的办法，瓶颈在哪里。

在一个自治的敏捷软件开发团队中，保证开发过程顺利且高效从来都不是某一个人的职责，而是全团队所有人共同的责任。Tech Lead 责无旁贷需要引领团队构建这样的团队文化，产出 Path to Production 是一个比较好的方式，一方面帮助团队理解整个产品从需求到部署到生产的整个过程，另一方面也能让所有人通过这个过程理解团队中存在的问题，激发团队成员的自主性和责任感。