It's true that no matter what you do, you're human and you'll make mistakes or miss things. That said, regular changes to your requirements are most often the result of either poor requirements or poor develoment process, or both.
Some Design Up Front?
Business analysis is regularly given the short shrift by developers, project managers, etc. Most devs just want to start hacking away on day 1, and most PMs love to let them: "Wow, we can move from the project initiation phase to the construction phase in 1 day without any of that ridiculous business analysis stuff taking up time! That'll look great for completion bonuses!" But remember that the PM's primary job is to keep the project under control (on time and on budget) ...not necessarily to make users happy and certainly not to make developers happy. That's not to say they are totally heartless; good PMs will achieve their goals by enforcing scope control and fostering communication, both of which are helpful.
But taking the time to really think about what's needed and stepping through possible scenarios can make a serious difference in the issues you're dealing with.
If you have made an effort to do thorough business analysis and you're still ending up with last minute changes, then perhaps your problem is another classic challenge: disengaged users. Your subject matter experts are your top weapon in dealing with and identifying those corner cases. If you have users that are not engaged in the analysis process, get better subject matter experts.
It's also possible users are disengaged because they are too busy doing their regular work. In that case it's a management issue and they need to be given instructions that project participation is part of their jobs; that's hard sometimes because often the same management that told you to "get it done yesterday" is the same group of knuckleheads that is expecting the project to happen magically with no hiccups and without any resources (they are common in that they don't understand the complexities of custom software development and assume it is easy). If management is clueless and won't change...well, you have to either work overtime and deal with the issues you've described, or get a new job.
Can Agile Help?
It'd sure be nice if your users would tell you about those corner cases earlier rather than later, right? This is related to what Toby Hede discussed in his post. Perhaps a methodology that gets the software in front of the users as soon as possible, even in an unpolished state, can trigger feedback sooner. That was one of the inspirations for all the agile concepts. The creators were tired of dealing with the issues you describe and they also realized that if management and users weren't going to change, then maybe the development could. It's still development, but there's an emphasis on getting early feedback through a variety of techniques (have subject matter experts co-located with the dev team, getting rough prototypes into user hands sooner, pair programming to captalize on developer experience, and lots more). All this is because it's understood we're human and we're going to miss things.
Finally, you mention you're trying to make the system extensible to help with the rapid changes, but how? Are you separating presentation logic from business logic? Are you encapsulating business logic in objects, partitioned appropriately to minimize dependencies and coupling? All of those things are tough to do and can take time to plan and build.
You're not alone, by the way. Lots (maybe all) shops have these challenges.
This stuff is really challenging to deal with. The real problem here is that you don't actualy have a process.
The answer really depends on the political situation in your organisation and how much eneergy you have to drive change.
In the past I have attempted to introduce process change to several organisations and it has always been a struggle. It is possible, however.
I would have a look around at some methodologies for managing software development. I use and recommend Scrum, for example.
In a situation with rapid change, working on short iterations that have clearly accountable goals can be really helpful. You will probably need to champion and manage your Project Manager, but it sounds like the current "process" is clearly not working, so selling a new process actually becomes easier - you have solid business case for improvement.
A solid process will help you "push-back" on changing requirements. Rapid reactionary change is often a symptom of broader issues in organisational direction and strategy and it is in everyone's interest to fix this problem within the organisation.
This is one of the major challenges you will face as a developer.
One good technique I've used in the past is to ask questions. When you get the specs, find something in them which needs clarification from the final users. This always slows things down, and raises the possibility in managers minds of risks.
Make sure that your project manager knows the risks involved in implementing late changes for a project.
Have you and your team tried discussing about this with the manager himself? That's the first thing you should do.
He might not have that much experience with the development process, hence the constant tight deadlines and very late major changes. I've seen such cases, people who couldn't develop but thought they could do a better job at PM. From sitting and talking to him there could come out two thing, depending on his personality/professionalism. He'd accept your points and try change the situation for the future or he'll be a smartboy and won't give in a bit, in which case it is worth escalating the situation to a higher level. I don't think there is any company that will happily accept losing developers.
Alternatively, his manager could be all over him. And that's a problem.
If nothing works out, as already suggested, changing the job is a fair thing to do.
发布评论
评论（5）
确实，无论你做什么，你都是人，你都会犯错误或错过一些事情。也就是说，对需求的定期更改通常是由于需求不佳或开发过程不佳或两者兼而有之的结果。
预先进行一些设计？
业务分析经常受到开发人员、项目经理等的忽视。大多数开发人员只是想在第一天就开始破解，而大多数 PM 喜欢让他们：“哇哦，我们可以在 1 天内从项目启动阶段进入构建阶段，而不会占用任何可笑的业务分析内容，这对于完成奖金来说看起来很棒！”但请记住，PM 的主要工作是控制项目（按时、按预算）……不一定要让用户满意，当然也不一定要让开发人员满意。这并不是说他们完全无情；而是说他们完全无情。优秀的项目经理将通过加强范围控制和促进沟通来实现他们的目标，这两者都是有帮助的。
但花时间认真思考需要什么并逐步解决可能的情况可以对您正在处理的问题产生重大影响。
敏捷可以提供帮助吗？
如果您的用户能够尽早而不是稍后告诉您这些极端情况，那肯定会很好，对吧？这与 Toby Hede 在他的帖子中讨论的内容有关。也许一种能够尽快将软件呈现在用户面前的方法，即使是在未完善的状态下，也可以更快地触发反馈。这是所有敏捷概念的灵感之一。创建者厌倦了处理您所描述的问题，他们也意识到，如果管理和用户不打算改变，那么也许开发可以改变。它仍然是开发阶段，但重点是通过各种技术获得早期反馈（让主题专家与开发团队同处一地，更快地将粗略原型交到用户手中，结对编程以充分利用开发人员的经验，等等） 。所有这一切都是因为我们知道我们是人类，我们会错过一些东西。
最后，您提到您正在尝试使系统可扩展以帮助应对快速变化，但是如何实现呢？您是否将表示逻辑与业务逻辑分开？您是否将业务逻辑封装在对象中，并进行适当的分区以最大限度地减少依赖性和耦合？所有这些事情都很难做到，并且需要时间来规划和构建。
顺便说一句，你并不孤单。很多（也许是所有）商店都面临着这些挑战。
It's true that no matter what you do, you're human and you'll make mistakes or miss things. That said, regular changes to your requirements are most often the result of either poor requirements or poor develoment process, or both.
Some Design Up Front?
Business analysis is regularly given the short shrift by developers, project managers, etc. Most devs just want to start hacking away on day 1, and most PMs love to let them: "Wow, we can move from the project initiation phase to the construction phase in 1 day without any of that ridiculous business analysis stuff taking up time! That'll look great for completion bonuses!" But remember that the PM's primary job is to keep the project under control (on time and on budget) ...not necessarily to make users happy and certainly not to make developers happy. That's not to say they are totally heartless; good PMs will achieve their goals by enforcing scope control and fostering communication, both of which are helpful.
But taking the time to really think about what's needed and stepping through possible scenarios can make a serious difference in the issues you're dealing with.
Can Agile Help?
It'd sure be nice if your users would tell you about those corner cases earlier rather than later, right? This is related to what Toby Hede discussed in his post. Perhaps a methodology that gets the software in front of the users as soon as possible, even in an unpolished state, can trigger feedback sooner. That was one of the inspirations for all the agile concepts. The creators were tired of dealing with the issues you describe and they also realized that if management and users weren't going to change, then maybe the development could. It's still development, but there's an emphasis on getting early feedback through a variety of techniques (have subject matter experts co-located with the dev team, getting rough prototypes into user hands sooner, pair programming to captalize on developer experience, and lots more). All this is because it's understood we're human and we're going to miss things.
Finally, you mention you're trying to make the system extensible to help with the rapid changes, but how? Are you separating presentation logic from business logic? Are you encapsulating business logic in objects, partitioned appropriately to minimize dependencies and coupling? All of those things are tough to do and can take time to plan and build.
You're not alone, by the way. Lots (maybe all) shops have these challenges.
首先不要让他们强加最后期限。
你有 2 个选择
如果 PM 是你的经理或者有权规定截止日期+功能数量，那么我会寻找一份新工作。 careers.stackoverflow.com
如果 PM 不是您的经理，那么您需要让您的经理加入并让他们向 PM 提供他们的信息上面列表中的选项。
Don't let them impose the deadline in the first place.
You have 2 options
If the PM is your manager or has the authority to impose deadlines + number of features, then I'd be looking for a new job. careers.stackoverflow.com
If the PM isn't your manager then you need to get your manager on board and have them give the PM their options from the above list.
这东西处理起来确实很有挑战性。这里真正的问题是你实际上没有流程。
答案实际上取决于您组织中的政治局势以及您有多少精力来推动变革。
过去，我曾尝试向多个组织引入流程变革，但这一直是一场斗争。然而，这是可能的。
我会研究一些管理软件开发的方法。例如，我使用并推荐 Scrum。
在快速变化的情况下，进行具有明确责任目标的短期迭代确实很有帮助。您可能需要支持和管理您的项目经理，但听起来当前的“流程”显然不起作用，因此销售新流程实际上变得更容易 - 您有可靠的改进业务案例。
可靠的流程将帮助您“推迟”不断变化的需求。快速的反应性变革通常是组织方向和战略中更广泛问题的征兆，在组织内解决这个问题符合每个人的利益。
This stuff is really challenging to deal with. The real problem here is that you don't actualy have a process.
The answer really depends on the political situation in your organisation and how much eneergy you have to drive change.
In the past I have attempted to introduce process change to several organisations and it has always been a struggle. It is possible, however.
I would have a look around at some methodologies for managing software development. I use and recommend Scrum, for example.
In a situation with rapid change, working on short iterations that have clearly accountable goals can be really helpful. You will probably need to champion and manage your Project Manager, but it sounds like the current "process" is clearly not working, so selling a new process actually becomes easier - you have solid business case for improvement.
A solid process will help you "push-back" on changing requirements. Rapid reactionary change is often a symptom of broader issues in organisational direction and strategy and it is in everyone's interest to fix this problem within the organisation.
这是您作为开发人员将面临的主要挑战之一。
我过去使用过的一项好技巧是提问。当您获得规格时，请在其中找到需要最终用户澄清的内容。这总是会减慢事情的进展，并增加管理者思考风险的可能性。
确保您的项目经理了解实施项目后期变更所涉及的风险。
This is one of the major challenges you will face as a developer.
One good technique I've used in the past is to ask questions. When you get the specs, find something in them which needs clarification from the final users. This always slows things down, and raises the possibility in managers minds of risks.
Make sure that your project manager knows the risks involved in implementing late changes for a project.
您和您的团队是否尝试过与经理本人讨论这个问题？这是你应该做的第一件事。
他可能在开发过程方面没有那么多经验，因此最后期限总是很紧，并且重大变更很晚。我见过这样的案例，那些无法发展但认为自己可以在 PM 方面做得更好的人。
坐下来与他交谈可能会产生两件事，具体取决于他的个性/专业精神。他会接受你的观点并尝试改变未来的情况，否则他会成为一个聪明的男孩，不会做出一点让步，在这种情况下，值得将情况升级到更高的水平。我认为没有哪家公司会欣然接受失去的开发者。
或者，他的经理可能会全心全意地关注他。这是一个问题。
如果没有任何进展，正如已经建议的那样，换工作是一件公平的事情。
Have you and your team tried discussing about this with the manager himself? That's the first thing you should do.
He might not have that much experience with the development process, hence the constant tight deadlines and very late major changes. I've seen such cases, people who couldn't develop but thought they could do a better job at PM.
From sitting and talking to him there could come out two thing, depending on his personality/professionalism. He'd accept your points and try change the situation for the future or he'll be a smartboy and won't give in a bit, in which case it is worth escalating the situation to a higher level. I don't think there is any company that will happily accept losing developers.
Alternatively, his manager could be all over him. And that's a problem.
If nothing works out, as already suggested, changing the job is a fair thing to do.