如何做需求

一、如何对付需求

内容摘自优秀的产品经理如何去真正了解用户需求?

1.反问思考法

面对列出的众多没有章法的需求,我们往往是先一条一条的过,但是往往我们自己心里都没有底,你说这个需求重要,她说这个需求是必须的,当遇到类似的情况 时,可以运用“反问思考法”,所谓反问思考法,就是在面对一条功能描述时,首先要反问,增加这个功能对产品来说有意义吗?我不加他对产品有什么损失吗?假 如你半天想不出来,那么就可以考虑将他pass掉.

2.80/20法则

在现有的移动设备领域,关于如何抓住用户的核心需求,两个著名的设计哲学代表HIG和zen of palm也没给出一个明确的答案,zen of palm只是给出了一个法则:80/20法则,就是用户花80%的时间去解决的问题,构成产品的核心需求;剩下的20%则直接放弃。

3.少就是多

这个思想来源于包豪斯学派,最初使用在建筑领域,后来被用到工业设计领域,而乔布斯本人也非常推崇,特别是在手机的使用环境中,受天然的屏幕限制,功能越 多,产品就显得越繁杂,面对浩瀚的功能,这时用户往往会选择放弃使用。而面对激烈化的手机桌面争夺战,就那么一点空间,保持产品的简洁是不能不考虑的.

时间: 2024-11-03 19:31:45

如何做需求的相关文章

我们应当怎样做需求调研:初识

很多需求分析的工作是从需求调研开始的,我们就从这里说起吧.需求调研是需求分析最重要的一环,也最集中地体现了需求分析的特点——既是一份体力活儿,更是一份技术活儿.它既要求我们具有一种理解能力.设计能力,更要求我们具有一种与人交往.沟通的能力. 在一个阳光明媚的下午,项目经理带领着项目组成员,参加了客户组织的见面会,一个新的软件研发项目就这样开始了.双方在一种友好的气氛中进行,相互寒暄,介绍与会人员,拉拉家常.逐渐地,会议开始进入了正题.初次接触客户,对于项目团队意义重大.对方对你印象的好坏,今后如

不做需求复印机——批量操作流程设计

相信每个技术人员都不会甘心做"需求复印机".    不做需求复印机,有两种简单的方式.一种是在代码/模块/系统的结构上下功夫,例如前面几篇设计方案(审批.分发等).另一种则是直接对业务流程开刀,例如这篇文章要举的例子. 背景 大家一定都遇到过"批处理"这类需求.这次的背景就是一个批处理需求.按产品提出的需求,系统流程是这样的:     如果将这个流程直接"复印"到系统.代码中,显而易见会有性能风险. 思路 这个需求的业务逻辑并不复杂,设计的关注点

用leangoo怎么做需求管理及规划?(产品Backlog、用户故事)

传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发.在这样的环境下,需求文档是信息传递的主体,也是一份契约. 然而详细的需求说明书有以下5大弊端: 单向的信息传递,容易出现理解偏差. 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断. 有了详细的文档,我们不会反复讨论它,相互确认. 书面文档不利于团队共享责任,它扮演了证据的角色.Scrum强调团队共享责任,不论是需求人

请问怎么做需求,需求文档怎么写?急!

请问怎么做需求,需求文档怎么写?急! 下午就要陪经理去客户那了解需求了(基于B/S的ERP),我还是个新手,请问:A.请问怎么做需求?B.求那些方面需要特别注意?C.需求文档怎么写? 看你老大怎么做的学着点不就好了-- 过去先跟客户打声招呼 客户如果是个懂行的你可以很快开始准备用例了 客户如果是个棒槌,你就要麻烦点了,先搞好关系,之后先给他简单说说,如果觉得是个明白人能点透,就扫扫盲,如果真的不行就换个方法,实际去看看他是怎么处理业务的,在旁边观察就行了,最多问问他保存了什么文件,记录了哪些数据

万字干货:手把手教你做需求管理

通过这篇文章,总结自己在工作实践中需求管理的方法论--普拉姆方法.总结这个方法论的特点是,用最轻量化的投入,与他人协作,并管理需求,推动需求上线.这套方法论组合了项目管理.敏捷开发的知识,希望能对大家有所帮助.本文适合0-2岁产品经理阅读,产品大牛.敏捷管理大师请绕过. 本文大纲如下: 1. 为什么要做需求管理? 1.1 我们的工作是否像救火 1.2 需求管理是什么? 1.3 宗旨是什么? 1.4 结尾 2. 需求管理中的干系人和角色 2.1 什么是干系人 2.2 需求管理中的角色 2.3 如何

同样的工作、同样的做需求,为什么他们能进阿里

引言 古人云:"活到老,学到老."互联网算是最辛苦的行业之一,"加班"对工程师来说已是"家常便饭",同时互联网技术又日新月异,很多工程师都疲于应付,叫苦不堪.以至于长期以来流传一个很广的误解:35岁是程序员工作的终点. 如何在繁忙的工作中做好技术积累,构建个人核心竞争力,相信是很多工程师同行都在思考的问题.同样的工作.同样的做需求,为什么有的人只能在现有岗位上缓慢前行,而有的人却能进阿里,本文是我自己的一些总结,试图从三个方面来解答: 第一部分阐

做需求不是做零件,而是做细胞

前段时间国内一家互联网造车企业发布新车型,功能中包括车载KTV,有朋友对此评价是:这不就是一个录音软件加上歌词显示吗?从整车角度看,车载KTV是车的一个零件,零件满足其基本属性和功能即可,那有没有别的视角看待这个问题哪?不把它看做零件,看做细胞会如何?故有此题目:做需求不是做零件,而是做细胞. 1. 零件 VS 细胞 要想区分零件和细胞的差别,要先理解什么是零件.什么是细胞. 假设我们从宜家买个家具,回家组装的时候发现少一个螺丝,我们可以按照型号.长度.直径等参数再买一个即可:当我们身体不舒服,

怎么用leangoo做需求管理?(用户故事地图)

用户故事是在敏捷开发中表达需求的主要方式,我们在做敏捷开发的时候都有需求池的概念,在Scrum中这个需求池就是产品backlog,需求池里面是条目化的需求,每一条通常是一个用户故事.按照Scrum的定义,产品backlog是一个基于价值强制排序的队列,团队按照价值的高低,顺序地交付需求. 在开发的过程中,团队会逐步的细化产品backlog,为了保证短平快的交付,高优先级的用户故事会被分解为较小的粒度.但是这样带来了一个问题,对于那些规模稍大一些的产品来讲,故事的数量就会很多,故事拆分后通常会有只

如何做需求管理

需求管理目标: 需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解.需求管理的目标有两个:  ? 使软件需求受控,并建立供软件工程和管理使用的需求基线. ? 使软件计划.产品和活动与软件需求保持一致.  在需求管理过程中,为实现第一个目标,必须控制需求基线的变动,按照变更控制的标准和规范的过程进行需求变更控制和版本控制: 为实现第二个目标,必须就变更和软件项目各小组达成共识,对软件项目计划做出调整,其中包括人员的安排.用户的沟通.成本的调整.进度的调整等. 需求管理是一