posts - 188,comments - 176,trackbacks - 0

    开始接触需求工作时,在对用户需求的沟通基础上,多依据于做软件开发的结构化思维方式来编写需求文档,这种方式易陷入实现细节的陷阱。如何在用户需求和软件需求之间找到平衡点,使得做出的产品即是用户想要的又在技术可行和成本上性价比最高,甚至超出用户期望,给用户惊喜,开展需求工作时需认真考虑。业内谈得比较多的‘六何法(what、why、when、who、where、how)’,在需求分析工作中同样适用,可作为问题分析的基本习惯。下面谈些自己的理解:

1、信息收集和初步分析:
 what:需求是什么,解决什么人的什么问题(用户群体、用户规模、业务场景、性能指标和组网)?
 why:背景是什么,为什么有这个需求(高层领导思路、团队主动规划需求、竞品分析需求)?
 when:需求的市场时间(实验室验收、试运营和正式上线等各阶段时间)?
 who:需求的用户对象是谁(如:技术部门),是否与其他用户对象(如:业务部、内容部、运维部门等)有关联?
 where:哪里做(现场开发还是团队本地开发)?
 how:怎么做(需求端做可行性分析、技术团队负责实现)?
  需求端需要关注的几个维度:
   1.关注需求的输入
   2.关注需求的输出
   3.关注中间的业务流程
   4.关注对历史需求的影响
   5.关注需求的价值延生
   6.关注中间业务流程的数据回收

2、结合现有产品的情况做进一步分析:
 原则:树叶—>树枝—>树干—>树枝—>树叶(树X思路借鉴自《人人都是产品经理》)
 过程:首先,从树叶—>树枝—>树干,其次,从树干—>树枝—>树叶的过程。一方面不能漏掉提炼用户需求的这个过程,目的是透过现象看本质,另一方面也不能停在本质上,试想如果做到“树干”就结束,后端的执行人员可能还是不知道要做什么东西,所以要继续把树干再重新分解成树枝、树叶。总结成一句就是:自底向上的透过现象看本质以抓心核心,自顶向下的将需求逐步分解以指导研发。
  分析过程:
  1)从业务流程的角度,搭建需求框架。
  2)对各个功能需求逐步细化。
  3)将需求分析过程中的疑问形成访谈清单。
  4)与用户沟通澄清,达成一致。
  5)根据澄清意见修订需求。
  6)根据修订后需求及全流程,重新梳理一遍。
  7)考虑和已有功能的关系及并行下的业务处理。
  8)考虑需求的外延(基于新业务规划和运营数据分析),为后续迭代准备。
  9)考虑不同区域客户或同一区域不同客户的易用性需求。
  10)需求查漏补缺,形成闭环。 

读后感:《项目经理应该知道的97件事》中关于“矛盾体的需求说明书”
      良好的需求具体描述了你正努力解决的问题,并描述了为何一定要解决这个特别的问题(即需求需要说明“做什么”和“为什么要做”),这会使程序员在开发过程中更灵活、更高效和更积极。编码人员只有致力于解决问题并深入了解这个问题时,才会做出独立的设计选择。他们应只受限于他们已经选用的技术,而不受限于非编程人员制作的教条式的脆弱说明书。
      将你努力制作的东西与怎样去制作它区分开来。然后,让训练有素的各个团队成员根据他们自己在项目中的角色来做决定。
      倘若不分清用户需求和软件需求说明书的界线,就会导致错误的人在作决定。导致的结果无外乎两种,要么是让软件开发人员来决定什么功能对客户重要,要么是软件项目经理来告知开发人员如何构建代码。无论如何,都只会产出低劣的软件产品。 

posted on 2013-02-18 22:53 cheng 阅读(2656) 评论(2)  编辑  收藏 所属分类: 通信&政企产品

FeedBack:
# re: 浅谈需求分析
2013-02-19 14:56 | 裁线机
对这块还真不是非常了解啊  回复  更多评论
  
# re: 浅谈需求分析
2016-03-09 22:14 | ttt
看看技术人员的工作blog 学习了 慢慢看起来  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航: