定制化系统开发：需求做的好，项目不乱跑

01.04 / 2024

在之前的文章中，我们谈到以项目交付作为商业模型的公司，要想业务规模做大做强、又要赚钱要利润，就一定要做KA大客户、百万以上大项目。而越大的项目，风险又越大，这既是一个残酷的事实又是一个充满矛盾的命题。

其实不只是百万以上级别的项目才会出现风险，只要脱离了【标准产品】实施的范畴，或是基于标品定制开发，都会存在一定的风险，从脑海中的需求到开发出来的产品，需要以项目化的方式进行管控，否则就会以失败告终。

分析报告指出，多达76%的项目失败是因为差劲的需求管理，这个是项目失败的最主要原因，比技术、进度失控或者混乱的变更管理还要关键。很多项目经理或客户成功经理并没有把需求管理重视起来，甚至认为这只是产品经理的事情，自己只做交付和统筹即可，俗话说：好的开始是成功的一半，一开始就没有管理好，注定为后续埋下了很多坑。

百万级项目可能考验的是综合项目管理能力，那么"短平快"的中小项目，如几十万、十几万甚至几万元的开发任务，就更加聚焦对于【定制需求】的管理管控与落地交付能力了，但这也是项目管理中最难得一点，项目的全生命周期绝对不是到了需求给我们才是项目管理的开始，越往前参与越深，我们的价值就越大。

为什么要做好需求管理？

为什么需求管理是项目管理中的一大难点呢？我们先看看这些场景是不是都很熟悉：

1）产品提的期望是A ，结果做出来演示的是B，实际出现很大的偏差，从期望到真正可落地的需求千差万别；

2）老板和产品负责人对需求的理解不一致，经常出现已经定好的目标，产品负责人要变更，但老板觉得没必要，项目经理受夹板气；

3）老板经常性的插入需求，导致变更率居高不下，需求变更流程形同虚设；

4）需求落地执行的过程中，一切都看上去挺顺利的，都在按计划执行，结果到验收阶段，各种问题频出，不是功能缺失，就是进度延迟，功能看着像是做完了，但各种小问题一大堆；

5）多方不断地插入需求，但时间又不允许增加，还要求按原计划完成，导致团队怨声载道，满意度很低。

以上这些场景，是不是都不陌生。事实上，可能远不止这些问题。

就我们项目管理日常的一些场景来分析，需求管理的难点在于：

1）需求管理本身，因为项目的特点是渐进明晰，不确定性是贯穿整个周期的，而需求是源头，一旦源头有问题，对整个项目全流程都有很大的影响；

2）需求管理“背后”，需求输出、实现、交付、完成，都是由人来参与的，有人参与的地方，人的复杂性，就使得整个链路都不会太简单。比如对需求方期望的真正理解、对老板变更预期的理解、对团队执行过程中的跟进与监控、还有团队执行的满意度。

作为一名项目经理，或是说一个需求任务的管理者，在我们日常项目管控中非常重要的一项工作，就是需求管理。如何做好需求管理，非常考验项目经理能力。下面就需求管理进行系统性拆解。

如何做好需求管理？

1、【了解背景】

我们在负责一个项目或接到某个需求任务之初时，需要花大量的时间了解清楚项目/需求的背景，这是一个非常重要的前提。何谓项目的背景，简单来说，就是这是一款什么样的产品？是什么类型的产品？市场上是否已经有类似的竞品？和竞品相比，产品的优势和亮点体现在哪里？项目的主要干系人有哪些？项目发起人，项目核心管理层的预期是什么？

除了这些以外，还有必要了解清楚，我们为什么要做这个项目？做这个项目能带来的价值是什么？再更深入一点的，这个项目主要要针对的是哪些用户？这些目标用户，我们的项目交付成果是否可以满足他们的期望和诉求？我们项目将围绕怎样的目标来展开，以便满足这些用户的期望和诉求。

当了解项目的背景之后，会有助于我们真正理解需求方/客户方的业务。

2、【明确目标】

当了解了项目背景之后，接着就要进一步明确项目的目标，从项目阶段来说可分为：短期目标、中期目标和远期目标。从产品本身来说，项目目标分为：最直接的目标、业务目标和战略目标。不论项目内部自己怎么划分，重点是需要明确项目的目标。

以最直接的目标为例，其实就是弄清楚时间、成本（人力）、范围和质量这四要素。要做这个项目，预计是在什么时间，投入多少人力资源，做多少需求，达到怎样的质量标准，这是必须要确定且非常具象化的。比如我们常常会去界定，项目在某个时间节点必须上线，这就是最直接的目标。

一个项目（无论大小）都必须有一个固定点"关门"时间，因为"锣鼓长了没好戏"，特别是在这样一个VUCA时代。

3、【界定范围】

在目标明确之后，要落地好目标需求，就必然要界定清楚需求交付的范围。这个需求范围通常可以按照MoSCoW的简洁法则来界定即：Must have（一定有）、Should have（应该有）、Could have（可以有） or Won't have for now（现在没有）。

以一个为期半年的项目为例：

1）项目最直接的目标是，一年后要达成上线运行；

2）为期半年的项目，说长不长，说短也不短。界定范围时，得先有一个整体的需求框架，这个是整个项目的大范围。梳理需求框架的目的不言而喻，就是我们要做一款产品/系统，会涉及到哪些功能模块。如下图表格所呈现的模式，把要做的需求先都界定清楚。

3）有了整体的需求框架之后，如果这是一个拆分版本迭代交付的项目，此时则需要进行版本的整体规划，我们不能完全凭靠拍脑袋做一份规划或计划，需要和产品/用户负责人进行深入的沟通和交流，确保彼此的理解一致。

进行需求优先级的划分更有利于需求的落地执行，同时定要预留时间缓冲期，以便可以应对各种突发情况。

4、【确认需求】

范围确定之后，接下来就是确定需求。需求管理，最根本在于对需求源头的管理，只有源头抓好了，后面的每个环节才会更顺。所以，具体到每个需求在正式开始落地之前，一定要经过确认。

特别是对于甲乙方视角的合同交付项目，很多时候客户提出的不一定是真需求，可能是某一个期望。这种情况下，从期望到真正落地的需求，项目经理是需要花费更多的时间来对齐确认的。这也是定制化需求开发落地比较难管理的点之一，确实有时依赖项目负责人的专业经验甚至风格魅力。

所以，需求是一定需要经过确认的，只有经过需求提出方/用户方确认过的需求，包括甲方项目负责人/业务部门Leader等一并确认过的需求，才会被提到需求开发List中来。这也是项目需求范围管理的最基本的原则之一。

一旦没有经过确认的需求进入开发，项目的风险和问题就会"涌现"出来。

5、【需求开发】

近年来很多甲方客户会提出敏捷开发的概念，但真正的敏捷开发方法论和大众所理解的敏捷却有所不同，敏捷提倡我们小步快跑，快速迭代，但并不代表着对需求的输出质量和时间没有要求。传统瀑布式开发往往甲方客户希望在保证质量的前提下，实现的功能越多越好且越快越好，还不能追加成本。而现代敏捷开发推崇的是迭代周期和资源负荷是恒定不能改变的，但需求功能是可以随时变化的，如下图所示：

需求的源头确认了，那么在需求进入开发阶段的伊始，也需要多次核对并确认。正所谓磨刀不误砍柴工，千万不要认为这个时间花了，还不如提前介入写几行代码，试想，如果为了省这个几天的时间，结果导致需求开发完成之后，出现一堆bug，最后验收效果不好，测试过程坎坷，看着前面省了一点时间，但其实整个需求的开发周期都拉长了。

在软件开发行业里面有一句话：质量是设计出来的。项目经理或测试人员通常是质量最后的“守门员”，但不应把所有的质量问题都留在最后测试环节。

6、【搭建可视化】

需求管理的过程需要透明化，可视化。市面上有很多好用的工具，可以借助工具来搭建搭建可视化，建立需求自动化运转流程。一个好的工具，可以让我们在对需求管理时事半功倍。如果是内部产研型组织的项目，成熟的TAPD工具就已经非常强大了。

因为每个公司的项目管理工具可能不一样，但利用工具的目的都是为了更好的提升效率，让整个项目管理过程更加的可视化，透明化，想尽一切办法让能够可视化的都尽量可视化，这也是项目管理的核心价值之一。

高呈自Q3季度开始，从部分项目试点开始率先使用了一款SaaS级的甲乙协同可视化产品，能够将需求、任务、资源进行可视化的呈现给内部团队成员与甲方客户，除关键节点邮件往来与纸质文件外，其余本地/线上文档都可以通过此工具可视化出来，如下图所示是自动生成的项目计划甘特图：