简述
刚进入职场时候，其实是四处碰壁，也就是所谓的情商不高所指，对自己没有什么规划，常常废了很大的劲却没有好的效果。工作久了之后，自己也成长了不少，也观察到身边一些优秀同事的做事方法，这里总结一下互联网公司常见解决问题的方法。
如何接需求
产品经理的需求过来，并不是照盘全收，一定要弄清楚产品的细节，对于有疑问的地方，一定要积极找产品沟通，对于现在不适合做的地方以及风险点，一定要找产品确认清楚，如果产品执意要做一些不明确或者现在不适合做的功能点，需要把这个风险上升给leader, 让leader参与决策。因为很多产品经理的工作就是尽快完成需求，而不是高质量稳定地完成需求，如何高质量和稳定的完成需求，是需要我们研发自己去把控的，这一点千万不要松懈，不然就是给自己埋坑。一定要学会质疑产品经理的需求，不要轻易被产品经理压工期，要给自己留些buffer。
如何分解任务
任何复杂的任务，只要确定可以做，将任务分解之后，就能够执行，所以分解任务非常关键。大任务分解成小任务，如果任务太多，自己处理不完，需要上升争取资源。每个小任务需要指派责任人，并且确定好完成时间。
任务处理的思考模型
对于一些复杂的系统，我们需要参考公司内部或者业界已有的解决方案，并且针对自己业务的特点去做定制。尽可能的去高度抽象，不要陷入具体的细节。尽可能抽象出一些模型出来去解决。一个任务往往能拆分成几个关键要解决的点，然后对这几个点分别找解决方案。
方案文档与执行计划文档
和相关的同事讨论出方案之后，需要将方案记录成文档。对于复杂的系统，再必要的时候还需要加上调研的排期，在调研期内完成关键技术难点的解决。当调研完成之后，需要写详细执行文档。其他新手，根据文档的步骤，能一步一步完成任务处理。
方案执行过程中
方案执行过程中往往会涉及到线上部署等，如果对业务可能有影响，需要周知，让相关人关注。对于线上部署的任务，过程中需要关注监控和告警，并且要能随时回滚。
方案执行，需要分阶段的，需要分阶段执行，这样更早出阶段性成绩，节奏感好，定好每个阶段的产出和完成时间。
比如下面是一个例子：
| 事项 | 完成时间 | 进度 | 备注 |
|---|---|---|---|
| 迁移方案可行性调研 | 0305 | 100% | |
| 迁移方案初稿 & 讨论 | 0312 | 100% | 【done】0307 整理出迁移步骤文档 -- jack 【done】0312 确认数据迁移过程中没有并发问题 -- july |
| 确定迁移方案 | 0318 | 100% | 【done】-0315 方案初稿部门内讨论 【done】0317 完成方案 【done】0319 组内同步 |
| 迁移工具准备 | 0327 | 20% | TODO: 【done】sql生成脚本 -- jack 【done】镜像生成 ... |
| 完成第一个数据迁移 | 0408 | - | - |
| 完成剩下所有数据迁移 | 0501 | - | - |
方案阶段性执行后总结
很多人以为一个任务完成之后，就算完了。其实，一个任务完成之后，需要做一下总结，尤其是多人参与的任务，总结的要点主要包括:
- 哪些遗留的，需要进一步确认和解决的
- 下一阶段计划需要外部支持的地方
- 做的不好的地方
执行后的总结起到承前启后的作用，其实是很关键的。
复盘
线上问题要及时处理，处理完之后，需要写一个复盘文档。一个比较好的复盘文档，需要包括几个部分:
- 问题描述
- 问题原因
- 定位过程
- 解决方案
- 经验总结
其中，定位过程要描述清楚什么时间（精确到分）什么人做了什么事情的过程。解决方案包括已做了的，和TODO。 其他几个部分也很重要。复盘的主要目的是为了避免将来重复出现类似的问题，索引一定要找到本质原因，经验总结要到位。
思考怎么做远比做事情本身重要
以前总觉的要抓紧时间做事情，往往做出来的事情质量不高，而且总是处于疲于奔命。有了一定经验之后，发现经验总结很关键，需要多思考关键点，多考虑一些细节点，返回问为什么和为什么这样做和不这样做，这样可以提高自己的思考能力，考虑问题也更全面。事情本身细化之后按部就班地做，其实很简单。
先总结这么多，后续待补充....
