软件需求和问题解决-转载

(一) 
   小满当上项目经理后不久,参与了一个大项目。当时市场签下来的时候,公司里面是欢天喜地的。项目做了一年多。到了交付的时候,用户却很不满意,当初说好的东西,好多都变了卦。
   用户是上帝,最关键的是如果收不到后面的钱,那就算白干了。公司要求项目组加班加点的修改。搞得大家是怨声载道的。做市场的和做开发的相互指责,然后,大家又一起骂客户刻薄。公司里面弥漫着灰心丧气的气氛。
   小满觉得郁闷的很,就跑去跟老鸟聊,看他有什么主意。 
   老鸟听了小满的一通抱怨,说:“很正常。以前我们也经常遇到这样的情况。很多案例说明,失败是一开始就注定了的。”

  (二) 
   老鸟说:“你们怎么跟客户谈论或确定需求?” 
   小满想也不想就说:“他们市场先谈单,估计人家需要做什么。然后,我们这边就派一个技术的人过去了解需求,拿一些对方的表格和笔记回来。好像都差不多。” 
   老鸟说:“然后呢?” 
   小满说:“我们做好一个需求文档,罗列出开发功能要点。附在合同的后面。大体上就是这样。” 
   老鸟说:“看起来没啥问题。好像还很严密。” 
   小满说:“你的意思是有问题?” 
   老鸟没说话,从旁边拿了一张纸,用铅笔在纸上画了两个圆。问小满:“你说,这是啥?” 
   小满说:“两个圆。” 
   老鸟摇摇头:“是两个鸡蛋。” 
   小满觉得老鸟很无聊,不耐烦的说:“好吧,就算两个鸡蛋。” 
   老鸟摇摇头:“不是,这不是鸡蛋。这是两个乒乓球。” 
   小满不知老鸟在暗示什么。他在听。 
   老鸟说:“我看到的东西,和你看到的东西,不一样。但是,在纸上,画的是同样的两个圈。” 
   小满说:“哦。” 
   老鸟说:“你们去询问需求,然后做了一个文档。你们头脑里的东西,跟客户要的东西,其实是不一样的。但是,大家都认为这样白纸黑字,基本上是一样的。这里面其实有差异。这种差异,有时影响不大,但有时,是致命的。毕竟文档,不是最终的实物。”
   老鸟说:“客户永远认为,他是把需求给你讲清楚了的。如果你做不到,不是他的责任。而且,你要记住一点,用户只有在见到或使用过实物的时候,他才知道他其实要的是什么东西。”
   小满点头:“最后这句话,我严重同意。可是,要按你的说法,那用户和我们就永远不可能真正存在沟通一样?哪不成了虚无主义了吗?” 
   老鸟说:“我说的是这样一种情况:如果你不了解客户的业务,或者真正熟悉它的行业规则的时候。你需要更严谨的方式来询问和确定需求。否则,那些落在纸上的文字和文字之间,埋藏着数也数不完的陷阱。”
   小满说:“那你们一般怎么做?” 
   老鸟说:“开始一样,还是会有一个初步的文档。但是在合同签下来后,会有一个相对时间较长的需求的再确认过程,我们会和客户一起来走一个流程。然后,我们会把大家商业的结果,转换成最终的设计,用PPT把它的操作界面和业务流程都模拟出来,让用户有身临其境的感觉。在正式开工以前,给客户汇报。到此为止,我们并不做任何真正的编码工作。”
   小满说:“这样做,还是很花时间,效果如何呢?” 
   老鸟说:“相对于搞错了需求,重新开发,这是最合算的了。很多人都不愿意这样做,最后,项目没完,人都跑光了。这种事情,也是不少啊。” 
   小满说:“这样看来,我们的需求是比较简单了。如果遇到理解偏差,就会出大问题。” 
   老鸟说:“需求阶段过于匆忙,也会出问题。比如说,客户忙,随便给你找一个表格,就跟你说,我要的就是这个。或者有些用户就直接告诉你,他要怎样怎样。” 
   小满疑惑了:“客户不都是这样吗?有何问题呢?” 
   老鸟说:“客户没有问题。而是去问的人要格外的小心了。他要注意一下客户的立场:客户关注自己要的结果,但是每个人关注的东西不同。比如说领导不关心过程,关注结果;实际做事的人希望不要给他们增加过多的工作任务,越傻瓜越省事越好;部门级的人关心新系统是否剥夺了他们的权力,如果是这样的话,他们一般会给你找各种理由搪塞;而系统管理员,关心技术和安全。总之,每个人都各怀心事。需求是多种多样的。还有一些人,他就象一个设计者一样,跟你说,让你跟着他的思路走。其实,都需要仔细记录,认真掂量。”
   小满说:“如何掂量?” 
   老鸟说:“多问自己几个问题。他们的问题来自于哪些方面?真正的问题是什么?是谁的问题?哪些问题是可以简单的,哪些是比较复杂的。”
   老鸟说:“我遇到很多次了,很多人去做需求,以为拿着本子记下来就好了。其实,很多时候,都没那么简单。觉得简单,是因为很多人认为从技术上设计这类的软件,简直是小菜一碟。但是,他没有想到的是,很多问题是不可能光靠软件就能解决的。”
   “有一次,有位客户气急败坏的来找我,他说他要设计一套软件,加强管理。我问他起因。他说他下面店的经理,因为山高皇帝远,经常想方设法隐藏收入。我说:这种管理的软件多的很,不需要单独开发。你需要的不是一套软件,而是一套相应的监督机制。”
   “结果,他就是坚持要做,他觉得要把所有的店控制起来。他不想买现成的。现成的有些特别的功能满足不了。” 
   小满插了一句:“客户都希望自己的东西是独一无二的。” 
   老鸟说:“你猜后来的结果如何?我们简单做了一个非常简单的设计,报了一个天价。他自己再没吭气了。” 
   小满说:“你们损失了一个客户,不觉得可惜吗?” 
   老鸟说:“我们经过了仔细的询问和调查。一是他的需求很奇怪,贪大贪全。而且要求的时间比较紧。但是他的价格,我们做不出来。” 
   小满说:“他为何不找其他的帮他做呢?” 
   老鸟说:“太大的公司,人家没空做你这些。太小的,他又不放心,当然,还有一个重要的原因,也是我们最后打算放弃的真正原因。” 
   “他找我们做软件,解决下属公司的问题,并不是他真正的需求。我们有一次讨论的时候,他说高兴了,自己说漏嘴了。他说他正在跟香港某公司谈融资的问题,对方对管理要求很高。”
   “当时,我就想:哦,这是一锤子的买卖。如果要做的话,我们要不吃亏才好。所以,我们就说了一个价格,把他吓跑了。” 
   小满笑了。 
   老鸟说:“你看,我们白谈了20多天。结果就这样完了。所以,尊重客户,也要尊重自己。不要把客户当傻瓜,也不要让自己做傻瓜。” 
   小满说:“你从哪儿学到这一套的?” 
   老鸟说:“告诉你,所以的秘密都在这里” 
   他递过来一本书。书名叫《你的灯亮着吗?》。 
   老鸟说:“这是要学习思考问题的人的必读书,也是项目经理的必读书之一。” 
   
  (三) 
   小满向老鸟借书。老鸟坚决不肯。小满知道老鸟其他都很慷慨,除了书以外。他自己买了一本,并作了一些摘要。 
   小满是这样写的: 
   怎么去寻找一个问题的解决方案? 
   【1】首先要确定问题从哪儿来? 
   【2】然后确定是谁的问题? 
   【3】发现真正的问题所在; 
   【4】在特定的层面上理解问题,并寻求合理的解决方案; 
   【5】有时,人们真的需要去解决他们所认为的问题吗? 
   小满还写下了自己对专业的理解: 
   什么是真正的专业呢?过去,我一直以为有了专业技术,就算专业了。现在,看来还远远不够。有技术的人,容易犯一个错误,就是把专业当一个万用的榔头,看见什么问题,都想用榔头把它敲下去。但是,很多问题,不是光用榔头就能解决的。
   所以,并不是一开始就把榔头亮出来,而是多问自己几个相关的问题。有时,思考比榔头好用的多。多样化的思考,会让你以简洁有效的方式去思考问题。而不是迷失在快速搞定事情的方向上。
   指责客户是没用的。但是,你可以思考,发现问题的真正所在,用内心的灯去照亮前进中的道路。

时间: 2024-11-15 11:15:50

软件需求和问题解决-转载的相关文章

软件开发流程(转载)

软件开发流程 迭代化软件开发技术 1. 传统开发流程的问题 传统的 软件开发流程是一个文档驱动的流程,它将整个软件开发过程划分为顺序相接的几个阶段,每一个阶段都必需完毕所有规定的任务(文档)后才可以进入下一个阶段. 如必须完毕所有的系统需求规格说明书之后才可以进入概要设计阶段,编码必需在系统设计完毕之后才可以进行.这就意味着仅仅有当所有的系统模块所有开发完毕之 后,我们才进行系统集成,对于一个由上百个模块组的复杂系统来说,这是一个很艰巨而漫长的工作. 随着我们所开发的软件项目越来越复杂,传统的瀑

敏捷软件开发要点【转载】

下面的文字来自于<敏捷软件开发 原则.模式和实践>一书,作者是Robert C. Martin.我把这些文字发布在这里,希望对敏捷软件开发还不是很了解的朋友所有帮助.我推崇这本书,是因为它提出了许多有价值的软件项目管理的理念,以及软件设计思想和方法,其中,很多可以直接用在我们的工作中,或用来指导我们的工作----敏捷软件开发是务实的. 一.敏捷软件开发宣言 我们正在通过亲身的实践以及帮助他人实践,揭示更好的软件开发方法.通过这项工作,我们认为: 个体和交互 胜过 过程和工具 可以工作的软件 胜

怎么通过应用程序控制策略限制软件运行?(转载)

1.打开控制面板,选择管理工具.如下图所示:2.选择本地安全策略.如下图所示:3.打开本地安全策略后,打开"应用程序控制策略"--点击"Applocker".如下图所示:4.打开 Applocker 后如下图:5.再设置规则前先确认 Application Identity 服务是否设置为自动启动,只有该服务启动,Applocker 设置后才生效,开启方法同步骤 1 ,打开搜索后输入"Services.msc",打开服务设置界面.如下图所示:6.

机房收费系统(三)软件需求说明书

软件需求说明书 1引言 1.1编写目的 软件需求说明书是需求分析阶段的一个文档,是对软件目标及范围的求精和细化,深入描述软件的功能和性能以及软件的约束范围,使用户和软件开发者对该软件的初始规定有个大概了解,有利于对项目的回溯和指导后续的开发和维护. 文档读者:开发人员与用户代表 1.2背景 A.待开发软件名称:机房收费系统 B.项目提出者:米新江教授 开发者:周家林 用户:廊坊师范学院全体教职工和学生 实现该软件的计算中心或计算机网络:廊坊师范学院机房局域网 C.该软件系统同其他机构的基本的相互

软件需求与分析课堂讨论一

课堂讨论 分组:每4人一组 内容: 某大学为进一步推进无纸化考试,欲开发一考试系统.系统管理员能够创建专业方向.课程编号.任课教师等相关考试基础信息.教师和考生进行考试相关工作.系统与考试有关的主要功能如下: (1)考试设置:教师制定试题(题目和答案),制定考试说明.考试时间和提醒时间等考试信息,录入参加考试的学生信息,并分别进行存储. (2)显示并接收解答.根据教师设定的考试信息,在考试有效时间内向学生显示考试说明和题目,根据设定的提醒时间进行提醒,并接收学生的解答. (3)处理解答.根据答案

需求工程-软件需求模式读书笔记1

今天读完这本书<软件需求模式>的第一部分,也就是准备阶段. 需求分析是困难的.需求分析师又往往缺少经验和训练.本书的目的是帮助和决定新的软件应该走什么,建议添加那些额外的特性,使系统更好或更卓越.需求模式是经验的结晶,本书主要建好了37个模式,解决了所有系统中反腐出现的特定问题.适合业务分析师.软件架构师和工程师.软件开发人员.软件测试人员.项目经理等人员阅读.. 软件系统的需求定义他要定义的问题:它的的意图和目的.为了更好地构造系统需要一系列的改进.该书主要可分为两部分:第一部分:解释开始,

软件需求模式 读书笔记三

通过这一个月的阅读,我终于读完了<软件需求模模式>这本书,前两个读书笔记已经把这本书的几种模式介绍了,之前有基础需求模式,信息需求模式,数据实体需求模式,用户功能需求模式.这次介绍的是性能需求模式,适应性需求模式,访问控制需求模式和商业需求模式. 性能需求模式包括五种的性能的需求模式:影响时间(系统需要多少时间完成一个请求).动态容量(系统能够同时处理多少件事).吞吐量(系统处理时间的速率).静态容量(系统可以保存多少某种类型烦的实体)和可用性(什么时候系统对用户是可用的,以及多么可靠). 当

软件需求说明书

1引言 1.1编写目的 1.2背景 1.3定义 1.4参考资料 2任务概述 2.1目标 2.2用户的特点 2.3假定和约束 3需求规定 3.1对功能的规定 3.2对性能的规定 3.2.1精度 3.2.2时间特性要求 3.2.3灵活性 3.3输人输出要求 3.4数据管理能力要求 3.5故障处理要求 3.6其他专门要求 4运行环境规定 4.1设备 4.2支持软件 4.3接口 4.4控制 软件需求说明书 1引言 1.1编写目的 (1)为了更好的了解软件的需求,该文档可供用户浏览,了解海法内容和各部分模

《软件需求十步走》阅读笔记六

本次阅读笔记写一下<软件构造十步走>最后一篇<组织篇>. 本篇共分为四章,分别是建立需求分析体系,需求分析部门的组织结构,需求分析部门的管理工作,需求分析部门的业务工作. 首先是<建立需求分析体系>. 长期以来"轻业务.重技术"的理念根深蒂固,而解决措施是建立一个专业从事软件需求分析的独立部门来承担这项工作.此部门是介于业务部门和技术部门之间的,专门负责对组织自身业务.客户业务.客户对象和竞争对手的研究,然后将其转换成提供给技术部门的软件需求规格说明