没有规矩，不成方圆。说的正是这个理儿。
最近工作中经常被教导缺少套路，做事没有自己的方法论，眉毛胡子一把抓，到头来却丢了芝麻也丢了西瓜。所做的工作有很大的主观性，怎么做，什么时候做，都没有要求，只不过做成什么样要经过评审。刚接手这个工作的时候确实被牵着鼻子走，别人说做成什么样就是什么样，没有按照别人说的来做就是有问题；完全忘记问一句为什么要做成这个样子，需求背景是什么，需求作者想要做成什么样。经历了几个月，严格来说已经6个月了，却也没有深入骨髓的理解其中精华。经过了几次洗脑，也开始并强迫自己走上套路方法论的路上展开工作。
说到底，工作和生活的大半个部分都可以用套路来应对，用自己的方法论搞定很多事情。比如，对应于我现在的工作，从以下几个方面就可以cover住90%的事情:
（1）需求是什么。需求来源于什么，需求背景是什么，最终用户想要实现成什么样，他们想要怎么使用，他们的收益是什么。搞懂了需求，也才知道要做什么，也才能判断方案和实现是否满足要求。针对实现，有没有现有方法能满足用户的需求，如果有类似的功能，为什么还要专门开发这样的一个需求，区别是什么。
（2）理解了需求，做成什么样也就明了了，怎么做也大概有个方向了。接下来就可以看下方案是否能满足要求了。方案的实现方法，增删改查，是否考虑全面，整体思路是否合理，为什么先这样再那样，两者的顺序是否可以换下；系统间是如何协调配合的，流程是怎样串下来的；和之前相比哪个地方有了新的分支，测试要不要考虑；如果涉及文件以及数据等操作，异常流程如何处理，是否需要回退，怎么回退；接口定义中的字段都代表什么意思，最初来源是什么，系统间怎么传递的，字段是必选还是可选，为什么是必选，是否可以传递多个，为空或者单个以及多个是否覆盖到了，针对修改的接口是否还能兼容以前的实现，接口为什么这样定义，按照功能要求到底要传递哪些参数等等。
（3）最不重要的是实现细节。这是到开发一层的，怎么实现，是先获取所有的值然后排序还是边获取边排序，还是什么算法，保护怎么做，是客户端还是服务端做等等。这一层只是为加深理解提供了更加直观的纬度。
（4）放在最后的是协同配合，这也是最重要的一点，很多特性功能没有按期交付的原因多半在于此。这个地方指的是项目间或者项目内人与人的配合。联调计划是怎么样的，有没有环境，工具是否满足要求，测试策略和测试用例是否如期交付，QA能力和经验是否支撑，开发人力是否足够，有没有并行开发是否存在，特性风险是否明确，跟踪是否及时等等。
（5）结果复盘。每一次总会有遗憾，如何保证下次没有类似的遗憾，复盘就成为了一种手段。为什么会出现这样的问题，究竟是哪个环节导致的这个问题，有没有方法避免，出现这种问题的现象是什么样的，这一类问题有没有通病。等等
针对其他套路方法论，比如
（1）每周六下午4点提醒清空本周工作以及box:平时会把一些需要后续学习或者关注的放到box中；
（2）每周日下午4点提醒清空本周生活以及box:短信，微信，qq等清理，收藏整理后清空。
等等。
套路方法论是逐渐培养并形成自己的风格的，也是有助于工作学习的。后面再逐渐补充。
在写这些的时候也感觉到了总结，确实为一种快成长的套路。
