需求“沙漏”的实践：产品线需求Vs具体项目需求

名易软件产品

当前位置：首页>管理咨询>需求“沙漏”的实践：产品线需求Vs具体项目需求查询：

需求“沙漏”的实践：产品线需求Vs具体项目需求

沙漏之喻　　软件工程——其实是人们希望从工程领域中学习经验、借鉴理论来帮助解决在复杂系统和软件开发中遇到的问题。然而，随着软件工程的实践，越来越多的人认识到软件的生产和造桥铺路等工程项目的最大不同就是在于开发过程中人的灵活性和创造性。现在软件工程的发展趋势也重视和体现到这一点，既需要包含和鼓励个体的灵活和创造，但同时也希望从工程的角度对活动进行规范，对创造的过程和结果进行很好的保存和展现。产品项目研发中的需求活动贯穿整个生命周期，前期的市场部门的灵活沟通，广泛收集的活动到后期研发团队紧扣需求、巧妙分析、严格设计的过程不仅反映了工程的力量，也体现了“艺术”的技巧。但如何将客户的凌乱的需求和最后的严谨的解决方案联系起来，如何将人的活动和工程的工作平衡起来，如何在更高的层次分析和分配需求都是系统工程的重点，也是实际工作的难点。　上大学时非常喜欢哲学课，它能一个简单的问题通过辩证复杂化，可把一个复杂的问题通过统一简单化。这篇文章无意哗众取宠地追求哲学上的高度，只是想通过以沙漏为模型，以需求为主线，除去细枝末节，更深刻地来认识此间的概念和问题。随着讨论的展开，我们可以看到需求活动的沙漏之喻是如何帮助解答实际工作中的困惑和问题。　　　　从“问题”到“答案”　　沙漏是一种古代的计时工具，以它的式样来刻画需求的过程显得非常恰当。图1中沙漏的上端对应需求捕获的过程，沙漏的下面是需求开发找到答案的过程。在需求捕获的过程中，我们需要尽可能的扩展我们的思路，争取能收集所有可能对最后系统或产品产生影响的信息。然而，当沙漏的口开得很大的时候，收集的信息是高度分散的、凌乱的和非结构化的，有些需要还可能是互相矛盾和冲突的。因此，我们需要沙漏的筛选：对要求解决的问题进行梳理，对系统的范围做出决定，选择那些合适的，现实的需求，需求就得到了精炼。这时候问题陈述就是对系统要解决问题的陈述，而不是所有问题的陈述。通过这样一个漏斗的过程，漏下来的需求就是我们系统要满足的需求，这个时候的需求是一个正式的结构化的信息以交付给开发团队。在这个基础上，就可以设计解决方案。　怎么来做需求精炼和筛选，下文会有更详细地讨论。在这里，我想要谈的是区分问题领域和解决方案领域，这也是JeremyDick给我们的忠告之一。经常遇到这样的情形，客户抱怨花了钱没有得到有用的产品，而开发团队也会觉得很郁闷因为拥有这么多而好的功能的系统客户却不懂得“欣赏”，不愿接受。有用和既多且好的功能，这看似统一的表述在这里却成了矛盾。什么对客户来说是有用的？其实很简单，能帮助他解决问题是有用的。而那些拥有很多强大功能的系统和产品如果做不到这一点，矛盾就不可避免。很多团队负责需求收集的人员有着很强的技术背景，习惯将思考的出发点放在系统应该有什么样的功能，怎么实现这些功能。也就是说，他们往往在没有深入理解客户问题的情况下直接进入解决方案，而不是首先定义独立于解决方案的全面而真实需求集合。　那么，如何有效地区分问题领域和解决方案领域呢？其实，从需求的原始陈述开始，到最后的系统实现，整个过程是连续的：体现了从问题到解决方案的持续演化；同时也是离散的，各个阶段的需求信息之间应有明显的差异。最关键的区分在涉众需求和系统需求之间。涉众需求描述相关涉众、用户的想要解决的问题，期望达到的效果；而系统功能需求则是刻画为了要解决提出的问题，相关的产品和系统应该具有怎样的功能。通过下表的对比，我们可以清楚地看到两者之间的差别，特别是在最后一项，两者在文字描述的差异上更显示出立足点的不同。　由此可知，我们只有在充分理解用户想解决的问题的基础上，才能正确地分析出系统应该提供哪些功能。首先，研发团队一定要注意对涉众真实需求的收集和理解。更进一步看，在涉众需求的收集和定义阶段，风险主要存在于定义了错误的需要解决的问题；相对去后续阶段的设计而言，在定义系统需求阶段，系统工程师应该只是抽象地描述解决方案，这个阶段的风险存在于不必要地带入过多地设计约束，影响详细方案的可能选择。　可能有读者会抱怨或怀疑这个思想是不是太理想了:用户常常就告诉开发团队他关于解决方案的设计和想法，这时候怎么办？这就更要求我们的需求捕获人员有清晰的思路，首先，“用户可能自己也不知道自己需要什么”，这是常常发生的事情，我们需要适当地提出“为什么”来引导客户；其次，假定客户知道自己想要的，那么客户提出关于实现的想法也反映了他的潜在目标，也就成为了我们设计时的约束。　市场和研发的平衡　　在很多上了一定规模的公司中，有两个团队是一定存在且非常重要的：市场部和研发部。市场团队主要和“人”打交道，进行市场的调研和需求的获取，这处在图2中沙漏的上半部分。在沙漏的下半部分是工程领域，也就是开发队伍工作的领域。对开发人员来说，他们很少有机会真正地面对客户，他们工作的基础就是需求。对一个项目或产品的成功，这两个团队必须紧密合作，扮演好自己的角色。一旦此间的平衡被打破，团队就会遇到麻烦。很多公司里市场部门“坐大”，为了赢得客户的定单，或不深入理解客户的要求，或是直接“指示”研发部门按照自己对系统实现的理解进行开发。这都违反了上文中提及的需求捕获的关键原则。当另一方面，我也遇到这样一些公司，它们是由研发起家，整个研发部门在公司中占有比较多的“话语权”。会有这样的开发经理或人员，可能是出于追求技术领先或完美的热情，在满足用户需求的同时，也会增加设计实现其他“多余”的功能点。这些功能点其实是“无源之水”，并没有实际的市场和用户需求与之相对应。　需求将市场部和研发部紧密地联系起来，让两者之间的有效连接并维护平衡的角色就是团队中的需求专家。市场部和直接的用户，以及相关系统的投资方、监管方、维护方等等进行交流，我们不能保证他们能够提供准确的清晰的需求描述，因为他们只是在提出他们的问题和对结果的期望，而且要求我们的客户去学习什么是好的需求和如何提需求是不现实的。现实的是团队中有这么一些人，熟悉领域且受到过需求管理方面的指导和培训，他们知道应该怎么去收集、分析和总结需求。例如在西门子，负责捕获客户需求的工作主要由市场部人员去做，但并不是直接将这些需求转给开发部。有一个需求管理小组，隶属于研发中心，主要职责则相当于市场部和开发部的一个接口。需求工程师对从市场部那里获取的零散和庞大的需求文档进行整理和分类，然后提交给开发部。开发人员不需要和市场部争论哪些事情做得到还是做不到，而是由需求工程师来做。（具体参见《探索需求管理的三步曲》——《程序员》2005年9月刊）这是一个很好的做法，需求工程师可以是一个职位，也可以是一个角色。单独的职位可能在小的团队中不太实际，但拥有这个角色的人自己必须很清楚自己的位置：是处在市场和研发中间，需要维护好平衡，做好接口的工作。　产品线需求vs具体项目需求　　研发团队的项目性质很大程度上决定了需求管理做到的深度和广度。有项目经理问，我的项目周期常常只有几个月半年的，还需要做需求管理吗？诚然，若是一些没有专注业务领域的团队，他们项目的时间短，而且没有类似的后续项目，可以不必在需求管理上面投入太多的资源。而另一方面，如果这个项目是一个产品发展的某一个阶段，我们就要重新审视这个问题。就如一个做打印机的日本公司在上海的研发团队，他们的项目周期也是半年左右，但是一个基本型号的打印机已经有二十年的历史。也就是说，现在的这款打印机是一个个小的项目的开发成果的累计。这时，该开发团队就需要很好的需求管理，而且需求管理已经不再局限在某个项目里。　市场的激烈竞争，企业自身的发展，我们看到一个产品的需求往往会非常多。如果全部实现，那将是一个“完美”的结果。时间和资源的现实面前，决策层需要进行选择：既要快速地将产品发布面世，同时新的版本中也需要有足够地引起客户购买欲望的需求实现。　这里需要决策。孙子兵法中的“胜兵，先胜而后求战；败兵，先战而后求胜”早就阐述类似的道理：打胜仗的部队是在有胜算时之后才投入战斗，打败仗的部队先投入战斗，才寻求胜利的条件。需求工作的重要性是老生常谈的事情了，不是本文的重点。我们关注的是如何做出正确的决策而占得先机。　沙漏的上半部分强调的是在产品和项目的规划阶段，我们需要将做出正确的决策以满足现在市场的需要。这体现在收集和记录正确的需求；对需求的重要程度做出准确的刻画；基于成本和效益来规划产品的路线图，将需求的实现分配到各个的项目中。在需求明确的前提，项目经理就可以带领他的团队开展工作，这个阶段的重点就是如何保证需求在每一个研发的每个阶段都得到严格的满足和测试，而切实保证需求驱动开发和保证需求驱动测试，是研发团队将事情做正确的关键。　决策的重要基础是对需求的重要程度进行排序。但排序的基准在哪里，且基准也会随着个人的角度和时间的推移而变化？如果读者参与产品和系统规划的工作，尝试着回答下面的问题：所有来自A地区客户的紧急程度为高的且估算工作量在180个人天以下的所有需求有哪些？他们现在的项目状态如何？这是一个问题的简单样本，问题的实质在于决策者可能需要从多个角度去分析需求，并需要在众多需求中找出最重要的或者是当前最感兴趣的需求的子集。在没有方法的指导和工具的支持下，这个工作在竞争越来越激烈的现在是越来越难了，因为决策者往往面对多个产品，多个市场，多个竞争对手，当然还有时间和成本的压力。　　　“沙漏”的具体实践　　沙漏虽然是个比喻，但实际上有很多公司都在实践这种思路。以Telelogic公司开发DOORS这个产品为例，该产品的信息架构也呈沙漏的形状（为了展现的方便，图4为一个卧倒的沙漏）。在沙漏的前半部分，需求的来源主要分三大块：客户反馈（CustomerFeedback）、市场行销部门反馈（SalesandMarketingFeedback）和竞争对手分析（CompetitiveAnalysis）。基于这些原始的需求信息，产品部门总结出DOORS产品的用户需求，而后是分析得到功能规格来满足用户的需求，再分模块去详细设计。　重点解释一下在离散的原始需求和正式的用户需求之间所发生的整合的动作。正如上文提及的，我们不能期望客户的反馈是清晰的，是结构化的，但提交给开发部门的需求必须是清晰的、准确的、抽象的和可测试的。整合的动作就是进行信息的梳理和转换。　重要的是，开发部门使用工具将整合的过程和思路记录下来。常常在一个项目中听到这样的抱怨：客户（甲方）说不清楚原来提出的需求有没有在开发中得到体现，或者是直到见到产品了，才能确定需求是否体现，体现在哪里；而开发团队（乙方）会抱怨客户总是到项目后端变来变去，但能和客户“讨价还价”的依据又太少。在沙漏的模型中，最初的需求文档可以是图4中列出的，更可以是其他的贴近客户和市场的记录形式，如Email，会议记录等等。整合的过程中，我们需要将用户需求中的某条需求将和上游的来源文档中的需求描述部分联系起来，如利用工具建立类似超链接的link。这样对于需求来源方（客户和市场部）可以清楚地知道自己的要求在正式的需求文档中是否有提及，如何被描述；而对于开发人员来说，也知道这条需求的提出者是谁，原始的描述图4：一个“沙漏”的示例是如何的，方便地进行评审和确认。　整合还将帮助发现重复的需求：可能一个需求被多方提出，但归结到用户需求中只有一条需求，但该条需求对应关联到多个最初的需求来源。但这条需求得到满足的时候，多个涉众都应该能够通过关联知晓自己的需求被满足。此外，整合的意义还在于发现冲突的需求，这时候就需要产品部门决策和平衡，必要时通知相关人员并做出解释。沙漏中流淌的是细沙，而我们面对是需求。细沙漏过后直接就沉入瓶底了，但经过整合后的需求才刚刚开始它的演化之路，用户需求将被系统功能所对应满足，系统进而被分解成模块，同时测试的工作也将展开。这些信息之间的关联就是反映了需求在沙漏的下半部分被分解和验证的过程。这样，层层的关联可以让我们从沙漏的前方知晓后方的研发进度和状态同时，也可以为沙漏的后半部分中研发任务追溯到需求的源泉。