基本上讲，这两个月一直都在写文档，做PPT，提升所谓Consultant能力。
除此之外比较系统地学习了Shell和一些Linux有关的知识，自认为自身短板还是在技术上。

个人觉得以下分析问题的方式还是比较面向过程和面向任务，比较适合团队Retro，并不是很适合做自我总结。不过还是想试一下。

内容回顾

Technique

• Shell(Done)
• Linux(In porgress)

Commuity

• Shell Workshop(Done)
• 搜集整理团队资料(In porgress)

LeaderShip

• CAT release standard(In porgress)
• Take wish wall job

Workflow

• Confulunce
• DevOps Onboarding Guilde(Done)
• 看完了《持续交付》和《敏捷故事》

分析

总的来说过去两个月值得记住的事太少了，唯一觉得有所收获的就是学了下shell，在每个维度上的学习都不够深入，主要还是精力太分散所致，DevOps确实有很多坑，比如说你不能像做开发一样专注于一件事，但好处是你可以从更宏观的角度来看一个项目，应该说做事情的节奏是可以自己调整的，能从整体架构的角度看问题还是比较令人兴奋的。但是，目前来说中心偏离了技术，就偏离我的意愿了。
其实还有比较困惑的点是自己思维方式的能力，思维方式肯定不是以多为好，我们总是会为一个新观点感到醍醐灌顶，但是总会有新的新观点让我们的思考被颠覆，但我们依然不能放弃追逐真理。。恩。
那些很牛逼的人，并不是脑子转的有多快，而是你问他的问题他以前就思考过了，甚至回答过别人了，甚至参考过别人的回答，甚至将自己的答案发表过，在网上和别人激烈的讨论过，所以当你刚刚开始思考这个问题的时候他已经有了比较自信也比较完整的答案。他不是比你聪明，只是走在了你前面。
那么如何成为一个比较聪明的人呢？

• 在别人遇到问题之前先发现问题
• 反复咀嚼遇到过的问题
• 记住你的解决方案，并帮助身边的人解决同样的问题

这样的成长轨迹很容易应用于技术领域，事实上一个程序员的成长很多就是按照这样的轨迹来的，但是如果把这个本领用于咨询，就变得困难了许多，因为描述问题本身就是一个问题，就跟早期的机器学习算法的建模一样，模型建的号，机器算法就优，技术领域的问题被封闭的语境限制着，所以能够有明确的答案，所以咨询的难点就变成了语境的建立和同一，比如“敏捷”，“精益”，一说这个语境，就好比技术上讲一个框架，这种方式适用于什么样的场景，有哪些优劣，一下就有了，我们在语境下的讨论就会变得有着落，明确，保证了沟通的效率。
回到学习能力建设的问题上来吧，虽然我们说没有一个确定的标准来构建你的知识体系，但是冥冥之中每个人都是有自己的standard的，比如说你至少认为人有理性和感性两个向量，比如说你认同三维比二维能更清楚地描述问题。
所以标准的建立有助于问题的分析和思考。

Well

• Bash workshop做的还不错
• 对项目架构有了进一步认识
• 对敏捷的工作方式更加熟悉了
• 看问题的角度从一个开发提升到架构的层面

Lesswell

• 太久不写代码，感觉都要生疏了
• 一直在写Document，做PPT，感觉没有在做有价值的工作。
• 思维方式和思考能力并没有提高，只是换了个看问题的的角度

Suggestion

• 如果可能的话，希望多集中精力在技术上一点的成长
• 希望自己的文档和思维方式更加结构化，可以在几种结构之间切换，但是得变得容易被人理解，容易传播，最好是发人深省
• 多看书，看书，看书

Action

Role-Map

Todo-list

下个月的学习计划主要是考取AWS认证，看几本书，以及尽快完成release standard

• AWS认证： 多看几篇文档，希望能够产出几篇博客
• 关于看书，主要是在TWI之前，希望能把手里的两本看完，产出Session吧
• 关于Release Standard，尽量在本周内完成
• git,Linux
• 凤凰式部署