Some downtime is necessary after reaching major milestones. People need to relax and decompress. Pushing on just carries the stress and fatigue forward and the team won't be working anywhere near their potential.
Give everyone a couple days to a week off and let them come back fully refreshed and ready to continue.
I think the key is when you say the remaining tasks are more tedious than glamorous. Yep life is like that but many developers don't want to work on tedious. None the less as the lead, it is your reponsibility to determine what tasks need to be done and assign them to people to do. Same as with the more interesting tasks, maybe even more important (someone will almost always step up to do the interesting stuff, not so much with the tedium).
So assign your tasks, give them their deadlines and follow-up on the progress they are making. If you have any of the more interesting tasks left, don't let anyone have one of those to do until he or she has completed his share of the tedium. In fact dangle the interesting tasks left as a reward for getting the tedium done faster or doing the most of it.
If you don't have any more interesting tasks left, thn maybe you can generate some competition to get the rest of the stuff done.
It's ok to be slack for a few days after a major push, but if it lasts more than a week, I think you need to get the team together and talk about what needs to done to fix the slacking.
Do something, other than work, as a team. Go to lunch, happy hour, laser tag, anything you can do as a group that is not work. A short break from stress can be a huge relief, and hopefully can reenergize your team for the final push.
I also strongly believe in "slackweek". If the deadline for the entire project isn't too close: just let everyone do what they want for a period of time. Could be write some tests here, align some stuff in the gui, read up on the latest in bla, whatever. Up to you if it has to be work on that specific project or just something useful overall.
THEN, you have a big "launch" meeting where you talk vision and goals for the remaining third - big picture stuff, and get everyone aligned again. I'm assuming the stuff left is really needed to give the customer a complete product so that it can be motivated for.
Add an easter egg! It doesn't improve the core project, but it helps give developers a sense of ownership.
Also, it can be helpful to set aside time for "pet peeve" cleanup. This gives developers a chance to fix nagging issues that are important to them. This helps improve the project, and at the same time allows the developer to make progress with something that is important to them. It helps keep the excitement level up.
Are there clear deadlines/milestones coming up soon? That would be something to consider as having a target date can help provide some focus.
The momentum being lost, does it tie back to people just being burned out, not as motivated as they were before or the work becoming much different, e.g. working out specifics on vague requirements rather than the cool parts that are done now?
One of the things Agile gets you is a finer focus on where you stand, what you've done, and what's left to do, within the next few weeks. There are concepts of "backlog" (what has to get done) and "velocity" (how fast are things getting done). Since each iteration is typically about a month, it's very clear to see when the team is not working at the projected/required rate, or working too hard. You might be able to borrow some concepts from Scrum for these purposes.
A more straightforward solution is to remind them that if they keep working at a reasonable pace, there's no end-of-milestone crunch time that makes everyone's life hell.
发布评论
评论（8）
达到主要里程碑后，需要一些停机时间。人们需要放松、减压。继续前进只会带来压力和疲劳，团队将无法发挥其潜力。
给每个人几天到一周的休息时间，让他们回来时精神焕发，准备继续。
Some downtime is necessary after reaching major milestones. People need to relax and decompress. Pushing on just carries the stress and fatigue forward and the team won't be working anywhere near their potential.
Give everyone a couple days to a week off and let them come back fully refreshed and ready to continue.
告诉他们你只需要 3 个人就能完成这个项目。
Tell them you only need 3 people to finish the project.
我认为关键是当你说剩下的任务比迷人更乏味时。是的，生活就是这样，但许多开发人员不想从事乏味的工作。尽管如此，作为领导者，您有责任确定需要完成哪些任务并将其分配给人们来完成。与更有趣的任务一样，甚至可能更重要（几乎总是有人会去做有趣的事情，而不是单调乏味的事情）。
因此，分配你的任务，给他们最后期限，并跟进他们所取得的进展。如果您还剩下任何更有趣的任务，请不要让任何人完成其中一项任务，直到他或她完成了他或她那份乏味的工作。事实上，把剩下的有趣任务作为更快完成单调工作或充分利用它的奖励。
如果你没有更多有趣的任务了，那么也许你可以产生一些竞争来完成剩下的事情。
在一次重大推动之后，懈怠几天是可以的，但如果持续超过一周，我认为你需要让团队聚集在一起，讨论需要采取哪些措施来解决懈怠问题。
I think the key is when you say the remaining tasks are more tedious than glamorous. Yep life is like that but many developers don't want to work on tedious. None the less as the lead, it is your reponsibility to determine what tasks need to be done and assign them to people to do. Same as with the more interesting tasks, maybe even more important (someone will almost always step up to do the interesting stuff, not so much with the tedium).
So assign your tasks, give them their deadlines and follow-up on the progress they are making. If you have any of the more interesting tasks left, don't let anyone have one of those to do until he or she has completed his share of the tedium. In fact dangle the interesting tasks left as a reward for getting the tedium done faster or doing the most of it.
If you don't have any more interesting tasks left, thn maybe you can generate some competition to get the rest of the stuff done.
It's ok to be slack for a few days after a major push, but if it lasts more than a week, I think you need to get the team together and talk about what needs to done to fix the slacking.
作为一个团队，除了工作之外，做一些事情。去吃午餐、欢乐时光、激光枪战，以及任何你可以作为一个团队做的与工作无关的事情。暂时摆脱压力可以带来巨大的缓解，并有望为您的团队重新注入活力，为最后的冲刺做好准备。
Do something, other than work, as a team. Go to lunch, happy hour, laser tag, anything you can do as a group that is not work. A short break from stress can be a huge relief, and hopefully can reenergize your team for the final push.
我也坚信“slackweek”。如果整个项目的截止日期不是太近：就让每个人在一段时间内做他们想做的事。可以在这里编写一些测试，在 GUI 中对齐一些内容，阅读 bla 中的最新内容，等等。取决于您是否必须在特定项目上工作或只是总体上有用的东西。
然后，您将召开一次大型“启动”会议，讨论剩下的第三部分的愿景和目标——大局，并让每个人再次保持一致。我假设剩下的东西确实需要为客户提供完整的产品，以便激发他们的兴趣。
祝你好运！
I also strongly believe in "slackweek". If the deadline for the entire project isn't too close: just let everyone do what they want for a period of time. Could be write some tests here, align some stuff in the gui, read up on the latest in bla, whatever. Up to you if it has to be work on that specific project or just something useful overall.
THEN, you have a big "launch" meeting where you talk vision and goals for the remaining third - big picture stuff, and get everyone aligned again. I'm assuming the stuff left is really needed to give the customer a complete product so that it can be motivated for.
Good luck!
添加复活节彩蛋！它不会改进核心项目，但有助于给开发人员一种主人翁感。
此外，留出时间来清理“烦人的事”也很有帮助。这使开发人员有机会解决对他们来说很重要的棘手问题。这有助于改进项目，同时允许开发人员在对他们来说重要的事情上取得进展。它有助于保持兴奋程度。
Add an easter egg! It doesn't improve the core project, but it helps give developers a sense of ownership.
Also, it can be helpful to set aside time for "pet peeve" cleanup. This gives developers a chance to fix nagging issues that are important to them. This helps improve the project, and at the same time allows the developer to make progress with something that is important to them. It helps keep the excitement level up.
很快就会有明确的最后期限/里程碑吗？这是值得考虑的事情，因为设定目标日期可以帮助集中注意力。
动力的丧失，是否与人们精疲力尽、不再像以前一样有动力，或者工作变得大不相同，例如根据模糊的要求制定具体细节，而不是现在完成的很酷的部分？
Are there clear deadlines/milestones coming up soon? That would be something to consider as having a target date can help provide some focus.
The momentum being lost, does it tie back to people just being burned out, not as motivated as they were before or the work becoming much different, e.g. working out specifics on vague requirements rather than the cool parts that are done now?
敏捷给你带来的好处之一是在接下来的几周内更好地关注你的立场、你已经做了什么以及还需要做什么。有“待办事项”（必须完成的事情）和“速度”（完成事情的速度有多快）的概念。由于每次迭代通常约为一个月，因此可以非常清楚地看到团队何时没有按照预计/要求的速度工作，或者工作过于努力。您也许可以从 Scrum 借用一些概念来实现这些目的。
一个更直接的解决方案是提醒他们，如果他们继续以合理的节奏工作，就不会有让每个人的生活陷入困境的里程碑结束的关键时刻。
One of the things Agile gets you is a finer focus on where you stand, what you've done, and what's left to do, within the next few weeks. There are concepts of "backlog" (what has to get done) and "velocity" (how fast are things getting done). Since each iteration is typically about a month, it's very clear to see when the team is not working at the projected/required rate, or working too hard. You might be able to borrow some concepts from Scrum for these purposes.
A more straightforward solution is to remind them that if they keep working at a reasonable pace, there's no end-of-milestone crunch time that makes everyone's life hell.