暨程序员吐槽大会落幕，开发人员与产品经理之间再起“爱恨情仇”！_程序员 与 客户的爱恨情仇

       在今年的云栖峰会后，程序员吐槽大会也是满满的亮点，里面程序员于产品经理的吐槽更是让大家笑开了花，其实产品经理与程序员的“积怨”也不是一两天了，相信大家读听过“五个程序员杀了两个产品经理”的故事，虽然故事有点夸大，但却反映了程序员和产品经理之间长久以来的“恩怨”。做为开发中的两个关键角色，程序员和产品经理的冲突在哪里呢？作为一个做了十年技术，同时也有过主导产品经验的程序员，今天和大家分享一下我的理解和体会。

       首先，我们先来总结一下，冲突发生在哪里？

       第一点，产品经理不尊重技术规则，程序员不尊重产品经理的创作用心

       这方面可以总结的例子很多，举一个极端的例子：程序员调了一天的bug，产品经理过来看了看，直接就说一句：“今天什么都没改嘛”，甚至有的产品经理就可能说出这个程序员“很懒”的话来。

 

       Bug有很多种类。很多不懂技术的产品，大多都以为程序员解决的问题都是自己操作上用到的或者看得到的功能，对一些纯技术层面的东西是不大了解，更不懂得做这些事情需要花费的时间。只要界面不变，操作不变，就觉得程序员没有在做事情。对于一些有难点的技术问题，程序员“当机”好几天的情况还是会有发生的，这个需要产品经理多去理解。

       还有一种“Bug越改越多”的情况，这个估计也是不懂技术的产品经理无法理解的。项目开发催得越紧，程序员自顾不暇，出状况的概率也会变高；不经意修改了核心代码的某个部分，连锁效应就会影响到很多关联部分的代码，对正在验收的产品经理来说，就是一夜回到解放前的感觉；甚至会觉得是程序员在“使坏”，故意搞的。

 

       另一方面，程序员跟IT的关联更为密切，对计算机、互联网的产品的了解是随着兴趣、从学习开发语言的时候就开始了，所以对于互联网产品都会有自己的见解。但往往也会因为这样，对产品经理的工作指指点点，甚至把对产品原型的不满情绪带入开发当中。

        同类的问题很多，产品经理若懂得技术，那固然是好事情。但这个要求不大合理，那需要的就是需要双方各自尊重对方的“专业”。产品经理对技术不要盲目揣测，程序员也要尊重产品经理的专业性，多体会产品经理创作产品的用心。

        第二点，关于开发进度

        有的时候，程序员迫于压力和暂时的效率自信，预估的工期本身就是短了的。进度问题已经发生，程序员在努力赶进度的时候，产品经理来了：“为什么这么慢？不是说好什么时候做完的吗？”；或者一个功能一个功能地过“这没做完，这个也没做完”；甚者“最多给你两天，后天一定要做完”。进度没有完成，产品经理的心情可以理解，但是这些有帮助吗？时间用在这些方面了，谁来写代码？搞到程序员心情烦躁，还能指望着效率的提升吗？

 

       进度问题的产生，需要产品经理和程序一起总结，共同探讨解决的方案。但毕竟这是共同完成的一个项目，双方的信任还是必须要有的，另外还是需要把精力用到开发上面，而不是没完没了的争执和总结。

       同时为了确保开发进度，产品经理需要多做一些“细致”的工作。有些产品出的产品原型，是只有“主线”的页面的，看图能理解开发的是个什么样的产品，大致怎样的流程和处理方式。但在开发中间，程序员会发现有很多的“缺失”而走不下去。极端的情况，有直接给程序员产品原型和一两张主要界面的UI图，就让程序员去开发的，各种去操作的界面让程序员去脑补，或者是需要的时候再去要，再去补。这样自然会影响进度。这部分的图可以晚点给，但进入开发之前一定要提前交给程序员。

       关于工期的预估，产品经理也需要和程序员提前进行沟通，不要自己做工期的预估，如果产品经理的经验更丰富些，对于一些程序员过于自信的估计，要有自己的坚持。

       第三点，关于“改动后”的需求

       这个冲突的根源，更多是产品经理和“老板们”关起门来开了个会，脑细胞激荡后，赶出原型和UI图，之后交给程序员的就是“圣旨”。“反正我们就这么定了，你照着开发吧，技术问题自己解决”，更可怕的再来一句“这个改的不多，工期还是按照原来的哦”。

 

      冲突的根源

        产品经理和"老板们”关起门来开了个会,赶出原型和Ul图,之后交给程序员的就是“圣旨”反正我们就这么定了,你照着开发吧

       如果是懂技术的产品经理，对当前开发的程序架构有充分的了解，并且对改动后的需求已经有了明确且可行的技术解决方案，倒也无可厚非。但是，如果到了程序员哪里，真成了要“大动干戈”的事情，那这个怎么去收拾？产品经理再去和“老板们”头脑风暴？估计很多产品经理是不愿意这么去和“老板们”重来一遍的，那么就变成了对程序员的“收买”或者是“战争”。

       我的建议，但凡是涉及到“需求改动”的，产品经理最好是先和程序员讨论一下方案的可行性。尤其是对那种“层级关系”比较分明的公司，这点尤其重要。

       第四点，关于“反技术”的原型设计

       这点我想单独拿出来说一下，因为对于创业公司来说这点尤其重要，“反技术”的设计意味着成本大幅度升高。

        大多数产品由于不懂技术，不清楚不同操作系统有什么不同，iOS有的，非得安卓的APP也要，也不考虑当前可用的开发能力，即便只有一个程序员也要求各种细节的提升和完备，各种“极致”。

         冲突的根源

         iOS有的,非得安卓的APP也要

         各种组件、各种操作都是“新”的,都需要程序员去研发,甚至超出程序员的当前能力要求

         如何避免

         如果要避免出现这种状况,在原型确定前多和程序员沟通是很有必要的。

        对创业项目来说，能充分利用现有的资源，对开发必然会有很大的帮助，但如果一个项目，各种组件、各种操作都是“新”的，都需要程序员去研发，甚至超出程序员的当前能力要求，这似乎就有点不应该了。

       如果要避免出现这种状况，在原型确定前多和程序员沟通是很有必要的。

 

       第五点，关于验收

        大部分的项目团队，验收都很靠后，都会等到beta版本出现之后，才进入验收环节，一旦出现问题，就是各种修改。

        中途介入验收，能提前进入验收环节，把验收分散于整个开发的环节当中，提升产品的品质。但是需要有合适的配套工具，否则也会导致工作量的增加。另外需要转变验收的心态，不能把半成品当成是成品来验收，或者是当成是盯程序员工作进度的工具“这个做了这么多时间，那个简单点的，为什么也要用那么多时间。”等等。

         那么我们该如何改进呢？

          1.中途介入验收,能提前进入验收环节，把验收分散于整

          2.个开发的环节当中

          3.需要有合适的配套工具

          4.不能把半成品当成是成品来验收.当成是盯程序员工作进度的工具

 

       第六点，不得不说的BOSS

       是谁在阻止“程序员”和“产品经理”的相爱？作为产品经理，需要一款产品让自己扬名立万，而这个产品出自你身边的程序员之手； 一款好的产品，也能给程序员带来资历的提升，提升自己的身价。所以，还是好好相爱吧！

        最近准备了一些c/c++相关的资料，有需要的同学可以私聊获取，有什么不懂的也可以随时问。加油，相信自己能够做到。

 

​