扫码阅读
手机扫码阅读

谁懂啊家人们?我真的没有拖延症

106 2024-03-26



#
产品经理必须知道的99个事



第9期:我真的没有拖延症

程序员经常加班加点的主要原因是什么?或许我们可以从一个熟悉的对话场景中找到答案:总监:「能不能加快需求分析的速度?你们给开发的时间不够用了。」

产品经理:「为了提高质量,我们需要更多时间;为了提高效率,我们必须牺牲质量。我们已经非常努力地工作了,这个需求非常复杂。」这个对话场景大家应该都很熟悉。总监与产品经理在争论中,总监认为未完成工作是产品经理的问题,被催促的产品经理觉得总监不了解实际情况。经过辩论,总监认识到业务方合作不够及时,产品经理也发现了自身不足,如需求迭代传递信息给开发团队。开发团队只想知道为何总是受伤害。

在实际工作中,每个里程碑时间都提前确定。一旦收集完原始需求,产品经理需要对整个系统的需求进行分析。然而,无论是企业内部还是外包公司的项目,上游需求设计延迟交付给开发团队,导致开发工期被严重缩短。


截止时间驱动开发


Business Analysis





截止时间驱动的开发方式在上述情况中是非常常见的,实际上已经成为一种常态。当业务设定一个目标时,通常会同时设定一个截止时间,要求在截止时间之前完成相应的开发任务。

这种开发方式被称为瀑布模式,其目的是确保系统或产品的功能完备和品质可控。在项目的生命周期中,大部分精力都集中在开发和测试阶段,而需求收集和分析只占用很少一部分时间。项目的末尾阶段通过系统集成将项目成功转化为业务价值。

当需求分析占用过多时间时,会威胁到开发和测试阶段,从而影响项目的质量和进度。为确保项目整体质量和进度,我们需要有效管理需求分析的时间和质量标准。如果现有的需求分析方法不足以满足要求,就需要寻求改进的途径。

然而,在实际工作中,大多数产品经理在获取原始需求后,会急于开始梳理功能。尽管他们本意是按计划交付需求,但在实践中会发现业务复杂度远超预期。


为什么需求分析会显得延迟


Business Analysis





确保质量需要充足的时间:

1.业务方回答问题不及时,导致确认细节耗时长。在梳理过程中可能会发现之前遗漏的业务方面,不得不反复修改已梳理的文档,最终匆忙交给开发团队。

2.上游提供资料需要时间。上游提供的资料可能需要制作,负责制作的人员可能需要收集需求信息,如模板和规则。有时还需要复查法律法规相关内容,这可能会影响需求分析的进展。

3.文档书写消耗大量时间。需求文档需要详细描述,要考虑格式一致性、语法准确性和简洁性,还需要进行内容复查,避免错别字等错误。发现不足或错误时需要修改甚至重写,如果没有足够时间,可能会导致需求交付给开发团队时存在粗糙和遗漏的情况。


有没有什么质量效率双赢的


Business Analysis






我们来分别两种不同形式来描述一个需求:

1.用纯文本方式描述一个需求:

当角色是讲师的时候

且当作业的状态是【已通知讲师】的时候

且当这个作业是由这个讲师本人颁布的时候

讲师可以按下【点评作业】按钮

2.用决策矩阵矩阵方式描述一个需求:

显然,将需求以矩阵形式呈现,无论是可读性还是可维护性方面都是质的飞跃。这种方式避免了冗长的文字描述,不仅提升了质量,避免了笔误问题,还节省了开发人员大量的阅读时间。从效率的角度来看,也会有显著的提升。

因此,需求交付延迟可能并不是产品经理的拖延症,而是我们长期以来固有的工作方式所导致的结果。我们需要改变这种习惯性的工作方式,采用更高效、可读性更好的方法来交付需求。这样不仅可以提高工作效率,还能提升整个团队的质量和协作效果。

原文链接: http://mp.weixin.qq.com/s?__biz=Mzk0MzM2OTQzOA==&mid=2247485583&idx=1&sn=ce9a723cb6741c3385b5bdc908193595&chksm=c335b53ef4423c282932dbb21180f8b4678eccd9f43d071d166715b07460498844e84ef27fa3#rd