project-management - 如何在时间紧迫的情况下应对项目规范的快速变化？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

4年前关闭。




Improve this question




如何处理一个项目经理的截止日期非常紧迫，但在截止日期前一天左右会带来要实现的新功能和规范更改，还有另一个紧迫的截止日期。

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

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

我怎么能应付这样的情况？这真是令人沮丧，一位同事已经退出了团队。

Answer 1

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

一些预先设计？

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

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

如果您已努力进行彻底的业务分析，但仍然在最后一刻进行更改，那么您的问题可能是另一个经典挑战:脱离用户。您的主题专家是您处理和识别这些极端案例的最佳武器。如果您的用户没有参与分析过程，请找更好的主题专家。

用户也可能因为太忙于日常工作而脱离了工作。在这种情况下，这是一个管理问题，他们需要得到指示，项目参与是他们工作的一部分；有时这很难，因为通常告诉您“昨天完成”的同一管理人员是同一群傻瓜，他们期望项目神奇地发生而没有打嗝并且没有任何资源(他们很常见，因为他们不理解定制软件开发的复杂性并假设它很容易)。如果管理层毫 headless 绪并且不会改变......那么，您必须加类并处理您描述的问题，或者找到一份新工作。

敏捷能帮上忙吗？

如果您的用户早点而不是晚点告诉您这些极端案例，那肯定会很好，对吗？这与 Toby Hede 在他的帖子中讨论的内容有关。也许一种能够尽快将软件呈现在用户面前的方法，即使是在未完善的状态下，也可以更快地触发反馈。这是所有敏捷概念的灵感之一。创作者厌倦了处理你描述的问题，他们也意识到如果管理和用户不改变，那么也许开发可以。它仍处于开发阶段，但强调通过各种技术获得早期反馈(让主题专家与开发团队同处一地，更快地将粗略的原型(prototype)交付给用户，结对编程以充分利用开发人员体验等等) .这一切都是因为它明白我们是人类，我们会错过一些事情。

最后，您提到您正在尝试使系统可扩展以帮助快速更改，但是如何？您是否将表示逻辑与业务逻辑分开？您是否将业务逻辑封装在对象中，并进行适当分区以最小化依赖和耦合？所有这些事情都很难做到，并且可能需要时间来计划和构建。

顺便说一句，你并不孤单。许多(也许是所有)商店都有这些挑战。