作为没有项目管理的开发人员，避免范围蔓延的最佳方法

Question

我是一家金融公司内部小型IT部门的s / w开发人员，曾参与过许多项目管理很少或根本没有项目管理的中小型项目。这似乎总是导致范围蔓延，因此不能满足最后期限，并且必须牺牲良好的设计/代码以在短期内满足用户/经理。

作为开发人员，我可以做些什么来确保在编写任何代码之前确定用户需求，并且考虑到用户/经理的需求和期望，任何变更请求都得到妥善管理。

感谢。

Answer 1

在这种情况下，范围蔓延几乎是不可避免的，利益相关者没有时间提前帮助进行分析，也没有正式的合同。我建议选择一种敏捷的方法，让您不断调整目标和期望。像scrum这样的东西。短周期将帮助利益相关者及早看到结果并调整需求，因为他们更好地理解问题，并且它们将使您免于精神错乱，因为冲刺周期将允许您适应这些变化。

Answer 2

在开始编码之前，几乎不可能拥有全功能的规范。特别是在小公司。 敏捷方法效果更好，但这不应该让您无法完成项目。

你能做什么：

• 尽可能多地沟通 正在做出的决定。甚至你认为你的老板应该这样做。优选地 电子邮件，所以没有人可以声称无知
• 如果要求新功能，请确保每个人都知道多少 这将是时候了。别 低估。做一个受过教育的人 猜测并将数字乘以a 风险因素，取决于风险 功能。
• 当项目到达终点时，请列出任务列表 仍然需要一起完成 有时间估计。再说一遍 确保所有参与者都能看到这一点 始终列出。

基本上你需要做的是确保每个人都知道你在做什么。这并不一定能使项目本身及时完成，但它可以作为管理者的一个镜像，因此他们可以看到他们决策的后果。

但总而言之，沟通，沟通，沟通并成为一种迷你项目的领导者。

Answer 3

如果在请求其他功能时没有经理可以推回，那么您将不得不自己动手。我会发布一个发布计划并为项目的未来阶段添加其他功能，这样您就不会因为这些附加功能而在整个项目中迟到。让人们知道这些附加功能将多长时间添加到项目中以及何时可以看到它们。

最难的部分是学习如何告诉人们不，但这是你需要学习的东西。

Answer 4

范围蠕变有两种类型。一个原因是预先没有得到好的要求。这会导致意外的任务，以实现预期的目标。如果这是问题所在，那么您可能希望在收集需求时花费更多时间，并严格记录每个期间的预期。完成此操作后，您可以创建许多低级别任务和时间估算。如果有时间超支，那么至少你会提前知道。

第二种类型源于在开发周期中间添加的少量功能。这是你必须学习如何说不的地方。你不能总是说不，但你必须选择你的战斗。请记住，这种类型的范围蠕变并非来自一件大事。它来自很多小东西。这是一千个纸屑的死亡。

Answer 5

不要害怕说“不”。当然，礼貌，专业。不要做任何你不能做到的事情是不可能的。不要立即承诺任何你不确定的事情。

此外，即使您只是将它应用于自己，也不要害怕拿起项目管理书籍，阅读并应用它。

Answer 6

关键是文档和可见性。我们有一个易于使用的问题跟踪系统，需求创建者可以使用它来输入他们的功能请求。他们从不劝阻他们这样做，但是在我们对编码它们进行了大量估算之后，会议将用于审查请求。如果时间有限，现在请求者必须在彼此之间竞争编码时间，而不是仅仅期望它完成。然后我们作为编码员受到保护免受蠕变，因为他们必须讨论它如何相互影响。

Answer 7

一旦您和客户对需求感到满意，请使用签名的需求文档将其锁定。之后的任何事情都是需要花费更多钱的变更请求。

如果客户永远不想签字，这不起作用。看看你是否可以在合同中设定一些合理的截止日期，例如“soft reqs deadline”和“hard reqs deadline”。

显然应该有一些摆动的空间，并且从来没有一种快速的方法来弄清楚事后应该发生什么，不应该发生什么，但是增加一个艰难的期限和更多成本的威胁通常会使确保大量的req在一定程度上存在且不变，从而保留了一些理智。

Answer 8

不幸的是，您基本上必须自己进行项目管理，并了解一下变更管理。您最好选择一本可访问的项目管理书籍（不是PMBOK）并阅读有关变更管理的任何部分。

关于项目我已经参与过，我们已经通过

进行了变更

1. 起草利益相关方签署的需求规范
2. 估算构建指定内容所需的工作量
3. 每次请求更改时，请估算需要更改的工作量，以解释因更改而导致的成本和完成日期的影响
4. 对不包含更改计划的更改说“否”
5. 对已接受的更改进行签字（包括接受更改时间表）
6. 记录所请求的更改以及已批准的内容。

不幸的是，根据我的经验改变管理从来都不是很有趣，并且有很多地方可能出错。我听过的最常见的是对估计精确度的不切实际的期望，以及利益相关者的不合理要求（简单地拒绝你所阐述的变化的含义，或者忽略了过程，例如“只是完成它”）

Answer 9

多年来，我一直处于同样的境地。然而，我的经历有点不同。最初在我的公司，我是孤独的狼。要求会议全部由我领导。收集完需求后，我会构建应用程序，并且看，这不是用户想要的。重建时间，有11亿次更改。多么可怕的过程。从我的经理，我的经理，用户那里，每个人都会为此感到生气。

不幸的是，我发现想要软件的人往往不想花时间帮助您设计解决方案来解决他们正在寻找解决方案的业务问题。他们将一直模糊，不想做任何事情。

随着我们的成长，我们聘请了一些人成为即时项目经理，即使他们以前从未管理过软件开发项目，也几乎没有技术经验。这导致获得“具体”规范，每个人，但我的开发者，同意。

当然，结果几乎与原始情况一样糟糕，但至少我们在执行规范方面有管理层的支持。不幸的是，这些具体的规格充满了荒谬，往往是真正不可能的要求。

在应用程序中争取理智之后，它将被构建。十分之九的用户仍然感到不安，因为他们总是和项目经理一起设计了愚蠢的解决方案，这些解决方案并不适合他们。

再次，重建地狱随之而来。

我们现在已经完整了。所有的项目经理都不见了，我们已经进行了一些相当大的裁员，所以我再次负责整个周期。幸运的是，我们从错误中吸取了教训，管理层仍然致力于执行协议所需的工作。我们在为用户提供应用的方式上也有所改变。

我们经常给他们小块，并要求他们测试它们，并签署该部分是他们想要和需要的部分。如果不是，他们想要的任何更改都会添加到项目的最后，并且每个人都会知道它将如何更改计划。当底线明显受到影响时，小小的变化和突发奇想很快消失。

Answer 10

让您收到的每项要求都由经理签字，您可以自己管理项目，但在实施之前让其他人批准更改。然后你可以使用签字作为杠杆说不。

Answer 11

跟踪当前的要求。当客户来并要求新功能时，请确保他们知道添加新功能会导致以下事情之一发生：

1. 交货日期将被移回
2. 需要删除功能要求以便为新的
腾出空间
3. 或者，他们的新要求无法满足
正如鲍勃·金在评论中所说，在专业问题上说“不”并不是坏事。

Answer 12

阅读一本关于Scrum的书，并在办公室实施该练习。它有效地改变了管理层的表格，使它们优先考虑他们想要完成的事情。我们常常为开发人员提供庞大的需求列表和短时间线。使用Scrum，您可以将这些要求分解为任务，确定在特定时间内可以工作多少小时，然后在该时间开始时召开会议以确定此“冲刺”的优先级。除了管理你的经理之外，还有更多的东西，但真正的天才是它消除了“Cutesy”的要求，因为优先级往往是应用程序的真正优势。自从我在组织中实施以来，我作为开发人员的生活变得更加愉快。

Answer 13

范围Creep是关于未经批准的更改。阅读您的问题看起来您知道答案，您需要要求，变更请求和批准。

如果您有BAs和PM以及所有其他管理中间件，您可以使用需求声明，变更请求表单，更改审查委员会等全部工作。但是我猜这不是您想要的。

你可以简单地完成所有这些工作。首先确定项目的赞助商是谁。谁踢了它谁拥有它。这需要一个人批准您的项目的预算和日程安排。你们两个都需要提出一个类似于以下的过程，你们都可以达成一致。

接下来在Excel中为您的需求注册创建一个工作表。列出所有要求。给每个简短的描述并在必要时留下一列用于更长的描述。还包括请求该要求的列，何时以及是否设计了解决方案，以及是否提供了解决方案。与你的赞助商坐下来，并同意这是基线。

现在创建一个更改注册表。这需要一个用于简短描述的列，一个用于更长的描述，一个用于影响的列，一个用于批准的日期并且经过批准。影响栏是最重要的。每当有人请求更改时，您需要确定该更改将如何影响您的范围，预算或计划。额外功能可能会增加5天和5,000美元。如果您需要在圣诞节前交付，则必须删除要求项1,2,3。

一旦您有了要求和方法来传达变更和影响，最难的部分是您未经赞助商批准就无法实施变更。此批准可以是电子邮件或其他任何内容。但它需要明确说“我批准更改号码12”。如果没有明确的批准步骤，您也可以不用费心。

这是关于您可以逃脱的最低数量的文档/流程。主要目标是确保每个变更的影响得到充分沟通，并被合适的人接受和拒绝。此人不是您，通常不是提出变更请求的人。

Answer 14

不要让每个人都不同意的功能发生变化或深化。如果你必须选择，丢弃别的东西。决定应该自己做。

Answer 15

您将不得不自己做一些项目管理。了解敏捷项目管理：

http://agilesoftwaredevelopment.com/blog/artem/scrum-under-10-minutes-video

开发积压而不是对更改或功能说“是/否”，按优先级对其进行排序。将事情变得完美的“好”东西总是可以推迟到以后的版本，并明确说明这就是计划的内容。专注于最低要求，以获得功能性产品。