作为软件开发经理要避免的错误
在我早期的软件开发生涯中，经过艰苦的努力，我很幸运地比较早地成为了一名软件经理。作为一名新经理，我相对年轻和天真，我的重点一直放在承诺和项目交付上。尽管如此，我还是做得很好，爬上了管理阶梯，成为了一名高级经理，甚至没有意识到作为一名经理，我错过了很多我应该做或不应该做的事情。今天回想起来，当时的我已经达到了底线，但我在很多方面都失败了。在重新开始我的职业生涯并进入一个新的行业，即过去七年的移动开发之后，现在我要回到某种程度的管理。以下是我将在这第二次机会中避免的错误，我非常幸运。作为开发人员，交付什么最重要？我们的项目和截止日期！向老板证明我们的价值和能力的唯一方法是确保我们交付承诺。即使在晋升为主管、经理，后来晋升为高级经理之后，我仍然保持这种心态。我向老板展示了所有项目都按时交付，这给他们留下了深刻的印象。当然，我确实有人在我手下工作。它们是使项目可行并按时交付的资源。当我们失去一个人时，让我们寻找另一个人。是的，我交付了项目，但现在十年后，所有这些项目都过时了。他们是历史。很快，他们中的大多数都会被遗忘。但是十年前与我们共事的人仍然非常活跃。那时我没有虐待他们，我们仍然是朋友。
但后来我问自己：我为让他们成为更好的人投入了多少？我对他们的成长有多少关注，以便他们能够更好地完成他们正在做的事情，而不仅仅是为了让项目顺利进行？作为一个人，我对他们了解多少？他们的热情和抱负是什么？想到这里，我就深深地懊悔。我很失败。我们进行了一对一的交流，在这些交流中，所有的谈话最终都是关于项目、项目、项目。不要误会我的意思，项目很重要。但是，如果我们建立人员并与他们建立联系，项目交付就会变得更加自然。以人为本的关注使我们能够培养人才、与他们建立联系并交付项目。我比较自律。为了知道我的时间花在什么地方，我创建了一个电子表格并记录了我一贯做的事情。出于健康目的，我用一个记录我每天喝了多少升水的日志来测量我每天喝了多少水。有一天，我记得我正在考虑衡量团队的生产力。我们需要衡量一个项目所需的工作量，并量化它随着时间的推移的改进。那时，我们没有一个很好的工具来自动做到这一点。所以我想出了一些流程，让每个开发人员定期为我尽可能准确地记录他们的工作，然后我将它们组合在一个电子表格中。从中，我创建了一个计算一切的公式。开发人员不太高兴，但我用“如果你不能衡量它，你就不能改进它”的话说服了他们。虽然这行得通，而且工作量也不大（对我来说），但开发人员需要付出相当大的努力来记住、定期输入这些值并对其进行测量。然后将这些数据编译并生成一些图表和统计数据。
它根本没有帮助开发人员的生产力，也没有以任何方式减轻他们的工作。我在他们的工作中添加了更多流程，但没有任何好处。开发人员的首要任务是完成项目，而不是提供统计数据。引入的任何流程都应该帮助他们更好地开展项目，而不是让他们承担比实际工作更多的“任务”。如果我们需要测量，我们应该聘请专业人士，他们能够量化开发人员的努力，而不会让他们的生活变得更加艰难。无论如何，最后我回想起我主动收集的数据以衡量生产力，数据最终并没有太大用处，最后，该过程被丢弃了。一切努力都白费了！ “竞争可以提高绩效，”有人告诉我。没有竞争，人们就会自满，后来的表现就会下降。这就是为什么我们看到他们在奥运会上的成绩不断提高的原因，因为竞争很激烈，对吧？这也是我们在学校里学到的。学生在班级中进行排名和定位。这将激励学生努力学习，最终进入更好的班级或学校。如果我们将这种心态应用到软件开发中，我们就会开始引入流程，例如，看看谁创造的错误最少，谁的 PR 审查反馈最少。有些人甚至为那些在代码签入请求中获得最高 PR 审查反馈的人制作“耻辱厅”，以劝阻开发人员不要提交不良代码。或许我们也可以按人查看代码贡献量，除以他们贡献的bug，然后衡量每个开发者的成就。让他们竞争成为最高效的开发人员。
我忘了一件事，工作不是每四年举行一次的奥运会。它也不是一所会在预期时间毕业的学校。开发人员每周工作五天，每天工作八小时。这可能占他们一生的 30%，有些人花在工作上的时间比与家人在一起的时间还多。持续的竞争环境会使工作环境充满敌意。每个人都会开始思考谁将成为他们的下一个竞争对手。会有政治活动、暗中暗杀，甚至更糟的是，建立一个非常不合作和功能失调的团队。这将是一场内战。任何国家都吸取了一个教训：一个内战的国家将落入外部势力的手中。同样，内部竞争功能失调的团队的组织将在外部竞争中失利。因此，我们不要在内部建立竞争。相反，让我们建立友情！让工作场所成为每个人都想来一起工作、一起欢笑、一起建立强烈团队意识的地方。它不仅会让开发人员在工作中更快乐，而且还会建立一个更强大的组织。我从小就有这样一种心态，即默认情况下，期望做得好。是我们的责任！我们应该这样做！没有什么值得称赞的。我认为，作为一个实干家，这是我们应该期待的。我们得到报酬是为了做好工作。作为经理，我害怕“表扬”和“感谢”膨胀。如果我们过于频繁地赞美或感谢某人，它的价值就会越来越小。我认为最终，人们可能会认为这是理所当然的。
所以，我的“感谢”和“表扬”只针对那些非常非常大的成就，即非常了不起的成就。我的期望更高了——鼓励“改进”。过去80分的好会得到“表扬”，现在80分是常态，90分才能得到“表扬”。我几乎不知道，我实际上正在建立一种不欣赏的文化。所做的每一件好事都值得期待。为什么要说“谢谢”？过了一段时间，人们开始只做基本的必需品，因为没有人欣赏它。获得“感谢”的门槛变得如此之高，为什么还要努力实现呢？总能得到大家的赞赏和感谢的，只有少数顶尖的表演者，因为他们是唯一能够不断实现不可能实现的目标。很快，大多数人开始疑惑，为什么还要上班。也许只是为了养家糊口，别无其他。我有机会和一个年轻、聪明的人一起工作。勤奋工作，态度很好，但他从来没有达到顶峰。因此，作为经理，他并没有从我那里得到多少“感激”。我从内心欣赏他，但从不口头上，只是为了公平对待他人。我平等对待他们，除非他们达到高分。有一天，他辞职并去另一个组织工作。几年后，我听说他因某种意外疾病去世了。年轻有为的家伙。可惜他离开得太快了。更糟糕的是，我从未对他所有真诚所做的工作表示感谢，而且我再也没有机会这样做了。我是一个超级勤奋的人。专用。当我开始我的工作生涯时，我会从早上 9 点工作到凌晨 2 点，以完成工作并给我的老板留下深刻印象。当时我工作的大多数组织的回家标准是下午 6 点，虽然正式的工作时间是上午 9 点到下午 5 点。作为一个比别人更努力的勤奋员工，我通常的下班时间是晚上 8 点
我的老板警告我不要这样做，所以我没有筋疲力尽。我没有筋疲力尽，所以我爬上梯子去“成功”，正如前面提到的。我快速成为主管，后来成为经理，然后成为高级经理。我把工作迟到的态度从我作为开发人员的时间带到了我作为高级经理的时间。我需要向所有人“证明”我因为努力工作而获得晋升。我需要成为榜样。我在深夜通过电子邮件跟进我白天错过的事情。我不是故意这样做的，但因为白天开会很多，只有晚上才有时间清理邮件和跟进事情。因此，这成为了一种习惯。我想，“我这样做是为了我的家人，为我的家人赢得一份事业，让我的生活更美好。”我没有意识到我有多少时间忽视了我的家人。我很幸运，我有一个非常理解我的妻子，她在这些时期非常支持我，并且仍然设法抚养我的两个孩子，他们像父亲一样爱护和珍惜我。我不仅忽视了家庭，而且还建立了工作到很晚的文化。没有多少人能跟上我的步伐，但越来越多的人试图跟上我的步伐。当我在晚上发送电子邮件时，我的直接下属有时会感到有压力要立即回复，以表明他们也很敬业。整个工作文化变得像一个工作引擎压力锅。许多人来上班时感觉自己总是处于崩溃的边缘。有些人仍在努力，因为公司“付给他们足够好”。但工作不再令人愉快。来到办公室是一件很辛苦的事。有些人“迟到”只是为了表明他们“在工作”而没有真正工作。他们为组织贡献了 30% 的生命，现在不得不付出更多——这是对家庭和个人生活的权衡。
仔细想想，我作为一个人失败了，因为我没有让别人的生活变得更好。我不仅毁了我的家庭，也毁了其他人的家庭。在考虑流程改进——工具、技术、框架等——用于工作时，我考虑的类别是有效性、效率和成本。开发人员对此的感觉是“次要的”。如果是有效、高效、合理的成本，那就太好了！让我们开始吧。我当时的理论是，当我们更有效率和效率时，开发人员自然应该更快乐。如果他们不是，至少当组织从变革中受益时，我们可以给开发者奖金，他们会“更快乐”。对我来说，当时，人们总是次要的——低于成功的项目交付。太可怕了，现在想想。我第一次听说“开发者幸福”是在我作为开发者第一次过渡到移动开发时。我们提议改用一种新语言，即 Kotlin，它在 2017 年开始流行。在说服管理层使用新语言时，我试图证明该语言在表达能力方面有多棒，因为它是与Java相比简洁的语言。我被问及它在编译时、运行时、潜在风险（将来是否会继续支持等）方面的效率。
很难证明以上所有内容，但我的技术负责人说，“如果 Kotlin 没有明显的缺点，如果这增加了开发人员的幸福感，那么值得考虑。”在考虑更改工具、流程等时，开发人员的幸福感是一个非常重要的考虑因素。如果开发人员喜欢它，他们会尽可能让它工作，除非我们选择了一个可怕的选项。即使我们确实选择了错误，但我们这样做是为了“开发者的幸福”，团队会心甘情愿地纠正这种情况并改善它。我们将从错误中吸取教训，我们“快乐”地犯错，我们也会“快乐”地纠正错误。 “我努力工作；我应得的晋升！”这是一个陷阱，人们在获得他们辛勤工作并获得的东西时很容易陷入困境。我非常谨慎，不要陷入这种“骄傲”。但是当了几年的管理人员，那种享受特殊待遇的“资格”的感觉自然而然就来了。在团队合影中，我应该因为职位而获得“特殊席位”。人们看到我时自然会打招呼，他们知道我的存在。我得到了关注和特殊待遇。作为高级经理，我在许多事情上也享有优先权和排他性。
当我说话时，人们会倾听。我以为我“赢得了它”并且“应得的”。当我改变我的职业生涯时，我不再受到所有的关注。不再享受优质待遇。当我说话时，人们打断并继续前进。我只是一个“噪音”。然后我意识到一个现实：当我担任经理时，很多人对我更好，不是因为我是谁，而纯粹是因为我的职位。事实上，我不值得。如果他们对我很好，我应该感激不尽。即使他们没有，也没关系。永远不要落入感觉“有权”的陷阱，因为我们永远不知道什么时候会有一天我们不再处于这种位置。事实上，正是在我们“不在位”的日子里，我们才能发现真正的朋友和真正有意图的人。对你很好的人，没有任何附加条件。这些是我们可以与之建立长期关系的好人。不管我们处于什么位置，我们都和其他人一样只是普通人。尊重每一个人。永远不要期待独家待遇。毕竟，我们只是暂时生活在这个地球上的同胞。总有一天，一切都会过去。到那时，重要的不是我们受到的待遇有多好，而是对他人的待遇如何。我从一名开发人员开始。我专注于学习技术知识：编程语言、技术、范式、最佳实践。
当我成为一名高级经理时，我现在有经理为我工作。我心想，也许我应该专注于领导力，多读一些管理和领导力方面的书籍。我的主管和经理应该处理所有技术问题；我只是“委托”给他们。我不再有时间处理低级的“技术性东西”了。最初，这是可持续的，因为我“过去”的知识仍然相关，我仍然可以理解开发人员所说的话，等等。但过了一段时间，技术发展了。出现了新的语言，并引入了新的框架。开发人员继续前进。我所理解的不再相关。我仍然尝试使用“旧知识”来链接到所提出和讨论的内容。我开始做出很多假设，有时会过于简单化而不是停留在现实中。我再也无法理解开发人员的痛苦和挑战。我无法理解复杂性使我提出了要求，并提出了不合理的期望。对当时的我来说，任何编程语言都只是一种编程语言。这有什么难的。我们可以在几周内学习任何语言并掌握它，因为我们的 C++ 基础可以带我们去任何地方。现在，当我重新开始我的职业生涯并回到实际开发中时，我现在很感激开发人员的许多艰辛——学习的痛苦和技术挑战。
当开发人员知道我们了解他们并能与他们产生共鸣时，他们就更愿意被领导和指导。他们信任我们的领导。 9. 不要忘记投资于自己。它对你和公司都有好处 我是一个非常敬业的员工。我的时间用于完成项目。我集中时间学习所有内部流程和公司的专有工具。所有大型组织都有自己的流程和工具，所以我的目标是掌握它们。换句话说，我的投资都集中在组织内部。我是一个非常忠诚的员工。如果我花时间学习其他东西，我觉得我不够专注，因为获得的价值并不直接适用于我如何在组织内应用它。了解和理解与我们的工作相关的组织内部流程很重要，但我们应该学习足以满足我们工作所需的知识。相反，我们应该花时间学习我们非常热衷的外部知识和领域。这些知识可能与组织没有直接关系，但它确实让我们开阔了思路，对许多事情进行了更广泛的思考和理解。出于自私的考虑，我们让自己与就业市场保持联系。专业知识在简历上不是很有用。与工业相关的技能组合使一个人继续有销路。
同时，在现实中，我们更广泛的知识也使我们更具创造力，因为我们有能力在寻求改进和解决方案时跳出框框。当我们的组织拥有非常多样化的知识和技能组合时，它就会创新并发展得更好。除了学习，我们应该花时间在生活的其他方面投资于自己，例如健康和情绪健康。通过成为一个更全面的人，它也使我们成为更好的员工，以及更好的角色模式。问题是生活的一部分，管理也是一样：我们是来解决问题的。有时我们称它们为机会。当我们遇到问题时，我们有很多工具可以帮助我们进行根本原因分析。这些工具帮助我们列出导致问题的不同可能性，这非常有帮助。但该工具仅对我们在确定根本原因时的真实性有多大帮助。在一些不容忍错误的组织中，人们会避免列出潜在的根本原因，以反映他们是原因的一部分。作为经理，我的职责是找出问题的原因。也许是结构，也许是外部因素，也许是我们员工的能力，但绝不是我的错误。由于从不将自己视为问题的潜在根源，我有时感到非常无能为力。我继续在我之外寻找什么是“责备”，这样我就可以避免这个问题的“责任”。
过错总是“别人”而不是“自己”。因此，我们并没有真正完全控制。有了这个，如果我们总是将自己排除在图片之外，我们可能会错过问题的实际根本原因。我从我的技术主管那里学到了这一点。有一天，一位专门的开发人员犯了一个看似“愚蠢”的错误，导致我们的软件从外部崩溃。经过一番调查，开发者知道了这个错误，感觉非常糟糕，并遗憾地承认了错误。如果我是经理，也许我会同情开发商，并要求他们以后小心。我可能会要求开发人员帮助找到解决方案以防止将来出现错误。当时我的技术负责人并没有因为开发人员承认错误而感到欣慰，而是承担了全部责任，声称他没有建立安全网来防止这种错误。如果他创建了安全网，这个错误在发布软件之前就不会被发现。当我听到这句话时，我并没有因为他没有建立安全网而鄙视技术负责人。相反，我对技术负责人的尊重增加了。他不仅让开发人员感觉更好，而且还充分承担了责任。在这方面，他感到有能力确保问题得到解决。脱帽致敬！
