产品经理不靠谱怎么办

一、产品和开发之争

开发和产品宿命的争斗由来已久，倏然就是一对天敌。

1.1 平安产品掐架事件

在刚毕业那会，还不知道产品具体是干啥的时候，就听到了不少产品和开发打架的事情。印象最深的，就是平安产品开发掐架事件了。起因是产品经理提了一个需求，要求APP开发人员可以做到根据用户的手机壳来改变手机软件主题，面对这样的需求，开发自然是要起义的。

真假分辨不是重点，从争论的热点而言可知，就这件事情而言，争论的原因是需求不符合常理。开发做的事情只是对世界建模而不是无中生有。而我们作为开发，平时和产品决斗最多的情况，是对于时间资源之争。产品混乱的开发节奏，不符合逻辑的需求，不合理的时间安排，不重点的优先级安排。

而且很多时候，产品的职位是要比开发的高的，话语权更加的高，会让他们更加的肆无忌惮，可恨！

拿我之前公司的真实的例子来:

• 
  
• 产品所谓的需求文档都是短短几句话
  
• 一个迭代周期内从来没有按照原订计划上线计划的功能，各种小需求，拍脑袋的需求随意插入。
  

前者，总监对于产品这种行为的解释是需要开发和产品共同去参与设计，相互查缺补漏。尚且不论开发是否能够得到第一手信息，时间也是不够的，重要的是工资它不涨。

后者直接导致了开发的加班。

1.2 为什么会有这些不靠谱的产品经理呢？

根本还是我的问题，我没有能力轻易的选择自己工作环境🙃

其次呢？是他们专业程度不够，被培训机构忽悠，人人都是产品经理，门槛低工资还高，上可以直接对话老板，下可以指挥程序员，所以导致了什么阿猫阿狗都涌入。

矛盾的是，正好相反，产品的门槛其实很高的。

他们需要很强逻辑能力, 整理出来的需求需要逻辑自洽, 需要思考用户的操作体验,需要思考人力资源的分配。

面对老板、市场、业务方抛来的‘建议’，能够甄别出什么是功能，什么是需求，然后制定出合理的优先级。在敏捷项目中，还要制定迭代的计划，顶得住上面的压力，压得服下面的开发。

其中涉及到的专业技能有社会心理学、管理学、软件工程管理、用户画像学、以及一定的开发知识、一定的设计知识、一定的运营知识。

涉猎之广，以及程度之深，不是程序员用计算机能够模拟的，不然为什么会有智障的小爱同学、小冰同学、siri。

1.3 根本的目的是为了解决问题

当然，本篇文章以及《10x程序员》目的并不是为了抨击产品多么多么的不靠谱。就像郑晔老师所说，如果从不靠谱的数量来说，程序员是比产品多得多得。

第一是因为程序员基数就比产品的多，第二也是因为万物皆可转码导致的。培训班培养几个月就出来工作了，他能有多强的编程能力？

只是从整个市场来看，当然还是有很多转行的，培训出来的很强的人。

这篇文章的目的，是为了解决点那个我们碰到这些不靠谱的产品经理的时候，我们应该如何怎么办？

首先要知道产品和开发的战争是因何而战的。

二、争论的真相是什么

2.1 争论的原因

产品和开发相互攻击是解决不了任何问题的。为了解决争斗，我们首先需要知道到底是争什么？为何而争。方能对症下药。

我们常常会出现下面这样的一个场景：

产品：我们需要一个单点登录的界面。输入账号密码就可以进行我们的界面。

开发：好的

一天时间，界面和交互逻辑，接口哗哗做完。

开发：东西做完了，你来看看

产品：？？？ 验证码呢？

开发：你又没说

产品：这个不是常识么？

开发：。。。。

又是半天时间，验证码搞定

产品：这个项目是放在门户下面，登录的功能不是应该在门户上面做么？现在跳转到别的项目还需要重新登陆，你怎么想的？

开发：顶你个肺，一开始怎么不说是这个场景

产品：你又没问。。。

🔪 🙎‍♂️

这是由于双方信息不同步的导致的。如果一开始开发就问：

• 
  
• 这个需求的用户是谁？
  
• 这个需求的使用场景在哪里？
  

我想问题就会拖到后面了。开发必须要有自己的独立思考，多问几个为什么，才能够减少掉进坑中的次数。

双方的知识储备不一样，双方掌握的信息不一样，得到的结论自然也不一样。

所以这就需要我们在一个信息平台上，才能够沟通得有效率。

而这就需要我们双方都能有一个很好的沟通能力。也需要我们开发多张十个心眼，默认产品都是不靠谱的。多问几个为什么，不要害怕问题幼稚。如果产品都能够一一回应，而且逻辑自洽的话，那么恭喜你，你碰到了一个不错的产品。

有一句话说得好，当你和一个人谈话谈得很开心的时候，很可能是因为对方的段位比你高，他在向下兼容。

当然，出现上面的那些问题，也由于现在解决的问题不再是明确的，常常范围模糊，别说产品自己，业务用户也不知道自己想要什么？这个无形中提高了产品的门槛，还提高了需要软件设计师的架构能力，需要提前布局。

软件开发的主流由面向确定性问题，逐渐变成了面向不确定性问题。为了应付这个问题，敏捷开发这个最佳实践就应运而生。到了中国就变成了“田园敏捷”🐶，需求不明确，所有需求都是P0级。
为了解决这个问题，我们产品和开发能够在有效的资源中做些什么呢？这就不得不提到敏捷开发中两个很重要的阶段，需求澄清和需求反澄清，如果是开发负责人还需要参加需求准入。

2.2 沟通的真正目的是什么

先简单的介绍一些敏捷开发流程：

两周一迭代，在进入开发之前，产品内部需要先过一遍需求，随后根据列的需求和开发负责人讨论需求准入，开发负责人会根据人力资源来和产品共同商量，这个迭代可以上的内容。

到需求澄清，这个是全体人员都参加，产品一一说需求的逻辑，开发可以提问。

之后就到了需求反澄清，这个阶段是开发在说自己对于需求的开发，以及开发的思路。随后进入开发阶段。开发完成，向产品show case, 测试通过之后前后端封版。

封完版提发布工单，然后才进行反版。在这个阶段还包括了每日的站会过需求，还有发版之后的回顾会。

如时间表下图：

从图片可以看到对于开发两个重要的节点，一个是需求澄清，另外一个是需求反澄清。前者是产品在说，开发问。后者是开发在说，产品再问。这两个就是一个很好的拉平双方认知的机会。
这两个沟通的机会至关重要，是有效减少之后扯皮的关键节点。这就需要我们知道如何有效的进行沟通了。

唯心主义不是贬义，而是一个客观的事实。具体表现就在于，这个客观世界和我们所想象的总是不一样的。同样的，由于每个人认知的世界是不一样的，所以信息的传递是会衰减的，你不可能把你理解的信息 100% 传递给另外一个人，而这中间，如何传递，也就是如何描述将直接决定衰减的比例。

可以根据书中信息论模型来进行解释：

幻化为人的沟通的话。人的脑子就是信源，携带着信息到发送器，发送器通过自己的表达通过声带发送给对方，对方接受到信息还需要转译一遍进行自己的大脑。在传送的中间过程，还有噪声源，这个噪声源可以是物理环境认为的嘈杂，也可以认为是双方因为地位的不同，导致的思维方式的不同的噪声。

根据这个例子，可以用下面这张图来表示上面争论的原因：

扮演不同角色的时候，我们的思考模式是不同的。上图是产品作为信源，而开发作为信宿，反之亦然。

作为信源的话，我们将自己脑中的信息通过嘴巴表达出去的过程，是受限于知识储备和表达能力的。也就是说如果我们的知识储备足够的多，表达能力足够的强的话，在发送信息到对方的闹钟的时候，偏差自然也会更加的小。

作为信宿的话，我们开发作为接受的一方，需要提高自己的知识边界，主要是了解业务的前因后果，尽可能的提升解码的能力。

综上所述，我们沟通的目的是为了同步信息，减少对于需求的理解的偏差。而沟通出来的结果，就是共同确立一个验收的标准。

只有验收的标准确定下来之后，才可以最到限度的减少后期扯皮的可能性。

那么我们作为开发需要怎么做呢？

2.3 开发需要做什么

开发在需求澄清的时候，其他问题都可以不问，但是这两个问题一定要搞清楚。

1. 
   
2. 需求的背景是什么
   
3. 需求能够给用户带来什么业务的价值
   

前者是为了理解业务的前因后果，当自己当成产品经理，让需求的逻辑能够自洽。后者是换位自己作为一个用户，以用户的视角来看问题。这也和我们公司以用户导向的价值观相符。

在需求反澄清的时候，作为一个前端工程师，我们最低限度的需要出两个东西，一个是API的设计文档，另外一个就是数据走向图。这个数据走向图我的前一篇文章《vue的业务开发如何进行组件化》中进行过阐述，具体可以去那篇文章看看。

敏捷开发不代表文档的缺失。

我曾经把产品问懵逼之后，把需求都砍了一大半。也间接实现了最好维护的代码。

我的目的不是为了砍需求，而是为了写出全世界最好维护的代码，即不用的代码。

三、抛弃固有印象

在程序员眼里：

• 
  
• 产品一般都没逻辑、缺乏交流基础（没常识）、没能力没主见；
  

在产品经理眼里：

• 
  
• 程序员通常属于严重沟通障碍、缺乏用户和产品意识、只考虑技术、没有大局观。
  

抛弃这些固有的刻板印象，沟通和理解更为重要。作为开发不能因为一时的占了上风，就沾沾自喜，大快人心，觉得压了产品一头。爽归爽了，你的工资可还是没动的。班还是要加的。所以解决问题才是主要的目的，不管工作中，还是生活中。
而这就要求我们：

• 
  
• 加强专业知识的学习，
  
• 增加对彼此工作领域的认知，
  
• 用逻辑而非借口来说服对方。
  

开发可以去考考PMP证书，虽然都说没有含金量，但是你得过了才有资格来说这句话。作为前端还可以去学学基础的美学设计。总的来说就是要扩展自己的知识边界。

而且，大家都是打工人，成年人了，我们要知道矛盾的根源是什么？真的是产品的不靠谱和开发的沟通障碍么？或许不见得。

四、矛盾的根源

之前刷知乎看到过程墨大佬的一段话，记了下来：

在我国，产品经理和研发工程师的核心冲突，是“有限的开发资源”与“无限制的目标”之间的矛盾。
“有限的开发资源”在研发工程师这一边，人力是有限的，人的工作时间是有限的，人的耐心是有限的，人能够做的事情是有限的。

“无限制的目标”在产品经理这一边，无数量限制的需求变更，无规则限制的产品设计流程，无时间限制的工期规划……

怎么解决？

要么提供更多的开发资源，也就是招更多更合格的工程师；要么就让产品经理对自己的行为做更多限制，让产品设计和规划按照客观规律办事。

当然，说到底两者之间的矛盾的根源是我国特色资本主义的内部矛盾，一方面想让团队跑得快，一方面又没有本事进行合理管理，最后产品经理和程序员打架，世人在骂产品经理无能程序员暴躁，其实归根结底是上面人无能而已。

五、一个问题

我之前面试，被问我这么一个问题：

一个需求你评估完成的时间需要两周,但是产品最多只能给你一周的时间,你怎么办?

那场面试虽然过了，但是我没有收到对于我说的答案的评价。所以很好奇大家的答案是什么😂