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

Question

我是一家金融公司内部小型 IT 部门的开发人员，曾参与过许多中小型项目，这些项目自始至终几乎没有或根本没有项目管理。这似乎总是导致范围蔓延，因此无法满足最后期限，并且不得不牺牲良好的设计/代码来满足用户/经理的短期需求。

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

谢谢。

score 8 · Accepted Answer

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

score 5 · Accepted Answer

在开始编码之前，几乎不可能有一个功能齐全的规范。尤其是在小公司。敏捷方法效果更好，但这不应该阻止您完成项目。

你可以做什么：

尽可能多地就正在做出的决定进行沟通。就连你们都认为你的老板应该这样做。最好通过电子邮件，这样没有人可以声称无知
如果需要新功能，请确保每个人都知道这将花费多少时间。不要低估。根据功能的风险，做出有根据的猜测并将数字乘以风险因素。
当一个项目接近终点时，列出仍然需要完成的任务，以及时间估计。同样，确保所有相关人员都可以随时看到此列表。

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

但总而言之，沟通，沟通，沟通，成为一种小项目负责人。

score 3 · Accepted Answer

如果您在请求附加功能时没有经理可以推迟，您将不得不自己做。我会发布一个发布时间表并为项目的未来阶段添加额外的特性，这样你就不会因为这些额外的特性而迟到整个项目。让人们知道这些附加功能将添加到项目中的时间以及他们何时可以看到它们。

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

score 2 · Accepted Answer

范围蔓延有两种类型。一个源于没有预先得到好的要求。这会导致意外的任务，以便交付预期的内容。如果这是问题所在，那么您可能希望提前花更多时间收集需求并严格记录每个时期的预期内容。一旦你有了这个，你可以创建一些低级别的任务和时间估计。如果有时间超限，那么至少你会提前知道。

第二种类型源于在开发周期中间添加的小功能。这是你必须学习如何说不的地方。你不能总是说不，但你必须选择你的战斗。请记住，这种类型的范围蔓延并不是来自一件大事。它来自很多小事。被一千张剪纸杀死。

score 1 · Accepted Answer

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

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

score 1 · Accepted Answer

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

score 1 · Accepted Answer

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

如果客户从不想签字，这将不起作用。看看你是否可以在你的合同中设置一些合理的期限，比如“软请求期限”和“硬请求期限”。

显然应该有一些回旋的空间，而且从来没有一种硬性的方法来确定什么应该在事后顺利通过，什么不应该，但是增加一个硬性的最后期限和更多成本的威胁通常会确保大量的 reqs 在某一点上是不可变的，从而保持你的一些理智。

score 1 · Accepted Answer

不幸的是，您基本上必须自己进行项目管理，并学习一些有关变更管理的知识。您最好拿起一本易于理解的项目管理书籍（不是 PMBOK）并阅读有关变更管理的任何部分。

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

起草由利益相关者签署的需求规范
估计构建指定内容所需的工作量
每次请求更改时，估计它将更改多少所需的工作量，解释更改对成本和完成日期的影响
对不包括更改日程的更改说不
签署已接受的变更（包括接受时间表的变更）
记录请求的更改以及批准的更改。

不幸的是，根据我的经验，变革管理从来都不是一件有趣的事情，而且有很多地方可能会出错。我听到的最常见的是对估计精度的不切实际的期望，以及利益相关者的不合理要求（简单地拒绝你已经阐明的更改的含义，或者忽略流程，要求“完成它”）

score 1 · Accepted Answer

I have been in the same situation for many years. My experience was a little different however. Originally in my company, I was the lone wolf. The requirements meetings were all led by me. After gathering the requirements, I would build the app, and lo and behold, it wasn't what the users wanted. Rebuild time, with eleven billion changes. What a horrific process. Everyone would get mad about it from, my manager, to me, to the users.

Unfortunately I have found that people that want software, all too often, don't want to put in the time to help you design a solution that will solve the business problems they are looking for a solution to. They will be consistently vague, and not want to commit to anything.

As we grew, we hired some people to be instant project managers, even though they had never managed a software dev project before, and had little to no technical experience. This resulted in getting "concrete" specs that everyone, but me the dev, agreed upon.

Of course the results were nearly as bad as the original situation, but at least we had management buy-in on enforcing the specifications. Unfortunately these concrete specs, were filled with ridiculous, and often truly impossible wants.

After fighting for sanity in the application, it would be built. Nine times out of ten, the users were still upset, because they invariably, along with the project managers, designed stupid solutions, that did not work well for them.

Again, rebuild hell ensued.

We have now come full circle. All of the project managers are gone, and we have had some pretty heavy layoffs, so I am once again responsible for the entire cycle. Fortunately we have learned from our mistakes, and management is still dedicated to doing what is needed to enforce agreements. We also have changed a bit in the way we give the users an app.

We give them small chunks, often, and require them to test them, and sign off that the section is what they want and need. If it isn't, any changes they want get added to the end of the project, and everyone is informed about how it will change the schedule. Petty changes and whims, disappear quickly, when the bottom line is demonstrably affected.

score 0 · Accepted Answer

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

score 0 · Accepted Answer

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

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

正如鲍勃金在评论中所说，在专业问题上说“不”并不是一件坏事。

score 0 · Accepted Answer

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

score 0 · Accepted Answer

Scope Creep 是关于未经批准的更改。阅读您的问题，您似乎知道答案，您需要要求、变更请求和批准。

如果您有 BA 和 PM 以及所有其他管理中间件，您可以全力以赴地处理需求声明、变更请求表格、变更审查委员会等。但是我猜这不是您想要的。

您可以简单地完成所有这些工作。首先确定项目的发起人是谁。谁启动了它，谁拥有它。这需要是一个批准您项目的预算和日程安排的人。你们双方都需要提出一个类似于以下的流程，你们都可以同意。

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

现在创建一个变更登记表。这需要一个用于简短描述的列，一个用于较长描述的列，一个日期，一个用于影响的列以及一个用于批准日期和批准者的列。冲击柱是最重要的。每次有人要求更改时，您都需要弄清楚该更改将如何影响您的范围、预算或时间表。一个额外的功能可能会增加 5 天和 5,000 美元。如果您需要在圣诞节前交货，您必须删除要求项目 1、2、3。

一旦你有了你的要求和沟通变更和影响的方法，最困难的部分是你不能在没有得到赞助商批准的情况下实施变更。该批准可以是电子邮件或其他任何形式。但它需要明确地说“我批准第 12 号变更”。如果没有明确的批准步骤，您最好不要打扰。

这大约是您可以摆脱的最少文档/流程。主要目标是确保每个更改的影响都被正确的人充分传达、接受和拒绝。此人不是您，通常也不是提出更改请求的人。

score 0 · Accepted Answer

不要让每个人都不同意的功能改变或加深。如果您必须选择，请放下其他东西。决定应该自己做出。

score 0 · Accepted Answer

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

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

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

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

15 回答 15

Related

Reference