“看别人撕逼觉得自己智商高充满欢乐，自己撕时又乐此不疲浑然不知”。在互联网界有两种生物，他们经常邀约吃饭，开会扯淡，他们是产品大佬和技术大佬。他们相信 “撕逼才是人类进步的阶梯” ，以撕逼为乐。曾经我也天真的相信技术大佬和产品大佬之间可能有纯洁的战友情。但是当多次被技术大佬怼的无地自容之后，我知道了阶级矛盾是不可调和的。反正都是要死，与其害怕斗争，不如实行黑暗森林法则，让我们先发制人。毕竟达芬奇也说过：“对于你的敌人来说他激怒你他便战胜你”所以负负得正，我们激怒技术大佬失去理智，就是我们撕逼胜利的冲锋号。产品大佬看着手机，马上时间停留在5点55分，产品大佬走到技术大佬面前，用1分钟讲完了一个紧急需求。然后在花4分钟讲了领导是如何催的急，他是如何的无可奈何，浑身散发者一股不知足的油腻气息。后下班前后10秒种，产品大佬问技术大佬：“今天晚上能上线嘛？”这个需求很简单，不就是实现一个简单的配置界面么，为什么讲了几遍你听不懂？产品大佬大佬洞悉各种业务细节，讲需求的时候上来就和技术大佬讲实现细节，为什么，怎么做，做什么，只需要告诉他做什么就好了。把技术大佬带到细节的沟里去，让他成为crud工具人。当客服丢出一个问题到线上问题反馈群，产品大佬不用自己排查，顺手就艾特技术大佬。至于到底是bug还是配置问题，其实都不重要，因为产品大佬的目的是惹怒技术大佬。很多项目并不是产品大佬想要做，所以当项目价值的不清晰的时候，产品大佬可以把锅甩给领导，向下传递“敷衍”。此话一出，只要产品大佬不觉得油腻，油腻的就是技术大佬。产品大佬干不好技术，所以选择了做产品，但是不代表产品大佬不懂技术。谁没学过几句sql，谁不会点语言，对技术大佬的关怀就应该无微不至。有技术追求的产品大佬就应该大脑技术评审会，字段命名不规范，设计不合理一个都不能放过。当技术大佬已经进入了code环节，产品大佬可以偷偷的修改prd，刚一点也可以把技术大佬喊到跟前，口头修改需求，这样的修改重复三四次效果更佳。这样的修改好要重新设计表结构，总之影响越大对技术大佬的伤害越大。项目评审的时候，技术大佬还是产品大佬口里的小甜甜，等真正在开发过程中，产品经理好玩消失。技术大佬有什么问题，让他们自己读文档解决，解决不了让他们自己猜。产品大佬写PRD好拿出小学写作文的水平，前后可以不一致。新项目嘛，逻辑有问题，细节写的不清晰，界面之间没有跳转都不是事儿。产品经理这么忙，所以有时候考虑不周全也很正常嘛，对细节不清晰，所以才体现了技术大佬的重要性。反正产品大佬要的需求就是这样，怎么实现那是技术大佬的事情，不怕死的产品大佬就是这么蛮横。每当技术大佬评估完一个项目的工作量之后，产品大佬就把工作量打个5折在上报，不用在乎技术大佬同意不同意。毕竟大家都是长期合作的生意人，谈排期打个折那也是很正常的。虽然在技术大佬花费了大量的时间在code上，但是他也获得了工资收入，所以后续项目运营结果不要和他们同步。同时技术大佬心脏也不一定好，项目烂尾的消息更是一个字都不能提。这个月给研发提了一个数据治理的需求，下个月提的是营销类的需求，让研发不断练兵，在各种系统和架构之间跳舞。让他们开始体会变化就是大的不变，让他们系统架构乱如毛线团。很多产品大佬的信仰不是用户是金钱，但是不代表技术大佬没有信仰。很多技术大佬的信仰是 ，“通过合适的设计，解决复杂问题” 。所以要从源头上毁灭他们的信仰，所谓合适的设计就是抄竞品，只要每次谈需求都打开竞品。教他们怎么像素级抄袭，并且还告诉他们 先抄袭后超越，让他们毫无心理负担。为了让技术的工作不是很乏味，要充分通过时快时慢的节奏感，调动他们的工作积极性。偶尔的项目排期相当紧凑，偶尔的项目排期又十分松散，让技术大佬开始怀疑自己的骨干位置。人类只能控制自己能够控制的事情，所以技术大佬加班是能控制的，但是用户是我们不能控制的。所以按这个逻辑，技术大佬加班提前3天上线，项目上线后30天还没开始运营。杀敌一千，自损八百，上一位实战过以上15条的产品大佬，至今还没有出院。其实技术大佬的愤怒，都是从产品大佬以自我为中心，不考虑他人感受开始的。也许你可能会说，为什么不是技术大佬多站在产品大佬的角度考虑问题呢。傻瓜~ 在一段长久的关系里，总有一个愿意低头的人。产品大佬和技术大佬互相嫌弃又离不开对方，word 妈呀，这多么像有趣的爱情啊。。。作者介绍：呱哥，某头部金融科技产品，出过一本书，创过业，也在小厂做过管理的斜杠产品经理，若不是遥望星辰与大海，谁愿忍受眼前的苟且。
