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

互联网公司如何管理实施项由于中后台系统开发本钱高，但是通用性较强，因此对于大局部企业来说，采购 成熟商业套件进行实施，从本钱和时间上都更为合算。即便是某些一线互联网企 业，他们早期的后台系统也采用了 Oracle这样的商业化套件。
但是，相对于自研，外采系统往往潜藏着更大的风险。特别是互联网企业，由于 业务调整迅速，组织集权度低，用户体验要求高，外采系统的风险远高于传统企 业。因此，互联网公司外采工程的实施管理，是一个颇有挑战性的课题。
01外采工程的风险外采工程的风险主要表达在两个方面。一是自研系统往往是小步快跑，从核心功 能出发，再不断进行迭代。而外采系统那么追求一步到位，需要在相对短的周期， 一次性形成相对完整的解决方案，系统交付的范围往往较大。另一方面，由于外 部系统和外部团队等不可控因素，也使得外采系统的实施雪上加霜。
1 .旧城改造不容易为了降低交付本钱，商业化软件必须追求产品的标准化。在信息化时代，SAP、 Oracle都是用一套产品实现多个行业的解决方案，这除了导致产品复杂度的大 大增加，用户体验也受到较大影响。
在这个阶段，工程经理要参与到最关键的业务讨论中，充分开掘和讨论差异。事 实上，在这个阶段能否充分挖掘差异很大程度决定了工程后期的风险严重程度。
6 .方案编制方案编制阶段可能会遇到很多困难。对于某些大型工程，工程组面对的可能是企 业长期以来存在的问题，但是需要在短短2个月内拿出具体的落地解决方案。
在这个阶段需要频繁的组织会议讨论,工程经理要亲自参与到最重要的方案讨论 中去。老实说，在这个时候也很考验工程经理的专业能力，因为如果方案达不成 一致，这个阶段就无法顺利完成。工程经理必须兼顾方案质量和工程进度。
某些关键的问题在执行层可能无法得到答案，工程组要及时向工程指导委员会汇 报，让高层来对关键问题决策。
在讨论的过程中，要组织屡次沙盘演练。只有看到具象化的操作流程，业务方才 能更容易发现方案存在的问题。
最终，整体方案形成后，要进行一次正式的高层汇报，只有高层认可的方案，才 能投入大量资源进行开发和配置工作。
7 .开发与配置某种程度上来说，实施工程是创新型的工作，因此工程管理的过程其实就是风险 控制的过程。 由于工程进度可能比较紧张，新开发的功能往往存在bug ,或者不满足业务方 的诉求。这一方面要求工程组制定好工程规范，比方产品设计需要业务方签字确 认，另一方面也要做好单点测试和验收工作，尽可能提前暴露和解决问题。
8 .集成测试当所有的核心功能都开发完成了，要适时的组织集成测试，以确保单点功能有效 的串联起来，支撑解决方案的落地。
集成测试完成后，上线的核心条件就基本满足了。因此，集成测试阶段是一个非 常重要的里程碑，需要组织一次演示，让各组组长代表业务部门进行确认验收。
最后，需要给高层做一个汇报，主要是汇报工程进度和各业务部门验收情况，同 时确认工程上线时间等。
9 .上线准备截止到上线前，工程组更多是小团队、内部的工作模式。这就意味着工程还并没 有经历全员级的用户考验。因此，上线准备工作需要细致筹划，确保一次性成功。 具体来说，有以下几个方面的工作需要重点关注：
9.1 上线策略所谓庙算多者胜，上线策略需要提前考虑上线可能会遇到的问题，从而提前进行 梳理，确保上线步骤、资源安排等工作准备妥当。
上线策略涉及到方方面面，关注公众号：ToB老人家，发送"上线策略〃，即可 查看我曾经编制的一份上线策略模板。
9.2 最终用户验收测试我们要记住一个原那么：风险恒在原那么。
实施工程往往范围广、难度大、周期长，风险本来就容易被遗漏，同时由于存在 风险转移漏斗，即便到了上线前，风险仍然是很多的。
因此，有必要在上线前通过真实、相对完整的数据进行一次或屡次最终用户验收。
通过实际业务来检验系统的可用性。
对于有条件的工程，强烈建议进行一次模拟上线。我的实践证明，经历过模拟上 线以后，实际上线的压力会大大降低。
9.3 最终用户培训对于最终用户培训，需要补充的一点是，培训的内容不仅仅是系统操作，也包括 上线作战方案，即工程上线的计划，以及上线问题的提报和解决途径。
上线期间容易集中爆发问题，因此提前做好最终用户的安抚工作，可以减轻上线 期间工程组的压力。
9.4 上线宣传准备 对于涉及全员的系统，做好上线宣传也是有必要的。一方面，可以散播系统上线 的信息，减少上线期间的混乱；另一方面，也可以宣传系统的价值，为工程组营 造好的舆论环境。在某些时候，会说和会做一样重要。
10、切换与支持阶段终于到了正式上线的阶段。对于没有进彳亍过模拟上线的工程组来说，这是整个项 目最有压力的一个阶段。不过，如果我们做好了上线策略，在这个阶段应该就是 累并快乐着的。
这个阶段可以补充两点。其一是如果工程经理对工程风险没有把握，一定要提前 准备好额外资源和应急机制。到了临近成功的时候，相信甲乙双方的高层都愿意 助工程组一臂之力。其二是要做好问题跟踪，一份统一的问题跟踪列表是有必要 的。上线过程中，对于问题要确保日清日结，不能积压；上线完成后，也要继续 跟踪问题列表，直至工程到达预期目标。
03总结工程管理是成为管理者的踏脚石。
尤其是互联网公司的实施工程，要求高难度大，能很好锻炼工程经理的管理协调 能力。作为一个产品经理，如果我们需要接手公司的实施工程，一定要提前筹划， 建立好工程机制，把控好各个阶段的工程风险，相信你一定可以在工程中有所收 获。
到了数字化时代，SaaS厂家往往专注于少数行业，这使得行业贴合度和用户体 验有了大幅度提高，但是软件的二次开发能力也受到了很大限制，导致用户的个 性化诉求无法得到有效满足。
互联网公司自研的产品在设计之初就是为企业贴身定制的，其后又不断进行迭 代，其业务切合度和用户体验都是商业化软件所难以比较的。因此，商业化软件 的二次开发难以防止。但是，由于商业化软件的固有架构和封闭性，使得其改造 难度和本钱都远大于自研系统。
曾经有一家国外企业想要优化实施系统的用户体验,最后发现必须对所有界面都 进行重新开发，可以想象这样的工作量有多么巨大。
2 .可怕的60分原那么实施公司的目标是盈利。这就意味着，在合同金额确定的前提下，如何控制本钱 和风险是实施公司的管理重点。
实施工程是一个"需求逐步明晰化”的过程，因此也无法通过合同条款明确所有 细节的要求，这就导致交付团队所认为〃应交付的内容"，往往小于甲方所认为 "应交付的内容"。
同时，反正只要工程能够交付，合同金额都是确定的，这也导致交付团队〃多一 事不如少一事"，这就是所谓的"60分原那么”。
60分原那么的危害性很大，很容易导致风险被遗留到工程后期。经历过实施工程的小伙伴可能都有这样的经历：一个实施方自己很容易发现的问题，但是一直拖 到上线前用户抱怨，实施方都没有主动提出来。但是，这是实施类工程所固有的 风险，我们只能选择去面对，想方法去规避。
3 .不可控的团队外采工程难度大风险多,对团队的要求也是很高的。除了个人能力，团队协作和 紧张的气氛也是必不可少的。
由于实施团队属于外部团队，我们并不具备人事权和赏罚权，也就意味着没有办 法按照我们的要求去管理团队。
曾经在一个工程中，实施团队的一个核心骨干因为各种个人理由不断请假。后来 我才得知，一局部请假其实是支援其他工程。毫无疑问，这种行为都是实施公司 授意的，但是作为甲方，也很难抓住他们的把柄。
4 .风险转移漏斗从合同签署的那一刻起，风险就开始像漏斗一样，从实施团队的一端转移到甲方 工程组团队。
因为一旦工程启动，甲方工程组团队就有责任推动工程成功上线。即便工程后期 出现重大风险，为了工程成功，甲方工程组团队也只能选择去承当和解决。这就 是所谓的风险转移漏斗。
风险转移漏斗可能导致实施团队存在侥幸心理，拖延问题的发现和解决，最终影 响工程的交付质量。
5 .跨部门协作的陷阱大型实施工程往往需要多个部门的协作。
在传统企业，会从各部门抽调核心骨干脱产投入工程，这在很大程度上解决了跨 部门协作的问题。
在互联网公司，各个部门都有苛刻的业务KPI指标，每个核心骨干的工作量都是 饱和的，这就决定了让他们脱产几乎是不可能的。另外，由于工程工作会占用较 多资源，影响到他们自身KPI的达成,也增加了跨部门协作的难度。
在曾经的一个数据中台工程中，需要各业务系统配合改造并接入数据中台。我们 投入了大量时间进行协调，最后请CTO帮助每周review各个团队的改造进度， 才保证了工程的按时推进。
02实施工程的管理重点实施工程的诸多风险，决定了我们需要在各个阶段重点部署，并从制度和机制上 防范风险。
1 .工程立项工程价值与风险明确
实施工程最大的风险，来自于高层不切实际的期望。
由于外部公司专业售前的早期介入，很容易将高层对工程的期望值抬高，而一旦 工程达不到预期，最终受伤害的可能是内部团队。比方，高层可能很期待工程的 管理咨询效果，同时默认系统的用户体验是互联网级别的。但实际上优秀又懂特 定行业的管理咨询顾问其实是非常稀缺的。而实施工程是旧城改造，用户体验很 难在短期得到根本性改善。
在这个阶段，建议通过安排投标方讲解具体咨询案例、演示系统操作等环节，帮 助高层获取更多有价值的信息，从而做出更合理的决策。
1.1 工程团队与机制准备互联网公司的工作节奏都很紧张，考虑到实施工程的诸多潜在风险，必须要建立 一支高效的工程团队。在这支团队中，除了工程经理，还有几个关键角色是必须 要存在的。
工程总监：甲乙方工程经理在工程推进过程中，难免会出现推进困难；双方在协 作过程中，也可能会出现工作矛盾。为了不影响工程进度和质量，当出现超出项 目经理能力的情况时，需要工程总监出面协调解决。同时，工程经理也需要定期 向工程总监汇报工作，以确保工程方向符合公司期望。
工程指导委员会：工程是为公司目标服务的，涉及很多重大决策。因此，需要有 工程指导委员会在工程各阶段进行把关，防止工程方向的错误；同时，工程组也 需要指导委员会帮助解决跨部门协调问题和决策重大问题等。
小组组长：虽然无法让业务骨干脱产，但是仍然应该把他们纳入工程组，同时指 定其部门领导担任组长。这样，当出现资源协调等问题时，组长可以帮助解决。
当然，仅仅设立角色并分配职责是不够的，必须通过工程机制让各角色主动承当 起责任。常见的工程机制包括工程例会、专项汇报、月度优秀小组/成员评选、 优秀工程评选等。
值得一提的是，工程组不能把会议和汇报当做负担，而应该当做防范工程风险、 推进工程的工具。比方，阶段性向工程指导委员会汇报工作时，可以让各小组组 长来进行汇报，从而增强他们的主动性和紧迫感。
1.2 提前梳理需求在立项的同时，就要开始着手梳理详细的需求。
需求是工程的基础，很多工程出问题，都是源于一开始的需求不够完整和明确。 建议可以开一个预启动会，把工程团队召集起来，正式安排需求梳理的任务。
2 .选型阶段选型阶段的工作主要包括产品选型、实施方选型和合同谈判三个局部。
2.1 产品选型互联网公司对软件的要求很高，因此产品选型也需要比传统企业更加严格。
除了常规的重点方案讲解、同行业标杆案例讲解和系统演示之外，建议对软件的 用户体验、开放性和灵活性进行重点考察。需要强调的是如何应对组织架构的频 繁、快速调整，特别是涉及业财一体化时，如何应对组织架构快速调整是一个不 小的挑战。
另外，需要注意的一点是，要让高层充分认识到软件的优劣势，否那么可能就会面 临工程上线成功但"工程不成功〃的局面。可以安排一些关键流程的高层演示， 并且内部出具评估报告给到高层。
2.2 实施方选择三分产品七分实施，放在互联网公司身上仍然适用。
同一套产品不同的实施团队来负责，结果肯定是有差异的。实施团队的选择又分 为咨询公司选择、工程经理选择和实施顾问选择三个方面。
相对而言，工程经理和实施顾问的工程经验比公司案例更加重要，在这方面要重 点考察和把关。甲乙方工程经理要多沟通，确保大家在工程管理方面的理念和习 惯是相对一致的。至于咨询公司，一分价钱一分货，抱着合理的期望，选择合适 自己的最重要。
2.3 合同谈判合同谈判可能是一个比较艰苦的环节，除了合同金额，条款的谈判可能更加困难。 因为实施方实际上是合同驱动的，或者更直白的说，他们只会遵循合同里面明确 了的规那么。
因此合同谈判阶段必须要把控住关键条款。比方，在工程阶段对应的付款比例方 面，我们要确保在每一个关键的阶段都有一定比例的付款，这样才能持续激励实 施方保持高效的状态。同时，考虑到风险转移漏斗，前期的付款比例应该尽量控 制得小一些。另外，需求列表也非常重要，梳理好的需求范围一定要写进合同， 否那么就有可能会扯皮。
3 .工程计划从某种角度来说，工程计划决定工程成败。
工程计划分为两种，一种是整体计划，工程经理需要考虑每个阶段的重难点，合 理分配时间和资源；一种是每月、每周和每天的计划，工程经理要根据实际情况, 充分评估工程风险，再灵活调整计划。这种日常性计划其实是属于工程机制的部 分。
工程管理是一个苦活，因为对于参与工程的大局部人来说，工程工作与日常工作 是脱节的，有时候甚至是矛盾的，优先级并不高。工程经理实际上是一个没有实 权的岗位，他必须更多依赖别人去完成工作，这就意味着大量的协调。只有做好 了工程计划，提前考虑各种风险，工程经理才能协调好资源，维护自己的影响力， 减少工作的难度。
由于乙方工程经理负责交付资源的管理用方那么需要负责内部资源的协调。因此, 甲乙方工程经理必须充分沟通，对工程计划和工程机制达成一致。
4 .工程启动会召开一个成功的启动会，可以〃秀出工程组的肌肉"，让相关部门看到公司对项 目组的重视。同时，在启动会上让工程干系人登台、发言，实质上是让他们做出 了一个正式的承诺，不失为一种有用的激励方式。
工程启动会可能牵涉到众多部门，涉及甲乙方高层。因此，准备一定要细致，并 且做好排练。
5 .调研与需求梳理调研阶段实际上包含了两块重要的工作。
其一是实施团队详细了解企业的业务与需求，并且与系统的标准功能进行匹配， 差异的局部将作为方案编制的重点；其二是业务方详细了解系统的标准功能，并 且与企业的业务需求进行匹配，差异的局部也将作为工程的重点。
两块工作看起来是重复的，但是实际上是从各自熟悉的领域出发，相当于优势互 补，因此都不可或缺。