|
互联网时代，似乎每个人都在谈需求，刚需，痛点。作为产品经理，更是每天忙忙碌碌的围着需求打转。那又可曾停下来想过需求到底是什么，从哪里来，怎么分析，转化成产品功能？ 这篇文章就是我的一些思考，本篇文章也是由问题的形式展开，也是七个问题，大家可以在看文章前，思考下这些问题。
一、需求是什么？ 心理学定义 需求是由个体在生理上或心理上感到某种欠缺而力求获得满足的一种内心状态，它是个体进行各种活动的基本动力。 需求是一种状态，其来源是生理和心理上的欠缺，不满足。如孤独，就是社交需求得不到满足生成的一种心理状态，它会促使你去联系一些人，陌生的或熟悉的；饥饿，生理上的不满足带来的需求，促使你去吃东西。 而产品在这起到了什么作用呢？需求如果存在，那肯定有已存的解决方案（产品），但无论什么样的解决方案限于环境，科技，设计等，随着条件变化，都会存在改进的空间。需求一直在那，在变的是解决方案。如传递信息的需求，从古代的烽火，接着是书信，然后是固定电话，然后手机电话，然后是手机微信，后续可能是VR。 例如，在百度上输入路由器等一些词的时候，会关联出各式各样的词，查看这些词，代表着人们各种各样的目标和原有解决方案的问题。  百度搜索 很多产品在讨论需求的时候，会流于表面，最常见的一个问题就是把解决方案当成了需求，对需求的理解挖掘一定要到心理状态这个程度。因为需求是一种心理状态，其表现在外会受到认知结构，经验等的影响，提出的一个个满足需求的方法。 同时，需求的满足过程会伴随各式各样的情绪体验，需求的不满足的怒，需求满足的乐，需求被人破坏的怨，不断追求需求的痴等等。情绪对需求动力性起了很大的促进作用，而人们常说的贪嗔痴，也只是需求的情绪体现而已。 需求分类 1、需求层次：马斯洛需求层次理论 说到需求分类的时候总会把这个拿出来谈上一谈，其可分为两大类基本需求和成长需求，基础需求包括，生理需求，安全需求，归属与爱，自尊的需求；成长需求包括认知需求，审美需求和自我实现的需求。在学心理学的时候这个是被作为经典理论来学的，也就是这个理论已经出现很久，久到作者的徒子徒孙都把这个衍生和扩展了不少。这也反面说明了心理学和实际应用的脱节吧。但说回来，作为心理学的学生，不是研究这方向的也就是了解到这个地步，再往下的拓展，也想不起来多少。而且在现实的产品设计过程中也没把这个应用起来，最多放放马后炮，这个功能是因为满足了某某需求。 大家也可以思考下，市面上的各个产品都是满足了下面的哪种需求。生理需求对应的外卖类，购物类，团购app；归属与爱的需求，尊重的需求对应社交类app；认知的需求对应于阅读，资讯类app；审美的需求对应于音乐类app，旅游类app；自我实现对应于健康类app。可以看到越是底层的需求，对应的用户人群就越大。  马斯洛需求层次理论 2、需求起源：生理需求，社会需求 生理需求，人对维持生命和延续后代所必须具备的条件的反映。 社会性需求，人对维持社会的存在与发展而产生的需求的反映。 3、需求对象：物质需求，精神需求 物质需求：指人为了维持个体和社会的生存和发展，对物质产品的需求。 精神需求：指个体参与社会精神生活的需要。 4、需求满足后的后继发展：一次性需求，周期性需求，上升性需求 一次性需求，这类需求一旦获得满足，将会消失并且不会再次产生。 周期性需求，这类需求的产生与满足呈现出周期性变化的特征。这个又可以细分为高频需求，低频需求。频次可以再结合需求的层次分类来对需求做评估。 上升性需求，这类需求在获得满足后，不但不会消失，反而会出现不断上升的发展变化趋势。人总是不会满足于现状，无论哪个需求在满足后，其带来的正向情绪总会慢慢变得平淡。有心理学研究表明，中500w大奖的人在一段时间后幸福感并不比一般人高。也 正因为如此，人才能不断前进。 5、真实需求，伪需求，表面需求 真实需求：反应了用户内心真正的需求 伪需求：用户把一些需求包装成其他的需求，比如说开房去看书 表面需求：用户依据自己的经验，认知提出的需求，如更快的马 需求特点
认识需求在产品开发中的作用
我认为需求不是创造的，就像马车到汽车的飞跃，不变的是出行需求，变化的是需求的创造性的解决方案。 二、需求从哪里来？ 产品经理每天都是未知需求打转，经常感觉需求无穷无尽，但这些需求都是从哪里来的呢？我们又该如何去主动获取需求，保证需求获得的可靠性呢？ 1、用户研究 用户研究在需求分析中所起的作用主要有发掘、验证、明确用户需求，跟需求来源相关的用户研究方法主要有：
还有一些用户研究方法如用户体验地图，可用性测试，满意度调查也就不赘述了。不过，作为产品要多注意把用研的结果结合到需求分析中。 2、用户反馈 喜欢前几天看的一篇文章，用户反馈是建立产品与用户情感联系的极佳方式（建立用户与产品的情感关联，最有效的办法是打造用户反馈体系）用户反馈的功能设计后续可以独立作为一个产品设计框架来讲，在这先说下处理的流程。：
马化腾在腾讯研发部关于“产品设计与用户体验”内部讲座中说到，腾讯有一个“10/100/1000法则”：产品经理每个月必须做10个用户调查，关注100个用户博客，收集反馈1000个用户体验。在bat中，腾讯的产品体验是明显优于其他两家，这并非没有原因。 我们能收集到用户反馈永远只是停留在我们APP的用户中的愿意反馈的一部分用户的声音。我们更需要的是没有来用，用了就走了的用户的声音。过于关注已有用户的声音，为他们做需求，对于小众的APP来说，会非常致命。这样的迭代往往会让产品越走越偏，吸引新用户能力反而更差。在pc端的时候，在用户卸载一个软件时，总会跳出来一个提示框，让用户说明下卸载的原因，相信大家都是直接点叉走人。也说明了这个问题其实一直都在，这也需要我们能跳出自己的app的现有用户范围去收集更多的用户信息，反馈。 3、数据分析 我现在的工作内容比较杂，数据分析的工作也要接触，就整理了下流程，顺便推荐大家看看这篇文章（数据驱动设计：数据处理流程、分析方法和实战案例）：
上面这个流程是针对自己产品的数据工作，其他的数据来源就比较杂，咨询公司出的分析报告，大公司的发布数据，各个应用平台可见数据，还有像appannie，百度指数等等，也可以作为产品工作的一个参考。 很多时候，有数据作为支撑讨论问题，评审需求都更有底气，也能避免产品经理拍脑袋（虽然有时候也需要~）。 4、竞品分析 对于竞品分析，相信大家都做了不少，也形成了各自的一些竞品分析方法。我在网上也看到了不少竞品分析的文章和方法，各有侧重。我现在写的，也是一时之见，随着将来水平的进步，肯定还会不段的优化。但，只有不断的写，才能不断的进步： 竞品定义：
竞品寻找方法：
分析流程：
上面是我的一些竞品思路，更多的是注重产品思考，多问为什么和自己应该怎么做。 比较常见的竞品分析思路还有是从产品的五要素出发（参见《用户体验要素》），从上而下（战略层-表现层），结构清晰。但这种方式对于大产品会因为涉及的需求，功能太多，会容易流于表面，蜻蜓点水。 还有是从产品定位，核心功能，主要界面，这样的方式去体验，需要体验者对产品有一定的了解。 还有就是针对产品的某个方面如，SWOT分析，功能罗列对比，波士顿矩阵。 另外再推荐几篇觉得不错的相关文章供大家思考： 再谈竞品分析——选择重于分析，分析重于罗列 最好的竞品分析报告的思路应该是这样的 FACEBOOK产品设计总监！设计APP时的14个必考题 5、公司内部 1）老板拍脑袋 作为产品，在创业公司，老板提的需求占了需求总量的不小一部分。毕竟在创业公司，老板才是最大的产品经理，这个产品可能也是老板以前一点一点想出来的。老板的大部分想法都比较靠谱，毕竟人家经验丰富，站得高看的也远。但作为老板，顾忌少，又不能很好的遵守需求的流程，但需求优先级又很高。所以，很多坑就是这么来的。 就像最近策划会议的时候，老板抛出来一大堆的功能，然后让我们讨论，这些功能应该怎么策划（创业公司，老板永远是最大的产品经理）。我一脸无奈，“老板功能是为了解决用户的需求和问题，如果没有确定用户需求，那功能策划只是无源之水，更不要说其后的功能评估了。”争论了半天，把会议的主题转到了需求评估上。然后发现老板的需求都来自和一些家长的聊天，还有自己平时的想法。但这不靠谱啊，所以，议题又转到了怎么确定需求。最后，老板手一拍，我的需求就这样了，你们回去思考分析下。然后散会。。。需求其实是产品设计的地基，后续的一切都建立在这上面，也是准绳，后续的功能评估也是依赖于此。这里一步错，就是步步错。 （后来老板还是直接跳过了需求确认会直接开始功能确定会议。。。） 多说几句，以前刚来这个公司的时候，还得意自己能和老板拍桌子，讨论需求，硬顶一些需求。后来，才发现，得不偿失。吵得多了，老板就开始不局限于需求了，你的思路有问题，你的设计能力欠缺等等。很多时候，要把心态放低，多学习下沟通的艺术。 2）其他产品 是的，作为产品一起思考讨论碰撞，还能冒出不少好点子，毕竟一人计短二人计长。尤其身边有一个有经验的产品真的很能起到指导的作用，如果没有就主动走出去认识人。 3）运营人员 运营人员是公司中最直接接触用户的一批人，接触频率高，很多时候，运营人员能提供很多用户的反馈，需求。 另一方面，运营也是需求的产生者，运营活动会产生一系列的相关需求。这方面的需求角度和其他的需求还不太一样，运营一般是背有kpi的，所以更多的和一些运营数据相关。在这里产品需要起到设计并把关的作用。 4）技术测试 是的，技术，技术的同学总能站在技术的角度提出一些你从来没想过的问题，思考问题的角度不同，有时候还是能提出一些独到的见解。就像是我们的技术经理说的，有一个愿意给你提意见的技术，总比默默给你写bug的技术好。愿意提意见，需求，说明技术真的在思考产品，可以反过来促进产品经理进一步思考产品的需求。但是有所为有所不为，因为产品和技术在争论需求时经常处于弱势，这就要求产品要真正的站在用户角度提出需求。而不是说老板说的，运营要求的等等，这绝对是致命一击。 一个产品经理背后总有一堆指点江山的大神，毕竟产品的门槛低，谁都能说上两句。但作为产品还是应该积极应对，通过完善的需求获取方式，把大神们的需求纳入到流程规范当中。要说服别人同意你的意见，也要做到有理可依，有据可查。决不能沦落为功能实现经理，画图经理，机械地执行任务。 三、需求怎么评估 需求的评估细分下来还可以分为两个问题，需求做不做和需求的优先级问题。 To do or not to do，这永远是摆在产品面前的一道难题。咋看来是无从下手，但还是有一些明确的方法可以借鉴。 1、逻辑分析法 正如上文需求分类和来源中提到的，我们发现的需求并不一定是毫无问题的。数据分析可能会有偏差，用户研究可能会有人为因素，但综合多个来源产生的需求，互相印证，综合分析，走歪的可能性就大为降低了。很多需求，产品是可以通过经验和逻辑判断能力直接去除的。这也是为什么很多产品经理招聘的要求里有逻辑分析能力强的一个原因。 从一个需求是否需要满足，可以砍掉一些价值不大的，没有什么使用场景的，和无法实现的需求。 对需求进行进一步深挖，把一些表面/伪需求/需求解决方法转化为真实的需求。 2、产品定位法 产品定位主要包括三方面，目标用户，主要功能，产品特色。对需求按照这三方面来检验，是否是目标用户的需求，是否和主要功能紧密相关，是否符合产品特色。 就像网易云音乐，分享听音乐时的感受这个需求，符合云音乐的目标用户（大众音乐爱好者），跟主要功能（找歌听歌）比较相关，也符合云音乐的社交音乐app的产品特色，所以这个需求是可以做的（音乐评论）。（《【聚焦产品核心能力系列】价值链导向的产品决策》这篇文章也是类似的角度，讲的也挺精彩的，推荐下） 对于产品定位的探讨，可以再另外写一篇文章来探讨。 3、KANO模型法 KANO模型把需求分为如图三类：  基本型需求： 如果此类需求没有得到满足或表现欠佳，用户的不满情绪会急剧增加，并且此类需求得到满足后，可以消除用户的不满，但并不能带来用户满意度的增加。产品的基本需求往往属于此类。对于这类需求，产品的做法应该是注重不要在这方面失分。 期望型需求： 此类需求得到满足或表现良好的话，用户满意度会显著增加，当此类需求得不到满足或表现不好的话，用户的不满也会显著增加。这是处于成长期的需求，用户、竞争对手和产品自身都关注的需求，也是体现竞争能力的需求。对于这类需求，产品的做法应该是注重提高这方面的质量，要力争超过竞争对手。 魅力型需求： 此类需求一经满足，即使表现并不完善，也能到来用户满意度急剧提高，同时此类需求如果得不到满足，往往不会带来用户的不满。这类需求往往是代表用户的潜在需求，产品的做法就是去寻找发掘这样的需求，领先对手。（定义来自于百度，略改）  这表可以通过用户思考功能实现和不实现时感觉获得，一共25种可能分类。 字母代表对此功能，实现和不实现情况下的情绪反应对应的人数比例。 同时，E表示兴奋型需求，L表示期望型需求，M表示基本型需求；R表示相反的需求，I表示无关紧要的需求，Q表示存疑的需求。 公式中字母代表该需求，选择这个类型的人数总和。 A=（E+L)/(E+L+M+I)越接近于1，说明增加这功能用户得到的满意度提升 B=（L+M）/（E+L+M+I),越接近于1，说明不增加这功能导致的不满意度上升 A低B高说明是基本型需求，A高B低说明是兴奋型需求，A高B高说明是期望型需求，A低B低说明这个需求无关紧要，不需要做。 评估要不要做后，接下来就应该考虑的是，哪个先做，就是需求优先级排序。 经过上述的一步步，你手里可能已经有了一堆的需求列表，那什么该先做，什么该后做，也许这就决定了你这个产品的生死。如果你是神级产品，按照你的经验直觉来就好，不过估计也不需要来看我这篇文章了。作为菜鸟产品，就老实按照方法来，积累经验。 首先，要考虑产品是否已上线，如已上线，需要考虑几个点：
考虑了种种要求后，可以得出一个需求优先级排序列表。 如果产品还未上线，12数据的获得都是需要产品主动的去获取，各种竞品，分析报告。5中需求类型也优先做基本需求。但整体的步骤相差不大，对产品的要求也更高。 做产品有一个体会就是，越在上游做的多，下游就越轻松，宁愿在这一步多花一些功夫也不要在产品上线后才发现功能不如预期。 以前待过一家公司，那时候刚去，每周五会进行一次产品演示，把已经开发好的app功能通过大屏幕展现出来，然后让几个合伙人看产品是否符合需求。如果有问题就要从头开始设计，这样导致的问题就是项目进度非常慢，在我去之前，已经花了两个多月的时间来反复修改。这样做了两个星期我就忍不住了，这样的返工效率实在太低，就加入了需求评审和交互稿评审的环节。到了界面开发这个阶段，就不再做大的改动，才大大提高了项目进度。 四、需求文档该怎么写 产品要写的需求文档不少，但我们一般说起来的，用的最多的，应该还是prd文档。 prd该怎么写呢？ 要回答这个问题，首先要考虑的是，这是给谁看的。 同级的产品，交互，UI，技术，测试，运营看的，需要够详细，够清楚，才能让他们知道怎么按照需求文档做。是的，这一大帮子人，都是要依赖这份文档来下一步工作，这份文档的基础性，重要性不言而喻。 那这份文档应该包含什么呢，有什么规范和注意事项。 下面的文字主要来自于我自己工作学习中的感悟，只能说适合我的需要，而且也还在不断的摸索改进中，大家可以看看作为参考。文后也贴了些一些其他人的文章，大家可以对照的看，以找到合适自己的需求文档写作方式。 1、需求记录 对我来说，这个文档是我与其他相关人员（老板，产品组，交互，视觉，技术，测试，运营）沟通和pk的主要工具。每一次的沟通结果都要在这有一定的体现和记录，只有如此，后续的工作才能有效的展开。而需求记录在这起到的作用就是对这个过程有个记录，并且每个看到这个记录的人都能知道这个文档的进展，不会做无用功，重复功。可以想象，如果不做详尽的记录，文档的每一次变化，相关人员看到的时候都会不知从何下手，不知道哪里有变化，上次讨论的结果最后如何做等等。需求文档是一个统一思想，同步进度的工具，而需求记录就在其中起着至关重要的作用。 做好了这个记录，需求变更，需求追踪都会变得轻而易举，是我们产品与其他人员“撕逼”一大利器。  需求记录 2、需求背景 介绍市场情况，产品定位，竞品分析，用户研究，需求来源，需求分析等，这些工作都要做的扎实，可以参考前面的内容。要让文档面向的对象明白为什么要做，做的大致方向，起到统一思想的作用。这里的功夫更多的是在文档外。 3、总体介绍 对需求总体进行介绍，在这我一般采用思维导图的形式，对需求进行介绍，涉及的模块，功能范围。让大家对需求有个总体的认识。 不要过早的进入细节，这点还是很有好处的。只有大家的思维站在了同一高度，才不会在后续的需求讨论时局限于细节，而这点也是在各个评审会上最令人头疼的一点。 4、需求描述  需求描述 关于流程图，很多产品不怎么画，但对我来说，在需求的完善阶段，一个好的流程图，能起到查缺补漏的作用，而且可以让你不要过早的进入到交互，界面，导航的考虑上。这里想得越清楚，后面的需求变更会少很多。 用这个和开发进行沟通其实挺有帮助的，测试也不需要追在后面不停的问，这里有个情况怎么处理。 5、相关原型 原型的做法往细了讲，太占篇幅，主要分为低保真，中保真，高保真。在工作中，我一般做到中保真的程度，足够传递界面，交互细节。 这里还有个特点就是为了便于讨论，最好把需要讨论的页面都做出来。 具体一些细节，因为是讨论需求的，就不过多讨论了。有机会在原型篇章再做讨论吧。 五、需求评审怎么过？ 需求到了文档这一阶段，就不再是存在于产品脑海中的事物了，需要通过沟通把需求传递给相关人员，这就是需求评审会。 需求评审涉及的人员极多，老板，产品，交互，视觉，开发，测试，运营，每个人所站的角度都不同，对需求的理解水平也相差极大。 所以需求评审会，是产品推进的一道坎，这一条坎过的好坏，直接影响后续工作的推进。 那需求评审应该怎么进行？功夫都在会外。 1、提前发出 把需求文档，原型提前一定时间发出，确定参会人员有时间查看，思考。要考虑项目的时间进度，发出的时间不能太早或太晚。太早，有的人看的早，忘得也早，有的人觉得时间还早，晚点看，就忘了。太晚，大家不一定抽的出足够的时间来看，来思考。 2、提前沟通 会前需要找关键人员进行一对一的沟通，这个主要有三个好处， 一个是确保大家都看了文档，这样不会一头雾水的进入会议室，这样就会导致会议的效率大大降低，相信我，这样的会议会出各种幺蛾子。 二是提前沟通，可以让大家有什么疑问可以提前提出，如果你已经有思考过，可以提前解释，节省会议的时间；如果没有想到（这是很有可能的，毕竟一人计短）那就可以提前做好准备，思考完善。 再者开会时，你是一对多，而且是不同职位的同事，在会议上进行有效说服的成本会很大。一个人提出一个质疑，经常会引起其他人的共鸣，这样你就要努力说服多个人，这是很痛苦的一件事。 因为一个理由可能只能说服一个人，每个人的思考角度不同，出发点不同，搅在一起，是很难理清的。当然，口才好的，觉得自己能舌战群雄的同学可以无视这个。 我不希望产品的通过口才来说服同事。很多时候，一个一般的需求也能在产品的妙语如珠下通过。这个真的不是好事，因为产品不能靠口才来打动不能见面的用户。 在阐明了强有力的理由后，通过事实来说服同事，把信息传递给同事，这个才是需求评审的意义。窃以为，这点也是为什么很多优秀的产品经理都是内向的，因为内向的产品经理，只能通过更加完善的需求来打动同事。 3、确定会议时间，参会人员 开会前的准备工作还有就是，协调参会人员，参会时间，参会地址，确认大家都知道这些信息。可以在会议开始前再通知一次，不然到了点再催就是组织上出了问题。 同时，开会前也要确定下，相关的会议室，设备和材料准备完全。这些事都是细节，但还是挺有用的。 4、会议过程 讲解的流程我一般按照需求文档的内容，可以参见上文《需求文档该怎么写》。如果前面的工作做到位，会议更多的是统一思想同步进度。但需要注意以下的几个易犯的问题： 1）离题万里 需求会议一看，大家经常会由一个点，无限的延伸开去。这点其实是好事，说明大家对产品的参与感强，是把产品当做自己的事。但时机不对，导致需求会议是要确定需求，优先级。新的需求不是在这里产生的，不经过仔细的思考，研究，拍脑袋的需求大都会误导大家的思路。 产品经理作为会议组织人，要发现这个的苗头，做个扫兴的人，在大家谈性正高的时候，把会议拉回正题。但需要一定的技巧，比如，”大家的建议都很有价值，我这边都记录下来了，以后可以专门做些调研，研究。接着我们再确定下个需求吧。“ 2）纠结细节 对于交互，界面，大家都有自己的使用习惯，理解，反映出来就是大家都能对这些提一些主观的看法。很多时候，这个也代表一部分用户的意见，很有参考意义。但也只能作为一个参考意见，产品如果在这里过于纠结就会因小失大。 这时候，还是得让产品说出自己这么做的理由，并总结他人的理由，做出最后的决定。 3）难以确定 在一些需求上，大家最后都有自己的看法，无法统一，这时候再怎么纠结也不能做出最后决定。产品可以站出来，搁置需求，会后产品综合意见，沟通后再做确定。一定要确保会议的顺利进行，不能浪费大家的时间。 4）维护自己权威 在看需求会议的时候，在讲的一个个需求都是产品经理经过不断思考，挖掘的需求，可以说每行文字都有产品经理的心血所在。当产品听到别人的质疑时，总是想说服别人，维护自己的观点和权威。产品有一定的权威有利于产品项目的推进，但不是靠固执，执拗，反对听取他人的意见来维护。 在需求会议上，产品一定要记得带上耳朵和开发的心态，让大家一起参与到需求确定上来。大家的每一个看法都是促进产品完善，用户体验上升的机会。 5）问题反复 当一个需求确认后，已经推进到下个需求，然后又说着说着又回到了上个需求。这时候，要及时制止，把会议拉回到进度上。还有意见，会后再议。 6）、会议结束 会议结束后，要及时整理会议的记录，并把大家的意见收集到需求文档中，附上最后的处理方式，相关修改。 有些悬而未决的问题也要及时找对应的人员确定。 确定的需求也要及时的推进到交互，视觉和开发人员，确定估时，排期。 六、需求变更怎么办 需求变更这种事，大家都不想的啦，无辜脸~千辛万苦的把需求推进下来，这里面产品花的心血也不少。但作为掌控需求的人，需求变更的锅只能产品经理背。 1、需求变更的原因 1）产品战略，市场环境，外部条件变化。这种客观条件的变化，大部分时候不以产品经理的意志为转移，只能适应，只是要注意传达好原因，不要因此影响了团队士气。 2）老板又开始拍脑袋。人家是发工资的，很多时候，你费尽九牛二虎之力也说服不了老板要改主意。既然反抗不了，那就闭上眼睛享受吧。 如果无法说服老板，或者被老板说服，你就要尽可能的执行，完善。即使老板的想法你觉得非常不对，但讲清楚你的意见后，你还是得顺从。在公司，不要把产品经理这头衔太当真，恶了老板那就去坐冷板凳吧。 3）产品前期工作没做扎实，尤其是需求分析这一步。这一点虽然坑，但对于新手产品其实是必然要踩的一个坑。对于有经验的，也只能说尽量避免。产品与技术的矛盾很多时候就来源于此。 4）产品设计出问题。这个也挺常见，一些逻辑流程，交互设计，边际状况没考虑好，或者觉得有更优的方式。到了上线前的测试阶段也会出现一些。这种变更就要评估改动的成本和带来的效益了。 5）在需求确认会，开发觉得能做，随后也估了时。然后某天，开发溜过来， “嘿，我觉得这个需求这样不好，用户肯定不会这么用户我们的产品，这样做对用户体验不好” “说人话” “原先的方案有问题，这个需求实现起来会非常麻烦，需要改需求” 一番探讨后，撸起膀子改需求呗。 2、需求变更的应对 1）重新分析需求 当变更的时候，不要着急改变，重新思考原有需求的思路，对比新旧需求的变化，变化原因。要对自己原有的思路有信心。对新需求一定要慎重，再慎重！如果新需求提出后再对其变更，非常损害团体的士气，对后续的工作展开会非常麻烦。 2）更新需求文档 按照需求流程及时更新相关内容，并在文档注明索引，方便大家查找和后续追溯。并且根据需求变更大小，通知相应人员同步信息。这里的人员不要仅限于开发，还有测试，运营，视觉等。要做到信息的及时同步！相信我，这里有坑，泪目。 3）项目进度更新 需求变更大都会带来项目进度的问题，在需求变更后，需要及时对其产生的进度影响做评估。 4）需求变更的复盘 这一步其实是产品自身的提高所必须的，前车之鉴后事之师。 讲真，需求变更其实是产品与开发最容易产生问题的地方，盗的一张图，大家可以引以为鉴。 七、需求怎么管理 我们收集来的需求，按照各自的版本迭代顺序，会慢慢上线，但肯定有优先级和时间前后，那应该怎么管理呢？ 要做好需求的管理，需要建立需求库和做好版本规划。 1、需求入库 建立好需求库，分析好的需求按照下表进行记录分类，优先级，描述等，然后放入到需求库。如果已明确对应版本，直接放入。  2、需求跟踪 随着项目进行及时更新项目状态，从新建-进行中（记录目标版本）-已解决（上线），特殊情况如关闭，重开，延期。并在上线后做好需求对应的功能上线后情况，做好数据和用户反馈跟踪。 产品到一定程度后，需求库，及每个版本的需求量都是极大的，一般都是采用一些管理系统来管理，如redmine，禅道等。这之间的差别倒也不大，只要成员之间用的来就行。 不过需要注意，这个只是工具，充分有效的沟通才是最有用的，这里更多的是一个记录提醒作用。 这篇文章写了好久，在写和查找资料的过程中也总是会冒出一些新的想法，不断的添加修改。最后，总算觉得再改下去就不知道写到什么时候了，而且以我的水平，也只能写成这样了。估计要再修炼一段时间才能站在新的高度来审视需求，这个产品经理的核心能力。 接下来应该会再写一篇，市场分析方面的文章，现在还在思考和收集资料阶段，估计又是痛苦的历程~ 大家有兴趣也可以关注我的简书账号，静默之思。里面也写了不少产品设计方面的产品框架的文章，请大家多指教~ 一些参考的文章和书籍，大家可以看下。 书籍 《产品心经》 《破茧成蝶》 《互联网产品从设计到运营》 《用户体验设计师的成长之路》 文章 产品经理必须学会的会议管理技巧 真实案例：用KANO模型和PSM价格敏感度确定产品功能和定价 心理学之需求和动机 用户研究的旧瓶装新酒 产品经理：不要成为作图经理 【聚焦产品核心能力系列】价值链导向的产品决策 作为产品经理，如何给用户需求排序 你还在犯草根产品经理在犯的错吗？ 论需求和功能：如何分析需求并设计成功能 产品新人如何开需求评审会？ 从哪采集需求？这十方面就够了 『三分法』搞定产品需求分析 PM大招：百度贴吧前负责人首爆9条心得 任督二脉的启示录 陋习 快速上手 *著作权归作者所有，转载请联系作者获得授权。
|
|
|
来自： blackhappy > 《职场》
