在项目接近尾声时,你如何度过不可避免的激励性“衰退”?[关闭]

不要把所有“无聊”的部分都放在最后——确保每个组件在项目中尽早通过回归测试和文档工作。

这就是说,过去几周仍将涉及到追查真正难以发现的错误、处理最后一秒的需求变更、最终确定文档,以及通常把这该死的事情从门上弄出去。我的方法只是把它吸进去:放下你的头,知道越快完成,你就越快可以开始对所有低优先级,更有趣的事情,已经排在当前版本后面。

除了安排客户在发布前度假之外,您不能完全避免最后的需求/文档更改。或者让自己处于像苹果和谷歌这样的主导地位,这样客户就不知道发布了什么。

你“应该”尽早追踪难以捉摸的错误(我的意思是那些很难重现的错误,以至于你没有一个一致的测试用例),因为你无法估计它们需要多长时间才能修复。但是在实践中,随着项目的进行,他们中的一些人会变得不那么难以捉摸,或者最终成为另一个已知问题的副作用,所以平均来说,给他们一个有限的机会来节省时间。这样做的缺点是,在接近尾声的时候,会剩下一些。不过,如果超过两个,你就错了。

在一个重要的最后期限之后,休息一下,做你觉得最有趣的事情,这是一个避免长期疲劳的好方法。即使你最终放弃了大部分,因为你跳过了一些困难的计划,你也会使自己更有效率。

使用测试驱动开发。考试不及格总是很有动力的。

让一些测试人员放松一下。没有什么比看到人们使用你的有趣的东西并发现明显的改进更能激励人的了。

对自己重复: 我的代码在签入之前不存在。

或者,如果不使用版本控制,“直到发布”或“直到发布”。

你也可以使用恐惧,说如果你不完成并启动它,其他人会。

通常我会告诉自己 让事情在现实世界中运作 也很有趣,因为你的代码在那里 信用 或将 改进 通过发现的错误和功能请求。

不要先做所有有趣的部分。

我总是在最后留下一点得体的东西,并且严格要求先完成无聊的部分,以此激励自己去做无聊的代码。

“如果你不完成并启动它,其他人会。”

以前告诉过我自己。不过,有时候休息几个小时,然后再回来休息是件好事。那你就不会像以前那样筋疲力尽了。

我试着推广bug日/夜的概念。设定一个要解决的错误/问题的目标,当你达到这个数字时,每个人都可以出去(付费!)比萨饼/啤酒。保持团队的士气,在一个无聊的时期作为一个焦点。

此外,您还可以在这个概念中添加奖品/CUDOS,以获得最佳的重构或性能改进等。

我同意这很难。唯一能让我坚持下去的是,在看到它完成/发货/在客户手中之后,我会有一种感觉。

我的动机就是完成它。就像一个接一个的人说的,你只要蹲下来做就行了。这都是优先考虑的问题。优先权越快被排除在外,你越快能回到有趣的事情上。

1. 试着看看你能不能休息一两天,然后恢复精神。
2. 不要把无聊的东西留到最后
3. 自己测试一下
4. 确保你的饮食/运动/睡眠等水平不会降低。
5. 告诉其他人你有点沮丧,你能把工作区换一天吗?

一般来说,当你完成了90%的工作,它就快结束了,你只需要完成最后90%:-)

一直想一想,你会发现这是一个很长的路,直到它的工作。

我很乐意做一些有创意的有趣的节目。

但在那之后,我想让用户满意。