svn中项目管理中ec_项目管理中的需求管理

在项目管理中，项目正式实施以前的工作是非常重要的，却很容易被人忽视。很多人都觉得只要项目开始实施了，就能通过所谓的“项目管理”一步步走向胜利的终点。这样的想法最符合“欲速则不达”这句话，因为没有做好正式实施以前的各项工作，而导致实施后要付出数倍的努力来修正项目，这样的辛苦是得不偿失的。

而项目正式实施前的工作有两步非常重要的环节，第一步是项目范围管理，第二步是项目策划。其中项目范围管理通俗的说法就是项目需求管理，即收集、识别、整理出项目的各方面需求信息，然后整个项目的终极目标就是为了满足这一套需求信息。如果连需求信息都无法找准，后续的各项工作都可能南辕北辙，根本无法高效实现项目的目标。下图就是项目管理中最经典的教学图片，需求方需求一个简单的秋千，却在项目过程中被理解出十余种状态，我们相信其中每一种理解都付出了认真的努力，可是都成了白辛苦，需求方的需求并未被满足。可见项目需求管理何其重要。

有人会说，项目需求管理确实重要，但现实中的项目需求不是一道数学题或者几何题，能够直观准确的给出对应参数和尺寸。在现实中的项目初期，连需求方自己都不知道自己的需求是什么，项目团队又怎么可能收集到准确需求，并瞄准需求方需求来开展项目呢？这种观点看似是一种合情合理的悖论，实际仍是对项目需求的不尊重，想以此简化或逃避项目需求管理。如果需求方一开始就能详细描述自己需求的所有指标，那需求方就已经是这方面专家了，可以自己完成的项目，又何必再找外部项目团队？就好比一对新人找婚庆公司，要求举办一场浪漫的婚礼，婚庆公司却要求新人提供“浪漫”的标准，这样的婚庆公司是否会贻笑大方？

越是复杂和未知的项目，越要重视和做好项目需求管理。我认为应该通过以下几方面来提高项目需求管理的质量。

第一，主动对需求方需求进行复述性解读。当需求方提出需求以后，项目团队应主动将收到的需求内容按自己的理解解读出来。信息的传递分为编码和译码两大部分，当需求方按他们的习惯完成编码，而项目团队按自己的规则完成译码时，双方都很容易想当然认为自己已经正确完成编码/译码工作了。但由于习惯和规则的不同，不能以想当然的方式认为“我已经说清楚了”或者“我已经理解清楚了”，只有再反过来进行一次项目团队的编码和需求方的译码，依然能够达成共识时，才说明需求被真的理解了。所以收到需求方需求时的主动复述解读，能够显著增加信息传达的准确度，有助于需求被真正理解。

第二，以标准化的图表或模板来规范需求提出的形式。作为专业从事某类项目的团队，必然在这一领域具有更加精通的造诣。这样的团队能够以最精确的框架来确定哪些信息足以说清楚一项需求。以做PCB板为例，设计方的电路图除了功能符合设计原理以外，还有使用温度、PCB板材质、镀层等要求，但设计方并不像制板方一样可以用专业术语直接表述出这些需求。这时专业的制板方通常会提供一张空白需求表单，让设计方直接勾选各类需求。当设计方看到表单中的选项时，立刻就明白自己的需求对应的选项，即使不主动描述，也可以通过选择来让制板方清楚自己的需求，而且通常不会遗漏关键信息。如果项目团队能够提供这样的标准化表单，是可以大幅降低沟通需求所需的时间，提高沟通效率。

第三，用专业的意见引导需求方发掘其内心尚不明确的需求。需求方在项目初期经常也不知道自己的全部需求，而是以摸着石头过河的心态与项目团队沟通。这种不明确的需求让项目团队无法捕获真实需求，即使逼迫需求方也无法提高准确度。这时项目团队应给与需求方有效引导，帮助需求方找到自己的真实需求。依然以上面的“浪漫”需求为例，当婚庆公司收到“浪漫”这个不明确需求时，可以主动提供给新人具有浪漫效果的建议，比如一段记录二人感情之路的VCR，又比如现场的布景建议等。让新人心中感到“浪漫”的效果，自然就将“浪漫”这个需求具体到了某几个动作上。这样既体现了婚庆公司的专业能力，又满足了一对新人的浪漫需求。现实中很多需求都是这样引导而确定的，专业的项目团队就该给出需求方专业的引导。

第四，整理后的需求要和需求方反复确认并签署定稿。当双方的需求收集沟通已经完成，项目团队应将获取的所有需求完整表示出来，请需求方确认清楚并签署定稿。时间的推移和环境的改变会影响每个人的思考，所以需求方方的需求也可能因为想法的改变而发生变化。如果项目已经开始实施，需求方的需求却不断更新，项目团队是难以按计划完成项目的。在项目管理中这种变化称为“项目范围蔓延”。如果任由项目范围蔓延，轻则付出更多劳动和成本完成项目，重则使项目永远无法完成。所以项目需求管理必须结束于项目需求定稿，在没有变更流程作为前提时，项目需求是不能随意改变的。这是双方互相的一种承诺关系，是项目管理必须坚持的原则。

优秀的项目需求管理，能够使项目实施工作更加简单、可控，真正实现既满足需求方的根本需求，又提高项目执行效率。如果要管理好一个项目，请从项目需求管理开始！