敏捷的意义：BOSS, 我们要不杀个 PM 祭天？

最近在做一些自己的小东西，在做的过程中发现了一个小问题：想和做如何协调？做一个功能的时候会想到另一个功能，生怕忘了，赶紧做一点；做了一会儿，突然想到前面的功能貌似还没完成，赶紧去补补…在这样的反反复复的过程中，很容易拖累进度。想了一下以前曾经和我的一个团队共同使用过 Teambition 这个协作工具。它可以认为是一个电子看板，用它我就可以像以前做敏捷一样有计划，有记录地开展工作了。

这让我想起了在前厂的敏捷实施过程中遇到的一些问题，于是想聊聊我的一点看法。在我看来，敏捷中最为核心也是最为精华的部分就在于看板。看板提供了以下几个作用：

1. 工作内容记录
2. 工作进展状态展示
3. 项目实施顺利程度
4. 团队工作量汇报

我突然想起来曾经做过的很多项目实施过程是这样的：

1. PM 告诉我用户需要实现 ABC 功能用户很着急需要快速完成。
2. 我们加班加点紧赶慢赶完成了 80%。
3. PM 告诉我们，客户需求改了，A 功能砍掉，B 要改成 b，C 要改成 C+D，另外再加 E 功能，还要把流程改成 λ，用户很着急要快速完成。
4. 我们加班加点紧赶慢赶完成了 80%。
5. 重复以上步骤 N 次。

接下来你将遭遇到的是：

1. 用户投诉：你们的开发干什么吃的？就那么一丢丢功能怎么做了那么久还没做完？
2. BOSS 谈话：你们团队怎么回事？这么点用户需求都完成不好？此时你一定会说：明明是他们一直改需求啊~
3. PM 会说：是的，用户确实改了一丢丢需求，但是不多啊，我都尽量帮他们回掉了！
4. 此时你只剩下心中的一千万头神兽奔腾而过，只留下 PM2.5 笼罩在你那比天空还宽广的心中。

这样的场景我想我不是第一个遇到的，也一定不会是最后一个遇到的。如果可以，PM 一定会被我按地上摩擦...明明是你无法引导好用户，尽责调研用户需求，为什么要开发来背锅？但是，你无处申诉，因为谁都说不清用户究竟改了多少需求，增加了你多少的工作量。BOSS 哪怕愿意帮你，也无从下手。（ps:我是经历过当传话筒的 PM，也因为曾经年轻气盛而向 Leader 要求坚决不再与其合作。现在看来还是图样图森破啊...）

这样的死局直到我遇到了敏捷，我觉得我似乎找到了对策。敏捷提供了一套工作过程记录方案，他并不排斥需求更改，只是简单地做了一件事：把更改所产生的工作记录下来于是再次遇到多变的需求时你的工作会变成这样：

1. PM 要求需求变更
2. 把 PM，开发，测试拉一起，共同商议新增的工作量
3. 把新增的任务贴到看版上，并记录变更
4. 更新燃尽图

如果上面的例子用了敏捷方法，那么它的燃尽图应该是这样的：

画美不看…此时如果我们经历了疯狂的需求变更后洗礼后用户再次投诉进度缓慢，怎么办？

请把这张大家共同确认过的图交给您的 BOSS，顺便问一句：

BOSS,我们要不杀个 PM 祭天？

我的公众号欢迎各位关注