给开发团队领导的建议

这篇文章分享了我在软件公司担任开发团队负责人期间的经验教训。我的目标是让其他团队负责人对自己的角色更有信心，并鼓励那些正在考虑担任这个职位的开发人员勇往直前，实现跨越。

我的经历

我担任 Sitecore 架构师和开发主管领导软件开发团队已有三年多。我之前的团队有 9 名后端 .NET/Sitecore 开发人员和 2 名前端开发人员。我们分布在全球各地——最早开始工作是格林威治标准时间 (GMT)+2，最晚开始工作是格林威治标准时间 (GMT)-8。在一个大型远程团队中工作很有挑战性，但我们成功地完成了企业客户设定的非常紧迫的截止日期，最终批准了一份重要的后续工作路线图。

在一个典型的项目中，我需要审查业务需求、编写技术需求、选择技术和框架、提供估算、指导实施、审查代码并提供反馈、编写文档、培训和指导开发人员、决定哪些开发人员做哪些工作、让项目经理了解每个人的工作进度、管理部署、就未来工作的方向和策略咨询客户、参加（许多）会议，哦，对了……还要编写代码。

我们总是在截止日期前努力工作，因此确保所有工作流程按计划进行至关重要。如果有什么事情严重阻碍了我们的进度，无论是内部资源问题还是外部因素，我都需要介入并帮助解决，以确保一切顺利进行。

除了亲自领导团队之外，我还担任过其他领导领导的团队的成员，有些是技术人员，有些是非技术人员。

第一部分 - 内在技能

本部分旨在塑造您的个性和行为，使您成为一名伟大的领导者 - 增强信心，注意反馈，寻找资源以了解更多有关领导力的知识等。

你不是冒名顶替者

我承认，虽然我的团队非常成功，但那种鬼鬼祟祟的冒名顶替综合症时不时地会冒出来踢我一脚。这是因为我和许多拥有相同头衔的人一样，之所以能晋升到领导职位，是因为我是一个能力强、自给自足的开发人员，学习能力强，而且善于沟通技术概念。我拥有计算机科学学位，但从未接受过任何关于如何管理或领导他人的正式培训。这是我在前进的道路上必须不断摸索的东西。

你可能已经从上面的“我的经历”部分注意到，作为团队负责人，我做的大部分工作都涉及管理工作流以及与团队进行口头或书面沟通。而写代码——这件让我晋升的事情，也是我知道自己擅长的事情——却是我做得最少的。因此，我患上了冒名顶替综合症。

如果你是一位担任团队领导的开发人员，却发现自己像个冒名顶替者——这意味着你会质疑自己是否具备管理能力，并担心自己做得是否正确——那么我可以向你保证，你绝对不是冒名顶替者。通常来说，如果领导团队的是经验丰富的开发人员，并且正在学习如何管理，那么团队的绩效会比领导那些拥有管理经验但不了解开发人员在做什么的领导更好。

所以我的建议是，不要让内心那些对你资历的攻击喋喋不休。提醒自己，提拔你的人知道自己在做什么，他们一定知道你有能力成长为领导者，即使你缺乏经验。这就引出了下一部分……

领导力是一种后天习得的技能

没有人天生就有领导天赋。你生活中所有那些看似轻松上手的优秀领导者，都和你一样，一开始就不断进步。进步源于有意识地留意那些能够激励他人、提升绩效的行为，并付诸实践。如果你认为自己并非优秀领导者，但你身处领导岗位，也不必担心。你可以不断提升，你可以练习那些对优秀领导者至关重要的特定沟通技巧。

理想的学习方式是通过导师，无论是在公司还是在家庭。大多数领导技能与行业无关，所以即使你的导师不是开发人员也没关系。如果你没有合适的导师，或者你认为每周与导师会面不够，那么最好的办法就是在亚马逊上查找相关主题并订购一些书籍。可以向同事寻求推荐（布琳·布朗的《敢于领导》就很棒）。

决定接受谁的反馈……

作为开发主管，有一件事我可以肯定地说：我从来不缺那些没有像我一样亲身经历的人的批评和意见。作为团队的代表，我总是第一个站出来接受各种反馈，有建设性的，也有居高临下的。

我的建议是，要明确谁的意见重要。不可能让所有人都满意。你必须负责项目的实施，并且要对你的团队、你的老板以及你的业务利益相关者负责。除此之外，要把反馈当作建议。这样可以最大限度地减少所有（有时相互矛盾的）评论和请求给你带来的压力和困惑。

然后乐于接受反馈

一旦你决定了你重视谁的意见，就要有意识地努力让自己接受反馈。

首先，这些人可能不知道你想听取他们的意见，所以你可能需要主动征求他们的意见。其次，并非每个人都擅长提供反馈。例如，我认识一位非常聪明的开发人员，但他非常不擅长撰写拉取请求评论。他质疑我团队代码的方式非常尖刻，有时甚至很粗鲁。虽然他的表达方式本来可以更好，但他提出的建议对项目大有裨益。

我的建议是，在脑海中将反馈精简为事实，这样你就能理解信息本身，不受信息传递者情绪和态度的影响。这样就能更容易地判断是否需要对反馈采取行动。

需要明确的是，我并不是说你应该容忍人们像混蛋一样行事，这让我进入下一部分……

勇敢一点

作为团队负责人，你有权决定会议上可接受的态度。如果你的团队和你的实施方案被打压，要勇敢地站出来维护他们的利益。最重要的是让你的下属知道你支持他们。你也有权力设定团队承受压力的标准。要勇敢地捍卫估算，并指出范围蔓延的问题。

第 2 部分 - 外部技能

本部分介绍需要练习的人际交往技巧，以提高您与团队互动的质量和领导的有效性 - 指导、沟通、加强团队联系等。

指导是优先事项

如果编码只是工作中最小的一部分，那么那些让你晋升的优秀开发技能又会怎样呢？答案是，你可以将这些技能传授给你的团队，从而让它们成倍增长。作为团队负责人，你的首要职责之一就是指导你的开发人员——这是你为公司提供的最大价值。

我对指导的建议是：

1. 了解开发人员的优势和劣势，并根据他们的技能水平和发展目标分配工作。分配具有挑战性的工作，但不要让他们感到“力不从心”。为团队成员设定成功的目标，让他们觉得自己无所不能。为了评估开发人员是否成功完成任务，可以定期进行一对一的沟通（争取每天进行）。“进展如何？”
2. 不要等着开发者主动来找你。相反，要定期与开发者沟通，了解他们的进度，并表明你随时可以与他们讨论。一句友好的问候：“嘿，你最近在做某某事吗？有什么问题吗？” 是一种轻松随意的问候方式，不会让人觉得你事必躬亲。
3. 每个冲刺至少举行一次专门针对开发人员的知识共享会议，每个人都讨论他们所做的工作以及他们面临的挑战。
4. 尽可能多地编写文档。指导的目的是传播知识，而文档是一种共享知识的协作方式，即使你转到另一个项目后，这些知识仍然会继续存在。

利用整个团队进行咨询

我曾经抱有不切实际的期望，认为自己必须精通团队所有领域。这原本是出于好意——我只是想自己能回答所有问题，避免拉拢额外的人手开会，让团队可以专心工作。此外，由于团队经常与我讨论实施策略，我喜欢在已经了解相关背景的情况下进行对话。但事实上，这种心态给我带来了巨大的压力，因为我不得不不断地进行调研，并为会议做额外的准备。更重要的是，它剥夺了我的团队成员练习讲解技术主题的机会，而这恰恰是一项至关重要的技能。

因此，我的建议是尽可能地跟上你各个工作流的知识，但要意识到你的团队里挤满了领域专家，并尽可能地利用他们。尽量在每次技术会议上至少有一名开发人员与你一起参加。你可能需要向项目经理解释这一点，因为现在参加会议的开发人员数量将翻倍，所以要明确表示这是对团队成长的一项投资。“共享”会议还有一个额外的好处，那就是它可以防止所有知识都被一个人掌握。所以，如果你离开项目，对团队的打击不会那么大。

知道何时倾听而不是解决问题

作为领导，我一直面临的一个问题是，当开发人员向我提出问题时，我会立即进入“我自己该怎么解决这个问题”的模式。这也是出于好意。我想提供帮助，也想帮助大家解决问题，让他们能够在冲刺中取得进展。由于我平时不怎么写代码，所以对应对编程挑战感到很兴奋。我必须不断提醒自己，耐心等待，给大家机会自己解决问题，这对团队来说是最好的。

我的建议是，要求对方更明确地说明他们需要你做什么。例如，“Anastasiya，我可以就某某事跟你提一些想法吗？” 而不是“Anastasiya，我在某某事上花了很长时间，但还是不对。我需要你的帮助。” 当对方的请求措辞如此明确时，我心里就毫不犹豫地知道是需要提供解决方案，还是干脆闭嘴倾听。如果对方的请求措辞含糊，只需问“我能帮你什么忙？”，就能明确对方的意图。

作为负责人，您有责任确保团队在实施目标以及需要遵循的任何技术限制上保持一致。但请给予开发人员自主决定实施细节的自由。告诉团队要构建什么，而不是如何构建。

记住，犯错是可以的

当你允许团队自由地决定实现细节时，他们有时会尝试一些行不通的方法。永远不要因为有人尝试了之后需要重构的东西而羞辱他们，我们每个人都是这样学习的。

如果你在实施检查过程中怀疑有人犯了错误，你很容易直接指出问题：“哦，不，你不应该那样做，应该这样那样。” 当然，在这种情况下你并非有意刁难，你只是想避免开发人员将来浪费时间进行故障排除。当然，如果这是一个会导致服务器瘫痪的严重错误，那就指出来，但这种情况很少发生。通常情况下，问题在于忽略了一些边缘情况或类似情况。在这种情况下，我的建议是引导开发人员进行对话，让他们思考问题，并将实际解决问题的任务留给他们。例如，“你有没有想过，如果用户尝试只用键盘与这个组件交互会发生什么？” 或者“你认为这个组件存在任何安全漏洞吗？” 教会人们如何寻找他们需要的信息，而不是直接告诉他们做错了。

始终保持积极的意图。

我最近看到一条推文，完美地概括了这个概念：

团队中的每个人都会尽力根据当时掌握的信息完成工作。他们正在努力克服各种限制和挑战，而这些限制和挑战在之后的工作回顾中可能并不明显。

这或许是本页最重要的一条建议。它对减轻你在工作中感受到的压力和挫败感，以及提升他人对你的印象都大有裨益。

赞扬人们所做的出色工作。

尤其是在别人面前。向你的老板表扬你的员工的出色工作。记住也要表扬其他部门的员工。

不要妄下结论

对我来说，当开发人员未能达到商定的期望（例如满足冲刺承诺、在线（对于远程工作人员）或遵守拉取请求清单）时，领导人员就模糊地变成了管理人员。

如果你不得不与开发人员对质其绩效，我的建议是不要妄下结论，而是在例行检查时直接要求解释。开发人员可能只是遇到了你没有意识到的问题，不会再次出现。

但是，如果你发现自己一次又一次地与开发人员纠缠于同样的问题，并且需要召开更正式的会议，那么我的建议是向团队其他成员解释清楚这个问题的影响。不要威胁他们，也不要告诉他们如何解决问题。请他们提出解决方案：“你打算怎么做才能确保不再出现这样的情况？” 让团队成员承诺解决方案并记录下来。然后在几周后召开一次跟进会议，看看他们是否落实了解决方案。

做人

我并非完美地领导或管理。有时我会说错话，有时我会情绪化，有时我会冒犯别人。本页中我建议不要做的所有事情——我都做过，所以我知道最好尽量避免。当我犯错时，通常是在团队或客户面前，所以我对尴尬的感觉并不陌生。

我最后的建议是，要习惯这种不舒服的感觉。承认错误，从中吸取教训，必要时道歉。然后原谅自己，继续前进。

祝您胃口好！