我有时候在思考，到底自己还有哪些缺点和坏习惯？就算是自己找到了，自己有没有有效的方法进行纠偏？
我一天的工作效率到底是多少？
领导分配给我们组任务是负责产品中心项目和任务调度项目，今年下半年又有一个运维和开发工作更重的API平台。
我和一个有接近一年经验的毕业生暂时负责这三个项目。
这是很正常的现象，随着我们的经验的积累同时在公司的时间越长，负责的业务也会慢慢多了起来，
一方面是自己要成长，另一方面是公司也要你成长。
一点疑惑
开发写代码，处理线上问题，开会，对接系统，管理项目，对下沟通，对上沟通，平行沟通 ......
这些事情在一天的时间里来回穿插，不仅每天事情要安排得当，而且从时间线上来看，每一类事情是有发展的，并且最好还有一些反馈和回报。
很长一段时间里，我都是每天做着近期比较忙的项目，忽略了其他项目。导致从时间上来看，只有一个项目在进展，其他的都在停滞不前。
每次我的想法就是——这个项目需要统计一下接口使用情况，了解业务，了解系统影响面积。
哎呀，这个估计需要一段连续的长的时间，现在忙起来没这么多连续时间给这个项目，等有时间再说吧。这个也是一个重要不紧急事情。
以前我的理解，只要是重要不紧急的，其实可以往后放，这个想法看上去也对，先处理重要紧急。但是把所有的时间都规划给了重要紧急，导致了其他重要不紧急事情得不到进展。
长期以来，我们年中规划的重要的事情和安排，因为一些重要紧急的事情被冲散，原来的计划被打破，本来规划的项目得不到进展。
而且我所谓的重要紧急是真的重要紧急？是不是我自己理解的重要紧急本身就是错误的？
重新梳理
我给自己重新制定了几个小原则。争取拿到身边的事情是真正的优先级。
问题需求类
* 统一问题出口入口，其他渠道汇总过来的问题和需求，自己简单了解后，交给产品决定，根据产品之间的讨论进行优先级处理。
* 用户层面反馈的问题，优先解决，从用户视角来看，我们系统出现问题就会打破用户对我们的信任等级。
* 响应时间，与具体对接人商讨一个具体交付时间，在时间内相应。不能拖延。契约精神。
* 定期复盘汇总问题和需求解决情况，高频问题是是否可以程序实现？（每周五例会，重要的事情看情况单独开会）
* 分工，将工作组内分工，同时保持用户运维工作都必须掌握。建群，防止请假，也能在第一时间进行响应。
重要不紧急
* 相对以上的相应用户、问题处理、需求开发。重要不紧急的事情也要定期有进展。比如：每天拿出半小时处理，每周有一天时间重点处理
* 尝试使用OCR进行这种重要不紧急的项目进展跟踪。最好是打印出来。
O：产品中心接口数据流转统计
K1：项目群A使用系统接口统计，以及数据在业务系统中的流转情况
K1：项目群B使用系统接口统计，以及数据在业务系统中的流转情况
R ：8月23号下班前，完成统计，并输出数据流转图
* 锻炼组内成员，慢慢培养一些任务的决策思想和决定权。
比如：电子签章的开发，文档有37个接口，需要从中抽取满足我们需求的接口，并且串成流程，开发落地。
这整个事情交给了组内这个刚刚毕业不满一年的女生。做的很棒。后面会再细说。
关于效率
从上面看，我们看上去忙，外人看我们好像项目很重要很忙很用户，我们也有这种错觉，我们对接这个对接那个，搞得每天不用笔记录下处理的事情，每天总结时候瞬间脑子空白，记不起干了啥。
是否是真的很忙？这也是我写这篇总结的初衷。
在前段时间阅读了 《软技能-代码之外的能力》这本书给了很大的反思和启发。
番茄工作法
在半年前，我也尝试过番茄工作法，发现效率低下，无法适应也不能很好使用。
读完这本书我的这些问题已经不再是问题。因为书中已经将这些问题一一解答。
是的，在尝试的初期你会效率低下，因为你要适应一种新的工作模式和工具.
同样，你会一段时间内得不到你期望的反馈和效果，导致烦躁和不安。
最后，在经历过这样一个短暂的适应期后，你会发觉它是有效果的。并逐渐改进你的效率。
一点统计数据
不是很系统，安排也很零散，但是我打算继续使用，从中总结一套符合我自身工作方式的番茄法。
上周开始我觉得25分钟一个番茄，太短，我调整成55分钟，效果还不错。
我有预感，后面我可能还会调整番茄时间，在我熟练了番茄工作和任务再分解之后，时间会更有效利用。
我也使用番茄，在我们每天的早晨和晚上以及中午吃完饭午休前，将时间分割来学习扩展深入知识：比如linux，比如go，比如每周锻炼。
我也将自己的系统换成了linux，每天早起看点。长期积累起来。
番茄感悟
以前总以为自己八小时都在工作，其实不然，真的保持4小时的工作时间也算是很高效了。
有一天印象深刻，那一天我拿出30分钟做了当天的任务列时，然后开始工作。
当天插入的临时任务较少（感觉上），所以当天梳理了很多的东西，也输出了很多的图。为后面项目规划做为分析基础。
但是会看番茄钟 应该是执行了四个55分钟的番茄，我那四小时去哪里了？我真的很模糊，实在想不起那四小时用在了哪里。时间去哪了？
开会？培训？讨论？对接？ --也许吧？
当天就这4个番茄钟，临下班前我就感觉有点疲，有种脑子转不动很累的感觉。
下周继续使用，摸索更有效的使用方式。
一些工作反思
工作几年后，会遇到发展瓶颈，怎么去突破这些瓶颈。
我发现不得不尝试一些新的学习方式，思考方式，以及吸收渠道。
我们现阶段的学习吸收方式已经远远满足不了我们的成长需求。甚至说我们的学习方式已经满足不了用户市场的需求。
所以有更多的互联网以及专业人士，来闯到、授业、解惑。
比起很早之前的互联网，已经不是稍微懂点开发就会发展得很好，
以前我们从前段写到后端甚至是干到数据库，开发运维一起挑。
现在已然分为了UI，前端，后端，DBA。公司一直也在招聘这些在一定方向上专业的人，更专业的人。
将这些资源调配组装，来快速适应市场需求，尽可能避免技术能力带来的制约。
不仅仅是技术
其实不仅仅是技术，我们开发在工作几年后会发现一个很大的发展制约，就是我们的沟通能力和管理能力
即使我们没有管理title，已然会多多少少有带人的任务，也会随着负责业务的逐渐累积，沟通也越来越多。
逐渐地技术真的就是一种实现业务的工具而已。更多的是在沟通理解和带人，让业务可以转得更快。
公司对人才的需求也会有更多的要求，比如技术、学习能力、沟通能力、抗压能力等
这些软能力，间接地影响着我们的发展，影响着公司的发展。
大浪淘沙，我们向前发展需要更高的标准和专业能力。所以这些催化剂让我们焦虑，让我们无所适从。
确定好目标，拆分目标，使得每个目标可以短期内能看见效果和成长，才能有更强的动力向前。
读书
最近在看技术实际的同时，我也读了基本非技术书籍。《如何高效学习》《原则》。
在学习技巧方面，我发现自己有时避重就轻，常常迷失了方向。后面我会按照《如何高效学习》书中的经验，结合实际情况，来提高自己的学习能力。
《原则》这本书刚读到300页，书中讲述了作者很多的经历，尤其是失败的经历。作者不断地反思，不断地尝试修改，从中总结出了自己的原则。
在长时间的实践中验证这些原则，并形成了一套自己的模型。将这些模型通过计算机技术落地成为系统。
在接下来的社会发展中，通过输入这些社会参数，模型验证输出结果。作者并根据自己长久以来的一些原则，来平衡这种模型的输出。
保持一定的进攻性，同时保留一些防御性。不盲目自信。逐渐接受其他人的不同意见，并能从他们的角度去验证他们的结论。
以前自己总是沉醉于技术书籍中，觉得技术就是一切，当然技术依然要保持。同时更多地要扩展自己的视野和其他领域知识。
把读书算成一种乐趣，就算是对职业生涯没有作用。我就当成将来能对自己的孩子可以有更多的知识储备和视野来教育我的小孩。