背景和目标

项目为了进入一个产品，需要整个系统降低资源消耗。而因为原来系统并没有相应的应对方案，现在选择的方案是尽量使用原来的系统服务，进行资源降低以及组件裁剪。事实上并不是进行简单的裁剪就能完成交付的，还需要为了剪裁组件调整部分功能，并且同时还需要补充该产品价值需求。
现在交付管道遇到一些问题，表现为故障多、交付带宽不足、交付承诺有达不成、开发团队人力无法支撑需求等现象。 还有就是需要达到一个非常极致的低消耗，可能以各组件进行简单的缩减内存无法达成目的（之前产品一直注意进行资源消耗，所以可以通过简单方法可以缩减的资源并不大）。为了使这个产品的开发能够消除这些问题，做好产品交付，部门领导组织了这次工作坊。

流程

1. 首先是破冰，相邻两个人交流一下最近感觉开心的事。事实证明，这个操作确实对于后面讨论具有一定破冰效果
2. 前期问题收集信息的澄清，主要包含：产品规划、项目管理、质量现状、架构挑战等。
3. 前期问卷调查收集问题，以及现场分组：产品定位与交付策略组、架构方案组、项目管理组、开发测试组、与用户产品协调组。每组确定组长之后，其他人根据喜好选择自己的组，但是每组人数需要协调到基本一致。
4. 每组头脑风暴列出该组主题的问题，并为这些问题排定优先级（组内可以适当控制一下问题数量）
5. 每组进行问题展示，接受提问
6. 小组讨论，寻找根因。可以采用 5why法，我参与的组是头脑风暴加讨论进行寻找根因的。
7. 每组进行根因展示，接受提问
8. 小组针对每个根因，讨论输出解决方案。
9. 然后进入世界咖啡环节：组长不动，小组其他成员轮转到其他感兴趣的专题桌。主持需要协调一下各组人数
   1. 组长进行解决方案介绍
   2. 过程中，过来的人挑战组长介绍的解决方案
   3. 组长进行解决方案调整
10. 进行2轮转移，期间组长要跟每个解决方案的干系人进行确认，方案是否可以落地
11. 每组进行方案展示，并形成AP并确定干系人

人员选择

• 项目规划人员
• 架构团队
• 项目管理团队
• 交付团队SM
• 测试团队负责人
• 项目线领导和部门领导

输出问题与AP

个人感悟

1. 这个一天的工作坊时间非常紧，中午到十二点半，下午到7点半
2. 即使超时也要认真做完，因为沉默成本很高
3. 领导一定要全程在场，进行参与、把关、决策，否则过程中很容易大而化之
4. 前期工作和人员选择要匹配，确保可以拍板的干系人都在场
5. 问题被抽象化了，所以解决方案没有能够带入进行推演验证
6. 整个工作坊，是有讨论边界的：确定资源开销额度了即使不合理、需求已经不能减少了、需求优先级已经不能调整了等。这些限制（或者隐形限制，领导的决策）对工作坊输出方案有效性会造成影响？