《技术为径：带领公司走向卓越的工程师》–项目管理进阶

作为一个研发经理，你需要承担起为团队制订工作计划的责任。在你的上级管理层尝试制订整个季度，甚至整年的工作计划过程中，经常需要你来评估自己的团队是否能够承担某些项目，包括评估这些项目所需要的工作量，以及这些项目是否与你组员的技能相匹配。

虽然作为一个团队经理，你可以将一些项目管理工作下放给你的技术小组长来进行，但是肯定还需要自己承担一部分相关工作。

你所面临的主要任务是，决定哪些项目可以承担，而哪些项目需要推掉。同时，你可能还需要适应敏捷状态下需求的不断迭代，为每个项目预估一个大概的完成日期。

若要做好对团队工作的管理工作，你需要对团队的工作节奏十分熟悉。万幸的是，有一些窍门可以帮助你做到这一点。

敏捷与项目管理

项目管理并不意味着进入瀑布式管理模式，从一开始就将项目中的每一个细节都计划清楚。

然而，对于大部分团队来说，长期的、抽象的目标，以及短期的、具体的、面向长期抽象目标的工作计划是并存的。

当需要实际规划小的项目目标时，团队应该采用敏捷过程来快速评估项目并且分解项目目标，这样效率最高。

作为团队管理者，你不应该过多干预，甚至应该推动团队自主进行。你需要对更大范围的项目目标–那些需要数月，而不是数个星期才能完成的事情负起责任来。

预留20%的工程时间

预留20%的工程时间来处理研发可持续性工作。“研发可持续性工作”指的是添加测试用例、调试问题、重构老旧代码、更换编程语言和升级语言版本，以及其他类似的工程杂事等。

如果能够坚持这样做，你就能将一些中等大小的陈旧代码逐渐消化、转换掉。每个季度做一点就够。随时清理陈旧系统，可以降低其维护难度，从而给团队留出更多时间来进行新功能的开发。

就算不这样做，你也可以用这个时间来补偿项目过程中的意外情况。如果真的把项目研发计划填满100%，你很快会发现由于各种情况导致计划流产。监近交付时间时，管理有说“不”的义务。

设定截止日期在项目管理中是很常见的，有时这个截止日期是团队自我设定的，也有的时候是来自更高管理层的要求。

按照截止日期按时交付项目的唯一方法，就是在项目末期不停地裁剪末完成的项目需求。

这就意味着，作为研发经理，你必须和自己麾下的技术小组长与产品负责人/业务代表一起开会商讨到底哪些需求是必须交付的，而哪些需求是可以删减的。这意味着，作为研发经理，你经常需要对两边都说“不”。

说到底，你需要向技术团队交付一系列定义清晰、实现成本合理的产品需求，同时需要向产品团队解释清楚完成所有需求所需的额外时间。

更多的计划时间

软件开发时间预估中有一个“翻倍定律”：当需要测算软件开发时间时，永远将你预期的时间翻一倍。

不要每个需求都需要让技术团队预估实现时间

研发经理的时间预估与项目计划职责的的原因之一，是因为工程师针对每个需求都交付一个预估时间，不仅浪费其时间，而且徒增其压力。

管理层承担不确定性是责无旁贷的，管理都不应该将不确定性统统甩给团队成员来承担。

管理者不仅仅是技术团队和公司其他部门的传声筒。这样不仅不解决问题，反倒干扰正在实际做事的人。但是，你也不能只是团队的“挡箭牌”，而不管公司其他部门的实际需求。

你需要帮助公司建立一个针对新需求和用户反馈的持续沟通流程，减少意外情况和紧急需求的发生。

《技术为径：带领公司走向卓越的工程师》–管理项目

制定一份项目计划，需要搞清楚各部分之间的相互依赖关系。所有依赖关系都必须详加考虑，一个一个地反复讨论每个子任务的描述信息、时间安排、以及如何拆分。

领导能帮助我解决一些问题，但是更多的问题需要我自己去解决。

我一点都不喜欢这样的工作。这种体验给我留下了极为深刻的印象。我清晰地记得自己对任何一点疏忽的恐惧，对计划中的任何一点不确定性的反复斟酌。

而这一切都是为了制订一份能让领导看上的计划表。接下来我们又需要将这份计划表转化为可以展示给公司管理层的格式，说服他们接受这一计划。感觉自己简直要烦死了。但是，这也是我职业我生涯中最重要的学习经历。

现在都是敏捷开发，是不是不再需要项目管理了？

敏捷开发只是一种拆分工作的好方式，它让你将注意力集中在小型目标上，从而不停地持续交付这些目标。

但是，这不能取代项目管理。大型项目不可能在一个或两个冲刺周期内完成。你还需要向管理层预估项目的完成时间，同时附带对项目所需时间的解释信息。

另外，某些项目，比如基础设施项目、平台项目、系统设计项目，通常需要详细的系统设计，或者非常超前的项目计划。

在面对这样的项目时，存在大量的未知信息和刚性很强的时间节点，敏捷模式根本不适用。

随着职业生涯的不断进步，学会如何将超出个人能力的复杂项目进行拆分是不可或缺的。

对于一个时间周期很长、多人参加的项目进行项目管理，并不是每个人都会喜欢的工作。

这项工作过于烦琐，同时还有点可怕。我喜欢构建系统、交付功能，而不太喜欢每天思考一个细节模糊的系统如何进行拆分。

同时，我很怕自己在项目计划中某个疏忽导致项目最终失败。但是，如果我不亲自参与的话，项目也不会自己完成，而且有很大概率会浪费大家的更多时间。

项目管理不能事无巨细地进行，这一点很多组织都意识不到。

不要招专门的项目经理，因为他们往往会成为工程师推卸责任的“挡箭牌”，而非一起合作的的伙伴。专门的项目经理往往导致项目以瀑布流的方式进行，而非采用敏捷的方式推进。然而，一定程度的项目管理是不可避免的，技术小组长对技术性强的项目应该根据需要进行合理的项目计划。

于项目提前规划的意义并不在于你是否事先想到了每一个细节，对未来考虑得是否周全，或者项目进度是否完美推进。

其真正的意义在于，制订项目计划这个过程强迫工程师在动手实干之前，先对项目进行一些深度考量。

++制订项目计划的真正目标在于，推动工程师在合适的进行合理的预测，并制订针对意外的应对计划。++

至于这个计划到底有多么准确，并不一定真的那么重要。

我们提前确定了想要达成的目标，同时也提前识别出一些可能导致项目失败的问题，并且为此提前做了准备。

项目管理，让每个人认真地花时间去面对这些非技术性、无法提前预测的难题。这些困难的工作帮助每个人完成自己的复杂项目，并且帮助成长。让每个人都能带领更大的团队，更好地拆分任务，以构建更复杂的系统。

作为技术人员，我们往往假设管理层十分这解我们的所做所想。“有问题就看看代码吧”作为技术领域内沉浸多年的技术人员，我们很容易假设别人和我们一样对这些问题了如指掌。

但是，这是错误的。技术管理者竭尽全力地去招募精兵良将，是为了让这些人才来解决非常棘手的技术问题的。但是，这不意味着技术管理者全知全能。在我的职业生涯中，每次我们向一些非常资深的技术管理者耐心解释诸如“NoSQL是什么”这种问题时，他们都很由衷地感激我。

现在，我一点都不觉得向其他人（不论他们是资深经理，还是新人）介绍基础技术概念及相关技术的优势对比是浪费自己的时间。

如果以平等的方式与他们进行对话，他们就会慢慢地培养起对我的建议和决策能力的信任，而这终将有利于推动我想推动的变革。花时间向别人解释自己的想法是非常重要和值得的。

《技术为径：带领公司走向卓越的工程师》–如何管理一个项目

所谓项目管理，就是将一个复杂的最终目标分成一些小目标，同时将这些目标以最高效的方式进行排序，识别出其中可以并行开展的工作，以及这些工作前后的依赖关系。

同时，还应该试图找出那些可能导致项目延期或者彻底失败的高风险环节。

项目管理的过程，就是试图将不确定的部分更确定化、将不可知的问题变成可知问题的过程。

同时，我们也应该认识到在这个过程中犯错误和漏掉一些未知风险是不可避免的。

1、将工作进行拆分

拿一张表格，或者采用甘特图的形式，抑或采用你最习惯的其他形式，尝试将你的大目标（例如，重写应收账款系统）拆分成一些具体的小目标，继续迭代。这个过程不一定要完全由你自己来完成。

如果系统的某个方面你不是很了解，就让其他人来帮助你。

你将目标拆分到一定程度的时候，就要专注于这些任务的排序。哪些任务可以马上开始？

将其拆分成一个个具体的任务进行推进。

2、持续关注细节与未知部分

做好项目管理的秘诀就是，迎难而上，永不停止。

项目管理本身就是一项非常烦琐、累人的工作。所以不管这项工作有多烦人，有多无聊，有多痛苦，你都不要停止。

一个好的上级领导会和你一起完成这项工作，帮助你指出计划的不足之处，同时向你提出自己的看法。没有人喜欢制订项目计划，但是这是一个和上级领导共同工作的好机会，同时也是一个很好的学习过程。

一定要持续跟进项目中的未知之处，一直到无可追踪为止。

3、真正落实项目计划并时刻调整

之前的周密计划制订过程的价值所在，就是帮助你了解项目的真实进度，以及与达成最终目标的距离。

在项目进展过程中，如果出现延期情况，一定要向所有人及时通报信息。

有计划在手，你就不再需要盲目地猜测项目进度，而是可以清晰地知道项目的哪些目标已经达成，而哪些目标还没有达成。

4、利用计划过程中获得的知识来管理需求变更

在按照原始需求进行任务拆分的过程中，你对项目有了更深刻的了解。如果中途发生了需求变更的情况，这些知识可以帮助你更好地应对。

如果某项变更大大增加了项目风险，或者需要大量的额外工作，你就可以与他人明确这项变更的成本。

如果正在做的项目有一个非常严格的截止日期，那么了解每项细分工作所需的时间可以让你更好地排列优先级，甚至是割舍某些工作，平衡项目的整体质量、进度与交付时间。

5、随着项目的推进不断完善细节信息

当项目快要进入尾声的时候，烦琐的工作又出现了。

这正是落实项目每一项小细节的阶段。还差哪些任务没做完？测试做完了吗？交付验证做了吗？

可以考虑进行一次复盘模拟，提前将项目发布时可能出现的各种问题场景都预演一遍。

这也就是在落实“足够好”这个标准线的时候，让团队内的每个人都了解这个标准线，并且要具体落实到自己负责的部分。

排队那些无关紧要的工作，让整个团队都专注在落实真正重要的细节问题上。

制订一份发布计划，再制订一份回滚计划。

重读经典–《程序员修炼之道》

是什么造就了务实的程序员？

早期的采纳者/快速的适配者

你对技术和技巧有一种直觉，喜欢尝试。当接触到新东西时，你可以很快地掌握它们，并把它们与其他的知识结合起来。你的信心来自经验。

好奇

你倾向于问问题。这真不错–你怎么做到的？你对那个库有意见吗？总在听人说起的量子计算到底是什么？符号链接是怎么实现的？

你热衷于收集各种细微的事实，坚信它们会影响自己多年后的决策。

批判性的思考者

你在没有得到证实前很少接受既定的现实。当同事们说“因为就该怎么做”，或者供应商承诺会解决所有的问题时，你会闻到挑战的味道。

现实主义

你试图理解所面临的每个问题的本质。这种现实主义让你对事情有多困难、需要彡多长时间有一个很好的感知。一个过程应该很难，或是需要点时间才能完成，对这些深刻理解，给了你坚持下去的毅力。

多面手

你努力熟悉各种技术和环境，并努力跟上新的进展。虽然目前的工作可能要求你在某个专门领域成为行家，但你总是能够进入新的领域，迎接新的挑战。

重读经典–《程序员修炼之道》

大多数开发人员对设计正交系统的必要性都很熟悉。只不过他们可能会使用其他一些词来描述这个过程，例如模块化、基于组件和分层，等等。

正交性是什么

“正交性”是从几何学中借用来的术语。

若两条直线相交后构成直角，它们就是正交的。

例如，图表中的坐标轴就是正交的。对于向量而言，这两条线相互独立。图示中的向量1指向北，完全不影响东西朝向。向量2指向东，完全不影响南北朝向。

在计算科学中，这个术语象征着独立性或解耦性。

对于两个或多个事务，其中一个的改变不影响其他任何一个，则这些事物是正交的。

在良好设计的系统中，数据库相关代码应该和用户界面保持正交：你可以变更界面但不应影响数据库，切换数据库而不必要更换界面。

正交的好处

编写正交的系统，就能获得两个主要的收益：提高生产力及降低风险

提高生产力

1、将变更限制在局部后，开发时间和测试时间都会减少。

2、正交的方法同时促进了重用。

3、组合正交组件能获得相当微妙的生产力提升。

假设一个组件能做M件独特的事情，另一个能做N件。如果它们是正交的，组合起来就能做M*N件事。如果两个组件不正交，有重叠之处，结果就少一些。

在正交组件的组合过程中，单个单元的性价比提高了。

降低风险

1、代码中病变的部分被隔离开。

如果一个模块生病了，不太可能将症状传播到系统的其他部分。把它切下来并移植一个新的健康器官进去，也更加容易

2、这样获得的系统不那么脆弱。

对特定区域进行小的变更和修复后，因此而产生的任何问题都将局限于该区域。

3、你不会被特定的供应商、产品或平台紧紧束缚。

因为这些第三方组件的接口所关联的，仅仅是整个开发中相对很小的一部分。

4、正交系统可能更利于测试，因为为其组件设计和运行测试更加容易

正交的方法

设计

系统应该由一组相互协作的模块构成，每个模块实现的功能应独立于其他模块。

有时这些模块组件被组织到不同的层次上，每一层都做了一级抽象。

这种分层的实现是设计正交系统的有力途径。

因为每一层只使用它下面一层提供的抽象，所以可以在不影响代码的情况下极其灵活地更改底层实现。

工具包和程序库

在引入第三方工具包和程序库时，请注意保持系统的正交性。技术选择要明智。

当你拿出一个工具包时，问问自己，它是否会将一些不应该有的变化强加给你代码。

编码

每当你写下代码时，就有降低软件的正交性的风险。

不仅需要盯着正做的事情，还要监控软件的大环境。

养成不断质疑代码的习惯。只要有机会就重新组织、改善其结构和正交性。这个过程被称为重构。

保持代码解耦

编写害羞的代码–模块不会向其他模块透露任何不必要的信息，也不依赖于其他模块的实现。

试试最少知识原则。如果你需要改变一个对象的状态，让该对象替你来完成。这样做能让你的代码和其他代码实现隔离，更有可能保持正交性。

避免全局数据

只要代码引用全局数据，就会将自己绑定到共享该数据的其他组件上。

即使只打算对全局数据进行读操作，也可能引发问题。

避免相似的函数

重复代码是结构问题的症状。

测试

基于正交性设计和实现的系统更容易测试。

由于系统组件之间的交互是形式化的，且交互有限，因此可以在单个模块级别上执行更多的系统测试。

文档

正交性也适用于文档。其涉及的两个独立维度是内容和呈现。

真正符合正交性的文档，应该能够在不改变内容的情况下显著地改变外观。

读完刘媛媛的《精准努力》，想起了冯唐说的“结构化思维，结构化表达”。当你再怎么焦虑、恐慌时，不只是情绪表现，而应该提出为什么焦虑，焦虑怎么消除？怎么体现结构化思维，最佳表现形式，就是绘制一张思维导图。

在《精准努力》中，作者针对我们常见的问题：目标、策略、执行、心态、学习、社交六个方面进行了结构化表达。

目标篇

制定目标，我们一般会想到SMART原则，但作者提出了独特的视角：

最主要的思想就是二八原则，找到那20%的因素，作为核心目标，进行攻克。

产品质量管理中有一个法则：重要少数法则

这个法则是由质量管理专家约瑟夫朱兰提出的。朱兰认为，大多数品质不良的问题能够形成，可以归因为重要的少数，其余的小瑕疵，才是属于不重要的多数造成的。

在发生质量问题的时候，20%的问题是由基层操作人员的失误造成的，但是80%的问题是由领导者造成的；而80%的领导问题，又是在20%的重要环节上造成的，这就是质量管理当中的“二八原则”。

有用不等于值得

值不值得，要把机会成本考虑进去

为何你的努力和别的人的努力总是有差别？

如果能够抓住关键的环节，就可以更少的投入，收获更大的回报。

这不是投机取巧，我们只是追求有效。人的专注力、时间、精力都是有限的。我们必须选择一种有节制的、更专注的努力方式，去追求更高的效率，追求有用功。

当我们不知道什么问题是关键问题的时候，要把通往目标遇到的所有问题全部列举出来。问自己：

是哪些问题，导致你对现在的生活不满意？

其中的哪些问题是你认为的主要问题？

这些问题的解决，是否可以促进其他问题的解决？

通过自问自答，圈定其中关键的部分，然后在这20%的领域，投入专注的卓越努力，去得到80%的收获。

改掉只要有用就去做的思维，也可以反过来思考这个问题：如果我只做三件事，我应该做哪三件？如果只做一件呢？

策略篇

做事的正确顺序：策略，勤奋地执行策略，然后成功。

要做成一件事：

1、要有一个目标

2、思考通往目标的途径

3、最后才是执行层面的事情

每个人都应该去追求成功。在这个过程中，无论是靠天分、靠勤奋，还是靠机遇，都靠不住。最可靠的是属于自己的方法论。方法论带来的成功是必然的，只不过来得早或晚而已。

六步循环

自我定位-瞄准目标-制定策略-执行反馈-调整行动-最终完成

自我定位

什么是目标？“我想考北大”这不是目标，说得好听点，叫想法、愿望。目标要有可执行性和衡量标准。也就是要符合SMART原则。比如“我要考到240分”，这算是一个目标。

什么叫作学会解释目标？

比如要考北大，意味着两门专业课都必须要考120分；意味着这张卷子当中80%的考点我都要知道；意味着考试范围内的80%我必须得知道。如果我只知道10%的话，那么还要搞定70%，那整个复习的过程就会变成这样：找到不会的地方，变成会的，直到这个百分比达到80%。

这就是目标被解释的过程，从“我想考北大”到“我要考到240分”，到“我要搞定那此不会做的题目直到百分比达到80%”，到“我今天已经做了50%，还有30%”。

策略

策略意味着：

第一，找到通往目标的真正问题和障碍

第二，为这些问题和障碍去设计方案

第三，方案应该是一个互相促进和统一的系统

第四，集中精力去执行自己的方案，放弃其他的事情

执行

一件事情最后的成果如何，取决于以下几个要素：

效果=时间x精力x目标x策略x专注度x熟练度

执行篇

1、专注力

2、拖延症

3、精力管理

4、专注

5、坚持

最近在工作中使用一个消息队列组件。发现当系统没有完全启动成功时，就开始消费消息了，出现所依赖资源初始化工作还没有完成，造成消费失败的情况。

通过源码跟踪，发现组件开始消费是在InitializingBean#afterPropertiesSet中触发的。

怎么处理呢？

首先，InitializingBean#afterPropertiesSet是在Bean初始化完成后调用的。

而现状是想在所有资源都被初始化完成后，再开始执行。

第一种方案：SmartInitializingSingleton

spring中提供了所有Bean初始化完成后再调用的机制。实现SmartInitializingSingleton

SmartInitializingSingleton 与 InitializingBean两者有很大的区别：

1，SmartInitializingSingleton只作用于单例bean，InitializingBean无此要求。但他们都不能用于懒加载的bean。

2，SmartInitializingSingleton是在所有单例Bean都初始化完成后调用的，InitializingBean是每个bean初始化完成后就会调用。

但因为是第三方组件，也不想修改源码，所以此路不通。

第二种方案：想到了@Lazy

把触发的Bean设置成@Lazy，再所有资源初始化完成后，进行主动加载。激活具体的消息消费行为。

行动分两步：

1、在具体消费消息的Bean上增加注解@Lazy

2、spring启动完成后，再主动加载此Bean

此时，又涉及到了spring的初始化过程

spring提供了很多启动各个阶段的触发点

包括ApplicationRunner、CommandLineRunner以及各种事件：

ApplicationContextInitializedEvent : triggered after ApplicationContext is prepared and ApplicationContextInitializers are called but before bean definitions are loaded

ApplicationPreparedEvent : triggered after bean definitions are loaded

ApplicationStartedEvent : triggered after context has been refreshed but before command-line and application runners are called

ApplicationReadyEvent : triggered after any application and command-line runners are called

ApplicationFailedEvent : triggered if there is an exception on startup

结合spring初始化过程，写一个小示例，验证一下bean初始化与这些事件的先后顺序

创建一个Bean

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public class InitFirst implements InitializingBean, SmartInitializingSingleton {

    public InitFirst() {
        System.out.println("InitFirst construct method");
    }

    public void init() {
        System.out.println("InitFirst init method");
    }

    @PostConstruct
    public void postConstruct() {
        System.out.println("InitFirst @PostConstruct");
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("InitFirst afterPropertiesSet()");
    }

    @Override
    public void afterSingletonsInstantiated() {
        System.out.println("InitFirst afterSingletonsInstantiated()");
    }

}

实现一下BeanPostProcessor

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@Component
public class InitBeanPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        if (bean instanceof InitFirst || bean instanceof InitSecond) {
            System.out.println("postProcessBeforeInitialization:" + beanName);
        }
        return bean;
    }

    @Override
    @Nullable
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        if (bean instanceof InitFirst || bean instanceof InitSecond) {
            System.out.println("postProcessAfterInitialization:" + beanName);
        }
        return bean;
    }

}

监听一下各种Event

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@Component
public class InitListener {


    @EventListener(ApplicationPreparedEvent.class)
    public void preparedEvent() {
        System.out.println("Yaaah, ApplicationPreparedEvent");
    }

    @EventListener(ApplicationStartedEvent.class)
    public void startedEvent() {
        System.out.println("Yaaah, ApplicationStartedEvent");
    }

    @EventListener(ApplicationReadyEvent.class)
    public void runAfterStartup() {
        System.out.println("Yaaah, ApplicationReadyEvent");
    }

}

最后执行的结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

InitFirst construct method
postProcessBeforeInitialization:initFirst
InitFirst @PostConstruct
InitFirst afterPropertiesSet()
InitFirst init method
postProcessAfterInitialization:initFirst
InitSecond construct method
postProcessBeforeInitialization:initSecond
InitSecond @PostConstruct
InitSecond afterPropertiesSet()
InitSecond init method
postProcessAfterInitialization:initSecond
InitFirst afterSingletonsInstantiated()
InitSecond afterSingletonsInstantiated()
Yaaah, ApplicationPreparedEvent
Yaaah, ApplicationStartedEvent
ApplicationRunner
CommandLineRunner
Yaaah, ApplicationReadyEvent

整个初始化的顺序：

construct -> postProcessBeforeInitialization -> @PostConstruct -> InitializingBean#afterPropertiesSet -> init-method -> postProcessAfterInitialization -> ApplicationPreparedEvent -> ApplicationStartedEvent -> ApplicationRunner/CommandLineRunner -> ApplicationReadyEvent

ApplicationRunner与CommandLineRunner谁先执行？

在都没有标注order的情况下，ApplicationRunner 的优先级要高于CommandLineRunner

在方案二执行时，发现了Spring延迟加载Lazy没有生效的情况，后来追查到是xxl-job的bug。在遍历任务时，加载了所有的bean，包含了Lazy的Bean。在最近的xxl-job 2.4版本中进行了修复：

https://github.com/xuxueli/xxl-job/pull/3155/commits/b4835d40f18084e9facb9ec0d41993fdc885aca8

参考资料

Run method on Spring Boot startup

对于新晋升管理者常见的困惑中，“不自信”也是普遍存在的一种现象。

如何克服这种“不自信”，大家服不服我？套用江湖人的话，“谁不服，那就打到他服”。

当然，如果在普升管理者之前，你就是团队中最强的技术骨干，其他成员的战斗指数以及综合实力都在你之下，那对这个困惑估计体会不深。

但在普升管理者之前，团队内有跟你级别一样的，能力差不多甚至专业能力在你之上的成员，那将经历一个痛苦的适应过程。

不自信

其实归结起来，新普升管理者不自信的来源，主要有三点：

第一，管理经验不足和能力欠缺

很多对管理事务不知道该怎么着手，在摸索前行中磕磕绊绊，于是怀疑自己没有能力做好管理。

这是每位管理者的必经阶段，其实也是学习所有新事物的必经阶段。就像刚接触技术时一样，也经常会碰到一些不知所措的问题。

只不过，技术问题往往有比较标准的答案，通过查资料就能解决大部分问题；而管理问题刚很少有标准答案，很多经验和技巧是在不断实践的过程中积累起来的，掌握起来不像技术问题那样可以查查资料就能快速解决。这也是管理有挑战的地方。

第二，和团队成员对立比较

由于资历或能力不是团队里最突出的，担心团队里资历老或能力强的团队成员会不服自己，尤其当这些人提出不同意见的时候，常常会引起新晋管理者的挫败和颓丧。

要解决这个问题，关键是转变认知。

你现在是团队的负责人，需要把自己从和任何团队成员的比较和竞争中抽离，把目光投向远方，去看看你将带一个什么样的团队，以及在这个过程中，你能为公司、团队和团队成员带来什么样的成绩和成长。

当你不把团队成员放在你的对立面的时候，你和他们就没有任何竞争关系，因为所有的比较和竞争都是在同一个层次上才会发生，就好像你可能会和你的同学、同事比财富，但不会和马云去比较一样。

你要做的，不是和团队成员竞争、比较，也不是比团队每个人都强，而是要考虑如何让大家把自己的才智发挥出来，去达成一个共同的团队目标。总之，你要做的不是管束和控制大家，而是引导和支持大家。

你要做的，就是用大家的力量，去做出更好的成果，而不是单单因为你的职位让大家服气。

因此，当团队中有老资格和高能力员工的时候，转换一下思维，得到两个结论：

1、你真的是非常优秀，以至于你能被公司赏识来负责这样一个团队

2、因为这些老资格和高能力员工的存在，你有机会做出更好的业绩

第三，背负着沉重的包袱

因为担心管理工作做不好会辜负上级的期望，所以带着很大的压力去工作。

前两类自信来源于自我能力和角色认知的提升，那么第三类自信的增强来源于外部反馈，尤其是上级。

事实上，自信心的建立的确需要外部的正向反馈，这些正向反馈可以极大地提升你的自我认可度。

如何才能得到外部持续的正向反馈？首先要把反馈通道建立起来，尤其是和上级的沟通通道。可以和上级约好一个例行的沟通机制，定期汇报团队工作，并就已经完成的一些重要工作征求上级的看法和评价。这其中，改进建议固然很宝贵，但是你还需要寻求一些肯定性的反馈。

怎么服人

虽然文章开头戏称：谁不服，就打到他服。这显然是受武侠剧的深度影响。看看武侠剧里面，有哪一帮派的帮主或掌门人不是武术最高的？

可管理者终究不是武侠剧里面的掌门人。看看武林第一的少林寺方丈，功夫深还得看扫地僧。再说还有梅长苏呢。

所以首先需要确立一个认知：管理者在技术实现能力上并不一定比团队的技术骨干强。管理者比下属技术能力强又如何呢？技术更强就能服人吗？如果你沉浸在“让自己最强”的表象中，就会导致一个问题–你的水平会成为整个团队的瓶颈，这可不是公司希望看到的。

级别越高的管理者，越应该明确一点，管理者的目标是让团队的成员更强，凝聚力是多高，从而可以一起去攻克更艰难的目标，而不是证明你比你的下属或者平级更强。

有了认知，如何赢得骨干的尊重呢？三步走：“给干将搭台子”，“克服心理障碍”，“提升自身能力”

给干将搭台子

第一、给充分的资源支持

给资源支持，分对内、对外两个方面

对外，平时你要多找一些需求点，然后把你的员工推出去，让他们去负责解决这个强需求点，并且要持续地推出去。

对内，为了团队的核心骨干能有更好的发展，你需要给他们提供充足的支持，努力去找需求、要资源、要认可，让他们获得真正的成长。

第二、让员工有被需要的感觉，让他感觉自己在这个团队里“独一无二”

不耍语言技巧，陈述事实。说出每一句话都是真诚的。

“这件事很有意义，但是也很难，就我们组织目前的人员配置，只有你最有可能搞定这件事，我没有别的选择，只能靠你”

克服心理屏障

你有没有遇到过这样的情况，你明明觉得你的平级或者团队的高级别员工有些事情做得让你不满意，但是因为他们级别高，或者你觉得他是个硬茬，而你没有足够的感情强度去把他们的问题指出来？

当你没有了解具体的细节，或者对事情的认识不够深刻时，就去给员工提意见，那效果一定会很差。所以，你给员工提意见和建议的时候不要空谈，要不绕弯子地谈具体的细节。了解得越详细，你提意见的时候也就越有底气。

提升自己的能力

如何提升自己的能力呢？没有捷径，最有效的方法就是去经历挫折，主动去走出舒适区，把每一次办砸的事情都看成“天将降大任于是人也，必先苦其心志，饿其体肤”。犯错比不犯错好，人从失败中汲取营养的效果远好于从成功中汲取营养的效果。

总结

当你知道了这些认知，自信心也不是一两天就能建立，但得相信你的上级，你被提拔为管理者，绝不是他的一时冲动。就好比你现在需要从团队中提拔一个新管理者一样，当他需要像你现在的情况，你会怎么鼓励他？“
你也许不是那个最强的人，但是你得相信，你是此时此刻做这事儿最合适的人”

所以相信自己，既然你被认命为这个团队的负责人，你就是此时此刻带领这个团队最合适的人。

管理是一门实践科学，从“知道”到“做到”，还需要长期地刻意练习。

管理有两个对象：一个是“事”，一个是“人”。

“事”指的是目标，“人”指的是团队。也就是说管理有两大基本职责：一是达到目标，二是建设团队

在担任管理职务之后，过去的业务思维和行为模式没有及时转变过来，则会在实际操练过程中，会碰到各种各样的问题，这是常态。

如果提前知道前面有哪些“坑”是最容易踩到的，就可以提前规避，选择跨过去或绕过去。

最近在读了几篇管理材料后，对于有哪些“坑”，做了简单的收集。

《技术管理案例课》

1、管理太细

陷入微观管理；

要么给部下制定出特别详细的解决问题细则，而不是给问下提出问题让他自己拿方案

要么就是不停地去盯问下的进度和要求问下汇报工作，不等部下自己去思考和做事就先给一堆意见

人的本性是要自由，要我的地盘我做主。

要注意下属对自己话语权威性的追求和对自己是一个靠得住的人的自我认可

2、大包大揽

“与其等他做，我自己早就做完了”

要么你不要把这件事交给下属做

要么你就跟他说清楚他的责任，然后让他全权负责

下属不吃点亏是长不大的。但这个“亏”必须是我们这个部门能承受的

3、迷信流程

误以为流程能解决一切问题

要提高组织效率，不脱两层皮付出点代价是不可能的。

我们真正的难点在于怎么用人，怎么拿捏流程不能处理的意外情况。

想要用好人，首先就要了解这个人。知道每个下属擅长做什么？不擅长做什么？他在乎什么，反感什么？谁和谁搭配能够形成互补？这需要进行长期积累和挖掘。

与其花大力气把这个人拗成你希望的样子，还不如专注在怎么用好他的长处。

4、刷存在感

邮件和会议里频繁出现，但很少看到他做关键决策

必须问自己，为什么团队需要你来做经理，你给团队提供什么额外价值，你对于所管理的团队有推动感吗？

对日常工作中的事情有了独立见解，也能做关键决策促进一些事情的解决，但没有长期目标，没有制定为了达到长期目标的阶段性举措。

5、不能聚集

对于多个项目，平均分配注意力

要做成一件事，必须要聚集。如何判断有没有做到聚集？简单地说，就是你得有一个且只有一个目标。

作为主管经理，在同一时间有好几个项目，你的主要精力只能放在其中一个项目上，绝对不要平均分配时间。

6、不会说不

对兄弟部门、上级领导无原则“认怂”

有理有据，采用“不夸大，不缩小”的策略。

对于老板的要求，可以问老板问题以获取更多信息。比如，你可以问老板：我们为什么要做这件事？你的具体期待是什么样的？我现在碰到的具体困难是这样的，如果你一定要做A，在不增加人手的情况下，我现在手头的B项目会受影响。

《技术管理实战36讲》

1、过程导向，被动执行

管理思维：管理看结果，员工看动作。

没有从“管理者”的视角出发，所以至少带来如下后果

1、团队方向感缺失

2、团队做不出有效的业绩

3、无法带领一个团队

2、大包大揽，唯我最强

包工作、包责任、包功劳

会带来如下后果：

1、梯队问题

2、激励问题

3、个人发展问题

3、带头大哥，当家保姆

1、不职业的管理风格和文化

2、团队没有方向

4、单一视角，固化思维

1、习惯性卡住

2、认知层次低

3、难堪重任

5、自扫门前雪，固守边界

角色和责任的边界划分，是为了分工和合作，但由于很多大型项目有赖于多个团队一起协作完成，所以双需要有人主动站出来，去承担边界模糊的那部分职责。

作为员工边界分明无可厚非，但作为一个管理者，需要以全局的目标为己任，才能拿到公司要的业绩结果。

否则会带来如下问题：

1、项目推进不畅，从而影响全局的结果

2、自我设限，因此个人成长受限

3、个人影响力无法扩展

6、患得患失

对此详细的解释在《做技术还是做管理》文章中已经描述。

《不确定的危机下，做确定的业绩》

管理认知不到位，会出现充当二传手、过度亲力亲为、充当救火队长等管理错位现象

第一种：充当二传手

上级有任务给到管理者，管理者就直接转给下属。

下属有问题，管理者就让他直接找上级。

上级和下属都觉得组织当中最没有价值的就是这种管理者。

第二种：过度亲力亲为

这种管理者责任心非常强，他认为自己既然是团队管理者，所有的工作都应该是自己的工作，就应该事事冲在前面，做出榜样给下属看。

因此经常看到团队管理者玩命干，可他的员工却没事干。管理者的能力再强工作再忙，也不可能靠一己之力完成整个部门的业绩。

第三种：充当救火队长

由于没有事先分工，没有明确职责，没有设立流程，没有奖惩制度，没有充足训练，导致工作到处出问题。

对于技术管理者来说，团队执行力这件事，不是什么难事，因为工程师有一种确定性思维，“靠谱”是好的工程师天生的品质，凡是明确答应过的事情，往往都会如数兑现。

虽然如此，但也不能确保每件事都是落地有声。也有很多时候，技术管理者也有如下的心声：

1、这事我来干，一天就搞定了，怎么搞了一周？

2、如果A也像B那么积极主动，这个项目就不会出问题了，所以A，你能不能更主动一些呢？

3、我们各种各样的流程都有，很完整也很系统，但是大家就是不按照流程办事

如何有效地推进事项的进展，按计划成功落地。需要做好三件事：事前规划，事中跟进，事后总结。

事前规划

此阶段，重点就是做好计划。把事安排得明明白白。计划就是达到目标的路径图。

优先级

首先得有“资源是永远不足”的认知。公司本身也是在有限资源下利益最大化。

到每个团队的资源更是如此。常用判断策略就是：重要紧急四象限。

换个角度，我们都是要趋利避害的，从收益大小来看事情的重要性，从损失大小看事情的紧急性。

那么重要紧急四象限就换种画法：

计划

各个任务的优先级确定完成之后，就得给优先处理的任务制定落地计划。

而达成计划共识和计划落地是计划中两个重要的部分。

计划共识

共识的第一层境界：听懂

讲得人要讲得清楚，听得人要听得明白

共识的第二层境界：认同

认同就是认可和赞同，实现上下同欲

共识的第三层境界：行动

共识的终极目标就是要促发下属行动

计划落地

计划制定完成，也与团队达到计划共识，剩下的就是计划落地，开始执行了。

这个阶段有两点比较关键：

1、职责清晰，责任到人

2、团队的排兵布阵

OGSM模型

目的、目标、策略、衡量标准

事中跟进

下属不会执行你要求的，但会执行你检查的。检查到哪儿，执行到哪儿。

事中阶段有三个重点：行动、规范和进程

行动：检查计划有没有在推进，能力和意愿是否到位，及时辅导和鼓励

规范：过程规范，结果才正确。检查基本流程和机制是否缺失，工作流程是否规范

进程：按照其实制订的工作计划，定时检查工作进度

事后总结

总结最好方式就是复盘。

不管工作的结果好与坏，看看工作过程中有哪些经验，有哪些问题，接下来目标如何调整，计划如何调整，执行如何优化，经验如何固化。

其目的是着眼未来，确保下个阶段工作做得更好。

寻找任务成功的必要条件，也就是关键节点。

思维导图

《技术管理实战》

《不确定的危机下做确定的业绩》