互联网公司如何管理实施项目？

ToB老人家 2023-07-27 11:13:30

由于中后台系统开发成本高，但是通用性较强，因此对于大部分企业来说，采购成熟商业套件进行实施，从成本和时间上都更为合算。即便是某些一线互联网企业，他们早期的后台系统也采用了Oracle这样的商业化套件。

但是，相对于自研，外采系统往往潜藏着更大的风险。特别是互联网企业，由于业务调整迅速，组织集权度低，用户体验要求高，外采系统的风险远高于传统企业。因此，互联网公司外采项目的实施管理，是一个颇有挑战性的课题。

01 外采项目的风险

外采项目的风险主要体现在两个方面。一是自研系统往往是小步快跑，从核心功能出发，再不断进行迭代。而外采系统则追求一步到位，需要在相对短的周期，一次性形成相对完整的解决方案，系统交付的范围往往较大。另一方面，由于外部系统和外部团队等不可控因素，也使得外采系统的实施雪上加霜。

1. 旧城改造不容易

为了降低交付成本，商业化软件必须追求产品的标准化。在信息化时代，SAP、Oracle都是用一套产品实现多个行业的解决方案，这除了导致产品复杂度的大大增加，用户体验也受到较大影响。

到了数字化时代，SaaS厂家往往专注于少数行业，这使得行业贴合度和用户体验有了大幅度提高，但是软件的二次开发能力也受到了很大限制，导致用户的个性化诉求无法得到有效满足。

互联网公司自研的产品在设计之初就是为企业贴身定制的，其后又不断进行迭代，其业务切合度和用户体验都是商业化软件所难以比拟的。因此，商业化软件的二次开发难以避免。但是，由于商业化软件的固有架构和封闭性，使得其改造难度和成本都远大于自研系统。

曾经有一家国外企业想要优化实施系统的用户体验，最后发现必须对所有界面都进行重新开发，可以想象这样的工作量有多么巨大。

2. 可怕的60分原则

实施公司的目标是盈利。这就意味着，在合同金额确定的前提下，如何控制成本和风险是实施公司的管理重点。

实施项目是一个“需求逐步明晰化”的过程，因此也无法通过合同条款明确所有细节的要求，这就导致交付团队所认为“应交付的内容”，往往小于甲方所认为“应交付的内容”。

同时，反正只要项目能够交付，合同金额都是确定的，这也导致交付团队“多一事不如少一事”，这就是所谓的“60分原则”。

60分原则的危害性很大，很容易导致风险被遗留到项目后期。经历过实施项目的小伙伴可能都有这样的经历：一个实施方自己很容易发现的问题，但是一直拖到上线前用户抱怨，实施方都没有主动提出来。但是，这是实施类项目所固有的风险，我们只能选择去面对，想办法去规避。

3. 不可控的团队

外采项目难度大风险多，对团队的要求也是很高的。除了个人能力，团队协作和紧张的氛围也是必不可少的。

由于实施团队属于外部团队，我们并不具备人事权和赏罚权，也就意味着没有办法按照我们的要求去管理团队。

曾经在一个项目中，实施团队的一个核心骨干因为各种个人理由不断请假。后来我才得知，一部分请假其实是支援其他项目。毫无疑问，这种行为都是实施公司授意的，但是作为甲方，也很难抓住他们的把柄。

4. 风险转移漏斗

从合同签署的那一刻起，风险就开始像漏斗一样，从实施团队的一端转移到甲方项目组团队。

因为一旦项目启动，甲方项目组团队就有责任推动项目成功上线。即便项目后期出现重大风险，为了项目成功，甲方项目组团队也只能选择去承担和解决。这就是所谓的风险转移漏斗。

风险转移漏斗可能导致实施团队存在侥幸心理，拖延问题的发现和解决，最终影响项目的交付质量。

5. 跨部门协作的陷阱

大型实施项目往往需要多个部门的协作。

在传统企业，会从各部门抽调核心骨干脱产投入项目，这在很大程度上解决了跨部门协作的问题。

在互联网公司，各个部门都有苛刻的业务KPI指标，每个核心骨干的工作量都是饱和的，这就决定了让他们脱产几乎是不可能的。另外，由于项目工作会占用较多资源，影响到他们自身KPI的达成，也增加了跨部门协作的难度。

在曾经的一个数据中台项目中，需要各业务系统配合改造并接入数据中台。我们投入了大量时间进行协调，最后请CTO帮助每周review各个团队的改造进度，才保证了项目的按时推进。

02 实施项目的管理重点

实施项目的诸多风险，决定了我们需要在各个阶段重点部署，并从制度和机制上防范风险。

1. 项目立项

1.1 项目价值与风险明确

实施项目最大的风险，来自于高层不切实际的期望。

由于外部公司专业售前的早期介入，很容易将高层对项目的期望值抬高，而一旦项目达不到预期，最终受伤害的可能是内部团队。比如，高层可能很期待项目的管理咨询效果，同时默认系统的用户体验是互联网级别的。但实际上优秀又懂特定行业的管理咨询顾问其实是非常稀缺的。而实施项目是旧城改造，用户体验很难在短期得到根本性改善。

在这个阶段，建议通过安排投标方讲解具体咨询案例、演示系统操作等环节，帮助高层获取更多有价值的信息，从而做出更合理的决策。

1.2 项目团队与机制准备

互联网公司的工作节奏都很紧张，考虑到实施项目的诸多潜在风险，必须要建立一支高效的项目团队。在这支团队中，除了项目经理，还有几个关键角色是必须要存在的。

项目总监：甲乙方项目经理在项目推进过程中，难免会出现推进困难；双方在协作过程中，也可能会出现工作矛盾。为了不影响项目进度和质量，当出现超出项目经理能力的情况时，需要项目总监出面协调解决。同时，项目经理也需要定期向项目总监汇报工作，以确保项目方向符合公司期望。

项目指导委员会：项目是为公司目标服务的，涉及很多重大决策。因此，需要有项目指导委员会在项目各阶段进行把关，避免项目方向的错误；同时，项目组也需要指导委员会帮助解决跨部门协调问题和决策重大问题等。

小组组长：虽然无法让业务骨干脱产，但是仍然应该把他们纳入项目组，同时指定其部门领导担任组长。这样，当出现资源协调等问题时，组长可以帮助解决。

当然，仅仅设立角色并分配职责是不够的，必须通过项目机制让各角色主动承担起责任。常见的项目机制包括项目例会、专项汇报、月度优秀小组/成员评选、优秀项目评选等。

值得一提的是，项目组不能把会议和汇报当做负担，而应该当做防范项目风险、推进项目的工具。比如，阶段性向项目指导委员会汇报工作时，可以让各小组组长来进行汇报，从而增强他们的主动性和紧迫感。

1.3 提前梳理需求

在立项的同时，就要开始着手梳理详细的需求。

需求是项目的基础，很多项目出问题，都是源于一开始的需求不够完整和明确。建议可以开一个预启动会，把项目团队召集起来，正式安排需求梳理的任务。

2. 选型阶段

选型阶段的工作主要包括产品选型、实施方选型和合同谈判三个部分。

2.1 产品选型

互联网公司对软件的要求很高，因此产品选型也需要比传统企业更加严格。

除了常规的重点方案讲解、同行业标杆案例讲解和系统演示之外，建议对软件的用户体验、开放性和灵活性进行重点考察。需要强调的是如何应对组织架构的频繁、快速调整，特别是涉及业财一体化时，如何应对组织架构快速调整是一个不小的挑战。

另外，需要注意的一点是，要让高层充分认识到软件的优劣势，否则可能就会面临项目上线成功但“项目不成功”的局面。可以安排一些关键流程的高层演示，并且内部出具评估报告给到高层。

2.2 实施方选择

三分产品七分实施，放在互联网公司身上仍然适用。

同一套产品不同的实施团队来负责，结果肯定是有差异的。实施团队的选择又分为咨询公司选择、项目经理选择和实施顾问选择三个方面。

相对而言，项目经理和实施顾问的项目经验比公司案例更加重要，在这方面要重点考察和把关。甲乙方项目经理要多沟通，确保大家在项目管理方面的理念和习惯是相对一致的。至于咨询公司，一分价钱一分货，抱着合理的期望，选择合适自己的最重要。

2.3 合同谈判

合同谈判可能是一个比较艰苦的环节，除了合同金额，条款的谈判可能更加困难。因为实施方实际上是合同驱动的，或者更直白的说，他们只会遵循合同里面明确了的规则。

因此合同谈判阶段必须要把控住关键条款。比如，在项目阶段对应的付款比例方面，我们要确保在每一个关键的阶段都有一定比例的付款，这样才能持续激励实施方保持高效的状态。同时，考虑到风险转移漏斗，前期的付款比例应该尽量控制得小一些。另外，需求列表也非常重要，梳理好的需求范围一定要写进合同，否则就有可能会扯皮。

3. 项目计划

从某种角度来说，项目计划决定项目成败。

项目计划分为两种，一种是整体计划，项目经理需要考虑每个阶段的重难点，合理分配时间和资源；一种是每月、每周和每天的计划，项目经理要根据实际情况，充分评估项目风险，再灵活调整计划。这种日常性计划其实是属于项目机制的部分。

项目管理是一个苦活，因为对于参与项目的大部分人来说，项目工作与日常工作是脱节的，有时候甚至是矛盾的，优先级并不高。项目经理实际上是一个没有实权的岗位，他必须更多依赖别人去完成工作，这就意味着大量的协调。只有做好了项目计划，提前考虑各种风险，项目经理才能协调好资源，维护自己的影响力，减少工作的难度。

由于乙方项目经理负责交付资源的管理，甲方则需要负责内部资源的协调。因此，甲乙方项目经理必须充分沟通，对项目计划和项目机制达成一致。

4. 项目启动会

召开一个成功的启动会，可以“秀出项目组的肌肉”，让相关部门看到公司对项目组的重视。同时，在启动会上让项目干系人登台、发言，实质上是让他们做出了一个正式的承诺，不失为一种有用的激励方式。

项目启动会可能牵涉到众多部门，涉及甲乙方高层。因此，准备一定要细致，并且做好排练。

5. 调研与需求梳理

调研阶段实际上包含了两块重要的工作。

其一是实施团队详细了解企业的业务与需求，并且与系统的标准功能进行匹配，差异的部分将作为方案编制的重点；其二是业务方详细了解系统的标准功能，并且与企业的业务需求进行匹配，差异的部分也将作为项目的重点。

两块工作看起来是重复的，但是实际上是从各自熟悉的领域出发，相当于优势互补，因此都不可或缺。

在这个阶段，项目经理要参与到最关键的业务讨论中，充分发掘和讨论差异。事实上，在这个阶段能否充分挖掘差异，很大程度决定了项目后期的风险严重程度。

6. 方案编制

方案编制阶段可能会遇到很多困难。对于某些大型项目，项目组面对的可能是企业长期以来存在的问题，但是需要在短短2个月内拿出具体的落地解决方案。

在这个阶段需要频繁的组织会议讨论，项目经理要亲自参与到最重要的方案讨论中去。老实说，在这个时候也很考验项目经理的专业能力，因为如果方案达不成一致，这个阶段就无法顺利完成。项目经理必须兼顾方案质量和项目进度。

某些关键的问题在执行层可能无法得到答案，项目组要及时向项目指导委员会汇报，让高层来对关键问题决策。

在讨论的过程中，要组织多次沙盘演练。只有看到具象化的操作流程，业务方才能更容易发现方案存在的问题。

最终，整体方案形成后，要进行一次正式的高层汇报，只有高层认可的方案，才能投入大量资源进行开发和配置工作。

7. 开发与配置

某种程度上来说，实施项目是创新型的工作，因此项目管理的过程其实就是风险控制的过程。

由于项目进度可能比较紧张，新开发的功能往往存在bug，或者不满足业务方的诉求。这一方面要求项目组制定好项目规范，比如产品设计需要业务方签字确认，另一方面也要做好单点测试和验收工作，尽可能提前暴露和解决问题。

8. 集成测试

当所有的核心功能都开发完成了，要适时的组织集成测试，以确保单点功能有效的串联起来，支撑解决方案的落地。

集成测试完成后，上线的核心条件就基本满足了。因此，集成测试阶段是一个非常重要的里程碑，需要组织一次演示，让各组组长代表业务部门进行确认验收。

最后，需要给高层做一个汇报，主要是汇报项目进度和各业务部门验收情况，同时确认项目上线时间等。

9. 上线准备

截止到上线前，项目组更多是小团队、内部的工作模式。这就意味着项目还并没有经历全员级的用户考验。因此，上线准备工作需要细致筹划，确保一次性成功。具体来说，有以下几个方面的工作需要重点关注：

9.1 上线策略

所谓庙算多者胜，上线策略需要提前考虑上线可能会遇到的问题，从而提前进行梳理，确保上线步骤、资源安排等工作准备妥当。

上线策略涉及到方方面面，关注公众号：ToB老人家，发送“上线策略”，即可查看我曾经编制的一份上线策略模板。

9.2 最终用户验收测试

我们要记住一个原则：风险恒在原则。

实施项目往往范围广、难度大、周期长，风险本来就容易被遗漏，同时由于存在风险转移漏斗，即便到了上线前，风险仍然是很多的。

因此，有必要在上线前通过真实、相对完整的数据进行一次或多次最终用户验收。通过实际业务来检验系统的可用性。

对于有条件的项目，强烈建议进行一次模拟上线。我的实践证明，经历过模拟上线以后，实际上线的压力会大大降低。

9.3 最终用户培训

对于最终用户培训，需要补充的一点是，培训的内容不仅仅是系统操作，也包括上线作战方案，即项目上线的计划，以及上线问题的提报和解决途径。

上线期间容易集中爆发问题，因此提前做好最终用户的安抚工作，可以减轻上线期间项目组的压力。

9.4 上线宣传准备

对于涉及全员的系统，做好上线宣传也是有必要的。一方面，可以散播系统上线的信息，减少上线期间的混乱；另一方面，也可以宣传系统的价值，为项目组营造好的舆论环境。在某些时候，会说和会做一样重要。

10、切换与支持阶段

终于到了正式上线的阶段。对于没有进行过模拟上线的项目组来说，这是整个项目最有压力的一个阶段。不过，如果我们做好了上线策略，在这个阶段应该就是累并快乐着的。

这个阶段可以补充两点。其一是如果项目经理对项目风险没有把握，一定要提前准备好额外资源和应急机制。到了临近成功的时候，相信甲乙双方的高层都愿意助项目组一臂之力。其二是要做好问题跟踪，一份统一的问题跟踪列表是有必要的。上线过程中，对于问题要确保日清日结，不能积压；上线完成后，也要继续跟踪问题列表，直至项目达到预期目标。