高级质保经理：（1）如何有效地进行需求开发？（2）如何培养能有效胜任需求开发的人？（3）需求定义的产物：《需求规格说明书》，如何保证它的质量？（即同时满足客户与项目组的需求？）
备注：客户方认识到需求是软件工程源头性的工作，结合实际工作中的惨痛教训，公司提出对需求的相关活动进行改进，目标是首先确保项目组“做正确的事情”，然后才是“如何正确的做事情”。
感谢您的来信*，关于“需求及需求管理”实在是一个过于庞大的主题，这次的回答首先试图回答我们应该如何理解“需求”或“系统需求”。关于怎么做以及如何实施是相当关键的问题，但是只有首先理解了“做什么”，我们才能确保展开正确的行动。
本回答只是试图开启一扇窗户，关于如何培养相关的团队成员，工作与控制应该如何设定才能使得需求工作变得更加优秀，我们可以在其后的月刊中作为连载。
什么是本企业客户的真实需求？
对需求及其管理的一个重大的误解是我们以为企业内部的人员可能知道需求，但是需求只可能来源于外部，来源于客户，所以我们只能向一类人了解信息，即“客户及最终用户”。当我们去真心诚意的理解客户及最终用户的需求及需要时，我们就会发现对于客户及最终用户来说的需求与我们自己定义的需求大相径庭。
其实大多数的 IT 服务供应商都忽略了这样一个问题：即对接受 IT 产品及服务的典型客户及最终用户来说，接受服务的过程往往也是一次（重大）改革的过程。这样的例子层出不穷，对于每一个下决心实施 ERP 的企业来说，采购哪家的软件系统从来都不是重点，重点是谁能为我提供过程及管理改进。对于采购一整套自动化系统的公司来说，是否必须实施自动化是一次重大事件，并且可能直接与某个竞争战略挂钩；也许面对终端消费者的互联网企业并不那么认为，但是只要问一问已经习惯了在实体环境里购物的顾客如何彻底改变消费习惯——使之保证每一件商品都在网上购买，是多么困难的一件事情，我们就知道这必然也是一次变革的过程，是客户及最终用户重新认识自我的工作（或活动）及其背后价值的一次大胆尝试！
换句话说，客户到底是在购买一个系统，还是采购了一次改革？这样的问题回答直接将颠覆我们对于客户需求的认识，并且理解许多的需求及需求变更是从何而来，又为何组织不了也预见不了。这也意味着，我们可能并不十分清楚，对于自己的企业客户，什么才是他们的真实需求。
对需求及管理的难点
项目，是一件事情、一项独一无二的任务，也可理解为是在一定的时间和一定的预算内所要达到的预期目的。从定义中我们不难看出“项目”具有的最大特征就是“不确定性”，无论我们已经完成过多少次楼宇设计，下一次的楼宇设计对我们来说依然需要重头开始；同样的，无论我们曾经设计过多少款财务软件，为下一个客户提供的定制必定充满未知。目前绝大多数的IT工作皆以项目的形式出现，而对项目的各种管理，包括需求管理，本质上对就是对“不确定性”的管理。
只有重新认识了我们的客户及客户的需求，我们才能够去深入思考“在自己的工作中什么关键因素造成了最大的不确定性，同时这种不确定性对需求工作的麻烦也最大”这个问题。限于篇幅，这里只列出几个我们认为最重要的因素，供各位作为思考的起点：
产品及服务的根本价值
还有什么比这个问题更容易回答呢？MS Office 提供办公自动化，财务软件提供自动化的财务数据处理及信息流转，OA 带来办公信息的共享，诸如此类。但可惜这并不是事实，需求工程师们现在都已经知道，被调研者口中说出的需求并不一定是发起一次解决方案服务的根本动机，比如财务经理是口述财务软件应该做成什么样的人，但是财务报表的最终受益者却可能是公司的总经理或股东们，而他们却并不是操作系统的人，甚至他们都不接触系统，但是某个财务软件的发起又很有可能是一次股东大会上某个股东提出的一系列财务制度改革的重要组成部分。那么对这家公司来说，财务软件多么自动化的解决了繁琐的财务工作并不是服务的重点，重点是新的财务流程及相关制度。让我们来看看另一个案例：在同一市场竞争的两家物流公司都需要一套信息管理系统，并且90%的功能都几乎雷同，但是对于第一家物流公司，其背后真正的需要是通过一套信息系统真实改善企业经营流程，期望通过降低成本从而提高日益激烈的市场竞争力；而第二家公司则完全是为在第二年推出电子商务的需要做出考虑，他们需要整合服务信息从而率先在市场上独家推出基于互联网的电子商务（IT 服务），从而彻底改革公司的经营服务内容。对于第一家公司，他们实际采购的是一次运营管理改革，而对第二家公司他们根本是要采购一次公司战略改革。一次服务背后的价值大小，直接决定了此次服务中变更的可能性、发生的时间及其变更的内容重点，背后价值越大的，其变更的可能性就越大，但发生变更的时间点却恰恰较为靠前，原因是由于客户的重视，在整个服务过程中客户都会不断去思索和提出新的问题。但是变更的数量却并不是由这个关键点所控制的，无论是做一个有价值的系统还是做一个没有价值的系统，需求的变更数量都是差不多的，差别在于变更的内容。当系统的价值很大时，对于业务及非功能性的需求变更就显得较多（因为这些与最终的变革密切相关）。但若系统本身价值不大，则发生变更的部分就显得比较琐碎，包括界面的操作、数据的定义、一些支持性功能等等。
市场中的客户及最终用户对于服务的认识及成熟度
零售或制造商们现在都是十分理解一点，那就是一件商（产）品的成熟度越高，与顾客的沟通就越容易。今天，没有人会怀疑电话的作用，但若放在 50 年前，人们会怀疑既然我们已经拥有了那么便宜和方便的电报系统，人们为什么还要去花钱购买一台电话？快递业务一经推出就受到了市场的广泛质疑，当时的人们找不到任何理由去接受一个价格远远高于邮政服务的业务，但是事实证明所有嘲笑快递业务是哗众取宠的人自己却成了这个笑话的主题。同样的例子也发生在了惠普、IBM、埃森哲身上，总之事实证明在一个新生事物被普遍接受之前，不受待见属于常态而不是特例。IT服务是这样一个充满沟通与协作的过程，是一个共同创造的过程，作为需求的源头，客户及最终用户对于此事的理解直接决定了工作的效果与效率。但十分可惜，包括客户在内的绝大多数参与者都并不十分清楚最终的产出目标是什么，这就注定了越是重大的变革，就越是只有模糊的期望，而不是明确的目标。同时，客户及最终用户对于产品及服务的认识，也直接决定了变更的数量。一种产品及服务推出的时间越长，接受客户检验的机会越多，其功能就越稳定，其特征就越是可以被标准化，在目前 IT 的各个行业中，系统集成各行业所推出的解决方案标准化是最多的，这绝非偶然！
IT 专业人士对于客户业务的熟悉程度
截止到目前，只有在为某个特定领域服务超过 5-8 年的工程师和经理人才会对于 IT 专业人士给予认可，无论你是编写代码还是做测试，无论你是一位前线的销售人员，还是后台的实施人员，技术能力都只是工作的基础，业务知识才是工作的核心。如果客户对于产品及服务的熟悉程度决定了“表达”—— 信息的正确输出，那么IT供应商对于自己所提供服务的本质及客户业务的熟悉程度就决定了“理解” —— 信息的有效输入，同时也决定了对于无法被量化或标准化的抽象概念的控制程度。就像代码走查，最优秀的代码走查人员能够通过观察代码找出潜在的 BUG；同样，最优秀的 IT 专业人士，能通过观察各种中间产出物（无论是阅读代码、测试用例还是需求书）来找出潜在的业务缺陷（而不是技术BUG）。换言之，我们就掌握了一种能力，在工作的各个阶段我们都是边工作边验证，边摸索边前进。和上述两种客观造成需求变更的原因不同，供应商对于业务的理解程度较低会主观上直接造就变更，对客户隐藏着的需要的错误理解将直接产生虚假的变更。这些虚假的变更与真正的变更混淆在一起会造成与客户的沟通更加困难，并且往往得不到客户的认可。所以这些变更是真正的质量问题，是值得去努力提升并解决的重要研发问题。
上述一系列的问题只是开启了一扇窗户，看到了一些风景，市场、公司及人力资源等客观环境的不同会造就不同的对变更的影响，甚至许多是组合影响。理解这些内容实际上并不需要花费经理人过多的时间，但是只有组织上下真正理解了变更的原因，才有可能尝试去控制变更或正确应对变更。
虽然，造成麻烦的因素多种多样，但不同的企业并不是要针对所有的因素做出处理，也不可能解决所有的问题，那是不经济的。对于一家企业的某个阶段，导致严重问题的真正重要的因素往往不会超过3个。接下来的问题必然是我们需要做什么？
首当其冲的必然是明确企业的环境，并且列出本企业需求工作的不确定性特征。
其次，企业必须就变更的因素进行重要性分析，筛选出至多不超过3项关键因素。
接着，企业必须为这些因素分别确定一个重要特征——控制力。比如之前的第一项因素是企业根本无法控制的因素，价值只取决于客户及最终用户，供应商仅有选择客户的权利。一旦选择了市场及相关客户，就决定了企业必须坚定不移的满足客户的需求，所以控制力是最弱的；第二项因素中，虽然我们无法控制客户，但是至少我们能够循序渐进的影响客户，我们至少有机会“教育客户”，但是“教育客户”必然是一个长期的过程，而且十分依赖客户本身的能力和态度，所以对于企业，我们倾向于将其定义为一个较难控制的因素；第三项显然是我们可以通过努力去控制和改善的，我们对于第三因素具有较强的控制力。
再次，我们必须将这些因素放入项目管理中，针对不同的特征进行管理与控制。比如，对于完全无法控制的因素，我们所要做的是必须将其作为独立的决策项尽早发现与提出，越早理解这些内容我们就能将问题的损失控制的越小，反之对计划的变更所造成的影响也就越大且毫无讨价还价的余地。项目经理针对这样的因素，只能将其视为约束项考虑，即这是无可避免的，所要采取的策略也毋庸置疑，即我们必须在计划中留出空余来应对必然产生的变更；而对于需要经过长期不懈的努力才能解决的变更因素，我们必须采取完全不同的态度，敏捷方法论的提出恰恰是为了解决这个层面的问题，将产品交付的生命周期分割成小模块的最大好处就是可以尽早的发现变更与问题，并不断与客户产生沟通与理解。从而将变更的影响力控制在最小的范围内。
最后，诚如 IBM 的广告——我们提供的是随需应变的解决方案，如果我们意识到 IT 服务的本质就是应对变化，其工作的核心内容不是生产而是设计，那么我们就最终理解了诸如持续改进的意义所在了。对于生产性工作，我们是在工作内容稳定的假设上展开的工作；而对于设计性工作，恰恰是建立在工作内容未知的假设上展开的工作。面对这样的工作，我们能从什么地方获得灵感与借鉴呢？真正了解 ERP 或即时生产（或精益）历史的管理者会得到这样一个启示，这些管理方法和工具的产生的背景是这样一种环境，生产工作本身是相对稳定的，但是对于生产多少、采购多少、何时运送、投入资源等环节却是因市场环境变化而发生剧烈变化的。即时生产所要求的，恰恰是充分利用现有资源，在需要的时刻生产出适当数量的产品。这就要求：
a. 保证信息及沟通的畅通；
b. 保证各种资源渠道的畅通；
c. 保持一个从市场到最终服务的完整生命周期的计划链；
d. 同时这种计划链又必须十分灵活，易于调整；
e. 持续不断的改进自己的服务，以保证不要受到质量约束的影响。
对于我们，上述案例所给出的启发是从市场第一次接触一个客户开始就当作一个项目的起始，而不是等到合同的签署或签署前；即使是最特殊的市场，项目和项目之间也必定存在较大共性，持续不断的提取出这种共性，并且保持特性的灵活；树型的组织结构已经极大的妨碍了工作的灵活有效和即时工作，企业需要更灵活的组织结构以保持工作沟通的顺畅。
以上仅仅是窥视了需求及其管理的冰山一角，更谈不上十分系统的阐述了某种方法论，因为一成不变的方法是不存在的，解决方案必须在充分理解具体环境的基础上被制定出来。但是至少我们可以有了一个开始，真正了解需求，以及用严谨的态度去应对需求工作中的困难。
