如何处理一个项目经理,该项目经理规定了截止日期非常紧张但在截止日期前一天左右的时间会带来新的功能和规范变更,以及另一个紧迫的截止日期。
最糟糕的是,大多数新内容会导致现有代码的重大改写,因为先前实施的业务规则不再适用或“获得”需要单独处理的奇怪角落案例。
似乎无论我们如何努力使系统具有可扩展性,总有一些事情在最后时刻出现,需要快速实施和支持。
我怎么能处理这种情况?这真是令人沮丧,一位同事已经退出了团队。
答案 0 :(得分:5)
无论你做什么,你都是人,你会犯错误或错过事情。也就是说,定期更改您的要求通常是由于要求不佳或开发过程不良,或两者兼而有之。
有些设计在前面?
业务分析经常受到开发人员,项目经理等的不断关注。大多数开发人员只想在第1天开始攻击,大多数PM都喜欢让他们:“哇,我们可以从项目启动阶段开始在1天的施工阶段,没有任何荒谬的商业分析占用时间!这对于完成奖金看起来很棒!“但请记住,PM的主要工作是保持项目的控制(按时和按预算)......不一定要让用户满意,当然也不要让开发人员满意。这并不是说他们完全没心肠;良好的PM将通过实施范围控制和促进沟通来实现他们的目标,这两者都是有帮助的。
但是,花时间真正考虑所需要的内容并逐步完成可能的情景可能会对您正在处理的问题产生重大影响。
敏捷帮助可以吗?
如果您的用户会提前告诉您有关这些角落的情况,那肯定会很好,对吧?这与Toby Hede在他的帖子中讨论的内容有关。也许即使在未完成状态下尽快将软件提供给用户面前的方法也可以更快地触发反馈。这是所有敏捷概念的灵感之一。创作者厌倦了处理你描述的问题,他们也意识到,如果管理和用户不会改变,那么开发可能会。它仍在开发中,但重点是通过各种技术获得早期反馈(主题专家与开发团队共同定位,更快地将粗略原型提供给用户手中,结合编程以捕获开发人员体验,以及更多) 。所有这一切都是因为我们理解我们是人类,我们会错过任何事情。
最后,你提到你试图使系统可扩展以帮助快速改变,但是如何?您是否将表示逻辑与业务逻辑分开?您是否将业务逻辑封装在对象中,进行适当分区以最小化依赖性和耦合?所有这些都很难做,并且需要时间来计划和建设。
顺便说一句,你并不孤单。许多商店都有这些挑战。
答案 1 :(得分:4)
不要让他们首先施加截止日期。
您有2个选项
如果PM是您的经理或有权限制截止日期+功能数量,那么我会寻找新工作。 careers.stackoverflow.com
如果PM不是您的经理,那么您需要让您的经理参与其中,让他们从上面的列表中向PM提供他们的选择。
答案 2 :(得分:1)
这个东西真的很难处理。这里真正的问题是你没有实际的过程。
答案实际上取决于组织中的政治情况以及你需要多大的能量来推动变革。
过去,我曾尝试将流程变更引入多个组织,这一直是一场斗争。但是,有可能。
我会看一下管理软件开发的一些方法。例如,我使用并推荐Scrum。
在快速变化的情况下,处理具有明确责任目标的短迭代可能真的很有帮助。您可能需要支持和管理您的项目经理,但听起来当前的“流程”显然不起作用,因此销售新流程实际上变得更加容易 - 您有可靠的业务案例需要改进。
坚实的流程将帮助您“推迟”不断变化的需求。快速的反动变化通常是组织方向和战略中更广泛问题的症状,在组织内解决这个问题符合每个人的利益。
答案 3 :(得分:1)
这是您作为开发人员将面临的主要挑战之一。
我过去使用过的一项很好的技巧就是提问。获得规范后,在其中找到需要最终用户澄清的内容。这总会减慢事情的速度,并增加管理者对风险的看法。
确保您的项目经理了解实施项目后期更改所涉及的风险。
答案 4 :(得分:0)
您和您的团队是否曾尝试与经理本人讨论此问题?这是你应该做的第一件事。
他可能没有那么多的开发过程经验,因此持续紧迫的截止日期和非常晚的主要更改。我见过这样的案例,那些无法发展的人却认为他们可以在PM做得更好 从坐着和他说话,可能会出现两件事,这取决于他的个性/专业性。他会接受你的观点,并尝试改变未来的情况,否则他将成为一个聪明的人并且不会放弃,在这种情况下值得将情况升级到更高的水平。我认为没有任何公司愿意接受失去的开发人员。
或者,他的经理可能在他身边。这是一个问题。如果没有任何结果,正如已经建议的那样,改变工作是公平的事情。