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