横看成岭侧成峰
放大软件的职能和概念对于软件尤其是大型系统的需求管理是极其不智的，可叹的是有些软件厂商夸大软件功能或玩转若干概念，目的是为了赢得客户的青睐，而这后果也就造成了恶性循环和劣币驱逐良币现象的发生。软件的职能受制于硬件性能，也回归到一点：软件最终还需要依赖于机器去执行指令；尽管软件经过软件工程、算法等加工可以对机器性能和智能放大到机器所能承受的极限，但机器终究无法与人类目前所要求想符合。实际上，在人类科技发展过程中，因为实际需求去设计开发了某种工具，然后工具的使用又促使我们在实际应用中去改良工具及其使用工具的方式方法，这种相互作用和辨证统一关系同样也体现在人类与计算机上。
计算机是一种工具，但怎么理解计算机呢？懂计算机，是否意味着你懂硬件、懂软件、懂网络、懂各类应用软件的操作、懂系统集成、懂人工智能、懂计算数学吗？计算机和IT等同吗？这些概念没有去一一辨析的必要，但肯定要理解任何一套软件和人一样都只能服务于其特定职能范围内。正如客户认为从事软件业的人应该懂与IT相关的任何事，客户对软件的需求往往也陷入软件无所不能的看法，可以完全替代或帮助客户在工作中解决大部分问题，这对需求管理带来致命性问题。但又不能否认需求变更的必要，因为随着客户见到更多有形软件的运行并结合本身实际工作，肯定会提出更深入的需求，对于需求变更在软件工程领域有很多过程来满足。可怕的是这些需求超越了软件或机器作为一种工具的本身职能。
不可否认只有超越极限的要求才能促进技术革命性跳跃，如web2.0创新性，但也依赖于硬件的跨越。本文这里谈的需求管理侧重于两点：每个软件有自己职能范围不能无限制要求其扩大职能；软件仅是工具，工具只能部分替代或帮助人的工作。而这两点统归一点就在于：如何有效进行需求管理，抑制需求的无限扩大化。下面有两个例子，其中一个是转载的，另一个是笔者亲身经历的需求调研并在需求管理中遇到的。
============================转载例子-开始======================================
某日，老师在课堂上想考考学生们的智商，就问一个男孩:“树上有十只鸟，开枪打死一只，还剩几只？”
男孩反问:“是无声枪么？”
“不是。”
“枪声有多大？”
“80~100分贝。”
“那就是说会震的耳朵疼？”
“是。”
“在这个城市里打鸟犯不犯法？”
“不犯。”
“您确定那只鸟真的被打死啦？”
“确定。”老师已经不耐烦了，”拜托，你告诉我还剩几只就行了，OK？”
“OK。鸟里有没有聋子？”
“没有。”
“有没有关在笼子里的？”
“没有。”
“边上还有没有其他的树，树上还有没有其他鸟？”
“没有。”
“方圆十里呢？”
“就这么一棵树!”
“有没有残疾或饿的飞不动的鸟？”
“没有，都身体倍棒。”
“算不算怀孕肚子里的小鸟？”
“都是公的。”
“都不可能怀孕？”
“………，决不可能。”
“打鸟的人眼里有没有花？保证是十只？”
“没有花，就十只。”
老师脑门上的汗已经流下来了，下课铃响起，但男孩仍继续问:“有没有傻的不怕死的？”
“都怕死。”
“有没有因为情侣被打中，自己留下来的？”
“笨蛋，之前不是说都是公的嘛!”
“同志可不可以啊!”
“………，性取向都很正常!”
“会不会一枪打死两只？”
“不会。”
“一枪打死三只呢？”
“不会。”
“四只呢？”
“更不会!”
“五只呢？”
“绝对不会!!!”
“那六只总有可能吧？”
“除非你他妈的是猪生的才有可能!”
“…好吧，那么所有的鸟都可以自由活动么？”
“完全可以。”
“它们受到惊吓起飞时会不会惊慌失措而互相撞上？”
“不会，每只鸟都装有卫星导航系统，而且可以自动飞行。”
“恩，如果您的回答没有骗人，”学生满怀信心的回答，“打死的鸟要是挂在树上没掉下来，那么就剩一只，如果掉下来，就一只不剩。”
老师当即倒!
============================转载例子-结束======================================
这个笑话，不少人会认为小朋友是需求调研的最佳人选，而本文转载的文章也正是以这样出发点分析软件失败的因素正在于需求不明确，客户对需求的变更等等。笔者对于需求调研有深刻的理解，调研的目的就在于深入了解客户的业务和工作并收集资料，如小孩般打破砂锅的方式一定程度上是比较到位的调研方式，考虑到问题的方方面面，与客户确认各个具体可能性，这避免后期需求管理中客户更多的纠缠，同时又避免想当然的作法。在需求调研中，往往摘取片面的客户信息然后用技术的角度去考虑实现，想当然地认为应该是这样，却与客户实际或总体上客户需求并不协调。
如果把小朋友作为系统分析人员去做调研，可以定位为：把简单问题复杂化，但却是必要的，绝对是横看成岭了，绵延但可实现。如果把这个笑话中的小朋友看作是客户，客户无休止地对一个需求的各种可能进行扩大化提问，那么绝对是把侧看成峰了，太陡峭了，寒！下面是笔者亲历的与客户需求互动过程。
=========================自设例子-开始=========================================
需求确认环节，需求分析人员：对于角色这部分，你确信只要一种，并且具有所有权限就可以吗？
客户：也不清楚，系统能给我用来发短信就行。
分析人员：所有功能都给一种角色，没有其他角色的要求吗？如有些角色进来只能发送短信不能提取报表。
客户：这个目前还不知道，现在只要满足能发送短信就可以了！那到时候能不能让我自己设置角色并分配可操作功能的权限呢？
分析人员：可以啊！那你的需求就是建立可配置角色和权限！
客户：是，那能不能导入角色和权限啊？比如有一批用户现在要让他们用系统，我不想一个一个配，直接导入！
分析人员：可以，不过要按照我们设定格式来编写然后导入！
客户：那能不能导出你们格式，然后我按照格式输入？另外我想如果数据太多，尤其是如果分不同用户组别的，能不能把报表合并后再导入？
分析人员：你的意思不同组别的人把按照格式中名单给系统，系统能合并一起，然后再由你一次导入吗？
客户：是，我总不能一个组别导一次，另外以后要是修改的话，批量导入时也是一个组别导入一次不是很麻烦吗？
分析人员：这个？？可以吧，不过还是需要你把各组的报表导入我们才能合并，如果系统不能获取这些报表是很难合并的。
客户：系统应该会自己找吧？
分析人员：那这样，你在本地建一个独立文件夹，然后把报表都放进去，然后你只要给系统文件夹地址，系统就自动合并然后导入到系统中。
客户：可以，那么权限上能不能有些人给报表查询？有些人给报表提取呢？
分析人员：就是说有些角色可以进行报表查询，有些角色可以进行报表提取吗？
客户：是！
分析人员：那你配置这些角色就可以，系统中我们把报表提取和报表查询分为两种不同功能操作权限就可以了！
客户：要我配置角色啊！能不能固定这些角色，我给这个人这种角色就行了？
分析人员：可是你刚才的意思是角色可配置，如果这样，那么请你给出那些角色是要固定以及可操作的功能权限？
客户：我现在也不知道啊！就不能不用我配置就指定某人可不可以用这些功能吗？
分析人员：分配好角色后然后还可以修改具体个人权限，你指的是用我们内部预先固化好的角色，然后你可以修改个人权限而不用重新配置角色，对吗？
客户：应该是的！
分析人员：这个不好控制！因为角色是从属的，如果个人可以设置其权限，那角色就没意义了！直接为个人分配权限就可以！
客户：那就直接给个人分配权限！
分析人员：那还要支持导入吗？如果可以为个人修改权限，导入不具有意义，因为具体到个人了！
客户：还是要导入，如果用户多呢？
僵局中……，分析人员暗中哭泣！
=========================自设例子-结束=========================================
这段对话暴露中客户对需求的两个意向：减轻其工作，尽可能让软件来实现；需求带有想当然，认为这样就是能实现！这个例子此处的对话多少有笔者模拟意思，但当时情景的对话主要内容在这里是真实重现。客户一般对于其业务范围内的软件需求有种模糊的认识，刚开始一般都是朦胧，一旦软件分析人员害怕到时候需求变更而进行详细调研时，客户会越想越多，然后开始漫无目的地扩大需求，对软件的功能提出非软件本身或非该系统本身能实现或应当实现的范畴。
软件的需求首先就是要界定这一套软件的边界，就是这个系统能完成什么不能完成什么不去完成什么？无限制扩大软件的功能范畴对于软件需求管理是灾难性的。当前为了客户是上帝这样一个理念，软件越做越大，附带的软件小工具越来越庞大，也幸亏软件工程的推出，使得软件可以不断膨胀。
面对客户对需求的无限扩大化需求的趋势，该当如何为之呢？换到当前呼叫中心的软件开发和维护环境中，明显面临两方面的需求无限化问题：内部系统内部用户；呼叫中心整体方案外包用户。为了赢得客户，在不能对客户说“不”的前提下，去界定系统边界并做好需求管理，笔者确实头痛！对此，笔者认为软件分析人员应该有一下几个把握：
软件边界还是要定，并且与客户明确；
需求管理中，尽量引导客户去思考系统核心功能；
设计上，重点把握支持可能性需求变更的思路。
实际上，在与客户交流中，有些对软件熟悉一点的人经常会表达一种他提出的需求变更很容易实现的观点，这很可怕，对软件开发人员来说是毁灭性的！任何一个需求变更，都可能引起连锁性的修改甚至结构性的变动，但客户不会意识到这点。横看成岭侧成峰，用在此处最恰当了。因此笔者对于系统分析人员的需求管理能力非常看重，并着力于从开发到设计再到分析，到了分析阶段就要带着技术视角去思考同时又不能含技术成分去做需求，看似矛盾在实际软件需求分析中是很实在的。
2008年8月1日 星期五
扫一扫
1921
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
