漫画:程序员,你能“管理”好你的产品经理吗?

漫画:程序员,你能“管理”好你的产品经理吗?

漫画:程序员,你能“管理”好你的产品经理吗?

漫画:程序员,你能“管理”好你的产品经理吗?

一、第三选择

在工作中,你面对产品经理的各种需求变动、项目经理对关键点的 Deadline,总会有一些冲突发生。而对于事情最终执行的开发人员来说,如果这些冲突处理的不好,可能就会变成你个人的问题。

做为最终实现功能的程序员,你总不会想被贴上一个 “无法按时完成任务的开发” ,这样的标签吧?

这些问题,其实都可以借鉴第三选择的思想来解决。《第三选择》是一本书,作者是 史蒂芬·柯维,我想说到该作者的另外一本书,应该更多人能知道,《高效能人士的七个习惯》。而在《第三选择》中,他把之前的七个习惯浓缩成一件事情,可以说,第三选择是解决所有难题的关键思维。

当我们面对冲突的时候,正常的思路如何解决?

  1. 我打败你。

  2. 我认怂,你打败我。

而站在第三选择的思维下,你还有一个选择:我们共同找到一个双方都能接受的解决方案,达到共赢。

注意,这里的第三选择,绝对不是来自某一方的妥协,或者一人让一步,核心思想是创造力。如何通过第三种选择,双方协同达成另外一个更好的结局。

例如两个人分苹果,一人一半?这个方案对两个人都有亏欠,毕竟我赢了是可以得到一个完整的苹果的。那什么是第三选择?我们把苹果拿出去换点什么,然后再来分,或者把苹果种成苹果树,只要愿意长线投资,最终我们一人可以收获半棵树的苹果。这些都是第三选择,只要双方能达成共识,这是一个双赢的局面。

二、面对产品经理的冲突

那么我们在和产品经理合作的过程中,通常会面临什么冲突?

2.1 现阶段,技术上无法实现的需求

不能要求所有产品经理都是技术出身,当产品经理对技术细节不那么了解的时候,总会有一些异想天开的产品方案。当然有一些并不是技术无法实现,可能是现阶段你的团队实现起来会很吃力,可能会面临一些未知的坑,而导致整个项目进度很难把控。

面对这样的需求,你不要直接拒绝,尤其是不要立刻拒绝,说这个需求做不到,这就把对方推入了冲突的局面。你拒绝他,不做这个需求了,或者他说服你,强行要实现这个需求,这都不是我们想看到的。

那现在冷静一下,想想第三选择?

我想大多数产品方案,其实并不是唯一的解决方案,你总是想到一些更容易实现的方案的。

你可以问清楚对方的真实需求,给出一个你可以做到的方案,而不是直接拒绝对方的方案。

2.2 需求复杂度和开发时间不匹配

当你面对一个过于复杂的需求的时候,可能因为各种原因,给予你实现功能的时间并不宽裕。

这个时候怎么办?自己加班加点完成吗,大家都是程序员,加班写出来的代码具体质量如何我想你也应该心里有点数。你因为加班写出了质量不好的代码,于是上线之后的 Bug 增多,还需要花时间处理,并且新周期新需求也立刻紧跟上来,发现质量不好的代码扩展性差,想重构时间上又不允许,只能打补丁,越干越慢,越干越烂,Bug 越来越多,于是你压力越来越大,被抱怨的越来越多。

现在欠下的技术债务,之后总是要偿还的,否则长此以往,只能是恶性循环。

这个时候直接答应或者拒绝,又会陷入冲突的境地。想想第三选择,你不要直接说 "不"。你应该先了解清楚,他为什么要这么做这个需求?出发点在哪里?目的是什么?当你了解清楚产品经理对这个需求的真实意图的时候,你可以从自己技术的角度,给出一个自己能接受的方案,或者和对方讨论出一个性价比更好的方案。

能讨论出一个大家都接受的方案,固然是好的,但是如果依然很需求复杂,时间和复杂度依然不匹配,怎么办?

可以选择拆分需求。你可以说,这个需求我仔细分析了一下,需要做 A、B、C 工作,以现在分配的时间来说,我只能做到勉强实现 A、B,并且 B 并不保证质量,你看你这个功能,我们能不能拆分成两期来实现,调整一下需求,这样我能保证代码质量,第一期先保证基本功能,上线让用户来验证需求,第二期再根据用户的反馈调整细节。

相信我,产品经理也是有各种压力的,他也需要保证进度在推进,在一个完成和完美的选择中,我想这不难选择。

这里的诀窍是:当我不能完全满足你的时候,我可以选择有条件的满足你。

这样的好处在于,你把选择权留给他了,这一部分压力是你们共同在承担。如果谁对于这样的延长的周期有异议,你的产品经理也会帮你说话,说自己需求设计的很细,所以我们决定按两期来做,这样也显得他对需求细节的把控很有力。

2.3 需求变动太频繁

作为开发,有时候自己写代码的时候,可能写着写着发现最初的方案或者选型不合适了,就会主动去调整代码、重构代码。而产品经理在设计需求的时候,也会有这样的问题。可能是开始没有考虑的那么细,可能因为来自第三方的压力等等问题,种种原因吧,最终导致需求需要调整,而产品方案的调整,在开发周期内,他是没法自己独自调整的,工作压力一定会转嫁到实现需求的开发身上。

首先我想说,需求变动是一定会发生的,所以拥抱变化。

本身在需求排期的时候,开发者就应该预留出一些时间来应对这些变化,可这也架不住产品太频繁的变动,甚至太过分的明天要封板了,今天还在改需求。

这样的情况,你需要做的是尽量和他捆绑压力,既然对方把压力给了你,你要想办法把这个压力还回去,让对方和你一同来分担这个压力。

我通常的做法是:

1、先用快捷的方法实现并上线,后续再要时间偿还债务

我想很多功能,总是有一些粗暴而不优雅的方式来实现,而这些都是技术债务,之后是需要时间来偿还技术债务。

要让产品经理认领这些技术债务,并且必须立刻给予时间来偿还这些债务。

最简单的一个选择是,我可以加班加点以一个比较粗暴的方式完成这个需求,但是面临的问题是后续可能效率会有问题、扩展会有问题等等。这事后,下个周期我需要额外多出一个星期的时间来优化这一段代码,这就是对技术债务的立即偿还。

2、拆分变动

和之前的思路一样,将变动在现有的基础上最小化,以最精简的方式去完成这些变动。

如果没法精简,想办法拆分成二期来实现。

3、增加变动成本,给予对方压力

虽然所有需求上的变动,最终影响的是开发人员,但是并不是说其他人就没什么事情可做了。想办法增加产品经理的变动成本,让他来共同承担压力。

例如:

增加了这个功能,UI 也需要变动,那你能不能和设计师沟通我们这一期就不要扣太多 UI 细节。— 减少沟通成本

这个需求的变动影响了原本的开发安排,你看能不能将另外一个需求(不那么重要)延期。— 置换不重要,但是需要花时间做的事情

这个需求如果遇到这样的情况,是不是没有办法得到处理?— 提醒他完善需求,避免再次改动

这个需求还有一些 "数据" 需要处理,你看能不能手工帮我处理一下。— 给他找点事儿做,有点损,不推荐

写在最后

在工作和生活中,不要把所有事情的解决方案都放在:不(第一选择,要赢)或者 是(第二选择,认怂)上,如果只存在两种选择,很容易就进入一种推拉的环境中,实际上是可以考虑考虑第三选择 。

第三选择并不是某一方的妥协,他的核心思想是创造力,找到新的出路,让双方协同找到一个大家都能接受的新方案。


发表回复