不少开发同学应该在工作中都曾面临过需求模糊这个令人头疼的问题。产品经理在口吐莲花地讲述需求，你却听得一脸懵，要么是心中烦躁的情绪升腾，要么是开始定向关闭听觉系统，总之是已经无法专注，听不进去产品所讲述的内容。
产品经理犹如建筑设计师，希望设计出传世的作品，开发人员像工程队，要把图纸变成真实的建筑。曾经还发生过这样一个故事，产品经理的需求是APP主题颜色需要根据手机壳颜色来改变。开发人员开头还能控制住内心的惊恐，不失礼貌地在言语上打两下太极，但几番交流之后就压抑不住心中的愤怒，上演了全武行，最后两人被双双开除。
开发同学也许能够幸运地遇上一些非常有经验的产品经理，也可能遇上一些正在成长中的产品经理。那么从开发的角度，是否能够有一些方法，让自己做出来的东西减少一些返工的可能，让产出的效果更好，让自己所投入的时间更有价值呢？
不少开发同学希望产品经理能像建筑设计师一样，提供一份确定的、详细的设计图纸，然后开发同学只需要考虑如何去实施的问题。但不幸的是，计算机相关学科才发展了几十年，而人类的建筑史已经有几千年。而且现在需要解决的问题往往更复杂，尤其是一些创新的产品，会有更多不确定性。即使有一份非常详细的需求，开发同学如果忽视了下面几点，也非常容易导致最终的交付出现偏差。
不了解所要解决的问题
这个现象并不少见，有不少产品经理与开发团队在澄清需求时，这个问题往往是容易忽略的，或者说从开发同学的角度认为与开发关系不大的。但实际上是否清晰真正要求解决的问题是什么，与接下来开发同学的一系列工作都息息相关。
不了解真正的用户是谁
我们做出来的东西到底是给谁使用？提需求的人未必是真正最后使用的人。小男孩和中年男人都喜欢车，但前者需要的是玩具车，后者需要的是可以带着家人自驾游的车。用户不同，需求就会不同。
不明确的需求价值
如果无法明确需求价值，那么可能存在的问题是，可能是需求过大而无法评估，还需要进一步细化。或者定位不清晰，还没有建立起清晰完整的逻辑链。
不明确的验收标注
没有明确验收标准的需求，就会出现不同立场有不同的解释。就像同一个剧本，但是一千个读者眼中就有一千个哈姆雷特。
敏捷开发中有一些很好的实践，例如优先去完成当前价值最大化的、明确的需求，并尽可能早地交付一些产品增量，然后通过不断迭代的方式，去实现一个复杂的产品。产品和开发会多次通过product backlog refinement会议，对产品backlog进行细化、价值重排等，这些都有利于开发人员在选择需求进入迭代时，已经有比较清晰的需求可以进入开发。
今天要说的2招从敏捷而来，也不仅仅适用于敏捷，在非敏捷开发的团队中，也可以尝试用这样的方式来沟通需求和描述需求，也非常有利于产品和开发就需求达成一致。这两招就是：
使用用户故事的模式来描述需求
明确验收标准
下面我们通过一个故事演绎的方式，来说明一下如何使用这2招。下面以P代表产品角色，以D代表开发角色。
P很兴奋地来找D讲需求.
P：我们需要造一种飞机，这种飞机要像战斗机，能够短距离起降，能够超低空飞行。一定为大买。
D：对不起，这个需求实现不了。
P：怎么实现不了？
D：造真飞机还是假飞机？造出来的飞机给谁用？能不能用户用户故事的方式，描述一下这个需求？
P和D不欢而散。晚上P回顾了今天的对话，并思考这个事情。P找前辈指点了一番之后，又做了一些功课，准备第二天再找D谈。
第二天来临时，P试着这样子又给D将了一遍他的想法。
P：作为[航空爱好者]，我想要有[一架无线遥控的战斗机航模]，以便[在航模比赛中可以取得好成绩]。
D：哦，原来是准备早航模。那这个事情我们可以试一试。具体都有什么要求呢？
P：样子要像F16，能够短距离起降，能够超低空飞行，也能够高空飞行，还能做各种动作。
D：你能不能说的具体一点？
P：已经很具体了啊！
D：实现不了。
P：怎么又实现不了？
D：需要你把验收标准明确一下。
P这次虽然没有说服D马上就开始干活，但觉得还是取得了一些进展。P再次找前辈指点，又做了一些功课后，准备第三天再找D谈。
第三天来临时，P试着这样子给D明确了他的验收标准。
无线电遥控距离要不低于1KM；
航模的最大飞行高度不低于200M；
航模的续航时间不低于30Min；
航模翼展9.45dm，长度15.09dm，高度5.09dm
航模最大飞行速度10m/s
航模最长起飞距离10m
D：小P，你太专业了，我知道该如何设计这个航模来满足这些验收标准了。 P：小D，你也不错，两次提醒的都很好，用用户故事后，造出来的东西是给谁使用的就一目了然，要解决什么问题，给客户带来什么价值都很容易理解了。再配合上验收标准，你也清楚要做到什么程度了，我清楚如何衡量你最终给我的航模是否合格了。 D：互相学习，互相促进！2周后等着验收吧。
再总结一下，当遇到产品需求不好理解，不清晰明确时，不要着急，试着先了解一下这个需求是满足什么用户的需求的，通过什么特性可以能够解决他的什么问题，给到客户什么价值？这个理解了，再和产品好好沟通一下如何来验收这个需求，通过场景化、量化的指标来明确验收的标准。希望这2招能帮助到您。
