背景
此文献给自己和走在这条路上的小伙伴，讲解了一路走着来自己的所见、所感，以及深层思考出来的一些东西。希望看到的同学可以参考、少走弯路。
做事方法论
定义问题
分析问题（思考）
解决方案
业务结果
后续规划
职场
沟通：
- 对事不对人
- 用事实说话：比如A这么爱迟到，实在太不靠谱了 换成 A这个星期迟到了5次，是不是有什么困难？ 这样可以提升影响力
- 当自己的想法与同事不一致，并且觉得自己的方案好，那么怎么说服对方？
- 当你在做一个方案或者接口，上游的输入差异性会对你的接口产生较大影响，你如何去统一？
如何确定系统、项目、功能边界
功能聚焦
要划清边界，比如交易系统只做交易核心的内容，其他的不相关的尽量不去做。就像设计模式中谈到的单一职责原则，系统职能不要有交集。
使用顶层思想做项目
使用顶层设计思想做项目。以往大多是站在业务、功能的角度去做项目，最后的结果是功能没有高内聚、难扩展、维护。好比写程序没有遵循设计原则，导致的结果就是难以维护。那么如何使用顶层思想：
- 立足所在的领域，熟练业务领域流程、业务流程、上下游关系、细节点。抽象出一套解决问题的通用流程。比如要把大象装进冰箱总共需要三步，那这三步就是一个通用流程，类似的问题都要向这这个方向靠，这样不会走偏。
- 流程确认完毕后，关心每一步如何设计思考。对于每一步也可以使用顶层思想。对每一步要做的事情要精通，比如打开冰箱门可以直接打开，也可以戴手套去打开，或者说一句芝麻开门就开了。每一步做好扩展。就像HSF的序列化你可以选择java，当然可以选择Hission。每一个的功能要通用给大多数类似的功能，同时也得给个性化留好扩展。
思考深入决定你的职业高度
持续不断学习
如何做好一个项目的pm
- 进度把控
优先掌握项目架构流程，如果时间允许可以充分了解细节，反之将这个任务down下去。 - 大图
了解每个模块的运作方式，原理、协作关系。
技术方案设计的一个思路：有时会遇到这样的场景，为了实现一个case，技术设计上可能需要耗费较大的成本，其实这个设计大概率不是最优的。可以换个思路：比如看这个case是否是重要的场景，如果不是那么可以弱化一下这个case，同时换成成本低的方案，从另一个角度去实现，降低成本。例子：计算新增店铺券下商品的到手价。常规思路是查该券下的所有品，然后分别计算，这个计算量是很大的且需要维护品券关系，成本很高。思路：弱化case，很少因为新增店铺券导致到手价过低，那么就可以考虑弱化这个case，新增店铺券不去计算。在计算单一品的时候，看下该品是否有店铺券即可。这种成本就小了很多，同时满足绝大多数重要的场景。