需求管理系列一（概述）

概述

严格来讲，需求管理是一项需求工程。在现代互联网企业中，需求在整个项目周期中所占的比重是非常大的。需求的管控直接影响到整个项目的成败，许多项目的夭折往往是由于需求管控不到位带来的，需求的正确获取，需求的合理分析，需求所涉及的风险，需求的控制都可能是导致项目失败的脆弱环节。

为什么需求如此重要

  从来没有人告诉你需求是不重要的，这应该是互联网企业，尤其是软件外包企业的核心，需求才是源头，需求做不好，项目是没有意义的。严格地讲，我们做的不是项目，而是产品。专注产品本身会将其他影响决策的非必要因素排除。，一个有经验的项目经理或者产品经理，应当对产品概念了然于胸，对产品的描述应当简洁而又明朗，会正确的分解产品的周期，将产品的概念正确的传达给相关人，保证不出现理解的偏差。

  需求才是目的，在将需求实现出来的过程中，我们将需求分解为许多子需求。这些需求可能是从已经在设计完的产品中分解而来的，也可能是未来提出的。后者往往带来较大变动。只有需求出现之后，项目才可能进入下一阶段，我们这里不谈论技术问题，技术总是跟随需求的，从来没有不以需求为核心的技术，哪怕是以技术为需求的需求也是需求。因此需求总是如此重要，以至于它所占比重非常高。

需求的本质

  需求一词古已有之，古代匠人为帝王打造龙袍、为妃子打造凤冠，小到为平常百姓设计桌椅、建造房屋，处处透露着需求的存在，可以说，我们的社会就是需求驱动的社会。欲望亦是需求，社会不可能不存在需求。需求亦不可能一成不变，需求总是跟随环境的变化而变化的，因此若是认为需求是不变化的，抑或害怕需求变化带来的麻烦，那么你可能只适合出家了。

  抓住需求的本质，方能解决问题，我经常在家装设计中看到需求的变化，春夏秋冬各不相同，我们要求冬暖夏凉，要求采光充足，又要求保障足够的私密空间。这些需求都是在变化的，有些变化是环境所致，有些是内部驱使。我们需要搞清楚需求的本质，需求往往是由需求提出者提出的，他们可能是直接客户，可能是间接代理。无论是谁，需求总有人提出，我们应当搞清楚，我们是要满足需求者，还是满足需求本身。

  需求是有主体的，对于需求的实施者来说，这非常重要。需求是最终目的，它是需要被满足的，在这个过程中对于模式很强的需求，需求被包装成了产品出现。

• 教育产品解决知识获取需求
• 空调解决温度需求
• 汽车解决出行需求

• 纸张解决文化传播需求

    这些需求是集中的，因此人们将需求包装起来，打包成产品，开箱即用。

    但是有些产品不能做到模式化，他们的需求过于定制化，受众十分小，我们要区别对待两种情况。比如残疾人出行，你可以参照这些准则和经验来设计分析需求。

如何正确地获取需求

例子-附属需求

  这是一个看似简单，实则困难的题目。你会认为需求的获取简单在于只要需求提出者表达自己的诉求即可，但是事实并非如此。我们要为一个儿童设计一个椅子，方便他（她）写作业使用。这个诉求已经被提出，接下来设计者就要设计这个座椅，作为一个设计者而言，他了解到的诉求就是为儿童设计座椅，但是这仅仅是最核心的需求，需求往往有附属属性，我称之为需求附加属性，有时候这些附加属性是不必需的，有时候附加属性却是必须的。为儿童设计座椅这个需求需要设计者获取儿童身高，儿童坐下时候的膝盖高度，站起身时候头部在空间划过的痕迹（防止过高或过低撞到障碍物），这些诉求是需求的提出者不会提出或者忽视掉的，需求提出者本身不是设计者，他们往往关心的是核心去求，但是在使用需求的成果时，他们作为直接使用者往往会受制于环境和内心诉求来验证产品。

  假设这位设计师设计除了一个单人独坐的木椅，座椅高度十分合适，但是儿童长时间坐可能会导致臀部肌肉紧张而疲劳，尤其当儿童十分精瘦的情况下，这个问题就更突出了。因此可以认为对座椅的舒适要求是附属需求，但是由于需求者要求的是完成家庭作业使用，因此一开始他们的需求关注点往往在于有这个座椅即可，但是在使用过程中舒适的需求就显现出来了。这种例子还可以很多，随着儿童年龄增长，身高增长，这个座椅的高度已经不能满足需求。此时带来的直接效果就是需求变化。

需求变化

  但是这种需求变化是合理的，我们不能因为需求变化而恼怒，这是设计师无能的体现。一个有经验的设计师应当注意到这些需求变化。简言之，实现者应当对需求的提出者进行深入的了解，需求提出者往往不知如何正确表达自己的诉求，因此在这种情况下盲目开工，只会适得其反。

需求的传播-“谣言”

  我们需要注意的是，诉求是可以被传播的，这得益于文字的功劳，让我们可以传播想法，聆听诉求，因此一个诉求者的诉求可以被另一个诉求者提出，也可以被一个没有这个诉求的诉求者提出。对于前者而言并没有什么不妥，他们的诉求是相同的，但是后者就不同了，这是一个十分危险的信号，一个诉求正在被一个没有该诉求的人提出，这种时候我们已经脱离了真正的诉求者，这就意味着诉求变成了“谣言”，此时的诉求往往有失偏颇，这是不理智的诉求，它在传播过程中会导致诉求的扭曲，从而影响设计者判断，同时由于传播者没有这个诉求，因此不能“感同身受”地提出附属需求或者考虑到附属需求，他更加不会被设计师观察或者需问到有意义的附属需求，中途的沟通带来的需求谣言是很多的。因此，你需要面对真正的诉求者。

  “众包”这种软件外包方式是诉求获取的大敌，这种方式仅仅适用于具备需求模式的诉求，这些诉求具备一定的模式，这些模式可以被封装成产品，他们所满足的条件十分有限。因此出错可能性不大，但是同样的诉求，在不同的环境中附属需求会发生变化。如果你将订单查询模块众包出去，并且你认为你的诉求仅仅是对订单查询，你可以交给别人完成这个诉求，但是如果你没有考虑到附属需求的话，那么改诉求很可能在不同环境下不被满足，比如高并发。

需求蔓延-需求彩蛋

  需求是可以蔓延的，这是由于对附属属性沟通不善导致，就上述儿童座椅例子来讲，诉求者是儿童监护人，在一定程度上是可以提出正确的诉求。但是由于使用者是儿童，因此会面临长高的问题，此时座椅便不再适用。因此的需求就多了一条，可增长式设计。由于儿童作业繁忙，使用座椅时间较长，由于你设计的座椅没有靠背，导致儿童脊柱受到挤压变形，你的责任可就大了。因此这个蔓延开来的诉求就是，需要合适角度的靠背，并且你受到第一条蔓延诉求的启发，你设计的靠背的角度还应当是可以调整的。

  由这个例子可以发现，诉求的提出往往掩藏了很多“彩蛋”，之所以称为彩蛋，是由于诉求彩蛋往往在最后才能被发现，因为在被验收的时候诉求者才能有所“顿悟”。这需要经验的积累才能保证你的需求不被蔓延，更安全地讲，保证绝大部分诉求以及可能出现的诉求蔓延，都被你预料到了，如何做到这些“彩蛋”的挖掘呢，你不可能预料到所有的诉求蔓延，诉求蔓延一个根本性的问题就是获取者没有站在诉求者角度考虑问题，无法洞察诉求者的属性和所处环境，因为需求的提出是环境和自身决定的。只有对诉求者进行了深入的了解，才能明白诉求者为何如此诉求。只有你懂诉求者，你才能发觉蔓延诉求，也就在一定成都上避免了诉求变更问题。

  诉求蔓延问题的处理还应当采取效率的方式，当一个产品或者项目经理经验不足时，往往无法很好做到第一点，此时取猜测或者理解诉求者往往不够效率，与其取猜测还有可能出现的情况，还不如排除掉不需要的诉求。明确对诉求者提出哪些是他们不需要的诉求。

  一个简单的案例，当你在诉求者口中得知，这个系统要有一个登录功能时，你不应当草率的去设计，包括UI和数据库，甚至业务设计。因为此时你并不能排除诉求者是否需要auth2授权，若是需要，那么你的数据库设计可能要更改，这直接导致你的业务变化。然后你恼怒的埋怨诉求者不不明确提出这个诉求，我们说过，诉求者并不能很好的提出诉求，有些彩蛋是需要我们来挖掘的，若是诉求者明白这一切，那还需要你做什么呢？因此你可以明确在这里询问诉求者来进行排除，当你挖掘到了auth2的彩蛋时候，你还应当排除哪些厂商的auth2接入是不需要的。因此，学会设立需求黑名单，把不需要的诉求排除进去。把正确的，明确的诉求放进白名单中。

需求池

  当你学会把需求划分黑白名单的时候，你已经做到了需求池了，在你的白名单中，你已经捕捉到了正确的诉求，这些诉求列表组成了诉求者的所有诉求，至少是正确的大多数诉求。你要做的就是从这个需求池中把诉求完成移动到已经完成的需求池中。

诉求的整理-子系统的划分

  在需求池中存在的是杂乱无章的诉求列表，这些列表之间存在很多复杂的关系，他们可能依赖了其他诉求。被依赖的诉求未处理，你可能无法处理来一个诉求。同时这些诉求应当是被划分成模块或者子系统的，这在一定程度上将系统业务的耦合分离，在诉求名单中需要做到的就是划分模块或者子系统。人类处理信息的能力是有限的，只有将资料的分类做好之后，我们才能将一团乱麻梳理成一根简单的麻绳。在子系统划分完毕后，我们才可以对系统的实现进行迭代，版本的划分，产品开发的迭代周期在此显现。而如何在迭代中选择哪一个子系统，则是需求优先级的范畴了。

需求的优先级

  在将诉求进行整理后，我们划分多个阶段进行迭代，需要注意的是，迭代的版本尽量是可以独立发布和测试的，这便于诉求的更改和调整。及时有效的迭代能够将诉求的变化最大范围适配。但是如何选择子系统或者诉求来作为哪一个阶段的迭代变得扑朔迷离，此时依然不能脱离诉求者，诉求是诉求者提出的，诉求者才有资格进行诉求的先后体验。实际上诉求者依然是受制于环境的，但是如果你强行违背诉求者意愿，那么你实现的诉求已经失去意义。你可能得不到酬劳，也可能遭到诉求者埋怨，可能影响的是你作为设计师或者架构师的名声，最糟糕的情况就是给你所在的企业带来负面影响。你们可能从此失去一部分客户。口碑的力量往往是裂变式的，诉求者所在行业的社交辐射可能是你无法想象的，因此当你无法满足或者不想满足诉求者的诉求的时候也应当是友好的，有引导性的。你的专业素养可能会让你作出比诉求者提出的诉求更为优越的方案，并且确实能为诉求者带来利益，此时你应当引导诉求者，如果你真正站在诉求者角度思考问题，那么诉求者一定会听你的意见。很少有人能够做到这一点，哪怕诉求者无话可说，但他们依然是持保留意见的，很多经理人无法理解这一点，其实很简单，你还是没有站在诉求者角度思考诉求。

  这里并不考虑诉求者本身的局限，或者错误，实际上诉求者是没有错误的，错误的是你没有挖掘和引导好你的诉求者。如果诉求者本身没有想清楚诉求，作为专业的咨询或者企业，你应当及时制止诉求者的诉求，停下来与诉求者讨论一个最根本的问题，诉求者需要什么，找到这个诉求需要什么样的边界条件和资源，诚然，这些能力综合能力和经验要求非常高，如果你们公司做不到这一点，可能你们公司需要招聘这样一个人才。他能为你们企业省下不少钱的同时带来更高的效率和收益。

结语

  实践是检验真理的唯一标准，当问题已经在行业内普遍凸显的时候，整理成理论是行业走向成熟的标志之一。若是能标准化自然最好，但是到今天为止，在互联网行业还没有普遍统一的需求标准，人是最不可预知和最大的变化因素，当一个活动严重依赖于人的时候，标准化就越困难，实施也越困难，因此你还需要一定的变通能力。

未完待续…