最近找了很多产品朋友聊天，都聊到同一个话题：你上次被程序猿喷是因为啥？
出乎我的意料，大部分产品人都自称没有被喷过。
这就尴尬了，本想收集点素材写推文，没想到现在程序猿的工作态度已经向高速收费员看起了吗？
不对吧，以程序员们的情商，应该很难委屈自己。
掐指一算，应该是我的问题有点太直接了，所以我迂回了一下，改问：上次跟程序员起争执是因为啥？
果然，收集到了很多案例，多半是吐槽程序猿的， 剩下的少部分，就是我们今天的主题：产品经理被喷死都不冤的几种场景。
需求不完整
这是最常见的惹恼程序员的方式，没有之一。
产品经理苦思冥想很久之后终于灵机一动想出一个可以改变世界的功能之后，高高兴兴的拉着程序员过需求却收获一顿白眼：整体没啥毛病，细节缺失太多。
比如：
只有主流程， 忽视分支流程、逆向流程等；
忽略不同状态下页面的文案变化；
缺少交互规范等；
缺少异常状态的处理；
…
这种事儿，老板干出来没毛病，随口一提我要做个**功能，自然有人去细化实施。
产品经理干出来就要被喷了，因为你就是那个去细化老板想法的人啊！
频繁微调需求
就是字面意思。
其实设身处地的想一下，如果运营向你提需求后，在开发过程中频繁的调整需求，你会不会跟程序猿一起怒喷之？
运营改需求对产品经理来说还好，顶多是调一下原型、改改文档而已，但对程序员来说，就真的是哔了狗…
举个栗子，比如做菜，运营突然跑来说，客人把红烧鱼改清蒸了！
产品经理这儿很简单，改个菜谱而已，最多就是把盛鱼的盘儿换成盛汤的碗。
但程序员这里就真的是要爆粗了，我都起锅烧油爆炒半天了，你让我改清蒸，那这炒了一半的鱼给你吃吗？？？
特别是对于很多不懂技术的产品人来说，经常会天真的想：我不就是把需求微调一下，至于骂人吗？
其实有时候动手也不奇怪，因为产品经理随口改个需求，很可能就意味着程序员加班熬夜码了半个月的代码要推倒重写。
流程比较正规的团队在项目进程里都有“需求封板”这么一步，通常是在需求评审会后、开发之前做。
需求封板之后，就不能有任何功能性的改动了，避免出现红烧改清蒸的情况。
提需求不考虑实现
有个经典段子：产品经理提需求，根据用户手机壳的颜色来自动调整App的主题色。
然后程序员表示：改造不了APP，我改造一下你好了！
现实情况没那么夸张，能提出这种需求的人，一般也做不了产品经理。
但确实有很多不懂技术的产品经理随口提的需求会让程序员一头问号。
比如富文本编辑器、推荐系统、全文搜索、数据同步...
我本人也属于不懂技术的产品经理，在初入职场被技术喷过几次之后，就乖乖养成了一个提前沟通的习惯。
在提需求之前的构思阶段，就频繁利用上厕所、抽烟放风的时间跟程序员做开放式沟通：如果我想实现一个某某功能，技术实现难度有多高？
这种场景下，即使提出一些太过逆天的需求，也不会被骂，毕竟是闲聊天嘛。
改需求不通知到位
前面提到需求封板之后，不能再做功能性调整。
那是理想状态。
现实中总会出现一些不可抗力导致改需求，比如甲方一个电话、老板一拍大腿等。
对程序员来说，无论什么原因，改需求总是让人火大的。
但他们接触不到甲方、不敢喷老板，所以发泄对象一定是锁定在你——产品经理身上。
但这事儿又不能赖你，所以程序员就会处于想喷而不得喷的不稳定状态。
这时，任何风吹草动都可能成为引爆他们的导火索，比如改需求没通知到所有相关人员。
产品经理有时候会认为某某需求是前端负责，或者是后端负责，所以改需求时只通知到一端。
其实大部分需求的实现都是前后端联动的，任何的需求调整，一定要通知到所有人，宁可错通知三千， 不可错过一个。
正确的改需求姿势是用邮件通知，收件人包括开发、测试、设计、运维、客服等等你能想到的跟项目沾边的所有人。
所以你上次跟程序员起争执是因为啥呢？在评论区聊聊