管理一个团队
从管理一两个人到管理一个团队只是一步之遥，但还要做得更多。它是不同于高级工程师职位的全新的技能和挑战。
以下是工程主管要做的工作：
工程主管花更少的时间写代码，但仍会参与一些小的技术交付，如bug修复和小的功能点，且不影响项目的进度。他们更多的责任是辨识流程中的瓶颈，扫除团队通往成功的障碍，对团队产生更大的影响。他们辨识团队中的高价值项目，让团队聚焦于这些高价值项目，同时，他们和产品leader结伴合作，管理项目范围，确保技术交付符合要求。他们统计项目中的人数需求，计划、招聘新的成员。
除了很强的管理技能，他还领导产品组的技术路线，和他们沟通时间、范围、风险，领导时间线内主要计划的交付。辨识战略上的技术债务，评估成本收益，解决这个债务，并和管理层沟通时间和优先级。
刚成为管理者时，你会把更多的精力放在与人相关的任务上，成为管理者，不是拥有最多的技术知识，更重要的是给别人提供支持。
保持技术实力
作为管理者，你要引导技术决策，让架构师和高级技术人员对他们的决策负起责任，确保技术决策通过评估，并和团队的技术环境和业务平衡。
另外，如果你想真正获得技术团队的尊重,必须被认为是技术上可信赖的,否则你将会非常艰难,即使你走上领导岗位,你的选择也会被限制。
你要学会平衡,你将花更多的时间在会议,谈话上,但不能因此过早荒废技术,你可以修复一些bug,实现一些小的功能点，以从中发现瓶颈和流程中的问题。你将会被召唤指导哪些是你系统中可以实现的,哪些是不能的,如果你知道功能如何在系统实现,你将更容易管理产品经理的疯狂的idea,注意不要过度自信。复杂项目管理最关键的部分就是充分理解系统,决定实现新功能的最佳路径。
但是有些公司是管理和技术泾渭分明的，建议你继续待在技术岗位，直到学会了编程和系统设计的必要技巧。
调试运行不良的团队：基础版
有时候你会接手这样一个团队，迟迟不能交付、团队成员士气低落，离职很多等等。这里又一些方法，有助于你找到症结：
1、不能正常运转
即使是做研究,也要设立小的可交付的目标。
要在推进团队和放松之间寻找平衡, 如果你仍在写代码, 可以帮助团队满足交付需求, 深入项目脱节的部分,看清楚当前情况。
有时候团队不能正常运转是因为工具或者流程让他们难以快速完成工作。一个普遍的例子是你的团队只是一周发布生产一次,甚至更少,低频率的发布会隐藏许多痛点,如落后的发布工具,繁重的人工测试, 过重的功能,及开发者不懂得拆分任务的方法, 作为管理,你要移除这些瓶颈。
事实证明，发布可能是一个资源争夺点。当人们争夺稀缺资源时，团队成员之间的冲突和不快几乎是不可避免的。使资源充裕，立即提高了团队士气。
2、people drama
一个人如果工作效率很高，非常聪明，但是没有团队合作精神，让其他成员很不开心，这时候你要勇敢快速地采取行动，将他们的戏剧表演扼杀于萌芽状态，你可能要和你的主管和boss说明原因。也许必要的时候可以调到不同的团队。
处理态度消极的人比上面的人要容易，他可能没有意识到其行为的影响，你要及时和他讲清楚，或者他只是工作不开心，合适的时候可以帮助他到其他团队。
3、劳累过度引起的不愉悦
如果劳累过度是因为生产系统的不稳定，作为管理者，你要放慢产品的步伐，在一段时间内集中于产品的稳定性。明确告警、停机时间和事故，努力减少它。可以将每次计划的20%的时间用于系统的可持续性方面的工作。
如果劳累过度是因为紧迫，时间敏感的发布，记住两点，一是尽一切可能支持他们的工作，特别是帮助他们工作的完成。订晚餐，告诉他们你感激他们的辛勤工作，发布之后会有一段放松的时间。让这一刻尽可能变得有趣。第二，尽你所能从这段艰难时期中吸取教训，避免重蹈覆辙，如果可能的话，削减功能，推迟不现实的计划时间。艰难时期会发生，但不应该经常发生。
4、合作问题
如果你的团队和其他技术团队、产品团队或设计团队不能很好地合作,要定期和相关同事接触解决这个问题。收集可行的反馈,进行建设性的谈话, 在团队面前说其他团队的同事只会让问题更糟。
如果你的团队不能很好地合作, 可以带他们出去聚餐,参与有趣的活动和谈话。
ASK CTO：如何管理前同事
如果你被提升到管理岗位，刚好你原来也有位同事有志于此，你如何在不疏远他的同事行使自己的管理职责呢？
首先你要承认这种转变的奇怪的感觉，你会尽力做好工作，但你需要他的帮助。
第二是要知道你的工作在某些方面发生了较大的变化，你可以否定他的决定，但要小心地使用这种权力。运用管理权力去否定技术决策常常是有害的。要避免微管理的诱惑，前同事对此会格外敏感。
为了承担更多新的职责，你要将你原来的一些职责分配出去，给前同事更多的技术控制范围。这对初级程序员而言也是一个不错的挑战。
你的目标是向团队表明你致力于帮助他们成功。你的新角色并没有带走团队的什么，只是你增加了一些职责，而把原来的职责分配给团队其他成员。
成为盾牌
管理者的一部分工作是成为盾牌, 让团队成员专注于自己要完成的事, 不要被公司政治和外部的变化所干扰。但有时候让压力传递到团队也是合理的, 让他们了解面对的事情的环境背景,比如为什么要设立这个目标; 解决了什么问题, 出了问题会导致什么后果。 理解背景也有助于团队成员决策,分配自己的精力。
还有一种错误的方式是不承认外部的变化，比如其他公司的裁员风波，而你又沟通不善，很容易会让谣言在团队内传播。
如何驱动好的决策
你可能有产品经理规划产品路线，有技术leader深入技术同时也兼职项目管理，但你要对团队的进程负责，引导一个好的决策。
1、创造数据驱动的团队文化
如果你有产品经理，让他习惯于用关于商业、顾客、用户行为、市场潜力的数据证明他的决策。还可以加上关于团队生产力（功能完成时间）和工作质量（发布后处理停机的时间和发现的bug数量）的数据。这些数据都可以评估关于产品功能和技术变动的决策。
2、有产品直觉和用户共情
不管你是为外部用户编写功能还是提供内部技术服务，你要理解哪些是对你的用户重要的，花时间发展用户共情是重要的，因为你要为你的工程师提供所做工作的上下文环境，也让你了解哪些领域的技术会对你的用户产生巨大影响，进而引导你的技术投资。
3、放眼未来
你从产品和技术两个角度去思考，产品路线可以帮助你引导技术路线，许多技术项目都是为了让新的功能实现更加简单。
4、回顾你决策和项目的成果
看看你曾经驱动项目的一些假设是不是真的，重写系统后团队工作是不是更快，添加新功能后用户行为是否改变。
5、对流程和日常工作进行回顾
敏捷开发每两周的工作周期中都有一次回顾会议，讨论发生了什么。经常性的回顾可以发现事物的模式，迫使你对决策的结果和效果进行思考。它比关于团队的数据更主观，但可以说更有价值，因为它是团队自身意识到的。
优秀的管理者，还是差劲的管理者：冲突回避者和冲突解决者
有些管理者工作很棒，但是厌恶对团队内的新项目说不，也不要求增加人手，让他解决冲突或者作出艰难的决定是不容易的，最后导致团队超负荷工作，难以安排工作优先级，团队成员也十分不满。有些管理者与团队合作，确定工作的优先级，并提供选项，征求反馈，引导他们克服技术选型方面的分歧。没有能力说不，承担决策的责任，最后只会让团队引导你，而不是你引导团队。
创造一个安全的环境，让分歧自行合理解决，远比假装所有分歧都不存在要好得多。
管理冲突时，哪些该做，哪些不该做：
1、不要完全依赖共识和投票
共识可能在道德上具有权威性，但前提是参与投票过程的每个人都是公正的，在各种结果中都有相同的利害关系，对背景也有同等的了解。这个前提在经验、角色不一致的团队中是很少满足的。作为管理者，有时候要自己承担责任，传达不好的消息，而不是实行一次失败的投票。
2、要建立清晰的流程来取消决策的个性化。
当你想要团队决策的时候，必须有一个用来评估决策的标准。对目标、风险、问题有共同的理解。当您将决策权分配给团队中的某个人时，请明确说明应该向团队中的哪些成员征求反馈意见，以及需要将决策或计划告知谁。
3、不要对酝酿中的问题视而不见。
如果某人的工作中存在重大问题，那么你应该在注意到这些问题时马上让他知道，而不是等到写绩效考评的时候。如果你自己没有注意到这些问题，但在回顾过程中通过几个同事的反馈了解到这些问题，这不是一个好迹象, 这可能表明你没有注意在一对一会议中让你的团队与同事讨论他们遇到的问题。
4、解决冲突并不是助长功能失调
你想要给人们留出表达沮丧情绪的空间，但要注意释放压力和真正的人际问题之间的区别。用你的判断来决定什么该解决，什么该丢弃。你要问的关键问题是:这是一个持续存在的问题吗?这只是你个人注意到的吗?这是团队中很多人都在努力解决的问题吗?是否存在权力动态或潜在的偏见?我们的目标是确定导致团队工作效率降低的问题并解决，而不是成为团队的治疗师。
5、不要把冲突带到其他团队。
具有讽刺意味的是,当冲突涉及到其他团队时，冲突避免者经常倾向于冲突。他们强烈认同自己的团队，并激进地应对他们认为来自外部的威胁。当事情出错时，比如跨团队的事件，这类就会变得仗势欺人，要求他的团队得到公正的对待，或者把问题归咎于另一个团队。有时，这种行为是主管压抑了对自己团队情绪的一种发泄方式。正如一位朋友所说，“我没有告诉我的员工他们需要改进的那部分10%，因为我担心他们会错过那部分90%的好消息，所以我把这种渴望转移到了其他团队身上。我真的只是想让每个人都完全负责任，我需要清楚如何以健康的方式在团队内外表达这一点。”
6、要友善,人都想被别人喜欢
作为管理者,不必让人感觉亲切,但一定要友善。告诉某人还没等到提升的时候,让他继续努力,告诉某人他会议上的表现扰乱了团队,都是一种友善,开展这些艰难的谈话是你工作的一部分。告诉某人他可以被提升,却看着他失败,这就是一种不友善的行为。
7、不要害怕。
避免冲突往往源于恐惧。我们害怕承担做决定的责任,我们害怕自己似乎太苛刻了, 害怕人们会离职, 担心人们不会喜欢我们，或者我们冒这个险就会失败。有些恐惧是很自然, 对冲突结果保持敏感是一种明智的习惯。
8、保持好奇
思考你的行为,是战胜对冲突恐惧的最佳方式, 把决定权扔给团队,是因为他们是最佳的做决定的人,还是因为害怕做出一个必要但不受欢迎的决策。我不给下属提供反馈是因为他确实心情不好,这只是暂时的,还是因为我这么做了,他不会喜欢我这个管理者。思考你的行为，你不太可能会寻求不必要的冲突。
挑战:团队凝聚力的破坏者
1、才华横溢的混蛋:
这类人很聪明,个人工作非常出色,但团队中几乎每一个人都害怕他,不喜欢他。他迷信个人智力, 严厉地压制团队中不同意见,忽视、轻视团队中的成员。
管理者很难放弃一个有巨大产出成果的人,特别他只是偶尔混蛋的时候。什么时候算是太过混蛋了呢，就是你试图矫正他，给予反馈，他只是稍微有点改正，后面却愈发严重。
避免这类人的最好方式是不雇佣他们，一旦雇佣，就算你没勇气解雇他们，也不要提拔他们。
团队中有这类人的时候，就是要简单公开地拒绝恶劣不良的行为，让这类标准更加明确，这是对“公开表扬，私下批评“的一次倒置。但你要控制好自己的情绪，不然他只是认为这是一次情绪发泄，或者是你太挑剔了。如果他冒犯的只是你个人，而不是整个团队，最好先私下交流。
2、不沟通者
不沟通者对你，对团队、对产品经理隐藏信息，他们倾向于秘密地工作，等一切准备就绪，推出一个重大的项目。他们不对团队分享信息，不想要code review，也不想在重大项目前进行设计评审。
这类人会惹恼团队中的每一个人，作为管理者，你要将这些隐藏信息的行为苗头扼杀在萌芽状态。他这么做可能是因为害怕了，害怕自己被发现能力不足，害怕被叫去做不感兴趣的工作。也可能是因为他觉得自己可以承担更多的责任，或者暗示着对管理者的不够尊重。无论什么原因，都会破坏团队凝聚力，因为他没有和团队其他成员一起合作的意识。
首先你要找出根源，如果他只是害怕被批评，要想想你团队的文化是否太过严厉。如果你的团队排斥这个人，就将他移到其他团队，或者有时候需要矫正自己团队的文化，打破排斥新人的习惯。
3、缺乏尊重的人
这类人不尊重你,或者不尊重其他同事,这会逐渐蚕食团队的凝聚力。和他讲明问题可能需要你主管的帮助。但你自己解决的话,可以直截了当地指明,如果他不尊重你或团队其他成员,他为何来这里工作,如果他表明想继续待在这里,就要清楚明确地表达你的期望。如果他不想,就将他移到其他团队, 或帮助他离开公司。
高级项目管理
作为工程主管,你要帮助你的团队安排计划,有哪些项目要做,是否有合适的人完成计划。你可以将一些项目计划让技术leader去做。但你也需要做一些事,
您可能必须决定接受哪些项目，以及何时推迟拒绝一些项目。您可能会被问到工作何时完成的粗略估计，即使是以敏捷方式计划和迭代的工作。您需要对团队的工作节奏有强烈的直觉，以便成功地管理他们的工作负载，有一些简捷的方式可以提供帮助:
1、这不是对敏捷项目管理的替代
这里不是让你详细计划每一个项目，采用瀑布式开发。绝大多数项目都有长期目标，也有短期目标，当涉及到规划小模块的细节时，团队协作进行工作划分和粗略估计的敏捷过程在组织日常工作方面非常有效。作为管理者，你不要试图打断甚至亲自执行。然而，你要对更大的工作图景负责—以几个月而不是几周为维度来衡量成就—你必须开始实施一些更高层次的计划。
2、每季度每个工程师拥有十周的工作产出时间
你将面临假期，会议，季度回顾，线上问题，新员工入职，这些都会占去很多时间，不要想着每个工程师每季度拥有超过十周的时间专注于主要项目开发上(每季度大约13周)。一般而言，第一季度是生产力最高的，第四季度是最低的。
3、预算20%的时间用于普遍性的工程可持续化工作
普遍性的工程可持续化工作,是指调试、测试、清理代码、迁移语言和平台版本等必须完成的工作。如果您养成了这样的习惯，您可以使用这段时间来处理一些中等规模的遗留代码，并在每个季度进行适当的改进。在进行系统整理时，保持这些系统易于维护扩展，从而使您的团队在新特性开发上快速前进。在最坏的情况下，您可以使用这段时间的松弛来平滑度过开发中的意外延迟，但是如果您功能开发的时间占到了100%，那么可以预测到，新功能开发将会由于这种过度安排而迅速放缓。
4、当你接近截止日期的时候，你的工作就是说“不”
你几乎肯定会有临时的截止日期，要么是你设定的目标日期，要么是来自高层的目标日期。实现这些目标的唯一方法是在项目结束时缩减范围。这意味着你，作为工程团队的领导，将与你的技术leader和产品主管/业务代表确定哪些并不是真正必须的。你必须对双方都说不。有时候，工程团队会说，如果不做一些其他的技术工作，他们就不可能实现某个功能，而您需要弄清楚什么时候应该推动以hack方式实现，什么时候应该保留而促进正确的实现。有一些产品特性的实现将带来比较大的工程复杂度，您将需要与产品团队合作，在解释实现其产品愿景的成本时，找出真正必须具备的功能。到了紧要关头，你将是给团队提供选择的人,什么是实际可以实现的，或者需要多少时间才能把所有东西都完成。
5、使用倍增法则来快速估算，但对于估计更长时间的任务,要争取专门的计划时间。
软件评估中流行的加倍规则是，“每当被要求进行估算时，就将你预测的时间加倍。当你被要求即兴估算的时候，这条规则很合适，也很好用。然而，当你讨论那些你认为会花费超过几周时间的项目时，你可以将估算的时间翻倍，但要明确的是，在确定时间尺度之前，你需要一些用于计划的时间。有时候，长时任务需要的时间远远超过您预期的倍增时间，在您将团队投入到一个大型的、未知的项目之前，花一些时间仔细地计划是值得的。
6、对你给团队带来的评估要有选择性 ***
我之所以强调您在评估和计划过程中的角色，部分原因是，对于工程师来说，主管不断地随意向他们询问项目预测评估会分散他们的注意力，增加压力。作为主管，你有责任处理这种不确定性，限制您向您的团队暴露的不确定性数量。别当工程师和公司其他人员之间的电话机，鹦鹉学舌地传递信息，来回走动，让那些忙于重要事情的人分心。但你也不是吸收一切的黑洞, 要尝试建立一个团队范围内的流程，以讨论新功能和客户的抱怨，并限制在此流程之外进行评估。
ASK CTO: 加入小团队
作为主管加入一个小团队是很困难的。当您从软件工程师晋升为主管时，平衡技术工作是一回事，但是带领需要管理的新团队，学习的新代码又是另一回事。
有几种方法可以在不烦扰团队的情况下熟悉软件。首先，请某人向您介绍系统和体系结构，以及测试和发布软件的过程。如果有一个常规的开发人员入职流程，您可以在其中学习如何check出代码并部署系统。花些时间熟悉代码库，并开始进行一些codereview(如果存在的话)。
在你的头60天里，计划至少做几个功能。选取一个特殊的功能，并添加到系统。和其中一个工程师合作开发他的功能，当你自己开始做一个功能的时候，让他和你合作。让其中一个团队成员review您的代码。执行一次发布操作，并做几天技术支持和维护工作。
您可能会发现，这意味着您的管理入职过程可能会更慢，因为您还在学习如何在这些系统中工作。这种放缓是值得的。通过了解代码、了解编写代码的过程以及您的团队日常使用的工具和系统，您将会了解管理团队必需的一些知识,获得团队对你的信任,觉得你是一个有能力的领导者。
java达人
ID：drjava
（长按或扫码识别）
