项目管理实践常见困境（十四）

1. 关于产品，您是支持以业务驱动定义产品联动科技测；还是支持科技侧定义产品支持业务？

01

—

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

项目场景：

一位学友在讨论中提到，在其服务的企业有个基本问题一直没有解决，如何在企业现有服务中定义产品。产品是业务视角的服务的组合（Operation Value Stream）,与科技侧系统/功能/服务的映射与联动关系，目前其企业由于驱动不了业务侧，就定义了一个IT产品线/IT产品的概念，基本还是以实际业务为主线把软件的系统/功能/服务分了不同篮子，但落地起来很繁琐且体现不出价值来，基本投入了一年后续就放缓了，内部初步判断是没有市场对产品的诉求形成驱动力push科技侧，科技自己强推科技产品往往倾向于架构层面的搭积木，爱咋搭咋搭，从市场产生价值来评价是无关痛痒的。

问题：

关于产品，您是支持以业务驱动定义产品联动科技测；还是支持科技侧定义产品支持业务？

反馈：

针对业务还是科技驱动产品的问题，选哪个都可以，主要还是得看公司环境。

无论（业务或科技）哪边作为驱动，都是公司战略落的事儿（这里先不用区分产品战略是自上而下还是自下而上），推不动通常是改变了现有的运营模式，而遇到了阻力。

在这里先可以看作是一个变革。

面对变革，从另一个维度去看公司整体运营，至少要分成两侧，业务运营和创变。

业务运营即原有的业务和科技互动模式，在公司整体运营中肩负着主要的收入来源。

创变即基于公司战略对业务和科技互动模式要做出的改变和调整。这样的创变在公司整体运营中的规模会影响变革的烈度。烈度越大通常阻力也就越大，而且需要更大规模的共识和更强的推动力。

面对做这样的变革，一是发起方的选择对内驱力影响极大，特别是在公司组织还没有很好的适应性的时候；二是适当的业务尝试比例（类似试点）一定程度上降低烈度可能是好的尝试。

关于发起方的选择。

如果公司有极强的科技驱动战略，无论是源于生存的压力还是自上而下强烈且持续的信心，那么科技驱动业务是可以的。这里在启动变革前，哪怕是小规模的尝试，愿景的沟通可能比低头做事儿要重要得多。

一般情况下，从流程、信息（注意区别于技术）、知识等这些要素切入作为驱动可能会阻力小一些。而这些要素和业务紧密相连，这里就尽量要去说服业务部门愿意尝试的那部分作为发起方去做试点，内部政策上配合一些对原有业务评价的平衡。

关于尝试的范围。

都说小范围试点争取尽快的收益。但这里更应该注意的是对收益的评价和转化周期要有合理的预期，所以评价的时间和谁来评价有时比评价什么更重要也更容易忽略。

另外，以上的变革实现了，如果公司的文化和适应性环境较好，大规模推到公司组织时，也要注意收益的转化周期。

小结一下，针对业务还是科技驱动产品的问题，选哪个都可以。还是得看公司环境，作出决策后作为变革来推动这件事。要综合自己公司的情况看各个运营要素在变革前后的状态变化，选择合适的发起方作为持续有信心的驱动。对起始驱动到正常运转的周期要有合理的预期，且明确地沟通达成共识。