不要跟产品经理聊天,你跟他扯了半天,他的需求出来了,你的代码一行未写。——开发人员的幸酸
上篇站在开发的角度出一篇《做个开发喜欢的产品》,本文作为姊妹篇,站在产品角度,来审视一下开发的小伙伴们,到底什么样的开发小伙伴会与产品人员的成为好CP。
你在工作中与产品人员配合的怎么样?会不会有对立的时候,什么原因呢?不妨站在团队的角度,来重新分析一下这种对立是不是有必要?
关于需求
有疑问的地方会主动讨论,而不是按自己的理解来解决问题。闷头做完的后果,大概念下会返工重来,浪费的都是团队的时间。
存在逻辑遗漏或不顺畅之处,能与产品人员一起补充完整。理论层面能梳理清楚明了,但具体到代码编写时,细节处难免会出现逻辑遗漏或冲突的情况,导致需求难以为继。
不合理的需求会主动PK,而不是等上线后出问题了,再给你来个马后炮。产品经理虽然主抓业务,有很大的话语权,但开发人员也不能死脑筋,明知道是错的还要去做,一句“都是按产品经理说的做的”也是显得有点不负责任。
给产品人员广开思路,有些方案产品并不能面面俱到,特别是具体的实体场景上。
对原型不吹毛求疵,能表达清楚意思即可,不一定非要高保真。对一些潜台词,即便没写出来,开发小伙伴也能Get到点。
讨论需求时,只讨论需求,不要把“需求会议”最后变成了“技术实现会议”。
关于功能实现
功能严格按照需求来做,按时保质保量完成,当然有歧义或不合理之处能与产品主动沟通处理。
开发完成后,及时提出功能验收,功能可用性强,不会轻易的验出问题,以及潜在的问题
有关联的功能点可以一并调整。很多功能间有着千丝万缕的联系,不能仅从面上理解去调整,冰山背后隐藏的内容有时候更重要。
关于沟通配合
容易沟通交流,这是很关键的一点,人缘好的人,运气都不会太差。
砍需求可以,拿出实际理由,看优先级,看时间节点,砍的合情合理,心服口服。不来一句“这个实现不了”交差,这不是做事的态度。
有些基本的共识,不需要过多交流。这是长期磨合后的默契,可以大大提高做事效率。
这些点抽象出来,其实就两个字:靠谱
,靠谱的人做出的事自然靠谱,让人放心。再次引用下前文中提到的几句话:
从“为人处事”,“待人接物”,“因人成事”等这些成语中可见一斑,先有人,再有事。人要学会变通,既然是同一个团队,就可以站在同一立场出发考虑问题,而不能你站在需求提出方,他站在实施提供方,对立起来。和谐的一对好CP,才能把产品做好。
题图 From Unsplash