昨天我有另一个团队的团队负责人说他们花了一段时间来弄清楚我在维基页面上写的东西，因为我提到从源代码控制中获取代码“签出”显然混淆了他们。他们说他们用于Clear Case并且只听说过“加入一个项目”一词，并说他们很长时间没有真正编程。
虽然这很好，但是让我想到的是我多年来不同类型的团队领导者。我有一些几乎是纯粹管理的，我有那些同时做管理事务的程序员。
人们对他们拥有什么样的团队领导者有偏好吗？如果您的团队负责人积极参与您的产品开发，您如何关心？我发现团队领导者实际上坐下来并且像团队其他成员一样更有可能理解（根据我的经验）：
我觉得让一个拥有开发人员头脑的团队领导者也更加满意，并且他们也喜欢在代码中沾沾自喜。也许有些人喜欢团队领导者，他们与实际的编码方面保持距离，只是简单地完成工作，或者是我未提及的其他类型的团队领导者？
答案 0 :(得分：21)
团队领导必须是一名程序员 - 他们不能领导团队，除非团队尊重他们以及他们带走所有人。
另一方面，团队经理可以是编码员，也可以是组织良好的人，知道何时向其他管理层提问和界面。
可以在同一个人中找到经理和领导者，但更常见的是角色（应该）是独立的和不同的。
答案 1 :(得分：5)
我没有偏好，我不能，我必须与所有人一起工作，即使有太多的厨师破坏了肉汤。在一个多开发人员的典型项目中，我有技术主管，项目经理和非技术客户。当然，部门和计划管理人员都会坚持不懈。
有许多类型的领导者，每个都有自己的特点：
非技术客户： “客户永远是对的。”经常需要一个月球棒。将致电管理层和技术人员，并将最佳答案作为福音。
团队经理/直线经理：有点牧师的角色。对我正在进行的项目并不特别感兴趣。在项目优先事项之间做出决定的步骤。可能真的想成为一名程序员，并将他所有剩下的工作委托给他的下属。
项目经理：不同程度的技术诀窍。只关心时间尺度和成本。不明白，“我不知道要花多长时间，我需要先玩几天才能感受到它。”
团队负责人/技术主管：只是另一位开发人员，但有更多经验。负责影响整个项目的技术决策。经常与项目经理进行斗争，以进行良好的工程实践，即使短期内需要更长的时间。
团队领导/荣耀的秘书：应该带领团队的人，但更像是一名秘书。 （通常是团队以上的成绩）。回答手机，将客户与技术人员隔离开来。这种方法很好，直到他们提出一个技术问题，这位荣耀的秘书试图将他/她的方式排除在外，最终他们围绕秘书工作并直接与团队交谈。
答案 2 :(得分：4)
您应该阅读这本书Managing Humans。我认为管理者应该保持他们的代码。他们有更重要的责任，比如让人们远离开发人员，这样他们就可以完成自己的工作。让他们进入开发会产生混乱，因为他们不足以知道发生了什么，并且他们的时间在那个和其他事物之间分配，所以很难指望它们用于主要的功能。另外，当你必须告诉你的经理他们刚写的东西需要改变时，你真的很糟糕，你必须回去重做它。经理真的是他们为团队的其他成员投入手榴弹，所以他们可以专注于完成手头的任务。
话虽如此，管理者是否应该了解软件工程？是的，他们当然应该，这就是他们所在的领域。应该知道如何使用最新最好的技术进行编码？只要他们了解软件开发的工作原理，那就不重要了。
答案 3 :(得分：1)
我们通常有一个PM（非技术人员）从管理员管理项目。观点和技术主管，负责管理技术方面并为团队提供技术领导。
技术主管将编写项目的部分内容，并可能成为“概念证明”阶段的主要（唯一）开发人员。
在一些较小的项目中，他们是同一个人，但这是一种罕见的组合。
答案 4 :(得分：1)
我曾与之合作的绝对最差的软件领导/首席软件工程师是那些希望密切参与技术细节的人。太多重要的任务要么被遗漏要么要么没有完成。管理团队是一项全职工作。如果领导想要参与技术方面，那肯定会以管理方面为代价。
我只有2个软件主管/首席软件工程师，我认为这些数据是值得的。虽然两人都是以前的软件工程师，但对他们两人来说，那些日子早已过去。他们知道。他们甚至没有试图假装。他们的工作现在要管理。他们的工作是确保开发人员有机会获得成功。他们尽力消除所有障碍，确保每个人都取得进步。
我有一个理论，但从未在行动中看到过，最好的软件主管将是那些不是，也从未成为软件开发人员的人。他们擅长真正的管理精神，特别是作为促进者的精神。不幸的是，大多数管理人员更多的是出于政治动机，或者只是在工作，因为他们已经达到了技术上的顶峰。