领导预设的deadline明显不合理，如何有效应对？

本文由本公众号专栏“B端产品经理的工作笔记”的特约作者：东瓶西镜同学 撰写。他作为产品总监，从供应链金融的工作实战来分享B端产品的工作经验，来分享相关的文章。欢迎关注公众号：李宽wideplum，持续关注独家文章更新。

作者说：

迄今所有人生都大写着失败，

但不妨碍我继续向前！

上周一评审通过了我的产品架构设计，我根据需求内容评估了完整的产品设计周期，大概需要在2-3个月，也邀请开发进行了高层级的评估，反馈的开发时间预计需要4-5个月。

公司领导也熟悉金融产品的工作，结合人员现状，认为这个时间也是合理的，原本已经计划按照这个时间在工作了，我也开始着手进行详细需求的设计了。

但领导周三去集团开会，回来反馈说：老板认为时间紧，为了适应市场，要求必须在3个月内完成上线。

于是我们赶紧开会讨论：据时间倒推，产品设计需要在1个月内完成，交付技术团队开发。

相信很多产品同学都会遇到这种问题，本来合理的产品设计时间，突然来了一个外部因素，强迫缩短产品设计时间，倒逼进行工作，我咨询了很多朋友，也在微信群做了个调查，发现这其实是一个非常常见的现象，本文就讨论分析下这个现象，并且结合我了解到的经验，分享一些应对方法。

1、什么算是不合理的deadline项目？有哪些特征？

2、常见原因是什么？

3、带来的影响后果有哪些？

4、如何有效应对？

01 定义与特征

很多人都听说过deadline是第一生产力，也有调查显示，越来越多的职场人认可这个观点。

众所周知，项目有明确的开始日期和结束日期，那么分解成工作包，其中产品设计也会被要求制定相应的完成日期，这个最后期限就是截止日期，也就是我们常说的deadline。

从这个角度来说，每个工作包的节点完成日期、关键里程碑完成日期，汇总并组成了项目的进度管理规划。

有了合理的进度管理规划，加上有效的过程管理，才能保障项目的高效完成。

怎么保障合理的进度规划呢，最重要也最常用的，就是专业岗位的评估，比如，产品设计的时间一般由产品经理评估，产品总监审核，依据的是需求内容、标准要求、设计流程及输出成果等。

我们在进行预算规划时，对结果评估的依据时，超出预算或者低于预算一定范围时，都属于预算不合理；关于deadline的合理性，我的观点与此类似：也就是说，合理的deadline一定是基于客观现实的规划，无端延迟属于不合理，强迫超前也属于不合理。

与之相对应的特征表现也有两种，一种是1个月可以完成工作，推迟到2个月，这种情况一般是由于对工作要求的理解不一致，比如员工可能要做到精致，深度更深，而领导对详细的工作认识不足或者要求没那么高，由于这个认识的偏差，导致周期拉长，当然，也不排除岗位人员留的摸鱼时间过长，但我很少遇到过这种情况。

另一种就是强迫超前完成，典型特征可以举例来说，3个月的工作要求1个月完成，领导也知道正常也需要三个月，没有认知分歧，但受制于内外部因素，必须要提前完成，这也是本文重点要讨论的。

02 常见原因

导致工作中出现这种情况的原因，可以分为内部因素和外部因素。

内部因素通常是协作表达与理解的不一致。

还拿产品经理来说，产品经理从自身岗位要求出发，一般会按照完整的需求设计流程进行工作，包括需求的调研，竞品分析，产品架构的设计，逻辑功能图、业务流程图的绘制，需求文档的编写，需求评审，需求变更的处理，与开发的沟通解决等。

这些一系列的工作比较完整，合乎逻辑也符合流程，相对比较细致，但是上级领导的了解一般不会这么透彻，可能更多的是关注于业务实现逻辑，至于Axure是低保真或者高保真，其实并不关心，但产品经理可能想把原型设计的完美一些，把交互逻辑都有所体现，需求文档也想写的更加规范一些，这样更加方便开发理解需求，提高评审和开发效率。

但是呢，领导并清楚，想不到这么细节，那就会觉得可能是我们效率的原因，可能就会在自己的个人认知里，认为这一块产品设计工作用不了这么长时间，这便是理解上的偏差。

外部因素通常来源于高优先级带来的主动或被动的强迫。

比如说，产品设计要服务于业务场景，单个的产品要服从于产品线的发展，要遵从整个公司业务的战略规划，而市场变动比较大，经常为了快速适应市场的变化，尽快推出产品来为业务争夺时间差，又或者是，上线的产品突然由于政策限制或者其他问题，导致运营效益严重下滑，急需现有需求上线弥补，都会对原有的时间规划造成很大的冲击，从而被动的前置deadline。

03 影响后果

当deadline被强制压缩后，会带来诸多负面影响与不利后果，典型的如下列三种。

首先，容易导致工作节奏错乱，问题频出。

现在基本每个人都背负着KPI，而KPI最重要的指标就是按时保质保量的完成工作任务。其中质量和工作饱和度都有主观上的弹性空间，而工作完成时间则是一个最重要的可以量化的参数，相对来说是客观体现的。那么当deadline被强制压缩后，打工人的第一反应就是抓紧往前去，往前赶进度。

那这样的话就会。很容易导致工作节奏出现错乱，也容易产生一些问题。举个例子来说，我上一周在听到Deadline缩水一半后，开始也明显着急了，你想啊，3个月的工作，要求一个半月完成，越有责任心岂不越心急。当时让我写的《产品调研分析报告》就出现了很多问题。比如说逻辑不清晰，定位不明确，内容不合理，行文不规范等等。甚至存在很明显的错别字。那这样的话，文档质量就有明显的下降。

事后我分析，分配的编制时间太少是最主要的原因，原本需要一天的工作，2个小时强迫交工，不出问题才怪呢。

其次，容易产生大量的沟通成本。

当截止时间被强制提前之后，很多工作就很难做的十分细致。比如说？原型设计可能就会减少很多交互逻辑。需求文档描述可能也不会特别的详细，业务逻辑图怎么简单怎么来吧，领导没有强制要求，但对开发有帮助并且原本计划写的文档、画的图，也都先省省吧。需求评审也不能浪费大量时间，业务背景就不讲解那么细了，等等。

这些前期省去的工作，都会导致后期沟通成本的增加，而且有些工作原本就需要需要前置，但若因沟通不到位，造成方向性的，不仅会产生沉没成本，更会耽误开发周期。

此外，会对工作氛围带来一些影响。

当整个的截止时间被强制压缩之后，工作节奏是紧张了起来，但公司的氛围普遍会受到一些影响，带来个人情绪的紧缩直接反映到工作之中。

因为大家工作都很忙，原先可能偶尔聊两句天气，活跃下氛围的话不讲了，甚至也不带薪拉屎了，整个氛围多少会有些死气沉沉和压抑。

那原先可能有时间来赋能他人，帮助别人理解工作的事情，也没时间做了，都在为了自己的工作拼命输出，那其实对于整个团队的效能来讲是不利的，尤其来说，工作氛围是一个企业的文化的重要体现，会深度感染这团队成员，影响着整体的团队建设。

04 怎么解决？

那应该怎么解决呢？我觉得，最终的是，解铃还须系铃人，这里有以下几个经验可供参考。

第一，从落地角度出发，尽力去争取资源。

deadline被提前过多，工作量无法优化的情况下，提出岗位招聘需求，争取资源是其实是最好的解决方式，不要觉得不好意思，要知道产品工作处于流程上游，对开发工作影响很大，没有充足的工作时间或者足够的人员，是很难保证产品质量的，而且，从自身角度来说，压迫性的工作更倾向于工作量输出，很多细节缺少了深度思考的过程，也不利于个人的提升，所以就要向上反馈，比如，我们上周评估工作后，我就明确提出来，再增加一个产品经理，来保证设计质量，也获得了批准，退一步来说，你提出来资源需求，哪怕没得到批准，领导也知道你的工作现状，后续如果有需求问题也方便解释。

第二、优化岗位工作量。

有些公司基于自身现状，未必能增加人员，但还需要到期交付，而且，就算是同意招聘人员，补充资源，那也有个过程，不是说招聘就一定能招聘到合适的，就算招聘来了也得有个熟悉的过程，所以，对于工期压缩明显的工作来说，优化岗位工作量便不可或缺。

优化岗位工作量要优化什么呢？我的经验是“一保一推两舍弃”，“一保”是指要保证核心业务流程能按时交付，不影响业务的市场推广，比如说，我们就围绕这核心业务流程进行需求设计，“一推”是指分步迭代，推迟部分功能上线，比如说，我们原本计划的是采购融资产品，包括对库存的管理设计，那本次就将库存管理这个功能放置在下个版本上线了；“两舍弃”是指，一是要舍弃也就是非核心的功能设计，二是要舍弃体验性的细节需求设计，比如复杂但不必要的交互设计。

只有通过对工作量的优化，让合理的工作量来匹配有限的资源和时间，才能从源头保证质量，当然，这个优化一定要把握尺度，并且要组织评审。

第三、敏捷沟通，工作留痕。

但凡是这样的项目，一定需要敏捷开发，小步快跑，高效沟通，关于敏捷需要指出的是，敏捷开发提倡 MVP（最小可行产品，Minimum Viable Product），先做个简单的或者部分的交付，这样，既容易找到下手点，又因为周期缩短，可以早点儿看到系统的模样，早发现偏差。你看，敏捷的落脚点不是单纯追求做得快，而是快速反馈、快速调整。离开了这两项，敏捷就没有保证质量的方法了。

比如说，原型设计就不要做成高保真了，也没必要设计复杂的交互，需求文档重点写出业务前置条件及功能内容，特别细节的就可以先不写，所有的工作都先围绕着主流程进行，先完成一个版本设计，再逐步优化，时间来的及的话再深度完善。

以我来写这篇文章为例，其实我也是采用的敏捷方法，我先写了一个提纲，然后围绕这个提纲把内容一气呵成，先填充进去，这样初稿就完成了，接着再调整两三次内容，第一个调整可能比较多，后面就是微调，这样做的好处是思路连贯，逻辑不断层，效率也高。

再者，沟通也要敏捷，多采用站立沟通会的方式来传达需求，尽量不要邮件或者群消息文字沟通，有时候三两句话能讲清楚的，就没有必要长篇阔论。

最后就是，工作一定要留痕，要有记录，这个留痕和记录也是敏捷的，比如说，需求有个变更，可能时间不允许写详细的需求变更说明书，但是一定要有变更说明留存，以便后续回查，我以往会设计两个流程，一套是标准流程，标准流程下所有的文档，原型设计等成果都是要求标准的，格式也要规范；另一套是敏捷的，只要保证需求能有效传递，其他的都可省略。

第四、规范流程，保证效率。

根据以往的经验，越是在这种情况下，越容易因为流程问题导致效率低，原因也很简单，一来工作节奏容易乱，二来敏捷以后大家都有工作省略，所以一定用流程来保证敏捷不能成为不规范的借口。

做起来其实也很简单，就是传达规范，责任到人。首先大家要对敏捷的工作流程有个共识，比如说，需求变更可以不再写详细的变更文档，但是要有评审会，或者要有文档记录上传协作平台。

当大家都有共识时，沟通效率就高，产品设计以及开发过程也更加顺畅，这就需要流程规范，制度保证，从而形成底层约束力，而产品设计流程，产品经理最熟悉，要在敏捷的框架下，主动的提出更适合的流程，反馈建议的规范，从而形成产品需求的制度，这样对于产品设计就可以形成有效的保障。

第五、有效的项目管理，加班赶工。

对于这类敏捷开发的项目，最需要有效的项目管理，从项目启动开始，一直到项目规划、项目执行、项目监控和收尾，可以做好全流程的过程管理，并且可以发挥团队的协作性，协调解决各种项目问题，对于产品设计的工作也是极为有利，不仅可以辅助指导，也可以节约大量的沟通时间。

再者来说，做好项目节点管控也十分重要，比如说，要将工作拆解成工作包后，确定关键里程碑，找出负责人，以后重点盯控节点，做好过程管理，来保证效率，只有deadline而没有节点管控时，大概率会成为如下的情况：

所以最好确定一个项目经理来统筹项目的管理工作，可以专职也可以由产品或者开发来兼任。

实际上，做好以上以后，就从流程上，组织规范上，以及管理上扫除了障碍，剩下的关键也就是自身的促进，那确实要通过加班赶工的方式来适应进度的压缩，争取最大限度的完成工作，要发挥主人翁意识，敢于挑战自我，这点，对于我们产品人来说，既不复杂，也不困难。

总的来说，deadline用好了就是第一生产力，用不好就是第一破坏力。

而我们所做的工作，为的就是生产力。

稳住，我们能赢。