X公司是国内知名软件服务公司，一直致力于以技术的手段解决业务问题，且一直期望以产品化的打法来解决项目交付的问题。本文以X公司的项目交付过程为例，介绍下ToB软件服务公司在产品化、项目交付中遇到的问题。
组织架构
上图是X公司的组织架构：
- 市场部：负责获客和关系维护等。
- 产品研发部：分为产品部和研发部，按照产品线来组织；产品经理负责具体产品的规划等，交付产品经理负责项目交付中的配合等。
- 基础研发部：为X公司提供大中台的基础设施建设，主要包含运维、中间件和业务中间件等。
- 架构组：负责公司整体技术架构设计，以及具体项目的架构设计。
- PMO：项目经理部门，对项目生命周期负责。
- 实施部：KA客户项目交付的实施部门，分交付产品经理和技术团队，交付产品经理不足时，由后方产品部交付产品经理补上。
项目生命周期
上图是一个典型的项目交付流程，贯穿始终的是市场部和客户接洽的人员(后续称销售)，立项后主负责为项目经理。项目经理负责调动后方资源，完成项目交付，资源专人专用。比较重要的铁三角是交付产品经理、项目经理和销售，在需求把控上需要铁三角配合，一旦需求变更把控不住，大概率会造成项目延期，甚至项目亏损。
在实际项目生命周期中，存在以下问题：
- 各部门无法专人专用，资源大多处于多并发状态。项目经理大部分精力花在协调资源中，内部协作推动困难。各部门负责人多线并进，各有各的KPI，权责不统一。
- 架构组人数不足以支撑所有项目，部分项目架构设计人员经验不足，甚至是交付技术团队出架构设计，导致项目结果不如预期，客户满意度差。
- 无法准确估计项目成本，因此投入资源需要填报项目工时，工时系统自动计算项目成本。
- 实施团队资源不足，产品部资源需要支持项目，最后产品研发资源不足。造成产品经理无法在产品上形成有效业务积累，产品研发团队疲于项目交付，标准化产品迭代缓慢。客户对产品的业务理解深度甚至超过了产品经理，客户满意度差。
- 一线人员感觉是工具人，人员流动率高。
- 项目时间紧，产品经理和交付产品经理疲于奔命，缺乏有效地沟通、整体产品规划和落地，存在重复建设、反复造轮子等问题。从项目中去孵化产品的战略无法有效落地。
- 迫于营收压力，基础研发部的资源也会投入到项目中，影响迭代。
根因分析
- X公司管理层有产品化的战略意图，但是在业绩的压力下，姿势变形，在资本金充足、现金流不足的前提下，缩编后将大部分资源投入了项目，导致在战略方向上投入不足。
- 战略方向上意图以大中台的技术解决方案解决交付效率的问题，出发点没问题；但是在大中台系统群没有得到验证之前，便进行全公司切换，从而导致在开飞机的过程中需要修引擎，但是修理工又被派去干别的，加大了公司的困难。反思：如果能以小范围试点，逐步打磨完善大中台产品，再逐步全面铺开，局面就不会那么被动。
- 产品经理行业经验不足，期望以招聘的方式来弥补短板，但是在人员培养上投入不足，大多产品经理处于超负荷状态，无法形成足够沉淀且流失率高。
- 大中台缺乏有效统一的产品规划，产品经理在此方向上投入精力不足且无法得到有效地改善。
- 权责不清晰，项目经理、各部、各Team负责人对多项事项负责，资源争抢严重，无法形成有效地合力。
最终结果：标化产品久久不能如人意，项目式交付大行其道，客户满意度不高。
如何做产品化的思考
- 产品研发资源投入的问题：交付团队和产品团队边界应清晰，资源不足时，产品研发团队投入在交付项目中的资源应有个界限。如果想以项目来孵化产品，应由产品研发团队来完成项目交付，但产品研发团队同时应只承接一个项目。一句话，始终应保持在产品研发上一定的资源投入，这是未来制胜的关键。
- 架构组和资深产品经理应同时参与交付和产品研发。产品团队只关注产品研发，很容易带来的一个问题是前后线需求脱节，产品研发可能存在自嗨的可能性。所以作为产品设计者的架构师和资深产品经理能否保持在客户侧敏感的“神经”就至关重要，这两个角色应对交付侧的技术架构和产品方案负责。这里，如何保障架构师和产品经理在产品研发上时间的投入值得思索，架构组、产品组内部之间的分工协作会是关键。
- 项目式的ROI（投入产出比）始终是有限的，对于大中台等战略实际产生的效能提升，管理层应设计并关注一些核心指标的变化，以针对性进行产研侧和交付侧的协作改进。
- 若从组织架构上考虑，产品研发独立子公司或者BU是否会更权责清晰。
- 项目经理应有项目资源的完全的指挥权，特别是涉及产品线众多的项目，同时推进十多个部门，对于项目经理的要求太高，不具备复制性。从组织上去保障会更有具落地性。
关注微信
