开发说这个需求实现不了,怎么破?

23,095 阅读6分钟

嗯,这个工作量比想象的要大,短期内实现不了

设计的似乎不太合理,这次还是先不做吧

感觉这个功能没有什么意义,以后再说吧

……

作为一名摸爬打滚N年的PM,与程序员相爱相杀的堪称一本血泪史,天衣无缝的功能常在上线前被开发突然告知实现不了而被迫腰斩,部分功能甚至再三延期,PM们备显无奈。好的方案总是实现不了,真的太难了!挫败感笼罩着整个团队,久而久之,PM的工作状态愈发迷茫,毫无价值和荣誉可言。

为什么开发总说实现不了?

讨论这个问题前,我们先复盘常见的产研工作流程,以便发现问题本质:

图片

  1. 功能规划:PM调研市场需求,收集竞品特性,根据产品特性规划功能,产出原型稿

  2. 界面设计:设计师收到原型稿后,开始进行界面还原,产出高保真UI设计稿

  3. 计划评审:PM召开需求或计划评审,讲解功能及意义并提出验收重点

  4. 前端开发:工程师根据UI界面开发界面,开发完成后,合并代码,提交测试

  5. 测试上线:产品人员、开发人员对照原型稿、设计稿对功能进行测试,记录问题指派开发修复

……

再三推敲,不难发现“这个需求实现不了”的根本原因如下,但大家似乎对这些都习以为常,甚至并不觉得有什么问题:

  1. PM仅关注功能价值,不负责代码,具体难度还是在具体工作中才能准确判断;

  2. PM在开发阶段参与感很少,基本是开发闷头苦干,主动的跟进较为匮乏;

  3. 开发一个新功总会衍生其他BUG,开发还需要充足的时间进行测试和修复。

难度无法评估、产研沟通匮乏、开发时间紧张……,这就是典型的产品管理问题,功能制定、开发追踪、测试上线的各个环节都存在缺陷,仓促上线,产品质量必然一言难尽。

3招破局,保证产品质量

所以,开发说 “这个需求实现不了”,看似是开发任务未完成,实际上是在抱怨产品管理的不合理,PM需要从源头根治问题,才能快速破局、保证产品上线质量。

图片

(一)制定合理的开发计划

合理的开发计划(通常指月度计划),是团队工作的重要指导,制定计划时,以下3个原则一定要切记,看似微不足道,实际上都能在源头上避免很多问题:

1)版本发布次数不宜超过2次

一般来说,月版本发布次数建议为1次,因为每发布一次版本,就需要调动团队内所有人手进行上线准备,包含环境部署、脚本导入、功能自查、测试验证、产品验收、功能文档、教程等繁琐的工作量,来回至少需要折腾1周才能如期上线,剩余1次用于临时修复,如一些重大BUG或策略缺陷的热更新。

2)人均开发时长控制在10-14天

计划中的任务量最终都是落到人头上,缜密的安排尤为重要,这直接决定版本的发布与否,切记宁松不紧,宁愿任务量少一点,也要确保版本能如期上线,若该同事开发的功能将于本月发布,则控制应在10-12天/月较为合理,若本月不发布,则可适当调整为12-14天/月,尽可能杜绝负荷过大导致的版本延迟。

3)协调重大新功能的人手、时间

PM设计的重大新功能,开发预估的时间往往与实际开发时间存在较大的差异,这是因为很多难点只有在开发阶段才能涌现,极其考验开发判断能力和综合实力,PM能做的不多,但我们可以对比竞品重大功能的更新频次,从而优化产品发布节奏,比如难点功能,我们可以安排1个中高级工程师负责,1-2个初级工程师从旁协助,发布时间从当月调整为下月,从源头上根治开发时间、人手不够的问题。

(二)全流程把控开发进度

大多数PM在讲解完计划或功能后,基本处于甩手掌柜的状态,开发阶段的跟进和参与感非常低,而这个阶段开发若遇到功能实现与策略描述不一致,则会优先保证功能,选取最简单的技术手段实现,这就是产品预期与开发结果有较大出入的原因——开发比较无助的阶段,产品缺少主动的沟通和追踪,导致开发凭经验做事,最终的产出和预期相背。

对此,PM不仅需要严格把控设计稿的还原进度,还需要优化团队现有的协作方式,在这里,推荐一款高效的在线协作平台——摹客设计云,产品、设计、开发全流程在线协作,大幅度提升团队的工作效率。

  1. 设计师可上传UI设计稿至协作平台,并添加设计说明,便于团队评审;

  2. 前端工程师可下载所需切片并复用代码,保证界面、功能的还原正确;

  3. PM可依据UI设计稿的还原情况追踪开发进度,补充一定的策略支持。

图片

(三)必要之时的取舍意识

诚然,我们在前期已经做的足够充分,但计划始终赶不上变化,上线期间或多或少会遇到各种突发情况如开发转岗或离职、重点客户的需求需要紧急处理,这就导致部分功能不能如期上线。

此时,PM应调整心态、挺身而出,根据功能的性价比的高低做判断——功能性价比=功能价值/开发时间,优先保证性价比高的功能如期上线,再妥善安排剩余功能,PM并不怕功能晚发,就怕发布的功能不是用户需要的。

图片

“这个需求实现不了”,确实有开发人员本身的问题,但作为一名优秀的PM,单纯的将责任归给开发能力不足不仅解决不了问题,反而会陷入与开发持续冲突的死循环。

我们需要深度挖掘问题的本质并从源头进行根治,方能一劳永逸。

  1. 计划制定时,保证合理的任务量,预留充足的时间进行自测;

  2. 计划执行时,主动追踪开发进度,提供必要测策略支持和测试用例;

  3. 意外出现时,客观判断需求的价值,优先上线市场急需的功能。