【51CTO.com原创稿件】现在业内有太多的技术分享大会了。我们经常会看到来自各界的高手，从 VP、总监、架构师到高级工程师，他们站到台上讲各种漂亮的基本架构，或者讲一些很成功的案例，讲怎么管理团队，讲成功学，讲如何带队伍等。
为什么要讲研发管理中的坑
一个貌似完美的技术解决方案或先进的方法论，往往看不到落地时的惨痛失败。这种案例很少有人讲。但失败的经验教训对于我们却是极其重要的参考。
我提出的第一个问题就是：别人成功的“术”，很可能不是我们的成功术。比如，我们看到 BAT 的敏捷教练讲研发经验谈的各种迭代，各种训练的方法，然而到自己尝试时，为什么行不通呢?
BAT 校招的工程师都是 15K 以上的研究生，是全国的尖子生，而我们自己的团队成员呢?我们只看到了“术”的表面，却很容易忽略“术”背后的因素，比如工程师的水平。
近两年，我们看到业内有越来越多的人分享“踩坑”的经历。有的踩坑经历会分享技术的演化路径，不再是技术呈现的最终结果，而是分享整个演化过程。从一开始的弱小，中间遇到哪些挫折，遇到问题之后是怎么解决的。这是很好的一个趋势。
再举一个“别人的成功术”的例子，比如“赛马理论”。所谓赛马理论，偏激一些地讲就是一个业务，多个团队并行做，谁做的最好谁就能留下。能承担地起“赛马”的一般只有超大规模的互联网公司。
一般的中小型公司，一个技术团队就几百人，哪有这个资源。“别人的成功术”往往是在特定的场景下、特定条件下的经验，所以脱离了背景信息，借鉴起来就会很有难度。
为什么还要讲“踩坑”这件事情?因为中小型公司研发团队或者大公司里面的小团队最稀缺的是资源和时间。为了追求更有效地达成业绩目标，团队避免踩坑越来越成为大家的刚需。
还有个有趣的说法，解释为什么管理岗的薪资会更贵。专业人员因为踩坑而没有业绩产出，大不了一个高T的100万年薪浪费了;而如果一个管理岗做出失误决策，那么就会带着几十、几百个兄弟集体跳坑。
管理岗的经验主要是靠带年薪几百万甚至几千万的队伍做千万甚至上亿的项目训练出来的。也可以说管理岗的经验主要是通过踩坑踩出来的。管理岗有多贵，主要看踩坑的代价。
一般来讲，踩坑分为两类：
- 研发管理人员自己踩的坑。
- 研发管理人员带领团队踩的坑。
我们从管理幅度的角度来给大家聊一聊研发管理人员自己踩的坑。
如何避开研发管理人员自己踩的坑
一线管理岗，带领团队规模在 10 人左右
当我们从团队领导晋升到一线管理岗的时候遇到非常核心的两个问题，一个是时间特别碎片化，第二个是不满意团队成员的业务能力，自己却身先士卒地冲上去了。
时间特别碎片化
时间碎片化在这个阶段最为严重，被开会、被沟通、汇报工作、指导下属、写文档、以及一点自己专业上的事儿。而且在这个阶段的一线管理岗还很难对“被打断”说“不”。
面对时间碎片化该怎么办?当我们在这个岗位的时候，我们所有的精力都在做什么呢?就是一件事——执行。一线管理岗不需要谈公司蓝图，不需要谈公司战略，就是踏踏实实地把手里的业务完成。
执行的过程，又可以拆成若干个关键事项。抓住了关键事项，执行结果就很有保障了。我的习惯是每周把正在跟进的一大堆事情记在一个文档中，每个事项的进度在一周内实时更新，有点像自己写给自己的工作周报。
比如，绩效考核我要跟谁去沟通，运维的事情怎么样，团队有几个重点，不同的团队做什么事，谁具体负责什么，我本人需要在哪一个时间点跟进。这张简单的表格对我的帮助很大，帮助我把自己的时间管理好，把关键事项管住。
当管理者把自己的时间和精力管住之后，会惊喜地发现整个团队业绩也会同步提升。
所以一线管理岗在应对时间碎片化的时候，核心原则是，时间可以被碎片化，但关键的事儿要保证能抓得住，并根据每周关键事项列表来 review 自己的精力投入。
自己身先士卒
反而容易使团队成长缓慢。我们常常看到这样的现象，老板给的指标重，一线管理岗总觉得自己的兄弟短期内能力提升太慢，为确保项目目标，管理岗自己身先士卒。
结果几个月高强度 996，自己写代码的时间超过 50% 甚至 60%，管团队的精力越来越少，忽然发现这几个月中团队的小兄弟们还是没什么成长。
而团队小兄弟面对外面大把的机会，感觉自己长期得不到指导，技术没提升，这时候团队人员流失风险就大了。
遇到这种情况怎么解决?我建议业绩压力再大，管理岗也该为招聘留时间。2014 年，我带的团队压力非常大，一边扛着非常重的业绩压力，兄弟们 996，另一边使劲招聘。
那一年，我面试的技术高手有 60 人，前面还有 3 轮技术面试，每一轮面试不低于 1 小时，可以粗算一下当时为招聘这件事是下足了时间成本的。但只要真进来几个靠谱的人就值了，之前团队为招聘付出的精力很快可以找回来。
保证项目目标时，还很考验管理岗的跨部门协调资源的能力，以及将客观困难给老板们表达清楚的能力，从而争取合理地调整任务目标或者引入跨部门的资源来降低团队成员流失的风险。
老板们都会算一笔账，对一支团队的业绩压力过大，把团队压垮了，人员流失了，团队重建的成本会更大。
在这个阶段，对于一线管理岗，我推荐一本书《卓有成效的管理者》，这本书的作者德鲁克开篇就讲时间管理。
二线管理，团队规模 30-60 人
这个阶段常见的几个问题有：原来带 10 人的时候精力还觉得不足，现在带 30-60 人，精力就更不够用了;通过其他的管理者管理团队，隔层管人，很容易执行不到位。
到这个阶段之后，每天就是开会，写文档，我们会发现技术高手出身的管理岗，专业能力很可能会退化。最大的挑战就是我们这层管理岗几乎决定了整个团队的水平和高度，所以压力很大。
先说精力不足的应对方法
第一，我们只能够做重要且只有我能做的事，那么其他事情尽量授权。
第二，开始保护我自己的精力，因为每个人的精力有限，对没必要的事说不。甚至只要不是需要“我”去做决策的会议，统统说不。
第三，就是整块地使用个人的时间，我觉得这个对提升工作效率帮助非常大。
举一个例子，2012 年有一段时间，我感到自己琐事非常多，其中 IM 类沟通工具经常打断我的连续工作，而工作场景切换代价又很大，于是我就把 QQ/MSN 全部关掉了，只保留邮件，还关掉邮件标题的提醒。
有一些同学说，把聊天的工具关掉了，还不实时回复邮件，别人找不到我的时候得多着急啊。请放心，你才带几十个人，如果真有火烧眉毛的事情发生，一定会有人打电话催你的。
这是我觉得提升工作效率特别有效的一招。给大家一个建议，最好把我们的时间变成整块的，20 分钟也好，30 分钟也好，这在时间利用效率方面会提升很多。
第四，我以我的时间安排为准，调整了整个团队的工作时间和优先级。
背后的思考是这样，在一个 60-100 人的团队中，信息量最大的人不可能是小朋友，一定是团队的管理岗。
这位管理岗拥有这团队中所有重要的信息，比如重要项目的业务价值，每个项目关系到自己团队、关系到跨部门团队的利益，甚至关系到公司层面的战略意义等等。
不是说团队管理岗的时间比一线员工的时间更宝贵，而是团队管理岗的时间安排，本质上代表了我们这支百人团队所负责项目在执行层面的优先级。
如果管理岗变成救火队员，那么这个团队的状态一定出了问题。如果我们看到老板时间安排的井井有条，那么他所带的团队状态往往是不错的。
通过其他管理者来管理团队
容易出现执行不到位。从二线管理岗的角度看一线管理岗，可以清楚看到他们常常出现时间碎片化和关键事项抓不住的问题。
我们曾经实践过一个有效的管理办法，对初级管理岗推行“标准管理动作”。
2012 年，我们给新晋升的开发经理推行“新晋升开发经理的标准管理模板”，内容包括技术架构方面做哪些事、每件事的达成标准、技术团队管理和技术产品运营的具体产出物，再比如开发质量要管住哪些事，团队开发资源使用效率的衡量指标。
我把这个标准管理动作模板放在那，每周定一个时间点，照着标准管他们要结果。在新晋开发经理刚走上管理岗的时候，不求他们应用所谓艺术的管理手法，先要求他们把标准管理动作统统执行到位。
个人的专业技能成长放缓，甚至负成长
解决的办法，管理者首先要确定自己的专业方向是什么，比如有人追求不断提升对业务、对行业的理解，或者有人追求对技术解决方案的认识广度。
确定自己的专业方向之后，保持与行业内朋友们的交流和互动。建立工作机制，每周留出一定精力，参与一线专业讨论，甚至一线指挥一些小项目，让自己保持专业的敏感度。
最大的困惑来自：团队的管理者决定了这支团队的高度。
- 第一个维度，从公司的角度算人力成本，少则这个团队年薪总和几百万，多则上千万。
- 第二个维度是团队的兄弟，这一年下来，几十位兄弟拿出风华正茂的时光跟着我们干了一年，到年底，我们能拿出什么样的团队业绩给兄弟们作为交代呢。
- 第三个维度是我们自己，我们在全行业排名什么样，我们做的产品在业内被不被认可。
综上几方面，来自公司的压力、兄弟们的付出、自己的期望，很大层面取决于团队管理者的水平。
我觉得这里面没有具体的办法，就是不断学习，不断地进取，UP or OUT。如果你在这个阶段，那么《明茨伯格·管理进行时》这本书很适合你。
管理层级再增加，团队规模百人以上
第一个挑战
保证团队工作质量难度越来越大。管理层级增加以后，团队的工作质量就越来越难保证了，这个时期首先梳理工作流程、工作制度、岗位职责，构建管理仪表盘，并且不断更新优化。
管理仪表盘本质上是我们的管理抓手，我们该看什么数字，不看什么数字，以及对每个数字的解读，这体现了我们带团队的功力和对业务的深刻理解能力。
第二个挑战
保证团队氛围一致性越来越难，保证整个团队对目标认识一致越来越难。当你发现团队达到几百人的时候，最容易出现这样三个现象。
- 当我们明确了团队目标之后，团队目标再被层层拆解 KPI，到团队每位成员落地执行的时候，对这个事的理解和执行不一致，甚至出现本位主义。
- 信息下达时被层层衰减，事情在传达几个阶段之后，可能与之前的事情描述就完全不一样了。
- 团队氛围和风格不同，有一个团队特别的主动，有的团队按部就班，有的团队执行力非常强，有的团队不作为还找借口。
分析以上现象，诊断问题出在这里：团队成员在信息量上和对信息的理解上出了问题，以及团队成员在团队目标、文化、氛围方面的认同不一致，管理标准不一致。
分享我实践过的有效解决办法：
- 保障信息上传下达的通道能通畅，尽量降低信息损失。
- 管理力下沉，二级汇报定期参加管理例会，不说项目，只谈团队管理，保证信息下达的深度，不断强化团队目标，统一团队管理者的价值观和方法论。
第三个挑战
在这个阶段的时候，公司层面业绩压力巨大，团队层面的高期望，自己的家人也需要我们陪伴，自己身体健康问题等，我们在这几者之间找不到平衡。
我本人在这个挑战方面，现在还没找到一个很好的办法。
如何避开研发管理人员带团队踩的坑
重构：开发工程师们的好胜心
开发工程师往往会主动发起一些重构项目，尤其在他们接管了别人的代码以后。还有某个技术流行了，什么东西火了，什么时候重构项目就冒出来了。
工程师特别喜欢把一个简单的事儿搞的特别复杂，仅仅是因为可以用上更牛的技术。这是他们的驱动力。
然后为此找一堆理由，如代码可读性差、业务可维护性差、结构可扩展性差、甚至原来的代码风格很难看、维护成本太高、原来的架构不能支持多人开发，然后再给管理岗秀一个特别棒的技术重构方案。
这是工程师们的情怀，情怀这个东西是挡不住的，是刚需。我讲一些我没有管住他们情怀时发生的各种案例。
重构失控，最小的代价是延期，有的工程师在做小项目时，他顺手重构了部分代码;你去问项目为什么延期，他告诉你原来架构不行，给它重构了，所以项目延期了。这是小的损失。
某些关键代码在重构过程中，某一个骨干工程师突然拿到了一个无法拒绝的 Offer，然后就惨了，项目遭受中型损失。
重构项目启动了，但深陷其中，出不来了，这是大型损失。
还有超大型损失，那就更惨了，弄了一个几百人上千人的项目，突然组织调整了，或预算调整了，或竞争对手上一个新功能，我们不得不停掉手里所有项目跟上去开发新功能等等。
这么多失控的项目，它的损失都是在重构的过程中导致的。
怎么来平衡这种情怀和项目失控的风险呢?
理想的情况下，我们一般都会把开发资源预留出 20%，这部分资源是技术团队做重构、架构优化或者探索创新性的项目，并把这个事情制度化。
第二件事情，专门为重构设定一个立项流程，工程师们可以重构，但一定要将重构正式引入项目流程，并做好评估，无论重构项目的大小。
第三个，针对重构项目的风险，我们要准备好风险预案。像超大型的重构，要慎之再慎。
工程师“我有一把锤子”的惯性思维
名字听起来就挺有意思，但这把锤子砸了我们自己很多次。
我们经常会看到这样的情况，算法工程师看到什么论文了，或者是开发工程师们学了新语言或者新类库，比如学了 spark，看哪都想并行计算一下。
这个阶段还不叫我有一把锤子，这个阶段叫“我得到了一把锤子，想找个钉子敲敲”。这个阶段你是管不住的，他一定会找一个大家看不见的地方练练大招，等他练娴熟了，就会出现“我有一把锤子，看哪都是钉子”的现象。
我们发现“我有一把锤子”这个事儿是非常典型的工程师惯性思维。工程师往往会从最熟悉的角度看问题，用自己最熟悉的办法解决问题。
从熟悉的角度出发，他们常常可以一下子想到各种各样的招儿，但也往往是问题还没完全看清楚，“招儿”就出来了。
真正落地执行遇到困难之后，猛然发现这把熟悉的锤子根本不是合理的解决方案，但时间精力已经消耗很多了。这是工程师们经常出的问题。
如何解决工程师“我有一把锤子”的惯性思维?
最重要的事情是需要管理岗抓的足够细，越早发现问题越好。
为什么说管理岗一天 12 小时都不够就是这个意思。你要挑战工程师直到完全搞清楚，从现象是什么，到问题分析，问题到底是什么，为什么采用这个解决方案，这个方案的特点是什么，怎么解决等等。
“我有一把锤子”这样的问题在产品团队很少出现，他们往往跟业务人员思考模式类似，会将要解决业务事情的周边情况仔细盘问一遍，他们会做预研，会做推演。
开发的同学们在研究问题时往往“跳步”，特别容易掉进去。开发的负责人要抓得细，抓的早，听方案汇报的时候要听的深。
重构的美好理想与残酷现实的差距
前面说工程师们会把重构想的比较美好。其实公司高管，CEO/CTO/技术总监们也常常寄希望于重构，主动发起重构。
似乎觉得可以通过一次重构，解决技术上的所有问题。非常遗憾，真正按我们的标准实际达成的几率极低。
有三个原因：
- 预期过高。因为任何一个东西没出来之前，在你脑海里面都特别美。
- 理想与实际之间的达成路径没有规划清楚。比如团队中有足够的工程师资源吗?如果出问题的话，哪一块能够出问题，预案是什么?会用到哪些关键技术，预研过吗?
- 还是人的原因。团队中是否存在一位能将整个项目方方面面思考清楚，从业务到产品，再到架构和研发，从最前端到最底层都能串起来的人才。如果没有上面三点的保证，全凭一腔热情，项目失败率岂能不高?
针对以上问题
首先要解决的是预期过高的问题，跟老板在预期目标方面达成一致，比如按照老板的想法，先产出一个高保真产品原型做确认。
这就相当于把天上的小龙女变成地上的小龙女。接下来找到靠谱儿的人，规划达成路径。
无论是人还是达成路径不到位，都不要随意“拍胸脯”。“拍胸脯”是职场大忌。承诺无法兑现，会让信任指数大打折扣。
要当心漂亮的嘴巴
大多数开发出身的或者典型的开发给人的印象是这样的：严谨、负责、内敛、谦逊、扎实、上进，这是典型的工程师的形象。
当我们遇到这样一个工程师：不仅追求技术，还能把技术架构讲的特别清楚，而且还能给你讲业务，搞得定产品经理，哄得了测试的妹子，可以解决团队当中跨部门协调的问题。
这样的员工，一定要当成大熊猫一样保护起来，这是未来的干部，要重点培养。为什么他们要重点培养呢?因为他们有一张漂亮的嘴巴。
据我个人的“不完全统计”，“说得比做得好”的人往往是“漂亮的嘴巴”。
- 第一个观察，大多数工程师内敛、谨慎，那么他预估项目的工期会怎么样呢?当然也是偏保守了。而这些嘴巴很漂亮的工程师，他们的性格往往比较乐观，在预估工期方面表现得乐观而激进。
- 第二个观察，漂亮的嘴巴对事物描述能力往往也强于普通青年，他们会描述的很鲜活，让我们在脑子里有一个过高的预期。
- 第三个观察，我们会发现这些人大多数成长路径比较顺。比如很小的时候，阳光外向的小孩子往往就是老师们和同学们的宠儿，在这种马太效应的正循环下，漂亮的嘴巴得到正面的激励比普通青年多的多，于是进一步在表现能力方面与普通人越拉越远。
我认为漂亮的嘴巴是典型的“谋士”，而不是“将军”，是不能带兵打仗，尤其是打硬仗;若委以重任，项目风险很大。
那么漂亮的嘴巴是该被弃用，还是该被培养呢?我坚持认为，他们仍然是培养的好苗子，只不过这些小伙伴们需要一个沉淀过程，一个将说的标准和做的标准统一起来的沉淀过程。
同时，管理岗没必要把沟通能力作为核心的考察能力，反倒是在团队工程师们不善于表达成果的时候，管理者要做到心知肚明。
对于每位员工的贡献有所了解，让员工们不要纠结于向上汇报，而是专注在工作本身，同时在奖励、晋升、项目方面给予公平的回馈，这才是管理者的硬本事。
傅强
九枝兰合伙人和CTO
为企业提供在线营销的整合投放服务。2006 年-2015 年任职当当，从工程师、架构师、高级总监到技术副总裁，见证了中国电商时代的风起云涌，先后研发了当当网站内搜索引擎、个性化推荐引擎等高实时性高可靠性服务，2011 年/2012 年推动大数据技术应用，大幅提升数据挖掘能力，崇尚“让技术创造价值”的理念，2014 年升级大数据计算能力，结合算法尤其是机器学习的能力，通过推荐系统和广告系统创造数亿的增量商业价值。
以上内容节选自 CTO 训练营出版图书《CTO说》，根据 30 多位CTO训练营导师的课堂分享内容整理、改编，包括乐视网 CTO 杨永强、360 副总裁谭晓生、跟谁学 CTO 李钢江、花虾金融 CEO 段念、极客邦科技总裁池建强等。
更多内容查看：https://item.jd.com/12065279.html
CTO 训练营为 51CTO 推出的面向中高端技术管理者的学习及社交平台，16 年推出以来受到了行业里的中坚技术力量的欢迎，邀请了行业里资深的技术高管、技术类型的投资人以及技术创业者，打造技术管理者的 MBA，帮助中国最具潜力的技术管理者成长为未来技术领域的领袖。CTO 训练营第四季正在招募中，愿意加入我们吗?
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
