开发2B产品要注意哪些问题?

别想歪了,这里的“2B”产品是指“企业级产品”——为企业用户的各种业务提供解决方案而开发的产品,与其对应的则是针对大众消费者开发的产品(2C产品,就是微博、微信这些)。最常见的2B产品包括CRM、ERP、OA等。我在天拓期间负责策划的Ework就是一个企业内部CRM系统。这是本人首次接触企业级产品的策划和开发,感觉这里面有着一些与消费者产品截然不同的逻辑和原则。我先引用一段自己在10月份写的工作报告:

首先,Ework是一个初始就设计得十分庞大的产品,经历过两年时间和多个团队的共同策划和开发,在交到我的手上时已经积累了大量问题,现总结几个最严重的如下:

一,公司内部对产品的需求得不到有效的整理和规划

这一块是由一个运营专员在负责,但是之前两年的各种需求都无法被有效地整合到产品中,导致产品功能和结构异常混乱,无论哪个部门提出需求都被立即放到产品上实现,这样的结果是产品既想迎合每个人的需要,但却令到每个人都不满意。

二,项目管理混乱

所有IT产品都需要项目管理,对于业务逻辑较简单的产品,这个职责可以交给产品经理。但是对于类似于Ework这样无论业务逻辑还是功能结构都比较复杂的、开发团队成员超过10人的产品,则一定需要专职的项目经理来负责实施。程序员们天生不合适担任沟通工作,设计师和产品经理也需要花费较多精力在产品设计上,面对复杂而庞大的项目,都不可能也不应该指望他们能身兼二职。否则项目必然会陷入《人月神话》中所描述的典型的“IT项目焦油坑”中。事实上,前几年的开发情况已经展现出这一点了。

三,团队对Ework系统理解严重不足

几年的产品开发经验告诉我:产品的用户其实才是产品经理最好的朋友。因为只有天天使用产品的用户才拥有最大发言权,他们了解产品的每个优点和缺点,他们有大量想法希望能告诉开发者,他们倾注了很多热情和时间在与产品打交道。因此,我一直认为只有对产品的业务流程熟悉才能更好地去优化产品。但是Ework团队除了一个运营专员和部门经理外,全部是入职不超过一季度的新人,他们对公司的各种业务流程,尤其是销售业务流程的理解程度还相当欠缺,因此由他们去负责优化Ework甚至重构产品是必须付出一定代价的。

四,公司最高层对Ework的定位及目标指引不清晰

部门经理曾经清楚地描画出Ework的目标和未来定位,这是很重要也做得很正确的一件事,只有团队都明确了前进的方向,才会狠下一条心勇往直前。但是,公司的最高层从未对Ework做过表态,最高层不发言有几个弊端:1,新人团队感觉不受重视;2,结合过去几年Ework的几次失败的开发会令人心生疑虑;3,信心不足(尤其很多成员的工作经验不长,在自我调节能力不足下更容易产生放弃的念头)。

除了上述四大问题外,还有很多局部性的战术性的问题存在,但是我认为其产生根源都是上述四点,因此不再展开。现在我们找到Ework项目所面临的几个核心问题了,下一步就是一个个解决它们,我给出的解决方法如下:

一,确立Ework项目组对Ework的最终决策权

Ework项目组的地位给我感觉就是一个临时搭配的短期工作组,但这个项目是一个长期性的,整个项目组应该是对Ework产品负起全部责任的“部门”。因此,目前Ework小组在没有对产品的最终决策权的情况下,就不得不疲于奔命地应付各种需求,不断修改功能、不断增减字段……简单地说:不断做各种无用功,对产品的优化迭代毫无价值。合规部和其他部门的主管必须认识到,他们当然有权利提出需求,但他们没有权利在自己不在行的领域做决策。Ework项目组要杜绝外行领导内行的情况。

二,增设一位专职的有经验的IT项目经理

目前,部门经理是一个接近于Ework项目经理的角色,但是我们要看到对他而言,其最主要的精力还是放在了对整个工具研发中心的管理工作上,而且Topsem的销售和运营工作也占去了他很大一部分工作时间,因此他不可能很好地监控Ework项目的各项开发工作是必然的。而我本身更擅长产品的策划和运营,虽然之前也统筹管理过几个IT项目,但那都是业务逻辑较为简单的互联网产品,面对庞大复杂的CRM+OA项目开发,也是经验不足。因此,最好的解决方法是从内部选一名对Ework熟悉的有经验的项目经理来全权负责Ework项目的未来开发工作。我不鼓励从外部招聘,因为哪怕再高手的项目经理,他也需要时间来适应公司和熟悉Ework。此外,鉴于我已经完成了第一阶段的产品策划和交互方案,在第二第三阶段不设产品经理一职也是可以的,因此可以做到在不改变预算的前提下去掉产品经理、增设项目经理。

三,将运营专员的角色明确为Ework2.0开发顾问,同时从合规部抽调一名同事常驻Ework项目组

运营专员现在的主要工作是处理Ework1.0有关的各种投诉和吐槽,其实就是一个客服,我觉得这个工作安排并没有发挥他的最大价值。他的最大价值体现在:他是团队内唯一一个从头到尾参与了Ework上一次开发过程的人,他对Ework的熟悉和理解能够大大提高团队其他成员的开发效率。与其将他的主要精力放在维护一个即将被淘汰的系统上,倒不如更多地分配到对新系统的开发工作上来。另一方面,除了运营专员,对整个Ework开发最熟悉的莫过于合规部了,他们如能抽调一人到Ework项目组,每天坐在C区这里与A专员一同担任顾问角色,面对面与开发同学沟通,这样便能更好地解决“开发者不懂用户需求”这个问题。

四,高层需要就Ework的未来向全体员工作表态

个人觉得这个解决办法的成本其实是四个方法中最低的也是最容易实现的,高层代表只需要发个邮件或做个演讲就能彻底打消开发团队的很多疑虑和迷惘想法,在大大提振团队士气的同时,也激发出了每个人的潜能。这种表态绝不是做做样子,而是实实在在的强心针。

上面列出的问题和解决方法是我在10月份提出的,幸运的是高层都一一采纳了这些建议,Ework的开发进度从而得到了最大保证,最终能够实现在Q4结束时进行内测的预期目标。现在,我已经离职,回头看看这个过程,总结出的针对企业级产品开发的经验如下:

一,产品的开发团队必须熟悉其开发对象的业务。例如你要做一个CRM,你就必须熟悉用户销售的流程和规则,最好能做一段时间的一线销售再回来策划和开发。

二,需求必须明确且简洁。要杜绝那种由几十份文档组成的庞大需求库,同时要规定需求提出方可以提需求但不能有求必应,整个需求必须统筹规划。

三,产品架构必须设计成能够根据业务逻辑灵活改变的开放式架构。用户业务流程和规则可能会频繁改变,因此一个优秀的2B产品的架构绝对不是僵化的。

四,敏捷开发模式在这里不一定凑效。Scrum可能更适应灵活的、业务逻辑较简单的2C产品。而对2B产品而言,业务流程和规则一般都是比较确定的,不需要频繁去“测试”用户的需求并“及时”优化迭代。一句话概括就是:2B产品并不需要那么频繁的更迭。我觉得更好的做法是把Scrum和瀑布开发结合起来操作。

我认为2B产品对需求的熟悉程度和项目管理的要求更严格于2C产品,不夸张地说,大多数2B产品的失败是由这两方面衍生出来的。这一点值得留意。

发布在TMT那些事 已有标签 , , , , . 将该链接存入书签发表评论或留个互链:互链地址.