《需求管理》系列之一需求捕获

小老虎菲菲 · 发表于 2007-7-23 10:42:05

《需求管理》系列之一需求捕获
之所以用捕获这个词，而不是获取、获得一类词汇，仅仅是想说明需求不是信手拈来的、它是跳动的、不稳定的，你必须下点功夫才可能有所收获
主要方式
圆桌会议
最常见、最普通的需求获取方式，就是需求人员与用户（代表）坐下来就某个（业务）主题展开培训或讨论，用户称述、需求人员提问的方式，这种方式通常能获得业务问题的基本流程等整体感性认识，但要形成明确的需求陈述，一、两次是远远不够的；
其优点是快速切入主题，使需求人员对用户业务有粗粒度的整体性认识
这种方式的另一种常见场景是：需求人员对于当前业务已形成一定程度的认知、但仍存在一些不确定或不理解的业务问题，此时主要是需求分析人员提问、用户回答的方式，这种互动的过程中，很多情况下都会出现新的业务问题或引出用户潜在需求（这种需求用户没有直接称述或指出），这个过程是需求分析前期的重要过程，是需求不断深入、不断细化、不断明朗的过程
个人认为，必须通过这种方式解决需求前期的如下问题
用户当前是否已使用或正在使用其他MIS系统
是：
当前系统的使用状况如何，解决了哪些业务问题；还有哪些业务问题没解决；当初，引入旧系统的出发点是什么；现在，要引入新系统，最急切要解决的业务问题是什么（出现了旧系统不能胜任的新业务需求、产生了需求变更，但是在原系统上修改又无法满足等等、旧系统数据吞吐量不足、旧系统可能是C/S的想要迁移到B/S上以适应异地办公的需要，等等）？
在需求前期可以利用旧系统挖掘用户需求，保留其合理的部分，如有可能，可以构造出系统原型
要充分利用旧系统所包含的业务信息和业务数据处理流程；根据实际情况同用户确认
否：
企图引入（新）信息系统实现什么或者要达成什么目标？
大部分公司告诉你他们想信息化、提高生产效率、降低生产成本，诸如此类；个人认为，这个和没问这个问题的效果是一样的；大多数需求人员也知道他们不可能从这个问题得到什么实惠的东西
因为这个问题所涵盖的内容相当泛，很多时候，这个问题都被有意或无意的被忽略了，但这是一个必须面对且需要明确陈述的问题，最好能够有定量的描述（数据才是最客观的），比如，想降低库房管理成本30％（哪些库房业务会产生库房成本，如何改进（或仅仅通过信息化）这些业务来降低管理成本；系统实施后，如何跟踪库房管理以测量系统是否真的达到了预期的30％，表面看来，这是一个很难回答的问题，其实，系统还是有办法尽量靠近这个目标的，比如定期预警、设定最低库存等等）；确保每月资金回笼率达到85％（如何才能达成，有哪些相关业务去支撑），这是自然而然可以想到的；这一部分的任务是很难完成的，需要用户的密切配合和大力支持
但这一部分是很关键的，它是目标系统愿景的主要组成成分
用户管理层的参与
能取得用户的主动参与自然是相当好的事情，事实上，这比较困难；退而求其次，锁定几个关键用户，这几个关键用户必须对所在领域（比如采购、销售）的业务流程相当清楚并有可能协助BPR（业务流程再造），如有可能，可以通过msn、qq类似IM工具和他们建立realtime联系，提高需求沟通效率
业务资料搜集
用户业务资料，最主要的是各种
日常业务单据（牵涉到业务流程）
报表
因为各种业务处理最终通过这些纸质媒体上的数据反应出来，整理、归类、分析这些单据、报表可以找出数据源头（映射到系统的原始数据录入）、流转、存档及分析、提取等，资料上面的公式、表达式等直观反应了现实的业务规则。
这个是任何一个需求团队都不能避开的步骤。
将搜集到的用户需求不断分析、比较才可能发现问题；因此这是需求细化的一个前提条件
如果用户有遗留系统，分析现有遗留系统的业务功能也能对目标系统提供帮助，理清用户当前业务逻辑
头脑风暴
这里借用一下brains storm，简单的说，就是需求人员充分发挥主观能动性、各抒己见、甚至异想天开对于业务问题给出自己的认知和解决方案，如果有对该行业业务熟悉的同事参加更好，这样大家在一起讨论的效率会更高，否则极有可能出现“公说公有理、婆说婆有理”的僵持局面，这种情况下，头脑风暴的主持人必须作出仲裁，结束争端。
这种方式在需求人员对于行业业务缺乏认识或者认识较少的时候充分发挥团队成员想象力、利用集体智慧和常识、逻辑构造出一个业务问题模型和解决方案模型，这种模型具有很大的主观性，在对行业的真实需求逐渐明朗的过程中，往往可能要将以前的假想全部否定（这是一件极其痛苦的事情），而且真实的业务问题比构想出来的业务问题要复杂的多；但是这种方式在早期对行业需求缺乏认知的时候能积极推动需求工作向前进行，同时通过对比也能让需求人员对需求过程的理解获得更深入的认知，一定程度的采用是不无裨益的。
辅助方式
文卷调查
草拟用户可能关注的目标系统特性、业务问题解决方案等
个别访谈
就某一具体业务问题刨根究底的明确
需求导出
用户很多时候很难表达出他想要什么，一旦你把软件交付给他使用时，他会说：“我们，这里不是这样处理的”、“还有一种情况，你们的系统不能够支持啊”等等；其实，这种现状反应的是系统需求的不完整性，这种不完整性有用户本身的原因，也有需求分析人员不可逃脱的责任，如何尽可能降低这种需求不完整性（因为这种情况是不能杜绝的），要从两个方面入手：
需求分析人员：
需求人员的责任就是从用户那里取得需求并表达、组织，因此需求人员要尽一切可能从用户那里获得完整认识，要获得相对完整的认识，如下的工作必须做到位
1、分析各需求之间的关系，有制约、依赖、关联等
2、构造业务流程图，仔细分析每个可能的业务路径，每个业务路径触发条件是什么，如何处理，需要哪些前置条件，其结果是什么，对其他需求有何影响
3、开发需求导出工具或系统原型
以当前流行的B/S架构，可以用html生成简单的业务demo，简单的表达目标系统可能的“模样”，对于现时业务的处理方式，UI等等
用户更多的喜欢这种直观明了的方式，也更易于帮助他们清理出“藏在他们心底的”需求