站点公告
最新日志
博文评论
博客留言
博客登陆
博文搜索
博客信息
收藏连接
 
谈需求管理 —— 连载1 
一孑 发表于 2009/6/11 9:52:00

准备好好花点时间详细的说明一下需求的管理,并结合曾经做过的项目,阐述一下需求阶段内容。尽管是准备花点时间来仔细斟酌考虑这部分内容,但还是要说,其中的方法或者观点并不一定正确,只是根据经验总结而得。马上进入正题。

需求的重要性是显而易见的,在此仅说两点来再次证明需求的重要性:1)、需求工作是在确定项目边界;2)、项目质量的主要衡量标准就是是否满足用户的需求。所以,需求没做好,意味着项目范围是不可控的,质量也是无法衡量的。

对于软件项目而言,需求管理可以分为两个内容:需求建立需求跟踪。需求建立又可分为需求获取、分析、输出和验证。需求跟踪可分为需求跟踪及变更控制。在需求建立阶段,主要参与的人员就是需求工程师(注意是“主要”,根据项目的不同,及管理模式的不同,此阶段可能会有其他角色的人员参与,笔者认为合理的做法会在后面中进行说明),需求跟踪则参与的人员会多一些,但也会依据具体的项目规模、团队构成等因素而定。

依据项目类型的不同,对于需求工程师的要求也不同,但无非是偏重业务领域经验多一些,或偏重项目领域经验多一些。但从笔者的工作经验来看,需求工程师最主要的能力应该在于是否具备灵活的思维方式及较强的逻辑思维能力,通俗点讲就是是否可以站在对方的角度来思考问题及理解问题。在笔者所参与的项目中,最怕遇到的就是以“我”为中心的需求工程师,虽然其自己也努力克制,但实际已经篡改了用户的思想,以“我”的思想为主了,这种变化很多时候是无法感知的。

好了,前面已经做了一些铺垫,下面开始说明每个阶段的内容。

一、        需求建立

任何项目都会经历此阶段,只是有些项目会有明确的用户(甲方)需求,有些项目没有明确的用户需求(产品型)。但无论是何种项目类型,都是为了满足特定群体(用户、市场、其他部门)的某种需求(管理、办公、甚至是娱乐)。需求的建立可以分为需求获取、分析、输出机验证四个环节。

1、 需求获取及需求分析:

通常情况下,需求的获取与分析是同步进行的,而且是不断循环深入的,获取->分析->再获取->再分析。很多需求分析师在甲方做调研的时候,通常都是1天的信息收集,1天的信息分析,或者白天收集信息,晚上进行分析。分析的工作是至关重要的,在此总结了一些分析工作的重要性,可结合自己的实际项目进行参考:

1、  指导后续工作;

2、  确认用户的真实需求;

3、  挖掘用户的潜在需求;

4、  寻找遗漏的业务;

5、  寻找量化需求的方法;

6、  寻找验证需求的方法;

7、  确认需求的完整性;

8、  进一步确认项目的边界范围;

实际还有很多重要性,在此不再重复了。总之需求分析是非常重要的。同时也需要清楚的知道,需求分析并不是随着需求获取工作结束而结束,对需求分析而言,这只是一个开始。

1)         需求获取

需求获取通常采用的方法总结如下(无重点顺序之分):

a)         通过采用提前制定的调研表来收集用户需求;

b)         收集用户业务表单、流程信息;

c)         采用访谈方式获取用户需求信息;

d)         通过召开双方会议来获取需求信息;

e)         模拟实际业务流转来获取需求信息;

下面几点较适用于产品型项目:

f)          竞争产品分析;

g)         市场需求分析(通过需要查阅大量的资料);

h)         市场发展方向及预测分析(实际是获取潜在需求);

对于需求工程师而言,在需求获取时一定要“来者不拒”,即只要用户提出来的内容、给于你的资料都要接受,至于是否有用、是否超出项目边界,在分析阶段剔除,不要在获取阶段就做这样工作。

同时需求获取时尽量不要给于用户一些关于系统的承诺,也不要给于用户过多的需求分析结论,但实际情况下,这些都是不可避免的,沟通是有来有往的,用户给于了信息,肯定希望获取信息,但这个时候不建议需求工程师给于过多的明确答复,一是因为很多内容都还处于一个模糊的阶段,任何承诺都不会准确,其次需求分析师不是技术人员,对于技术实现并不擅长,此时给于的答复也会过于草率。还有一种情况就是:销售人员期望拿单所以会做过多承诺,这也是销售与PM的主要矛盾之一。针对这种情况,通常是在需求获取阶段增加技术人员或业务领域专家来解决此类问题,即便有了这样的人员,但还是会通过一些正式的需求沟通来进行答复,这样做的目的是消除需求工程师或销售工作中的“失误”(毕竟需求工程师或销售的沟通是无法控制的,很多时候为了工作方便会做出一些答复),并规范项目管理的沟通渠道(告诉甲方,其他人说话都不算,只有指定的责任人才算话,呵呵)。

在这个阶段中,常犯得错误有两点:

a)         成为了一个倾听者,而不去交流、引导;用户是不知道该给你何种有用的信息,需要引导用户去说明自己所做的业务内容,但不要让用户会滔滔不绝的给你讲业务(这还算不错的用户),而需求分析师则成了一个倾听者,最终就是,讲完收工回家。

b)         跑题;与业务打交道的通常是底层的业务人员,要知道任何业务模式都有其优缺点,所以,很多时候业务调研就成了业务人员的牢骚会,不断的质疑当前业务管理的问题,要知道业务是否合理、是否存在问题不是需求人员解决的问题,需求工程师只要把业务了解清楚就可以了,当然所存在的问题也要了解问题,至于如何解决不是这个阶段的重点,也许用户更关注如何解决,但这不是需求工程师的问题,很多时候是由于用户站的角度不同所以看到的问题才会不同,需求工程师不要跟着用户去跑,重点还是在收集信息。

(未完待续!)

发表评论:

    昵称:
    密码:
    主页:
    标题: