做个开发喜欢的产品

发布于:2021-10-16 19:39:36


最*老问产品的同学,如果开发不配合你怎么办?产品与开发处于一种什么关系中?(本文仅从一线开发的角度出发)



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


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

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

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


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


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


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


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


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


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



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



题图?from Unsplash

相关推荐

最新更新

猜你喜欢