作为一个集需求收集，产品设计，项目管理以及核心价值背锅于一身的产品人员，与程序员的交流是日常工作的很重要的一部分。要是恰好在一个多产品线并行需要抢资源的情况下，程序员仇恨师这个新职业诞生了。今天想聊一下和程序员们不得不说的故事。
程序员，有的人把他们称为码农，又有人说你只需要在群里面扔一句“最好用的语言是PHP”就可以引起他们的一场骂战，还有人说程序员泡上一杯咖啡带着一个耳罩耳机对着电脑就可以活下去。
但是对于一个产品人员来说，接触到更多的是有血有肉的程序员，所以打起交道来就没那么简单了。这里想要合作，需要下更大的功夫。
团队的大小项目的多少直接影响产品与程序员的关系。总的来说，根据项目临时拼凑起来的项目组，工作的磨合与产品的传达有时候可能会浪费更多时间。这样就需要产品的文档更加清晰有逻辑性。
文档的重要性是一个老生常谈的事情了。在我看来，在保证文档记录的重要作用之下，如何传达产品意思更重要。所以这时候就要根据项目的不同，以及程序员大神们的不同好好调整了。
对于后端同学来说，更偏向于清楚产品逻辑，各个功能点，所以整理一份流程图加上元件说明是一个极好的选择，否则极有可能被虐哭。而和前端同学交流的时候，他们可能更看重界面的交互效果，这个时候，交互图或者demo就要给精细了，抛开UI大神不谈，一个按钮成功提示，失败提示，等待提示，延时提示，错误提示。。。。。。还是蛮重要的。
同样，工作5年的大神和刚毕业的小苗决不能一概而论，团队的支柱跟刚报到的新人也不可能递同一份文档。有时候会发现给大神说一句话就能解决的问题，可能给到了小苗要做3小时。当然有时候并不是技术方面的问题，而是经验不同理解即不同。这可能就是能力与大责任越大吧。
文档虽然要求精细，但总难免有没考虑到的地方，特别是产品一个人搞定所有事的时候。有一次测试一个页面，发现一个元件字体超大，反过去问前端同学，得到的回答是，这里做大一点不是更加明显吗。后来慢慢聊过后发现，他对这个产品的需求意义并不了解。在这种多项目混杂的时候，出现这种情况只能说是情理之中了，如果之前能够细细讲一下需求的目的和意义，在做之前有一个全面深刻的了解，那程序员的开发速度和质量肯定会大大提高的。
我记得当时我入职的第一天，我的老大让我去各个地区拜山头，而且让我一天之内记住这个办公室人的名字和职位（虽然我失败了，我答错了两位前端的名字，虐哭）。从此老大几乎随时会给我灌输各种类似的招式，这类招式叫做：和程序员打好关系。事实证明，拜山头的好处还是很明显的，产品的调和工作我做起来还算是顺手。程序员跟你关系好，起码自测都更认真，改需求也方便点。
最后，作为一个程序员仇恨师。
默默埋头苦干是好事，自己做了哪些，还得多多表现，社会那么复杂，不是富二代，还是不要玩深沉的好。
