第四章:需求分析和管理

作者: 守约大大 | 来源:发表于2019-07-21 09:32 被阅读40次

    4.4 分析需求:用图形代言需求

    4.4.1 需求蛋模型(理论,了解即可)

    Gerald M.Weinberg在《探索需求》中提到了需求理论:需求是我们想要的东西和我们不想要的东西。同时,我们收到的需求,总是含混的。做需求相关的工作,就是不断地降低含混。

    由于每个人生活背景、知识体系不同,对事物的理解也不一样,这就造成了用户在表述需求时的含混。产品经理的工作,就是不断的讲波浪线拉近成直线,从成本和实现价值的角度来对需求进行分类,从而找到必不可少的需求及锦上添花的需求。

    4.4.2  思考需求:痛点×收益×明确、可行、简单的第一步 > 维持现状(理论,了解即可)

    痛点:客户迫切需要满足的需求。(B端产品多业务走一走,容易发现痛点)

    收益:收益是投入资源后获得的成果。(需要可以量化,提升多少,降低多少),关键还是改变用户的行为。

    明确、可行、简单的第一步:我们所提供出来的需求方案,是投入资源立刻就可以开发的。产品经理思考出可行性方案需要简单,方案可以快速迭代。当遇到多个方案无法抉择时,选择最简方案。

    维持现状:收到的需求,如果用户对这个需求的痛点感觉不强烈、收益不高或者没有可行、确定、简单的方案。只要满足其中一个条件,那么这个需求就可以暂时维持现状。

    4.4.3 解析需求:用图形为需求代言

    解析业务和探索需求的方法论:UML(统一建模语言)

    注意:数据驱动:行为产生数据,数据联系行为

    数据流动形成数据流,从而把业务中的人联系在一起。(数据的流动一定是有输入和输出)

    一些常用图解:

    流程图(把业务流程描述清楚)必须懂

    第一步:先总结主要流程。

    举例(吃饭):进店—点餐—下单—制作食物—送餐—就餐—结账—离店

    第二步:再对框架进一步细化。

    举例(点餐):查看菜单—介绍菜品信息—选择菜品—添加至订单—结束选菜—核对订单—下单

    实物关系图(ER图,用于数据库和表结构的设计)了解就行

    数据之间的三种关系:一对一,一对多,多对多

    用例图(UC)了解就行

                                                                     (网上随便找的图,仅做了解)

    4.4.4  需求的输出物:需求文档

    1.需求文档包含的内容

    需求范围:包含用例名称、使用角色、优先级、备注

    业务概念(不一定要有):放实体关系图,解释每一个元素具体定义,包括的属性数据有哪些。

    流程展示:流程图和页面流程图

    需求描述:

    非功能需求:

    把性能的好坏拆分成各种具体的参数和跑分,比如:搜索单号要在0.5秒反馈结果。

    总结:分析需求

    产品经理做什么?

    使用图形化的工具,对业务方的需求进行抽象和具象化并形成结构化的文档,以推进后续开发。

    有什么可以提供帮助的工具?

    会议产品经理与需求方坐在一起讨论需求,往往会比较高效的了解需求。

    UML。通过学习UML,使用流程图、实体关系图等工具来高效地分析需求。

    做完得到什么?

    需求说明文档

    4.5 管理需求:打造简单可实践的需求池

    4.5.1 为什么要做需求管理

    产品经理在工作中每天忙碌地处理需求,虽然每天都很充实,但极为耗费精力,时间长久的话就会缺乏动力,不容易朝着战略规划的方向走。

    需求管理的宗旨

    积极主动:核心,主动承担责任,去推进事情的落地。(执行力和推动力)

    知识共享:分享不同团队的领域知识,减少沟通的未知区域,从而减少沟通中的误解。(协作沟通,及时备注说明)

    相互尊重:每个人站在不同的立场,有着不同的知识储备,看待问题必然会有不同的观点和角度(换位思考,以目标结果、数据为导向)

    4.5.2 需求管理中的干系人和角色

    干系人:是能影响项目决策、活动或结果的个人、群体或组织,以及会受或自认为会受项目决策、活动或结果影响的个人、群体或组织。

    在需求中每个人都会从自己的立场出发提出需求,可能会不经意间破坏别的业务线的流程,所以需要产品经理从全局的角度去思考需求,把不同的关注点都考虑到位。

    需求管理中的角色:需求人,负责人,产品经理,研发经理,研发工程师,测试工程师。

    4.4.3和4.4.4不属于核心知识点,不做展示

    4.5.5 需求池的核心:优先级和重要性

    1.什么是需求池

    需求的状态:筹备中、待排期、待开发、开发中、待测试、测试中、待上线、已完成。

    需求池是为了帮助产品把握产品的发展状态,把控项目进度的工具。

                                                                      作者的需求池

    书中的需求池属于大公司业务下多个产品线才使用到,我个人建议做一下精简优化,找到合适自己的就是最好的:

                                                                      守约的需求池

    2.优先级——需求分类和排序

    优先级表现形式多样数字、汉字、字母都可以,选择适合自己的去使用即可。

    我们可以对优先级定义,便于我们快速的对需求进行归类。(根据所在公司和组织及所经营的业务来进行综合评估,比如有些公司的当前业务流程繁琐,员工效率低下,只要优化就一定可以极大的提高人效,那么这时候提高工作效率的需求就会到最高优先级,实际情况实际分析)

                                                                                       大多数需求的评定标准

    3.重要性——优先级的辅助

    重要性是对需求进行打分,用户对同一个等级的需求进行排序不代表其他信息。

    4. 统一地看优先级和重要性

    优先级和重要性一旦确定,将贯穿需求的整个生命周期,所有的资源将根据优先级和重要性被安排。

    划分需求的优先级和重要性是围绕企业和组织的战略。

    4.5.6 需求收集的工具

    收集需求的模板:用户的愿望清单

    4.5.7 需求管理的证伪

    值得思考的三个问题

    问题一:如何评估工作量?

    让研发经理或者研发工程师评估工作量,以天数为单位。一方面要看开发,一方面产品要自己通过经验累积去评估。

    问题2:如何确定需求完成的时间?

    根据需求管理周期进行测算,比如会在1周内发布,或者2周内完成。当然也可以问开发需要多久

    问题3:如何处理长期堆积在需求池中的需求?(重点)

    产品经理需要时常关注已经积累了很长时间的需求,可以以三个月的时间为标准。产品经理要通过各种方式与需求人和负责人沟通,分析在需求池长达三个月的需求到底出现了什么问题。看看这些需求是否不适于公司的发展方向,若它们已经被部门战略规划抛弃,是否可以将这些需求删除或者重新修订后再提出。

    总结:管理需求

    产品经理做什么?

    产品经理通过协作,管理需求从建立到发布上线。(优先级,重要性,排期)

    有什么可以提供帮助的工具?

    项目管理

    SWOT分析、KANO模型等分析工具

    做完得到什么?

    需求池

    需求排期计划

    相关文章

      网友评论

        本文标题:第四章:需求分析和管理

        本文链接:https://www.haomeiwen.com/subject/qgqmlctx.html