关于提高工做效率的一点思考

最近参加了一个由TGO鲲鹏会组织线上技术交流活动，主办方邀请了一些大牛作技术分享，其中有个议题就是如何提升工做效率。听完各路大神的分享，而后恰好最近本身负责的项目出了一点问题，平时工做常常也会出现疲于应付的问题，根据高效这个议题，而后结合本身的工做经历，深入反思了一下，就像总结一点东西，督促本身。

1、能高效的工做，首先要有良好的精神状态

相信这一点，你们都知道，就不用多说了。最简单也最广泛方式就是保证睡眠（早睡，午睡），锻炼。没有头发的程序员是失败的程序员，，保持良好的做息，健康的生活习惯，才能有良好的精神状态。

2、良好的工做习惯

1. 关于时间

• 时间分片，作好计划：每段时间只作一件事，才能保持专一度，专一度才能保证效率，例如：不要同时解决测试提的bug,同时写代码或者写文档，思惟中断后再链接是须要时间回顾以前的思路的。
• 如何分片，如何排序：第一个问题顺序：要事第一，其后可按照优先级排序，第二个问题：分片的粒度，在开启新项目或新需求时，任务都会作拆分，可按照任务的粒度来执行，固然中间难免有一些会议，能够一天预留出一到两个小时做为临时会议或者沟通时间。
• 避免情绪波动：与产品测试沟经过程中，不免有一些意见不合，好比针对不合理需求，可寻求开发leader或领导介入，尽力去沟通，争取本身的最大化利益，若是最终没法改变，就妥协。好比：加需求，顶头上次都说时间不能顺延，那就只能加班了（若是长期如此，也能够走人了）。

2. 关于需求

• 有备而来，带着疑问沟通：需求评审前，仔细精读需求文档。
• 明确现状，评估可行性：回顾每个需求改动点的业务现状及其现有实现逻辑，明确新需求指望与现状的差距，作好开发时间评估和可行性评估，方便在会上提出需求不可行缘由以及可能存在的风险。
• 记录结果，防止纠纷：记下需求中的模糊点，在会上沟通好肯定好细节，并以文字的形式记录下疑问点的沟通结果，要求产品经理将疑问点写入公开的需求文档。
• 正确理解，相当重要：任什么时候候对需求有疑问，必须找产品沟通确认，正确实现需求才是最重要的，切不可没时间把事情作对，却又时间返工。

3. 关于会议

• 不参加不须要我说话的会：我不须要说话，基本会议与我无关，纯属浪费时间。
• 参加了就要高效： 凡是会议必有主题；凡是主题必有议程；凡是议程必有决议；凡是决议必有跟踪；凡是跟踪必有结果；凡是结果必有责任；凡是责任必有奖惩；凡是奖惩必须透明。最后一次会议达成共识，比面反复耗费时间。

4. 关于反馈

• 定时反馈进度：阶段性向leader或者PMO反馈开发进度，树立良好的作事风格，同时也可减小由于询问而被打断思路。
• 主动反馈，不要作反馈黑洞：遇到技术难点，及时与leader讨论解决方案；

5. 关于工做中被打断

• 来自项目经理的打断：同时是询问开发进度，按期反馈，主动反馈。
• 来自来自产品的打断：在审批阶段解决掉疑问，正式开发后只专一开发。
• 来自测试的打断：文档写详细，避免被询问打断，将他人带到本身的工做习惯中，避免被牵着走。

6. 关于面子

• 需求沟经过程中，有疑问就要问，切记由于很差意思，而不沟通，需求的正确执行是第一要务，不懂就要问，爱面子只会阻碍你的进步。

7. 关于工具

• 熟练掌握经常使用工具：快捷键，代码不全功能（如idea的live template可定制代码生成），减小鼠标键盘切换，保持连贯的思惟
• 重复工做脚本化：autohotkey,windows批处理文件
• 熟悉经常使用工具包：好比：Apache common,google guawa。

3、具体小习惯总结

1. 每日总结，下班总结工做内容，整理第二天需完成的内容。
2. 早到半小时，安排工做计划，对一天进行规划
3. 在提测前，花一天时间总体review代码，对比master与develop,总体评估风险点，并优化代码。