做一个不挨揍的产品狗

最新推荐文章于 2024-09-29 12:06:46 发布

「已注销」

最新推荐文章于 2024-09-29 12:06:46 发布

阅读量162

点赞数

文章标签： java 编程语言人工智能大数据 python

原文链接：https://mp.weixin.qq.com/s?__biz=MzAxNjMyMDUzMQ==&mid=2247545977&idx=2&sn=d66837b8b3951b317b4390c8ad438849&chksm=9bf4e505ac836c133e34c731ad45836e383d902a3062741a2f01f20f557d3d602c56798acc73&scene=126&&sessionid=0

版权

2018年曾经有一个视频火遍了整个朋友圈，某公司的产品经理和程序员大打出手，据说背后原因竟是产品经理要求用户App的主题颜色能根据手机壳自动调整，可能是程序员觉得这个要求太过分了，于是一言不合打了起来。

菜根早报

8月2日

互联网屁事早知道

今日热点导读

产品狗和程序猿打架

👇关注我入群，一起变优秀

作为产品经理的我，也觉得这个需求有点过分，但是也不至于就为这打起来啊。当时还有一些团队看热闹不怕事大，居然还给出方案出来了。

菜根早报

8月2日

互联网屁事早知道

今日热点导读

方案来了！

很佩服这个老哥给的解决方案，一个字：牛逼，两个字：真牛逼！你咋不直接人工智能呢？如果你是程序员给出这个方案，在佩服你智商的同时，估计也要挨打了。

我本身程序员出身，做到技术总监，后来由于业务的需要，不得不做产品和运营。有过技术和产品的双重经历，我能深刻的体会到技术和产品的矛盾，也更了解如何去化解这个矛盾。

1、需求分析和描述不到位

程序员在流程的最下游

如上图所示，程序员处在流程的最底端，产品经理跟客户/用户/领导沟通的需求，最后传递到程序员这里，有可能变了味道。如果产品经理把握不好，可能最终结果跟客户想要的完全不一样。等到最终客户/用户/领导勃然大怒的时候，矛盾可能就激发了。如何解决？

简单，一个杯垫搞定！尼玛，你咋不放把水果刀呢？

产品经理首先要了解业务，才能更好的理解需求。如果需求来自客户，那么一定要明确这个需求不是最终可用的需求，一定要做需求分析，帮客户梳理这个需求，弄清楚客户提这个需求的最终目的是什么？客户的需求如果是“我要一批更快的马！”，也许他的目的不是要一匹马，而是更快的交通工具。产品经理一定不是客户的传话筒，他一定要将客户需求转变为产品需求或者系统需求。

2、产品需求经常变动

再变别跳楼啊，拿刀去砍他！

由于产品经理经常改动需求，导致程序员不得不把做好的东西重新再做，结果可想而知。有时候程序员加班加点刚做完的东西，产品经理说需求变动了，不能这么做。严重的时候连核心模块都完全大变样。就一直这样改完做，做完改，无限循环下去。但是产品经理也有怨言，需求变化是正常的啊，老板的想法经常变，客户的需求经常变，我有什么办法？

产品经理必须掌握需求管理

需求变化从某种意义上来说是好事，有变化说明有进展或者有改进，我们不能避免需求变化，但是作为产品经理我们要学会控制需求，对需求进行有效的管理。

首先我们要做需求的合理性讨论，在这个阶段如果能让技术参与，发表意见，让他们感到被尊重，对于后期的需求支持是很有帮助的，切莫自己二话不说拍脑袋！确定需求必须要改变以后，我们要合理的管理这个变化。产品经理必须得有版本的概念，当前已经开发的版本内尽量不发生变化，把新的变化规划到下一版本；如果实在必须要在当前版本需要变化，那就和技术沟通工作量和计划变更。要么延长上线时间，要么替换其他需求任务，让需求的变化不影响技术的工作量和计划，技术又怎么能给你打架呢？

当然，由于老板的行政命令和对客户的承诺，你无法更改计划，那怎么办呢？还是和程序员做朋友，做兄弟吧，如此也许一顿饭就搞定啦。

3、产品狗不懂程序猿

遇到一个像我这样很懂技术的产品经理不容易（有点自恋O(∩_∩)O）。程序员经常听到的一句话就是，"这么简单的功能为什么要这么长时间？"这样的话令很多程序员恼火，是最能激发与产品经理矛盾的导火索。因为你不懂技术，你就和程序猿没有共同的话题，你就很难站在对方角度上去看这个问题，你也无法掌控程序猿对工作量的评估是否合理，总是以为他在骗你，如果是这样的状态，又怎么能不产生矛盾呢？

产品经理得学点技术，否则会被程序员鄙视的

从技术转到产品的人，本身对技术了解，可以更好的跟程序员沟通想法，但是一定注意，千万不要反客为主，不要干涉技术。之前就碰到一个曾经做过技术的产品经理，对于技术的方案评头论足，甚至指导技术，搞的技术很郁闷，摔了一句：“既然你这么牛逼，你自己做好了”。对于不懂技术的产品经理来说，建议要去了解一下基本的技术知识，不需要太深，但是要知道概念，知道大致的使用场景。别整出像“你是用Java还是SQL开发”，“Hodoop比你用Java开发好吧”等这样的概念性的错误，让程序员鄙视，啥都不懂，你还怎么质疑人家评估的工作量啊！

高山流水，知音难觅！知音不成，至少我懂！只有懂对方，才能在一个频道上沟通。

为了做一个不想挨揍的产品狗，一定要不断修炼上面说的一些能力。当然作为一个曾经的程序员，现在虽做产品但依然领导技术团队的我，也有必要给我们的程序员弟弟们点建议：

1、做好需求变化的准备，不要排斥变化。要提高代码的扩展性和维护性，用不变的架构应对变化的需求。

2、对需求理解透彻在开始写代码，要多和产品经理确认！我们经常碰到最后开发出来的跟产品经理想要的不一样，就是因为没有理解需求，或者理解有误，就开始做了。

3、评估工作量和计划时，一定要预留修改bug及其他突发事件的时间，给自己的工作留有余地。