做个产品喜欢的开发

不要跟产品经理聊天，你跟他扯了半天，他的需求出来了，你的代码一行未写。——开发人员的幸酸

上篇站在开发的角度出一篇《做个开发喜欢的产品》，本文作为姊妹篇，站在产品角度，来审视一下开发的小伙伴们，到底什么样的开发小伙伴会与产品人员的成为好CP。

你在工作中与产品人员配合的怎么样？会不会有对立的时候，什么原因呢？不妨站在团队的角度，来重新分析一下这种对立是不是有必要？

关于需求

• 有疑问的地方会主动讨论，而不是按自己的理解来解决问题。闷头做完的后果，大概念下会返工重来，浪费的都是团队的时间。

• 存在逻辑遗漏或不顺畅之处，能与产品人员一起补充完整。理论层面能梳理清楚明了，但具体到代码编写时，细节处难免会出现逻辑遗漏或冲突的情况，导致需求难以为继。

• 不合理的需求会主动PK，而不是等上线后出问题了，再给你来个马后炮。产品经理虽然主抓业务，有很大的话语权，但开发人员也不能死脑筋，明知道是错的还要去做，一句“都是按产品经理说的做的”也是显得有点不负责任。

• 给产品人员广开思路，有些方案产品并不能面面俱到，特别是具体的实体场景上。

• 对原型不吹毛求疵，能表达清楚意思即可，不一定非要高保真。对一些潜台词，即便没写出来，开发小伙伴也能Get到点。

• 讨论需求时，只讨论需求，不要把“需求会议”最后变成了“技术实现会议”。

关于功能实现

• 功能严格按照需求来做，按时保质保量完成，当然有歧义或不合理之处能与产品主动沟通处理。

• 开发完成后，及时提出功能验收，功能可用性强，不会轻易的验出问题，以及潜在的问题

• 有关联的功能点可以一并调整。很多功能间有着千丝万缕的联系，不能仅从面上理解去调整，冰山背后隐藏的内容有时候更重要。

关于沟通配合

• 容易沟通交流，这是很关键的一点，人缘好的人，运气都不会太差。

• 砍需求可以，拿出实际理由，看优先级，看时间节点，砍的合情合理，心服口服。不来一句“这个实现不了”交差，这不是做事的态度。

• 有些基本的共识，不需要过多交流。这是长期磨合后的默契，可以大大提高做事效率。

这些点抽象出来，其实就两个字：靠谱，靠谱的人做出的事自然靠谱，让人放心。再次引用下前文中提到的几句话：

从“为人处事”，“待人接物”，“因人成事”等这些成语中可见一斑，先有人，再有事。人要学会变通，既然是同一个团队，就可以站在同一立场出发考虑问题，而不能你站在需求提出方，他站在实施提供方，对立起来。和谐的一对好CP，才能把产品做好。