需求是一个天坑，里面塞满了各种功能

　　经历过产品任何阶段的人都对产品需求有深刻的印象，每个周期都会堆了很多很多需求，产品的BUG还没解决就又冒出各种各样的新需求，伴随着需求的不断增加，产品的问题也越来越多。最初小而美的产品经过几次大迭代就变得复杂臃肿，难以驾驭。
　　其实各种问题的根源基本上都能追述到产品规划阶段的需求整理阶段。这个时期也是各个类型工作混杂在一起，使得所有人焦头烂额的阶段，这个时候不仅会有一个劲儿只强调大方向的伪指挥官，还有死盯着细节不放的小喽啰，更多的是只把自己当标准用户的麻烦制造者。
　　需求汇总启动前要明确几点功能与需求之间的关系。
　　一、基础功能不等同于基础需求
　　基础功能是软件定位中最重要的部分，虽然基础功能是从基础需求中诞生的，但完整的基础功能并不是跟基础需求一一对应的，这个话看起来有点绕，举个比较简单的例子，比如，基础需求是阅读书籍、新闻资讯、笑话段子，这里对应的基础功能就是一个内容展示。这个基础功能的细节可能会有文字、图片、视频等要素，其中文字显示又分标题、内容、注释等等。
　　因此，这里要注意在获取需求的时候，哪些需求是独立的，哪些需求是可以合并的，是除了定义基础需求后关键的一环。产品经理要以需求分析的身份进入到产品之中，分析需求与功能之间的隶属结构。
　　这里有人会问，这个工作有什么用。一个一个需求提，一个一个功能做不也是可以么？
　　的确可以，在客户端使用上从视觉效果看起来没有什么不同。后面开发就完全不一样了，同一个功能因为不同需求用不同代码写，重复工作且不提，还会引起各种BUG，客户端体积庞大，运行速度慢，版本管控难度增加，新人更迭时会造成很多技术上的混乱与模糊。
　　一个简洁的功能架构，对软件以后的发展起着至关重要的决定性作用。不论多么庞大复杂的需求文档背后的功能都应该是一张清晰的网，而不是一团理不清的乱麻。
　　二、亮点功能不等同于用户需求
　　经过几年的工作，发现很多领导和运营人员总是喜欢提出“我们要有亮点功能”。有些认为只要拥有亮点功能才能吸引用户，用户才会长期呆在里面。这若不是臆想就是看洗脑的软文看多了。所谓的亮点功能这本身就是一个伪命题，功能永远只是功能，是用来用的，那个亮点是功能的展现方法。也就是说亮不亮看打扮，但用不用还是回归到功能上。一只猴子打扮再时尚也是猴子，不是人。与基础功能关联度过低的功能再亮也是没用的功能。
　　在谈亮点功能的时候一定要从用户需求，也就是用户需要的角度考虑，而不是以为同类产品没做，就凭空造出一个，或随手拿来一个，按在上面就算是亮点了。从用户需求出发的功能必然会集中到基础功能之中，在结构脑图中是基础功能项目中延伸出来的分支，不可能独立为一体。
　　“想当然”是在说亮点功能时候经常犯的毛病，当然这里面不乏很多人是为了向老板交差，硬挤出来一些生搬硬套的亮点。当领导的没怎么用过相关产品也容易被忽悠，这个矛盾现阶段看来是无法调和的，只能拼双方的配合和职业素养的底线了。
　　三、功能需求与交互需求是不同的
　　这个问题反复说，但又经常被遗忘，功能是功能，功能的展现是交互。脑袋里想的、眼睛看到的跟手上用的不是同一个事情。想的是功能、眼睛看的是效果图、手上用的是交互，后两者统称UI。
　　提出人阐述新需求的时候如果说“我要可以这样这样，那样那样。”往往是提出新功能，如果说“这个地方我要这样这样用，那样那样翻。”指的是交互。一般情况下都是先确定了功能细节再考虑交互方案。功能上的逻辑会直接影响到交互上的展现方法，但交互也是有一定灵活性的，有些功能不能满足的细节可以用交互填补完善
　　在产品规划的文档中，尽可能不要过早提及交互，所有交互方案都归交互文档说明，或者在定稿版本的产品需求说明文档中详细阐述。这是因为互联网发展很快，交互的发展也是日新月异的，在功能不变的情况下，交互表现各式各样，到底怎样最好、最新、最顺畅，都是跟随这环境变化和技术方案变化而不断优化的。
　　一旦有人在讨论功能的时候提及交互，请先记下，且暂不做考虑。规划期间单纯再单纯地讨论功能才是顺畅前进的路径。
　　四、鸡肋功能不等同于伪需求。
　　在基础功能的延伸分析中，总会碰到一些功能很鸡肋，弃之可惜但又理应存在，这里的常用方法并不是删除，而是降级隐藏，把关键位置留给更价值的功能。有些页面宁愿有大部分的留白，或者将主体内容范围区间变大，也不要堆积各类功能造成视觉噪音。
　　页面内功能多一个，用户的操作就更分散，重要功能关注度随之被削弱。也是因为这个道理，现阶段很多国际上的产品页面越来越简洁，功能按钮越来越少，入口模块相对多起来。能替用户做掉的就先做掉，能不让用户选择就不要选。这样才能让操作和时间都集中在关键事件上。
　　鸡肋功能是必要的，因为它们是协助完成功能闭环不可或缺的组成部分，只是用户不经常或不必须会用到，如果没有这些鸡肋功能会造成一些不可调和的BUG，往往发生在各类设置相关的功能上。
　　相对的是可以删掉的伪需求，可以被现有功能代替，删掉后不影响主体功能，不影响用户使用，不与其他任何功能紧密相关、仅在交互操作上的多重方式的需求基本上都可以算是伪需求。最典型的就是摇一摇搜索，摇一摇换一批，摇一摇刷新更换皮肤等众多完全跟摇一摇这个交互无必然联系的需求。
　　在产品规划的过程中，分析是不可被代替的，更不能省略的步骤。分析的过程中尽可能完整的保存文档是很必要的，虽然这些文档可能以后不会用到正式场合，但在后续的优化需求和版本升级过程中，都将是极具参考价值的原始资料，它能明确的在产品建立之初，这个产品是什么，从哪里来，要做什么，和将发展到哪里去。