PART.04

双产品经理的项目研发

电商物流企业的系统搭建，从构想到实现，中间面临许多的问题，这其中就有在开发过程中的“翻译”问题。

翻译问题之所以非常重要，是因为一旦业务部门和研发部门双方存在沟通障碍，翻译的效果就会大打折扣，甚至直接翻译错误，开发出来的系统就不能解决企业实际问题，系统研发可能就是竹篮打水一场空，所以系统需求和系统研发之间的翻译一定要流畅。

往期链接：

(实战)物流企业如何建设信息系统系列谈（一）“物流企业信息系统建设”系列谈（二）

“物流企业信息系统建设”系列谈（三）

在系统研发时，我们可以采用“分配法”。这种方法本身是一种资源的分配，如果把时间看作一个整体，这其中40%的时间就用于需求，30%用于研发， 30%用于测试和上线。这一分配法也说明了需求的重要性。面对系统需求的挖掘、处理和创新，应该怎么做呢？笔者认为，采用双产品经理制是一种科学有效的办法。双产品经理，是指需求经理和研发经理。只有需求方内部的人才了解自己的业务和流程需求，所以在系统研发时，两位产品经理中一定要有一方来自需求。公司在做系统研发时，若是只有一个产品经理跟进开发系统，产品经理对业务的真正需求不是很了解，只是站在研发的角度来进行系统设计，势必会因角度不同而产生很多问题。《三国志·吴志·周瑜传》曾说：“不习水土，必生疾病。”水土不服的情况同样会发生在产品经理的身上。不是企业内部熟悉业务的人来提供需求，会使整个研发过程产生很多的不适用。所以需要从需求方中抽出一个人来，这个人必须对公司的需求和要求有一个非常详尽的了解，并且能够围绕系统要实现的预期功能提出构想方案，并将这个方案的各方面业务需求与研发经理沟通清楚，直到研发经理非常清楚业务部门的需求为止，从而使得双方的翻译过程流畅有序地进行。那为什么是双产品经理制呢？这就得从现今很多企业的现实情况来看。现在许多企业的研发其实只有一个产品经理，这个产品经理大多都是从研发部门出来，自己组建团队，然后再带着团队，去找系统使用部门提需求，以此确定系统开发的需求，做出系统研发的流程框架图，从而对系统进行管理、测试和上线。但是，这样很容易出现问题。这时候，提需求的人往往是从业务层面去提要求，是按照系统要实现的效果去理解的。比如，在物流系统里，从某个目的地到某个目的地的线路，如果发生异常情况，我们在管理上要求它及时报警。这从业务层面来说是很好理解的。比如一个包裹，某个时间某个批次有一个合理的范围，中间延迟一旦超出合理范围，系统里就会或推送邮件报警，或调动使用报警，或闪烁提示报警等。但是研发的人员却并不懂得业务层面的逻辑。此时，研发部门的技术人员若是从技术的角度出发，去找实现报警的逻辑，那么就无法理解业务经理的设计。业务部门要的是结果，即凡是车辆不正常，系统就得给提示。但系统研发人员在研发时不熟悉业务流程，就不知道怎么去实现。如果他们按照自己的想法去研发，不光会导致研发效率低，研发出来的产品也可能不实用。系统起初在设计的时候，从大框架看是没有问题的，但研发后才发现，各种细节需要不断修修补补，且修订测试的很多逻辑混乱不清。所以，研发系统一定要有两方面的人来保驾护航，一方面就是需求经理，而另一方面就是研发经理。需求经理做的就是系统所有需求的梳理，从业务的角度把所有需求想要实现的功能、整个运营过程，以及需要输出什么报表都描述清楚，而需求之外的系统设计，就不用需求经理去考虑了。研发经理需要做些什么呢？其实也很简单，只需要考虑如何将需求经理提出的需求完整地、如实地转化为研发的需求即可。这两种需求是截然不同的，核心就是从业务需求到产品需求的翻译过程。从执行上来说，只需要由两个人主导就能完成。业务经理梳理业务需求，研发经理将业务需求转化为系统需求。只有准确地将业务需求翻译为系统需求，系统功能才能满足业务需要。可见，系统研发过程中，一定要认识到需求经理的重要性，双产品经理制的作用不可忽视。要从宏观战略出发，产品经理与需求经理相互配合、协作，不要忽视任何一方。年，PRTM咨询公司提出了产品开发流程的PACE这一概念。通过多年的发展与完善，PACE已经成为产品开发事实上的主要的流程参考模式。这个模式提到要建立跨职能的核心小组。这样做也是为了解决产品需求确定的沟通、协调、配合等问题，和双产品经理论的想法有异曲同工之处。

作者：张立民，先后在中国邮*、顺丰速递、京东集团等国内物流领域的代表性企业任职30余年。


转载请注明地址:http://www.dazaoa.com/dzcf/9526.html