作为为数不多的专讲敏捷产品管理的书,Roman Pichler 这位敏捷产品管理专家,全面描述了敏捷环境中的产品管理,将其经验及扩展理解倾注在这本双语小书(印刷规格尺寸)之中,确实觉得耐读奇特。
全书内容精简,中文版部分130页左右,共有6个章节,所述分别是 理解产品负责人的角色、规划产品愿景、产品 backlog、发布计划、sprint 会议中的合作、转型为产品负责人。
所读会意之处,思考记录如下:
1. 产品负责人
在项目/产品开始之前,对目标及愿景的理解和收集转换尤为重要。较传统方式是市场部负责市场调研,编写产品概念并将其传递给产品经理,产品经理编写需求规格说明书并将其传递给项目经理,项目经理再传递给开发团队。往往如此一番,产品愿景在经过层层传递之后迷失方向,直至最后“失真” 。
因此产品负责人作为管理产品backlog,并确保开发团队交付工作的唯一责任人。在Scrum中扮演者最困难且又重要的角色。PO作为一个全职工作,代表“客户”,传递需求,在“意愿”和“技术”之间起着桥梁的作用。
PO与SM的互补关系,产品负责人主要负责“目标”---开发正确的产品;ScrumMaster主要负责“方式”---使用正确的方式来实施Scrum。
对于复杂的大型Scrum项目,通常会设立首席产品负责人来对其他小型团队进行指导。
2. 产品愿景
《Scrum敏捷项目管理》提到“ 愿景描述了项目的发起原因以及预期的最终状态。” 因此,对于产品目标应广而专,少即是多。 针对众多的客户和产品属性,可遵循的优先级排序要素有: 舍弃孩子套狼、尽量保留、保孩子舍狼。
如我们所知的工具和方法,可以通过“穿刺”(其他地方叫探针)spike来探求具体问题的可执行原型。运用PDCA (计划、执行、检查、行动),还有建立在市场和产品什么周期基础上的产品线路图(关注眼下的6-12个月),还有Kano模型,愿景盒、场景和消耗图(通常创建2个消耗图,一种是在没有产品的情况下,实现特定目标所必须的活动;一种是在产品可用的情况下,未来所需要的活动)。
3.产品 backlog
四个英文字母DEEP描述产品backlog的特征: Detailed appropriate 详尽适当的、Estimate 经过估算的、Emergent 涌现的、Prioritied按优先级排序的。
特别提到梳理产品 backlog 的重要,通常会分配10%的时间来做这部分工作。其中, 价值、知识、不确定性和风险、可发布性、依赖性等都是产品 bcaklog 优先级排序需要考虑的因素。
在敏捷估算实践中 大家都经常会遇到估算不准确的情况,书中提了3点建议:1. 团队必须大致了解需求条目需要哪些具体的工作;2.团队成员必须能够判断这个需求条目与其他条目之间的依赖;3.必须要对完成标准有一个定义。
4.产品负责人角色
“固定时间而在功能范围特性的多寡上保持灵活 。”这句话巧妙的解决了时间、预算和功能这三个因素之间的关系和作用。
尽早而频繁的发布软件,除发布燃尽图之外,还有发布燃尽柱(通过前后sprint对比,知道存在什么问题)。
做发布计划是考虑的四个因素:产品 backlog 条目、backlog 剩余工作量、速率、时间;
5. sprint会议合作
参加sprint计划会议,PO的主要目的是:明确需求,回答问题 。
PO需参加每日例会,关心项目进展时,一定采用建设性的方式最好是提问的方式(引起团队注意,同时又将解决问题的自由留给团队)。
spint 评审会议,PO宣布会议开始,将增量与sprint目标、目标的实际情况进行对比,判断项目的进展。
sprint回顾会议,PO要定期参加,借助会议计划,提改进措施,巩固与Scrum团队成员之间的关系。
PO做汇报,应多邀请利益相关方参加sprint评审会议和scrum每日例会,而非只用sprint燃尽图做汇报工具,容易成为一种控制装置,征求领导对燃尽图的态度,说明缺乏信任。
总结
全书对产品负责人这个角色的重要性、所存在的问题及陷阱。应用实例,每章结尾又附加反思,浅显易懂,略显不足的是没有提供很多作为PO角色所涉及运用的工具图标模板之类,当然Scrum敏捷本就没有标答,因项目不同,环境各异。 书中重复很多次提到,产品负责人要更多的融入团队,是“我们”而非“我”, 不仅需要负责维护backlog并保证所有人都可以看到、理解到位。Scrum团队所有成员结成一种紧密互信的牢固关系。每天至少一小时的时间在团队办公室内与团队共处。作为产品负责人处理问题要坚决,待人接物要平和,最最重要的是,需要获取管理层的持续信任和支持。
2018.4.13
网友评论