揭开需求的面纱

在前面的文章中,我们重点阐述了需求工程与软件开发的地位关系(下图),讨论了需求复杂性的原因,也给出了设计思维这样的小技巧。

需求工程、软件需求、系统需求

 

今天,我们聊聊需求本尊,看看咱们对这位“大神”到底了解多少。你觉得需求是个啥?

  • 技术人员通常的回答是:功能模块

  • 销售人员通常的回答是:客户愿意为什么买单,什么就是需求

  • 客户通常的回答是:我想要的

果然,好不一样啊!

既然软件是用来解决客户在现实世界中遇到的问题的系统。那么软件项目中的需求,便是解决客户在现实世界中遇到的问题。问题源自现实与理想的差距(百度百科)。

既然是理想,就很有可能是不明确的、不具体的、不完整的,甚至是不切实际的。我们在需求工作中,遇到客户说不清、变化甚至矛盾的,就说得通了。可是理解归理解,项目还是要最终交付的,成本和进度也是有限的。客户理想那么缥缈,那咱们现实的日子怎么过下去呢?

约翰·冯·诺依曼(John von Neumann)和奥斯卡·摩根斯坦(Oskar Morgenstern)在《博弈论》中写道:“There is no point in using exact methods where there is no clarityin the concepts and issues to which they are to be applied”。应用到需求问题上,可以概括为一句话——在弄清楚需求本身之前,啥方法都不好使!

这就很明确了,想要做好需求,必须弄清楚客户的问题与期望,详细梳理和分解需求。

Step 1,明确客户的问题    

现实世界的问题都有三个层面:

揭开软件需求的面纱-Fancier凡奉信息版权所有

决策层问题:决策者站在战略、全局的高度,提出的由具体问题引发的目标问题。

执行层问题:执行者在执行实际工作任务时,提出的具体问题。

环境问题:其他外部环境干系人对执行层与决策层问题的约束与影响。

比如决策者打算开发一个“类淘宝”的电商平台。除了在执行层面要实现商品展示、下单、支付、物流跟踪、进销存管理、会员管理、促销管理等具体操作外,还要受限于广告法对营销活动的约束,金融监管机构、金融合作机构对支付环节的约束等。这些约束会直接影响到平台具体操作的设定。

环境问题的存在,会直接作用于具体问题与目标问题。总的来说,现实世界的问题主要体现为执行层问题与决策层问题两种。

Step 2,明确客户的期望,细化分解出对应的需求    

需求是客户解决问题的期望。因此,对应问题的层面,需求也有两个层面:

揭开软件需求的面纱-Fancier凡奉信息版权所有.png

解决决策层问题的期望,是基于目标问题抽象出的决策者高层次的目标期望。它描述了需要软件系统的根本原因,以及决策者希望借助软件系统达到的目标与效益。这是我们通常所说的业务需求,来源于所有决策者,包括发起人、投资人、实际的管理者、相关部门等。

解决执行层问题的期望,是基于具体问题抽象出的实际执行用户对软件系统所能完成的具体任务期望——即软件系统能够帮助用户做些什么。这是我们通常所说的“用户需求”,来源于所有直接和间接使用软件系统的各类角色。

值得一提的是,还有一种不得不提的,叫“不切实际的期望”,可能是目标期望,也可能是任务期望。有两大类型:① 不可行(技术上无法实现、存在风险与隐患)、② 超出合同范围(预算、周期、产品与服务内容等)。

我们在《直面需求问题的鸿沟》一文中提到,需求工程包含系统需求开发与软件需求开发(上图)。系统需求可能发生在售前阶段,此时我们要识别出不可行的,在合同中加以规避。而售后阶段,“不切实际的期望”主要表现为超出合同范围这一类型。一旦发现,不要盲目答应或拒绝,而是应将问题分析清楚,上升至更高管理层进行决策。如果高层管理者出于战略考虑,答应了客户这种超范围的期望。那么,PM应该理所当然地变更项目计划,比如延长时间、增加资源、调整工作任务及其优先级、调整风险计划与应对措施等。

在弄清了客户面对的问题,及他们解决问题的期望后。为了将之解决,我们除了需要确定系统化的工程解决方案(包括人力工程、硬件工程与软件工程对应的人力需求、硬件需求与软件需求,即系统需求)之外,还需要确定实现系统化工程的方式(包括项目需求和过程需求)。

项目需求主要是对项目重要活动和目标的期望,包括了工作任务、进度计划、成本、资源等。比如开发一个大数据系统,成本50万内,5个人,3个月完成,100个功能模块;除了软件产品,还需要编写用户手册1份,为客户提供试运行前培训1天等。

而过程需求主要是对实现项目需求的软件开发过程的期望,包括所选用的生命周期模型、过程中产生的文档等。比如选用敏捷开发模式;先由PO召开策划会议,编写与沟通Product Backlog、估算工作量、确定Sprint Backlog、制定DoD;再进入Sprint开发;每日站会,更新与记录Sprint与Product的完成情况,记录和处理存在的问题与风险;最后评审与回顾满足DoD的产品,分享过程中的问题与经验,彼此学习,沉淀经验……

 

揭开软件需求的面纱-Fancier凡奉信息版权所有.png

需求结构图 - Fancier凡奉信息版权所有

 

我们将各种不同名目的需求,按照产生的原因与时间顺序,整理出了上面的需求结构图。纯软项目中,我们通常会将主要的关注点放在软件需求上。但是,这仅仅是“系统行为”中的一部分,距离客户的期望与问题都还很遥远。而给项目带来巨大麻烦的那些需求问题,其实主要源自上图中的其他部分,更贴近客户的期望与问题。

经过上述的分析,我们可以看出,软件需求是为了解决客户在现实世界中遇到的问题,满足客户对解决这个问题的期望,从而产生的对软件系统以及实现软件系统的要求。这与IEEE对软件需求的定义如出一辙:

  1. 用户解决问题或达到目标所需的条件或能力。

  2. 系统或系统组件为满足合同、标准、规范或其它正规文件所需具有的条件或能力。

只要你的项目不是很少人参与、很短周期、很简单。上述林林总总的需求,总要清晰地记录并传达给项目组的全体成员。因此IEEE对软件需求还有第三条定义“一种反映上述a)或b)所述条件或能力的文档说明”。

日后的工作中,大家可以对照上述方式,厘清客户的问题,梳理客户的期望,得出满足客户的、全面、完整且正确的需求。以此,指导项目的前期策划与后期执行,并在不断经历的项目中,提高应对不同类型需求的工作能力。

凡奉首页    管理实践    CMMI管理实践    揭开需求的面纱
创建时间:2020-05-20 00:00
收藏