`
fangang
  • 浏览: 858891 次
  • 性别: Icon_minigender_1
  • 来自: 北京
博客专栏
311c4c32-b171-3767-b974-d26acf661fb2
谈谈用例模型的那些事儿
浏览量:37544
767c50c5-189c-3525-a93f-5884d146ee78
一次迭代式开发的研究
浏览量:67406
03a3e133-6080-3bc8-a960-9d915ed9eabc
我们应当怎样做需求分析
浏览量:405167
753f3c56-c831-3add-ba41-b3b70d6d913f
重构,是这样干的
浏览量:85050
社区版块
存档分类
最新评论

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

阅读更多
很多需求分析的工作是从需求调研开始的,我们就从这里说起吧。需求调研是需求分析最重要的一环,也最集中地体现了需求分析的特点——既是一份体力活儿,更是一份技术活儿。它既要求我们具有一种理解能力、设计能力,更要求我们具有一种与人交往、沟通的能力。

在一个阳光明媚的下午,项目经理带领着项目组成员,参加了客户组织的见面会,一个新的软件研发项目就这样开始了。双方在一种友好的气氛中进行,相互寒暄,介绍与会人员,拉拉家常。逐渐地,会议开始进入了正题。初次接触客户,对于项目团队意义重大。对方对你印象的好坏,今后如何与你交往,都在这个阶段被确定下来。然而,在客户至上的今天,与客户保持适当的谦卑是有必要的,但过于的谦卑却常常给项目日后的进程带来风险。为什么这么说呢?过于的谦卑,处处都是诺诺诺,客户说什么就是什么,就会使客户变得非常强势。这样的结果就是,客户提出了许多变态的、不太现实的、不合理的需求,而我们呢却是一味地服从,客户说什么就是什么。最后我们做得很累,结果却不能让客户满意。

正确的做法是,我们对客户提出的需求进行深入理解以后,运用我们专业知识,提出比客户的原始需求更加合理、可操作的解决方案,让客户感觉你说的正是他们想要的。如果能够这样,客户不仅能够欣然接收你提出的方案,而且会感觉你非常专业,你在客户心目中的形象也会无形中提高,使你有更多的机会提出有利于开发的可行方案,降低开发的风险。这毫无疑问会形成一个良性循环,但要做到这一点并不容易,毫无疑问,在与客户接触初期的表现起到了极其关键的作用。

人与人交往,往往在接触的初期就决定了相互的行为方式,与客户交往也是一样。起初的唯唯诺诺,客户说啥就是啥,必然造成客户不再关注你的意见,对你发号施令就可以了。相反,起初展现出一位技术专家的姿态,能大方而得体地提出自己的意见,会使客户重视你的意见,甚至主动征求你的意见。这一方面要求我们对自己要有足够的自信,另一方面也要有循循善诱的表达能力。如果我们做到了这些,就会客户心目中形成一种威信,使项目向着一种良性的方向前进。

同时,这样的会议又是一个项目启动会议。客户方领导要在会议上传达给与会代表一个清晰的信号,那就是与会代表今后要积极配合我们完成今后的工作。这时候,我们要弄清,客户方有哪些角色,谁是这些角色的需求提出者与决策者。这是什么意思呢?在软件项目中,特别是管理型软件项目中,客户都代表的是一个群体,而不是个人。他们代表的可能是一个单位、一个集团,甚至是一系列组织机构。在这样一个群体中,他们按照职能被划分成了不同的角色。拿一个单位来说,横向可能划分成不同的部门,财务部、销售部、采购部、生产部••••••不同的部门,由于业务的不同,对软件的需求自然是不同的,因此我们在进行需求调研的时候,什么部门的需求就应当跟什么部门谈。同时,纵向又可以划分为多个层次,如高层领导、中层领导与基层人员,理解这些方面格外重要:

1. 高层领导
高层领导关心的是宏观的目标,因此软件研发目标、宏观统计报表、决策支持功能,都应当与高层领导谈。他们关系的都是宏观的问题,因此不要与他们谈那些细枝末节;

2. 中层领导
中层领导关心的是具体的效益,即软件给各个部门信息化管理方面带来的效益,因此,中层领导是各项业务流程、功能模块的需求决策者。他们关心功能的定义、业务流转的衔接、查询报表的设计,但不太关心一些具体的操作,以及一些具体业务流程的细节;

3. 基层人员
基层人员是每一项业务流程的操作者,也是软件今后真正的使用者。他们是真正了解你所要开发的软件的业务需求的领域专家,是你进行需求调研的重点对象。但是,基层人员往往受到自身视野的局限,可能只清楚自己工作涉及的十分狭小的一个范围,因此我们需要努力寻找那些业务涉及面广,经验丰富,又有一定大局观的真正的专家。另外,他们就是软件今后真正的使用者,让他们参加,会让他们成为今后软件推行的忠实支持者,对其他操作人员的指导者,益处多多。而他们关心的则是每项操作的细节。

划分清楚角色,弄清楚每个角色的需求提出者与决策者,就是为了在今后的需求调研中找对正确的人,使今后的调研工作事半功倍。另外,如果客户方是一个集团、一个多组织机构的政府机关、事业单位,需求的多元化问题必须引起我们的足够重视。什么是多元化问题呢?比如同样一个业务操作,在同一级别的A单位是这样操作的,而在B单位却是那样操作的。需求的多元化往往会给今后的软件开发带来巨大挑战。因此,我们要在需求调研阶段降低软件的多元化需求。要解决这样的问题,首先应当从高层领导着手,提出规范化管理的口号。同时,在进行需求调研时,尽可能地召集各个单位的代表在一起开会讨论。同时,应当有高层领导,或者指定一个负责人,在出现分歧的时候最终拍板决策。这些都需要在项目启动的时候事先规划好。

最后,与客户方领导制订出软件目标,是相当重要但常常被我们忽视的一个步骤。软件信息化管理不是包治百病的神药。很多项目的失败都归因与项目目标不明确造成的项目范围的失控。因此,这时讨论项目目标,既重要又适时。

也许在此之前我们已经做足了功课,对业务需求进行了一番详细的整理,有了一大堆疑问急需解答。但是,在这时,不是解答具体问题的地方,这是我们常常会犯的一个毛病。在这样一个会议上,我们应当询问客户方领导对这个项目的期望,渴望达到的项目预期,而我们应当描述的,是对达到这些预期的整体解决方案,凡此等等。

俗话说:万事开头难。如果你在项目开始的时候总感觉千头万绪不知如何着手,在这里我给大家的三点建议:1)树立良好的职业威信;2)进行详细角色分析,将与会各方代表对号入座;3)从宏观上制订目标与方案。随后的工作,就是与各方代码建立联系,逐一拜访他们,将需求调研工作一步一步进行下去。

我们应当怎样做需求分析
我们应当怎样做需求调研:初识
我们应当怎样做需求调研:拜访
我们应当怎样做需求调研:研讨会
我们应当怎样做需求调研:需求研讨
我们应当怎样做需求调研:迭代
我们应当怎样做需求调研:需求捕获(上)
我们应当怎样做需求调研:需求捕获(下)
我们应当怎样做需求分析:功能角色分析与用例图
我们应当怎样做需求分析:业务流程分析(上)
我们应当怎样做需求分析:业务流程分析(下)
我们应当怎样做需求分析:用例说明
我们应当怎样做需求分析:查询报表分析
我们应当怎样做需求分析:子用例与扩展用例
我们应当怎样做需求分析:行动图和状态图
我们应当怎样做需求分析:业务领域分析
我们应当怎样做需求分析:原文分析法
我们应当怎样做需求分析:领域驱动设计
我们应当怎样做需求分析:非功能需求
我们应当怎样做需求确认:需求列表
我们应当怎样做需求确认:一个需求列表的实例
我们应当怎样做需求确认:快速原型法
我们应当怎样做需求确认:需求规格说明书
我们应当怎样做需求确认:评审与签字确认会

(续)
分享到:
评论
5 楼 allenchan 2014-08-21  
非常感谢博主,受益匪浅
4 楼 fangang 2012-02-02  
重新维护了一下,把这里提到的3个问题更透彻的分析了一下
3 楼 maimode 2012-02-02  
在客户至上的今天,与客户保持适当的谦卑是有必要的,但过于的谦卑却常常给项目日后的进程带来风险。

正确的做法是,我们对客户提出的需求进行深入理解以后,运用我们专业知识,提出比客户的原始需求更加合理、可操作的解决方案,让客户感觉你说的正是他们想要的。

学习了!
2 楼 aloneno1 2012-01-30  
听君一席话,胜读十年书。
在需求调研的时候,我发现总是难以拒绝一些不合理的需求,我觉得我的问题在于“提出比客户的原始需求更加合理、可操作的解决方案”

继续关注博主
1 楼 o0rid0o 2012-01-29  
如何做好需求分析是我们今年的一大课题呢,看了你的文章我有了很多感触,谢谢~

相关推荐

Global site tag (gtag.js) - Google Analytics