## 产品设计体会(十三)——再说需求分析
前段时间听到过一个说法,说需求分析与技术分析的最大的不同是思路的本质差异,技术分析是“树干——树枝——树叶”的任务分解过程,技术人员很适应并乐于用 这种方式思考,可以把大问题分解成小问题,发现难点逐一攻克。很多做需求的人都是开发出身的,所以开始往往会用这种思路做需求,听到客户提到的功能点,直 接想怎么做系统设计了,有时候需求分析甚至已经越俎代庖到“详细设计”的职责了。而真实情况是,需求分析是“树叶——树枝——树干”的分析过程,一定不能 漏掉提炼用户需求的这个过程。
确实很有道理,后来仔细一想,其实另有两个问题值得继续思考补充在这个说法上。
第一,这里玩了一个偷换概念,两者的“分析”定义不同,按照逻辑学的通俗定义,第一种分析是真正的分析,而第二种“分析”似乎更应该被称为“归纳”。可是,如果现在提出一个“需求归纳”的概念,连我自己都觉得拗口,所以继续用“需求分析”这个词。
第二点更关键,“树叶——树枝——树干”的描述并不完整,它只是前半部分。其实完整的“需求分析”是一个先归纳后分析的过程,试想如果做到“树干”就结束,后端的开发人员还是不知道要做什么东西,所以我们还要继续把树干再次重新分解成树枝、树叶。
小结一下,需求分析的目的是把从客户那里收集到的“用户需求(有时候甚至是解决方案,但我们不能不假思考的照做)”做归纳,然后得到一个总体概念后在分析、分解为“产品需求(给出我们的解决方案)”。
举个例子结束:小明说要吃肥牛火锅(18元),我们分析认为他是饿了,不是馋了或者真的想吃牛肉,最后给出我们的方案,扔给他2个馒头(0.5元*2),结果他虽然眉头一皱,但考虑到性价比(省了94.4%的成本啊!他省的多我们的利润空间也会大些),还是很愉快的吃了。
- 前言
- (一)——变态吧,开始帖周报了
- (二)——数据分析
- (三)——性价比:做不做?
- (四)——需求管理
- (五)——有关流程
- (六)——再谈流程
- (七)——需求探针
- (八)——产品与项目
- (九)——关于学习
- (十)——团队合作
- (十一)——市场扫描
- (十二)——少而精
- (十三)——再说需求分析
- (十四)——做过的几个项目
- (十五)——PM、PD、UE与UI
- (十六)——Feature List
- (十七)——PD的几种文档
- (十八)——概念设计
- (十九)——UPA年会的流水账
- (二十)——有关改版
- (二二)——封闭开发
- (二三)——用户研究
- (二五)——当交互设计遇到敏捷开发
- (二六)——PD就是出来卖的
- (二七)——大产品设计
- (二八)——细节之文案
- (二九)——产品设计的五个层次
- (三十)——“体会”导读的思维导图
- (三二)——零散的体会
- (三三)——用户大会
- (三四)——土老板破冰必杀技
- (三五)——QA与测试
- (三六)——再理解“敏捷”
- (三七)——可用性测试
- (三八)——项目外包!=开发外包
- (三九)——CSDN专访精编版
- (四十)——销售渠道
- (四一)——用户创意无限
- (四二)——又是零散体会
- (四三)——说说评审会
- (四四)——项目外包不适合“敏捷”?
- (四五)——外行眼中的技术分工
- (四六)——UML学习摘录(上)
- (四七)——UML学习摘录(下)
- (四八)——资源战争与BRD
- (四九)——产品市场化
- (五十)——终点:Matrix
- (五一)——敏捷的估计与规划
- (五二)——MS Office使用心得
- (五三)——产品文档与规范
- (五四)——PD招聘广告词
- (五五)——项目Kick Off
- (五六)——《需求工程》培训记录
- (五八)——《项目化管理》培训记录