随着互联网+的热潮，不少传统IT企业的项目经理都在考虑转行互联网。那么在传统IT和互联网企业做项目管理究竟有什么不同呢？我在传统IT公司和大型互联网公司分别担任过项目经理、产品经理，亲身经历过电信级产品、互联网2B、2C产品、互联网游戏等多种不同类型的项目，有些自己的体会，希望能够对有转型想法的同学有所帮助。

两类公司的不同

所谓传统IT公司和互联网公司这两个概念本身并没有严格的定义。在互联网已成为基础设施的今天，传统IT公司积极拥抱互联网，而互联网公司也在做一直由传统IT公司主导的企业级服务。本文以公司整体商业模式的核心产品形态来作为区分，暂且认为传统IT公司以传统软/硬件产品为主，主要面向企业级市场的；互联网公司以在线Saas服务为主，主要面向消费级市场。

1. 需求的稳定性

传统IT产品的客户需求是明确且稳定的。很多是先签订了合同，将白纸黑字写好的功能研发出来。而互联网产品的用户需求是模糊而变化的，用户不会提出要求，只会用脚投票。

2. 公司文化

传统IT公司流程规范较多，做产品的计划性强，质量要求高，做事情既关注结果也关注过程；互联网公司年轻化，组织架构相对相对扁平化，做产品以用户体验为中心，做事情结果导向。

思想意识的转型

思想意识的转变往往是传统IT项目经理转型互联网时首要也是最重要的事情。

1. 项目成功 VS 产品成功

产品为商业目标服务，项目为产品服务，所有项目经理都需要关心产品成功。但由于两类产品的需求稳定性不同，容易造成意识上的差异。

• 传统IT产品的客户需求明确，产品成功这个目标可以很清晰的被分解成一系列的功能以及完成这些功能对应的项目，项目成功交付，产品也就成功了。因此传统IT项目经理往往只需要关注项目成功，即项目能够按照既定计划，在规定时间内高质量的完成所有功能，产品成功就是水到渠成的。
• 互联网产品的用户需求模糊，特别在产品生命周期的最早期。满足用户需求会有多种不同的方案，需要以最小成本来验证方案，并快速迭代不断进行调整，以期望能尽快让产品达到的Product market fit。因此转型互联网需要首先认识项目成功不等于产品成功。项目必定需要根据产品的需求不断的调整计划，决不能固守着最初的计划。所以互联网项目往往采用敏捷开发，也必须拥抱变化。

2. 管理 VS 服务

由于项目成功和产品成功的差异，导致在项目经理这个角色在传统IT产品和互联网产品中的定位也变得不同。

• 在传统IT产品里，用户的需求明确且稳定，执行才是关键。项目经理是最核心的角色，主导整个项目团队。
• 而在互联网产品里，产品经理挖掘用户模糊的需求，找到最佳平衡点来满足客户需求和产品目标，是最核心的主导型角色(也有运营/市场主导型产品)，项目经理则是服务型角色。

此外，大部分情况是：

• 传统IT公司的项目经理往往是从基层研发人员做起，表现优异，工作多年后晋升的结果。这时他本身已经对业务非常了解，在公司已经积累起人脉，自然而然是项目团队的管理者。
• 互联网公司的很多项目经理是应届生(没错，应届生就叫经理:D)，不具备管理的基础，在团队的认知里也没觉得项目经理是个领导。因此项目经理需要是以服务团队的态度做事，千万不能一开始就以管理者自居，对团队其他成员指手画脚。而更多需要通过自己的专业性来建立影响力，以此获得团队成员的认可。

工作实践的调整

在项目管理技能本身，传统IT产品和互联网产品的项目经理并没有本质差别。只不过传统IT产品的需求明确，可以做长远规划，项目规模往往比互联网产品大，容易造成两类项目经理在关注的范围上的不同。

1. 关注范围：产品研发过程 VS 关注产品全链路

传统IT产品从研发到交互所涉及的团队和人员往往非常庞大，一个项目可能涉及上千人的规模，且公司文化也很讲究流程和边界，一线项目经理关注的是往往只是产品研发过程，其他职能比如销售、售前、售后、运维等往往有专门的团队负责人，进行总体协调的往往是高级别的项目集经理(program manager)或者项目总监。

互联网产品的团队规模往往就要小很多了，上百人已经是一个很大的产品团队了。一线项目经理需要关注产品全链路中涉及到的各个职能部门，包括产品设计、研发、运营、市场营销等。对多个职能的工作方式都要有足够了解，并且跨部门进行沟通协调。举个例子，市场同事在产品上线前就需要准备好相关的推广方案，对接各个推广渠道，运营同事也需要建立和用户的沟通渠道，以及确定用户反馈收集方案等等，而这些事情的落地都需要项目经理来驱动。简单来讲，互联网公司以结果导向，没有明显的职能边界，也就没有项目经理不需要关注的事情。

2. 项目计划和执行

在传统IT公司里产品经理和项目经理各司其职，产品经理负责提供产品的功能需求，项目经理负责协调到各种资源完成项目并交付版本，再由产品经理或者交付经理进行交付。因此产品管理和项目管理往往各自有各自的目标，理想的状态一切按照计划进行。当需求要变更时，需要遵循正式严格的变更流程，由需求变更委员会经过详细的评估后批准同意，方可执行变更。由于传统IT产品的功能稳定性，所以我们会在传统IT行业中看到这样的项目计划，项目需求列表功能列表→ 分解→ 工作量估算，再通过相关人员的资源日历，整理出项目进度图，最后画成一个很壮观的甘特图，里面详细的列上每一项工作的开始时间、结束时间、负责人、依赖关系等。一个项目可以规划半年到一年，甚至更久。

在互联网产品的项目管理中所有的流程都被简化了。产品试错是必要的，快速迭代成为互联网项目的必备。因此敏捷开发是互联网里比较流行的项目研发管理方式，以周期迭代的方式给用户交付价值，一轮迭代2-4周(有些产品可能一周一个迭代，比如游戏)。到目前为止我还没见到互联网产品有一个超过2个月的详细项目计划。产品经理虽然会制定长期规划，但这个规划往往是如果去验证假设的策略，并不是确定要做的事情，感兴趣的同学可以去看埃里克.莱斯的“精益创业”。此外，互联网产品变更里往往也没有严格的变更流程控制。迭代很多时候就是产品经理说要改需求，项目经理和技术负责人一合计就改了。所以互联网项目管理更像是一门艺术而非科学，边走边寻找平衡。

3. 项目质量

质量是传统IT产品里最重要的标准，是可以写进合同里的。所有的流程设计都是为了质量的保证，甚至于在项目团队外还有专门的质量经理这个角色来监控流程的执行。

互联网产品的质量实际是平衡游戏。互联网产品大都免费，在需求验证阶段，并没有太多用户，出几个bug影响也不大。而因为质量保证而降低了迭代速度，很可能会让产品错过窗口期，也就因小失大了。比如手游在研发的过程中往往是以周版本的节奏在推进，快的时候甚至可以做到日版本。一天一个版本，测试人员不可能把所有功能测一遍，肯定会有bug。但只有这样的节奏才可以让产品经理每天都能体验到最新版本的游戏，并且在不影响核心体验的基础上做用户测试。

个人感受

虽然只是个人工作的转型，但映射出来的是消费级市场和企业级市场的不同，其复杂性不是能简单说清楚的。这篇文章16年开始动笔，18年才写完。期间内行业也发生了很大的变化，过去的互联网巨头现在已经被戏称为古典互联网了。然而回归到个人本身，关键还是思想意识的转变，想清楚，愿意拥抱变化，转型也就成了。

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

题图来自 Pexels，基于 CC0 协议