紧急需求定义

本文部分内容来自网络整理，本司不为其真实性负责，如有异议或侵权请及时联系，本司将立即删除!==本文为word格式，下载后可方便编辑和修改!紧急需求定义篇一：产品需求分析思路产品需求分析（上）-理论流程作者：唐杰分类：产品设计发布时间：201X-05-0314:29好几个朋友让我分享一下产品需求分析，我想了好久也没发现有什么可说的。这主要是我在工作中很少把需求分析当成规范性的操作流程，通常我都是在脑海里直接判断需求，而且在绝大多数的公司里，也没有规范的需求分析标准，常常都是由诸多因素直接影响并决定了需求。出现这样的情况，也是职业属性决定的，因为产品类的工作带有很多主观性因素。既然要讲产品需求分析，那么就先要知道这在产品实现过程中处于哪个环节。无论是新产品还是迭代产品，首先由想法产生需求，然后需求汇集并分析，放弃掉不需要的，暂缓不紧急的，然后整理出需要下一步执行的，最终形成产品需求文档并实施。在汇集分析之前，需求的产生来自各个方面，由不同的人产生想法并表述反馈给产品经理，因此产生需求，主要来自公司内部（老板、其他部门或同事）、产品经理自己（策划、挖掘）、外部（用户、客户、伙伴）。通过上面的梳理，我们就清晰的认识到，产品需求分析实际上就是需求决策。无论是自己的创新想法，还是市场调研，或者说来自其他方面的需求，最终汇集到产品经理手里的需求分析，就是决策哪些要做、为什么要做、怎么做，同时也要给出哪些不能做、哪些暂缓做、为什么不能或暂缓。需求分析之前我们先要对需求进行分类，每个公司或产品都有不一样的分类喜好，通常有功能类、数据类、运营类、体验类、设计类等等，分完类之后再对需求进行权重考虑并决策。需求决策有三个基本考虑因素，分别是战略定位、产品定位、用户需求。这是一个层级的关系，战略定位决定了产品的位置，有些公司的产品在战略上只是需要有这样一个产品，也仅仅是需要有，有不代表非要做好，既然不要做好，也就不会有大的资源投入，更谈不上需求的迭代，所以战略定位是首要的需求决策因素。其次是产品定位，产品定位决定了哪些需求是必要的，哪些需求是多余的，同时也影响着用户需求的取舍。基于三大考虑因素，我们对需求进行了筛选，之后还需要进行分位，即使用“四象限定位法”进行需求分位，将需求划分成“重要又急需、重要但不急需、不重要但急需、不重要也不急需”。分好位之后，我们再对需求进行分级，也就是优先级，标注需求的优先等级，规划并决定需求的执行计划。通过上面的理论流程，我们可以大致的对产品需求分析有一个全貌的理解。简单直接的介绍就是说产品需求分析是一个产品决策过程，通过对需求的分类、筛选、分位、分级的四步流程之后，决定需要执行的需求，将其规划到执行计划中。产品需求分析（中）-需求分析和判断作者：唐杰分类：产品设计发布时间：201X-05-0417:16的位置和分析的方法。但是在很多公司，需求分析并决策是一个很快速的流程，特别是瀑布开发模式的公司，不会将太多精力放在需求分析上，而是在产品策划的过程中就直接对需求进行了分析并决策，这样可以大大减少其他工作人员的闲置。在大公司或者产品拥有众多决策对象的时候才会细化并单独进行需求分析，其余往往都是产品经理直接决策。产品需求分析是在需求产生之后、产品实施之前的一个中间环节，他有很多工作是和产品策划重叠的，因为绝大多数的情况下，需求分析和决策在策划的过程中就直接完成了，所以需求分析的工作往往出现在产品迭代过程中。新产品进入迭代周期之后，会收到各个方面的需求反馈，这个时间就会出现很多需求，因此就需要对需求进行分析和判断，决定需要实施的需求。通过上一篇介绍的理论流程，我们清晰了需求分析的流程方法，第一步我们先要对需求进行分类，通过分类我们可以清晰的认识到需求的重要程度。对需求分类也是考验我们产品运营知识的一个机会，例如微信公众平台的服务号从原来的每月1条群发信息调整到每月4条，这个实际上属于运营类需求，再例如微信公众平台服务号支持微信支付，这个策略看着像运营类需求，但实际上应该属于功能类需求。对需求分类之后，我们就要对需求进行分析和判断，主要考虑因素有三个，分别是战略方向、产品定位、用户需求。战略方向是一个很宏观的方向，这个方向没有明确的界线标准，但是可以给我们一个参考范围和目标，在实施的过程中又细化成各个阶段，在每个阶段里需要实现的目标又是不一样的，因而需求分析和判断的时候，就要取舍决策。常见的战略阶段分别为起步阶段、发展阶段、迭代阶段。在起步阶段的时候，注重核心功能的实现，快速推出市场验证产品的可行性；到了发展阶段就会进行功能扩展和完善，在这个阶段也会小范围的进行试错实验；到了迭代阶段的时候，产品基本已经成熟稳定，需求就会更加注重用户体验方面。在各个不同的战略阶段，需求决策的标准是不一样的，起步阶段可能为了快速实现产品，所以在核心功能之外的需求会被放弃或暂缓。例如微信要构建闭环的商业生态圈，但这个工程不是一步能完成的，所以分阶段进行，每个阶段的重心就会不一样。第一阶段需要先完成场景布局，所以推出朋友圈、公众平台，先将点对点的微信改造成有维度的社交圈；第二阶段开放定制接口、内推微信支付，构建商业蓝图吸引更多参与者；第三阶段升级服务策略、开放微信支付，放开权限提升各类常见模式的实现方法，完成闭环的可能性。战略分阶段，阶段分版本，通过这样细化需求标准，决策每个版本需要实现的核心是什么，其中需要考虑产品定位、用户需求和当前的环境，从而决定需求分析和判断的标准。这些说的可能有些虚，没有实在的案例支撑，所以听着也晕，并且很多公司里，产品经理很多时候是没有最终决策权的，这也是一个尴尬的职业处境。但是我们需要明白，再伟大的产品，都不是一口吃成胖子的，都是有阶段性的发展和提升，我们需要找准每个阶段的需求重心。通过战略因素，我们认识了需求决策要参考阶段规划，并不是所有“有用的需求”都要一次实现，这一点需要我们拥有项目管理的一些常识，更多的需要经验积累。产品定位和战略方向是有一些重叠因素的，但是战略方向更偏向于市场，而产品定位更注重功能定义，所以产品定位的考虑因素是判断功能需求是否符合产品定位的标准。例如地图APP是一个LBS模式的POI导航服务的应用程序，如果有一个显示路况信息的需求，那么这是符合定位内的需求，可纳入规划中按计划实现，但是如果需求是希望实现Web版离线地图下载，那么这个需求和产品定位以及运营策略是不符的，就没有必要纳入规划。战略方向和产品定位都是策略型因素，考虑的思路也是主观性的，但是用户需求这个因素就是实实在在的诉求点，但是用户的需求也不全部合理，也要考虑公司的战略和产品的定位，正如上一段提到的Web版离线地图下载，就不符合公司策略。既然用户需求是实实在在的诉求点，也就有了更加可挖掘的方法。用户需求的思考我们需要注重两个方面，分别是“不把需要当成需求、不把产品形态当成本质”，我分别也有两个案例供大家参考。不把需要当成需求：好几个朋友让我分享一下产品需求分析，这实际上是他们需要的，但不是他们真正的需求。用户往往在表述需求的时候，因为各种原因或因素，没办法认识到真实的需求，也就会把需要当成需求表述出来，但实际上他们的需求是希望我能分享一下“产品需求”产生之前如何挖掘和策划出需求，而不是产生之后的分析决策。策划流程，行李箱是产品形态，但不是产品本质，产品的本质是大众人群在出行中携带的一个物体，根据本质我们需要改良用户携带物体所遇到的麻烦。通过需求分类后，我们再结合“战略方向、产品定位、用户需求”这三个因素，对需求进行筛选，最终再根据工作计划对需求进行分位和分级，制定各个阶段和版本的需求文档。需求分析和判断是一个关联性的思考过程，筛选、分位、分级都需要结合三大因素以及其他因素一同参考并判断，这需要我们拥有宏观的思维能力，并且也要有足够的定力，避免发散性思维产生的诱惑让（来自：：紧急需求定义）我们偏离最初的战略方向和产品定位。产品需求分析（下）-分析文档/报告作者：唐杰分类：产品设计发布时间：201X-05-0514:30在文章之前先分享一个思维导图，由草榴网产品经理“小福子”针对前两篇文章整理的一个思维导图，结构化的罗列了我的文章内容，如下图所示：需求分析和判断之后，我们需要写一份报告文档，将需求的处理结果呈现给领导或其他同事，这和我们策划产品后要写一份策划方案是一样的，通常这样的文档都是PPT形式，以大纲加上演说的方式表述方案。PPT文档的大纲应当包括以下几点内容：1、 需求分类：将需求以需要的类型分门别类的罗列好，并介绍清楚需求本意。2、 需求分析和判断：在这个部分介绍各个需求决策结果，将可行性需求留下，不可行需求放弃；通常这个部分只介绍放弃的需求和放弃的理由。3、 需求分位：将可行性需求进行分位表述，表明需求的轻重缓急，这个分位的决定因素有很多，需要参考三大因素进行评估；四象限定位法在普遍的公司里也会这样称呼，重要（紧急）、重要（不紧急）、不重要（紧急）、不重要（不紧急）。4、 需求分级：根据分位再分优化等级，将需求划分计划，根据不同规划阶段分多个版本实现；如果需求很少，那么就一次性迭代实现了。通过PPT的展示和演说，就能详细的报告了产品需求分析的结果。篇二：如何处理客户的需求如何处理客户的需求一、需求的分类及其处理办法做一个产品要研究很多层面的，产品定位、受众心理学、可操作性、成本控制等等。当面向用户多了，当倾听成百上千个用户的想法之后，我们会越来越少地掺杂感性色彩，一些想法会更谨慎的提出，会有一个更理性更全面的思路，会缩短得到正确思路的时间。客户的需求是可以分类的：1、一次告知类；2、个人喜好类；3、不合理需求类;4、合理需求类。当某个功能可能用户第一次不知道，但是只要告知一次，即会使用。系统中的所有功能受限于一定的表现形式，不可能全部一目了然。这属于一次告知类，一般不急于修改程序或者没有必要动辄修改程序。通过培训解决。当你深刻理解人性的时候，你会发现有部分人在乎个人要求。当这样的用户提出的需求，大都是对现有已经实现功能的基于个人喜好提出的修改要求，或者提出功能之外的形式上的修改要求。可能别人并不喜欢这样，甚至其它用户提出的需求与此正好相反。这样的需求属于个人喜好类，可以说服用户，或者找到更折中更平衡的解决方式。还有一些用户提出的需求，可能不合理、或者相矛盾。明显不合理的需求容易处理。但是有些得从管理角度、应用角度进行全方位的说服，这对项目经理的要求要高些。比如，有的应通过管理去解决、而不是通过技术去解决；有的明显就是不合理的管理方式，就不应该把软件修改成适应这个不合理的管理方式。最后就是合理需求类了。用户提出的合理需求，我们的政策是：1、如果是对我们产品功能的完善，则对客户说，感谢您的意见，我将带回去提交产品会议讨论，争取加入到产品补丁包中，要是补丁包发布了，我将及时为您更新；2、如果所提的需求虽然合理，但是不是我们产品的发展方向，或者较多的超出了合同范围，则跟客户做真诚的解释，很抱歉不能实现。可能需求的“合理性”容易判断，但是合理需求的设计又不容易了。实现方式、表现形式中，富含逻辑思维、美学、成本控制、语言文字、程序开发和技术架构等综合能力。这方面以前也讨论很多，作为设计者责任重大。首先是产品经理，其次是一个可操作性的规范，再次是程序员，最后是测试。一个不经意的设计很容易“生根”，只要进入产品了，就可能在产品中会很顽固的呆上多年，由此浪费的成本累计极为可观。我们专业做产品的都是如此，更何况一般用户所提的需求（设计）了，所以面对客户的需求，我们要慎重对待，更严谨、更高层面的来设计这种需求，而不是把功能越做越僵化。软件产品的完善本身、软件产品的项目实施，都需要太多的哲学思维。二、走产品化路线才会双赢产品和项目的区别我们是做软件产品的，不是做软件项目的。软件项目是指通过对客户需求的调研而定制开发的、完全满足客户需求的软件系统。它的特点是只能让这个特定的用户使用，缺乏通用性。软件产品是指提炼所有用户的需求而开发的、满足所有用户的软件系统。它的特点是可以让所有用户使用，具有通用性。当开发商的技术、管理、理念等综合实力跟不上的时候，就使很多软件系统的开发和实施变成了低层次的软件项目，而不能成为软件产品。只有开发商的综合实力较强的时候，才能通过很多软件系统的开发和实施打造成一个标准的软件产品。而开发商的技术、管理、理念等综合实力非常强的时候，既可以做成功的软件项目，又可以做软件产品。为什么走产品化路线软件项目是完全按照客户的需求来定制的，因为它的唯一性、缺乏推广性，所以成本高出产品几十甚至上百倍。而软件产品在吸取成千上万的用户的使用经验基础上，通过软件升级的手段来实现逐步完善的。软件产品通过这种模式，可以发展得更成熟，使所有用户都能享受这种集体智慧的结晶，这就决定了项目实施中尽量避免用户独立的个性的二次开发，而通过产品升级的手段来实现逐步完善，只有这样，bug才会越来越少，产品在功能逐步强大的同时可以越来越稳定，这是软件产品成长的自然规律。反之，单个用户的思维会走进死胡同，越改越陷入狭隘，bug的更改效率越低，功能的完善时间越长、甚至缺乏通用灵活而陷入僵化，产品趋于稳定的时间越长，而开发商也投入越多，自然有悖于以产品来合作的初衷。另外，因为客户做了较多的二次开发，所以不能享受产品新版本的平滑升级。客户做了较多二次开发的系统，在合同履行完毕后，一定有终止开发的时候，而ezOFFICE产品是无止境的向前进步的，而且每隔一年功能都会有非常大的增加和提升，只要客户愿意走产品化路线，只要已有的系统可以平滑升级，我们甚至可以不顾合同的约束，给客户提供有很大增值的升级服务。产品开发和它的增值服务是需要投入成本的，万户网络在最近4年投入了1000多万才打造出ezOFFICE201X。我们的投入就是为了让所有走产品化路线的客户能享受到超值的服务，而因为走产品化路线，我们的产品才会专心致志的发展成现在这样的成熟和强大。从上述分析可以看出，走产品化路线是最科学的软件产品的项目管理(ProjectManage)方法，对用户方和开发商都有好处，是双赢的，而不是开发商降低成本的借口。三、如何控制客户需求除了答应客户在产品升级中处理的合理需求之外，其他需求都是需要项目经理控制的。如何控制客户需求呢？首先，项目经理要对上述两点“需求的分类及其处理办法”、“走产品化路线才会双赢”有深刻的理解。其次，要有一套让客户容易接受的说服技巧和方法。说服客户的技巧1、 条理清晰，全面陈述，重点突出。要说出一二三四来。你只有说出一二三四来，才说明自己思考了并且思路清晰，也让对方看出条理，增强沟通的效果。2、 多站在客户的角度考虑问题，而不是通盘从自我的角度去说服客户。如案例1中，对口子酒业项目关于人事模块的修改要求的说服。3、 不卑不亢的表明你的态度。文字沟通的好处4、 文字（书面或邮件）沟通，而不仅是口头沟通，可以很全面的、条理清晰的列出你要陈述的事情或理由。5、 面对面沟通或者电话沟通，会受很多因素的制约，如客户忙，没有耐心听你解释，你的口述很难条理清晰并且周到全面等。6、 文字的形式有时可以表述口头上不方便说出的内容。7、 当客户看到文字的时候，会静下心来看完，并且郑重地去思考，全面地去理解你要做的沟通。四、客户回复案例1、口子酒业回复（1）原文及回复：刘叶东：您好！OA有几个需要修改的地方：3、人事档案尽快修改完善。>>>RE:人事系统的修改，很抱歉，我们公司的政策已经明确这块不作修改。诚如我跟你们分别仔细解释过的：1、我们是协同办公软件，侧重于“协同办公”，如知识管理、公文、流程、工作任务、工作汇报、邮件等等。完善（强大）的其他应用模块不是我们的产品规划范围和发展方向，如人事管理、档案管理、物品管理等。2、 如果做得很完善很强大，那么人事系统会如用友人事、档案管理会如科怡档案、物品管理会是一个专业的MRP系统。而这些是专业的研究领域，也有与之相应的销售价格。3、 如果协同办公系统集成了人事、档案、物资等等应用系统，那么就是庞大的ERP了。ERP和OA也绝不是一个层面上的。4、 工资科的人事系统是刘强自己开发的access数据库，可以随心所欲的设计任何表格，他说过多次他是不愿意用我们的人事模块的，如果用了，老的也会同时使用。他深谙其中之道。假设用了用友的人事系统，也肯定有很多不能满足刘强的需要，那么假设用友跟着修改，那以后再变动呢？再有新的需求呢？还是要改。总之，没有自己开发的好。我们现有系统中的人事模块就是给那些不能自己开发、满足于保存查询人事资料的客户。5、 我们OA的B/S结构，决定了自由取字段生成表格的工作量极大。这也是C/S和B/S的区别，C/S结构的软件开发容易使用难维护难推广难，B/S结构的软件开发难使用容易维护容易推广容易。总之，敬请谅解！2、BBTV回复（1）这是一个比较典型的案例。通过沟通使客户认同你的想法，即使不能认同也要使他不至于成为你的控制需求或者验收的阻力。这位是蚌埠电视台的记者（到现在我也不知道他是否参加过培训或者是否见过面），文字可谓犀利，不愧是搞文字的，我采取的对策是：不卑不亢+真诚沟通。结果是意料之中的，即使不认同，也要使他不成为验收的阻力。最后，雷总让各部门填写验收意见，这一关并没有被为难。（从另外一个方面来说，也希望研发部同事能有所触动。当时的情况是：在知识发布页面，当选择word编辑的时候，在页面上调出word控件，可是每次总弹出一个错误提示框。技术难题有时候是难以克服，不过大多数时候如果心态和方法对了很多问题是可以避免的。看看客户的反应，我们应该反思。我们应该知道我们做出来的程序是给上帝用的，应该知道和上帝直接面对的项目经理有多难。）**********请问万先生，为什么我们每次打开稿件发布之前，都会跳出来一个东东？而且，它还挺牛X，不点它一下，楞是用不了。还请问，什么时候我能不再见到它？篇三：浅论需求的基本属性和商业价