我是一家金融公司内部小型IT部门的一名软件开发人员，并且从事许多中小型项目，这些项目在整个项目中很少或者根本没有项目管理。这似乎总是导致范围的扩大，因此无法按时完成，并且不得不牺牲良好的设计/代码来在短期内满足用户/经理的需求。

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

谢谢。

解决方案

如果在请求其他功能时没有经理回推，那么我们将必须自己做。我将发布发行时间表，并在项目的未来阶段添加其他功能，这样我们就不会因为这些添加功能而在整个项目中迟到了。让人们知道这些添加功能将添加到项目中的时间以及何时可以看到它们。

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

不要害怕说"不"。当然要礼貌而专业。不要承诺任何事情，马上就不可能。不要立即对不确定的事情做出承诺。

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

让我们收到的每个需求都由经理签字，我们可以自己管理项目，但其他人可以在实施之前批准更改。然后，我们可以使用签核作为拒绝的手段。

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

关键是文档和可见性。我们有一个易于使用的问题跟踪系统，需求创建者可以使用该问题跟踪系统来提交其功能请求。绝不阻止他们这样做，但是在我们浪费了对请求进行编码的估算之后，会议才花了很多时间来审查这些请求。如果时间有限，现在请求者必须彼此竞争编码时间，而不仅仅是期望完成。作为编码人员，我们将受到保护，因为他们必须讨论它如何相互影响。

跟踪当前需求是什么。当客户来找新功能时，请确保他们知道添加新功能会导致以下情况之一：

• 交货日期将被移回
• 需要删除功能要求以为新功能腾出空间
• 或者，无法满足他们的新要求

正如鲍勃·金(Bob King)在评论中说的那样，在职业问题上说"不"不是一件坏事。

阅读一本有关Scrum的书，并在办公室中实施该实践。它有效地将表格转交给了管理人员，使他们将要完成的工作列为优先事项。我们的开发人员经常会遇到大量的需求列表和较短的时间线。使用Scrum，我们可以将这些需求分解为任务，确定在特定时间内可以工作几个小时，然后在这段时间的开始时间开会，确定"冲刺"的优先级是什么。它还有很多，但是管理经理的真正天才在于，它消除了" Cutesy"要求，因为优先级往往是应用程序的实质。自从我在组织中实施开发人员以来，我的生活变得更加愉快。

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

你可以做什么 ：

• 交流尽可能多的决策。甚至我们认为老板也应该这样做。最好通过电子邮件发送，这样没人可以声称无知
• 如果需要新功能，请确保每个人都知道这将花费多少时间。别小看进行有根据的猜测，然后将数字乘以风险因子，具体取决于功能的风险。
• 当项目到达终点时，列出仍需要完成的任务以及时间估计。再次确保所有参与人员都可以随时看到此列表。

基本上，我们需要做的是确保每个人都知道我们在做什么。这不一定会使项目本身按时完成，但是可以作为管理人员的镜子，因此他们可以了解决策的后果。

但总而言之，沟通，交流，沟通成为一种小型项目的领导者。

示波器蠕变有两种类型。一个原因是没有预先获得好的要求。这将导致意外的任务，以实现预期的效果。如果这是问题所在，那么我们可能想花更多的时间来收集需求，并严格记录每个周期的期望值。一旦有了这些，就可以创建许多底层任务和时间估计。如果有时间超支，那么至少我们会提前知道。

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

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

如果客户端从不希望退出，则此操作无效。查看我们是否可以在合同中设置一些合理的期限，例如"软要求期限"和"硬要求期限"。

显然，应该有一些回旋余地，并且从来没有一种坚决的方法来找出事实之后不应该去抱怨的东西，但是不应该这样，但是增加一个严格的截止日期和增加成本的威胁通常会确保一定数量的需求在一定程度上是不变的，因此可以保留一些理智。

不幸的是，我们基本上必须自己进行项目管理，并了解一些有关变更管理的知识。最好拿起一本可访问的项目管理书(而不是PMBOK)，并阅读有关变更管理的任何部分。

在我从事的项目上，我们通过以下方式管理变更

• 起草由利益相关者签署的需求规范
• 估算构建指定内容将花费多少工作
• 每次请求更改时，估计它将改变多少工作量，解释更改对成本和完成日期的影响
• 对不包含时间表更改的更改说不
• 在已接受的变更(包括接受时间表变更)上签字
• 记录请求的更改和批准的更改。

不幸的是，根据我的经验，变更管理从来都不是一件容易的事，而且在很多地方都可能出现问题。我听到的最常见的情况是对估计精度的不切实际的期望，以及利益相关者的不合理的要求(只是拒绝我们已经阐明的变更的含义，或者忽略诸如"只需完成"之类的要求的过程)

范围蠕动是所有未经批准的更改。阅读问题看起来好像我们知道答案，我们需要要求，变更请求和批准。

如果我们拥有BA和PM，以及所有其余的管理中间件，则可以通过需求声明，变更请求表，变更审查委员会等全力以赴。但是，我猜这不是我们想要的。

我们可以简单地完成所有这些操作。首先确定项目的发起人是谁。谁开始了它，谁拥有它。该人必须是一个批准项目预算和进度的人。你们两个都需要提出一个类似于以下双方都可以同意的过程。

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

现在创建一个变更登记表。这需要一列简短说明，一列较长说明，一个日期，一列影响，一列批准日期和批准者。影响列是最重要的。每当有人要求进行更改时，我们都需要弄清楚该更改将如何影响范围，预算或者进度。一项额外功能可能会增加5天和5,000美元的费用。如果我们需要在圣诞节前交货，则必须删除要求项目1,2,3.

一旦有了要求以及传达变更和影响的方法，最困难的部分是，未经赞助商批准，我们将无法进行变更。此批准可以是电子邮件，也可以是其他任何形式。但是它需要明确地说"我批准变更号码12"。如果没有明确的批准步骤，我们可能也不会打扰。

这是我们可以避免的最少文档/流程数量。主要目标是确保正确的人充分传达，接受和拒绝每次更改的影响。此人不是我们，通常不是发出更改请求的人。

不要让并非所有人都同意的功能改变或者加深。如果必须选择，则放其他东西。决定应该自己做。

我在同一情况下已经有很多年了。但是我的经历却有所不同。最初在我的公司里，我是孤独的狼。需求会议全部由我主持。收集了需求之后，我将构建该应用程序，瞧瞧，这不是用户想要的。重建时间，进行110亿次更改。多么恐怖的过程。从我的经理，到我，再到用户，每个人都会对此感到生气。

不幸的是，我发现人们经常需要软件，他们不想花时间设计解决方案，以解决他们正在寻找解决方案的业务问题。他们将一如既往地模糊，不愿承担任何责任。

随着我们的成长，即使他们以前从未管理过软件开发项目，并且几乎没有技术经验，我们还是聘用了一些人作为即时项目经理。这导致获得了"具体的"规范，每个人都同意了，但我(开发人员)同意了。

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

在争取应用程序的合理性之后，将构建它。在十分之九的用户中，用户仍然感到沮丧，因为他们总是与项目经理一起设计愚蠢的解决方案，但对他们而言效果并不理想。

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

现在我们来了一个完整的圈子。所有项目经理都已辞职，我们已经裁员了很多，所以我再次负责整个周期。幸运的是，我们已从错误中吸取了教训，并且管理层仍致力于执行强制执行协议所需的工作。我们在为用户提供应用程序的方式上也进行了一些更改。

我们经常给他们小块，并要求他们进行测试，并签署该节正是他们想要和需要的。如果不是这样，他们想要的任何更改都将添加到项目的末尾，并且每个人都将被告知它将如何更改时间表。当底线受到明显影响时，小巧的变化和异想天开迅速消失。

我们将必须自己进行一些项目管理。了解有关敏捷项目管理的信息：

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

编写积压订单，而不要对更改或者功能说是/否，请按优先级对它们进行排序。使事情变得完美的"好"东西总是可以推迟到以后的版本，并明确说明这就是计划。专注于最低限度，首先获得功能性产品。