作为开发人员避免范围蔓延的最佳方法是不需要项目管理

Question

我是一家财务公司内部IT部门的小型开发人员，曾参与过许多中小型项目，整个项目管理都没有。这似乎总是导致范围蔓延，因此不能按时完成任务，不得不牺牲良好的设计/代码以在短期内满足用户/管理人员的需求。

作为开发人员，我可以做些什么来确保在编写任何代码之前确定用户需求，并根据用户/经理的要求和期望正确管理任何更改请求。

谢谢。

Answer 1

如果您没有管理员在需要附加功能时推回，您必须自己动手。我会发布发布计划并为项目的未来阶段添加其他功能，这样您就不会因为这些附加功能而拖延整个项目。让人们知道这些附加功能将添加到项目中的时间以及他们何时能够看到它们。

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

Answer 2

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

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

Answer 3

如果您收到了每位经理签名的要求，您可以自己管理项目，但在执行之前请其他人批准更改。那么你可以使用签字作为杠杆来说不。

Answer 4

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

Answer 5

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

Answer 6

记录当前的要求。当顾客来问的新功能，确保他们知道，添加新功能，将导致以下情况之一发生：

1. 的交货日期将被移回
2. 功能的要求将需要被丢弃以腾出空间给新的一个
3. 或者说，他们的新的要求不能得到满足

正如鲍勃·金在他的评论在一个专业的事情说，说“不”是不是一个坏事情。

Answer 7

阅读一本关于Scrum的书并在您的办公室实施。它有效地改变了管理层的表格，使他们优先考虑他们想要完成的任务。我们经常会向开发人员提交一份巨大的需求清单和一个简短的时间表。通过Scrum，您可以将这些需求分解为多个任务，确定您可以在特定时间内工作多少个小时，然后在开始时间内召开会议确定此“冲刺”的优先级。还有更多，但真正的天才，管理你的经理的旁白是它消除了“可爱”的要求，因为优先级往往是应用程序的真正优点。自从我在组织中实施后，作为开发人员的生活更加愉快。

Answer 8

开始编码之前，实际上不可能有全功能的规范。特别是在小公司。 敏捷方法效果更好，但这不会阻止您完成项目。

你可以做什么：

• 尽可能多的可能沟通上当受骗 决定。即使你认为你的老板也应该这样做。最好通过 电子邮件，所以没有人可以声称无知
• 如果要求新功能，确保每个人都知道这需要多少时间。不要 低估。做一个受过教育的 猜测并将数字乘以 风险因素，具体取决于该功能的风险 。
• 当一个项目到达终点线时，将需要完成的任务 的列表与 一起作为时间估计。再次，使 确保所有参与者可以随时看到这个列表 。

基本上你需要做的是确保每个人都知道你在做什么。这并不一定能使项目按时完成，但它可以作为管理者的反映，以便他们看到他们的决定会带来什么后果。但总而言之，沟通，交流，沟通并成为一种小型项目领导者。

Answer 9

有两种类型的范围蠕变。一个原因是预先没有得到很好的要求。这导致意想不到的任务，以实现预期的目标。如果这是问题，那么您可能需要在收集需求时花费更多时间，并严格记录每个期间的期望值。一旦你有了这个，你可以创建一些低级任务和时间估计。如果有时间超时，那么至少你会提前知道。

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

Answer 10

一旦您和客户满意要求，请使用签名的需求文档锁定它们。之后的任何事情都是花费更多资金的变更请求。

如果客户不想签收，这不起作用。看看您是否可以在合同中设置一些合理的期限，例如“软要求期限”和“硬要求期限”。

很显然，应该有一些摆动的空间，并且从来没有一种难以确定的方式来确定事后应该吱吱嘎嘎地说什么不应该，但是增加严格的最后期限和更多成本的威胁通常会确保大量的需求在某个特定的时刻处于不变的状态，从而保护您的一些理智。

Answer 11

不幸的是，您基本上必须自己做项目管理，并了解一些关于变更管理的知识。你最好选择一个可访问的项目管理书（而不是PMBOK）并阅读关于变更管理的任何章节。

在项目我工作，我们已经通过

1. 起草这是由利益相关者
2. 估计需要多少工作需要建立的被指定什么解约的要求规范管理变革
3. 每次请求更改时，请估计需要多少工作量才能更改所需的工作量，以说明更改对成本和完成日期造成的影响
4. 对不包含对计划进行更改的更改说“否”
5. 获取已接受更改的签名（包括接受更改时间表）
6. 记录所请求的更改以及批准的内容。

根据我的经验，变更管理从来都不好玩，不幸的是，还有很多地方可能出现问题。我听到的最常见的情况是对估算精度的不切实际的期望，以及来自利益相关者的不合理要求（仅仅拒绝你已经阐明的变更的影响，或者忽略了需要完成的需求的过程）

Answer 12

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

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

你可以简单地做到这一切。首先确定谁是项目的赞助人。谁把它踢掉了，谁拥有它。这需要一个人为您的项目批准预算和时间安排。你们两个都需要提出一个类似于以下的流程，你们都可以达成一致。

接下来在Excel中为您的需求注册表创建一张表。列出所有要求。给每一个简短的描述，并留下一个专栏，以便在必要时进行更长的描述。还包括谁要求这些要求的列，何时设计解决方案以及解决方案是否交付。与你的赞助商坐下来，并同意这是基准。

现在创建一个更改注册表。这需要一个简短描述的列，一个描述较长的描述，一个日期，一个影响列，一个批准日期和批准。影响栏是最重要的。每当有人要求更改时，您需要弄清楚这种更改会如何影响您的范围，预算或时间表。额外的功能可能会增加5天和5000美元。如果您需要圣诞节送货，则必须取消需求项目1,2,3。

一旦你有你的要求和沟通变化和影响的方法，最难的部分是你不能在未经你的赞助商批准的情况下进行变更。该批准可以是电子邮件或其他任何方式。但它需要明确地说“我批准更改号码12”。没有明确的批准步骤，您可能不会感到困扰。

这是关于您可以避开的文档/过程的最小数量。主要目标是确保每个变更的影响得到充分沟通并被合适的人接受和拒绝。这个人不是你，一般也不是提出变更请求的人。

Answer 13

不要让功能改变或加深，这对每个人都不适合。如果你不得不选择其他的东西，决定应该使自己。

Answer 14

我多年来一直处于同样的境地。然而，我的经历有点不同。最初在我的公司，我是孤独的狼。要求会议全由我主持。收集需求后，我会构建应用程序，然后瞧瞧，这不是用户想要的。重建时间，有110亿次更改。多么可怕的过程。每个人都会为我的经理，我的，用户而生气。

不幸的是，我发现那些想要软件的人往往不想花时间帮助您设计解决方案，以解决他们正在寻找解决方案的业务问题。他们会一直含糊不清，不想承诺任何事情。

随着我们的成长，我们聘请了一些人成为即时项目经理，尽管他们之前从未管理过软件开发项目，而且几乎没有任何技术经验。这导致了“具体”的规格，每个人，但我是开发商，同意。

当然，结果几乎和原来的情况一样糟糕，但至少我们在强制执行规格时有管理层的买入。不幸的是，这些具体的规格，充满了荒谬的，往往真正不可能的愿望。

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

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

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

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

Answer 15

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

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

制定积压，而不是说是/否来更改或功能，按优先级排序。为了让事情变得完美，“好”的东西总是可以推迟到更晚的版本，并且明确说明这就是计划。专注于最低限度获得功能性产品。