在各种场合，经常听到新晋的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进行完善：
- 流程需要包含所有步骤，尽量详细，不确定的步骤可以进一步找到对应的干系人进行确认，明确每个步骤存在的价值。
- 要明确所有的参与者对自己的职责是否清楚，是否有沟通计划保证各角色之间的信息传递是高效的。
- 工具的使用是否符合规范，是否有license和权限的问题，工具是否高效，有没有更好的工具。
- 产出物是否有清晰定义，是否和关键干系人有时间上的约定，实际操作中是否按预期产出，如果没有产出，是否能够重复生成。
- 有哪些浪费时间的步骤，是否有工作积压或等待的情况发生，是否有更好的办法，瓶颈在哪里。
在一个自治的敏捷软件开发团队中，保证开发过程顺利且高效从来都不是某一个人的职责，而是全团队所有人共同的责任。Tech Lead责无旁贷需要引领团队构建这样的团队文化，产出Path to Production是一个比较好的方式，一方面帮助团队理解整个产品从需求到部署到生产的整个过程，另一方面也能让所有人通过这个过程理解团队中存在的问题，激发团队成员的自主性和责任感。
