直面需求问题的鸿沟

只要是软件企业,我就没见过有谁说自己在需求这块没有问题的。

作为软件的源头,需求做的好坏基本可以决定项目的成败。作为乙方的软件公司,不能要求客户们成为工程师一般的“专业人士”,便只能给自己寻到两条出路:

第一,便是固守“专业人士”的底线,照着自己的“专业路子”做,再想方设法“教育”客户。

第二,就是老实听话,让干啥干啥,让咋改咋改;反正需求注定要变,还不如消停一点,换个良好的客户满意度。

在我看来,这两种应对需求问题的思路,都是消极地破罐子破摔。客户和开发团队之间就像是三维空间中,两条不相交的平行线一般自说自话。除了不断增加返工、成本与各种“并发症”外,没啥实质性的益处。

20世纪末,人们提出了“需求工程”的概念,希望借助工程概念的方式,解决日益严重的需求的问题。

需求工程是指,应用已证实有效的技术、方法进行需求分析,确定客户需求,帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。——百度百科

需求工程的核心,是需求建模与技术。随着软件的不断发展,需求工程也不断地演化与发展:

需求工程配图1,Fancier凡奉信息

 

软件的巨大普适性,涉及到诸如行业、人员角色、文化、社会背景、商业目标、利益协商等越来越多的非技术因素。时至今日,需求工程的技术也已经不再是核心问题了。而那些非技术的、社会性的因素在需求中的占比却不断升高,上升为需求问题的主要矛盾了。

因为这些技术、非技术与社会性因素的影响,几乎不会有客户能够给出对软件要解决的问题的全面说明。而只能是部分的、片面的、片段的“只言片语”。而需求人员面对的挑战,便是将这些结合起来,分析、重组、还原成需求的全局。这便需要需求工程转而面向服务分析的发展原因。

软件是用来解决客户在现实世界中遇到的问题的系统。因此,对软件的认知不应该仅仅是软件本身,还应扩展至软件服务。外延的扩大,可以让需求工程的关注点从技术延伸至非技术因素与社会因素。将软件开发当成一个系统工程来处理,如此构建出的整体软件服务,才能切实应对现实世界中的问题;如此系统化的需求工程才能兼具全面性与正确性。

需求工程图片3.png

由此可见,想要解决现实中的问题,软件只是整个系统的一部分。在软件之外还有硬件工程与人力工程。因此,我们经常抱怨的那个需求,也不应该仅仅指软件需求,而应该是系统的,包含硬件工程与人力工程的需求。

这个范围的延伸,非常好的诠释了软件行业中的一种现象——售前阶段,项目组已经开始进行需求分析,撰写技术方案,提供报价依据。这时,我们做的需求,主要面向的是系统工程的需求。而签订合同后,进一步做的需求,则是面向软件工程的需求。(见下图)

需求工程图片1.png

目前需求工程的主要任务:

  • 明确系统目标和应用环境。说明软件系统的总体目标,以及达成这些目标的功能、上下文环境、实现方式和方法、限制和约束等。也就是要说明软件为什么需要,以及需要做什么。

  • 将现实映射到软件。将目标、功能、环境和约束等,“翻译”成软件的准确的规格说明。

  • 动态管理目标、功能、环境和约束。由于现实世界是一个动态变化的世界,因此需求工程需要综合的、动态的、平衡的管理目标、功能、环境和约束在软件生命周期中的演化和分布情况。

需求工程图片2.png

系统工程的需求是对应系统目标和应用环境的,是直接映射到现实问题的,需要动态的管理。软件工程的需求是仅仅针对软件本身的。

需求人员认为系统工程的需求应该全面而正确地来自于客户,自己只应该负责软件工程的需求。然而,客户在这方面,比需求工程师还外行。他们需要需求工程师站在系统工程的角度,借助软件,解决他们在现实世界中遇到的问题。这便是需求问题一直以来面对的鸿沟。

凡奉首页    管理实践    CMMI管理实践    直面需求问题的鸿沟
创建时间:2020-03-31 00:00
收藏