我与产品经理的沟(si)通(b)方式

如果列出程序员最讨厌的五件事,可能最首位的就是需求变更。实际上把所有产品需求的变更都归咎于产品经理本身能力问题,并无助于提高工作效率。

为了说清这个问题,我们来一起回顾一下,一般公司内部的 问题->需求-> 实现 的工作流程。

  • 我们来假设,所有需求的建立,本质上都是为了解决某一问题, 我们将这个问题叫做问题A。
  • 为了解决问题A,产品经理提出相对的解决方案,我们叫它需求B。
  • 研发人员针对需求B,制定实现计划,将需求落实为代码,我们叫它结果C。

看起来很正常,似乎没有什么不妥对不对?
然而实际上,从我个人的经验上来讲,正是这种工作模式,很可能造成大量的需求修改。

实际上很多人看到这里应该反应过来了——整个工作模型,就是一个典型的悖论模型。最可能带来长期加班与需求修改的部分,往往不是C没有完美实现B,而是——C最终发现不能解决问题A。


近两年来,我总是反复提醒新人刚做需求的时候,不要先纠结需求的哪个部分是否好实现,哪个分支条件没有考虑到,而一定需要问清楚的是——你的需求,要解决什么问题?

当你手里握着锤子的时候,你看什么都像钉子,这是在学习算法的时候很容易体会到的事实(比如判断N个矩形的包含关系,当你不知道什么是线段树之前,你用已知的一些算法思路去解决,往往是低效的)。人终究只能在自己有限的知识和视野内提出有限的解决方案,所以大部分时候,产品提出的方案B,并不能解决问题A,或者从技术角度讲,有更加优雅高效的解决方案。

top Created with Sketch.