如何管理和控制

识别并避免项目范围蠕变

经过 01/10/2018 4月22日,2021年 没有评论
星期一的标志白色的透明背景

2021年球队的PM工具
绝对可定制,非常直观。

我们的朋友和支持者

项目范围蔓延……这句话听起来是阴险的。事情就是这样发生的,突然偷偷摸摸地闯进你和你的项目的痛处。

我们都需要小心处理扩大或改变范围,以避免令人不快的意外。在本文中,我将讨论:

  1. 什么是范围渐变
  2. 它会如何影响你的项目
  3. 当它发生时,如何减轻它

我将深入研究敏捷项目中的范围蠕变的真实世界的例子 - 甚至没有固定的范围开始。同样重要的是,我会谈谈变化范围和手臂的积极方面,并用一种​​合理的方法来拥抱它。因为变化可能很好!

什么是范围蔓延?

那么范围蠕变,究竟是什么?简单地说,它发生在项目上的范围,可交付成果或功能时从最初设置的内容扩展 - 而不在额外的时间或预算中占用。它可能会影响任何固定的范围项目。这是一个非常常见的事情,因为它可以故意和无意中发生,源于任何人参与项目的人。

不幸的是,范围渐变会导致项目失败:也许你没有在截止日期前完成,你耗尽了整个预算(甚至更多),所有这些都没有交付正确的东西。谁想要那样?!

范围渐变是如何破坏项目的?

它发生在我身上吗?是的,充足的次!这是一个快速的范围蠕变案例研究,我的经验说明它发生了程度 - 以及如何从直接客户端请求中出现:

案例研究:我与范围蠕变的经验

我继承了一个带有更经典的瀑布设置的项目:有线框和设计阶段,然后进入开发阶段。我是在它进入开发阶段时捡起来的。这非常简单:我们是在另一家代理公司的白色后端之上构建前端。我们已经签署了线框图和设计,并且已经与客户和代理完成了所有的工作……还有什么可能出错呢?

好!结果是其他该机构正在迭代他们的后端构建,并经常发布新代码。有趣的是,他们并没有考虑到我们是基于旧代码进行构建,所以我们的代码在每次发行时都会崩溃……*深深的叹息*

这意味着我们必须回到我们的代码中,更新它以适应来自其他代理的持续变化。这件事没有被计算在内——但这是我们必须做的工作。一开始,我们做了一些奇怪的、小规模的临时修复,但越来越多的问题开始出现。尽管我们向客户提出了这个问题,但我们试图将额外的工作折叠到我们的项目中,而不是向客户表明我们需要在继续构建之前共同确定一个解决方案。

哦,后智之益!发生了什么?我们更深入地重新开发了现有的代码时间延长,我们错过了我们的截止日期,我们在项目结束时发出了很大的压力。该团队被贬低了,客户不开心,而且这实际上都是我们的错!最后,该项目延迟了两个月,大量时间,未占。最后,我们想要的只是洗手,忘记它发生了。

那么,我们能做什么呢?

涉及的人员:谁真正导致范围蔓延

查看您的项目并确定谁可能导致范围渐变是很有用的。这可以帮助您及早识别并确定解决问题的方法。提示:并不总是客户端导致这些问题,就像你在上面的例子中看到的那样。

团队成员

范围蔓延可能来自于你的内部团队,原因有很多:

1.团队成员不清楚项目的范围是什么。

确保在项目的开始,任何需求或者已经列出了可交付成果,团队中的每个人都充分意识到了这些。如果范围已经确定,确保对话中尽可能多地涉及到将参与项目的团队。如果这是不可能的,至少跑步开会会议与团队一起,确保每个人都充分了解已经达成的协议。然后,在项目期间,确保保持定期的团队签到,让每个人都在同一个页面上。

2.团队成员希望开发什么他们想要发展,而不是什么在范围内。

当人们参与其中——当他们觉得自己拥有它的时候——他们会更理解。让你的团队参与设定范围对于让他们参与设计和构建内容非常有用。确保每个人都像一个团队一样工作。如果有人离开去制作超出范围的东西,因为他们想要因此,项目中的其他人不会投入到正在发生的事情中,这就导致了摩擦和对范围的不同看法。

3.团队成员在真空中做出决定。

有时,团队成员选择一种方法来解决对范围影响的问题,通常没有实现。甚至增加了一半的额外工作要做一些略有不同的东西可能会影响你的其余部分。例如,如果设计师或UX人决定在网站上包括某些功能而不与开发人员讨论,他们知道这可以对您的整体范围做些什么,但没有任何调查?

确保你的团队从项目一开始就开始合作,并理解彼此的决定。当有人直接向你提出疑问或问题时,如果需要做出更大的决定,就告诉所有人。让人们一起工作来定义和找到问题的解决方案。确保每个人都保持联系(无论是面对面的还是远程的)。大多数成功的项目都是由协作良好的团队促成的。

内部利益相关者

你的项目范围可以在组织内部受到高级利益相关者的影响。他们可能对组织有一个愿景,包括为你的项目交付更多的东西,或者他们可能想推动一个不同的议程。例如,有时对一个组织来说,客户关系比保持在你的特定项目范围内更重要。

确保你的内部利益相关者了解你想要交付什么以及何时交付。如果有什么事情会对你的项目产生连锁效应,明确地列出它会产生什么影响——无论是经济上的,基于感知的,还是其他方面的。

用户

用户测试应该(希望如此)成为你的项目或产品设置的一部分。用户对产品的反馈可以影响最终扩大范围的一系列事件。如果你从用户那里得到一些你无法忽视的反馈,会发生什么?即使它可能会增加您的范围,也需要解决它。

当您整理了测试结果后,与您的团队一起检查以确定要实现的必要更改。按优先级排列,这样你就知道哪些更改会对用户体验产生最大的影响。然后,计算出您可以在不影响范围的情况下轻松地合并哪些级别的更改。如果任何必要的改变都意味着扩大范围,那就告诉你的客户或涉众。同样重要的是,确保你了解它的影响实现这个改变将会。

第三方

正如我们在我的个人案例研究中所看到的,来自其他方面的依赖可以影响您的提要。无论是外部公司、第三方api还是内容提供商——如果您依赖外部任何人来完成项目,那么您需要了解他们可能产生的影响。

确保你确定项目依赖项当你启动这个项目时。试着考虑他们在项目上有什么影响,以及它们如何影响您的范围。例如,如果您的内容提供商向您发送的内容以最容易实现或上传网站中最容易实现的格式,那么这可以添加额外的时间吗?显然,您永远不会涵盖每种可能性 - 但是在开始时拥有这种风险规划的思想框架,意味着您可以在项目开头与客户或利益相关者提出这些依赖性,并确保他们理解潜在的影响。

对于项目经理来说,造成范围渐变的最大问题来自于试图在现有的预算和时间线内工作,而不告知客户或涉众的诱惑。是的,当你不得不说你不能做某件事,除非你提出改变的要求时,这可能是一场困难的对话——但这种对话在早期进行要容易得多,而不是在你超时和预算的时候进行。

确保你问题一出现就提出,而不是等待。如果你或你的团队发现了一个问题,通过不同解决方案的可能场景,并将它们呈现给客户或涉众。例如,如果额外的工作是必要的,那么看看哪些工作可以被取消——您在项目中所做的事情是否在第一个版本中是不需要的?

客户端

是的,我们不能不提到一个显而易见的问题:客户。这一点实际上更容易发现,因为大多数pm已经准备好这样做了!要注意客户逐渐增加的小请求,改变他们对已达成的协议的想法,或者建议新的方法来做事情,这些可能会影响所需的工作量。如果他们提出的要求会导致范围蔓延,那么你要确保自己是诚实的。同时,要组织好你的回答,这样你就不会总是说“不”。试着这样表达,你是在建议另一种选择,例如:

“这个新请求将会这个特定的影响时间/预算。我们已经看了优先级,替换怎么样而不是?它获得了类似的结果,因为……”

范围渐变的10个常见原因(以及如何消除它们)

10常见原因范围蠕变infographic1.1.没有清晰的视野

对任何项目来说,清晰都是极其重要的。如果你在一开始就没有明确地定义你的范围,接下来可能会造成很大的问题。

如何消除它:确保每个参与项目的人都清楚这个范围。让你的团队参与设定范围,这样他们就能接受他们所交付的内容。

2.没有客户协议

如果客户不认同这个范围,他们很可能会改变他们的想法——以及随后的交付物。

如何消除它:确保客户理解什么是-and的范围。不要只是发送概述可交付成果的文件 - 与他们交谈并妥善通过它。是透明的:提出问题,“你是清楚的,这是可交付的,你会得到什么?”

3.自始至终不让客户参与

你做一两个月的工作,然后把这段时间的最终结果发给客户征求反馈的日子已经一去不复返了。这导致了意外的结果,最终的工作必须重做,并影响了项目时间和预算。

如何消除它:与客户密切合作。向他们展示正在进行的工作,迭代,并在整个过程中主动让他们参与进来。

4.没有主动提出问题

躲在问题后面,对客户或利益相关者不透明,一开始似乎比较容易,但以后你会后悔的。

如何消除它:立即提出问题,当他们发生时(只是确保你有时间先通过一些解决方案!)。

5. QA需要比估计更多的时间

啊,这是由来已久的QA评估问题。您如何准确地估计将产生多少bug,需要多长时间来修复它们,以及这会产生什么影响?

如何消除它:根据构建的复杂性估计开发工作的百分比,然后添加偶然性。不要只是给出一个百分比——和QA分析师谈谈,让他们进行审查。此外,预先定义要测试的浏览器和设备,以及问题的类型。这将帮助您完善QA评估。另外,考虑使用自动化测试来节省时间手动和自动化测试的优缺点最好的自动化工具提供自动化测试的背景知识。

6.没有对功能进行优先排序

在瀑布式项目中,你的产品可能会一步一步地构建,直到你得到一个完整的、闪亮的新东西。这会让你觉得每件事都是优先考虑的。如果你在特性之间没有明确的优先级,当需求调整开始浮出水面时,就很难理解什么可以被处理。

附注:这不是一个瀑布vs敏捷的辩论- - - - - -可以存起来以备不时之需!或者看我的文章在这里在上面。

如何消除它:通过识别释放可用产品所需的内容优先考虑功能。考虑更灵活的方法,您可以尽快构建最小释放:确定用户绝对必要的功能,并构建每个阶段的客户可以测试和使用的工作产品。

我喜欢Henrik Chiberg和随附的这个图文章强调上面的方法。

范围蠕变-亨里克·克尼伯格

7.对如何应对变化没有达成一致意见

如果在项目开始时你还没有就如何处理变更达成一致,那么以后在范围内处理变更将会很困难,这是有意义的。

如何消除它:在你的轮廓工作说明书(或类似的文档)如何处理更改。如果你要使用变更请求,确保你详细说明了什么在范围内,什么不在范围内,以及如何提出变更请求。

8.估计差

估计很难正确。当有许多未知数时,在项目开始时准确就是一个挑战。某些事情可能不会被解释,您最终与此额外范围相关联,以便能够提供整体项目。

如何消除它:涉及整个团队的估计。不要在筒仓中工作并猜测。在估计之前,请确保您探索和确定客户要求的客户和业务需求。而不是根据可交付成果估计,看看以下内容:

  • 评估一个发现期,以确定您将构建什么—在此结束时,您可以为项目的其余部分提供更准确的评估。
  • 考虑使用时间和材料定价模型而不是固定价格。由于您在项目上计费了实际时间,因此它可能更灵活。这篇文化的文章在这里讨论了每种方法的好处和用途。
  • 不要确切地指定要构建哪些特性以及如何在范围内构建——允许变更的空间。

9.不询问新的请求

从客户或团队成员面临的新请求或想法很容易,相信他们是前进的正确道路(他们知道自己在做什么,对吧?)。如果您不正确询问这些请求,您最终可能会接受新的范围,重复工作或在不明显的情况下构建不必要的功能。

如何消除它:审查所有对整个团队提出新的要求。清楚地理解请求是什么,合并请求的影响,以及它对用户的结果。然后,对新请求进行优先排序,并交叉检查以确保它没有被交付到其他地方。

10.没有尽早让用户参与进来

我见过许多项目进入了最终阶段(甚至超过了最后阶段),然后才真正将其呈现给真正的用户。我们很容易欺骗自己,认为我们(客户、业务和团队)已经足够了解用户,从而避免与他们交互。如果你没有尽早采纳用户的反馈,你可能会走得太远,无法很好地接受用户的测试。在这一点上,你的范围可能会突然螺旋上升。

如何消除它:让用户尽早使用产品或服务。如果客户或预算持有者不愿意为此付费,那就通过不执行这种早期用户验证而获得的好处和可能产生的负面影响。制定一个计划来处理项目中出现的用户反馈。

如何在敏捷中管理范围渐变

范围渐变通常适用于具有固定范围的项目。如果我用的是敏捷方法?敏捷拥抱变化——坦率地说,如果你在不同的过程或方法中工作,你也应该这样。变革不应被视为敌人。

范围蠕变

作为一个敏捷的核心原则状态:

欢迎需求的变化,即使是在后期

发展。敏捷过程利用变化

客户的竞争优势。”

例如,如果你正在使用Scrum方法,当一个新的需求出现时,把它拉进Sprint计划会议把它写进待办事项里。与产品负责人和团队一起确定优先级,如果它进入Sprint,其他的东西将会被取消优先级。因为在项目开始时没有确定细节,所以可以合并变更。如果故事需要相同的努力,那么故事可以很容易地与其他故事交换。

敏捷的关键在于迭代,这意味着设计、构建、测试、学习,然后重复这个循环。改变是在你所拥有的时间内创造出最好产品的关键。

那么,在敏捷项目中什么才是范围渐变呢?因为你应该能够很容易地改变范围,而不用把整个项目抛给狮子,所以敏捷中的范围蔓延直到后来才会真正影响到你。

如果你的产品负责人在引入某些内容时没有优先考虑某些功能或任务,范围渐变就会发挥作用。如果他们想在当前周期中添加一些东西而不删除其他东西。此外,他们可能不会权衡新任务和优先级不高的任务之间需要付出的努力,这可能会导致他们试图把额外的努力塞进一个已经计划好的、太紧的周期中。

确保,对于任何进入待办事项列表的新特性,您都能有效地将它们分解成故事,并理解针对它们的工作,从而相应地确定优先级。如果您有一个理解这个过程的产品负责人,那么范围蔓延的威胁就会小得多。一般来说,在敏捷项目中减少范围蔓延要容易得多,这恰恰是因为它鼓励改变,并将改变纳入方法论本身的结构中。

管理范围蠕变的五种核心方法

5种方式管理范围蠕变

  1. 要积极主动。确定并同意变更管理前期过程。
  2. 优先考虑。看看什么可以被扩展以适应新的请求。
  3. 是透明的。出现范围蠕变后,将其与客户和利益相关者带来。
  4. 分析影响。计算出变更的影响(积极的和消极的),并向你的客户或利益相关者提出解决方案,以便向前发展。
  5. 拥抱它。弄清楚对于一个可测试的、可用的产品来说什么是必须的——如果这意味着改变范围,那么就考虑如何将这些改变合并起来。

视范围蔓延为积极因素!

在我看来,现在是时候改变我们的观察范围蠕变。我们不需要以不同的方式看待它作为偷偷摸摸的敌人。它不是范围蠕变 - 它的变化。你怎么管理变革是什么影响了项目——而不是改变它的请求。你只需要在它发生的时候注意到它,特别是在它不明显的时候,并在它发展之前提出它,而不需要任何形式的重新规划。

改变对你正在制作的产品是非常有益的。毕竟,我们都在这里建立最好的产品和服务,我们可以,如果这意味着需求必须改变,那么我们,作为项目经理,需要带头适应这一点。

你觉得呢?

你有范围渐变的例子吗?你是怎么处理的?或者你是否看到它积极地影响了一个项目,在这个项目中,你已经合并了需求的变化,并最终获得了一个更好的结果?请在下面的评论中告诉我!

我们的朋友和支持者:

星期一的标志白色的透明背景

2021年球队的PM工具
绝对可定制,非常直观。

免费试用

Suzanna Haworth.

Suzanna Haworth.

Suze Haworth是伦敦的一位自由数字项目总监。她有超过14年的机构工作经验,从早期从事客户管理工作到崭露头角,一路走来,并意识到自己对项目管理的真正需求。万博新闻皇马她现在领导的团队负责各种数字和网络建设,从社交活动和数字媒体到大型复杂网站。Suze曾为英国广播公司(BBC)、水援助组织(WaterAid)、第四频道(Channel 4)、埃索(Esso)、立顿茶(Lipton Tea)、SEAT和Mozilla等客户管理项目。她是一个经过认证的ScrumMaster,经常在会议上发言,也可以在网上发布博客。当她不导演和谈论数字事物(以及创建无数谷歌电子表格)时,她喜欢用山脉和咖啡来激发自己的痴迷。