离职前就在和很多人聊这次换工作的想法。在开发领域呆了六年多后，随着行业技术的积累、人才过剩以及重视技术的企业有限，业务开发领域越来越平均主义斯坦，或者说基于资历的天花板会越来越不可抗拒。离职前想了很多方向的可能性，包括管理。
管理一直是我认为很有趣的方向，好的领导力能够提高团队的整体产出。所以对于管理而言，整体产出的提高便是其价值点，以及不断的向上管理所带来的企业进步。遗憾的是很好遇到过可以分析的出色的管理人员。不过不可否认，Leadership（感染力，沟通、协调）是所有岗位都需要的，不需要局限于某一个岗位。
所以想了很久，“能够跨领域并且掌握领导力”。我想要最终的是对开发整体的认知，业务抽象与梳理的能力，产品与交互设计能力，沟通能力，同理心，谈判技巧与思考模式。离职和同事聊天，我说我的目标很明确，尽快成为一名合格的 Solution Architect。
有趣的是，入职后很短时间内，所见所闻以及参与可以不局限于特定类型的团队的项目，也就是可以在同一时间内观察多种样本。
入职的几个月前，我一直认为服务客户 / 用户应该是大于技术投入。但是假设一个极端反面实验，“没有技术积累，senior 开发比例低，针对所有的客户 / 设计需求都不直接拒绝”，那想象下这种模式会经历怎么样的过程：
- 不断面向客户的需求制作 Demo；
- 其他开发人员在等待设计细节定稿过程中被动配合为主；
- 项目整体流程长期处于未完全连通状态；
- 缺乏风险控制，被迫在终点冲刺（最后 20% 时间加班）；
接触的部分成员的主观能动性并不能扭转团队整体的被动或者弱势的地位。目前观察过的这类团队（包括我自己曾主导过的）的都具有的问题：
- 团队角色中，缺乏足够了解 / 掌控 整体流程以及设计的角色；
- 开发缺乏节奏感，没有明确的 milestones 以及 无常的加班；
- 缺少和客户 / 设计团队有效 谈判的角色；
上一阶段刚结束，就又去英国呆了两周。
在之前的国内团队积累的很多技术在英国团队中都没有用到。我们所推崇的 主人翁意识 持续重构与优化 以及 关注性能 都不再是关注的重点。我所在的第一个英国团队以一种轻盈的姿态避免了这些问题：
- 仅关注眼前的问题，不去提前考虑复用（第三个相似出现后才考虑复用）；
- 单纯执行已有的技术结论，不去做改变；
- 将任务拆的尽可能细/复杂度控制在 3 天左右，由开发自己选择任务；
我和英国同事聊了很久第三点，我一直坚持我们在国内的做法可以让团队的执行力更高：
- 推崇主人翁意识，鼓励开发主导某个完整的需求；
- 要求负责需求的开发提前准备设计文档，多人 Review 需求的实现方案；
- 如果需要提高某个任务的优先级，直接给该需求增加开发数量；
回国后又进入了另一个优先级更高的项目组。很快在合作中遇到了很多问题：范围过大的任务，过分不重视技术任务导致不同任务中有大量重复开发 以及 任务延期严重。
所以对于关注个体的松散的组织架构，控制任务复杂度并允许开发自由选择任务的确是较好选择。控制任务复杂度目前观察到的有四步：
- [Leader 与 BA 以及 Key Developer] 分解业务任务中的技术部分与业务部分；
- [Leader 以及 Key Developer] 抽取公共技术任务，根据依赖关系与商业价值安排优先级；
- [Leader 以及 Key Developer] 粗略将任务再次拆细，尽可能保证每个任务预计需要三天工作量；
- [ALL] Grooming 采用同时打牌策略，保证所有人对任务预期一致；
一方面会申明给开发足够的自由自行实现，实际上在 2 与 3 已经对任务有预期的实现的干预。
前几天转正谈话的时候听到了一个久违的词汇 “舒适圈”，突然发现这个极具脆弱性代表的词汇。近期看完《黑天鹅》 和 《反脆弱》，简单说，普遍缺失的通常是存在机会，所以职业规划就是面向这些机会去做 “能力冗余的过程”。
