pm 告诉自己的 40+个谎言
pm 告诉自己的 40+个谎言
原文：https://medium.com/hackernoon/40-lies-pms-tell-themselves-20be00570dc
我想我应该从这里开始。如果你能在评论中发表意见，我会很高兴。没有判断(我已经成为许多这类事件的受害者)。
http://www.kera.org/2014/07/22/delusional-perspective/
- 我们可以预测未来
- 我们可以冒充我们的顾客
- 可用性测试失败的客户不具有代表性
- 喜欢新功能的客户很有代表性
- 我们会在几个月后再回来讨论
- 我们的路线图将在一个多月内保持准确
- 这个故事已经准备好被评估了
- QA 没有消息就是好消息
- 默认情况下，团队会乐意给你建设性的反馈
- 客户会迫不及待地采用新功能
- 团队规模扩大一倍，产出也会增加一倍
- 应用程序已经死了。桌面已经死了。反应灵敏已经死了。[———]死了
- 销售人员了解如何销售新功能
- 我们知道如何销售新功能
- 产品复杂性随着所服务的人物角色数量的增加而线性增长
- 最终我们将能够利用所有这些数据！
- 这是“执行的全部”
- 只有你有(并且需要)大局
- 我们真的要让它向后兼容
- 开发人员最关心的是干净的代码和关于 PRs 的争论。他们不太在乎工作的影响
- 客户将会用我们的 API 做各种有趣的事情，我们将会轻松地将所有这些产品化
- 人们会阅读你长篇大论、雄辩滔滔的电子邮件
- 我们会在技术债务使所有的前进变得不可能之前得到预警
- 关键时刻是健康的
- 可用性在企业中并不重要
- 这个特殊的客户是有代表性的。为他们建造，剩下的就容易了
- 我们完成这笔交易必须做的工作“最终将不得不建立”
- 演示将按预期工作
- 我们只需要“让开发人员保持专注”,不受干扰，一切都会好的
- 我们可以“将该产品置于维护模式”并将所有资源转移到其他方面
- 如果我们给他们太多的自由，开发者将会“变得无赖”。他们需要被控制
- 我们知道一年后我们的竞争对手会是谁
- 开发者不成比例地缺乏同情心
- 我们的想法是最好的想法，我们的方式是最好的方式，我们的设计是最好的设计
- 向团队撒一个善意的谎言来让他们继续工作是可以的
- 客户现在可能会因为更新而受苦，但以后会看到我们的天才
- 成为史蒂夫·乔布斯那样的混蛋是天才的标志
- 定制工作可以很容易地产品化
- 我们可以开始下一部史诗，而反馈正从上一部史诗慢慢传来
- 没有故事的开发者是在浪费时间
更新(来自评论)
41.如果我们建造了它，他们就会来
42.销售不知道客户想要什么
43.一个不开心的客户只是“错误类型的客户”；反正我们也不是为他们造的…
44.在收到 ____ 的回复之前，我们没有别的办法。(让自己休息一下的最佳方式！:D)
45.我们将在 X-date 发布 n 个特性！
46.这很简单，我们不需要任何常见问题解答/文档。
47.很明显，我们不需要用户测试。
48.有很多用户不喜欢的东西。与其修复每一个，我们应该只是重新架构它。
