做个开发喜欢的产品

最近老问产品的同学，如果开发不配合你怎么办？产品与开发处于一种什么关系中？（本文仅从一线开发的角度出发）

刨去人的因素，站在公司团队的角度，两者确实应该是统一战线的战友。但是好多情况下，两个人又处在对立面，有几个场景，大家来感受一下:

• 开发做事不给力，预设的时间点经常完不成功能交付。

• 简单的一两句话能说清楚的业务，非要画原型发邮件确认，不然不做。

• 原型也给了，评审也过了，做出来的结果跟原型不一致。

如何判断这个需求能不能实现？很简单，这个需求在逻辑上讲的通，也不是很玄幻，肯定是可以实现的，成本大小而已。

如何判断这个需求需要多久做完？很明显，你不懂开发的逻辑，拍不了脑袋，但可以找个支点，比如一个基础数据的维护，拿到开发的评估结果后，与自己的评估偏差多少，久而久之基本上可以拿捏着八九分。千万不能说，这东西很简单，半天就可以搞定了，你不擅长的东西就不要挑战别人的专业性，这样很容易造成摩擦。轻则伤神，重则伤身。

怎么样才能更高效的将需求传递给开发人员？原型要完整，基本覆盖所有的场景分支，包括正常的分支以及异常的分支。很多小伙伴，原型上欠缺的东西太多，导致开发做一点问一点，有些人懒的问，直接按自己的理解动手，结果可想而知。

如何确保开发理解的跟我的原型一致？评审、澄清、讨论不一而足，最重要的一条就是要反馈确认。个人知识结构的差异，注定了理解的不一致性，一定要把双方都理解的东西摆在桌面上重复确认。另外，需求讨论会出现很多待定的情形，会给开发造成干扰，等确定后，一定要排除干扰项。

如何确保原型与系统一致？这话问的有些多余，但时有发生。需求讨论后，有变动，开发按新需求调整，但原型未更新，时间久了，这个问题就会成为病，在某个时间点爆发。养成一个随时更新需求/原型的习惯，保持一致性终能受益。

怎么做一个让开发喜欢的人？需求明确，原型清晰，逻辑明了。一句话，产品人员把能想的都想好了，开发把业务原型直译成程序系统就行了。这是一个理想状态，也是团队各方磨合的一个过程。

那该做的都做了，开发还是不配合我怎么办？做事先做人，关系没处理好，直接拿生硬的工作说事，这事就成不了。从“为人处事”，“待人接物”，“因人成事”等这些成语中可见一斑，先有人，再有事。人要学会变通，既然是同一个团队，就可以站在同一立场出发考虑问题，而不能你站在需求提出方，他站在实施提供方，对立起来。和谐的一对好 CP，才能把产品做好。