快，是当下的工作主旋律。拿到任务，快刀斩乱麻，达成目标交差。甚至同时处理多个事务，一天到晚忙前忙后。一旦闲下来，便觉缺少了存在感。这未必是什么好事，事情做得比较浅，经验不能有效的积累，最终其实还是快不了，还反而让情绪受工作牵制。相对于这种做事做到恰到好处的做法，我更喜欢要做就往大了做。
从一个任务的表面来看，做出结果就算完事，这是结果导向。你要一份报告，我就给你一份报告。解一个Bug, 就保证这个Bug正常，扩展一下没有问题就好。如果真得很紧急，这样做是理所当然，这时候慢下来就不合适了。但只要有机会(可以向上沟通确认, 没时间就自己挤吧!)，就努力让自己慢下来，好好的从系统面，从整体思考一下，遇到一些细节时，都尝试去理解一下。也就是想想，除了解决问题，我自己能从其中得到什么提高， 产品能做什么改变。总之有机会就要尝试慢下来，让事情更具广度和深度，更具系统性。比如做一件事的时候，先分清轻重缓急，再理解任务的目标和目的。
比如遇到一个页面开发的问题，它足可以发散出很多的维度。如果有时间，我就喜欢用如下的方式入手:
目标(Target)是解决特定问题，目的(Purpose):提高对产品及代码的理解，避免相似问题，提高产品质量。
1. 对于这个问题所属的功能，先总体了解这个功能中主要的类和流程。
2. 了解这个问题有没有标准规范，如果有就粗略的读一下，也了解一下相关概念的标准定义。
3. 别人是怎么做的? 比较一下相似产品的功能。写些测试页面验证一下。
4. 用户的期望是什么?
5. 从系统层面制订方案，而不是简单针对所要解决的问题，再发起讨论。
6. 如何避免类似问题? 如何验证问题？
7. 是否需要再深入理解? 有没有可能做些创新? 有没有申请专利的机会？
这也就是工作中尽量把事做大一点的思考方向，即使面对一个Bug, 也要发掘进一步优化创新的空间。事实上也只有深入到细节，才更有机会发现优化和创新的机会，根本不需要依赖从一个高大上的项目中来提高自己。 因为技术工作不断的细化，以较小的学习小组的形式促进大家的学习提高会更加有效，较大规模的技术培训收益很低。再细致一点，个人的学习却是最具成效的，但是这个习惯需要引导。
现在工作经验的价值已经远不如学习力的价值，关注于提高学习力远比关注于参于了什么项目有价值得多，工作中既要关注结果，也要关注过程和方法！
转载请注明出处: http://blog.csdn.net/horkychen