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