45-任务变更很随意，应该怎么解决？
前面已经对 “做好，而不是做完” 的问题进行了分析并提供了解决方案。 现在，我们来分析和总结 “项目月末统计及时完成率，出现人人达标的情况” 这一问题，希望能梳理出有价值的见解。 那就从源头开始，最开始，我们计划通过 “任务及时达成率” 来反映项目成员的工作情况，期望从中能发现一些问题并起到督促的作用。 打算通过一定的约束力、紧迫感，促使大家及时完成手头上的工作，为此制定的规则是： 每个月未及时达标的任务不可超过 2 条，超过则需赞助部门经费 50 元。 项目总负责人也不例外，同样需要赞助 50 元。 之所以这样设计，是因为能让项目总负责人与项目成员站在同一战线上，有助于避免形成对立，降低工作开展的阻力。 然而，历经一年有余，除了最开始有一两个项目成员未达标并缴纳了赞助费用外，此后很长时间都是人人达标的状态。 这从正态分布上来说，就显得不切实际。因为，很少有人能保证所有任务都及时完成。而且，月月如此。 为什么会出现这种情况呢？后来我分析了一下，原因是，我们对任务变更没有进行有效管控，插入需求的频率过高。为什么插入需求的频率会过高呢？因为项目业务需要根据客户反馈及时调整，第一时间响应客户需求。例如： 突然有客户反馈紧急需求，希望快速响应； 当前线上存在之前疏忽的功能细节，需要及时完善和补充； 有客户询盘并表达合作意向，但对某个功能不太满意，需要及时给出优化方案以推进合作。 这些情况都会破坏之前制定好的项目计划和正在执行的任务。此时，无论是项目总负责人还是项目负责人，往往没有深究是否应该变更，而是默认允许变更。 只要产品、后端、前端、运维等任何一方出现需求问题或任务执行未及时达成，影响后续关联任务，就会出现任务变更的情况。 此时，很多人要么不具备分辨能力，要么贪图省事，不愿花心思去辨别是否真的应该允许变更，而是一概通过变更申请。 要解决这个问题，首先应从减少插入需求入手。但对于研发工作而言，如果完全不允许插入需求和任务变更，就显得过于僵硬和死板。市场在实时变化，响应时间的早晚可能导致截然不同的结果。因此，对于紧急、关键的需求，肯定要及时响应。 然而，如果总是允许插入需求，项目计划就容易失控。久而久之，项目成员会产生一种心态，反正最后都要变更计划，今天做完还是明天做完有什么区别呢？ 这种思想一旦萌生就很难消除，必须从根源上、从制度上解决。 项目负责人要引导项目成员主动思考是否可以通过其他方式解决延期风险，而不是通过变更影响后续任务。例如，可以提高事情优先级、提升工作效率、适当加班等。这样才能以目标为导向，锻炼应对不利情况的能力。 当然，如果插入的需求需要较长的开发周期，自然需要变更任务计划，并同步更新。这一观点我在之前的文章《项目需求变更时如何处理》中也提到过。坦白讲，就是要在 “插入需求” 和 “任务变更” 之间取得一个平衡点。 这实际上，还是回到了项目计划和里程碑的目的。**正如我在之前多篇文章中提到的，项目计划的目的是提供一个方向和时间节点，就像大海中的灯塔，引导大家朝着同一个方向前进。**如果张三往东走，李四往西走，王五往南走，工作就无法有效开展。 其次，项目负责人和项目成员在面对任务变更和各种突发事件时，应该充分发挥自己的智慧，制定有效的策略，就像行军打仗、摆兵布阵一样，明确先做什么、后做什么，如何争取资源，如何与其他成员和上级领导协调沟通，以确保在规定时间内达成目标。 如果某个项目成员反馈任务需要变更（例如前端因为后端接口问题导致任务受阻，申请延长任务时间），项目负责人需要了解事情的前因后果，而不是仅凭这个项目成员的一面之词。这就需要把相关项目成员（如后端）叫来一起沟通，了解问题所在及解决方案，可能出现的情况包括： 后端接口没有问题，只是两人对需求的理解有误，这种情况不需要变更； 后端接口有问题，但前端可以先开发界面，最后一两天再联调，这种情况不一定需要变更； 后端接口真的有问题，但前端对延长时间的理解有误，可能存在故意拉长时间的情况； 后端接口真的有问题，追溯起来是因为对需求的理解不一致，这种情况可以总结经验，下次在需求层面多做分解和沟通； 后端接口真的有问题，前端提出的延长时间合理，符合常规理解，可以同意变更。 可以看到，有些任务只是看起来需要变更，有些任务只是看起来需要延长时间，实际上不一定如此。 归根结底，就是项目负责人在执行上出现了问题，为什么没有做到位呢？换位思考，我在带一个项目，里面有关系好的，关系不好的，关系好的呢，肯定是适当通融，关系不好的呢，不想得罪对方，这是人之常情。 每个人的角色不一样，所掌握的话语权和资源也不尽相同，面对同样的一个人或者一件事，在你看来，很容易处理，但其他人就会觉得很难，不同的立场，面对的阻力就会发生变化。 所以，要为项目负责人的执行背书，从源头梳理，制定《项目管理规章制度》，特别是任务变更的规定，然后，组织项目负责人讨论会议，对这份《项目管理规章制度》里的每一条规定，都反复讨论和敲定，有什么问题，当场提出来，现场就解决对方的顾虑和疑惑，能够达成共识。 只有达成共识，项目负责人执行起来就会从被动变为主动。 然后，再把这个《项目管理规章制度》在部门里发布和告知。 之后，项目负责人在执行的时候，就照着规定行事，不用顾及对方的感受，直接按规矩办事，实事求是，如果对方反应很激烈，那也不用项目负责人去解决，只需要把这种对立情绪向上反馈，由项目总负责人、部门去解决，不用有心理负担。 说到底，就是要给项目负责人做这个事情的正当性，而不是把压力完全由项目负责人承担，从源头贯彻理念，而不是处于模棱两可的状态，规定个12345，有问题解决问题，直到大家都没有异议，那么执行起来，就不会有那么多阻力。 谁没做到位，直接提出来，到底是什么原因，是制度的不完善，还是人的问题，制度不完善，继续完善制度，人的问题，就解决人的问题。 最后，要提的一点是，任务变更固然是一个问题，但这都是基于 “目标如期达成存在很大风险” 这个主要矛盾延伸的，先明白了这一点，再去抓任务变更这个事情，才不会舍本逐末。