AHA 神撩

• 为了快速完成，所以同时开工，期望早点结束，结果呢
• 工期紧，很多东西简单处理，留下技术债，结果呢
• 干系人都是大领导，得罪不起，啥都听，结果呢
• 干系人之间有意无意隐藏信息，结果呢
• PO要澄清的需求很多，

基模应对总结

还有一些没放进来，百度搜索十大基模有详细文章。

场景分析

既然前面学了那么多，现在可以尝试做一些练习了，下面的解读可以加深理解。

基本规则，系统思考的回路根据实际需要才有，不是图形上穷举。可以看出来，O的个数如果是奇数就表示平衡回路。

走捷径以加快

• 平衡回路
  • 压力大，更努力
  • 更努力，速度加快
  • 速度加快，压力减小
• 增强回路
  • 压力大，我就多走捷径
  • 走了捷径，缺陷数增多
  • 缺陷数多了，加大返工可能
  • 一旦返工，速度减慢
  • 速度减慢，压力加大

画图有点小疑问，这两个速度应该分开来，2个回路只有一个共同的点，就是压力。
前面是误解，其实没问题，S和O，只是表示变化方向是否一致，后面还会提到

• 对应基模
  饮鸩止渴

• 应对措施

  • 承认做了权宜之计
  • 做好技术债管理
  • 如果有必要，以后要根本解决技术债

多开始以加快

• 平衡回路

  • 压力大，同时开工任务多
  • 任务多了，速度加快
  • 速度加快，压力减少

• 增强回路

  • 压力大，我就多开工
  • 同时开工任务多，在制品增多
  • 在制品增多，速度减慢
  • 速度减慢，压力加大

• 对应基模
  成长上限

• 应对措施

  • 聚焦远期目标
  • 整体做完才算做完

PO和团队互相指责

• 平衡回路

  • PO定义产品的能力强，对验收的执迷弱
  • PO对验收的执迷弱，PO定义产品的能力就强

• 平衡回路

  • 团队对验收执迷，加强交付能力
  • 交付能力强，对验收不那么执迷

• 增强回路

  • 增加PO定义产品的能力，加大PO让团队参与产品规范的意愿
  • PO让团队参与产品规范的意愿加强，促使PO让团队参与产品规范的程度
  • PO让团队参与产品规范的程度，增强团队交付产品的能力
  • 团队交付能力增强，帮助PO的意愿加强
  • 团队帮PO的意愿加强，团队就加大帮PO的程度
  • 团队帮PO的程度加大，PO定义产品的能力增强

• 增强回路

  • PO定义产品能力越弱，对验收就越执迷
  • PO对验收越执迷，团队交付能力就越弱
  • 团队交付能力弱，团队对验收就越不在意
  • 团队对验收越不在意，PO定义产品的能力就越弱

• 对应基模

  • 舍本逐末

• 应对措施

  • 关注长期目标

多干系人，隐藏信息

干系人：和项目有关的人，可能是阎王，也可能是小鬼。

• 增强回路（A和B一样）

  • 干系人A的声音大，给他做的活就多
  • 给干系人A做的活多，给A带来的价值就大
  • 给A带来价值大，A的声音就更响

• 平衡回路（A和B一样）

  • 干系人A的声音大，团队无法自理，总是被插队任务，打乱计划，总的工作要求就增多
  • 总的工作要求增多，出现上面的问题，很多开始，但是都没结束，可用的产能就少了
  • 可用产能少了，给A干活也少了
  • 给A干活少了，为A带来价值就少了
  • A的价值少了，声音小了

• 平衡回路

  • A的声音大，透明性就降低
  • 透明性降低，优先级排序难度增加
  • 优先级排序难度增加，决策质量就下降
  • 决策质量越低，产品价值就越低
  • 产品价值越低，总产能就越低

• 对应基模

  • 共同悲剧
  • 恶性竞争

• 应对措施

  • 加大透明度

S 和 O的区别是变量是不是同方向变化，比如优先级排序难度（高）-O-决策质量（低）-s-产品价值（低）。

多干系人，压迫

• 增强回路（A和B一样）

  • 干系人A的声音大，给他做的活就多
  • 给干系人A做的活多，给A带来的价值就大
  • 给A带来价值大，A的声音就更响

• 平衡回路（A和B一样）

  • 干系人A的声音大，总的工作要求就加大
  • 总的工作要求多了，可用的产能就少了
  • 可用产能少了，就越要给A干活
  • 给A干活多了，为A带来价值就多了
  • A的价值多了，声音更大

• 平衡回路

  • 总的工作要求多，PO压力大
  • PO压力大，给团队压力大
  • 团队压力大，走捷径次数多
  • 走捷径次数多，返工
  • 返工造成可用产能降低

• 对应基模

  • 共同悲剧
  • 恶性竞争
  • 饮鸩止渴

• 应对措施

  • 整体目标明确

PO过载于需求澄清

• 增强回路

  • 透明性高，产品整体性好
  • 产品整体性好，PO个数增加
  • PO个数增加，产品待办列表份数就多
  • 产品待办列表份数多，透明性就低

• 平衡回路

  • PO个数多，产品待办列表份数多
  • 产品待办列表份数多，每个列表故事少
  • 每份列表个数少，PO需要澄清工作量就大
  • 需求澄清工作量大，对PO的压力就大
  • PO的压力大，PO的个数就要多

• 对应基模

  • 饮鸩止渴

• 应对措施

  • 把PO澄清的事交出去

PO排序优先级，团队澄清需求

• 平衡回路

  • PO压力大，PO数量增加
  • PO数量增加，产品待办列表份数增加
  • 产品待办列表份数增多，每个待办列表份数的故事个数减少
  • 故事个数减少，PO需要澄清的工作量加大
  • PO需求澄清的工作量加大，PO的压力就大了

• 平衡回路

  • PO压力大，团队参与深
  • 团队参与深，长期来看，需求澄清工作量就小了
  • 需求澄清工作量小了，对PO的压力也小了

• 增强回路

  • PO压力大，PO数量增加
  • PO数量增加，产品待办列表份数增加
  • 产品待办列表份数增多，每个待办列表份数的故事个数减少
  • 故事个数减少，需要的帮助就加大
  • 需要的帮助加大，团队参与就深
  • 团队参与深，长期来看，需求澄清工作量就小了
  • 需求澄清工作量小了，对PO的压力也小了

• 对应基模

  • 舍本逐末

• 应对措施

  • 聚焦远期目标

来自研发的团队PO以保持现状

• 平衡回路

  • 业务方变革阻力大，想要有更多的PO
  • PO多了，业务方需要的变革就少了
  • 业务放需要的变革少了，业务变革阻力就大了

• 平衡回路

  • 业务放变革阻力大，需要对业务方做更多辅导
  • 业务方接受辅导多，双发合作程度就高
  • 长期看来，价值和灵活性就加大
  • 减少业务放需要变革的东西
  • 从而减低业务方的变革阻力

• 增强回路

  • 业务方变革阻力大，想要有更多的PO
  • PO多了，双发合作效率降低
  • 长期以来，价值和灵活性降低
  • 加大业务放需要的变革工作量
  • 从而提升了变革阻力

• 对应基模

  • 舍本逐末
  • 意外之敌

• 应对措施

  • 关注长期
  • 减少短期依赖，甚至休克疗法

后记

它帮我们理清各种因素的干预关系，特别是变量多，系统复杂时，帮我们简化，又不失整体。

对于已经理清的关系，如何解决，可以考虑所谓分层的办法，多加一个变量，打破目前的关系。也许是一个解决之道（多谢91和bob贡献）

关注公众号，找画作者