我当上技术主管那天，翻遍了团队所有人的代码仓库。每个人都懂Python，会写类，会调包。但项目交付速度反而慢了。问题出在哪。
最缺的不是技术，是工作流视图。一个人写代码是线性的事。五个人写同一个模块，依赖关系就乱了。有人等你写完接口，有人等你改完数据库迁移。这些等待的时间，比写代码的时间还长。
我画了一张图。这张图不是架构图，不是流程图。是真实开发流程里的时间轴。每个人在什么阶段开始写哪段代码，谁必须等谁完成。这张图拿出来那天，组里最沉默的老张说了句：早该这样干了。
以前我们这样开会。产品讲需求，技术评估排期。大家点头，然后各干各的。第三天发现，A的接口和B的数据结构对不上。第五天发现，测试环境缺一个第三方服务的密钥，没人提前申请。第七天通宵改代码。
这张视图长什么样子。纵向是本周五个工作日。横向是模块名：支付、登录、商品列表、后台管理。每个格子写一段话：“张三建表，预计4小时，阻塞项：等运维开数据库权限”。旁边标一个红色三角形。李四写支付回调，边上写着：“依赖张三的表结构，最早周四下午开始”。这张纸A3大小，贴在白板上。每天晨会，大家站在这张纸前面说话。
效果很直接。第二周，没有人问“你那个接口写完了吗”。因为纸上有。第三周，老张主动说：我这个模块提前两天完成了，你们有需要我帮忙的吗。以前没人说这句话。大家觉得各管一摊，帮别人是额外的活。现在不行，纸上是联动的，你不帮他，你的时间轴也拉长。
工作流视图的核心不是管理，是暴露依赖。Python工程师技术都够硬。但多数人不善言辞。他们觉得沟通浪费时间。他们埋头写，写到一半发现前面有个坑。这个坑是别人的问题，但他不会主动说。视图把依赖明明白白画出来，不用他说。
有一次，一个新来的同事在视图上看到自己的模块有个前置任务。他跑去找那个负责人，发现对方请假了。他在群里喊了一句，没人回。他直接找了我。我帮他协调了另一个同事。这事放在以前，他要等到那位同事回来，白白耽误两天。视图让他提前发现了这个阻塞点。
还有一件事。视图上有个格子是“联调测试”，连着五个模块。以前联调都是到最后一天才做，然后发现各种接口对不上。现在视图上提前一周就标了这个时间点。负责联调的人从第五天就开始盯进度，看谁没写完，提前催。联调那天，一次通过。
我带团队之后才明白，技术好的人容易陷入一个误区。他们觉得流程是束缚，文档是形式主义。但真正拖慢效率的不是你的代码写得不够快，是你的代码写完了，别人不知道。是你等别人，别人也在等你。这张视图就是打破信息黑箱的工具。
你现在问组里任何一个人：这周你什么时候开始写支付模块。他能立刻说出来。以前问同样的问题，他要想想，然后说“大概后天吧”。后天是周几。他也说不上来。视图让大家对时间有了共同的锚点。
写一个Python装饰器很简单。设计一个类继承体系也不难。但让六个人在两周内无冲突地完成同一个系统，这张视图比任何设计模式都重要。它不是技术。它是技术之间的胶水。
