本文由 dbaplus 社群授权转载。

大家好，我是快狗打车的产品技术设计团队的负责人沈剑，可能很多人通过“架构师之路”认识了我。在这些年里我身上肩负着架构师和团队领导者的身份，完成了不少系统的产品设计，也从一线管理者晋升到现在整个产研团队的总负责人。

其实在这个过程中需要设定很多目标，包括团队的目标、业务项目的目标和技术项目的目标。今天分享主要集中在让大家了解，作为一个管理者或项目经理可以通过哪些方法和工具去达成既定的目标。

如果你是一个团队的负责人，或者未来也希望成为团队负责人，又或者你正在带领业务和技术项目、正在参与项目且未来希望能够带领项目，那么我希望通过今天的分享能够帮助大家解决以下三个问题：

如何达成既定目标；
如何制定计划；
实现团队目标。

前言

在开始分享前，我在这里先抛出两个问题：

管理者的职责是什么？

我的理念是，作为一个管理者在面对上级、同事和下属的时候职责都是不一样的。

面对老板，我们必须完成给定的业务目标或者项目目标；面对同事，我们就要为队友赋能；而面对下属，我们不仅要帮助他们解决问题，还有帮助他们成长和提升，也就是帮他们搭舞台唱戏。以上是我认为，作为一个管理者要尽到的核心职责。

然而究其根本，管理者的职责其实是实现自己承诺的目标。面对老板就是要实现承诺的业务目标，对同事是实现对合作的承诺，对下属则是对你实现承诺的方法和资源。管理者并没有拥有很大的权力，多大程度上实现了承诺过的目标才是岗位价值的体现。分层次说的话，CEO要实现自己对业务总体目标的承诺，CTO要实现对产研项目、产品系统交付的承诺，而总监经理要实现对交付质量、技术体系建设、组织能力建设的承诺，员工也要实现对自己在项目、在系统中负责的稳定性、迭代、效率和质量的承诺。

我们对管理者基本的要求，就是实现自己承诺的目标 。如果目标没有达成，那这个管理者就是不合格的。

管理者如何实现目标？

达成目标的要素有老板的支持、清晰的目标、下属的能力、到位的监督等等，可能每个管理者实现自己目标的关键要素都不一样。

回想一下，我们在做项目的过程，是不是先定下项目目标，然后是项目负责人，接着拆解、监督跟进、风险评估和改进、过程改进？这个流程可能大家没有一个系统的说法，但它就是使用计划管理去实现目标的。整个定目标、做计划、行动、复盘、调整行动、达成目标的过程其实就是计划管理。特别是在效率交付这个方面，对负责的相关研发部门来说，计划管理极其重要。

一、什么是计划管理

1、计划管理

要做计划管理，那就要先说说什么是计划。计划就是目标及一步步实现目标的步骤。想看一个企业做得好不好，带领一个团队带得好不好，我们要重点看其是否养成了做计划的习惯，因为做计划是一个主动规划的过程。

但是很多人会说：“很多时候我只是被动地被安排工作啊，老板让我做什么我就做什么。”

被动安排工作，很可能是你的老板在做计划而你只是执行他的计划。很多的时候，业务变复杂了，团队也扩张了，很多管理者就不会做计划了，或者做好的计划就乱套了，这样对项目推进有很大的影响，所以我们必须养成做计划的习惯。

计划管理是我们做一切管理的基础，是达成目标的一个工具。

2、流程管理

我们知道做产研项目的项目流程是提需求、接需求、需求设计和评审、研发设计和评审、研发链条测试上线部署。

那么流程管理能解决什么问题呢？重点解决的问题不是说哪个人在哪个环节进行审批，而是大家的分工问题。我们要知道整个流程需要哪些岗位来配合工作，借此设置产品、研发、测试和运维的岗位。流程管理是用来确保人人有事做，事事有人做，并且在整个项目、业务流程中，每一个岗位都是明确的。

3、组织管理

组织管理的内容是确定权责，它主要解决了负责人必须有权，有权的人必须负责的这个问题。

在实际落地的管理工作过程中，如果推进流程清晰、岗位分工明确，那么组织管理的工作就会比较少；反之如果推进流程模糊、岗位分工也含糊，那么管理者就需要投入大量精力去解决关于流程的问题，去解决组织上需要权责清晰分明的问题。

实际工作中，花费在流程管理和组织管理的时间还是比较少的，更多的时间用在计划管理上，需要做好设定和达成目标的工作。计划管理、流程管理、组织管理分别解决不同的问题：

计划管理， 解决设计计划、明确目标、合理分解任务和达成目标的问题；
流程管理， 解决流程和岗位要清晰，人人有事做，事事有人做的问题；
组织管理， 解决权责问题，确保组织合理，做事的人有权、有权的人承担责任。

这是基础管理最重要的三项内容，如果你要做更高阶的管理，往总监、VP、CTO的方向走的话，那么在管理工作中你还需要思考高阶的管理，比如说战略管理，我们要建设怎样的能力，又比如说文化管理，我们如何能够持续地建设能力并且在各个方向上文化都拥有战斗力。

计划管理是我们做好一切的基础，是达成目标的方法。 做好计划管理，基本上你就是一个80分的一线或者二线管理者。

二、计划管理最佳适用范围

问题：销售的目标是一个需要达成的销售额，销售额按月度考核，有的时候目标达成了而有的时候没有，那么我这个月需要怎样制定怎样销售额度。以上算不算计划管理？

答案：不算，这个例子更偏向于绩效管理。

对于直接为业务结果负责的部门，会特别注重绩效管理。但是对于不直接背负绩效管理指标的部门，绩效管理就不是这个部门的管理者最关注的的事情。像是最典型的研发部，它们为交付服务而存在，是一个注重效率的部门，要求快速、高质、高效地交付产品和系统。

计划管理适合关注效率而非绩效的部门。 对这样的部门来说，其核心管理方法论就是计划管理。

还是典型的例子，对技术部门来说，他们的主要职责不是技术驱动业务的部分（少数公司例外），更多的是为交付而负责，确保高质量、高效、安全、低成本地做系统交付，十分注重过程和效率。所以计划管理非常适合像研发这样的团队去做管理。

三、计划管理也是一个过程管理

有一些团队拍着胸脯说：“你就不用管啦，我季度末给你结果！”

这不算过程管理，它虽然有目标有结果，但是却没有关注过程，所以它其实就是绩效管理。像这样“不用管，到时候保证给出结果”的情况在很多公司和团队中都存在，这种管理方式极其容易出现管理失控。

结果团队，例如销售的KPI管理的review周期比较短，通常以周或者月为维度来review销售结果，这严重依赖个人能力而不是制度或者流程。过程管理运用到研发团队身上的话，绩效考核一般来说粒度更粗，以季或者年为维度review结果，也就不大会出现“拍胸脯”的现象，以避免管理失控。

既然计划管理是一种方法和工具，想要做好管理就需要去多学习、多练习。那么如何培养好好的管理习惯？大家回想一下自己的编码习惯是怎么培养出来的，应该就是通过不断写代码而训练出来的。所以类比一下，对于计划管理也是一样的，我们需要养成做计划的习惯，刻意训练自己运用这种管理方式的习惯。

举个例子，比如我负责58到家的技术部，而且在2020年有一个“提效、为效率负责、为项目交付吞吐量负责”目标。首先我会和技术团队解释我们有这样的目标是因为它与我们的职责相关，然后明确目标的内容是“本季度或者本年的交付吞吐量要提升到20%，线上线下bug要降低多少”等等。

其实这就是要向你带领的团队明确我们 为什么做、做什么和怎么做 ，以及其他细节：

为什么做？ 为了提高效率；
做什么？ 建设技术体系；
怎么做？ 讨论现在效率的瓶颈是什么，找出项目流程中的主要矛盾到底是需求评审阶段、项目设计阶段、研发阶段、链条阶段还是上线阶段。哪个过程最耗时间，如果是需求评审阶段很低效，产品没想清楚，那么我们这个季度就会主要抓这个部分来提高效率；如果是上线阶段，我们没有好的工具和平台，都是依赖于人肉，整个过程都是主要矛盾的话就重点抓这一块；
时间节点？ 季度；
负责人？ 我，沈剑。

四、计划管理五要素

看完之后其实会发现，上面说的 做什么、为什么、怎么做、时间节点、责任人 这些要素，不管是带领团队做产品项目、业务项目还是技术项目，在计划管理中就是最重要的五要素。为了方便大家记忆，计划管理五要素可以记成“他问我为何”，也就是 Target、Why、When、Who、How（TWWWH） 。

1、 T（Target）：

首先设定好目标；
其次这个目标必须承接战略和部门职责，比如说部门职责是提高效率、高质量、低成本、安全地交付。目标必须和职责相关。为什么要建设技术体系，一定是更高效、更高质量的和交付相关的。

2、W（Why）：

项目成立原因，比如研发团队的职责相关，所以要提高效率、建设技术体系、改进上线流程、改进产品协作流程等等；
这个点是负责人和管理者在做计划、传达的过程中最容易忽略的一个点。很多时候我们只跟大家同步业务目标和结果、项目目标和结果，但是没有传达为什么要做这件事情，这就导致了很多员工执行不到位。是因为他们在做这件事情的时候，本身就不认同这件事情的目标，也不知道为什么要做；
比如目标是技术体系建设，有些运维人员会觉得自动化运维工具会取代自己的岗位，他不认可这个目标。但是这个工具在平台建设中和部门职责息息相关，是必须要完成的事情。所以，在传达的时候要解释清楚这个工具会帮助运维团队提高工作效率，让他们有时间专注在其他关于自动化的工作上，而不是不断重复上线操作。这样，一旦他们认可你的目标之后，执行计划和配合工作才会更加顺畅。

3、W（When）：

时间点很重要，比如本季度或者今年要提升多少；

如果你说今年要完成5、6个项目，员工听着就会觉得时间粒度非常粗且不可控，会导致他们完成的信心指数非常低。如果把这个时间节点进一步细化和拆解，今年要完成5、6个项目，其中容器化项目实现需要12个步骤，并且每个动作需要1个月来完成。这样将时间点做了细致的拆解，听着相对可控，员工对于完成这个指标的信心指数就会比较高。又比如说这个项目需要2个星期上线，时间粒度粗所以项目风险也高，如果你说项目需要研发几个接口、每个链条和自测需要多长时间，时间拆解越细，老板对你完成这个计划的信心指数就高；
对于时间这一块想要强调的是，在做计划时尽可能将时间粒度拆解得细、最大程度明确动作，这样老板看完你的计划之后信心指数比较高，会觉得项目交给你之后他就不需要实时和你同步项目，他可以把精力放在别的项目上。

4、W（Who）：

在计划和管理中，责任人要对整个项目负责；

项目成功，就要奖励；项目失败，责任人就需要对项目负责。

5、H（How）：

分解、实施、review、复盘、改进行动计划以达成目标；
需要完成计划、明确目标、上传下达、提高老板信心指数；
举一个很粗粒度的例子，2019年我负责58到家的技术中心，当时老板向我提了一个要求，就是要提升团队的效率。提升团队的效率是在明确职责的前提下，相同的事情能够让更少的人去做，或者是人数不变的情况下承担更多的职责。我会首先，按季度粗粒度地将计划进行拆解：
- Q1：在架构侧、中台侧、基础服务侧和企业平台侧，可能要做效能的提升；而运维侧和IT侧可能需要成立虚拟的组织，让更少的人能去做更多的事情。Q1要成立一个创新的部门，去做一些创新的事情，Q1可能只完成了一部分，等我把这一块拆解之后，就把这个目标给相关的总监，由他做更细化的拆解；
- Q2：可能有两个部门的人效比较低，有人员的汰换或者质量部、效能部的重组架构调整，那我Q2主要抓这一块的矛盾；
- Q3：有些部门反馈到数据部，觉得效率比较低，那么就要对大数据进行调整。同时创新的方面，又孵化出了一个保险业务；
- Q4：我做了一级的拆解之后递归给下面的总监和经理做二级的拆解，可能最终年效提升了10%，节省40%的人完成过去相同的工作，又或者在人数不变的情况下，我还孵化了两个创新的产品。
我必须确保在我的管理范围内，所有人都知道我们的年度总目标是什么、为什么要做、计划是什么、每一块的负责人是谁、初步的规划怎么做。

大家可以想想，你们的团队是否明确了今年整个技术部的目标，或者你们部门是否明确了目标，又或者你们最近一个项目的目标是什么。你的团队人员究竟是清清楚楚，还是简单地被分配和执行工作。

如果他们对目标不清楚或者不认可这个目标，在执行的过程中就很有可能出现很大的阻力，也会有很多的问题。

还有就是，你们到底有没有和他们讨论怎么做。很多人会这样说，“人效要提升40%”，那你没有具体拆解过的行动计划，如果没有那最后就是靠天看这个目标能不能达成。

有没有负责人和明确的时间点，在怎样的时间节点要达成怎样的目标。

所以TWWWH（他问我为何），目标、为什么、时间节点、负责人、怎么做这五项因素在做计划管理中非常重要。

五、计划管理核心讨论什么

1、怎么做很重要

计划管理最核心应该讨论：怎么做。

举个具体的例子，比如我所负责的快狗的技术中心的部门，Q2的项目吞吐量中一个效率指标要提升30%。我们初步定的目标是30%，挑战点的目标是50%，其实我们并没有花多大的精力去讨论目标是30%还是50%。但是很多同学在做计划的时候会很精细地计算到，“我要提升15%，我算过了，做A可以提升5%，做B可以提升5%，做C和做D可以提升5%，所以总体可以提升15%。”

我不知道大家在定OKR的时候是不是这样细算出来的。我们知道，制定OKR的时候要制定有挑战的目标，而且最好50%概率能够完成，也就是跳一跳能够得到的目标。

所以你要把效能提升30%还是35%还是50%，其实没那么重要。甚至很多业务，你问他的业务增长目标是怎么做出来的，这很有可能就是老大拍板的。

怎么做非常重要，在做计划管理的过程中我们应该把时间放在讨论怎么做上面，重点应该讨论行动计划的制定。

我们重点需要花时间去想，执行中可能会有的潜在困难、这些困难的解决方案，再配合定期的执行、校验和行动计划的更新。

2、如何复盘

定期的执行和检查，我也不知道大家会不会定期复盘项目，你们的项目复盘会怎么开，重点说什么，但你们想一想是不是下面这个样子：

首先摆数据，我们订单增长了多少、效能提升了多少、体系化项目进度是多少；然后找原因，解释这个地方为什么没有达成预期，去做各种各样的解释。这是一种非常错误的复盘会。当然找原因是必须的，但是你会发现你找到原因解释，对后续的改进没有任何意义，所以复盘会上要重点讨论什么呢？

要重点讨论后续的行动计划、潜在风险、解决方案和行动的变更。 制定计划的时候要讨论行动计划和怎么做，复盘的时候也要重点讨论行动计划。之前做对了的我们要继续做，什么行动要保持，之前做错了什么或者什么没有做对，我们也要纠偏回来。

但是我参加过很多复盘会，这些会可能都和追责有关。很多复盘会做这样的工作，通篇都在解释为什么这个项目没有达成预期，不是我的原因而是别人的原因。

我又举个例子，我对Q2产品效能的提升定了一个50%的目标，最终目标完成了80%。Q2过去之后，我们要怎样复盘？

我们做对了什么？可能是组织架构调整了，目标更清晰了。原来一开会大家都在扯皮，说测试是瓶颈所以要加测试，说前端是瓶颈所以要加前端。我将组织架构调整成相对闭环的部门，业务里有一个研发小组，包含了测试、研发、前端和后端，那么原来沟通的成本就降低了，大家都看齐同一个业务目标，背一个业务指标，扯皮就减少了，沟通就更高效了，这样对项目提升可能有帮助。

最简单的方法，比如说五、六月份是战略重心，有几个战略项目都要上线。有些老大会说，“这两个技术团队的同学辛苦辛苦，周六来冲个刺。”这样可能团队多工作一天就提升了20%的效能，但我特别反对长期通过这种方式来提升迭代速度。我们还是要通过优化流程和工具去优化、提升速度。

又像刚刚说到的流程这一块，在项目流程过程中，原来在需求阶段可能存在问题但我没有改进，所以最终只提升了5个点。

或者说，原来上线都是通过人工，而现在用自动化的上线工具；原来搭建测试环境需要很长时间，现在通过自动化的方式去搭建测试环境，这样对效能的提升是肯定有帮助的。这方面就需要管理者了解当前的主要矛盾，并去解决这些主要矛盾。

如果你觉得人员技能不到位，那你就能要去做培训；你觉得不靠谱，那你就要做汰换。反正到了季度末我们复盘的时候，做对了的事情在下个季度就继续做，做错了的事情就要停止做，能够继续迭代的空间，我们就要去优化。

在计划管理的过程中，大家要多花时间去讨论行动计划，在复盘中讨论做对了什么、行动计划要改变什么，而不是单纯的质量和数字，以及解释、推脱或者甩锅，这样对后续达成目标没有什么帮助。所以我想表达的是，花时间的重头戏应该是制定行动计划。

六、计划管理的两大特点

1、目标不合理性

前面提到了怎样的OKR是好的OKR，如果你达成的概率是50%，50%概率不能达成，这个目标跳一跳就可以够得到，那这样的目标是好目标。

再举一个例子，Q2有一个项目是IDC或者叫集群，快狗侧可能有几百个集群原来做了过度的设计，微服务化拆分出了太多细粒度的服务，导致维护起来成本很高。那我们说Q2可能要做一些集群的合并和架构的优化。

当时项目有一个负责人，我让他提一个目标，他纠结了很长的时间，说我不知道集群要减少10%，还是15%，还是8%。但其实你会发现，不管这个值是多少，后面重点要花时间去讨论的是行动计划、怎么样合并集群、架构怎样更合理、以什么样的节奏去执行。其实目标是10%还是30%，和后面讨论的行动计划是没有关系的。所以后来我就说，那我定下20%这个值，然后Q2就按照这个目标去走，看Q2能不能达成20%的OKR。

OKR和KPI不一样。KPI达成与否跟你的涨薪或者跟你的绩效有关，但是OKR指定的是有挑战的OKR，所以你的leader一定要综合实现难度系数去打分。虽然说我拍了一个目标，但是因为我是一个技术专家，所以我在拍的过程中是有所谓的专业手感的，我并不是瞎拍的。

我实际是想了一下，20%的目标去做工作有一定的挑战，但就是能够实现的。在这个拍目标的过程中，能够体现我的专业手感。在一个专业领域里浸淫久了，拍目标的时候其实能够体现专业手感，IDC减少多少、效能提升多少、订单增长多少更合理，这些都能够体现你的专业手感。

总之，计划管理有一项特点是目标不合理，因为目标本身是一个预测，目标要符合战略的要求，而且目标更重要的是体现你对某一部分的决心。很多时候项目目标定下来了，团队管理反而简单了。有些团队之所以不出成果，是因为花了大量时间放在目标讨论上，而且在制定目标的过程中往往也提出了很多困难，去强调达成目标非常有挑战，并持续降低自己的目标，直到目标降低到自己有把握的程度。这个不是OKR，也不是计划管理。OKR不是在制定目标的时候有大概率能完成的感觉，而是一个有挑战的目标。

未来也希望大家在做计划管理的过程中，能够制定一个有50%概率能够完成的目标，这就是一个好的OKR目标。目标在制定的过程中也能够体现你的专业手感，所以如果你让一线的同学来这个事情会更不靠谱，因为一线的同学更多思考自己怎么才能不出错，所以你让他去定目标，一定是自己能够实现的。他们关注的更多是自己，可能不是业务或者公司的压力。

我们作为leader，有一项非常重要的要求，你要同时具备内外部视角。外部怎么看问题，你的老板希望你能达成什么目标。而很多一线的员工可能缺乏外部视角，他们可能更多思考的是做什么能够不出错，所以我要制定一个我能够完成的目标，这样我就能拿到奖金。这就是典型的KPI或者自我的思维。

计划管理的第一个特点，也是不必花太多时间精准地制定目标。很多时候大家精准地讨论目标，就会强调这个事情有多难、多有挑战，会持续地降低目标，直到降到一个自己有把握的目标。你想想，这样对团队的发展和对业务的发展，都是非常不利的。

2、行动计划的合理性

行动计划必须合理，你要花最多的时间在讨论行动计划上。

资源匹配要合理，如果你没有给我那么多的预算，我拿不到那么多的市场费用和流量，你也没有足够的研发团队，那你让我在一个月之内干出那么多系统，我做不到。所以行动计划的拆解必须是合理的。

下面举一个例子，快狗打车在做Q2的容器化项目来提升的自动化程度时有一个负责人，负责人是我们这边运维的总监，目标是Q2整个测试环境容器化全覆盖。

他就解释给团队听：

为什么要做这件事情，你要提高效率，跟我们的职责相关；
时间节点是一个季度，我们要达成测试环境的覆盖，他就进行拆解，总共有200个集群，第一个月要覆盖80个，第一个星期要覆盖哪10个集群完成容器化；
每一块工作继续拆细，研发和运维团队要负责哪部分；
在季度初，他就做了一个计划管理，然后在每个月执行的过程中，以月为单位进行review。上个月我计划完成三分之一，那我有没有80个集群测试环境的三分之一Docker容器化覆盖？如果项目delay了，我要发现为什么项目delay了；如果有一块技术方案我们想得简单了，那有什么解决方案？如果我们后续的行动计划可能要改变，我们就得加进人手，让大家更重视或者晚上加一个小时班，这样去不断地调整自己的行动计划，不断复盘之前哪一块工作做得好，做对的要继续做，做错的要停止做，迭代优化要继续改进。

总结

1、 对管理者最基本的要求，是对目标的承诺

你能够承诺多大的目标，你的岗位就有多大的价值。

大家想一想，你能跟你的老板举手说我愿意背什么样的指标。你这句话承诺的指标，项目、系统、团队或者业务的一个指标，你都会发现跟你的岗位有关。你的职位越高你承诺的指标和负责的范围会越大。

2、 计划管理是一切管理的基础，计划管理也是目标达成的一个工具

基础管理非常重要的几项：

计划管理解决的是目标及目标达成工具的问题；
流程管理要确定核心的业务流程。产研侧的话就是项目流程，确定实现过程中的岗位、解决事事有人做，人人有事做的问题。大家可以去看看，你们的团队是不是缺某些岗位，观察有没有PMO岗等等；
组织管理确定权责的关系，解决负责的人必须有权，有权的人必须为结果负责的问题。

流程管理，一旦流程确定岗位确定之后，我们在日常管理的过程中，再改流程的概率就会变小，你花在这个上面的比重也会小。组织管理也是一样的，一旦权责明确，组织架构明确。其实你调整的频率也是很小的，

所以基本上作为一个管理者，不管你是做项目管理还是团队管理，无论你是做业务项目还是技术项目，绝大部分的工作都应该花在计划管理上。

设定目标、设定行动计划、追踪行动计划，做好了计划管理就能做一个80分的管理者。

3、 计划管理，非常适合关注过程和效能的“非绩效部门”

研发团队是典型的为交付、产品负责的“非绩效部门”。部门的职责是高效、高质、低成本、安全性地进行交付，这样的部门非常适合计划管理。所以理论上，这种部门的管理者绝大部分做计划管理都是定目标、做行动计划、review和达成。

4、 计划管理是一个过程管理

过程管理对销售部门来说更多的是KPI导向，要完成多少的销售业绩，每个大区有每个大区的玩法，每个城市经理有每个城市经理的玩法，每个团队的执行过程都是不一样的。如果通过拍胸脯的方式，这样的团队review的频率或者是绩效考核频率可能会比较高，会以周或者月为单位。

5、 计划管理五要素：他问我为何（TWWWH）

目标（T）；
为什么（W）：这是Leader在管理的过程中很容易忽略的和下属和团队成员进行沟通的问题。Leader的职责是上传下达，很多时候你只是告诉他们业务目标是这个，项目交付时间是这个，但你没有告诉他，他为什么要做这个业务和项目，这样可能会引发团队成员的归属感或者疑虑。当他不认同这件事情的时候，他可能就会成为达成目标的一个反推力，所以这个部分非常重要；
时间节点（W）： SMART法则，要有时间概念；
责任人（W）：责任人很重要。负责的人要有权，有权的人要负责，你有没有授予他协调资源和完成目标的权力也很重要；
怎么做（H）：为什么很多团队的目标无法达成，可能是在制定目标的时候只提到这个季度要提升50%，但是没有提及怎么提升50%。如果就这样做了再说吧，那到了季度末的时候整个管理是会是失控的，整个项目和业务达成也是失控的。整个过程的初期中最核心要讨论的就是怎么达成，而不是你的目标到底是10%还是15%。

6、 计划管理中，核心要讨论怎么做

7、 计划管理两大特点：

目标的不合理性：不要花太多时间在讨论目标上，定一个50%概率能达成的、跳一跳就能够达成的目标是最合适的；
行动计划的合理性：行动计划和资源匹配必须是合理的，不能是不切实际的。

团队管得好不好，可以看大家有没有养成“计划管理”的习惯！ 如果你做的不好，大概率是季度初制定了目标，但不做行动计划、不做review复盘，季度末达成还是不达成，就全靠天。所以我也要求我的团队在各块工作都需要做计划管理，初期讨论行动计划，review整个过程，而不是找借口和做推脱，并且季度末也会根据他工作的难度系数给予他应得的东西。

作者介绍：

沈剑，快狗打车CTO

到家集团技术委员会主席，互联网架构技术专家；
曾任百度高级工程师，58同城技术委员会主席、高级架构师、技术学院优秀讲师。

原文链接：

58沈剑：如何利用计划管理提升团队效率和产能

创作场景

58 沈剑：如何利用计划管理提升团队效率和产能