用“系统思考”看破产品开发团队与项目实施团队的相爱相杀

0 评论 2529 浏览 12 收藏 11 分钟

编辑导语:在企业的项目合作中,产品开发团队跟项目实施团队很容易起冲突,产品和开发的角度有一定的差别,所以合作起来经常“相爱相杀”;本文作者分享了这一观点以及解决办法,我们一起来看一下。

让我们从一段充满火药味儿的假想对话开始今天的讨论——

项目实施团队指责:你们根本不懂业务需求!这点功能都支持不了!

产品开发团队反驳:你们根本不懂产品思维!你那需求没有产品意义!

一、话题背景

2B(To Business)产品,会因行业不同、企业规模不同、甚至是企业文化不同,对同一个核心需求点,需求的实现方式有自各独特的诉求,也就是我们经常说的“个性化需求”。

或许有人会说,作为产品经理不应该停留在表层功能层面,而应该挖掘底层需求,运用逻辑能力深层次的抽象,找到一种普适的功能实现方式。

我不否认这种观点,但同时也要向现实低头;以“协同类”2B产品来说,协同中很重要的一个因素是参与协同的“人”,想要帮助这些人提高效率,“让工具适应人”比“让人适应工具”更容易。

说点更现实的,当你的客户说“你这产品不好用”,而你又无法说服客户改变时(认清一个现实,就算我们的客户是高层管理者,有些事也不是他能改变的),你是放弃成交,还是为Ta改变?

跨越鸿沟理论告诉我们,一款产品,如果一开始就定位于主流大众用户,那它大概率什么用户也满足不了;在B端是同样的道理,如果一开始就想让自己的产品适应所有企业,那它大概率是蹩脚的、难用的。

所以,在2B产品中,过去常见的一种模式是,软件建设厂商的产品团队开发好产品后,先到甲方客户现场去部署,然后根据客户的个性化需求,由项目实施团队提供一定的定制化服务;虽然SaaS正对这种模式产生冲击,但在大客户中这种模式仍普遍存在;而我们今天要讨论的话题“产品与项目的相爱相杀”,正是在这种背景下发生的。

二、场景描述

要解决问题,我们首先要理解为什么问题会出现,我举一些纯属虚构的场景,来帮助我们更好的理解。

1. 场景一:不划算

某公司总部产品部门开发了个产品叫“宅男”,该产品新拿下了某地的一个大客户叫“白富美”。

此时,项目团队评估了一下大客户的需求和公司的产品,发现“宅男”离“白富美”的需求偏差很大;而改造“宅男”花的成本,比完全新开发成本还高!而且,改造“宅男”时还受到些限制,不能完全满足“白富美”的需求。

此时,你愿意花更多的钱,用一个更难用的产品吗?

2. 场景二:不主动不负责

继续说产品部门的“宅男”产品,“宅男”不主动去找各项目组了解客户真实需求,不主动给各项目组培训自己的优点,不主动告知项目组自己未来的改造计划;而当项目组想主动了解“宅男”时,却遭遇难以跨越的部门墙,产品部门推说要材料要找运营人员,运营人员说要去公司OA提工单,好不容易找到了这个工单,却发现工单提交就报错!然后继续让找OA的IT人员。

此时,大概项目组心里只会想,MMP,老子不陪你玩了!

3. 场景三:贵慢差

还继续拿“宅男”说话,总部领导要求,项目组必须用公司自有产品二次开发。

此时,项目组发现产品本身非常复杂,想自行改造成本太高了,于是,想让产品部支撑一下;但产品部门要求提工单,换句话说就是“拿钱办事”,项目组5个人辛苦一年才5万的奖金池,你产品部改一个功能就要拿走2万!没办法,客户急着要满足需求,咬牙给钱吧;结果,你会发现,产品部会告诉你他们需求很多,你等着排期吧!

然后,你辛苦安抚住了客户耐心等需求实现,产品部却交付给了你“产品化”的功能,你还得继续花时间改造才能满足需求!

三、问题分析

产品开发团队与项目实施团队的相爱源于“项目能给产品钱,产品能给项目省时间”,而相杀也源于相似的原因“项目占用产品太多的时间,产品没能帮项目省钱省时间”。

但这个问题,并不是这么简单,我们来用“系统思考”工具尝试探索问题背后的模式。

用“系统思考”看破产品开发团队与项目实施团队的相爱相杀

系统思考工具是什么我不细说了,我们只需要知道“+”号是正相关,“-”号是负相关即可;关于本系统思考图也不细说,只看核心逻辑节点;先从整个系统中最关注的点“利润”来开始看,影响利润最核心的2个点是“ROI期望”和“项目新签与续约”。

我们从ROI期望这条路径出发,看看会发生什么——企业追求利润,于是高管要求提升ROI,这本身是没有错的;但提升ROI势必会压缩产品和项目的成本投入,项目投入减少会直接造成项目团队交付能力降低,项目交付能力降低会造成项目交付速度降低;而交付速度降低会造成客户满意度降低,客户满意度降低造成项目续签减少,进行影响到整体收入和利润。

看到这个有趣的逻辑链了吗?高管想要增加利润,但结果却可能从其他方面造成利润下降;同样,在产品开发团队投入减少,也会最终影响利润,只是这个因果传递过程是有“时间差”的;看懂“时差”,很难。

在整个模式中,处于核心地位的除了“ROI期望”,就是产品本身能力了,即“产品通用性及开放性”;对于ROI,我们可以看出来,项目团队上的投入见效快、却不可持续;而在产品团队上的投入见效慢、却可持续。

如何平衡在项目、产品上的投入,如何确定合理的ROI,这是高管要决策的一个核心问题。对于“产品通用性及开放性”,有2个核心因素,一个是对产品开发团队的成本投入,另一个是产品团队对业务的洞察力;而产品团队对业务洞察力的一个基础是对业务的熟悉程度,这个因素相对容易,接下来我们主要从这个角度探索解决方案。

四、解决方案

我们要解决的问题是“如何让产品开发团队更懂业务”,在大客户的场景中即,“如何让产品与项目不脱节”;解决这个问题,你可以说我们要招优秀的人、积极主动的人,也可以说我们多组织一些沟通会,方法总比问题多;笔者再补充一种解决方案,这种方案的核心是“利益平衡”,在执行上来看即“组织设计”。

从产品开发团队规模角度,可以将组织形式分为三种模式,依次为大产品团队、中产品团队和小产品团队。

三种模式本身各有优缺,笔者从特征、原理、协作方式、应用现状和存在问题5个角度对三者进行了对比,具体如下图所示:

用“系统思考”看破产品开发团队与项目实施团队的相爱相杀

其中,对于第三种模式笔者还是很期待的,因为它可以适应笔者在B端产品中的另外一种思想,即“B端产品要适应客户自身成熟度”。

最后总结一下,以上三种模式各有优缺,具体选择哪种模式,还是要视自身以及客户的场景而定;而且,以上三种模式并不是必选其一,也可以视具体场景同时混合采用;比如,同一个产品,对大客户就采用中产品模式,而中小客户则采用大产品模式甚至SaaS模式。

 

本文由 @李晓杰 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!