产品设计预设deadline不合理 大家都怎么应对?

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

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

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

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

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

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

产品设计预设deadline不合理 大家都怎么应对?

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

2、常见原因是什么?

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

4、如何有效应对?

01

定义与特征

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

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

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

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

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

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

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

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

产品设计预设deadline不合理 大家都怎么应对?

02

常见原因

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

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

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

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

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

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

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

产品设计预设deadline不合理 大家都怎么应对?

03

影响后果

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

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

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

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

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

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

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

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

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

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

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

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

04

怎么解决?

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

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

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

第二、优化岗位工作量。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

稳住,我们能赢。

随意打赏

提交建议
微信扫一扫,分享给好友吧。