对任何一家公司来说，资源永远是紧缺的。对刚起步的创业公司来说尤甚，经常会出现产品研发、项目交付抢资源的情况。对管理者极具考验，资源调配的点很难把握。本文就项目交付/产品实现中的资源投入给出建议，供资源管理者参考，在项目交付和产品研发中做出科学决策。

成功的B端产品公司胜出的法宝之一就是把高价值高绩效的员工放在最核心的位置上、发挥出最高的效能，而不在于他的薪水和职位。

对业务上依赖B端产品或提供B端产品的创业公司，业务架构师BA或产品总监一定是超配的。千万不要心疼薪水，且起步阶段是可以选择平均水平的CTO的。尤其是业务增值类产品的，是靠业务方案吃饭的、而不是靠技术吃饭的。

一、项目初期

在项目的销售过程中赢单概率大时，售前会与后端沟通项目范围和预计入场时间。此时，交付线和资源管理者就得开始考虑项目经理、BA、SA的人选，尤其是BA的人选，得确认下来。

大型B端项目、或知名企业都会对核心人员进行面试，所以在准备人选时也要考虑此类问题，不能准备的A顾问其实只是为了拿下项目；而不是为了交付，这会给项目交付时带来一些困扰。

BA确定下来后，开始评估项目范围、业务目标、产品组合、定制工作量。并提前和售前沟通协同、确定哪些坑得在协议中约定下来、避免交付时出坑太难。未来我会分享项目前期和交付中有哪些坑。

二、入场交付

大型B端产品平台的交付会有5个阶段：项目准备、蓝图设计、系统实现、上线准备、上线运营。不同时期投入的工种、人员数量、能力等级是不同的。下表供参考（不同项目、人员构成和投入会有不同）

1. 关键人员的投入

项目经理、BA、SA是团队中专业能力较高的，也是薪水和成本较高的人员，这三类人员不能长期在项目上，只需在关键时段投入、做到有效产出就好。

这是本人以往多个大型项目交付总结的成功经验，如此才会一年中在3~4个大型项目中穿插，可保障多个项目始终在可控范围内，并持续滚动、进入新项目。

• 项目经理：在参与项目准备和蓝图设计阶段后，分阶段、非全时投入，在项目进度、项目资源、关键汇报等工作上做好即可。项目经理不在交付现场时，可指派顾问组长负责现场。
• BA和SA：在参与项目准备和蓝图设计阶段后，即可逐步撤出项目组。可远程或关键时刻参与项目工作，以方案指导和审查为主。
• 顾问组长：顾问组长是整个项目组的中坚，在BA、项目经理撤出后承担相应职责，在人选上要十分慎重。其知识面和专业领域相对要宽，具备较好的沟通能力和全局观，并可以得到团队的信任和专业认可。

2. 项目准备阶段

这个阶段的核心工作是项目有个好的开头，在项目蜜月期保持初恋时的热情。

售前顾问需要与交付团队无缝交接，尤其是项目动因、项目范围、交付难点、干系人及其重点关切和诉求、项目计划建议。

关键工作：甲乙方项目团队组建完成；项目计划确认；召开项目启动会。项目启动会是非常重要的项目会议，既是吹风会、拍胸脯会，也是培训会，充分的准备、做好首秀。

完成标志：成功的项目启动会。

3. 蓝图设计阶段

蓝图阶段是决定项目范围和成本的关键阶段，是业务描述由As Is → To be的过程。大型项目一般在进场1.5~2月完成蓝图设计工作。

越接近客户方的项目动因、核心诉求，业务方案越有针对性、项目越容易成功。重点加强什么、果断放弃什么，这是对BA和顾问团队的考验。蓝图阶段，不需要顾问全部进场，核心业务相关的顾问进场即可，辅助BA、顾问组长做好方案设计工作。

业务方案的实现策略、技术难点识别也是对SA的考验。基于业务方案，BA会提出总体的业务模型、给出ER图雏形，供SA做技术实现的参考，并传递给技术经理。

此时，系统实现需要的资源就可以基本明确、逐步安排进场了，并可以做一些技术开发准备和实际开发工作。

甲乙双方也由蜜月期逐步转入冲突期：对业务目标的不同理解、项目范围认识的不一致等逐步显现出来。并且受于项目成本的约束，乙方也会有意识的降低项目预期，包括业务目标、范围、创新应用等。

关键工作：高中层业务调研、IT环境调研（调研包含现状、需求两部分），业务方案汇报与确认，概要设计完成。

完成标志：业务方案签字确认。

4. 系统实现阶段

系统实现阶段是乙方项目资源投入的高峰期，业务顾问、开发人员、设计人员、测试人员分批入场。

关键工作​：系统开发与测试。

完成标志：完成集成测试​。​

需求传递：顾问向实现团队传递需求前，一定先与客户做好充分的沟通，避免理解出现偏差。RP稿设计中使用的信息，尽可能使用业务发生的数据，如商品、活动等等，把甲方的业务人员带入到业务环境中。内部传递时，需要准备充分，尤其是一定要确认测试人员的理解是否到位，这是产品质量的关键门槛。

开发人员：需要按业务线搭配好能力梯次，一般后端开发1个高级+2个中级+4个初级，就可以交付一个复杂的业务线，前端根据业务方案定资源投入。核心是对技术方案、开发规范、概要设计的高效落地。尤其是数据字典的管理，每增加一个字段必须由业务线的技术负责人确认，不得由开发人员随意增加。

设计人员：在交互风格和规范上，需要提前安排设计人员与甲方对接，此工作耗时较长。对审美、用户体验每个人的理解都是不一样的。

测试人员：测试组长很重要，尽心的测试组长会做好测试与需求、技术实现的有效衔接，并仔细审查每个测试用例。一个强势、负责任的测试组长，将是系统质量的关键保障。

关于开发方式：在复杂的B端产品上，不建议采用敏捷开发。在实际的管理项目过程中，没有严格的完全敏捷或者完全瀑布模式，都是各自掺杂了其他的方式。我们可以采用减小瀑布模型的粒度，用敏捷开发的优秀实践方式来处理。常见的项目中会分多个阶段目标，就是在减少瀑布粒度。

敏捷开发：首先把客户最关注的软件原型先做出来，交付或者上线，在实际场景中去修改弥补需求中的不足，快速修改，再次发布版本、再次上线或者交付。如此循环，直到用户（客户）满意。适用于需求不明确的项目、创新性的项目或者需要抢占市场的项目。

瀑布式开发：要求明确的需求，按照需求一步步做好规划，在项目运作过程中严格产出各种文档，按着流程一步步走下去。一般适用于需求比较明确、To B端项目。

5. 上线准备

上线准备是在单元测试、功能测试、集成测试（甲方项目组业务线成员测试）通过后，具备客户接受测试UAT（用户代表测试）条件时，开始准备上线。

主要工作有：上线计划内部发布、客户接受测试UAT、系统实现收尾、上线计划发布、数据准备、用户培训、生产环境准备等工作。

针对UAT测试结果做一些调整，需要顾问、设计、开发、测试的部分同事参与。

关键工作：UAT测试、生产环境与数据准备、用户培训。

完成标志：所有准备工作完成，正式的上线时间点确认。

测试结果应对：用户代表UAT测试时，会提出以前调研过程中未涉及的盲点业务，相对业务价值不高，但可能会影响用户的应用体验或某个小业务的处理。需要团队思考是否执行需求变更程序和迭代计划。

上线节奏：项目经理、顾问组长、技术经理需要与甲方项目团队就上线计划和系统实现成果、上线动员、用户培训等整体准备条件进行详细摸底和评估，确保顺利上线。提醒：涉及经销商端的项目，准备一定要十分充足，否则对项目的负面影响较大。比如涉及主机厂的经销商的项目，进展不顺或低于预期，会有经销商的老板电话给主机厂的董事长投诉的。

数据迁移：复杂项目中，数据迁移工作较复杂，需要专职的数据顾问与业务顾问一同对数据进行分析，比如客户唯一性规则、脏数据的处理规则等，包括一些数据工具的应用。从业务上梳理迁移策略，并与技术经理一同制定迁移计划和方案。经客户方确认后统一实施，在不停业务或短暂停业务的情况下，就需要采用提前批量迁移+补录的方式处理。

系统运维：生产环境准备、日常基础运维、运维支持流程、常见问题处理方案等工作需要运维同学在此阶段开始介入，按照约定的SLA服务协议执行。

6. 上线运营

上线后需要整个团队跟进一个月的业务，目的是为业务跟进、持续迭代、运营支持策略优化、项目收尾。

关键工作：应用跟进、持续迭代、项目收尾。

完成标志：项目验收完成。

业务跟进：上线后需要持续跟进上线应用情况，尤其是月头月尾冲击月度目标和月初业务调整的时间点，只有顺利度过这个时间点才算业务上线稳了。跟进的数据还包括用户使用量、频次、时间段、核心业务应用等，用以评价项目的应用价值和使用满意度。

持续迭代：跟进用户反馈的应用感受和改善建议，列入需求池待进行上线阶段的迭代。对关键用户的关键业务需求需及时反馈和响应，讨论和决定迭代计划。

运营支持策略优化：上线后运营政策需要根据实际情况对上线前准备的支持策略进行优化，逐步常态化。

项目收尾：项目经理或现场执行经理需要按照协议约定内容，或蓝图设计阶段双方约定的验收程序开始着手准备项目验收的材料。

三、产品与项目打架时的资源调配原则

很多初创企业在一边交付项目、赢得市场认可，一边在做产品研发，项目交付与产品研发上的资源紧缺和打架是常用的事。有4类人员可复用，资源调配时需考虑因素供参考：

• BA/SA：此类人员可在产品研发和项目交付上同时兼顾，一方面积极消化项目上的需求转为产品输入，另一方面需要站在项目、产品两个不同维度上思考。不能在项目上过度规划、造成项目交付困难。
• 业务顾问：需要输出RP稿件等较细节的工作投入，可在产品设计和项目需求上兼顾，但时间投入上要平衡，时间分配上尽量做到55或46分。如果产品和项目的业务相关性不大，或投入73分及以上，就直接专职，不要采用兼顾方式、哪边都做不好。
• 开发/测试人员：如项目中的某个功能需求已明确产品化的，可将产品开发/测试人员纳入项目体系，与项目开发/测试人员共同处理项目任务。前提是在BA、SA与产品负责人均已明确业务边界。

作者：王建儒，MBA，独立顾问/资深专家，17年业务运营、运营平台规划与建设经验

本文由 @王建儒 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议