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