如何在紧迫的期限内应对项目规格的快速变化？[关闭]

Question

如何与项目经理打交道，该项目经理的截止日期非常紧迫，但在截止日期前一天左右需要实施新功能和规格更改，并且还有另一个紧迫的截止日期。

最糟糕的是，大多数新内容都会导致对现有代码的重大重写，因为以前实现的业务规则不再适用或“获得”需要单独处理的奇怪的极端情况。

似乎无论我们如何努力使系统具有可扩展性，总有一些事情是在最后一刻才出现的，需要快速实现和支持。

遇到这样的情况我该如何应对呢？这真是令人士气低落，一位同事已经退出了团队。

Answer 1

确实，无论你做什么，你都是人，你都会犯错误或错过一些事情。也就是说，对需求的定期更改通常是由于需求不佳或开发过程不佳或两者兼而有之的结果。

预先进行一些设计？

业务分析经常受到开发人员、项目经理等的忽视。大多数开发人员只是想在第一天就开始破解，并且大多数 PM 喜欢让他们：“哇，我们可以在 1 天内从项目启动阶段进入构建阶段，而无需任何可笑的业务分析内容占用时间！这对于完成奖金来说看起来很棒！”但请记住，PM 的主要工作是控制项目（按时且按预算）……不一定要让用户满意，当然也不一定要让开发人员满意。这并不是说他们完全无情；而是说他们完全无情。优秀的项目经理将通过加强范围控制和促进沟通来实现他们的目标，这两者都是有帮助的。

但花时间认真思考需要什么并逐步解决可能的情况可以对您正在处理的问题产生重大影响。

• 如果您已经努力进行彻底的业务分析，但最终仍然在最后一刻做出更改，那么也许您的问题是另一个经典挑战：脱离的用户。您的主题专家是您处理和识别这些极端情况的最佳武器。如果您的用户不参与分析过程，请聘请更好的主题专家。
• 用户也可能因为太忙于日常工作而失去参与度。在这种情况下，这是一个管理问题，他们需要得到指示，让他们知道项目参与是他们工作的一部分；有时这很困难，因为通常告诉你“昨天完成它”的管理层是同一群傻瓜，他们期望项目能够奇迹般地顺利进行，没有任何问题，也没有任何资源（他们的常见之处在于他们不理解定制软件开发的复杂性并假设它很容易）。如果管理层毫无头绪并且不会改变......那么，你必须要么加班并处理你所描述的问题，要么找到一份新工作。

敏捷可以提供帮助吗？

如果您的用户能够尽早而不是稍后告诉您这些极端情况，那肯定会很好，对吧？这与 Toby Hede 在他的帖子中讨论的内容有关。也许一种能够尽快将软件呈现在用户面前的方法，即使是在未完善的状态下，也可以更快地触发反馈。这是所有敏捷概念的灵感之一。创建者厌倦了处理您所描述的问题，他们也意识到，如果管理和用户不打算改变，那么也许开发可以改变。它仍然是开发过程，但重点是通过各种技术获得早期反馈（让主题专家与开发团队同处一地，更快地将粗略的原型交付给用户，结对编程以利用开发人员的经验，等等） 。所有这一切都是因为我们知道我们是人类，我们会错过一些东西。

最后，您提到您正在尝试使系统可扩展以帮助应对快速变化，但是如何实现呢？您是否将表示逻辑与业务逻辑分开？您是否将业务逻辑封装在对象中，并进行适当的分区以最大限度地减少依赖性和耦合？所有这些事情都很难做到，并且需要时间来规划和构建。

顺便说一句，你并不孤单。很多（也许是所有）商店都面临着这些挑战。

Answer 2

首先不要让他们强加最后期限。

你有2个选择

• 产品经理给你一个功能列表，你告诉他们什么时候准备好。
• PM 会向您提供功能列表和截止日期。然后，您告诉他们您将在给定时间内实现哪些功能。

如果 PM 是你的经理或者有权规定截止日期+功能数量，那么我会寻找一份新工作。 Careers.stackoverflow.com

如果 PM 不是您的经理，那么您需要让您的经理参与进来，并让他们从上面的列表中向 PM 提供他们的选项。

Answer 3

这个东西真的很难处理。这里真正的问题是你没有实际的过程。

答案实际上取决于组织中的政治情况以及你需要多大的能量来推动变革。

过去我曾尝试将流程变更引入多个组织，这一直是一场斗争。但是，有可能。

我会看一下管理软件开发的一些方法。例如，我使用并推荐Scrum。

在快速变化的情况下，处理具有明确责任目标的短迭代可能真的很有帮助。您可能需要支持和管理您的项目经理，但这听起来像当前的“流程”。显然不起作用，因此销售新流程实际上变得更加容易 - 您有可靠的商业案例需要改进。

坚实的流程可以帮助您“推回”关于改变要求。快速的反动变化通常是组织方向和战略中更广泛问题的症状，在组织内解决这个问题符合每个人的利益。

Answer 4

这是您作为开发人员将面临的主要挑战之一。

我过去使用过的一项很好的技巧就是提问。获得规范后，在其中找到需要最终用户澄清的内容。这总会减慢事情的速度，并增加管理者对风险的看法。

确保您的项目经理了解实施项目后期更改所涉及的风险。

Answer 5

您和您的团队是否曾尝试与经理本人讨论此问题？这是你应该做的第一件事。

他可能没有那么多的开发过程经验，因此持续紧迫的截止日期和非常晚的主要更改。我见过这样的案例，那些无法发展的人，但认为他们可以在PM做得更好。
从坐着和他说话，可能会出现两件事，这取决于他的个性/专业性。他会接受你的观点，并尝试改变未来的情况，否则他将成为一个聪明的人并且不会放弃，在这种情况下值得将情况升级到更高的水平。我认为没有任何公司愿意接受失去的开发人员。

或者，他的经理可能在他身边。这是一个问题。

如果没有任何结果，正如已经建议的那样，改变工作是公平的事情。