软件工程师 产品经理_经理应该停止对工程师说的20件事

软件工程师 产品经理

这篇文章直接回复了我最近读过的标题为“ 工程师应该停止说的20件事 ”的文章。当我读完这篇文章时，我感到非常沮丧和恼怒，以至于我不敢相信自己的眼睛。 我仍然想知道什么样的经理会提出这些想法，以及他们的工程师在阅读了这篇文章后会如何React。

所有这20个“邪恶的”工程师短语都不是“技术怪癖”，而且它们是如此清晰，以至于即使是一年级的学生也很容易理解它们的含义。 您不理解该句子的哪一部分：“该功能的投资回报率是多少？” 老实说，这是经理在向开发团队放下荒谬的要求之前应该解决的一个问题。 您有工程师问这样的事情，您应该感到非常幸运！ 而且，其中一些对我来说看起来很奇怪，在我与软件开发团队合作的16年中，我从未听说过它们，因此我将尽力弄清它们的含义。

但是对我来说最重要的问题是，何时以及为什么工程师被迫说出那些“糟糕”和“小便”的东西。 让我们将它们与每个句子的根本原因（以粗体显示）并排在一起，并附上我的一些评论：

1. 我们不按日期工作：
   “ 我已向客户保证，一切将在12月25日准备就绪。 现在我们需要谈谈他们的要求。 “
   当然，如果我们没有固定的范围，则我们不会针对日期进行处理。
2. 我们需要更多资源：
   “ 你们两个将构建，测试，部署和支持我们的新ERP系统 ”
3. 质量，速度，成本-选择两个。 今天是星期五下午：
   “ 我希望客户在星期一之前要求所有这些功能，但我们不能支付加班费。 哦，我差点忘了。 请保持项目的最高质量（单元测试，复杂性，编码规则）。 此外，这是您的责任！ “
4. 该功能的投资回报率是多少：
   “ 成千上万的客户想要一个“小巧”和“酷”的新功能，当需要从学校接孩子时，该功能会向他发送通知。
   嗯
5. 我们不需要报告：
   “ 我希望每周都能在我的收件箱中获得精益求精，其中包含有关您的活动的详细报告 ”。
   醒来！ 有很多方法可以跟踪开发人员的工作，并且绝对“报告”不是正确的方法。
6. 客户实际上并不意味着：
   “ 客户希望每次他们按字母'A'而不是字母'S'时系统弹出警报 ”。
7. 他们可以使用命令行：
   “ 我'知道'您还有更多重要的事情要做，但是我们能否在明天之前实现一个带有一些漂亮按钮和说明的屏幕，以便客户可以触发pdf格式的每周报告？ ”。
8. 他们可以使用API​​： 请参阅＃7
9. 你不会的 实际上，正确的答案是：“您甚至不想理解”或“您不想理解”。
   “ 这是我第三次问您为什么要根据客户的需求编写无错误的软件如此困难！ ” 。
   注意：没有人知道客户想要什么，甚至没有客户！
10. 太好了： 请参阅＃4
11. 我们之前尝试过：
    “ 您能否将他们的“旧版”系统与我们的ERP集成？ 我知道他们没有提供任何访问数据的方式，但是您是专家，对吗？ “
12. 我不理解要求（您已阅读要求吗？否）：
    “ 为什么很难根据客户要求编写代码。 您可以在与一些最终用户进行面谈时所写的手写笔记中，在我发送给您的最近6封电子邮件以及与您共享的google文档中找到它们！ ”。
    这些“要求”中有99％有争议且缺乏明确性。
13. 技术债务：
    “ 我不想听到任何有关代码质量的信息。 只是在这里和那里扔一些代码以使这项工作！ “
    认真吗 您不希望工程师谈论技术债务吗？ 更糟糕的是，您不了解什么是技术债务？
14. 您可以对此进行质量检查吗？ –好的，也许这个不清楚。 是否“可以复制吗？” 有道理吗
    “ 客户声称该系统没有明显的理由随机地不允许他们删除订单！ “
15. 这不是一个错误，这是一个功能：
    “ 我知道我们还没有讨论过，但是当用户删除客户记录时，能否请您添加一个双重确认对话框？ 我们需要尽快修复此错误”
16. 这违反了CAP定理。 好的，下面这句话是唯一可以被视为“混淆”的句子：
    “ 我们的新企业平台将通过Web服务调用被成千上万的客户使用。 因此，实现100％的可用性，数据一致性并同时继续运行（即使有任意消息丢失）也非常重要。 “
17. 鲁伯·戈德堡：
    “ 让我们构建一个日历应用程序，它使用分布式NoSQL数据库，soap＆rest Web服务，弹性搜索，HTML5响应式设计，Node.js，SPRING MVC等等。 ”
    KISS（保持愚蠢）对您有意义吗？
18. 这就是平台团队的责任：
    “ 从数据库中获取数据时，我们可以添加缓存机制吗？ ”。
    当存在由“平台”组成的内部开发的库和框架时，这是完全有效的答复。 通常，在这种情况下，公司会有专门的团队来维护平台。
19. 这将需要30分：
    “实施此功能需要多长时间？”
    为什么“需要一个星期对您来说更有意义？” 因为如果答应的时间还没有准备好，您将拉动扳机吗？ 那可能会发生的技术困难呢？ 随机的任务会延迟我吗？ 还是任何其他外部因素会让我失去一些时间？ 30分是一个非常体面的答案。 您是否喜欢这样的内容：“此功能重30磅？” 我告诉你的是，我可以根据我以前的经验来估计此功能的大小，但不能保证交付时间。 这很难遵循吗？
20. 我们为什么要这样做？ （ 请参阅＃4或＃6 ）

现在您已经了解了开发人员的观点，谁是赢家？ 经理还是工程师？ 没有人！！ 双方都应努力理解彼此，并采取一种通用的沟通方式。 他们不是敌人吗？ 他们有一个共同的目标，那就是（或者应该）为最终用户/客户提供有效和有用的软件。

翻译自: https://www.javacodegeeks.com/2014/10/20-or-so-things-managers-should-stop-saying-to-engineers.html

软件工程师 产品经理