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