【导言】
随着互联网企业的发展，越来越多的互联网企业开始登陆B端市场，利用自己的技术力量和项目管理方法与传统企业展开角逐。但是，面对被传统企业“宠坏”了的企业用户，互联网企业的交付项目往往会有些难以言表的痛楚。
有的企业，在完成产品原型之后，就要开始在企业中敲锣打鼓的开始推广了，想用运营的方式来制造噱头占据市场，却没有考虑能创造什么价值。这是极不可取的！我们需要明确互联网和传统交付项目的关系，解决互联网交付的痛点，才能互联网交付项目的路上走得稳健。
业务对比
要想了解互联网交付项目的痛点，首先需要真正理解互联网项目和传统交付项目的本质和不同。只有在深入理解的基础上，才能在面对两者结合形成的互联网交付项目时，找准痛点并进行解决。
在笔者看来，互联网项目往往具有很强的互联网基因，就是价值与敏捷。所谓价值，其实就是产品和产品增量完成之后，能够为多少用户带来多大效益。所谓敏捷，就是在固定的时间周期（一般是1-4周）内，通过执行产品列表优先级排序、冲刺规划会、冲刺、评审会、回顾会等一系列活动内容，快速完成价值交付。而在传统的软件企业中，交付项目一般由实施方组建一个临时的团队前往客户现场，按照瀑布式的方式将产品交付给客户。所以，两者在基因上具有天然的差别。
从需求层面来说，需求提出方和验证人不同。交付项目的服务用户是单个企业用户，可进行一对一的面对面沟通然后进行需求明确，最终只需要得到这个企业的认可即可，因此需求具有很强的企业个性化，不方便进行企业间应用拓展。
而互联网项目的需求，是产品经理根据产品方向提出的（可能来自市场，可能来自用研，也可能来自自我产品认知），并在产品经理进行初步验收后，提供给用户使用。在此基础上，两者结合产生的互联网交付项目的需求，既有来自外部客户，也有来自产品内部。
从产品售卖来说，收费的方式不同。交付项目往往是固定总价的定制项目，需要根据客户需求的人天评估结果进行计费，而在项目交付之后，按照提供的运维服务进行收费。而互联网项目是一个不定价的持续交付项目，需要根据客户对已有功能的认可程度进行付费，支付费用获取使用权限（即按照license收费）。在此基础上，两者结合产生的互联网交付项目的费用中，包含定制费用和license费用两部分。
从项目实施来说，交付的方式不同。交付项目和客户是强关联关系，需要保持紧密的联系和沟通，且每一项功能都是需要单独计费的，因此，传统交付项目中，往往会临时组成项目团队按照项目前期确认的需求内容进场开发，按照瀑布的方式完成交付后撤场。而互联网项目都是有团队在公司内部开发，按照产品经理的设计，小步快跑的快速完成。在此基础上，两者结合产生的互联网交付项目的实施过程中，往往会需要不定期的前往客户现场进行事项确认，远程完成主要任务开发。
痛点分析
项目管理中总会遇到各种各样的问题，即使我们将互联网项目和传统交付项目结合，尝试着走出一条互联网交付项目的新路子的时候，这些问题也无法避免。但是细分原因，你却会发现一些不一样的地方。
以下是笔者关于互联网交付项目的一点思考：
1.需求管理困难
在互联网交付项目中，需求的来源往往会有外部客户和产品发展需求两个方面，然而两者并不总是相同的。交付项目的需求，往往来源于客户的实际需要，往往带有很强的个性化，与产品经理通过调研获得的需求明显不同，所以产品经理的第一反应通常会是“这个功能点还有哪个用户会用到呢”。但是站在用户的角度，花钱买的就是快速的服务，只要这个功能对我有用就行了。要从两个不同的立场看问题，这是交付项目永远的痛。
因此，互联网交付项目的需求管理中最重要的就是功能价值观的宣贯。互联网项目，内部项目或交付项目，必定是按照需求的优先级来确定的，而影响优先级的要素会有普适性、单个功能的价值和诉求。对于客户提出的需求，我们可能只会实现80%，但是我们可以保证，我们实现的这80%都是行业通用的解决方案，未来也易于扩展和延伸，且具备高可用性。对于剩下的20%，我们可以放在需求池中逐步实现。
其实，与需求相关的更敏感的话题是费用问题，也必须要引起重视。在互联网交付项目的现状下，我们可能很难在项目期间收取那20%的费用，但是将其放在服务期内，按照完成情况进行费用结算，从而实现一个双赢的局面。
2.计划安排困难
受互联网基因的影响，互联网交付项目往往也会采用敏捷的方法，按照产品优先级进行排期。但是在交付过程中，可能会出现一些突发性的bug，客户往往会提出一些额外的需求，抑或是一些项目之外的工作（做交付的同学都知道，这些都会或多或少的存在）。而这些突如其来的工作，往往会给整个迭代周期带来巨大的影响，但是 却不被客户所理解，对团队执行的计划造成冲击，甚至是需要调整计划。
所以，互联网交付项目的排期要有一定的预留时间，并设置相应的紧急需求处理流程。一般情况下，我们会在迭代周期中尽量多的去交付产品增量，但这会给紧急需求的实现造成阻碍，不妨在每个迭代中预留个5%的人日来应对。但是预留的人日使用要慎重，必须使用在真正紧急的事情上，要得到团队主要成员的认可，比如说产品主策、技术负责人、产品项目经理，甚至是产品负责人，然后才能进行需求插入。
另外，千万不要因为紧急需求的关系，去调整原有的计划，除非这个需求是重大bug修复。我们都知道，在互联网行业采用迭代方式的主要原因就是节奏和可持续性。如果随意的插入，甚至打断原有的节奏，那么对团队造成的影响是不可估量的。
3.资源使用困难
资源问题其实是一个常见问题，只是在互联网交付项目的背景中更加突出了这一点。与传统交付项目相比，互联网交付项目最重要的一个特点是用做产品的方法来做项目，所以团队都是一个，所有项目的需求都由这个团队负责实现。在这个背景下，让团队前往客户现场基本不可能，往往会出现部分资源不足的情况，影响整个项目的交付。
资源问题是一个千古难题，到目前为止，还没有看到哪一个团队是一个资源充足的情况。在笔者看来，主要有等待、借用资源和外包三种方法。
等待
就是在资源空闲下来之后在进行工作安排，这也是我们需求排序的主要原因，但是对于交付项目，还要注意及时与客户沟通，并获得认同，要把对外沟通做在前面。
临时借用资源
是在面对紧急需求的场景下，比如很快要到平台向媒体公布的时间了，等待无法满足要求，通过上层从兄弟团队临时借调资源的方式。一方面，兄弟团队对自己团队的产品比较熟悉，能够很快入手解决问题，解决燃眉之急；另一方面，如果发现团队在频繁的借用资源，那么便意味着团队规模无法支持现有的业务，需要上层申请扩张团队。
外包
分为人力外部和项目外包两种方式，各有优劣，但是核心还是要控制质量、时间和成本。此外，除非是深度合作的外包方，否则这种方式一般不适合于紧急情况，外包方在前期的学习成本太大，往往不是项目可以承受的。
不论采用哪种方法，其实都是要有风险意识，提前做好安排和沟通，根据实际场景在第一时间进行应对。
最后，在笔者看来，互联网交付项目还刚刚起步，还在逐步前行的路上，没有达到成熟的地步。希望借着这篇文章和大家共同探讨相关话题，让优秀的互联网产品可以更好的走到企业中，而不是在阵阵的痛楚中走向消亡。
本文作者：
