#团队精神 　　要管理好技术团队光靠前面说的开发流程和工作方法还远远不够的。我认为管理好团队要做好三个方面：制度、物质和精神。 前面讲的开发流程主要是制度方面的，良好的制度能让团队高效的写作。物质方面就是要多为团队成员争取奖金、薪资等待遇，让付出多的成员能得到应有的回报，注意也要做到公平公正。一个技术团队光有制度和物质没有精神也不行。 　　互联网公司和传统行业的区别在于，传统行业做的事情都是明确的，可量化的， 加班加人就能加快进度 ； 而互联网技术做的事情是不明确的，不可量化的 ， 同一个功能 用心和不用心开发出来结果完全不一样 ， 不用心的人可以开发得表面上没有问题，但可能没有做好架构设计，不能支持高并发或者有安全漏洞，管理互联网技术团队其实就是要创造一个环境能让大家用心工作。往往传统行业的人管理不好技术团队，他们还是想着能加班加人加快进度，以传统的命令式方式管理， 很难有一个用心工作的环境。只是制度+物质 能管理好工厂里的流水线工人，但很难管理好技术团队， 我们要为技术团队营造一个能用心工作的氛围，必须还得有精神，这样才能是一直有战队力有激情的技术团队。 　　作为技术主管，自己的行为和人格能影响整个团队，我认为一个技术主管应该有以下行为： ## 认可 　　团队成员做得好的地方，一定要把你的赞扬给他，多给他认可，如果你不积极响应同事的努力，慢慢同事就没有积极性了。作为一个程序员，成就感是一个很大的动力。他们就是能解决别人解决不了的问题，能写出很炫的程序，然而如果做好了没有人认可往往会失落、会打击积极性。 　　在一些公司，因为老板不懂技术，产品做得好的时候不会关注程序员，不会觉得是程序员的功劳，最多夸夸产品经理。但产品出问题有bug，就痛骂程序员，认为都是程序员的问题， 老板如果认为做得好都是应该的，做不好都是程序员的问题。这样的企业不会有一个好的技术团队。 　　技术主管要少说“不”，多说“好”。不要同事每提一个方案第一反应都说“不行” ，第一反应总是找方案的问题， 要先看到同事提的方案的可行之处， 即使方案有问题也要先看看问题能否解决。即使真的同事提的方案有问题，必须说“不行”，也要充分说明理由，让同事信服。 　　想否定同事方案的时候，不要直接说“不对”，告诉同事可以有另外一种方案。 比如同事向你提出了一个A方案，你觉得应该用B方案，如果你先说对方的A方案不对，对方有抵触心理，一直想证明A方案是对的， 你再说B方案时，不一定能听进去。 我们先不要说“不对”， 而是先告诉对方还可以有B方案，这时候应该你没有说A方案不对，对方能听进B方案， 说完后再对比A方案和B方案的区别，再说可能B方案更好一些。 　　看见做得不对的地方同时也要看见做得好的，比如我们发现同事代码注释写得很少，可以这么说：“这次单元测试写得不错，下次注意把注释写好就可以了”，让人觉得不是全都做得不好，只是一点不好已而，然后才有动力去改进。 　　主管对同事的认可，是同事们做事的动力，不要吝惜自己的认可。然而作为一个技术主管，本身就是程序员出现，可能性格也内向，可能很难说出赞美别人的话。甚至在自己下属得到别人表扬的时候自己还会嫉妒。人都总想得到别人的认可，当看见别人得到认可会嫉妒是正常的，作为技术主管如果还想向外获取认可，自己的内心都还没有得到满足时，无法做到能向外输出认可给别人。这时我们需要调整一些观念，调整人生态度，让自己的行为不再是索取而是输出，希望在后面的“人生篇”能给大家一些启示。 　　除了认可，该批评的时候还是要批评，如果团队成员违反团队规范或出现严重的错误，比如变量没有安全过滤，出现一次就说一次，直到改了为止。如果说了两三次都还不听，有的技术主管就不管了，他们不愿强迫人做事，害怕得罪人。但一些原则性的问题如果自己不坚持，团队成员就很难遵守了。 ## 乐观 　　面对“半杯水” 技术主管要说“真好，还有半杯水”，不要说“糟糕，怎么只有半杯水了”。技术主管要把乐观传递给团队，让团队成员觉得“可能实现”而不是“不能实现” 。 　　比如遇到项目工期很赶，可能不能在规定时间完成，团队成员们都没有自信， 而这时候如果技术主管也没有自信，那么就肯定不能在规定时间完成了。 　　程序员大多内向，容易缺乏自信。只要有希望，就要乐观，要有自信，技术主管要给予大家自信。 ## 关怀 　　作为技术主管应该多关怀同事，了解每个人的需求。 　　技术主管不要只想着公司的利益，需要考虑每个团队成员的利益， 知道他们每个人的理想、目标、想有哪方面的提升。要让他们实现个人价值时也能为公司创造传值。 　　主管要知道每个人的困难，麻烦解决他们的困难，理解他们的难处。 　　然而，主管如何知道大家的理想和困难？同事们会把真实的想法给主管说吗？技术主管不仅要能和同事们工作在一起，还要能和大家玩在一起，大家愿意和有亲和力的主管谈心，不愿意和高高在上的主管说真话。 　　每周花点时间找同事们一对一沟通是一种很好的方式。不要选办公室这种严肃的环境来聊天， 到公司外面找一个轻松的环境。 不要一开口就说工作的事情，先聊聊家常，一开始应该问对方那种完全不需要思考就能够回调的问题，例如 “中午吃了什么？” “搭哪一班车来公司” “昨晚回家的时候有没有遇到下雨” 这么做的目的是让对方开口说话，在闲聊的过程中营造有利于谈心的气氛，接着再进一步询问更深入的问题。如何能够先暖场再切入正题的话，对方应该就会告诉你他的烦恼、不满和疑问。当对方发牢骚的时候一定要多听对方说， 要表示理解对方和认同对方。 　　比如同事抱怨“产品经理又改产品需求”， 而你知道这个也是必须改的需求，这时候不要否认对方的抱怨不对， 先说“恩，是，的确有这样的问题”，引导对方把抱怨的话都说完，然后再告诉他为什么要改产品需求，争取他的理解。 有时候对方的烦恼只是想能找一个出口发泄出去，即使他说的烦恼，你不能解决， 他说出来就会好很多。 　　经常和同事谈心聊天，还能形成“至下而上”的决策： 一个好的方案不是主管提的，而是下面同事提的；一个问题不是主管发现的，而是下面同事发现的。 ## 跟我冲 　　一位朋友告诉我共产党为什么能打败国民党，在打仗的时候共产党的军官都是说“跟我冲”，而国民党的军官说“给我冲”，国民党军官不是带着士兵冲在前面，而是让士兵们先冲，自己躲在后面。作为技术主管，也要“跟我冲”，要做好带头模范， 不能同事们辛苦的做事，自己却很闲。 　　技术主管要给团队成员们信心，只口头上还不够。比如项目工期很赶时，你只是口头乐观的说“没有问题，我们一定能完成的”，但如果自己不实际行动开始干也是很难带动大家。 　　带头行动也是教人的最好方法，我遇到过有同事每次遇到bug解决问题都要花很长时间，每次遇到bug的第一反应是认为自己解决不了，不知道该怎么办。我给他说过多次解决问题的方法，也是前面本书讲过的方法：先找错误码错误信息，用排除法缩小bug的范围等等。但他就是不能把这些方法应用起来，下次遇到问题还是不知道该怎么解决。我意识到光说无用，需要用行动告诉他怎么解决问题。然后又一次他遇到问题时，我亲自动手给他解决问题，然后在旁边看，在我不熟悉他写的代码的情况下 也几分钟就找到了bug的原因。从此之后他也能自己解决问题了。 　　技术主管不要想着自己能轻松，自己可以不用做事，对同事们提的问题不要用应付的态度。比如同事问你某个方案可不可以，你要是看都不看就回答“随便，都可以”， 你这样马虎了事的心态也是能传到给团队其他成员的，后面整个团队做事都马虎做事了。 　　技术主管注意也不要出现孤军奋战的情况，把自己封闭起来做事，团队其他成员都不知道自己在干什么， 这样起不到带头作用。 ## 不专制 　　我们要在团队营造一种“至下而上”的氛围。然而如果主管太专制，什么都是自己说了算，不听取大家的建议，那将很难形成“至下而上”的氛围。 　　开会讨论问题时，主管要先听其他人的建议，自己最后在发表观点。 如果主管先发表观点，大家即使有反对意见，但因为主管是领导，也不好反驳，不会说出自己真实的想法。每次开会讨论问题，可以先让同事们轮流两圈发表建议，这两圈主管都不发表任何看法， 第一圈每个人说自己的建议， 第二圈每个人点评一下全部建议，这时候对所有人的建议都了解，也对自己的建议有再次思考，可能会发现自己的建议不太行，某个人的建议更好。第二圈点评后主管就能知道整个团队趋向于什么建议，再综合大家的建议，发表自己的观点。主管不要光用自己的观点， 最好能再融合多个人的建议，能使方案更完善，这样其他人也会觉得自己提的建议被采纳，下次才能更积极。 对不能采纳的建议，要充分说明原因，让同事认识到建议的不足，帮助他提升，让他有信心下次提更好的建议。 　　技术主管要相信群体的力量，不要有问题只是自己一个人思考，可以把问题都告诉大家，让大家一起思考。一个人想问题难免有想不到的地方，一群人想问题会更加全面。 　　技术主管除了要注意自己的行为和人格以为，还要引导团队成员形成以下心态： ##产品心态 　　我认为程序开发有两种心态：外包心态和产品心态。 如果是外包心态，想着按产品经理说的开发就行，表面上看着没有问题，不注意程序可读性、扩展性、安全性，产品经理没有说的事情就不做，总是认为是在给别人开发产品。 　　如果有产品心态，会站在用户角度思考，会积极和产品经理沟通，反馈产品的问题。产品经理逻辑思维没有程序员强，往往容易设计漏一些环节， 比如当数据为空的页面，很多时候程序员自己处理了在页面显示几个字 “暂时没有数据”。 但如果是站在产品的角度出发思考，数据为空的提示页面要不要设计得友好一些？要不要引导用户做其他操作？发现有页面产品经理设计漏掉了及时向他反馈，让他去思考这些问题。 　　有产品心态的程序员还会在产品上线后关注用户使用产品的情况，主动和用户接触。每个人都应该去了解用户，不能在用户都不了解的情况下站在自己角度提产品问题。程序员往往站在自己角度出发认为某个功能开发出来肯定没有人用，而功能开发好后却有大量的用户使用，大家在开发功能前不要急于下判断，要用数据说话。 　　技术主管要引导团队成员养成产品心态，不是为别人做产品，这是为自己做产品。 ##用批判性思维讨论问题 　　在讨论问题时，很多人的目的就是“自己的观点不能被否认”。为了维护自己的观点，会拿一些极端例子做论证，“万一，机房起火了怎么办？” ； 或者人身攻击的方式 “这个人能力不行，他提的方案不能用”。 　　他们认为好像自己的观点被否认了就很没有面子，不管怎么样都要反驳别人的观点，维护自己的观点， 岂不知越是这样越让自己难堪，在所有同事心目中也没有好的印象。 　　技术主管要让大家都知道：所有的讨论都是“对事不对人”，并不是说你的观点被否认了就是大家不认可你这个人。 　　技术主管要引导大家用批判性思维的方式来讨论，批判性思维就是大家不要做谬论，不要拿极端少数的例子来维护自己的观点，要分析每个观点的论题、论据、结论是否充分合理。 也不要光提观点没有论据， 光说“我觉得有损公司利益”，“我觉得不行” 而又说不出理由，是很难让人信服的。 　　中国人从小接收的都是服从性教育，认为老师说的就是对的，政府说的就是对的。 学校很少注意培养人们批判性思维，所以这块我们从小就欠缺，我们要好好去了解一下， 大家可以在网上搜索更多批判性思维的资料，推荐一本比较好的批判性思维的书《学会提问》大家可以看看。 ##不等待、不欺骗 　　团队成员容易出现这样的现象： 总是等待着被分配任务，自己不主动找事情做，任务完成了也不说，等主管问才说任务完成，总想在这等待的状态下能偷点懒。一些团队按敏捷开发的流程，每天有站立会议，这很容易就会变成形式主义，站立会议每天要说自己做什么，有的成员本来没事做了也要编点事来说。一些团队要求每天或每周提交工作日志， 团队成员也容易作假，编造一些事情在工作日志的。本来一件事情今天能做完，还要留到明天，因为害怕明天没事做。如何改善这些现象，让团队做到“不等待，不欺骗”？ 　　技术主管要引导大家做到坦诚。没有事做就是没有事，没事做光荣！ 在站立会议的时候能说 “我今天没事做，大家有什么事可以找我”的人，一定能赢得大家佩服，大家会觉得他工作效率高，这么快把事情都完成了。技术主管鼓励大家任务完成后可以利用工作时间来学习。 ##解决问题的心态 　　当用户反馈产品有bug时，程序员第一反应往往是以下两种： 　　吃惊：怎么可能有问题！ 　　自信：这不是我的问题！ 　　第一反应不是要解决问题，而是想逃避责任。其实很多时候技术主管都不是在追究责任，而是想赶紧解决问题。 即使有责任，往往也是技术主管一人承担，他自己接受用户或老板的痛骂，而不会牵了团队的其他成员，不会说别人做得不好。 　　技术主管要引导团队成员先解决问题，不要自责。 　　首先，问题已经出现了，不要吃惊，问题已经出现了，这是事实。 　　当团队多人协作开发的功能出现bug，团队成员容易说“这不是我的问题”， 前端程序员说 “这不是我的问题，肯定是后端接口的问题。” ， 后端程序员说“我接口没有问题，肯定是前端的问题”， 两人都认为自己没有问题，都不去查问题。 　　当你说“不是我的问题”时，需要证明真的不是你的问题。前端程序员马上查一下程序，排除是自己的问题，并看看后端接口错误在哪儿，把接口返回结果截图告诉后端程序员。 后端程序员也要立马查一下自己的代码，确认接口返回值正确。 　　遇到问题，第一反应应该是所有人都行动起来查问题，不要再推卸责任了。 ##换位思考 　　程序员容易瞧不起其他岗位的人。 　　首先是程序员和产品经理容易互相瞧不起。程序员认为“产品经理整天只会画原型，产品的实现还得靠我”。 产品经理认为“产品想法都是我想的，程序员只是实现我的想法的工具”。 　　技术主管要引导团队成员换位思考一下。 　　产品经理并不是只是简单的画原型，他们要做用户回访，要做数据分析，要做竞品分析，做了这么多事后才能画出产品原型。程序员去做产品经理做的事也是有难度的，比如用户回访，怎么保证能让用户接你的电话，不挂你的电话，能和你反馈产品的问题？程序员要真心的认为“产品经理很厉害”。 　　同样，产品经理也不要认为程序员只是简单的实现你的想法，他们要做需求分析、难点分析、做程序架构，保证程序的可扩展性、安全性，还要考虑高并发的问题。程序员做得远比产品经理想的要多。产品经理也要真心的认为“程序员很厉害”。 　　程序员还容易瞧不起业务人员，觉得程序员比业务人员辛苦，认为业务人员每天只是嘴皮子说话，工作太轻松，业务谈成后什么就都不管了，而后面程序员要花大量时间来实现业务人员谈下来的业务。其实业务人员也不容易，他们在谈业务之前要了解客户的公司，了解客户的产品，猜测客户的痛点。每当我们下班了，业务人员可能还在陪客户吃饭喝酒。业务人员要承受屡次失败，谈了10个业务有7、8个都可能不成功。程序员要真心的认为“业务人员真心不容易” 　　程序员之所以容易瞧不上产品经理、业务人员，我认为是他们给程序员带来了事做，好像是给程序员找麻烦了。但你真的希望在公司没事做吗？ 　　技术主管尽量做得上面说的几点就有可能营造一个能让大家用心工作的环境。 　　另外还想提醒大家：做管理都会面临混乱，不可能做到完美，主管要学会放权， 不要想着自己亲自解决每个问题， 主管只负责发现问题和提出问题， 让团队里面的精英们去解决问题，相信他们能解决得很好，也许还会超出你的意料。面对问题，精英们会觉得是挑战，主管应该给他们展示的机会。