第二篇、时间与团队管理
根据前两篇，我们通过了一些方法和技巧知道了如何能达到技能熟练的专业人才，也知道了如何通过信众管理来拓展人脉，达到从专业人才向大神的转变。我也与一些朋友们做了线上的沟通和讨论，发现其实现实生活中大量的IT专业人才并不能成为大神的主要原因，简单的来说其实就是缺乏信众，这时候就需要借助媒体、团队的力量来行事，并且切实的实践利他主义，满足信众的需求。如果再更加凝练一些，核心点就是在众人的印象中“靠谱”。
那么今天这篇文章的展开就是围绕着“靠谱”的另一个方面：管理。那么在引入管理之前，我们先需要看几个逻辑：首先人是一种生物，生物本身由细胞构成，细胞也是一种物质的化学反应容器，因此人的种种行为可以通过生物学、医学、化学来解释。因此技术团队管理的本质可以理解为对人的编程、对人的Debug。
1、靠谱的基础
从生物神经学角度深度剖析一下人类，究竟是什么样的情况之下，一个人才会“靠谱”？首先这个人一定是健康的，我们不要指望一个人疾病缠身依然还能全神贯注的敲出华丽的程序。有人可能会反驳：像霍金那样的优秀人才是如何做到的？首先，我们要明确，霍金这样的人才实数凤毛菱角，管理也是一种提高成功率的做事态度，我们要从大概率方向出发，不能寄希望于小概率事件，就像是股票跌了，股民就是不信，非要进去抄底当韭菜，这不正是博小概率吗？其次，这个人一定在做靠谱的事情时得到了正向反馈。一个良好的正向反馈可以不断刺激神经系统产生多巴胺，这种正向反馈若是大多来自自己和下属，则此人逐渐自傲；这种正向反馈若是大多来自管理者，则此人逐渐信赖管理者。我们经常会遇到有些管理者本身技能不足，在遇到技能比自己强的下属时，往往会采用打压的做法，具体到细节有“捧杀法”、“工作量堆砌法”、“指鹿为马法”、“移花接木法”、“模糊指派法”、“架空法”、“激化矛盾法”、“甩手掌柜法”、“甩锅法”、“曲解制度法”、“渔翁收利法”……，这里不详细讨论这些恶臭的做法具体是怎么做的，作为管理者或多或少、主观故意或非故意的一定会用到这些方法，而且下属也或多或少的一定会感受到，也许谁都没有错，但管理危机一定会随之出现，因此我们一定要识别并杜绝使用这些整治策略，会而不用方显度量，好的管理者一定能及时化解矛盾，若是不闻不问任由下属对此做深度解读，久长时就变成了可传播复制的组织癌细胞。如果们在遇到这样的情况之下，很容易产生负面情绪，即使是做了多少靠谱的工作，都不会被看到，但一旦执行时产生了错误，便会陷入陷阱。在责备、扣减奖金等惩罚性措施下，靠谱的人就会变得不靠谱，不靠谱的人却极难会变得靠谱，因此当一个明明入职时很靠谱的人，突然做事人浮于事时，一定是得到了你的负面反馈，越想深入的去谈，这个人越会用最恶意的想法去深度解读你，此时就应当立即停止就事论人的沟通，等下一件事情来临时就事论事的尝试从另一个角度去给予正向反馈，毕竟人性是多面的，对不同事物的认知存在多种维度，凡事都是可以挽回的，也因此要戒掉习惯性否定他人，大不了把要批评的事绕个圈子、换个角度、打个比方去讲，最后强调“为了你的成长，公司和个人之间要创造共赢，有1、2、3种职业发展路径，希望你能扛起大梁，届时做成了这几件事，你就可以亲自选择你要发展的路径，我会一直支持你的”。第三，这个人具备与业务相关健全的神经网络系统，这通过咱们的第零篇可以很容易的做出解读，现实中大多数管理者所管理的人员往往都是专业人士甚至大神级别的人物，但是介于刚刚谈到的第二点的影响，空降或者被分配过来专业人士和大神人物的多巴胺大多数是来自自身，工作时极易得到你的负向反馈（有时哪怕一个眼神、一声叹息），因此管理工作会变得非常艰难。对于一个成功的管理者来说，介于业余和专业人士水平之间的程序员是最好的管理对象，为什么这么说呢，因为这些程序员已经具备了健全的神经网络回路，只是仍然缺乏经验积累，而此时你能给到的恰恰就是这些，极少有人会对老师产生恶意，毕竟大家都接受过高等教育。当然这里也不乏许多扮猪吃老虎的管理对象，这就需要剖析其人性和目的了，往往扮猪吃老虎者都是为了自保和稳定，曾经当过“出头鸟”，被之前遭遇的环境伤到了，所以如果给予足够的尊重、利益、情感、愿景、责任的羁绊，就能大量激发此人的多巴胺，往往会得到意想不到的效果，这样的下属在职场上是金子，可遇而不可求。
从数字神经网络的角度去试图剖析程序员，可以知道“复盘”是强化靠谱的最好方法。因为程序员长期与计算机、程序相接触，所以程序员的大脑早已实现了模型化、模式化、逻辑化，所以可能在其他行业的复盘难以得到有效的收获，但是对程序员复盘，则可以得到意想不到的效果。做事时程序员的大脑类似运用了向前传播算法和激活函数，在复盘中，则是一种由结果向起因倒推的过程，运用了反向传播算法，并对程序员的大脑进行了各种权重更新，这里不仅仅包括技术，甚至也包括人文思想、沟通策略。因此一个有效的复盘一定是短时间、简单、有针对性、有激励、无惩罚的，下属心里想的事不吐出来，新的事装不进去，栈满了，还能往里面装吗？
2、时间管理
基于自身和团队的靠谱，我们才能做好时间管理，否则在一个不靠谱的个人和团队上尝试做时间管理，只是在浪费时间。那么经典的时间管理法有“四象限”时间管理法、“番茄钟”时间管理法等等，我们都可以拿来运用。因为这些成熟的时间管理法大多是用于管理自身，本文不详细阐述这些时间管理具体的做法。那在我在做团队管理时，会使用什么方法呢？
最初我在带团队的时候，就是采用的清单（TODO-LIST）时间管理法，结果到约定时间后，往往得不到想要的结果，除去管理因素，大多数是因为时间评估的不准。这件事也让我颇为头疼，因为按一个人的标准来评估整个团队，就会出现有些人明明只需要3天做完，但是却评估了5天；有些人明明需要5天做完，却评估了3天。后来又寻找了数学功底比较强的朋友一起研究，如果一个团队的成员是固定不变的，我们可以假设他们的效率呈现正态分布，典型的正态分布一定可以做整体移动加权平均法，得出来的平均值就是团队做一个项目的平均效率。但这种方法有其局限性，有两个问题解决不了：第一，成员变化了怎么办？极端情况下团队很可能都是小白。第二，只能按整体评估，不能按WBS分解评估，画个按钮和写个缓存机制肯定不能平均，一平均就评估失真。并且这种管理方式如果真按各种维度来划分，就太过精细、复杂，以至于陷入局部最优解，换个项目、换个人就失效。
所以后来我便回归原始，依然采用清单，只是这次清单的每一项都需要项目组成员仔细斟酌、线上匿名填写，所有的任务分解会让所有人都参与一次评估。比如任务是做一个微信小程序的商品列表界面（WBS结构是“前端开发”-“微信小程序”-“商品列表界面”），每个人都有不同的理解，因此统计到的预估可能是7天、5天、2天、3天、10天。那么先去掉最高评估和最低评估（如果项目组人数不足5人，则不去掉），剩下7天、5天、3天，加权平均后是5天。因此就定这个界面5天完成。
那么如果5天完不成或者提前完成了呢？这里比如实际用了6天完成，那么就在WBS分类的“前端开发”-“微信小程序”这一项上，最接近实际天数的评估者在下次评估时权重加0.5倍，这样就解决了类似换项目、换人的问题。等下次这些人还是同样顺序的报一个微信小程序的支付界面时，统计到的预估可能是15天、19天、10天、5天、26天，先去掉最高天数26天、最低天数5天，可得15天、19天、10天，因为上次第一个和第二个人最接近实际情况6天，加上他们的权重加成，可得15天、7.5天、19天、9.5天、10天，加权得到61天，按1+0.5+1+0.5+1，得到4，平均后可得15.25天，那就最终按16天评估这个工作量，因为存在权重惩罚机制（评估失误者的权重追不上其他人的权重），因此也避免存在了评估串通的可能（串通整个团队的难度还是相当大的，更何况具体执行人为自身利益考虑也极难实现串通），这个机制完全可以用Excel来实现（最好是用系统来实现）。
最后一步就是用甘特图规划人力资源并行，如果只是简单的前端20天+后端20天+产品10天=50天，这客户一定等的花都谢了。因此我们要将能够并行的工作任务设计成同时开展，与此同时还需要注意人做事是单线程的，不可能同时做好两件事，在同一时序下，一定只让一个人专心做一件事。所以产品可以先行2天，前后端同时开工用去20天，此时产品持续设计，因此22天就可以完成所有工作，节省了一半时间，如果按敏捷开发方法，可以每隔7天给客户一个局部功能迭代产品，也许14天就可以达到用户满意，从而避免过度设计。
3、团队的管理-沟通
团队管理的核心其实只有两个方面，一个是沟通，一个是授权。
首先我们要明确的是，沟通符合28定律，即实际工作中，中层干部往往会花费80%以上的时间在于沟通，但是只有20%是有效沟通，80%以上的执行问题，是由于无效沟通、不良沟通引起。
1）沟通失败
如果工作任务下达失败，下属不能正确理解管理者的意图，肯定是沟通出现了障碍。举个例子，经常会在一些平台上看到某种看似发散思维的面试题：如果你有无限多的水，有个3升桶、有个5升桶，如何量出4升水。很多回答这个问题的人都会把题理解偏，主要是因为大脑中没有建立水桶和集合的联系，相信如果把这道面试题改成“最大容量为3的栈”、“最大容量为5的栈”、“每次只能全出栈或者全入栈”，就会有很多人能答上来，看之前的题干只会让人不知所措。
下属都有自尊的需要，谁都不会承认自己不专业，因此管理者不能明确的去讲“你没理解我的意思”，此言一出，代表管理注定失败。除此以外，还需要注意的是，管理者对下属的各种优待和奉献一定不能讲出口，很多时候话出则友尽。举个例子：某管理者对下属说：“你看，我给你还配了人，今年的待遇也给你争取了”，下属会有什么反应？下属一定内心独白是：“你给我的团队配了人无非是要完成你的业绩、给我争取待遇也无法是你要更好的利用我”，于是瞬间抬头看管理者的眼神便是“我不说透，是因为我已经给了你尊敬”，这个心理活动过程可以用上一篇的理论解释，每一次下属的隐忍，已经用“尊敬”把该还的都还完了。这也是很多技术大神做管理者不懂的一点：永远不要强调自己的奉献、也永远不要强制让下属付出，因为只有你的奉献是应该的，下属的付出才是发自内心的。这是人类的天性，想想，谁愿意玩游戏天天让系统告诉你做什么、不做什么，反复强调游戏有多炫、系统有多好？最后还不是该卡BUG还是会试图卡BUG、该出现红名工会还是会出现。
2）高效沟通的核心
首先，一定要共同明确沟通目的，谁都不喜欢被绕的云里雾里的，适当的语言艺术、打太极是无伤大雅的，但此次沟通的内容，有几个模块、什么时间完成、对客户有什么益处、对公司有什么益处、对个人有什么益处、以后可复用还能做什么……，该明确写在邮件里的就得先写在邮件里，重点在于从语气上正确表达出发点和最终要达成的结果，只有这些先行传达了，给下属一些时间想想、消化消化，然后再说“到我办公室一趟”，才能达到有效沟通，在下属对任务自我理解的过程中，就足以产生可以用来共同明确的目的。
第二，管理者不能不顾下属是否正在忙着敲代码，直接过来敲工牌，掌握沟通时间是非常重要的。试想一下，你敲代码的时候每隔30分钟被叫过去开个小会，一天8小时的工作分段拆零碎了，你会如何做？相信大部分程序员为了能好好完成工作，都要选择加班到半夜，时间长了便会萎靡不振，开始习惯这种命运，沟通越来越无效化。但这样真的是对的吗？实际上工作时长也是符合28定律，一天之内的所有工作，实际上都是20%的时间来做，80%的时间来思考，若是长时间高负荷工作，则编码能力呈边际递减效应，无限接近0。经过我的观察和互联网上搜集到的信息来看，即使是一些互联网大厂，管理模式依然很随性，程序员效率依然不高：上午9点到12点开了3小时会、中午吃了2个小时饭、下午2点到5点脉冲式处理突发问题，和项目经理，产品经理斗其乐无穷，大神小神人来人往，大会小会从不间断、下午5点之后去食堂吃个饭、花一个小时抽根烟聊聊、上楼刷刷博客反正就是不想敲代码、主管来了，打开IDE睁着眼睛冥想一下怎么解释下午摸鱼（此刻鼠标滚轮一直在漫无目的乱划）、花10分钟写个有BUG的类（总之机械键盘一定要有点动静），反正主管不会看所有代码、反复徘徊在休息室，自助咖啡机，厕所，走廊，办公区、8点主管过来开个会，看了看代码，嗯，确实有BUG、敲了10行代码把BUG解决了，开始Building，反正只要屏幕黑乎乎的在滚动就证明自己干活了、9点30下楼抽根烟吐槽到10点30、去食堂吃了顿免费夜宵、11点30还有半个小时就可以下班了，主管写邮件给副总汇报上一天进度，没空理自己，正好给组员开个会问问进度，把会议纪要粘贴到邮件里发给主管、12点下班，明天早上9点到公司继续奋斗~真是充实的一天啊！（笑~，如果想成为大神，就不要像这则真实发生的故事一样去做事）
第三，要选择正确的沟通对象，试想，当你成为超级大神并在公司具有绝对话语权的时候，兴高采烈的跟客户谈完就叫着高级程序员说：“你看这个项目3个月能不能搞定”，高级程序员拍着胸脯说：“没问题”。结果三个月过去了，什么都没有。你把产品经理、项目经理叫来后问：“某某某项目现在3个月过去了，进展如何？”。产品经理、项目经理懵了，遂把高级程序员叫来，高级程序支支吾吾的说：“底层框架还有一些问题，耦合度太高了，我问了客户，这不是他想要的，我们组正在改”。你因为是超级大神，有PMP证书、花钱修过MBA，于是专业的问到：“与干系人约定了工作任务书、产品规格，签了里程碑吗？”高级程序员听后也懵了，四个人沉默着互相注释了十分钟……。通过上面这个例子可以知道，临时起意的沟通往往无效，避免隔级汇报、隔级下达是对的，用编程的思维试想一下，你的一个完整系统有若干个AOP切面（分管主管、经理），结果巧妙的避开了所有切面直接访问业务代码，这系统还能正常运行吗？
第四，要有一定的沟通方式和方法。沟通前需要做好充足的准备，临时起意的沟通大概率是无效沟通，作为技术大神出身的管理者常常会遇到这样的问题：看着一个开源的东西不错，还是MIT、Apache授权，立即把所有组长叫来，会场除了此起彼伏的赞叹外，没有任何实质工作进展落实，其他架构师还不知道究竟发生了什么。所以说准备工作很重要，一般包括整理信息、结构化化梳理、沟通艺术构思（不能伤人、试图增加赞美）、表达效果设计（是否震撼、是否有意义、是否能团结一心、避免冷场）、排练时长设计（尽可能压缩沟通时间，言简意赅，又能让与会者充分表达）。
第五，持续跟进并给予支持。这一点要注意的是，持续跟进不代表催促，往往管理者可以通过询问第三者、中层管理人员来获得第一手的资料，若是天天催促执行者，执行效率将大打折扣。可以说，极端的情况下，如果程序员被反复催几次，每天能产出的代码甚至不超过10行。因此催促是没有用的，侧面掌握了执行进度，当执行者真的遇到困难了，要适时地对下属进行辅导、提供相关有用的信息或者可以利用的资源。比如经过打听，知道集团里有个人知道如何对接API，但是执行开发工作的程序员不知道、并且卡在对接API上超过了2天，此时就非常有必要将集团中做过API对接者的联系方式给到这位程序员，并且事先对双方的情况、项目背景、目的、愿景做简单的交换，以保障愉快的沟通。
这些就是技术团队管理中沟通的干货和技巧，下一篇博文将深入探讨团队管理的另一个重要方面：授权。
写完这篇博文也进入了深夜，同时感谢大家这段时间的回复和关注，本系列将持续更新。
相关文章：
