↑↑点击上方蓝色字体可快速关注↑↑
上篇文章说，当产品经理提需求的时候，我们要微笑面对。今天我们再来谈谈变更类的请求。
变更类的请求可以分为两类：
一类是需求的优化，一类是需求的反复变更。
第一类需求大家比较容易接受，因为迭代开发从本质上说就是在一个产品上不断的优化。
大家比较难以接受的是第二类，需求反复变更——今天我要A，明天我要改成B；A改成B了之后，我又觉得还是A好。
对于这类变更，首先要接受的事实是：改需求是不能完全避免的，因为人无完人。
开发不能保证自己的代码一次性写对；测试不能保证自己测试过的产品完全没有bug；同样的，产品/用户也不能保证自己提出的需求一次性就提对。
所以如果发生这样的情况，要理解：这就是世界真实的、不完美的样子，并且——保持微笑。
心态调整好了，我们再来讨论如何减少需求的反复变更。
有很多的原因都可能导致需求的反复变更，今天我们先讲最源头的一种，以及如何从这个源头开始减少需求变更。
从一个故事说起。
有个小型创业公司，他们公司有十来个跑业务的人上午要出去跑业务，中午才能回到公司。
这导致这些人没有办法在PC端的订餐系统提前订午餐。
他们给公司的IT提了个要求，要做一个手机端的订餐系统，以便于他们外出的时候订餐。
IT做了很久都没有把这个系统做好，跑业务的同事很不满意。
终于有一天，业务和IT吵起来了，引起了全公司的注意，包括坐在一角的老板，和坐在前台的MM。
前台MM走上前说：
“从我这边的外出登记来看，你们不是天天都要出去，有时候出去的人也不是很多。这样吧，以后你们登记的时候，把自己要订的餐也登记上，我帮你们订了。这样行不行？”
空气突然变得安静——问题解决了。
故事讲完了。
现在开始做阅读理解。
请问：在这个故事里，业务同事的真实需求是什么？
A.做一个手机订餐系统。
B.给IT同事找茬。
C.在外面跑业务回来了也能吃上午饭。
答案是C.
A只是用户为了满足需求想出来的解决方案。
B，每个人的工作都很忙好嘛？
所以：
从一开始，就区分用户的真实需求和用户为了满足他的真实需求提出的解决方案。
只有这样，研发团队才能在理解需求上，始终走在用户的前面（而不是被用户带着跑），更有利于切中用户的真实需求，减少变更。
————END————
你可能也对下面的内容感兴趣：
如何管理用户期待——研发团队如何应对来自多方的用户需求（三）
研发团队如何应对源源不断的、来自多方的用户需求和期待？（二）
喜欢本文的朋友们，欢迎长按下图关注订阅号爱敏捷，收看更多精彩内容
转发是对作者最大的支持
349
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
