最近后台文章的留言中，发现了一些很早就关注了我的读者，大部分都是 2013 年前后关注的。
特别感谢你们的长期陪伴，一起见证彼此成长的感觉很好。
可能有的读者不知道，只要留言或者赞赏，我都能在后台看到你们具体是哪天关注我的，以及你们留过几次言、有过几次赞赏。
而且按照微信公众号的产品逻辑，取关后重新关注，关注时间就是按照最后一次关注的时间算起。
所以，如果不是实在受不了我，那还是别取关了。说不定哪天我给关注三年以上的老读者发个大福利啥的呢。
当然，如果你依然还是受不了我，那也只能江湖再见了。
我这个公众号最初的名字不叫「唐韧」，改名之前叫「Android 及 iOS 开发汇总」。
怎么样，是不是很土？
没办法，当年是直男程序员，想不出啥文艺名儿。
后来转型做产品就没写技术文章了，所以想改个名，思来想去不知道改啥，所以就把自己的名字放上去了。
好在，我的名字比较清奇，不是很常见。
噢，对了，还有头像。
哪天心情好的时候，我把过去公众号帅气的头像都拿出来让你们笑话一下。
最初关注我的读者基本都是程序员，而且大部分都是做 Android 和 iOS 开发的。
今天特别想跟这些依然在关注我的老读者聊一聊，聊什么主题呢？
想了下，觉得可以以一个产品过来人的身份，跟你们聊聊如何避免被产品经理坑。
做技术的都是兄弟，以前我也是个苦逼码农，也做过那些无脑需求，同样被产品经理的神逻辑折磨过。
最讨厌的，就是正写着代码呢，产品经理过来说正在做的需求有一点调整，或者偷摸小声说，只打扰你一分钟。
他们压根不知道，需求的变化对于代码来说很可能是推翻重来，不是他们所理解的“只有一点调整”。
他们也不知道，打扰的那一分钟，可能需要再花半小时甚至更长的时间来重新梳理逻辑。
尤其是改 bug 的时候，那种突如其来的问候真的不需要，哥们儿还想早点搞定下班呢！
面对这种情况，建议程序员兄弟们贴个条在工位上，注明“攻关中，看我起身再找我”。
还有，开评审会时，一些产品经理一上来就说要做什么功能，从来不介绍背景是什么，也不说为啥要做，做了会带来什么预期结果，更别提怎么衡量数据评估 ROI 了。
他们以为研发资源都很闲呢，大家都是有梦想的人好么。
遇到这种情况，作为地球上最理性的一类人，我们要做的就是“教他们做人”。
就像我们写一个函数需要提前声明一样，要有前因后果，否则就会报错。
当然，“教别人做人”的前提是自己已经做好了，且不说我们要多懂产品和业务，毕竟有更专业的人。
但至少，一套完整的思维框架还是需要的，领导们不就是思维模型和做事方式比一般人成熟么。
产品功能不是独立存在的，是基于用户场景、业务、需求、数据和可运营性综合构成的。
下次如果还有产品经理这么开评审会，至少有这么几个问题是可以向他们提出的。
第一，业务背景是什么？第二，什么样的场景解决用户什么问题？第三，如何通过数据衡量解决情况？第四，功能上线后谁来负责运营？
反过来看，如果产品经理的解决方案不行，咱也别就此作罢让他们回去改方案。
看看针对具体问题有什么可行方案，现场讨论就把问题都给解决了。
总比他们改完一圈回来然后再开一次会要节省时间，万一下次又不行呢。
另外，做技术的都怕产品经理只顾当下不管过往，代码可是活生生写在那的，所有的历史逻辑都会毫不客气的照常运行。
一个需求提过来，也不管跟以前的逻辑是否有冲突，只嚷嚷着要改，不行就拿老板说事儿，这样的产品经理真的得治。
治法也很简单，把逻辑卡点告诉他们，然后就可以拂袖而去干自己的活儿了，其他的也别多管，他们自己能反思并搞定。
谁让咱心里有一张全局代码图呢，谁让咱心里有完整逻辑谱呢，这就是技术的优势，不容置疑。
而且，对于不管过往的产品经理，最好的方式就是让他们做一张产品流程全景图，形式可以是流程图或者脑图。
每次做调整时，都让他们先把这个全景图的关键逻辑过一遍，以防出现上线后发现兼容性问题。
当然，咱最怕的就是那些甩锅耍赖的产品经理了，就算人家耍赖，咱也下不去狠手不是。
不管怎么说，还是不能硬钢。平时工作得做到位，这里也给大家支个招。
关键逻辑代码的注释一定要写完整，而且别光写代码解释。
把逻辑决策人、时间、讨论关键点以及当时的决策过程写清楚，打包时随业务代码一起上传。
如果到时候出现甩锅事件，把代码拉下来，这就是“云证据”啊！
