那些年我们一起对过的需求...

“你把keep的这个页面展示样式，加上途家的这个功能，微信的这个不错，是大家最喜欢的方式，我就要这个，嗯嗯，就按我这个来，不要乱改。”

“这个是我们老板说的，你就这么弄吧，别难为我了。”

“要的就是这功能，没有这个功能怎么上线呢？”

“真的一点功能都不能减，我们就是要一个全面超过竞品的APP。”

“我们遇到的场景你不懂，这个必须这样。”

无论你是内部的产品经理还是外部的受托团队，这几句话是不是似曾相识？

看过太多的项目的生生死死，最后发现绝大部分的“失败”的项目不是败在代码上，也不是败在设计上，而是败在需求上，需求是项目工程管理中最容易出现问题，又最容易不了了之的一环。

委托方似乎总是带着解决方案来

你会发现委托方/Boss在大多数情况下并不是以你想要的方式提出他的需求，而是以一种解决方案的方式，且这种方案总是会呈现一种“不可替代”“必须”“深思熟虑”的特征，而且他们会觉得需求很明确，“都说成这样了你们还不做，你们到底想干什么？”

为什么呢？具象的表述方式往往是容易且不用太多认知加工的，看到什么只要达成这个应该会有效的认知，便会被调用出来当做解决方案。而核心问题，以及问题上下游的系统性思考关系，以及这样的问题的解决路径则需要经过系统的逻辑思考后才能产出有效而无bug的解决方案。

理解到这点之后，一方面我们要正视这种情况，如果委托方什么都想明白了，还需要专业的同学参与做什么呢？另一方面一定要根据这些“面”上的东西，去试图挖掘出来他背后要解决的核心问题到底是什么？这才是项目需求的核心，也是所有的需求筛选的基石。

接口人似乎总是有着无法言表的苦痛

你往往无法接触到这个项目的拍板人，当听到一些接口人“没有办法”的表达之后，我们应该很快的意识到我们的接口人在这个项目里的作用是有限的，找到项目的关键决策者才能更好的推进和运行这个项目的进展，让项目得到真正的有效交付。

所以我们一方面要更快的去找到关键的决策者，另一方面也要更好的去帮助我们的接口人去完成向上的汇报表达。越关键的决策人越会从全局去考虑问题，一般都更会知道合作的重要性，而不是一味的要求下号施令，会清楚的明晰这并不是和外部团队配合的最佳状态。

功能似乎总是无法被减少

无法减少的功能背后的巨大隐患就是，没有想清楚，也没有明确的版本目标，我们交付上线的产品是要去运作并加以运营的，是根据解决问题的假设制造出来的实体，根据与周围环境的交互产生变化和数据的，通过这些我们才能够更好的去考虑是否解决了我们的问题，一次真的能解决很多问题么？功能真的是万能药么？

当无法抉择的时候，还是需要我们回头想想我们真正要解决的核心问题到底是什么，也许是一个，也许是三个，但这些总能成为我们要什么，不要什么的基础准则，而不是面对巨大的文档，大笔一挥说“这些我们都要”，不但浪费了人力物力，也让项目变得高度复杂，还延长了上线时间，极高增加了项目内部的开发风险。如果再碰上一个不那么靠谱的产品经理，从这边copy点页面，从那边copy点功能，那一定是一个灾难。

回头源头，会发现选择似乎没那么难，如果还难，那重新寻找你的核心问题吧。