产品线&组织架构调整
不知道是先开始的产品线调整（我的理解是公司业务战略调整），还是先开始的敏捷转型。如果按我从周金根老师那里偶尔了解到的关于企业架构、业务架构的一点儿皮毛的话，企业架构是更重要的，应该是在公司决定敏捷转型之前就开始架构公司的业务战略了，然后再通过敏捷转型去实现业务战略，创造业务价值。这是题外话，是我参与敏捷转型后想到的。我预感到，无论公司还是我们个人，尤其产品负责人，企业架构和业务架构的深入学习将在敏捷转型有了初步成效后展开。
本周在敏捷宣贯培训之后，统一了认知和理念，然后就开始了落地实践。首先公司根据几条产品线做了组织架构调整，每个产品线的角色如下图：
我从项目实施部的项目经理角色，转换为PO角色。负责公司一条产品线的项目定制开发需求工作。这样，我实现了一年前加入晓羊时对自己的定位和规划，我记得在项目部工作两三个月的时候，我就提出了这样的想法和建议，增加一个需求分析团队（也就是现在的PO角色，目前只有两个PO）专门负责项目上的需求工作，跟项目经理配合作战。
简单来说的话，就是项目上需要找研发支持的，就是PO+研发来负责，协助实施部项目经理做定制化部分的交付，包括集成对接开发、功能性开发。
PO和项目经理的职责划分如图：
“守破离”敏捷落地三字诀之“守”
有的产品团队已经开始了实践，王立杰老师作为公司的敏捷教练，参与和指导每个敏捷团队开始思考和梳理工作如何转变和切入。我们团队因为不是做产品，而是做项目，而且有几个大项目是进入了维护阶段，不时来几个需求，做完了就要发布，不像Scrum有一个固定的时间盒，可以按版本计划去发布，除非是一个新的项目，有系统级或大功能模块级别的功能性定制开发。所以根据教练的推荐，下周准备开始尝试看板。看板跟Scrum相比，是一种更简易的框架和模式。具体如图所示：
看板框架示意图
可参考的实际看板案例
看板的三大原则：
1、流程可视化，让需求或任务滚动起来。
2、限制WIP（在制品，Works in progress），也就是限制同一阶段区域里面的任务数，超过上限会造成工作效率低下，质量也会出问题，表现出来就是忙、乱、差。
3、度量生产周期，评估一个时间段内能做完几个需求或任务，对团队的生产力做一个估算。
作为PO开始梳理需求
有几个项目已经开始找到我这边了，有些问题就是马上要解决的。于是我对需求做了了解之后，就按用户故事的方式对需求做了一个描述，定义了DoD（完成定义，或者叫验收标准），这样研发和测试就知道如何算是完成了，确保需求按客户想要的价值目标实现。
如图，这是其中一个项目的需求：
某项目一个单点登录的需求
如果下周把看板建立起来，我准备做一些用户故事卡片（借用周金根老师的），类似这样的：
用户故事卡片（周老师设计）
SM跟我说，这才刚开始第一周，就感觉同时很多事情找过来了，他说得有个优先级啊，确实，他提醒了我，我跟他说，咱们下周就建立看板，其中的WIP原则就是为了限制同时进行的任务数量的，就能解决我们忙乱的困扰。
因此，周五下班前我去HR那里领了工具，下周就开始真刀真枪的干起来了。
我对我们的工作充满了期待，虽然有些忐忑，但摸索和创新让我们兴奋，因为我们的所作所为将会改进我们的交付价值，会让我们为公司做出更大的贡献，会让我们的客户更加信赖和离不开我们，也会让客户在我们的支持下更加高效和成功。