计划很丰满，执行很骨感

原谅我用这样的标题来吸引看客们的眼球，实际上，当你读起这片篇文章的时候，可能既不丰满，更谈不上骨感。既然手贱，点进来了，不防多看两眼。

前阵子，新来的项目经理很无助的跟我说，测试抱怨项目计划总跟实际的提测功能对不上，总是变来变去的，好混乱，导致他无法安排测试人员的工作，比如说他计划让测试员A这周跟进某个功能的测试，测试员B这周没有他负责的测试需求，可以临时安排他到其他项目中去，结果，实际提测的时候，发现测试员A没工作可做，需要测试员B上。好吧，我完全可以理解这位测试负责人的苦衷，也很同情他的遭遇。在我初为项目经理的时候，我也有过这样的苦恼，当然现在应对起这些问题来，也是轻车熟路，但在回答可能的解决这个问题之前，我们不防先聊聊为什么项目计划跟实际的执行总是有各种各样的偏差呢，即使是在你已经做了尽可能周到细致的安排之后，仍然难逃此厄运呢？

需求变更，需求增删改都有可能。不光如此，甚至还有需求讨论不充分，做着做着发现疏漏或者站不住脚的地方，这都是有可能的。互联网产品所面临的海量用户也意味着产品需求的多元化与实效性。不同的用户群有不同的用户诉求，用户今天想要的跟明天风靡的可能大相径庭。无论如何，传统项目管理中强调的范围、成本、进度铁三角在互联网背景下已经完全不适用了，拥抱变化成了项目管理的潜规则，所以在一个为期1～2个月的产品研发周期内，项目经理需要随时面对不期而至的需求变更，以及由此引发的交互设计变更、视觉变更。即使，在没有需求变更的情况下，交互设计和视觉设计的临时调整与变化也是常有的事情，想想看，交互设计因为需要权衡用户操作体验上的得失，视觉设计又得满足大众的审美，设计出来的草图，可能跟做出来的东西在体验上的感受并不那么一致等等一系列因素，都指向一个结果：唯一不变的是变化。

既然如此，你以为只要做好需求变更管理就万事大吉了，我可以确定且非常确定的告诉你，还没有！其实执行环节也并不如大家所想的那么顺利。首先，在项目初期，不管是哪个角色，大家的工作量评估往往不可靠，在不可靠的前提下，你期望得到一个可靠的结果，这种概率大概类似于瞎猫碰到死耗子，要么是运气好，要么就是你做的事情完全没有挑战性，所以才能准确无误的评估出工作量，要不然呢？然而，实际情况呢，就拿开发工作来说，这本身他是一项既具有艺术性，同时又兼具创造性的活动，不但要完成需求所要求的功能，还要有高效的性能、灵活的可扩展性，甚至是健壮性、安全性等等。所谓远看是山，近看才发现山上还有树，也正因为如此，很多时候，很多事情，都是在项目的实施阶段才发现，原来要这样。从这个角度来讲，项目管理看起来是要解决确定性的问题，但实际上需要处理的是不确定的现实或未来。

在继续讲之前，我们先谈谈食物链，大家都知道在生物上，食物链是用来描述各种生物间的一种吃与被吃的一种关系，每个生物要想生存，他一定要跟周围的其他生物建立起一个生态系统，不可能孤立存在，他有可能是这个生态圈里的生产者（被吃），也有可能是消费者（吃），也有可能即是生产者又是消费者。一个成功的互联网产品一定离不开产品、设计、开发、测试，他们之间更不可能孤立的存在，一定会有着千丝万缕的联系，比如，我所处的项目环境中，客户端开发就是最大的消费者，他们的工作很时候要依赖设计师提供的视觉稿、依赖产品需求文档、依赖后台同学提供的cgi、还可能依赖web前端开发提供的内嵌页面、甚至是客户端开发同学之间的工作彼此之间也有着关联，任何一个环节没跟上，很可能会对开发的实际工期或者工作的先后顺序安排造成影响，从而导致处于“食物链顶端”的测试工作档期安排不协调，有的时候饿着，有的时候吃饱撑着，进而影响整个生态系统（项目）的高效运作，从而大大增加项目延期的风险。

前面说的两条，其实到直接或间接的提到了风险，那我们就顺着这个茬儿继续说下去。风险的发生也是导致项目计划与实际不符的一个重要因素，为什么会发生风险呢？说到底还是因为各种不确定因素的存在所导致的，尤其是在项目初期，不确定性也最突出，随着项目的推进，不确定性逐渐收敛，下面这张图充分说明了不确定性和项目时间的关系。对于风险的预测、识别还有应对，很大程度上，取决于经验，比如对这个行业的了解程度、对所服务产品的了解程度、以及硬件的了解程度等等，即便你是个经验丰富的老手，我敢保证，你也很难做到滴水不漏，用一句话来形容最恰当不过了：“天知道下一秒会发生什么”。

还有一个很重要，但是往往会被大家忽略的原因：你的项目目标不单单是完成产品的需求列表，它还包含着更多的期望，以及为了满足这些期望所需要付出的额外的努力！听起来有点儿疑惑，不是吗？别着急，我会慢慢帮你回忆直到你相信。举个例子：版本的需求列表确定了，要完成从编号1到700的需求。然后一，开发总监表示这个版本，要把产品性能提升到一个新的台阶，启动速度要做到业界第一，下载速度要够快，播放要够流畅，不能有二次缓冲，页面加载不能卡，搜索结果响应要够快。然后二，测试人员表示，为了测试这个功能，需要提供一个模拟器；测试那个功能又要一个编辑器；测试XO个功能要个拦截器；如果说，前面两个然后是开发被虐的典范，那么然后三，就是开发自虐的标杆。为了保证自测的可靠性，开发说，我还得做个校验器！【别不相信，还真有这事儿，当我还是代码搬运工的时候，我就做过这样的事情，这件事的背景是要做一款棋牌游戏，我当时负责的是后台，为了效率，我放弃了使用字节进行存储和比对，所有的数据转为二进制来存储以及进行规则比对，只有在不得已的情况下，才转回字节来处理，虽然高效，但是出错的风险也是很大的，要知道，游戏后台逻辑一旦出bug了，那直接影响的是游戏的输赢和玩家口袋里的软妹币，会遭投诉的，好不！所以，为了验证算法的正确性，又用效率低但相对保险的算法开发了一套算法做双向校验。】还没完，然后四，老板说，界面还得够漂亮！漂亮，你懂吗？意味着你的团队很可能要做很多套备选方案供老板选择，给用户CE，一旦哪里不对头了，还得继续改，你真的懂吗？然后的然后，这么多需求里，没准儿还有需求背后的隐藏需求等你发掘勘探。说到这儿，我相信聪明的你，一定会领悟到：哦，怪不得大家都要加班，哦，怪不得即使大家没日没夜的加班，还是赶不上进度。其实，你赶不上的何止是进度，还有大大的期望。这该是多么痛的领悟呀。

说了这么多，你意思就是计划不靠谱吗，那干脆就别做计划了嘛，省的麻烦。那当然不是，现在轮到项目经理进入自虐模式，即使项目计划会因为如前面所述的各种原因而不靠谱，但计划还是得做，原因有三：第一，明确需求目标，统一行动。如果说，没有计划的时候，看山不是山，那自从有了计划之后，至少看山就是山。第二，明确时间目标，加紧行动。研究表明，人在有时间计划的情况下做事，和在无时间计划的情况下做事的状态是不一样的，有时间计划的人，对时间的利用率更高，产出更高，很多成功人士，都表示，他们并不是天资颖悟，只是更懂得利用时间。第三，有助于提前发现风险，防患于未然。借助于工作分解，会发现项目的关键路径在哪里，核心任务在哪里，人员安排是否存在冲突，人员是否短缺，时间资源是否够用等等，从而可以提前进行决策和应对。

好吧，现在回到文章最开始的问题上来，当计划和实际不符时，该怎么办？第一，有句话叫做，尽信书不如无书，用到这里来就是，尽信计划不如没有计划。计划不是死的，不是拿来当教科书的，因此，首先要在心理上接受这个冲突，所以，当测试来跟你抱怨的时候，你完全可以理直气壮的告诉他，是呀，是会不一样呀，难道你今天才发现呀，哈哈，我是不是很坏，当然只是半句玩笑话啦。第二，既然承认计划会变，那就要定期Review你的计划。Review的目的是通过定期的检查去发现问题，然后最大程度上去协调、去面对问题，以期达到解决或者缓解问题的目的。Review的周期大家根据需要定，前期会以周为单位进行，回顾上一周期的工作，以及安排确认下一周的具体工作；后期，随着项目的确定性增强，不确定性随之减弱，很多事情，没有多说回旋的余地，此时更适合以天为单位进行工作Review。第三，建立健全的沟通机制。Review后，一旦发生变化，一定要让相干人及时了解到变化，以及变化可能带来的影响，好安排下一步的工作。