• 程序员该如何和产品经理打交道
  • 发布于 2个月前
  • 301 热度
    0 评论
  • 海王星
  • 0 粉丝 19 篇博客
  •   
作为程序员,大家应该都或多或少要跟产品经理打交道。我工作过的公司的产品经理还算比较好说话的,虽然偶尔也会有一些不合理的需求,但起码还能沟通,不至于大打出手。但即便如此,偶尔还是会有小摩擦出现。要么就是产品经理觉得程序猿的能力不行,这也实现不了,那也实现不了,能实现的功能质量又不过关。要么是程序猿觉得产品经理不懂技术,就会瞎扯,明明是小团队却要实现谷歌亚马逊都未必能实现的功能。总之就是双方互相看不上,互挑毛病,轻则言语相讽,重则像上面那个视频一样大打出手。当然,动手打架我是不太建议的,作为程序员我们应该学会智取,尽量采用温和又有力量的方式把产品经理怼得无话可说。接下来我就传授几招我百试不爽的招式给大家,教你如何怼产品经理于无形之中。

1、三思而后行

所谓“三思而后行”,是指不要一拿到需求就开始研究怎么实现,甚至二话不说就开始撸代码。根据我的经验,代码写得越快,后面改的往往就越多。一来你不知道产品经理今天提的需求是不是他的最后方案,二来你也不清楚产品经理的需求有没有什么逻辑漏洞。大多数产品经理都不是技术出身的,所以他们对需求的理解大多停留在UI跟交互层面,但是一个小小的改动会不会对其他功能或逻辑产生影响,他们未必会知道。因此,当你拿到需求的那一刻起,千万不要急着去做需求分析,甚至代码设计,而要先把需求理解透彻,看看需求文档上的需求够不够仔细,有没有什么细节没有描述到。有时需求仅仅只是一张UI图,至于图上的数据怎么来,怎么排序,一页展示多少,这些都没有写清楚,如果你想当然地觉得这需求就该这么实现,因为常识就是这样的,那到最后可能要改的地方就不是一处两处了。在写代码前,强迫产品经理把需求文档写得越详细,对自己越有利,一来可以加深自己对需求的理解,二来白纸黑字写得清清楚楚,防止产品经理后期耍赖。

2、任何需求变更都要文档化

在产品开发中,需求变更是常有的事,有时一个需求一天变几次都有可能。作为开发,我们要推动产品将需求变更文档化,实在不行也要以邮件的形式通知到开发。坚决拒绝“一句话需求”。文档化的最大好处就是可以追踪需求的变更,还可以防止耍赖。因为口头沟通难免会有理解误差,还有一个弊端就是双方说了什么内容没有第三个人知道,后面如果需求改动造成需求延期,难保产品经理不会赖账。将需求变更文档化还有一个好处,就是起码可以证明你在做这个需求上面花了多少工作量,免得领导到时候问起你为什么一周就做了一个需求(其实你是一个需求改了7次),你无话可说。

3、任何需求变更都要周知领导

千万不要什么事都自己背,有时候一个需求的变动影响范围会很大,而你对整个系统的理解未必有领导理解得深,所以凡事多请示领导,后面出了什么事,锅也不用自己全背。再者,如果需求的变动比较大,也可以向领导多申请些资源,比如多分配给你一些人力,或者为你申请一些加班费等。总之,凡事别自己闷头干,多跟领导沟通,如果领导很忙,发一封邮件跟领导说下也是可以的。这并不是邀功的表现,领导通常不太喜欢自作主张的下属,如果自己拿不定主意,那就更要跟领导反映了,免得到时候出了问题不仅要自己背锅,还要挨领导的骂,得不偿失。

最后说一句,不懂产品的开发不是好程序员,程序员不仅仅要知道怎么搬砖,还要知道这砖要搬到哪里,为什么要这么搬。当你把这些事情摸透之后,还怕怼不过产品经理吗?

用户评论