如何在紧迫的截止日期内处理快速的项目规格变化？

Question

如何处理一个项目经理,这个项目经理实施了非常紧迫的截止日期,但是在截止日期前一天左右会带来新的功能和规范变更,以及另一个紧迫的截止日期.

最糟糕的是,大多数新内容会导致现有代码的重大改写,因为先前实现的业务规则不再适用或"获得"需要单独处理的奇怪角落案例.

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

我怎么能处理这种情况？这真是令人沮丧,一位同事已经退出了团队.

Answer 1

确实,无论你做什么,你都是人,你会犯错或错过事.也就是说,定期更改您的要求通常是由于要求不佳或开发过程不良或两者兼而有之.

一些设计前线？

业务分析经常受到开发人员,项目经理等的不断关注.大多数开发人员只想在第1天开始攻击,大多数PM都喜欢让他们:"哇,我们可以从项目启动阶段转向建设阶段在没有任何荒谬的商业分析的情况下,在1天内没有占用时间!这对于完成奖金看起来很棒!" 但请记住,PM的主要工作是保持项目的控制(按时和按预算)......不一定要让用户满意,当然也不要让开发人员满意.这并不是说他们完全没心肠; 良好的PM将通过实施范围控制和促进沟通来实现他们的目标,这两者都是有帮助的.

但是,花时间真正考虑所需要的东西并逐步完成可能的情景可能会对您正在处理的问题产生重大影响.

• 如果您已经努力进行彻底的业务分析,并且您仍然在最后一分钟更改,那么也许您的问题是另一个经典挑战:脱离用户.您的主题专家是您处理和识别角落案件的最佳武器.如果您的用户没有参与分析过程,请找到更好的主题专家.
• 用户也可能因为忙于正常工作而被解雇.在这种情况下,这是一个管理问题,他们需要得到指示,项目参与是他们工作的一部分; 这有点困难,因为通常同样的管理层告诉你"昨天完成它"是同一组傻瓜,他们期待项目神奇地发生,没有打嗝,没有任何资源(他们很常见,因为他们不明白定制软件开发的复杂性并假设它很容易).如果管理层毫无头绪并且不会改变......那么,你必须要加班加点并处理你所描述的问题,或者找一份新工作.

敏捷可以帮忙吗？

如果你的用户会提前告诉你有关这些角落的情况,那肯定会很好,对吧？这与Toby Hede在他的帖子中讨论的内容有关.也许即使在未完成状态下尽快将软件提供给用户面前的方法也可以更快地触发反馈.这是所有敏捷概念的灵感之一.创作者厌倦了处理你描述的问题,他们也意识到,如果管理和用户不会改变,那么开发可能会.它仍在开发中,但重点是通过各种技术获得早期反馈(主题专家与开发团队共同定位,更快地将粗略原型提供给用户手中,结合编程以捕获开发人员体验,以及更多) .所有这一切都是因为它被理解为我们是人类,我们会想念事情.

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

顺便说一句,你并不孤单.很多(也许是全部)商店都面临着这些挑战.