这是《落叶》文集里第 185 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
之前有些同学在向我咨询项目管理学习的时候，问我，虽然目标有了，可在制定计划时却感觉无从下手，因为这种偏管理的学习计划，不像执行类任务或工具类任务的计划，有着明确的完成标准或者清晰易衡量的产物，所以他们希望知道如何才能制定符合 SMART 原则的管理类学习计划？
【你问】
如何制定能有效落地的管理类学习计划？
【我答】
不管是团队管理，还是项目管理，都有对应的方法论，肯定都是学习为先，不过，在职场中的工作计划里，学习计划的占比通常都很小，并不是说学习不重要，而是因为多数公司都不会为你的学习和充电的过程买单。
所以，我建议大家最好是有个提前量的学习，至少在你开始制订该类目标计划之前，对该领域的基础知识能有个框架上的认知，最简单的方法就是找一本该领域中的经典入门书籍，快速地浏览一遍，不要求多，至少得像目录一样，知道这个领域大概有哪些东西。
学以致用才是目标计划里的大头，因为上面也说了，公司会为你买单的只会是结果。所以你的学习最终都得落到实处，比如用在了什么地方，产生了多大的改进，带来了多少效益的提升等等。
这类目标结果的检验标准，通常写的都是我管过多少项目，我管的项目是否按时按质完成交付的，有没有出现延期或成本超支等相对泛化的成果，较难体现出你和别人的差异化，也很难体现出你学习的效果和成果。
所以建议大家在罗列这种项目管理类的计划目标时，最好以产物为导向。你们肯定会问，这种管理类的计划，能有什么产物啊，都是一些泛泛的东西。好吧，那我们就接着往下看。
此类目标，一般会有两类产物：一类就是在你的管理实践中形成的流程文档、作业文件、模板、工具等；另一类就是你在学以致用的过程中，自己总结的知识或方法。
第一类产物：其实就是能体现你跟其他管理者差异性的重要项，大家可以试想一下，同样的两个项目管理者，完成了同样的项目数量，都正常按时按质完成了交付，数据也都正常。那如果要在他们俩中间评优，是不是这类产物就可以成为取胜的关键啦？
两个人同样完成了同等难度同等量的工作，其中一个人边做边总结，得出一些可以让其他人使用并保证项目成功的流程或工具，差异立现。
这里建议大家在描述此类产物的期望目标时，多用一些简单、直观、数据化的关键词，比如：提高30%的效率、减少10个人日的成本、节约100,000元的开支等等。
第二类产物：也是现在越来越被看重的一个方面，就是你在整个过程中学习到的很多知识和方法，积累的丰富经验，之前很多人都认为这只是自己的学习成果，怎么能作为工作计划的成果呢？你别忘了，你可以将自己的学习成果分享给其他人啊，在团队内部或团队外部都可以做分享，这种分享，包括课程和课件，都可以成为你计划里可以锦上添花的产物。
上面说的是通用层面的，就是不管是什么领域的管理，基本都可以借鉴或套用的。接下来我们就拿项目管理为例来细说一下。
项目管理，总共分为五大过程域，十大知识领域。如果定的是这个年度学习目标，那怎么去制订计划呢？
如果你总是想着，我怎么才能做出一份可执行的项目管理学习计划，那你就离实现目标又远了一步了。因为项目管理从理论角度上来说都已经分为十大知识领域了，如果落到具体公司的项目管理流程上，又能再细分成不同的过程阶段，如：需求评审、代码设计、测试执行和上线发布等若干个研发过程。一想到这么多过程，这么多领域，头是不是都大了？是不是就更觉得无从下手了？
这里我们应该先了解项目管理全过程大致应该分为几个阶段，每个阶段又对应着那些知识领域，再结合你所在公司的实际项目流程，把整个过程劈成 N 块，先挑出自己能力不足的，或者还不能游刃有余去管理的那几块，再从这几块中挑出今年从公司层面或者个人角度最重要的几块，个人建议不要超过3块。
就这最重要的几块，逐个去分析目前的不足，可提高的地方，针对可提高的地方，列举一下大致的改进思路和想法，举个实际的例子吧。假如你觉得当前项目管理过程中，测试人员因为对需求的理解偏差或错误，会导致一些问题被发现在开发阶段，甚至于发布后，你想针对这点去改进，那怎么计划呢？
需求设计阶段时，需求文档是产物，那需求评审时测试负责人发现的问题数是可以记录下来的，就类似于Bug，当需求评审阶段结束后，再发现有些问题是因为需求评审阶段遗漏掉的，也需要记录，最后看比例，类似于需求发布后缺陷率。
当你试着去用这种方法改进，最后提高了需求评审质量，这种方法是不是可以总结提炼成流程文档和作业文件，对于质量的提升，是不是也可以量化？采取了这种流程的项目，比之前的项目，在需求阶段发现的问题数增加了多少，需求发布后出现的该类问题减少了多少，节约了多少人日，以及后期沟通和补救成本等等。
说了这么多，大家应该可以自己去试试制定一个可以落地的管理类学习计划了吧？
《测试路上你问我答》里的 Q&A 43，如果是你要的，甚好！如果不是，你问，我答！
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
