工程师犯的最大错误?

22-02-04 banq

Zach Lloyd曾是谷歌的首席工程师,负责谷歌表单团队。之后,他在《时代周刊》担任临时CTO,现在是一家建立基于Rust的终端的创业公司的CEO。
他还在出版一本手册,记录他作为CTO/工程经理的管理风格。
这是他关于他看到的工程师所犯的最大错误的一个帖子的摘要。

概括
Zach 看到工程师犯的最大错误是在循环其他人之前自己做太多工作。
一个典型的场景是这样的
  1. 一位工程师承担了一个大项目。项目越大,情况就越有可能遵循这种模式。
  2. 工程师自己动手,开始尝试弄清楚如何构建这个东西。这通常被称为“探索性工作”,并没有具体的可交付成果。
  3. 几周后,工程师分享了一个更新,并发生了以下一件(或多件)坏事:

  • 他们一直在解决错误的问题,因为这个功能没有被很好地规划限定(规定)。

  • 他们一直在试图找出问题的一个非常具体的部分的解决方案,但这个问题根本不重要,而且产品需求可以很容易地被削减以避免它。
  • 他们设计了一个非常复杂的解决方案,如果他们能早点得到反馈,这个方案就可以大大简化。

  • 工程师开始构建这个东西,并准备为它发出一个非常大的初始 PR。这很糟糕,因为您应该尽可能发送最小的 PR,而对于大功能,您应该从设计/原型开始,而不是 PR。

这显然会浪费大量时间,也可能导致团队做错事。
沉没成本谬误使放弃已经完成的工作很痛苦(即使工作走错了路),团队最终可能会运送错误的东西,因为他们不想吞下沉没成本。

相反,工程师的工作应该与产品团队一起迭代开发。
工程经理应

  • 始终鼓励工程师尽可能快地展示他们的工作。一个项目中的工程师不应该超过一个星期不展示东西和获得反馈。
  • 工程师应该尽可能快地在内部推出一些端到端的东西。这将使每个人都能从用户的角度更好地了解该功能,同时也是了解代码碎片如何组合的最简单方法。
  • 鼓励团队中的每个人给出建设性的反馈。要注意任何过于消极的反馈,因为这不利于开发人员演示他们的工作和迭代工作。

猜你喜欢