作者都是各自领域经过审查的专家,并撰写他们有经验的主题. 我们所有的内容都经过同行评审,并由同一领域的Toptal专家验证.
待办事项优先级排序是一个关键的组成部分 敏捷产品开发. 然而, 当有多个涉众时,它可能会让人不知所措:它们都以异步方式独立地发出请求, 而产品经理要花很长时间进行一对一的会议, 与他们协商哪些项目会进入下一个sprint. 结果往往是浪费时间和资源.
弥合分歧,节省时间, 最好的解决方案是安排优先级研讨会,使他们能够就各自请求的相对优先级达成共识. 在这个密集的会议中, 所有利益相关者可以共同努力,就规划前进道路的计划达成一致.
让我们考虑一个常见的场景. 一家公司的产品团队发现自己在公司的旗舰产品上遇到了问题. 开发团队和架构师设定了一个具有挑战性的目标,将产品转移到基于云的平台上. 然而, 进度非常缓慢,因为开发人员忙于产品功能增强和错误修复. 有大量的技术债务需要偿还, 是什么扼杀了团队进行改进和执行计划中的sprint的能力. 同时, 涉众, 谁都是客户经理,直接与最终用户打交道, 继续要求功能增强,以满足他们所代表的客户. 尽管涉众知道开发团队只在项目可用时才从待办事项列表中提取项目, 利益相关者仍然感到被抛弃和忽视. 对于任何非紧急情况的请求来说,交付时间都很长,而且消防工作太常见了. 最重要的是,利益相关者的要求经常发生冲突.
利益相关者很不高兴 感觉他们的要求大部分都被打入了黑洞. 他们的 顾客很沮丧 处理简单的bug报告和交付它们所要求的增强所花费的时间. 结果是, 开发团队感觉自己被拉向了许多方向,根本无法进行技术改进,以实现更快的周期和交付时间,以跟上涉众和用户的需求. 开发团队需要在哪里集中精力的方向, 如何平衡技术债务和新请求, 以及如何安排工作的优先级.
产品负责人决定让所有人都呆在一个房间里,看看会发生什么.
第一步是获得利益相关者的支持. 在这种情况下, 产品负责人找到涉众的经理,并解释了提议的研讨会的好处. 他表示,目标是按照所有涉众都能同意的顺序对待办事项进行优先排序. 这些是卖点:
为涉众提供结构化的, 在一个方便的论坛上,他们可以表达自己的需求,并相互协作,使他们能够更好地理解如何构建一个伟大的产品. 在我自己的工作中, 我发现我的利益相关者更有可能通知我一个请求, 提供细节, 并在我主持了几次产品待办事项优先级研讨会后回答我的问题.
研讨会实现其目标的能力在很大程度上受到在场人员的影响. 确保你邀请了所有相关专家:
一定要提前发一份详细的议程,说明讨论的内容和时间. 这将为利益相关者提供一个事先提问或提出建议的机会,并使每个人在会议期间保持专注.
在参与者到达之前, 准备好会议室,这样参与者就可以直接投入到研讨会练习中. 首先,你要出示 产品待办事项列表 墙上的项目——把待办事项打印出来或者写在索引卡上.
这些卡片代表了您的团队计划在不久的将来实现的功能和改进. 把它们贴在会议室的墙上,按照当前的待办事项顺序排列——从优先级最高的一端到优先级最低的另一端. 准备好在投影仪或电视屏幕上显示更详细的请求描述和其他细节.
的 产品经理 练习的主要推动者是谁, 通过提供来自产品远景的上下文来监控时间和指导优先级. 产品经理应该避免参与讨论,让利益相关者来决定优先级的设置. 在利益相关者同意一个决定之后, 产品经理仍然可以根据需要移动待办事项项,以适应随着时间的推移而出现的其他优先级. 产品经理保留了对待办事项的决策权, 但是这个练习可以帮助他们收集信息,为未来做准备 优先级决策.
如果一个scrum管理员参加了研讨会, 让他们在你促进活动的同时记下参与者对练习本身的反馈——这对未来的改进很有帮助. 主题专家参加研讨会,为利益相关者提供背景和其他信息.
优先级划分可以分为两个阶段.
在第一个优先排序阶段,鼓励参与者决定哪些项目不重要. 把不重要的事情放在一边,可以让团队把宝贵的时间花在更重要的事情上. 如果仍然没有达成共识, 产品经理应该建议把这个问题放在一边,进行更深入的讨论.
在第二个优先排序阶段, 帮助人们达成一致的一个好方法是利用努力影响矩阵——一个简单而强大的工具,可以促进小组对话,明确优先事项. 那些需要最少努力却能产生最大影响的项目将会出现在列表的顶部, 而那些需要付出更多努力但影响较低的道具则会落在底部. 您可以找到这种技术的几种变体 如何改进它.
如果涉众在没有达成共识的情况下不断移动待办事项项, 产品经理应该对产品的优先级有最终决定权.
会议结束前, 产品经理应该检查参与者并询问他们的最终想法. 他们离开后, 确保对商定的请求进行编号或编码,以便您可以轻松地将它们转移到产品管理产品待办事项列表工具中——从一个作为最高优先级开始.
产品待办事项研讨会应该是Scrum周期中的定期会议, 它可以适用于看板团队的仪式. 如果你能在Scrum周期中进行这个练习, 您将在sprint计划之前收到涉众的优先级. 对于看板团队来说, 研讨会可以每周进行一次,或者以任何最好的节奏来重新调整路线图,以确定看板列表的优先级.
为了我的团队, 每三周召开一次优先级研讨会就足以刷新待办事项的优先级. 找到合适的节奏对研讨会的成功至关重要——确保你在参与者的需求和实际需求之间找到了一条微妙的界限. 定期与参与者确认当前的频率是否满足他们的需求.
此外,为参与者创建一个提供研讨会反馈的渠道. 有一个专门的人来记录研讨会未来的改进是很有帮助的——scrum管理员可以完美地胜任这个角色. 记录下研讨会的改进,以显示你为获得更流畅的体验所付出的努力.
定期安排专门的研讨会来确定待办事项的优先级,可以在几个不同的层面上给公司带来好处. 产品经理可以更有效地利用他们的时间和资源. 公司可以更灵活,更快地取得更好的结果. 要求涉众尽早参与是一个非常强大的工具,可以获得他们对产品计划的支持,并获得有价值的反馈. 高管们还可以利用这个研讨会来评估战术和战略层面的优先事项,以促进员工与公司目标的一致, 团队过程, 以及整体的沟通.
产品待办事项列表和冲刺待办事项列表的区别在于它们实现的紧迫性:Scrum团队使用冲刺待办事项列表来开发即将到来的冲刺中最紧急的项目。, 而产品待办事项列表是一个长期的功能列表, 其中一些可能永远不会进入实施阶段.
A 产品待办事项列表 is important because it lays out all the product’s potential features in one place so the development team can see them; it can also be used to set the expectations of product stakeholders.
产品经理负责创建、确定优先级并维护产品待办事项列表. 待办事项的请求来自各种来源:销售, QA团队, 客户支持, 产品利益相关者.
产品经理对待办事项进行优先级排序,并定义产品方向. 待办事项安排请求有很多来源,但它们通常来自产品涉众. 产品经理必须在利益相关者之间找到共识,有时他们的要求是相互冲突的, 待办事项优先排序研讨会是最好的方法.
一个好的产品待办事项列表是一个优先排序良好的计划,它将高层次的愿景转化为创建产品的工作细节.
世界级的文章,每周发一次.
世界级的文章,每周发一次.