产品经理，他们对产品了如指掌。收集需求，管理路线图——给我们派活儿。他们做这些的时候，还保护我们免受“业务”的干扰——不管那是什么意思。
如果你是一位产品经理，尤其是如果你认识我，你现在可能已经在想我会说些什么了。但请别紧张！这只是一篇轻松的文章，你应该知道我真心感激你。
只是，有时候，你们中的一些人在说话或做事上，让人有些无奈又有些好笑。并不是说到了让人无法忍受工作的地步，而是有点像 “你一直这么做真是有点儿可爱” 的感觉
好了，让我们来看看这些习惯。以下是五大无效习惯，看看你有没有中枪！
1. 他们总说 “这很简单”
要开发的时候，他们开口就是：“这个应该很简单吧。” 没错，他们信心满满地说这很简单，但同时又会问有没有经验丰富的人来做。真是逻辑满分。
有些人还会更进一步，连同需求一起提供了一个工时的评估。
我知道他们的意图是想减轻压力——让事情看起来不那么重要。
但问题是，工作总有相应的复杂度，这是无法改变的。工程团队无法让事情变得更简单，也不可能靠意志力让一个虚构的工期变成现实。
提前声明复杂度或工期基本上是多余的——我们需要的是清晰、简洁的需求陈述。
2. 他们 “自己动手” 做设计
在开会的时候，时机一到，他们就会掏出他们制作的原型大作。我们当然知道他们为什么会这么做，关键是，他们又会说：“我只是做了一个基础的 demo ，大家理解我的意思就行了” 。每当这时候，开发都会集体皱眉。
**这个问题在于——大家都知道那个 “基础 demo” 非常有可能就是最终方案。**产品在设计原型时甚至仔细考虑了布局，希望功能能完全按照他们的规格来建造。他们在展示自己的作品时，一定希望大家暗自赞叹：
“做的挺不错的！”
但遗憾的是，这种情况不会发生。相反，场面会有点尴尬，有些人努力忍住不笑。尤其是同一会议中的那些才华横溢的 UX/UI 专家。实际上，有些人甚至在努力忍住不哭。
专业的人做专业的事，设计这块儿还是交给专家吧，产品同学，别太固执。
3. 他们口述编程
需求评审会绝对是进行技术讨论的绝佳机会。这是一个安全的空间，所有想法都受欢迎。但请注意，不要过分自大和愚蠢，以至于浪费大家的时间。
如果工程师们正在努力理解一个相当复杂的问题，而产品经理突然插话，而他却完全没有工程经验——这至少是让人分心的。
举例来说，当开发针对某个功能进行一些深度讨论，觉得功能没那么简单，需要更多时间完成时，产品会打断他们说：“把 cookie 存一下，再刷新页面就行了呀”。 有些建议在基本的逻辑层面是有道理的，但通常和正在讨论的问题的解决方案间差了很多。建议是：与其打断对话，不如给团队一些空间去思考、讨论和解决问题。
请不要再以口述编程的形式来试图指导开发了。
4. 他们推崇抄袭
这些人不想让工程师们浪费时间在真正的工程上。有时候他们想的是：看和竞争对手谁抄的快。
他们甚至会说：“你们可以直接用他们的代码来实现”
当然，从商业的角度我能理解他们的考量及情绪，如果有一个已经存在的东西能用，那当然好。但是，你看到的其他团队的现成解决方案能够无缝嵌入到我们代码库的可能性其实几乎是零。
5. 他们质疑复杂度
预估时间各有各的形式。我们中的一些人会仔细分析 UI，计算出每个部分需要多少天来完成。也有人喜欢按周来预估，还有一些人会给出小、中、大这样的粒度。
但最让人愤怒的是，你给出了预估时间，却遇到了一个疑惑的表情和诸如以下的话：
“这不就是一个简单的页面吗？”
为什么这么侮辱人？因为这只能意味着两件事——“我觉得你很慢”或者“我觉得你在撒谎”。这两个都不是善意的想法。
好了，我现在可以停止抱怨了。其实在与我合作过的产品经理中，带有善意和专业的还是居多的，我们都是一条流水线上的同志，虽然大家做着不同的工作，但却是一个战壕的战友，那些和大家一起创造 “产品” 的日子，真的很难忘！而那些 “不靠谱” 的产品，说实话，我已经把你忘了，因为遇到你们是遗憾，我不想总记得遗憾。
