浅谈技术团队管理1104由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“技术团队管理”。
浅谈运维团队管理
---与刚刚从技术转向管理的同学共勉
付林 2015/11/ 分享的大纲如下：
1.如何从头开始组建一个运维团队（暂略）2.选择及培养合适的人：招聘及培训（暂略）3.愿景、目标的设定及共担、共享（暂略）4.管理者定位及角色认知 5.绩效管理 6.关于‘沟通’ 7.标准、流程及传承
其中，因为时间和节奏的控制，1、2、3节暂略，我们从‘管理者的定位及角色认知’开始，后面此次分享内容对外的时候（若有机会）会贴出完整的内容。分享内容中“【】”里面的内容为所引用的知识点，有兴趣的可以关注下。
各大纲的主干：
1.运维团队组建（暂略）
业务分析 短期规划 定岗定责 选择‘合适’的人 留足‘空间’
说说岗位职责、任职要求的编写 笔试题的设定 从简历分析开始 标题是“浅谈运维团队管理”，但本次分享主要的着重点是“团队管理”部分。
本次分享行文略显啰嗦，可能干货不多，各位手里的砖头请先放一下哈~~ 2.面试（招聘）及培训（暂略）
面谈礼仪、节奏和信息分析 培训计划、大纲制定（目的）培训实施及现场把控 测试、后续跟踪（效果评估）
浅谈‘战术’ 达成共识 建立共同目标 统一价值观 定位 角色
领导者 教练、辅导者 调配、协调者 督导、支持 解决问题 承担、承诺、信任 3.愿景、目标的设定及共担、共享（暂略）
4.管理者定位及角色认知
价值
5.绩效管理
价值来源 目标导向 任务分配 任务辅导、检查
要求主动反馈 合适的、逐步的授权 授/放权不等于放任不管
培养全局意识 ‘问题‘绩效的管理
任务回溯
考核（暂略）
6.关于‘沟通’ 目的、话术
对事不对人 多使用开阔性的问题
善于构建环境、维护一个合适的氛围 多听、注重事实，勿轻易下结论 情绪引导、心理干扰 解决问题的承诺
7.标准、流程及传承
制定规则、标准 构建合适的流程
不管是‘空降’到一个团队还是在团队中被提拔为‘管理者’，都会面临一个‘定位’的问题。比如：整个团队在组织中的定位，‘你’在团队、上级及对自身的定位、每个团队成员的自我定位等。当提升为管理者之后，我们面对的核心问题是：绩效来自于哪里并如何努力需要看到，从以前仅仅做好自己的事，变成我们需要对每个团队成员的工作负责，对整个团队的工作结果负责。因为，我们的绩效来自于两个方面：自己和团队。或者说：管理者需要帮助部属更有效的工作，不断地成就部属。另一方面，方向比结果更为重要。作为团队负责人，需要适时了解团队的紧要目标是什么，哪些事情最为重要，哪些可以暂缓，哪些很紧急等。简而言之：紧扣要事，先做正确的事，再正确的做事。【时间管理】、【项目管理】 也为了提高绩效、效率及团队稳定性，我们还需要维护一个良好的团队气氛，建立统一的规则（标准）、合理的分配工作任务，注意团队成员的心理变化、自我发展的需要……并用不同的技巧和团队成员、其他部门及第三方进行沟通等。继续说下定位的问题：‘管理者’的第一个位置是代表公司，第二个位置是作为一个团队的负责人，第三个位置是团队成员的伙伴。这意味着，对于公司而言，你代表的是整个‘团队’，对团队而言，你是最终的决策者及引领者，对于第三方，你代表的是‘公司’。
在做各种决定、决策的时候，‘管理者’在任何时候都需要以公司的利益为前提，此外还需要认识到：受限于自身的信息缺乏、认知缺陷的影响，在影响比较大的方案选择上，需要和利益攸关的部门及直接上级达成一致{忠告}。在带领团队成员工作的过程中，我们会发现自身的角色会不断变化。有时候达到？ 传承及改变（暂略）几个方案总是无法做出一个抉择，我们需要做出一个选择并执行下去（管理者），有时候团队成员碰到问题无法解决，我们需要辅助或提供其他的资源协助解决（教练、辅导、协调者），有时候团队成员的工作进度不理想，我们需要督促及提醒（督导），甚至我们需要在某些时候扛住团队成员无心犯的过{背锅}或协调来自于其他方面的压力（领导者）。
在这些角色变换的时候，可能有些场景会使团队成员产生迷惑。比如：针对某个方案，作为管理者，我们会说“可以，先按这个执行”。然后做的时候，他会找你说“诶，这个行不通，有XXX问题”，当我们执行‘教练、辅导者’这个角色并引导他解决问题后，他会提出来”现在和当初的方案不一样了“等等，这个时候需要让团队成员明白这些角色的存在及建设性的讨论多种角色重叠的区域，同时，尽量很清晰的表达自己在当下所使用的角色（或身份）及明确表达自己的原则和底线。
明确的底线、原则可能会使往日的兄弟与你保持一个距离，这是正常的，管理者注定‘孤独’，但，不应该孤单。注：承诺和构建信任放在后续环节。
下面进入第五个部分：‘绩效管理’。
前面提到绩效来自于自我管理和团队绩效，本部分内容就工作任务的分配、辅导、检查、回溯和有问题的绩效管理、考核而展开。
在工作任务被分配前，先确认清楚，我们手上拿到的需求是否明确，相应的资源调配是否充分。从如下几个要素分析：需要做什么，项目完成的标准是什么，完成时间是哪天，需要配合的资源能否按预期到达，现有的人手能否支撑，中间存在的风险是否可控，有无替代的更优方案。
如上6个要素确认在控制范围后，可将需求按团队当前的情况进行分解再分配给多人来完成，分解后的任务同时也需要满足如下要素：
a)可量化：如完成XX区域M个服的更新。
b)目标清晰：如完成XX版本升级，提高活跃和付费。c)责任明确：如 XX负责A区域S1/S2/S3 服。d)有期限：如 10月20日10点~11点
e)有完成的标准：如按照研发的要求操作并成功启动。f)任务不能被再次分解
在任务分配前，也需要考虑每个人的能力，让他努力一点就可以做得到就好，勿超出太多。【压力管理】 在这里，可能会同学提到，为什么不关注任务的‘价值’？对于部属而言，我们需要的是他们的执行力及可完成任务的承诺，是否具有‘价值’应在你的判断体系之中。
任务分配时，视工作习惯不同、能力的差异，所交代的任务细节也应有所差别。很多时候，我们要相信团队成员，提需求就好，不要过多干扰完成方法{目标导向，关注结果}。如果不确定他给的方案是有效的，可以约定：先提出几个解决方案和自己的想法，一起讨论选择并交由他继续完成。这实际上是个建立‘相互信任’的过程，且部属的积极性会得到很大的保障，因为这个任务是他来’主导’的。【目标管理】。
在完成任务的过程中，尝试多让团队成员自己去思考、尝试解决问题，在必要的时候，可以在解决思路上加以引导及鼓励，比如：
a)引导解决问题的发散性思维 b)讨论问题的多重可能性
c)引申多种可能的解决方案，让他选择并尝试
但同时，我们需要留意这样做可能存在的风险并加以控制，如合适的操作权限控制、二次check、高危业务操作流程约定等。
任务分配下去之后，除事先要求主动按阶段反馈外，我们也需要定期去跟进任务的进展，及时发现存在的问题及在合适的时机介入进行协助，也需要跟据每个人的能力和意愿不同，给予不同的授权，比如：
a)资源、需求的对接、调配（这部分涉及流程）b)主导单个或多个业务的单个、全部模块运维
c)可对外的承诺：适当的允许部属可对外承诺需求，可增强其自身的时间管理能力和责任心
参考：团队【激励】，授权意味着认可，也是激励的一种。
授权或权限下放并不意味着责任的移交。作为管理者，还需履行监督的职责并承担着所有工作失误导致的后果。为此，我们需要在关键的节点上多做二次check及确认。【PDCA】
进行检查的建议：
a)按‘作业’标准 b)按交付要求
c)任务完成时间、结果、质量
在遇到因部属工作失误或无法解决的问题时，我们需要在第一时间主动承担及解决问题{此处并非意指事事亲历亲为}。问题解决后，对于因工作失误、无法解决或执行力不高的问题，我们该怎么处理呢？
进入‘问题’绩效的管理的环节。
a)不会做 i.ii.重新审视部门的业务维护文档、工具、流程是否有效、完整并具可操作性。
再次培训前先了解对方的意愿（有力无心），如果意愿不强烈，先单独沟通，找下问题点，解决无‘心’的问题后，再进行培训。{无心无力有心无力有心有力有力无心—>有心有力} iii.iv.再次将任务分配下去，看看输出是否符合预期
提示：每个人都有一段时间的心理不适期，注意观察，一般偶尔的情绪波动是在可以理解的。
b)不知道、不清楚 i.ii.iii.确认需求（任务）是否传达（见 任务分配）确认需求（任务）是否被完整接收、清晰理解
任务所需的资源是否充足，任务优先级及是否和其他任务冲突、矛盾
c)不敢尝试 i.i.ii.iii.i.ii.i.ii.鼓励、加压并予以适当的辅导（见【压力管理】、任务辅导）第一次可以原谅，然后进行辅导、培训并反思流程、文档、需求分配有无可改善的部分。
第二次可以接受，强化操作意识、规范和流程要求。第三次：让他请客吃饭吧。实施目标管理，强调结果 提倡功劳而非苦劳
控制情绪：此时任何怒气都无助于问题的解决，相反，你的失控将会给部属极大的压力，后续恢复业务时更容易出错。控制局面：告诉部属，慢慢来，天塌不了，多想想再下手。若发现其情绪难以自制（如双手抖动），让其离开座位走走休息下再继续。同时，迅速启动应急流程以恢复业务运行，评估影响，告知进度等。【BCP计划】、【情绪管理】和老萧写的“技术人员的情绪管理”。d)多次出现小的失误或重复出现
e)多理由、借口
f)出现大的失误 iii.iv.业务恢复后，让当事人来总结，要求：找到问题背后的根源并给出解决方案。如有必要，可进行相应的辅导及一起改善。最后，勿轻易对其追责，部属没做好，都是领导的错。我们要始终相信每一个人都是在很努力的做好份内之事，只是因为能力、知识或经验不足无法尽善尽美。
g)无法按进度完成或相互推诿 i.ii.iii.iv.v.vi.vii.viii.部属对其角色认知是否不足、定位是否准确 任务本身是否可继续分解 责任人、完成时间、标准是否明确
任务理解是否与传达的意图一致，优先级是否明确 资源是否足够、存在阻碍，任务难度是否与‘人’匹配 我们自己是否有及时跟进？许诺的资源或支持是否及时兑现？ 制度上的处罚是否过于严厉或体系是否存在漏洞 最后来确认是否存在故意拖延、不愿意做或抗拒的问题
注意：确保这些结果是经过谨慎及客观的评估而得到的，然后，遵守组织的规则。
‘任务回溯’：一个任务结束后，可以组织团队一起对有问题（缺陷、风险）或效率低下的流程、操作、方案进行讨论，吸取经验教训等等……略过不提。
活干完了，该论功行赏了，那么规则是什么？KPI。
“考核”部分，今天这个分享可能没法说完整，所以暂时忽略，未来和大家一起分享、学习，抱歉。
兄弟们坚持一下，我们进入第六个环节了：关于‘沟通’。
其实，在前面的部分，我们多次提到了‘沟通’，比如在设定团队目标、做规划、分配任务乃至部属业绩出现问题了、心情不好了……我们都会和他一起聊聊，讨论下问题，但这样是‘沟通’吗？可能不是。‘沟通’是一个双向、需要有回应的过程，就是：我说你听并提出自己的疑问、想法，然后相互接受对方的意见并达成一致及开始行动。与之相反的例子是‘演讲’：演讲者长篇大论，台下无非就是掌声，无实质性内容反馈。因为它是一个单向的传送过程。在和部属沟通前，我们需要厘清这一次的目的是什么，我需要解决什么问题或得到什么样的信息，还需要根据沟通对象的性格差异，使用不同的描述方法、肢体语言及选择不同的环境。【MBTI】、【管理者的心理沟通技巧】。
如：有些兄弟可能更喜欢在轻松一点的环境中随意畅聊，有些喜欢在比较正式的环境中讨论工作问题，有些说话比较直白，有些更喜欢了解整个事情的细节等。在宣布组织决定、决策及触碰到原则性问题的沟通时，宜选择较正式的环境，有压迫性的肢体暗示，座次也以面对面为宜。其他方面的沟通，尽量选择轻松、开放一点的环境，如休闲区域、咖啡馆等。【商务座次礼仪】
如果是部属主动找我们，立即响应，马上放下手上的事情并保持极大的兴趣‘听’部属的诉求并讨论一个解决办法及给出一个期限，同时，可以视情况做一些激励，如：表达对他的工作的认可。不要吝啬赞美，有时候很简单的一句话，胜过万语。
在沟通过程中，也需要控制自己和沟通对象的情绪，描述问题或现状时，注重事实（仅阐述客观事实，只说看到的），然后发起不掺合任何主观判断的疑问，如：昨天XX业务在21点10分挂了，XX模块中断运行10分钟，这个是什么原因造成的？我们是怎么解决的，后续的规避方案是什么{聚焦问题点，关注问题解决方案而非过程}……而在4年前，我会这样问：怎么回事，XX模块挂了10分钟都没有处理好…大家可以评估下，哪种方式更好。
做一个好的‘倾听者’：在接受部属反馈的时候，我们也需要区分是情绪化的表达还是客观事实的描述或主观上判断，在部属未发表完之前，勿打断及做任何判断，并鼓励部属继续‘说’下去…在‘听’完部属反馈的问题后，先记录并告知一个答复的期限，随后，立即着手分析及解决问题，随时周知最新的进度信息。另外，你会发现，部属除了反馈问题外还是会有部分冤屈或不满需要找个人诉说，很幸运，你被选中了。【倾听的艺术】 在个人成长意愿和团队分配的工作中，总会有矛盾的地方，就此类问题进行沟通时，多问问部属他们的想法是什么样的，也一起聊聊团队现状和下一步的方向、计划，然后一起努力找到一个平衡点【共识】，有条件的相互承诺，如：如果你可以独立处理好XX业务，可以由你来负责AA业务。这部分的内容在第3节有所体现（今天未分享）。
（7）对于IT资源的管理方式现在有很多可以借鉴的流程或体系，如itil、devops甚至是4大运维体系…在或实施这些流程或体系之前，扪心自问，组织对我这个团队的期望是什么样的（第一节‘业务分析’），我现在拥有的资源是什么，我们现在能做什么，最需要做什么，究竟做到哪种程度就是OK的？这些问题留给大家思考。延伸阅读：IT服务成熟度级别。
运维团队存在的最大的价值是保障业务能稳定运行，不会因技术变革、人员流失、业务变更等造成业务运营出现不稳定状态。在稳定基础上，我们才可以做运维理论的实践、工具和成本的优化或者新技术的应用。
但考虑到现实环境中‘人’不具把控性，我们要考虑尽量剥离‘人’对业务的影响，为此，我们会去做监控、自动化、服务自助、可视化，会去建立各种流程、规则加以约束等等……而在这之前，我们需要把运维的基础工作做好，静下心来建立一些基本的业务维护标准及审视现有的团队结构和运维架构是否合理：
a)以业务维护来分析：
i.ii.iii.iv.v.vi.i.ii.iii.iv.v.vi.vii.viii.有无服务器硬件、操作系统安装标准
有无各模块版本、编译参数、部署位置、启动参数 资源使用有无统计、分析
备份策略、备份数据检测、数据存储策略 监控策略、对象、报警规则是否有效及正常运行 安全防护机制是否仍然有效 部门架构图是否依然适用
部门及各岗位职责是否清晰、有效、可理解 团队成员的技能是否依然能互补
团队人员的技能、经验、年龄组成结构是否合理 既有的业务维护流程是否依然有效
业务维护及说明文档是否清晰、有效及可具操作性 变更及事件的处理有无及时响应、归类记录、分析 业务、服务器的维护权限、操作规范，信息安全规则是否有效及执行 b)以团队管理制度、流程、成员结构来分析： ix.x.BCP计划是否有演练、有效
对外提供的服务的接口、标准（如邮件格式）是否统一
c)从业务部署来分析：
i.ii.iii.上面列出的几个片段，希望可以给大家在制定运维规范、流程时做一些参考。构建一个有效的流程可如下原则：
a)单点的输入、输出
b)输入、输出有标准、期限可依 c)子环节的次序、过程符合实际 d)关键业务点有明确的岗位、责任说明
现在的时代是最好的、也是最坏的时代，云及基于云的SAAS服务、各种运维理论的百花齐放，已让我们应接不暇或陷入争锋。但，无论如何，技术永远只是工具，运维的立身之处还是先要保障业务稳定运营，任何时候，优先满足业务需求。
多说一句：在由技术转向管理岗位的转型过程中，通常，成长为一名合格的管理者需要6~12个月。成长过程中较常见的问题是转型者会变成‘保姆’、‘老好人’、‘背锅达人’、‘劳模’等等。这个时候要不断的反思：你的职责、绩效(价值)、关注点及你的位置在哪里并加以改善。而你，也不是一个人在战斗！任何时候要记得的背后还有一帮兄弟……
书籍推荐：
管理类的：《第五项修炼》 《定位》 项目管理入门类：《人人都是产品经理》
成本类：《精益制造013：成本管理》
这本纯属个人爱好
各模块、业务相互依赖的业务逻辑视图是否需要修订 部署架构图、监控能否反映业务运行的最新状态 业务部署架构是否存在热点、单点及可能的雪崩效应，是否支持扩展及对运维友好
