在处理项目时,在对有趣的部分进行编码后,我的动机会严重减少.你怎么做才能克服这个问题？
不要将所有"无聊"位留在最后 - 确保每个组件在项目中尽早使用回归测试和文档.
这就是说,在过去几个星期仍然会涉及追逐真正难以理解的错误,处理最后一秒需求的变化,最终确定的文件,一般让那该死的东西出了门.我的做法是把它吸上来:把你的头下来,知道它的完成越早,越快,你可以在所有优先级较低的启动,已经排队的当前版本背后更有趣的事情.
您不能完全避免最后一刻的要求/文档更改,除非安排您的客户在发布之前全部休假.或者让自己处于像Apple和Google这样的主导地位,这样客户就不会对发布有任何了解.
你"应该"追难以理解的错误(我指的那些如此难以重现,你没有一个一致的测试情况)早,因为你无法估计他们会需要多长时间才能解决.但在实践中作为该项目的推移他们的一定比例将变得不那么难以捉摸的,或变成是另一种已知的问题的副作用,让你给他们一个机会有限,这样做节省时间平均.这样做的缺点是,到最后会有一些剩下的.但是,如果有超过两个,你做错了.
在一个重要的截止日期之后做一个短暂的"休息"来做任何你觉得最有趣的事情,这是避免长期倦怠的好方法.即使你因为跳过一些困难的计划而最终把大部分都扔掉了,你也会让自己更有成效.
京公网安备 11010802040832号 | 京ICP备19059560号-6 