您当前的位置:
随想之五--如何厘清业务需求
现在有很多工具帮助产品人员、开发人员收集、厘清业务需求；不论是传统的用户需求说明书方式，故事卡，用例图，还是IBM倡导的RUP等等。我的观点：工具可以更清晰的表达业务逻辑。但是清晰表达的前提是业务逻辑已经收集到了。从我参与的项目看，业务需求分析的阶段，很像挤牙膏。产品人员付出了很多繁琐的努力之后，总是还有漏下的牙膏；或者有些业务需求在没有真实业务需求的支撑之下反复地讨论；又或者针对某个需求，深入到数据结构层面进行'试图说服对方的活动'。林林总总的情况，有些是需求收集不到位，有些则是想象，有些则超出了需求分析的范畴。当然，我尊重所有人表达自己想法的意愿。
有时我就在想，如何才能厘清业务需求；极致的目标是‘增一分则肥，减一分则瘦’。这里我的追求只是当前的业务需求：假设有这样一个场景，我拿着一个不透明的盒子，请各个相关业务的用户代表代表他们的角色，描述他(她)们放入盒子的东西（输入）和期望得到的结果（输出）。我记录下这些描述；发现其中有很多包含业务意义的名词和动词、副词。然后将这些词汇交给用户代表们讨论，明确词汇的具体含义(内涵)，标记哪些词汇是对等的、哪些是相近的（记录差异），哪些词汇是对立的（作用是相反的）等等各种关系。从而获得了一个业务含义清晰的统一的词汇表。然后使用新的标准用语，代入业务描述，请用户代表确认，修订后的业务描述是否正确、业务需求是否完备？解决了这个问题，用户代表们就可以退场了。需求分析师们拿着自己的工作成果，进行自己后续的工作。
一个重要的误区：开发部门的需求分析人员逐一询问用户代表，获取业务需求。如果是这样，技术水平越高的需求分析师效果可能越差。当然需求分析师通过付出更多，从而得到更理想一些的成果。如果需求分析师对于业务需求的把握已经可以代替用户代表，我觉得要么是他的职位不对，要么是他的能力不对。
如何将软件开发中的各环节做得更好，如何更节约人力，是软件开发组织必须考虑的问题了；因为相比制造业，软件业的低人力成本会更快结束，而且失败项目的成本会越来越高。好的开始是成功的一半，做好软件开发的第一步。