三九宝宝网宝宝教育学龄段教育

软件需求实践之需求的沟通与分析

12月02日 编辑 39baobao.com

[如何和孩子沟通]我家女儿上小学一年级,在学校表现得比较好,但到家里爱发脾气,但大人还不知道原因,她就不高兴了,问她也不说,这种情况该怎么办? 父母是孩子的第一任老师,对孩子一生的发展十分重要。...+阅读

在信息化高速发展的今天,构建与时俱进的信息化系统已成为所有政府、企事业单位的重点课题之一。然而在软件项目实施过程中,进度超期、经费超预算、变更频繁的现象层出不穷,甚至有许多项目根本无法达到预期的目标,更谈不上为业主创造真正的效益。归根结底,软件需求实践这一共同的软肋是问题根源之所在。

引言

关于软件项目所存在的问题,互联网上曾经流传着一幅漫画,它十分生动地展现了这些问题。也许很多人看完之后只是一笑置之,但如果我们认真剖析后面的东西,还是会给我们的工作带来许多启发的。

沟通失真

究其原因,这幅漫画给人的启示就是在需求沟通过程中产生了严重的失真,从客户的描述到项目经理的理解、分析员的设计、程序员的编码、商业顾问的诠释,每个角色都根据自己的特点和需求对信息进行了不同的加工,从而导致信息的内容有了很大的改变。因此,对于软件需求工程而言,克服沟通失真就成了一个要点。

根据相关的研究显示,在信息的传递过程中,如果没有采取任何措施,那么在沟通过程中信息衰减可能的值高达60%。而在软件开发过程中,需求信息通常要经历用户代表、需求人员、设计人员再到开发人员,因此最坏的情况下,开发人员获得的信息仅是原来的8.4%(如图2示),这是一个十分可怕的结果。

怎样才能够更好地避免这种问题的出现呢?其实关键的手段有两个:

文档:如果信息在传递的过程中仅靠口口相授的话,就难免发生遗忘、加工等情况,因此必须在这个过程中有效地利用文档,将达成共识的信息文档化。但这种方法只是用来辅助沟通的,而不是代替沟通,这一点在后面还会提到。

Review:在此有意使用了英文,因为国内常将其翻译为“评审”,但这一翻译却容易给人误导。评审在很多人的脑海中就是得出一个通过与否的结论,这也是导致需求评审工作流于形式的罪魁祸首之一。顾名思义,Review就是再(Re)看(View)一遍的意思,其本质含义是通过再次的审读,尽早地暴露出错误。而最简单、有效的Review就是在用户代表阐述了需求之后,需求分析员用自己的语言再复述一遍,以确保沟通没有失真。

隐喻:经理叫来了小张,然后就下一阶段的工作做出了一些重要的指示和安排:“$%#^#(*)##……”。

小张正要扭头走的时候,经理叫住了他,说到:“你简单地说说看,我刚才给你交待的任务有哪些”(看来管理人员早已掌握了这一招)。

提示:如果有一个测试人员对你说:“我前天仔细测试了一下你写的程序,发现一个问题也没有,恭喜你!”。你会怎么想呢?

a. 觉得自己的程序写得很好!

b. 觉得测试人员方法不得当或测试不细致。

我想大多数人都会做出“b”的选择!可是到了需求评审时为什么却转了180度的弯呢?为什么期望需求评审时一点问题也没有呢?

“沟通失真”高度概括了其中所蕴藏的问题,但如果我们细细地思考第

1、

2、

3、

4、10幅图(这五幅图中的景象与需求活动有很大的相关性),并将其两两比较就会得到一些有益的启发。下面我们就一起来看看。

客户:放大需求

当我们比较图1中的1幅和第10幅图时,就会发现用户在描述自己的需求时做了许多“添砖加瓦”的事。“用户要么不会说,要么就会添油加醋”的现象,在我的实践中是屡见不鲜的。而在这种现象的背后有什么潜在的原因呢?我认为至少有两方面关键因素:

(1)客户希望支付的成本尽可能少,获得的效益尽可能多

这种思维对于任何一个客户、任何一个人而言都是本能反应。而当用户对开发成本越不了解时,这种心态就会越强烈,更加担心自己“亏损”了;因此在需求协商时就会采取尽可能增加功能的方法来降低“亏损”的风险。

要有效地克服这个因素的困扰,核心的要点在于建立客户对开发团队的信任度,而建立信任度的要点有两个方面:一是需求人员必须提升自己的专业主义(关于这一点我将在后续的文章中说明);二是需求人员要多站在用户的角度想问题,让用户感觉需求人员的目标是帮助自己解决问题,而非一味谋取利益。

(2)解决方案的选择权交给了不熟悉技术的客户

也就是用户经常会谈解决方案,甚至许多需求团队在进行需求捕获活动时,经常预期用户能够直接告诉他们要做什么(What),而不太关心用户提出需求的真正动机(Why)。但是这样就将解决方案的选择权交给了并不熟悉技术的客户代表,而客户代表选择的解决方案不是最合适的话,就必将引发后续的需求变更。

案例&场景:

在一次CRM软件开发的过程中……

负责输入客户信息的用户向开发人员提出:“你看这个界面,光电话就有快10个输入框,太麻烦了,每次按tab键都按酸了。我希望把他们合并成两个,一个为常用电话,一个为其他电话”。

“那有多个电话怎么办?”,开发人员回应道。

“其他电话的输入框可以设置为多行的、较宽的,这样我可以输入多个,中间用逗号分开它!”。

“好的,没问题” 。

……

当经理看到了这些客户信息之后,向开发人员提出:“我需要一个功能,输入任何电话号码,自动找出相应的客户。”

“啊……”

如果我们细究这个场景,分析一下负责输入客户信息的用户所提出的变更就会发现:“将10个电话输入框合并成两个”显然是解决方案,而真正的需求是“输入太麻烦了,每次按tab键都按酸了”。你或许就会想到如下所示的解决方案:

也就是说,默认情况上只显示左边的部分,当需要时点击“其它>>”按钮就可以将右边的不常用输入项显示出来。

总而言之,因为对于一个特定的问题可能的解决方案会有很多,因此用户可能在使用软件的过程中不断发现其他可选的、更合适的替代方案,从而导致了不必要的需求变更。而要缓解这一现象的关键就在于在需求捕获的过程中多问“为什么”。

项目经理:控制需求

当我们比较图1中第1幅和第2幅图时,就会发现项目经理在沟通的过程中会导致需求产生偏差。由于国内许多软件项目经理们通常是一身兼多职,项目管理、需求分析、架构设计一肩挑,因此在需求捕获的过程中,总会“及时”地在脑海里勾勒出技术框架和路线,然后尽可能地控制需求的范围。

就像这里,客户需要的可能是一个“秋千”或者是“上树工具”,但不管真正的需求是什么,第2幅图中的解决方案却都无法有效地满足。如果要做“秋千”,不应该被树干挡住;如果要做“上树工具”,木板的数量显然太少了。

究其原因不难发现,需求人员首先从项目经理的视角按工作量对需求进行了控制:将“三层”板的工作量减成“一层”板,如果不小心控制掉的是对业务很重要的东西,那么最终一定会以变更的形式“回报”给开发团队的。然后需求人员又从架构师的角度进行了“改良”:不稳定的“全挂在一个树枝上”改成“挂在两个树枝上”,结果根本无法使用。

因此具有多个角色的需求人员,必须在需求的过程中“戴正自己的帽子”,真正从理解业务的角度来捕获需求。

分析人员:技术加工

案例&场景:

分析员小张:“嘿,伙伴们!我有个提议,我们研究Hibernate已经有一段时间了,一直没时间真正动手用一用。我看这个项目就不错,不算太大,就用它试试吧!”。

“好主意!”,大家纷纷表示赞同。

……

“约定时间已经过去1个月,现在项目进展到底如何了?什么时候可以交付?”,客户方CIO质问到。

分析员小张:“现在主要困扰我们的是一些需求细节一直存在变化,开发团队又有了一些人离职,所以……”(真正的情况是:由于团队第一次使用Hibernate,有些数据访问层的问题一直没有有效解决,导致进展不断失控。)

现在许多名称中包含“需求分析”、“系统分析”之类的职位,大多是由技术骨干担任的,因此在工作中很少从业务角度进行分析,更多还是追求技术框架、新技术。对于这种现象,究其根源,关键还在于“技术能力”对他们的未来发展更为重要,而“业务能力”却不是那么重要。但为了使需求工作有更好的提高,我会强烈呼吁那些Title上有“分析”之类名称的人们,加强业务分析吧!

编程人员:断章取义

对于第4幅图,可以用一句生动的话来概括:“你要绳子,我给你了;你要木板,我也给你了;你为什么说这不是你想要的呢?”。我想程序员也有类似的问题想问自己的客户,“你要文本框,我提供了;你要一个表单,我也有了;你为什么说这个程序不是你想要的呢?”。这让我想起了这样一幕:

案例&场景:

叮铃铃……,程序员小赵的电话急促地响起。小赵刚接起电话就听到了对面迫不急待地抱怨声“仓库管理员反应,入库模块没法使用!你马上查一下,尽快解决一下!”。

小赵放下电话就开始Check out、Builder、Run、Debug……等一系列操作。经过一番测试之后,小赵没好气地提起电话回复说:“这些客户真是笨!这哪有问题,肯定是操作上出了问题!我怎么用都是好的,你们客户服务的人也应该加强对用户的培训,别什么事都扔给我们!”。

……

可是,问题仍然没有解决!开发人员到了现场一看,终于发现了问题的所在:这是一套基于B/S的仓库管理系统,在入库时,仓库管理员首先需要录入入库单,然后填入“验收情况”,最后点击“入库”按钮。但当仓库管理员录入完入库单,逐一验过入库货物之后再回到电脑前时,等待他的却是一个令其不知所措的问题,Session超期!

一肚子气的小赵一个电话就打到需求分析员小钱那里:“你们的需求是怎么写的!这么重要的东西也不写明白,我们怎么知道填完入库单后要验货那么长时间,才填写验收情况呀!”。

“哦,这也算是需求吗?如果这也算的话,那我们岂不成了业务人员了!”,小钱很强势地回答到。

这是需求吗?也许很多读者会有不同的看法!但如果缺乏对业务场景的了解,又如何能够真正理解需求呢?断了“业务场景”之章,必将导致取出的“需求”之义有所偏差呀!

作者简介:中国系统分析员顾问团软件工程首席顾问,中国软件技术大会杰出贡献专家,资深咨询顾问。主要研究领域为需求工程、系统分析与设计、软件估算,致力于推动软件工程方法论的落地应用。本文节选(并改编)于笔者新著《软件需求实践:SERU过程框架原理与应用》(电子工业出版社博文视点)

以下为关联文档:

保持家校沟通促进孩子成长一个孩子的成长,离不开家庭、学校和社会。 一把钥匙开一把锁 ,真正有针对性地培养一个身心健康的孩子,必须加强学校与家庭的联系和沟通,家访就是最好的途径。 前段时间有幸参与...

儿童的心理需求现在的父母,常常为了儿童的身体的发育,竭尽所能为儿童补充大量的营养品,以期他们有一个健康的体魄。然而,有些父母往往忽略了儿童在其心理的成长过程中也需要补充一些“心理营养...

平等地交流和沟通,才能更好地教育孩子我很喜欢孩子,特别的小班的孩子,因为觉得他们很好玩,什么都懵懵懂懂,你说什么他都会相信。比如说一次,我对一个孩子说 你的鞋子被大灰狼拿去了。 他点点头 哦,老师你帮我把大灰狼...

与家长进行情感沟通九畹溪镇幼儿园 谭林桂今年我们班有35名幼儿,我们的目标是走进每一位幼儿的家中,但是家长们对于我们家访反应不一:有的惊讶,是不是我的孩子在幼儿园里犯了严重的错误,老师要到家...

有些成长需要沟通——与家长沟通的一次成功案例折纸活动开展以来,孩子们学习的气氛一直很足,折纸似魔术般的神奇,每次折纸教学后,孩子们下课后,三五成群,纷纷聚在一起相互摸索起来。这几天,我发现小宇总是闷闷不乐的坐在那里,手里...

与家长沟通,使家长了解“家庭中的做中学”作者: 费萍 陈鹤琴先生指出幼儿教育是幼儿园与家庭共同的责任, 儿童教育是一件很复杂的事情,不是家庭一方面可以单独胜任的,也不是幼儿园一方面可以单独胜任的,必定要两方面共同...

心灵沟通,拉近师生间的心理距离读了《唤醒学生自我意识,促使自主学习》一文,我深深感动于书中李老师对学生的爱和责任感,她为在成长中迷途的孩子寻找心灵的家园,运用写日记的方式和学生做心灵上的沟通,敞开心扉...

通过家校沟通来形成教育合力,帮助孩子擦亮人生的底色新沂市时集中心小学 李红侠,一个真实的故事。这个故事发生在学校国旗台旁。一天,一个家长和孩子,走在校园经过国旗台旁,家长把替孩子擦鼻涕的一团卫生纸随手丢在了地上,小男孩立...

读《沟通人生心理交往学》有感| By: 18金晓雯 ]沟通是一门艺术,在人际交往中起着十分重要的作用。现在的幼儿,很多都是独生子女,在家里娇生惯养。以自我为中心,不会与同伴沟通和交往。他们在生活中也缺乏与他...

推荐阅读
图文推荐