网上的一个关于程序员和产品经理的图片想必深入人心......

日常工作中，程序员和产品经理的关系可谓相爱想杀，靠谱的产品经理搭配靠谱的程序员，需求提的对，任务完成质量高，产品成功，年终奖大大的有~然而大部分情况是程序员和产品经理互相看不顺眼，你嫌我改需求，我嫌你能力差，最终撕来撕去，一不小心还会擦枪走火，胳膊腿乱飞O__O "…

那么如何搞定程序员呢，小弟入行一年多，也积累了一些经验教训，目前与程序员的关系也还算可以，总结了以下几点，供大家拍砖~

1. 写清楚需求

写清楚需求这谁都知道，然而做起来却艰难无比。需求只有一个不变的属性那就是一直在变，变来变去最后亲妈都不认识了。这里所说的写清楚是指与程序员达成共识，让任务能够成功排进计划。什么意思呢？就我自己来说，提需求经历过两个阶段：

（1）瀑布流模式

瀑布流是传统的软件程序员模式，有需求分析、设计、开发、测试、维护等几个阶段。一开始我们是这样的，最重要的就是写一个需求文档，然后丢给程序员，做成什么样子大概就看天意了O__O "…。这样的模式下，基本不需要把需求文档写的太清楚，只要测试和开发人员能够接受就可以了，具体的细节可以在开发过程中沟通。第一次写需求文档被测试怼过一次，不过后来写的规范一些，也就没关系了。再加上之前的开发人员也有自己的主见，遇到一些不明确的地方按照自己的理解就干了。这样确实比较少操心，但是开发质量实在是堪忧。

（2）敏捷软件开发

做了一段时间，我们的模式变了，变成了敏捷软件开发。敏捷软件开发的特点就是不太需要大型的需求文档，而是把大型的需求拆解成一个一个的任务，通过这些任务来进行开发。虽然需求文档不需要写了，但是对于任务的要求更加严格了。任务写不清楚，被程序员怼，被项目管理怼，初期真是痛不欲生。不过后来也就掌握了窍门，把需求写的尽可能详细，而且要在细化会议、计划会议等各种会议上一遍遍的和程序员确认，让他们提出问题，一个个的解答清楚，直到达成共识，把任务排进计划。

总之，核心就是“共识”两个字，与程序员达成共识，产品经理说清楚这个任务要干什么，程序员也理解这个任务要干什么。达成了共识，任务就能排进计划，完成了第一步。

2. 悄无声息的改需求

之前也说了，需求只有一个不变的属性那就是一直在变。再加上任务中间遇到的一些突发状况，可能要插入任务，这时怎么办？在这样的情况下该需求就要做到”悄无声息“，不知不觉的加了一些任务。既完成了计划的任务，又捎带解决了一些小需求。

目前我们的产品是每两周发布一次，在这两周的开发过程中，尽量不要往里面加任务，否则又会被怼。这就造成在这两周里遇到的一些新问题需要等到再过两周才能解决，可能就需要一个月的时间，这是难以接受的。这个时候我采取的办法通常是把新需求塞到老任务中。举个例子：本来有一个任务A是修改一项数据，结果过程中发现另一项数据也有问题。这时怎么办呢？如果新建一个任务就需要再等两个星期了，而这个需求又挺紧急的。我采取的办法是先和程序员沟通，让他意识到这个任务也是很重要的，然后把这个需求塞到任务A中。这样既不用新建一个任务，又悄然变更了任务A的需求，还能及时的解决一个新问题，三全其美。

当然，改需求的时候还是一定要和程序员达成共识，让他接受我们的观点，才能顺利的变更需求。

3. 产品经理和程序员不是对立关系

产品经理和程序员之间怼来怼去，撕来撕去，本质上还是因为二者是互相对立的关系。产品经理觉得程序员不努力，这么简单的事情都做不好。程序员觉得产品经理什么都不懂，提需求根本不考虑实际情况。其实我认为，程序员和产品经理完全是互利共生的关系，共同做好一个产品，共同成长，升职加薪。所以与程序员保持一个好的关系是非常重要的，我觉得主要是有以下两个方法：

（1）有同理心，提需求要考虑技术可行性

程序员常对产品经理说的一句话就是这个做不了，那个做起来有难度。这时怂一点的产品经理就会算了，而强势的产品经理则会说这么简单都不会，辣鸡。然后又是无穷无尽的撕逼⊙▃⊙ 其实产品经理在提一个需求的时候，最好还是先把技术背景调查清楚，只需要一点点技术基础即可，这样程序员在说做不了的时候你才能有理有据的反驳。比如说，我们之前要做一个新功能，程序员觉得难度很大，毫无头绪，评估时间说要两个星期。这对我来说肯定无法接受，我没有去反驳他，而是去搜索资料，结果最后发现了一个开源的项目，正好可以拿来使用，有了它，这个任务就只需要3天完成。岂不是皆大欢喜~

（2）开会时气氛融洽，便于推进计划

敏捷开发的一个特点就是会特别多，每天都晨会，每周有细化会议，计划会议，回顾会议等等等等。在这些会议上，我认为要保持一个融洽的气氛，有一些幽默感。不要搞得冷冰冰的，互相臭脸。一个融洽的气氛可以更好地说服程序员接受你的需求，并且还可以让他们愿意提出问题，更快地达成共识。

不知不觉写了不少，想到哪写到哪，还是有一些文字不流畅的地方。算是这一年来对产品经理和程序员之间关系的一个思考，可能还不够成熟，之后还是需要在实践中不断学习~