2.4红宝书编写法则
据说喜欢看机器猫的人，在一定程度上都有自闭迹象，我不肯定我是否有自闭迹象，不过我很喜欢看机器猫，有空的时候会在家里和我上幼儿园的侄儿一起津津有味的看机器猫一个上午。我们共同的愿望就是——有朝一日能有一只像哆啦A梦那样的猫儿，或者，有一个哆啦A梦的口袋。
之所以会想到这一点，是因为在中层管理干部培训的问题上，我也曾经有过这样的设想。
有一段时间，不知道是不是人品爆发，公司不停地接项目，速度是以前的两三倍，有项目做当然是好事，代表有钱赚，但是HR部门就太痛苦了，因为业务增长太快，超过估算，导致人力跟不上，招聘的压力很大，实在招不到人的时候，就从公司内部把很多不够能级做项目经理的人，也委派去做了项目经理，结果项目出了很多问题，每个周末的例会，几乎都是项目部的专场批斗会或救火会。持续了一段时间之后，项目部的总监实在受不了了，跑来找我说：“DK，我不管你用什么方法，这个问题你得替我解决了。现在项目经理团队里有四五个，真的不行，折腾死人了，你想想有什么招儿，能把他们提上去，如果提不上去，我要换掉他们，提高项目经理待遇，从外边招人进来。”
作为权宜之计，将能级不够的项目管理人员提来做项目经理，做这件事的时候，我已经想到项目总监迟早会找我PK，保险起见，每提一个这样的人，我都会先集合项目总监、顾问部、总经办讨论，如实描述情况，让大家先一筹莫展的讨论一阵子，然后再心不甘情不愿的签字画押，这样至少后期问题暴露出来时，管理层不会将矛头齐齐的指向我，不过，我也知道，即便大家都签字画押了，最终出来善后、解决问题的那个人，也会是我就对了。
只是这个问题要如何解决，我自己心里也没有数，所以就一直拖着，等到项目总监抓狂来找我PK的时候，这个问题势必是不能再拖下去了。
这个问题要如何解决？
我最初的想法是，看能不能为项目经理做一本工作指南，把日常管理中会遇到的各种问题、针对问题的解决办法，都一五一十的写进指南里，项目经理遇到问题，就去翻这本书找解决方案，这本工作指南可以说是项目经理的哆啦A梦，或者哆啦A梦的口袋，或者，项目管理的红宝书。只要指南本身做得具有可操作性，项目经理遇事就不会慌，没吃过猪肉，至少看过猪走路，比着解决方案依葫芦画瓢，多少还是可以解决问题的。
但是项目总监跟我呜咽：“你知道项目管理有多少事情吗？二三十件不足以形容，三五十件完全可能，六七十件也并非天方夜谭，这和项目大小还有复杂程度都有关系，所以你讲的那个东西好是好，但是一年半载之内，是不要指望做出来的，远水不解近渴，你还是赶紧给我找一个立竿见影的解决方案比较实在。”
我只得将那个机器猫的小口袋重新按回内心的小角落，说：“任何解决问题的办法，都要比着实际情况出发，我先去了解一下实际情况再说。”
我让项目总监把他非常头痛的那5个项目经理逐个的叫回来，和我恳谈，收集情况。
这趟恳谈前后花了差不多一星期的时间，它不仅帮我看到了几个项目经理在岗位胜任上存在的不足，还让我认识到一个问题：这些不够级别但是被强行提拔起来的项目经理，他们内心实际上也非常痛苦（这是我没有想到的）、不安、惶恐、纠结、怕客户找、怕领导找、怕项目组成员说三道四，怕工作做不好，而越是怕，事情就越是做不好，越是被领导客户骂，越是在项目组内部没有威信。其中一个女生甚至对我说：“DK，我求你了，你把我换回去吧，做客服都行啊，我干这个项目经理，十天好像老了三个月。”
后来我和一位同行说起这件事，她表示非常的惊讶，说在她公司这种情况基本不存在，经理以上的管理人员，不管成绩怎么样，只要是和HR的人谈话，都铁齿的不得了，不管你说什么他都一口应承，批评也好赞美也好，照单全收，像这样主动说自己不行的，还很少见。
我想这可能和公司背景有关系，我们招聘的人员多数都是应届学生，毕业即在公司工作，年龄不大，又是理科生，为人处事上，没有那么圆润，心里承受力也会差一些，会更直接，也更忠于内心感受一些吧，觉得自己不行，主动退让的几率相对也会更高。
我把信息收集回来之后，找项目总监讨论，提供两个解决办法。
一个办法是做工作分解。
我们的项目管理，从大的方向来说，可以分为两大部分：技术管理，主要是各类项目实施方案、实施计划等的编写和制定；项目管理，包括项目人员分工，进度控制，质量把控，和客方的沟通和交流，项目汇报等。
技术层面的工作总体来说是比较简单的，一则是因为各类方案和计划都有现成的模板可以套用，二则是因为所有的项目经理都有很扎实的技术背景，也跟过一些项目实施工作，知道如何制定项目计划，缺的是实践。难的是项目管理工作，要做好项目管理，除了专业知识，还需要有一定的经验积累，简单说就是要有历练。我们公司有个特点，就是员工职业发展轨迹很清晰，道路很深远，因为整个管理层缺乏天才型领导，都是稳打稳扎一步一步从底层做起来的，因此历练（它的另一个词语就是工作时间）在员工的成长过程中就占据了很重要的分量。在公司工作很长时间的人不见得都能做管理干部，但是管理干部多数都是在公司工作很长时间的人，或者至少在他所从事的领域有相当丰富的经验。在这种管理文化下，工作两三年的员工，确实不太能有机会发展自己的管理能力。这种管理文化在公司稳步发展时不会暴露缺陷，一旦公司进入高速发展期，或者像现在这样，间歇性的人品爆发期，出现人力缺口，管理文化的缺陷就会完全暴露出来。
实际上，这5个让项目总监抓狂的项目经理，在各项掉链子的工作当中，做得最薄弱也最差的，正是在项目管理环节，不懂得如何应对客户，不善于把控项目进度，总是拖延工期，团队内部也有很多抱怨（因为拖延工期团队就没有奖金了）。
针对这种情况，我能想到的一个解决办法就是做工作分解。实行项目搭配的方式，将项目管理工作中最棘手的部分全部分解出来，由项目总监统一跟进，不要求他把具体事务做完，只要求他指导项目经理把项目推进下去。这个做法的本质，实际上是变相的让项目总监成为5个项目的实际控制人（因为对项目来说，技术层面的工作其实并不多，管理层面的工作是大部分），5个项目经理则成了项目助理类的角色。
作为项目的实际控制人，项目总监要从微观上去把控项目进度，这对他的时间管理术是极大的考验，如果平衡的不好，可能5个项目都会搞砸，但是，另外一方面，项目总监是我们整个项目部最优秀的项目经理，他在项目管理领域已经有8年多的经历，我相信，这5个不合格的项目经理跟着他走完各自负责的项目全程，管理能力会提升很多，这样一来，人力缺口就小了很多。而且，项目总监现在有一个助理，可以帮助他分担不少工作，至于薪酬方面的考虑，我会说服老板将项目奖金分一部分给总监。
但是项目总监一听这个解决方案，就将头摇成了拨浪鼓，说：“DK，你除非再给我生出个三头六臂来，不然这活儿我肯定做不完，自今年以来，项目部扩充的人数已经变成去年的一倍，部门的事我都还没扯明白，实在没时间带项目。”
我说：“总监，这件事一本万利一举多得，你再考虑下。我知道你时间紧张，但是只要熬过这一段，你就多了5个项目经理人选啊，而且LJ（他的助理）也可以帮你分摊一些工作，没有你想的那么难的，为革命捐躯尚且前仆后继，何况是区区5个项目乎？”
总监给我说得笑了出来，说：“不是我不考虑，我的时间有限，但是这个还不是主要问题，你也要考虑我的能力，这几个项目做的系统我都不熟，要我去跟，初期估计还不如他们呢。而等我把项目弄熟了，差不多也该收尾了，咱不费那力气，你还有其他招儿没有。实在没有了，我找老板商量，让他开个高价出来，去外头找两个熟手。”
我说：“老板肯定是同意去外头找熟手的，但是同不同意开高价，就要打个问号。不过我还有一个办法，就是做Q&A。”
Q&A即是question And Answer，问答集，我非常小心的避开了红宝书、机器猫、工作指南之类容易让项目总监爆青筋的字眼，说：“我们将项目管理会遇到的各类问题，挑主要的、出现频率高的，整理出来，做成一本Q&A（或者说是问题集锦），存放到公司内部网上，让几个项目经理自己去下载，人手一份，熟读，遇到问题就去手册里找，找不到现成答案的就把问题反馈到项目部，由项目总监回答了，项目文员整理出来，传递给他们，同时更新到工作手册里。每两个周末，你根据Q&A的内容抽查他们一次，或者组织一次培训和考试，考试结果记入他们月度考核记录，督促他们去学习。”
项目总监欢喜的说：“这个方法虽然慢一点，但是明显靠谱很多。”
我说：“我不肯定这个方法能够立竿见影的解决5个不合格项目经理的任职度问题哦。”
项目总监说：“我知道，好歹给我一点盼头，让我能够坚持到黎明。”
方法定下来之后，剩下的问题就简单了，我做了一个工作手册的模板，拿去给项目部的文员，又把之前和5个项目经理恳谈的记录整理了一下，把他们反应出来的问题做成清单，让项目总监另外再补充了一些，形成首轮的问题清单，为了节约时间，我们将项目部和开发部的管理人员都集中起来，根据各自的特长（擅长项目协调的、擅长管理沟通的、擅长写方案的、擅长控制项目进度的等等），将问题分摊给个人，要求他们写一份详细的、实用的解决问题指南（要具体到工作细节和流程），把自己的经验之谈倾囊相授。对于这份指南，项目总监给出的合格标准时：要精确到具体的人、事、资源调度，要有具体的案例提供，让有一点点技术背景的人，依靠这份指南，就能把项目管理做好。
在分工会上项目总监说：“兄弟们，这是一件功德无量的事情呀，你们不是在写文档，你们是在挽救5个濒危青年的职业命运呀。将来，等你们老了，坐在炉火跟前，你的孙儿问你，爷爷，你年轻时候都做了些啥大事情？你不用躲躲闪闪的把小孙儿从左膝盖挪到右膝盖，闪烁其词的说，爷爷我年轻的时候在大毛山上叉牛粪。你可以趾高气昂的说，爷爷我年轻的时候跟着XXX（项目总监的名字），挽救了5个濒危青年的职业命运！”
这件事至此得到了大家的支持，但是理工科生终究少有喜欢写文档的（除非是技术文档），在解决问题领域，他们的实操经验可能很多，但是要他们把过程写出来，却是个考验。所以三天以后，大家交上来的作业，质量也是参差不齐，有的写的很详细，具有很强的可操作性，有的就很笼统大概，基本上不可用，我于是抽调了部门的培训专员和人事专员，加上项目部的文员一起，配合提交的问题文档，帮助他们重新梳理过程，整理文档，画流程图。
等这些问题的答案都收集到了以后，项目部将之编辑成册，命名为项目经理实务手册1.0版本，这个1.0版本编排看起来很粗糙，但是因为内容专业又很实用，加上很多案例，可读性很强，不仅项目部的人很关注，连其他部门的人也都下载来看。
而作为我组织制定此份手册的主要针对目标，那5位能级不够的项目经理，他们阅读了这份手册之后，又提供了更多的问题，并且开始主动询问我工作手册中有关案例提供人都是谁。
我发现这一点之后，在第二轮的问答活动当中，就要求所有回答问题的人在文档末尾署上自己的名字和分机号码，便于联系。
这对那些被项目总监抓丁来写工作指南的人产生了巨大的激励作用。人就是这样：当你必须要为别人的工作负责时，你心里是会非常抗拒的，但是当别人抱着求教的态度来请你指导工作，你会欣然接受。
再后来，项目部索性在部门的子网站上开设了一个专门的管理讨论模块，大家将项目管理过程中遇到的各种问题以发帖的形式张贴出来，知道解决方案的人去跟帖说明。项目部文员定期整理这些问答帖，更新到工作手册里。
为了保证这种持久的发帖热情和跟帖热情，我们设计了一项奖励制度，只要问答被收集到工作手册内，提问的人和回答的人，都将得到一定金额的奖励（当然金额有差别就是了），这种奖励和被收集的问题数量成正相关关系，被收集的问题越多，获得的奖励越高。
这之后，项目部管理仍然还是存在很多问题，成长型的企业会遭遇到的各种挑战，我们都在一一经历着，项目总监也还是时不时找我PK，不过，以那5名项目经理为主题的沟通，没有再发生就是了。我姑且推测，他们应该是合格的，或者，就算不合格，至少他们的表现是在项目总监还能接受的范围内了吧。
现在，我的机器猫，哆啦A梦的口袋还在不断的完善过程中，它的实用性越来越广，问题也不再局限于项目经理范围，而开始向上和向下扩展，它的厚度在不断增加，我猜想，总有一天，我设想的那本能解决一切问题的红宝书，是会变成现实的吧？
在编写工作指南作为岗位指导手册方面，应该很多公司都有尝试过，但不是每个公司都把这个办法用灵了，总体来说，我自己做这件事的心得是：
首先，工作手册本身一定要清晰、翔实、简洁、具有可操作性，能有具体案例参考是最好，结合案例说事，远比只说事要有说服力得多。
其次，手册应该让最熟悉该项工作的人来写，因为流程和步骤的每个细节他们都了如指掌，这些人写出来的东西最具有指导性。
第三，在阅读者和撰写者之间建立一种良性互动关系很重要。工作手册的编写，最重要的不是编写的过程，而是对编写过程的控制，文档性的工作，写的时候是非常枯燥乏味的，在付诸笔端之前，要思考、分析、总结，对不善于做文案工作的人，这是一项苦差事，而很多实务能力强的人，都不善于做文案，所以，作为组织者，对过程的控制和检查——简单地说就是对文档质量的把控——尤为重要，而这一步是决定做出来的工作手册能否产生效益。
最后，也是最重要的，正如罗马不是一天建成的一样，撰写工作指南，哪怕是针对一个岗位设计的工作指南，都不是短期时间内能做出来的，我们应该要对岗位工作进行分析，选取那些主要的、出现频率高、且容易出错的工作先写指南，然后再选日常的，最后是不那么重要的但是也会遇到的事情。有先后顺序，分批分拨来做，可以把事情做的更细致，使指南更有参考价值，总之，在编写工作指南这方面，有一句古话说的是非常在理的：贪多嚼不烂。
我记得某一次去听一位管理专家的讲座，当时有人对他提问，说什么样的管理体系才称得上是成熟的。那位管理专家这样说，我不知道什么样的管理体系是成熟的，但是我认为，管理既是艺术也是科学，成熟的管理体系，至少应该具有一个特点，那就是有很强的可操作性，能够批量复制管理人员。
我很赞成这句话，因为我自己是做HR的，把这句话落到工作领域，我将它变成这样一个问题：构建什么样的人力资源管理制度，有助于批量的复制出符合公司需要的人才？
