如果没有找到双方合作的最大的问题症结,结局注定肯定一拍两散

2019-03-06 14:24:35来源:人人都是产品经理  

转型到产品后,做了好几个项目,主要以to B定制产品为主,从这几个项目的复盘来看,我对定制产品有了新的定义标准。就是客户觉得你帮他解决了问题,并开心的为之愿意付费,还能进行扩展的进行下一步合作。

产品做失败了?谁之过?

技术经理不行,没有把控好项目周期,没有把控好产品质量?是产品经理不行,没有挖掘好用户的实际需求,做出来的东西,用户不买账,需求变更一茬接一茬?

如果没有找到双方合作的最大的问题症结,结局注定肯定一拍两散,谁也不买账。

举例一个失败的项目,靠老板的关系拿的实验室的一个项目,给一个实验室的生产体系做一套内部管理系统,流程管理、业务逻辑都有一定的门槛。说白了,就是我们没有接触过的业务。

一开始我们做toB的系统时候,既然是定制产品,而且他们业务员比我们懂,那我们做的岂不就是既定的需求,只要他们说什么,我们做什么就行了?在各种需求对接的时候,业务方通常会直接说你给我一个什么什么功能,我们按他说的做,不就已经满足需求了?

接下来,跟传统做项目的方式一样,完整的做系统流程我们都照做了,也有交付验收,那到底问题出在哪里,客户把一期的费用付后,再也不想付二期的钱了,迫使我们不得不关闭这个项目。

复盘下过程问题:

一开始,我们做需求,对接的都是一线人员,最了解业务的人,应该是最懂业务逻辑的,侃侃而谈,我要一个什么明确的功能。很多时候,我们因为甲方太强势,依赖于甲方业务员的最后的验收报告,傻傻的给他们做了。

实际上根本不能解决他们的实际问题,他们不知道这个业务对企业管理有哪些提升价值。他们提出来的90%的问题只是业务数据展示要清晰,方便调取他平常工作中excel中记录的数据,还有就是操作要在系统上进行,会比手工更方便一些。

产品经理会认为有些详细数据,可以放到详细里去,主页面只保留基本核心数据展示,这样保持页面整洁,而且也不用滚动条上下,左右滚动。同时不同的数据业务展示在不同的模块中,是合理的。

但是业务如果不给他做一个一下子就能看到全部数据的页面,会跟你争的面红耳赤,直接提出没有满足需求,系统不好用。他们不能理解为什么这么一个简单的功能就是不给我做。

当然业务人员很多都是只站在我的业务层面上思考问题,不一定会关注产品宏观层面的价值、业务流程的标准化、管理规范的问题等。比如:真实目的是要做一项数据统计,但提过来的需求只是某个页面加个导出功能,或者某个列表加个什么字段之类的。最后我们是每个页面都有个导出功能,也是无语了。

我们做实验室,好多平台做实验,每个平台都有自己单独的业务管理员,每个平台实验的某一个步骤也是单独的一个业务员,在单独沟通的时候,他也只会说我负责哪个步骤,就完事了。

比如:一个单独的DNA提取,提取的需求很简单,把提取数据导入进来,保存提交就完事了。他不会考虑你如果后面的其他平台的实验,提取需要区分是后面一代实验做的,还是二代实验用的。

比如:建文库失败,要重新提取,如果样本没用完,如果第一次提的数量不够,还可以再补提,剩余样本量要保存还是处理掉。这些问题也是后面慢慢后面挖掘出来的,但是耽误的周期实在是太长了。

一开始我们不了解业务,听他们讲,跟他们一个个沟通后,一个版本出来后,导致我们只能维持他们70%的情况,还有特殊30%的情况,根本没有办法满足。

但他们并不能理解做产品是有迭代的,以为产品上线和传统企业的交付一样,一次性做完形成最终版然后给他们用。反正没100%满足我们的业务,就死活不用。产品从0到1的过程我们会规划MVP,先上线基本功能并持续迭代,但他们看了会说这个怎么没有我要的什么什么功能,一定要等我们把他们要的都做完了再开始使用。

改变他们的习惯真的很难,尤其是线下操作已经成熟了,反而说我已经有办法处理这些问题了,不理解我们为什么还要去改这些功能。

尤其是他们习惯用传统excel来记录数据,安排任务的时候,打印出来审报告的时候,你让他一下子用系统,根本就不适用,还不如用excel来的方便。

最后系统上线后,评估系统竟然做了一个统计,80%操作人员不想用系统,这个数据我们自己都惊呆了。明明他们的业务逻辑至少95%我们都包含了,花了这么多时间调研,开发,都已经做成了行业的专家了,而且我们的系统已经这么复杂了,功能这么全了。为什么还要用这么low的方法工作,这个结果让我们惊呆了。

在经历了这个项目那么多业务人员的对接过后,含泪总结了下几点教训:

一、自上而下,梳理需求

多跟一线沟通,没有错,这个时间不能省,但是首先我们沟通的是高层,最好是懂互联网产品的时候。我们需要知道他们企业为什么要做这个系统,主要要解决他们企业的什么问题,现在企业最大的问题在哪里,在3-5年里,企业的发展方向是什么。

我们应该怎么做,能帮到企业解决这些问题,我们优先要解决什么问题,哪些做了后还需要扩展。懂互联网的可以节省一大部分沟通成本,甚至能描绘出具体的使用场景。

接下来一定要找部门经理对接,他们对整个部门的业务是最熟悉的,而且会有跨部门的协作。对部门业务员的整个流程,会站在整个部门的发展角度去说,这样比较全局,能清楚的描述一条完整的流水线,主要还有哪些异常情况的处理。哪个流程之间有不一致想法,他都会去协调。

最后是一线人员,慢慢跟你讲业务细节,怎么样能把提高他们的工作效率,怎么样提高他们的用户体验。改变了之前的习惯后,会得到什么好处。

当然这边一定有工作流程图。

二、走进实际业务中去,别光听他们说

别老听他们讲,甚至让他们写,谁知道他们写的就是你理解的呢。一千个人还一千个哈姆雷特呢。每个人的专业背景不一样,认知不一样,性格不一样,表达方式不一样。对于同样一个需求,我们走进他们的实际业务中去,做一次角色扮演,我是这个岗位的,我是这么做的,有没有更好的解决方法了。

只有了解他们需求的本质,然后想一种更好的方式满足他们的需求,并且可以直接告诉业务方我们方案,以及这样做的好处,相信他们不会拒绝。

了解到一定程度后,我相信产品经理一定比他们更专业,考虑的细节比他们多,简单的问题他们想到了,我们早就帮他们解决了,难缠的问题他们没有想到的,我也帮他想到了,还帮他想到了一个好的解决方案。这样才能让他们信服。人只会听他们更厉害的人。

当然这变一定要有文档和原型图。

三、划清边界,多保持沟通

合作做一个项目,是为了共赢,甲方提高的工作效率,解决了管理问题。乙方得到了回报,并成为了这个领域的行业专家。

但是做项目立项的目的就是项目的周期,成本、预期、风险控制等,任何一项延期或者超出预期,都可能使整个项目失败。这个时候很关键,一定要通过建立本期项目目标和价值来引导用户确定项目范围,如果涉及到高层汇报,就一定要协调本公司的高层参加,通过高层对话最终确定项目范围。

除了把人管理好,最重要就是要控制需求,防止需求蔓延,引发大规模的需求变更,控不好需求已成为项目失败的关键因素。

我们做的这个项目,到后来,业务人员不断的需求变更,不断的发生需求增加,导致双方都很累。产品就成了被客户和开发人员喷的对象。当然市场是不断变化的,有可能我们在开发的时候,市场已经悄然的发生了变化。变更可以,但一定要核算成本。不然客户和技术都不会承认,那么注意这个锅就是产品的。交付一定要需要签字,才会引起重视。有这么一个形式,才会把责任落实。

标签: 双方 合作 问题 症结 结局

相关阅读

相关词

推荐阅读