如何把定制化的项目,做成标准产品?

产品微言 第  169  期


目前公司接了好几个定制化的项目,每个项目时间比较短,客户的需求还比较个性化,公司希望能逐渐把这些项目做成公司的标准产品。

那么如何用产品思维开发这几个项目并形成一个产品呢?

文  |  产品专栏作家  杜松

面向企业的2B市场持续火热,是时势所趋,也是互联网红利渐退的必然结果,人力成本的增长和移动互联网的快速发展为2B市场的发展提供了生存的土壤,企业的运营效率必须要大幅提升才具有可持续性,2B的产品或者说2B的产品经理,也是越发火热和吃香。

但摆在眼前的事实是,定制化的需求,仍然成为难以逾越的一道屏障。这个问题不是今天才发生,而是伴随着整个软件开发技术发展过程。

任何2B的产品,不管是什么形式的架构设计和渠道通道,触达企业客户的时候,必然出现如何解决企业客户的管理模式差异化问题,和企业发展进程差异化的问题。

所以,我们常见的问题是:

需求太多,明天就要上线,加班赶点是家常便饭;

BUG太多,各个项目都需要支持,研发成了客服;

产品很难用,耗时很长客户还不满意;

实施周期很长,回款总是很慢;

不断地需求变更和“个性化”要求以后,问题越来越多,沟通也越来越快困难,由于急于上线(换句话说,尽快脱离困境),项目经常性无法按照正规流程来走,很多系统都是不停地打补丁修复各种“噩梦”的bug,雪上加霜的是公司还需要控制成本......不能再招人了,要增效.......

面向企业的2B产品,是否真的有途径做成标准化的产品?

答案是肯定的,并且有足够多的样本可以研究和学习,只是会比较曲折。

01、对 需求 说 “NO”

在进行“定制项目 产品化”的过程中,我们首要问一个问题。

假设,你是公司的业务负责人,现在有三个客户,五个订单的许诺只等着你签,催着你交付,甚至还有海外的客户表达极浓厚的兴趣,你将如何决策?

应该说,在绝大多数情况下,这都是公司面临的极大机遇,特别是企业处于创业阶段,这是很难拒绝的市场机会,特别是“大单”。

这是两难的博弈。坚持冷静的市场驱动,可能面临错失机会导致公司业务下滑的情况。而如何是激进的订单机会主义驱动,面对各种迥异的管理风格,形形色色的业务流程,就可能导致项目扎堆,交付困难,疲乏应付进而引发一系列的问题。

因为一旦当你试图去满足各种独特的需求,为了赶进度,代码的维护性会越来越差,文档基本上上也越来越失真,很多时候因为差异性太大,现有的产品功能根本无法满足需求,改动成本非常大,甚至只能重新开发。

但为了业绩,只好做了再说。久而久之,整个公司完全陷入定制化项目的漩涡中。所谓的产品化,自然就凉了。

还有一种情况是,你的调研数据和行业预测显示某个领域正呈现巨大的需求缺口,市场规模很大,如果能在足够早的时间抢占先机卡住位置,则意味着进入一个很大空间的市场。

你是公司负责人,你是否会在现有的团队里面,调配资源开发新的产品?

想象一下当年凡客的SKU战略。所有的出发点都是好的,但因为各方面的原因,导致一系列的问题。

2B的产品,其实最担忧的是就缺乏冷静的分析,就一头扎进去。不考虑自身的状况和特长,有项目就做,就钱就赚,无异于饮鸩止渴。当所有项目都是高优先级项目时,也就没有所谓的优先级了,最后都变成了“随缘”了。

2B产品的标准化问题,或者说定制项目的产品化问题,本质上不仅仅是技术层面的实现问题,而更多的是企业发展过程中的综合性问题,想要解决问题,首先要改变的是企业经营的策略,改变一切以订单驱动的方式,强调以市场为中心来推动产品的发展。

改变以销售为中心的运作方式,是要调整整个企业的组织架构和文化,需要协调好销售、市场、产品和研发的利益冲突,调整相关人员的工作重心。

而改变思维方式和工作的习惯,通常都是最难的。

02、对 销售 说 “NO”

有一话叫做“离钱越近的,越有话语权”。

在项目型的公司,销售部门的话语权是最大的,因为他们是利润中心,而研发部门成为了成本中心。在过去的卖方市场,企业的研发部门远离市场仅负责交付,而不关注体验性问题,他们只能按照销售传递的信息进行产品开发,而无法对销售说 “NO”。

但这种时代早已远去。

今天的产品开发,研发部门必须深入一线,真实的了解用户,理解业务,通过过去销售作为信息传递的方式无法满足客户的需要,因此在整个的企业架构里面,他们早已不再只是充当幕后的角色,还是登上前台,深入现场研究和解决问题。

整个研发队伍的不断扩大,涉及到从需求分析,产品定义,项目管理,质量保证,过程改进等活动,需要逐步建立专业化的团队和管理模式,才能适应不断加剧的竞争变化。而传统单一的职能式组织架构,在这方面往往显得被动。

以市场为中心的产品策略,强调所有产品基于用户需求进行开发,并且把每一个新产品的开发视为企业一项投资决策来推进,把正确定义产品概念、市场需求作为流程的第一步,使产品的立项更准确,组织专业资源来进行产品的设计、开发和测试等一系列的工作。

这就是真正的“产品经理制”的组织方式,产品经理需要对产品的盈利性负责,而不只是负责把销售和客户要求的产品功能做出来。他们需要建立起一整套的高效产品开发机制,快速的响应客户的需要(不再是销售的要求),整个产品的开发过程,必须是以结构化的工作流程的方式开展,并确保流程的有序推进,和产品的上市质量。

无法忽视的一个问题是,变革过去以销售驱动的项目制,必须同步优化组织的考核方式和激励措施,解决不好这个问题,产品化将是一句空话。

03、比 客户 更专业

项目制的弊端,除了引发各种管理问题以外,还有一个显著的特征就是:由于项目的临时性和团队的松散性,项目团队往往不能是客户说啥就做啥,他们往往缺乏足够的专业来引导客户需求,也没有足够的时间来和客户共同探索新的解决方案。

很多公司都是做了很多项目,但行业知识仍然薄弱,原因就是项目制的过程中及其容易忽视业务知识的积累——赶工的后遗症,随着人员的流失,往往后面接受的人,根本搞不清之前的业务逻辑和技术方案,一旦开始新项目,重构成了口头禅。

想要真正实现产品化,就必须让自己成为技术专业和行业专家。

产品团队需要解决的一个顽疾,就是如何能把跳出客户需求本身来思考问题,设计产品架构和技术架构,而不只是把所有的客户需求堆砌为一个功能集合。

看上去要的东西都有,但体现不出任何的行业先进性和产品的独特性。

建立领先的行业领域知识和一支懂技术,懂业务的团队,是2B产品化的成功保障,必须要有人进行专业的梳理和管理,逐渐形成长期的培训和学习机制。

本文不解决任何产品技术和设计上的问题,但强调的是在产品架构设计上的领先性。2B产品化,尽管其目的是摆脱定制化的陷阱。但要求的是深入用户的业务现场,邀请客户特别行业性大客户的深度参与。

2B的产品化,必须要能保证产品符合客户和用户的真实需求,不仅仅是在需求调研之初和产品验收之时才去接触客户,而是在产品的产品生命周期中与客户紧密互动,持续性的与客户进行业务的交流和凡客,并对产品的阶段性版本邀请客户进行评估和测试,不断提升产品的价值体现和使用体验。

你可能感兴趣的:(如何把定制化的项目,做成标准产品?)