前段时间整理的,从事技术团队管理工作2年左右了,一些随笔,一些身边的事汇总一下.
如何建设团队
管理者其实是心理方面的服务生，影响而又呵护着团队，如果有一天你发现你真的在纯粹管理团队，那么此团队就面临巨大问题了。
沟通是建设团队的基石，沟通少或者沟通不当是管理者所犯错误中位居首位。
目 录
11，培养员工认识并接受“工作就是在接受自己不喜欢和不擅长的事情”
1，起步之初—如何面试
先从招人开始，这是第一步，团队中应该关注什么样人员呢？
至于是普通还是高级或资深，就靠面试者把握个度了。具体不管哪个环节感觉差距与职位要求差异较大，则就砍死，不再继续了。开场白一般先让应聘者自己介绍一下自己，最初先看看他的语言组织能力和叙述的条理性。
我认为面试是个向应聘者学习的好机会，每个人的经历都是不一样的，而我有这个机会去分享他们的经历，这对我来说是个财富。
1，专业知识
笔试题：答错的或者空着的会问问情况。只要应聘者的思路是对的即可，有理论支撑，知道为什么即可。并不一定要求全能答对。
JAVA基础知识：
List Set Map Colletion相关） 线程常识 事务常识
数据库（SQL）：
索引规则 优化SQL的思路是怎样的（怎么看待execute plan）？出个简单的需要group by或其他稍微复杂一点sql的题，看看是不是能写出完成需求的sql来
开源框架：
AOP深入讨论一下结合核心类图讲解，然后再结合spring的aop聊聊
spring/hibernate/ibatis/struts可以抽几个问题随便问问，这个可以自己把握。问一些面试官认为只要用过就应该会的问题，别整那些高难问题或源码级的东西。
linux常识：
如果面试官有这方面需要就挑几个常用命令问问
根据应聘者的简历：
看看他主要哪些技术要点掌握的比较好，如UML和设计模式或其他一些开源项目，问一些简单的问题。
2，思维逻辑能力，分析业务能力
根据以往工作经验，要求应聘者不带任何技术术语，就把我当一个完全不懂技术的人来将，讲解自己做过的一个项目，由应聘者自己选择最熟悉的项目。期间需要板书，画流程图。直到能把我讲明白为止。如果讲得他自己都糊涂了，就cut掉了。按照从大到小的原则，先概貌，再细化到他主要做的那部分。
3，学习意愿
最简单的办法就是，问应聘者有没有在以往工作中从来没涉及到，但是他自己又觉得掌握的还可以的技术，或某一小领域（如SSO/工作流/搜索引擎/推荐引擎/工作流 之类的）当然具体哪个领域由应聘者提出。
这个时候面试官（我）可能都不懂，这个时候是个很好的向他学习的机会。但是大致讲的入流不入流还是可以听得出来的。
4，如何学习一项新技术
就是这样的一个简单的问题。看应聘者如何回答。“工作中需要完成某个需求，而期间涉及到的某项技术你从来没接触过，你的学习曲线是怎样的？”
我认为的比较好的答案：
a，先确定我要做什么，最终我要达成什么样的目标。
b，搜索相关领域知识，从理论开始着手，找具体推荐度比较高的开源项目。
c, 从开源项目的官方网站开始着手。下载latest的final rc版。
d，学习官方example，自己跑流程，再次确认是否满足我们要做什么这一目标，在此阶段可能要经历重新选型考虑。
e，深入研究api，developer guide。
f，如果能够从中抽取基础框架更好，方便今后复用。对外可以屏蔽此开源项目细节，更便于团队使用。
g，碰到问题，google解决，官方论坛 wiki等途径解决。
h，善于总结者，最佳，写出自己的经历感受，与团队分享，与此同时自己也在进步。
5，碰到问题怎么办？
已离职的人写的代码因为某种原因需要修订bug。你如何办？
我认为比较好的方式是：摸清逻辑先，然后重代码，变成自己今后可以永久维护的代码。当然这得视具体工作情况以及此问题的影响范围而定。
或者
修订以前的代码。可以继续深入讨论，修改的原则是什么？如对外无影响。尽量不动以前代码，重新包装facade之类的。
以往工作中你认为最难解决的问题是什么？花了多长时间？如何解决的？
可以通过应聘者的回答得知，这个问题到底是不是问题，通过解决时间多少，可以了解到他的能力。如何解决的？了解他解决问题的思路。
6，沟通能力/团队精神
面了这么长时间了，沟通能力，应该早就心里有底了。看应聘者性格了。这个面试官自己把握了。这方面也是最重要之一。沟通不了的人，其余方面再好也没用。团队合作必须要认识到的。此项是可以一票否决的。
7，都有哪些因素会促使你离职
我一般会问这个问题，目的在于，我想找个能够呆的时间长一些的员工，干了几个月就跑路的，对大家都是一种折磨。看看应聘者在乎的东西，是不是我的团队中的弊病。
8，都有哪些因素会促使你在一家公司能够做的时间久一些
面试官的初衷同上，只是换了方向而已。但是从这个问题，面试官可以想想今后安排一些什么工作给应聘者更合适。
9，不合适我部门的，但是又觉得不错的
返给人力部门，让人力看看是否其他部门需要
10，英语
碰到留学的或英语还可以的，就顺便和他一起练练英语。提高下公司门槛的同时，对面试官也有一定好处。
大致就这些了。面试过程中什么都可能遇到。这些只是我的一些小总结而已。
2，建立立会机制
立会:顾名思义就是站着开会.保持会议浓缩,没废话.特别细节问题不在此会议上讨论,另外组织特别细节会讨论.
主要目的:
1,促进团队交流,提高团队合作精神,多个大家交流的机会
2,及时解决问题,共享经验承诺
3,了解其他人在做什么
4,了解具体项目进度
会议内容:
1,上次开会后你都干了什么?
2,你负责的、正在做的任务还剩下多少时间?
3,在我们下次开会之前你要做什么?
4,碰到什么具体问题了?
时间:
1,暂定为每周一/三/五 的 9:45--10:15AM. 根据开过几次后再定应该如何调整,是应该每日一次还是每周两次.
2,半个小时的会议,则每个人大概也就2-3分钟的时间.请开会前根据上述的会议内容组织好语言.
其他:
大家不要拘谨,希望我们共同找到一条,既把工作做好,又能提高个人修炼,团队气氛又喜洋洋的路.这个小的改革只是个起步.试验摸索着前进过程中离不开大家的共同配合.
3，开展工作之初步确认
立会后细节讨论会，工作执行者反馈文档
| 版本 | 改动 | 人员 | 时间 |
|
|
|
|
|
需求描述
解决方案
解决方案变更历史
待解决问题
补充
任务分配者-----分配任务给----->任务执行者
今后,任务执行者在接到工作安排或者工作讨论会后,需要先写一附件中的需求描述确认文档,反馈给任务分配者和我.
在以下情况需要写此文档:
1,此任务可能出现理解偏差.
2,有一定的逻辑.
3,多人或跨部门协作时候.
4,超过1个工作日的工作.
目的:
1,在最开始的时候杜绝理解偏差.做到半路才发现是错的,这种情况对大家也是一种折磨.整理任务执行者自己的思路.
2,任务执行者更为明确的理解需要做什么东西,不会遗漏细节,如一个功能需求有10个小点,可是做着做着做了8个,另外2个都忘记了.
现在这样做可以避免是因为在动手前是需要任务分配者再次确认.而且在任务执行中是有文档可查阅的.
3,在任务执行者写此文档的时候,就不确定问题尽早提出并明确.如需要任务分配者或者我去协调什么资源,如 服务器不够,需要协调运维做什么?
4,如果任务执行者善于总结,那么此类文档便于任务执行者个人总结,做问题归类.
此文档也就需要任务执行者在会后或者工作安排后的15分钟左右时间.但是这15分钟会是很必要的,大家都来试试看.
一个好的习惯需要大家共同遵守和养成.都有好的习惯的成员必然组成一个积极高效的团队.
4，用其所长
初步归纳一下，人员一般有以下几类，不全面但是是一些感觉。往往现实中同一个人上会具备多种类型。
1，技术攻关型：往往此类员工钻在技术细节，适合编写技术基础框架，无法关注业务逻辑，对外需求探讨上。
2，任劳任怨型：此类员工适合分配一些琐碎事宜，无自己独立想法，踏踏实实做事，技术上长期无大长进。
3，好高务远型：根本无法担当大任，做事喜欢找借口，尽早剔除出团队是好事。
4，喜新厌旧型：喜欢新技术，完全为技术而生，用此类员工需要注意，当分配任务无法适应其特点，则很容易造成此类员工的波动。因为团队中不可能随时有太多的新颖的工作。安抚还是第一位。
5，卓越朴实型：以工作产出为导向，技术扎实，善于组织团队满足对外需求影响。
6，解决问题型：思维缜密，善于分析并解决问题。往往不喜欢日常研发工作，但是在关键问题上能够起到奇兵作用。此类员工要使用在刀刃上。
7，无特殊需求型：自己也不清楚自己将来方向是什么，安排什么就做什么。对技术也有一定追求，对业务也希望有些了解。在适当引导的情况下，还是可以有一些发展的。
工作分配上，还是要针对员工特点进行分配工作。如果你为超过5个员工服务，那么此时，你无精力了解所有员工的特点，那么你所能影响的几个人，势必要让他们有此意识，建立合理的梯度。否则团队将怨声载道，工作难以推进。
5，及时调整工作
我这里所说的及时调整工作，旨在防微杜渐，不要等员工（管理者认为是重要人物）已经有想法离职了的时候，才想着调整工作，这时候往往都是亡羊补牢了。所以贵在做到及时。对于此类员工的离职，失职在于管理者，而不是员工。
举例几个我所做过的工作调整。
案例1：一员工经常在做琐碎，虽然有一定技术含量，但是基本上是比较平淡而又没什么挑战的工作。 但是，通过日常观察发现此员工，经常喜欢换手机，换PC桌面。处于沉闷期和忍耐期，如果此种情况长期下去，势必作成此员工积极性不高。通过找其谈话并适当调整工作，充分调动此员工积极性。
案例2：一员工沉迷于技术，虽然管理层一直想培养其为主管类初级管理职位。但是其从心里还是比较排斥管理，觉得与人沟通麻烦，累。但是通过几次彻心的沟通，让其认识到其工作的重要性，以及从管理角度看待问题会使工作发生如何的改变。结果，到现在为止，他已喜欢上管理类工作，甚至觉得管理与其沉迷技术其实是不冲突的，而且工作上更为有条理性，更有成就感。有些事情有些人也是可以改变的。只有朽木才不可雕。此处不是说管理就是要比技术路线好，而是在于强调及时调整工作，让大家能够更为愉快的工作。
6，如何看待人员离职
分几种情况吧。
1，不能融入团队的员工，离职是团队的幸事。
2，离职的员工提出离职给管理者一个打击或者一个意外，那么此管理者工作中存在着疏忽或不称职。
3，态度有问题的，或不思进取的，或如何调教都无法改变内心想法的员工，离职是可以欣然接受的。
对于想离职的员工，我有的会挽留，有的则会直接安排工作交接，甚至有的会直接主动开除（第9章节）。关键点还是在于防微杜渐留住自己真正想要的员工。直接安排工作交接的，这种情况一般我是认为我早就想到你要离职，你离职对团队会有一定影响，但是离职所带来的好处是大于坏处的。只是出于团队和公司的利益以及稳定性，我还是不想主动开除你而已。
7，建立梯度结构
每个人有效的管理也就3-5个人。如果管理超过3-5个人团队呢。有点类似传销的感觉，则需要建立一个梯度，每个小头目都在发展自己的下线。但是每个小头目的传销理念在延续着来自上一级的指挥。但是我们不用洗脑。只是在把建设愉快工作团队的理念深入人心。
8，消除优越感
避免任意一个员工有强烈优越感，或者有独一无二的不可替代性。这时候你会发现你的管理权利在他那里其实是行不通的。最简单的办法就是为每个人都要找个备份，和管理生产环境一样，你如果不想其出问题，或者出问题至少还剩一个办法解决，那么就好好的备份吧。
此处需要说明的是优越感和成就感是两码事。优越与危机是个反意词。而成就与挫败是反义词。
9，如何对待团队中的不称职员工
1，破坏团队气氛的必须剔除。如与团队中的核心人员或者几个同事发生口角。
2，能力不足的，态度无问题的，可以适当保留。如果工作安排在人手上不是特别紧缺，则没必要搞的人人自危，既体现一些人性化管理，也体现一下管理者也要为当初面试的看走眼付责任。为下一次的选择员工需要慎重考虑埋下伏笔。
3，能力强，但是其他方面有问题的。可以考虑让其单兵作战，如果单兵作战还有问题，那么就剔除掉吧。
10，结对编程还是复查，代码评审
大多数情况下，工作是这样的开展的，把任务分配给具体员工，卡里程碑，关注进度，上线OK无大问题，有问题直接找写代码的员工进行修订。基本就是个这样的流程。我们能做些什么改进呢？
结对编程在软件开发界已是有不小的熬头，而且也确实有不少的成功案例，见过一些老外比较open的企业确实在实施。而目前在国内的多数工作场合是行不通的，多数老板还没那么开明。还是容忍不了一个主机两个显示器，坐俩人，一个人就瞪眼看着。做为一个中层管理者还是要审时度势。
复查借助工具软件可以严格把关，不拘泥于结对编程看似存在的形式，也可以满足高层的眼球。而直取其要点。尤其是在员工水平参差不齐的时候，可以指定几名相对高级一些的工程师做为复查工，代码在经过复查后才可以成为正式代码。代码复查的最佳实践
代码复查是有代价的，甚至有时是巨大的，因此代码复查不宜频繁，最好一份代码只审查一次。同时，代码复查者应当对所审查的代码负有责任，即能够大胆地审查并指出被审查者的问题，并要求被审查者限期整改。与此同时，被审查后的代码如果还出现缺陷，审查者应当负有责任。只有满足了以上三个条件，代码复查才能为我们所接受。毫无疑问，项目开发小组的组长来担当此责任是最合适的。
一个项目开发组，根据其功能的划分，可以划分为多个小组，每个小组负责一个子模块。在这样一个小组中，小组长无疑是最有经验的开发人员，由他去负责组织和指导其它成员是合适的。小组成员不要太多，往往是3~5人。 小组长不要分配太多的开发任务，他的主要工作是指导和监督小组其它成员进行开发。将他从繁重的开发任务中解脱出来，他可以有更多的精力去指导其他成员的设 计，并且复查他们的代码。最终，他要对小组所有成员的代码质量负责，由项目经理或质量管理员进行抽查，检验其整体情况。
如果你只是一个小型项目，人员总共在5人之内，那么你不用这样分组。作为项目经理的你就是那个小组长，指导和监督你的成员。这样安排是因为在现代的管理理论中认为，一个人最多只能管理5个人，超过5个人就应当分组管理。而如果你在5人之内当然就不需要分开啦。
作为组长，你可以有效地审查和管理你的小组成员。同时，由于你负有责任，你也不得不认真有效地去完成审查工作。通过以上的组织形式，代码复查可以简便有效地在项目组中开展起来，从而从管理上有效地提高软件开发的代码质量。
代码评审一直觉得此项可能会引起员工情绪问题，而最后流于形式。
总体来看，我还是更倾向于代码复查机制。
11，培养员工认识并接受“工作就是在接受自己不喜欢和不擅长的事情”
“我对这个没兴趣；我觉得XXX语言不如XXX语言；我还没掌握这项技术，没把握；这个工作干着好好的，为什么偏要插个破文档让我来写，而且是个虚的文档；等等等等”
从事管理以来听了许多这样的话。
我的态度是，调研每个人的兴趣爱好所在，在工作允许的前提下尽量分配个每个人自己喜欢做的事。在我尊重他们的同时，也同时赢得他们对我工作上安排上的尊重。不懂得互相尊重的人是没有价值的。
管理者要善于引导，引导员工接受自己不喜欢或者不擅长的工作。多数人的兴趣所在都是自己擅长的东西，当然个别人是例外的。大多数情况下我没兴趣其实基本等同于我没这个能力，当发现自己能够把自己原本没兴趣的事做的比别人还好，其实自己兴趣就已经浓烈了，或者说那时候兴趣已经不重要了，因为你已有了很强烈的成就感。
如何引导员工接受暂时的工作被打扰。当然这些是确实没办法的情况下，大多数情况是应该比较有序的安排工作的。其实基本可以理解为：员工的有序工作VS工作的无序穿插。解决好此事也是管理者的职责，那么我们应该如何应付实在没办法的穿插无序的工作给有序的员工呢？第一必须从工作角度出发，讲解如此安排工作的必要性，先名正。第二从员工角度分析，说明此工作会给他带来什么好处。第三从调整心态方面引导员工，能够适应暂时的变化。
12，跨部门协作
跨部门协作是最难的，多个平级部门之间的协作沟通，事情往往都是出在部门与部门之间的连接点上。如果各个部门都站在解决问题的本质点上，那么还是相对容易解决问题的。往往各个部门的负责人都会有自保意识，这是造成拖延问题的元凶。
正确的解决问题之道是：任何一个部门负责人都不要承认问题是自己部门的（弱势部门），任何一个部门负责人也不要说不是自己部门的问题（强势部门）。以问题为导线，一步一步查就是了。但是必须讲明查问题不会问责，否则真的会举步唯艰。
与业务部门沟通也是相对来说比较麻烦的事。这时候要注意要以业务的语言去说话，不要满口技术，大谈数据库之类的。
负责人应该把主要精力关注在接口以及部门协作之间的通讯服务或者即订规则文档上。我的原则是，各个部门都多往前走一步就没问题了。可往往情况是，哪个部门都是各扫门前雪，有的甚至推自己的门前雪到别的部门那里，没有将认识提高到以工作问题为导向上来。这样的工作势必很难开展。再为本质的问题就是沟通问题，人天生是有惰性的，是有拖延心理的，我也一样，我在时刻提醒自己，这是今天应该做的事，不能拖，早干完早下班回家。要发挥自己的应尽职责，我的职责就包括在各个部门之间多走一步解决问题。
什么时候应该自保呢？超出自己工作范围的，绝对缄口不言。祸从口出！
13，培养小组负责人，主管职位
一个人有效的管理范围只能有3-5个人，当你的团队超过这个规模了，那么应该如何做？即需要建立梯度结构，这时候应该把团队划成3人左右小团队，那么自然就引出了这个问题，如何把一名员工培养成主管？下面把管理者我定义为A，被培养的对象定义为B。分为以下几个方面：
l 认同：
此点为基石，下面的所有的方面都是建立在此基础之上的。什么是认同：
B必须有此方面意愿，如果B一心钻技术，无心往此方面发展，那么很抱歉A选错人了。
A有培养B的意愿，这个靠机遇，为什么培养B。有时候可能是出于无奈（相比之下B已经是最适合的了，如何比较：资历，性格），有时候是真心想这么做。不管是出于什么目的，如果选择了开始，就要用心把它做好，矢志不虞。
双方都有意愿，接下来再如何认同呢？A与B必须能够保持正常的交流。如果没说几句，A觉得B各方面都完蛋，着急，训斥。B觉得我自己原来干得好好的，为什么要受这份苦呢。人都有自保意识，当受到挫折的时候很容易选择回归原态。这时候A的作用特关键，必须把他引上这条路，而不是赶上这条路。最主要的一点就是：A要稳住情绪，站在B的立场想，替他发自内心的剖析问题，不急不躁。强大的心理支撑着强大的行为。
l 分解工作：从做具体事，到把任务分解成具体事，这是个很艰难的转换。这时候A要出整体规划，讲工作要从大到小进行讲解。始终贯彻如何从大到小的过程。A手把手在project上教B如何分解工作。然后可以适当放开，做检查工作。检查一段时间无问题后，可以彻底放开。
l 积极反馈：一般反馈都不会及时的。必须通过耐心的与B交流，使其认识到积极反馈的作用。从以下两点着手：
1，如果不积极反馈，那么会影响整个部门的对外形象。
2，A要求B积极反馈，同时也是在要求B对其下属的要求也是如此。这些都是层层传递的。
l 团队激励：取得一定成绩的时候，A必须不要吝啬奖励，哪怕是一句话，一个暗示。
l 知识共享：A就B以及B团队所欠缺的知识，给予支持帮助，如搭建良好的询问渠道（如另外哪些部门哪些员工在某方面比较擅长）；提供书籍支持，书籍是大脑的粮食；B团队内部要及时share出自己所掌握的知识。这一点需要A来推动一下。
l 进度跟踪：分解工作完成之后，就是要跟踪每项工作的状况，如何做好此点，则需要B积极的与下属进行沟通。身体力行进行影响。当频繁出现进度问题，则需要A参与进来进行进度跟踪。指明原因：可能是因为最初考虑不周全；可能是因为某方面知识储备不够等。
l 立会机制与B下属员工确认工作
14，邮件的艺术
多数人都不会写邮件。更有的团队多数工作时间都在写邮件，回复邮件。邮件问题分为以下几种类型：
l 思维混乱：如果此类情况，基本就是不要让其通过邮件对进行邮件沟通，只做一些团队内部的工作即可。
l 以自我为中心：发件人认为理所当然的事，收件人却不知所以然。典型的容易发生在技术与业务之间，由于没有共同术语，很容易出现此类问题。
l 表达不清：如 邮件里出现 周四（那么是这周四还是下周四呢？具体的办法就是使用年月日方式，如果需要精确到小时，则需要近一步明确）。
还如“请设定每周二的自动job，发送给shuju和web即可”每周二（是0点还是23点59分？）shuju 和web是啥？邮件地址没写全。一群表达不清的人只能使事情越沟通越混沌。
l 切记“全部回复”：很多人没这个习惯。很可怜那些想知道状况，没有被全部回复的人，就彻底被蒙在鼓里了。
l 第一时间告知状况：被手头工作冲跨，未能及时回复，造成对方以为收件人未理睬此事，所以不管怎样，应该先保证及时回复，说明状况并明确时间点以及该时间点要达到的状态。如果到那个既定的时间点再有调整，则需要再次进行说明。
l 无条理：多个事情混在一起说，没明显区分1，2，3。未分别说明，状况描述—问题分析—后续影响—工作安排等等。
15，如何开会
1，会前需要有充分的准备，例如PPT，会议室预订，是否需要投影仪等。确定与会人员。
2，必须要明确主题。一定要坚决避免招来所有人开会。而讨论只有几个人关心的问题，浪费其余人的时间。我曾经开过我不得不中途退场的会议。产品人员组织的会议，一切涉及到后台技术的他们都认为简单，在会上大谈界面如何设计更合适，这是主持会议者认为的难点。那么招来这些对UE不敏感关心后台技术的人做什么呢？所以会议要浓缩，例如想讨论UE，那么只召集核心几个关心UE的就可以了。例如想讨论整体技术可行性方案，那么就避开UE吧，谈商业模式/技术难点即可。
3，避免跑题，纯技术会议这方面较明显，主持会议者必须能够在与会人跑题的时候迅速拉回正道。不要指望一次会议解决太多的问题。即使跑题，也要知道我们在跑题，不能越跑越远。适可而止的拉回主题上来。
4，会议时间不可以过长，最长2小时，我认为是个极限了。
5，必要的会议总结和会后跟踪。我不相信记忆，开会的结论必须要有，例如A人什么时间点完成什么，需要B人来协作什么？中间过程如果碰到什么问题应该如何处理等等。例如技术讨论结论，而这个结论必须是与会者认可的。我很不喜欢的就是一群技术大牛，一起海阔天空的侃。最后会议结束了，没什么事情或者很少有事情可以落实下来的会议。会议总结最好由会议主持者或会上最高权利控制者在会后通过email发出来。如果能当场确认并发出来最好。
6，解决问题的会议，一定要避免出现强势群体与弱势群体，尤其是入职比较晚的部门负责人，容易成为弱势群体。这样的会议解决不了问题。这样的会议只能是强者的舞台。问题还依旧存在。最好的解决办法就是，谁也不要承认问题，同时谁也不要推脱问题，谁也不要当技术大牛，可以分析问题，但是不可以断定问题。沿着技术路线由具体开发人员一一联调追查就是了，有时候管理者在细节上是没有具体执行者（开发人员）清楚的。但是事前要说好，不是追究责任的会议。顽固而且不可一试的或者敝帚自珍的不管是出于自保还是出于个人习惯惯性，都是应该坚决制止的。
847
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
