首先 i am no expert。这个技能树太庞大了，技能点远不远不够。但是知道这个树长什么样，可以帮助我们在加点的时候，做出选择。大体上来说，我认为是这样的一个模型：
映射到常见的角色分工上，大概是这样的。
但是并不是说，你目前主要负责的是某个角色的事情，别的角色的事情就和你毫无关系。恰恰相反，角色之间的互相协作才能做好各自的本职工作。为什么会有分工？因为每个领域有其不同的内在挑战，搞好其中任何一个都不容易。理想的情况当然是这些只是角色，每个人都可以在需要的时候戴上不同的帽子，扮演这样的角色。当然这是不现实的。
- 理解商业，并优化：产品经理/数据科学家
- 找到产品优化方向，变成下一个商业增长点：理解用户，一秒变小白。用户调查。找到用户价值所在，找到产品的优化方向。或者通过数据，通过ab实验发现改进的 insight。
- 设计产品方案：产品经理干的事情。把产品优化方向落地为产品方案，并推动实现
- 设计算法和策略：数据科学家干的事情。把产品优化方向落地为算法和策略，并推动实现
- 软件复杂度管理：写业务逻辑的开发
- 单点的问题：一个模块能够遇到的挑战
- 单点上堆叠复杂的业务逻辑：比如特别复杂的计费方式
- 单点上处理海量的事务：比如秒杀，比如交易所。对并发状态的处理方案需要结合业务场景的需要。
- 多点的问题：把问题拆分，但是拆分也有拆分的问题
- 多点状态上维护事务一致性：比如转账，需要保持多个账户的帐作的值是平的
- 拆分业务逻辑成为可管理的模块：最大化地进行拆分，同时最小化模块间的负责人员的沟通成本。跨团队的协作会议数量和联调成本，比高内聚低耦合这样的空洞的口号要实在得多。比如按单据分析业务流程
- 满足细分市场的需求：比如产品线模式，用一套代码去满足多个细分市场
- 理解软件和软件开发，并优化：测试/测试开发，运维/运维开发，基础架构开发，过程改进/项目经理
- 优化效率：提高需求沟通到上线的交付效率
- 优化质量：提高反馈的带宽和频次。无论是BI做分析，运维的监控还是QA做的测试，都是提供反馈
- 优化成本：过程改进，减少人力成本投入。运维卡资源申请，减少机器成本投入
- 优化安全：用各种手段保障业务不被中断，减少MTTR，提高MTBF。异地多活，安全漏洞扫描。
无论是什么样的buzz word，比如customer journey map，梯度下降算法，测试驱动开发，design pattern，多维数据分析，devops，linux hardening。我感觉都可以对应到上面这棵技能树的某个分支上。
这个树有什么用？两个作用：
- 不要羡慕别人的工作：分工是客观存在的。没有人可以干所有的事情。应该甩给其他人去解决的事情，就应该甩过去。如果他没法及时帮上忙，我们应该做的是临时补位。但最终应该是把合作伙伴们都培养强大了，大家才能共赢。但是在同一个颜色的区块呢，竞争是客观存在的。内部竞争客观存在，不可避免，也无需避免。
- 了解自己的岗位的深度：写业务逻辑的开发是最容易觉得自己干的活没有技术含量的。但就是对 if/else 的堆砌也是有挑战的。搬砖还要把砖给码放整齐呢，一个道理。
