当瀑布遇上敏捷:一段混合交付的故事
一家中型公共机构聘请了一家供应商,替换其老旧的审批许可系统。合同为固定价格,并带有刚性的法规上线期限——这是瀑布式计划的典型条件。然而需求确实模糊:在亲眼看到之前,没有人能完整描述新流程应当如何运转。团队分散在三座城市,在上一年办公室关闭后远程办公,决定把两个世界融合起来。下面就是这种混合模式的样子,以及它带来的教训。文中姓名与细节已作改动。
他们如何划分工作
对于那些确实无法挪动的事项,团队保留了一条瀑布式的主干:法规上线日期、数据迁移窗口,以及安全认证关卡。它们成为主进度表上的固定里程碑,每个都有明确的负责人,以及一个所有人都当真对待的日期。
在这条主干之内,开发本身以两周为一个冲刺推进。产品负责人——来自该机构而非供应商的一位资深分析师——维护着唯一一份按优先级排序的待办列表。每两周,团队都会向真正的许可办事员演示可运行的软件,他们随后会重新塑造下一个冲刺。固定日期告诉所有人列车必须抵达何处;冲刺则决定每节车厢装载什么。
差点出岔子的地方
这种混合模式起初并不顺畅。三个问题很快浮现,而它们正是多数混合项目都会遇到的。
两套汇报语言。 指导委员会想要的是相对于计划的完成百分比,而团队是以可运行的增量来衡量进度。有两个月,状态报告互相矛盾。他们的解决办法是把已完成的待办项映射到它所支撑的里程碑,这样一张图就能同时服务两类受众。
并未真正冻结的冻结范围。 由于合同是固定价格,每一次变更都像一场争斗。团队引入了一套轻量的变更流程:冲刺内部的小调整免费,但凡是触及固定里程碑的,都要经过一次简短、有记录的影响评估。仅这一条规则就大幅减少了摩擦。
远程的沉默。 分散在三座城市,团队把沉默误当成了赞同。一名开发人员花了一周时间构建了错误的校验规则,只因一项在聊天中作出的决定从未传到他那里。他们把关键决定转移到一份可书面检索的日志中,并让每日站会成为公开点名障碍的场合。
值得借鉴的经验
到上线时,系统在法规规定的日期交付,带着办事员真正需要的功能,而那些不可避免的取舍落在了较低优先级的事项上,而非法律所要求的事项上。回过头看,团队把成功归功于几项任何混合项目都能照搬的习惯。
明确说明哪些部分是固定的、哪些是灵活的——并且绝不让这条边界变得模糊。
保持唯一一份待办列表和唯一一位决定优先级的负责人,即使进度受里程碑约束。
把进度转译成一幅共享的图景,让高管与团队读到的是同一个现实。
让冲刺内部的变更成本低廉,而触及固定日期的变更则需慎重。
在远程团队中,把决定写下来;口头的共识会蒸发。
混合交付并不是一种谁都不满意的折中。若是有意识地推行,它既能让你信守固定的承诺,又能在过程中发现正确的解决方案——而这正是这个项目所需要的。
如果你正在固定期限与不确定需求之间寻求平衡,并希望有一套契合实际工作的交付方法,XNM 的项目集与项目交付咨询服务可以帮助你设计并落地执行。