……我明白这是从哪里来的，但这也挺让人难过的。以我的经验来看，这往往会创造出工程师在其中地位不如经理或产品经理的环境：我们只是负责“交付”，而不能独立做出任何真正意义上的决定，除了很小的范围。我们的决策时间跨度通常以天或周来计算，而在我见过的最好的团队中，这通常是按月、季度或年计算的。这看起来有些反直觉，但你完全可以赋予工程师真正的个人责任感，而不会造成单一故障点或脆弱的系统。这取决于有其他形式的缓冲空间，鼓励高质量的工作，并给予人们很大的空间，让他们灵活地调整自己的工作内容。人们仍然有真正的责任感，可以独立做出长期决策，但他们也会以非正式的方式协作，分享隐性知识，这样其他人就可以在需要时介入、帮忙甚至接管。我有点模糊，但我想说的是，我以前见过这种情况，当我再次看到它时，我会认出来的。……
源讨论对“普通”工程师的赞美原帖 113 条评论 · 导入时统计把你的经验，加入这段讨论。
工程以外的人无法立即认可工程师在长期决策上的贡献。他们没有能力知道该奖励什么。 我进一步认为，即使在工程领域内，团队外的人也无法立即奖励那些长期价值仅对团队内部有意义的工作，原因相同：他们不知道你所做的工作是否真的有价值，还是只是表面上看起来像那些通常具有长期价值的工作。 如果你对自己的长期决策和如何利用空闲时间足够自信，那么你应该能接受因交付成果而获得的奖励，因为你预期你的长期工作会在未来的交付和奖励中得到回报。
完整原文我很难看出你所说的你重视的东西和我所说的我重视的东西有什么不同（作者在此）。
完整原文我认为重写是编写软件的重要部分，也是所谓"敏捷"的一部分，意思是你可以进去编写一个非常简单的原型，而不太考虑长期架构，知道需求可能会改变，而且你可能不会一次就得到正确的设计。 编码就像写作一样，有时候先写一个粗糙的初稿，然后再写一个更好的第二稿，比费尽心思在第一次就写好要快得多。初稿是生成性的。它的目的不是要好，而是让你快速构建出一些东西，并让你探索问题，这样你就能知道在最终架构中需要考虑哪些边缘情况。 但这种工作方式永远无法通过管理层，因为一旦你向他们展示一个工作的PR，…
完整原文我以前也持有这种想法，我仍然同意工程师可以拥有个人责任。不幸的是，很多工程师其实并不想要这种责任。我认为大多数甚至所有工程师都对在团队边界上的责任感到舒适，但很多人并不关心更远的地方。这只是一个工作。 在个人工程师边界上的个人责任可能会在团队或组织内部产生不信任，但通常会疏远那些喜欢自己的工作但不试图领导的人，至少在责任所涉及的方面是这样。在这种混合环境中，某人几乎总是没有自主权。有时没有人有自主权。谁想要这样的情况呢？ 相比之下，给团队自主权和责任要简单而有效得多，通常是因为有了经理或主管的动态。 简单来说，个人层面有太多失败的模式，…
完整原文>我们只是负责"交付" 责任从来没有给我带来过任何好处，只是更多的麻烦。我只是在这里把事情放在页面上。 我们必须为额外的责任收费。经理/高管的薪资随着他们负责的人数而增加，没有理由不给开发人员也这样做。
完整原文同意你可以说确实存在真正的个人所有权。不仅如此，我认为这才是真正「高效」的唯一方式。 但我觉得这并不是重点。 个人是不可替代的，但团队成员却可以是——或者至少可以，这取决于你如何构建你的团队。 而随着组织的发展，你希望在团队层面有可预测性。省略了一些推理步骤，这意味着需要有一定可替代性的团队成员，以提供冗余。 这里的工程类比是可靠性和效率之间的权衡。通过增加冗余可以提高系统的可靠性。通过去除冗余可以提高系统的效率。
完整原文这非常简单。停止雇佣/晋升那些不懂这份工作的管理人员。这在其他每个行业都非常常见，我和许多人都会一直这么说。 当「足够好」是一个非常低的标准时，这似乎并不重要。
完整原文这在小地方确实有效，但有很多原因，也有很多书籍解释了为什么这在大多数组织中无法扩展或有效。 > 我有点模糊，但我要说的就是，我以前见过这种情况，当我再次看到时我会知道。 在谈论组织设计时，保持模糊是行不通的，告诉人们他们不需要围绕系统来组建团队是有点不负责任的
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。