写给程序员

最近后台文章的留言中，发现了一些很早就关注了我的读者，大部分都是 2013 年前后关注的。

特别感谢你们的长期陪伴，一起见证彼此成长的感觉很好。

可能有的读者不知道，只要留言或者赞赏，我都能在后台看到你们具体是哪天关注我的，以及你们留过几次言、有过几次赞赏。

而且按照微信公众号的产品逻辑，取关后重新关注，关注时间就是按照最后一次关注的时间算起。

所以，如果不是实在受不了我，那还是别取关了。说不定哪天我给关注三年以上的老读者发个大福利啥的呢。

当然，如果你依然还是受不了我，那也只能江湖再见了。

怎么样，是不是很土？

没办法，当年是直男程序员，想不出啥文艺名儿。

后来转型做产品就没写技术文章了，所以想改个名，思来想去不知道改啥，所以就把自己的名字放上去了。

好在，我的名字比较清奇，不是很常见。

噢，对了，还有头像。

哪天心情好的时候，我把过去公众号帅气的头像都拿出来让你们笑话一下。

最初关注我的读者基本都是程序员，而且大部分都是做 android 和 ios 开发的。

今天特别想跟这些依然在关注我的老读者聊一聊，聊什么主题呢？

想了下，觉得可以以一个产品过来人的身份，跟你们聊聊如何避免被产品经理坑。

做技术的都是兄弟，以前我也是个苦逼码农，也做过那些无脑需求，同样被产品经理的神逻辑折磨过。

最讨厌的，就是正写着代码呢，产品经理过来说正在做的需求有一点调整，或者偷摸小声说，只打扰你一分钟。

他们压根不知道，需求的变化对于代码来说很可能是推翻重来，不是他们所理解的“只有一点调整”。

他们也不知道，打扰的那一分钟，可能需要再花半小时甚至更长的时间来重新梳理逻辑。

尤其是改 bug 的时候，那种突如其来的问候真的不需要，哥们儿还想早点搞定下班呢！

面对这种情况，建议程序员兄弟们贴个条在工位上，注明“攻关中，看我起身再找我”。

还有，开评审会时，一些产品经理一上来就说要做什么功能，从来不介绍背景是什么，也不说为啥要做，做了会带来什么预期结果，更别提怎么衡量数据评估 roi 了。

他们以为研发资源都很闲呢，大家都是有梦想的人好么。

遇到这种情况，作为地球上最理性的一类人，我们要做的就是“教他们做人”。

就像我们写一个函数需要提前声明一样，要有前因后果，否则就会报错。

当然，“教别人做人”的前提是自己已经做好了，且不说我们要多懂产品和业务，毕竟有更专业的人。

但至少，一套完整的思维框架还是需要的，领导们不就是思维模型和做事方式比一般人成熟么。

产品功能不是独立存在的，是基于用户场景、业务、需求、数据和可运营性综合构成的。

下次如果还有产品经理这么开评审会，至少有这么几个问题是可以向他们提出的。

第一，业务背景是什么？第二，什么样的场景解决用户什么问题？第三，如何通过数据衡量解决情况？第四，功能上线后谁来负责运营？

反过来看，如果产品经理的解决方案不行，咱也别就此作罢让他们回去改方案。

看看针对具体问题有什么可行方案，现场讨论就把问题都给解决了。

总比他们改完一圈回来然后再开一次会要节省时间，万一下次又不行呢。

另外，做技术的都怕产品经理只顾当下不管过往，代码可是活生生写在那的，所有的历史逻辑都会毫不客气的照常运行。

一个需求提过来，也不管跟以前的逻辑是否有冲突，只嚷嚷着要改，不行就拿老板说事儿，这样的产品经理真的得治。

治法也很简单，把逻辑卡点告诉他们，然后就可以拂袖而去干自己的活儿了，其他的也别多管，他们自己能反思并搞定。

谁让咱心里有一张全局代码图呢，谁让咱心里有完整逻辑谱呢，这就是技术的优势，不容置疑。

而且，对于不管过往的产品经理，最好的方式就是让他们做一张产品流程全景图，形式可以是流程图或者脑图。

每次做调整时，都让他们先把这个全景图的关键逻辑过一遍，以防出现上线后发现兼容性问题。

当然，咱最怕的就是那些甩锅耍赖的产品经理了，就算人家耍赖，咱也下不去狠手不是。

不管怎么说，还是不能硬钢。平时工作得做到位，这里也给大家支个招。

关键逻辑代码的注释一定要写完整，而且别光写代码解释。

把逻辑决策人、时间、讨论关键点以及当时的决策过程写清楚，打包时随业务代码一起上传。

如果到时候出现甩锅事件，把代码拉下来，这就是“云证据”啊！

好了，多的也不说了。

总之，做技术的人，天生理性，学习东西快，多掌握一些关于产品、业务、运营的知识，省的被坑。

最后，产品经理们，你们看懂了么？

···············end···············

  推荐阅读

转型产品能干啥，不做产品能干啥

推荐一本好书