V0.9版本
写在前面：
从咨询视角到2B产品项目参与者视角参与敏捷研发过程，我打开了曾经没有开启过的视角。这让我想起曾经做咨询或管理者时常用的一句话，企业做过程变革，就像开着飞机换轮子。是一项既危险又需要优雅的事情。
敏捷中的责任主体视角变化
背景：小规模组织（笔者定义在整个公司20人以内的研发团队，也有20人以内的研发小组，但部门在百人级别，故在这两者上下文下，视角也不通用）
痛点：
1、研发团队内分工大类上只区分产品、技术。实际职责有区分，但边界上不会进一步明晰。实施规则改进时有明确的责任主体（一般是产品经理或技术经理自上而下快速实施管理手段），实施改进直接影响产品的成功，一般不经历严格的论证过程，快速浮现，快速改进，逐渐固化。缺点是因为定义与验证环节缺失，在规模增加时或者开始考核成果时，难以进行证明投入管理活动的效益。
2、大规模组织下，中层管理者一般无法打开具体的业务细节，所以也不会从交付团队的规则颗粒度给与辅导、协商。而一线管理，则被更严格的划分出了职能，分层实施管理活动。一般不跨职能指导规则定义。故责任主体分散，通过领导力通过影响力的方式间接影响团队形成自管理。（如站会浮现的规则，回顾浮现的规则，就是非部门统一形成的规则，适用于单团队运作）
区别：
1、在小团队中，浮现想法到落地实践，进而固化规则的周期可以很短，效果也比较容易在短周期内显现，一般在1-2个月内。在职责边界模糊的情形下，全员也比较容易达成共识，共同对团队目标集中发力。缺点是因为没有提前定义，所以事后也难以论证效果。
2、在规模化组织中，团队缺少明确责任主体，背后则是绩效和岗位要求上对人的考核。如果过多参与非考核目标中的事项，可能导致考核上的失利。以及人员流动性高导致的内部管理共识流失。需要经历组织层面的假设、研讨、论证，共识、培训、推广、改善、发文、验证的过程，最后固定为组织的通用标准。团队根据通用规范指导日常运作。
敏捷中的是团队还是团伙
背景：
大规模团队中的构成较为复杂：如外包、OD、自有、供应商等，流动性较强，信息差较大，辅导资源投入不一致。今天形成的团队规约，明天可能因为职责划分、人员变化、组织规则变化而失效。故每个职能筒仓形成自己的规则，通过【握手】方式供其他职能联调调用。难以在通盘角度灵活的考虑通盘优化策略，达成局部最优。
观点：
我认为规模型组织里，团队是个假设的集体概念，相同职能的人组成利益互相影响团体，而上下游协同的人员则形成的是短期团伙关系。通过充分可视化牵引局部优化到全局优化转变，直到形成统一的团队价值观。分工越细，团队统一价值的形成难度越高。利益斥力越大。
团伙作战的特征
1、在沟通中对交流词汇有严格的定义，如未遵循暗语标准，则会全面激发安全脑进而审视对话内容
2、在安全脑未被满足层面的工作模式大致是：表达、论证、价值、判断、行动。
3、在安全脑充分满足的情形下工作模式大概是：表达、判断、行动。
举个例子，你在和跨职能协作时，有多大概率下是能快速得到支持和共识的。
团伙作战下的回顾会议等于与虎谋皮
1、希望别人改进（参与者希望有人牵头提案，自己通过抛出问题来解决问题或问题不在自己的伦茨）
2、希望别人行动（参与者希望尽量减少自己在会上达成不利于的行动，有可能是以增加工作量为前提的）
3、难以定义团队牵引方向（参与者本身并无明确牵引，但通常具备质询的能力）
4、主观和客观指标缺乏有充分背书公信力的指导，难以取得共识
咨询视角的重要价值
1、较容易规避参与者安全脑战逃僵状态，从旁观者角度切入，但前提是能经受住内部骨干的挑战
2、完成组织牵引层方案后，定期辅导团队解决具体问题，方法实践落地实际运作
最后
1、在匆忙的没有优先级的会议时，改进成为了奢侈的行动项
2、在被挑战的交流中，许多具备建设性和创造性的涌现逐渐闭麦
3、那么作为参与者，如何逐步建立影响力为主的牵引力，在巨大的齿轮中既能明哲保身，又能逐步改进，还能实现价值就变成一个可以再开一篇文章讨论的话题 。
