北京
把一条交付流水线摊开来看，不看甘特图，看真实的时钟。你会发现一件让人不太舒服的事：一个功能的大部分交付周期，并不是花在"做这个功能"上，而是花在"人跟人之间"。
需求文档躺在评审队列里。设计稿等着签字确认。构建产物等着测试排期。精益实践者已经量化这件事几十年了，数字几乎没怎么变过：总交付周期里超过一半、常常是70%甚至更多，都是排队时间。没人在做那件事，所有人都在等一个"可以开始"的许可。
我们这样跑了很多年。也像大多数交付组织一样做了那些事：更严的SLA、更好的模板、更详细的工单、再加一个同步会。花了很久才意识到，我们一直在调那条链子，而链子本身就是问题。
交接债其实是两笔债，只有一笔会出现在账面上
第一笔是看得见的债：闲置时间。每个工种的启动条件，都是另一个工种的完成条件，而且这种阻塞不是部分的，是彻底的。
看"需求签字"进行时每个位置在干什么：开发不能开始，范围在官方口径里还是流动的，现在写的任何代码都算"有风险"，理性选择就是等。测试被双重卡住——每个用例都得追溯到一条已签字的需求，所以测试连一个用例都设计不了，测试数据准备不了，自动化脚手架也搭不起来；就算签了字，没有构建产物也执行不了任何东西。于是本该是整条流水线里最需要深思熟虑的测试准备工作，被压缩到最后几周、在截止压力下赶出来。
与此同时，组织里最贵的那批人，在每个项目的前段按合同规定闲着。
而签字不是一个时刻，是一个循环。初稿发出去，客户要花几天评审，人家有自己的生意要跑；意见回来时已经脱离了上下文；澄清会排上；新的干系人带着新的意见出现；第二版发出去。三到五轮这样的循环是常态，每一轮往返都增加日历天数，同时往往还减少清晰度。我们见过两到六周就这么过去。零代码，零测试，一整支团队停在一份文档后面打乒乓。
最难接受的一点是：这根本不是纪律问题。排队不是谁表现不好造成的，它是串行工作的结构性属性。丰田七十年前在车间里就想明白了这件事——批量交接就是浪费。你没法靠管理手段走出一个你的流程本身就在制造的队列，你只能重新设计流程，让队列压根不形成。
第二笔债：语义传话游戏
隐藏的那笔债更糟，因为没人给它记账。每一次交接都是一次翻译，每一次翻译都会丢东西。客户意图变成需求分析文档，变成设计稿，变成代码。等测试去验证构建产物时，他们验证的已经是第四手的转述了。
原文在这里截断，后续内容未提供。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
