Ⅰ 产品经理和程序员,如何避免矛盾
产品汪和程序猿
一、产品经理和程序员最讨厌的三句话
产品经理和程序员,就像一对情人,若即若离,有时还会撕逼,和谐的时候一切都好,撕逼的时候两败俱伤。
你知道程序员最讨厌的三句话是什么吗?
1、这个需求很简单,改一下就好了
2、你先大概弄一个,我看看再说
3、我先下班了,加油啊
我想任何一个程序员听到这样的话都会气炸了,不撕逼才怪,你作为程序员会如何回答这三句话?
1、这个需求很简单?你行你来啊!
2、大概先弄一个?请问先生(女士),什么叫大概?
3、你大爷的
你知道产品经理最讨厌的三句话是什么吗?
1、这个需求做不了
2、这个需求工作量太大了,估计要搞3个月
3、这个变更没时间做,往后排吧
产品经理在前端,有用户、有老板、有销售,版本发布的压力很大,听到这样的话估计心情也好不了哪去?
1、这个需求做不了?又不是我提的,还不是那个2B用户提的
2、要做这么长时间?养你们有什么用,还不如我自己来
3、变更没时间搞?随便,等老板来拍你吧。
二、产品经理和程序员本质上的差异是什么
奶爸干过程序员,也干过项产品经理,深知这两类工作的差异,各有各的不易。
总体上来看,做产品更侧重于创造和方案能力,不需要精密的逻辑,所以试错成本相对比较低,大不了改改原型,改改方案,这个成本是可承受的。
程序员的工作是非常精密的逻辑,一个看似很小的变更有可能对代码产生很大的影响,所以试错成本非常高,弄不好可能会因为需求的变化导致系统的重构,这时候程序员的挫败感是可想而知的。
三、产品经理和程序员友好相处的清单
1、产品经理收集需求后,在需求分析阶段,需要把一些不合理的需求尽量和用户沟通去掉,避免不合理需求造成产品发布时间延迟和没有必要的成本浪费,当然这需要产品经理去说服用户,不能只做用户的传声筒。
2、需求分析时,产品经理应该根据经验,敏锐的发现一些在技术层面实现有困难的需求,及时让研发介入,评估技术可行性,避免后续出现需求定下来,研发说做不了的情况。
当然这需要我们的产品经理对软件技术架构有一定了解和预判能力,你不能所有的需求都要在需求分析阶段让研发介入,这个成本也是极高的,所以要把握好这个度也是一项能力。
3、原型还是需求沟通的最好方式,这样是避免产品和研发在需求理解上有差异的最好手段,只靠写一些文字的需求说明书很难达到好的效果。
但这里面要注意一点,产品经理绘制出来的原型一般是非高保真原型,是为了更好的沟通需要,所以不能完全按照原型做,需要基于我们自己的前台架构进行定制。
4、需求评审的时候,研发可能会有一些不一样的意见,他们做了很多年的开发,会有很多好的经验,好的经验要虚心接受,不能觉得自己是产品就是老大,就是要按我说的做,这样很容易造成矛盾,求同存异,目标一致,这个是最好的结果。
5、研发说这个需求做不了的时候,有两种情况,一个是觉得这个需求实现起来比较麻烦,故意骗你;另外一种情况就是他的知识盲区,他可能确实不知道这个事能做。
产品经理需要有能力和研发进行谈判,比如采用类比法(类似的需求在其它项目上咱们就做过),比如去找架构师探讨技术可行性。
6、研发有时候评估的工作量会比较大,整个上线计划拉的比较长,产品经理可以要求研发出详细的资源配置清单,这样能清楚的看到一个需求被分解成了多少个研发任务,每个任务的起止时间,由谁负责完成。这样产品经理大概能看出任务的前后置关系是否合理?工作量是否合理等。
产品经理绝不能说,这么简单怎么要搞这么长时间,类似的话一出,绝对会激怒对方,还是要有理有据进行谈判。
如果实在无法压缩工作量,如果增加人力能解决问题的话,可以考虑找领导申请资源。如果还是不行就要砍需求或者改方案了。
7、在版本计划定好的情况,尽量不加需求,这样很容易打乱开发的节奏,如果一定要加进来,一定要和研发说清楚,这个是用户领导或者老板的强制要求,转移矛盾。如果可以的话,增加了需求尽量推迟上线计划。
8、开发过程中如果需求有改动,需要及时更新需求文档,同时发给我们的研发同学,否则只是靠嘴说一下,很可能研发的同事就不做了,所以一定要落到纸面上。
9、上线的时候要坚持和研发同事一起加班,这样大家才是一个团队,赢了一起狂,输了一起扛。
10、最后一点,就是要多交流,没有什么问题是一顿火锅解决不了的,大家关系好了,很多事情沟通起来自然容易,而且也会更信任对方,这样就万事OK了。
Ⅱ 生产技术部如何处理好与生产部、品质部的关系
产品在生产时,这个产品的一系列数据按理生产技术部都已有明确的数据了!生产部只按技术部的数据来生产就行了,而品质部是为了检验产品的好坏,也是根据技术部提供的数据来检验! 所以技术部自己的工作做到位,其它的部门不配合都不行,产品的技术开发数据正确,出了问题那就不是技术部的问题了! 至于各部门之间人与人之间的交流,我认为平时咱们以一种平等和蔼的态度跟人交流,我想没有人会很难相处的,除非那个人是存心无理取闹!