|
声明一下哈：这是装逼，不是PMP课程，所以只吹我自己的实际经验，不要拿什么理论来套，我这人不跟书呆子说话的。 以下正文： ---------------------------- 所谓任务分解也就是把一个项目的工作细分成具体的任务项，给任务项分配资源和时间，形成书面计划的过程。 形成出来的文档最常见的形式是甘特图，不过不同的企业对它的称呼五花八门，有叫甘特图的，有叫schedule的，我见过的最奇葩的称呼是管它叫：BOM，还不是一家，好几家制造业的大企业都这么叫，他们好像喜欢把一切分解的东西都叫BOM，我也沿用这个称谓吧，越是奇葩的越有逼格嘛。 形式谁都知道，PM都得做这个，不过水平那就是天上地下了。 至少有一半的PM做BOM纯粹是因为要有个BOM交差，所以根本就是胡嘞的，他自己从一开始就没打算按照这个执行，如果甲方没在项目开始时要求他先提交，他甚至会把这个东西拖到最后项目验收时再编一个凑数。从骨子里他们就不认为任何项目是有可能按照计划执行的。 剩下一半的PM虽然是打算定一个可行的计划的，但是做出来的东西看着事无巨细，一执行起来完全控制不住。 任务细分的颗粒度特别重要，到底应该细分到什么程度？ 菜鸟PM订的计划分解得特别细，恨不得细到每天上午干什么，下午干什么，中间几点吃饭，几点拉屎。然而，这样的计划是完全没法严格执行的，稍有一点意外计划就偏离了，很快大家就发现几乎每一件事都不可能按照计划完成，反正偏离是常态，也就无所谓了，于是计划就成了废纸。 我一般会从几个角度控制细分的颗粒度： 一是可度量性，也叫可交付性。一个任务项完成没完成不能仅靠主观判断和口头报告，你不能是只问一句：那个什么什么你干完了吗？程序员跟你说：搞定了，那十有八九会豁边。最好是能有个多边形成的不能抵赖的书面文档，比如一段程序的代码，我会选择以测试报告作为交付物，程序员提交了，测试组通过了，双方签字，这个活算干完。所以，工作计划太细了就有问题了，你不能几点钟去拉屎也签个拉屎报告吧？文档过多，双方都很烦，项目也会陷入繁文缛节，效率低下。 二是应该与你的项目检查周期相匹配。所有的项目都应该有固定的项目检查周期，有的是每天开例会，有的是每周开，甚至还有的每月开。如果连这个都不搞的PM那就该去死了，不过，讲真，根据我的经验，真的有七成以上的项目真的没有这个制度。没这个制度咱就没话讲了，能坚持这个制度的咱们可以继续往下说。 假定你一天开一次例会，而你分解出来的任务项的周期也就半天一天，结果是什么？例会中每一个报告的问题都一定已经逾期了啊！所以，再怎么说任务项也应该有至少三天的周期：头天开会报告说有困难，第二天你安排资源支持，齐心协力努力，第三天把问题克服了，一看，正好把进度追平，计划三天，实际三天达成，帮忙的有成就感，被帮忙的进度赶上包袱卸了也如释重负，完美。 所以，我一般会把颗粒度控制到每个任务项的周期大约在三倍到五倍检查周期之间。太粗了没压力，问题暴露不出来，一出来就是一堆；太细了，一出问题就超期，根本没有补救机会。 三是应该任务明确到人，最好一个任务项只有一个执行者，责任才明确，三五个人负责一件事，看着人多力量大，实际上出了问题互相推责任，谁也不负责。 另外一个问题是任务怎么分？不同的人有不同的办法。 如果你本身是领域专家，那这事儿简单，什么时间该干什么你都门儿清，当然很容易就能把计划定出来。然而万一你不是呢？其实也不难，那就项目组成员一起商量呗，坐在一块儿，一起讨论，先干啥再干啥，计划不就有了吗？ 然而，这个世界真的是很奇葩的，真的是有很多牛逼的销售能把客户忽悠得团团转，拿到一些自己根本就不会做的项目，项目组的一群人都特么不知道该咋干，你别不信，至少有一半以上的项目都是这样的，一群人胡屌乱搞，最后想办法再跟拿单子时候一样，在KTV夜总会里把客户搞定，然后也能顺利验收。 然而，总会有个别油盐不进的客户，甚至还有拔屌无情的，于是这时候就需要有临危受命的救场PM出现来拯救地球了。 救场PM的工作环境险恶程度不是一般人能承受的，经常是两年的项目最后剩一个月了，完成度还不到50%，而客户的信任度已经降到了零，项目团队成员的心态则已经彻底崩坏，一半多的人已经交了辞职报告只是还被公司扣着钱。 我干过三四次这种活，当然，你们碰到这种事不要打我的主意哈，这种事我都是要天价的。技巧我可以跟你们说说，你们自己想办法，实在想不出办法愿意出天价了再来找我。 这种时候千万不能乱，越是危局越不能头痛医头脚痛医脚，你必须在最短的时间内制定出一个可行的拯救计划，并且重新恢复客户和项目成员的信心，这个计划一般是issue based。 第一步是搜集问题，我一般是立即召集项目成员和甲方一起review项目，把所有存在的问题汇总出来，开着投影机，打开excel，他们说一个我记录一项。 第二步是责任到人，每个问题确定一下谁负责，excel加一列，把责任人填在问题后面。 第三步是制定时间计划，在问题表最前面加一行，然后再责任人后面那一列上填上日期数字，剩多少天填多少格，然后把这些列拉窄成方格。挨个人问，你打算先做哪一项？需要多少时间，哪天开始哪天完成，然后把对应的单元格设置成代表他的颜色。 每次我干到这里，客户都瞪大了眼睛说：excel到你手里就好像活了一样。 然后就是每天例会review进度，任务开始了，就在对应的格子里填上S,执行中填X，暂停填P，完成填F，这样背景色就是计划进度，而字母串就是实际进度，完美。 当然，不可能有了计划就能保证项目完成，不过今天的主题是谈任务分解，所以，说到这里可以了。关于具体执行，如果你们爱听的话，我以后接着吹。 然而，其实不管是用那种方式制定的计划，如果只是你的计划，你知道客户知道显然是没用的，你必须跟所有项目成员一起开个会，听听他们的意见，如果有不同意见就商量着调整，其实这个时候可以顺着他们一点，只要最终的定出来的计划能够满足周期要求就行，因为这个会的唯一目的是：让他们买单。 是的，这个时候你需要他们给你一个承诺，承认这个计划是跟他一起定的，他承诺可以完成，这是日后盯他的基础，否则日后他一句：“你的计划是胡定的，狗屁不通，老子根本做不到！”，你咋办？ 今天的内容就差不多了，最后不得不说：项目成员，尤其是年轻人，有低估工时的共性，一般他们说一天能完成的事情，你排三天，基本上他紧赶慢赶正好能赶上。老油子偏差小一些，不过除了销售，我还没碰到高估工时的。 |
|
|
