我刚刚和一个受训的人呆了几个小时, 导向器 公司建筑企业的产品管理专业 物联网 solutions (hardware+software+cloud aggregation) and now responsible for 3 product managers. 她 finds herself in a very typical situation:

  • 开发团队正在每周进行优先级排序,但是在那里’没有清晰的季度路线图
  • 目前正在进行许多项目,但没有一个主要主题。它’很难掌握什么’或正在完成的时间。
  • 首席执行官大声怀疑开发是否富有成效,并且可以’将技术活动映射到业务成果

该公司需要扩大规模以获取份额,达到收支平衡和履行董事会承诺。扩大规模是一个 商业 目标,但是,在决定集中精力方面几乎没有帮助 技术 努力。

该怎么办?

我们的主任’首先要确定阻碍增长和隐含产品改进的主要障碍。她四处闲逛,听说过(并经过深思熟虑地)有关产品相关问题的各种理论:

  • 可部署性。这些装置很复杂,散装运输,需要一些现场调查工作。如果他们可以简化安装过程并为现场团队提供更好的计划工具,则现场团队将加快部署速度。
  • 纯成本。物联网解决方案空间中的价格正在下降,并且交易在财务方面获胜/失败。将产品成本降低25%或更多将结束一些大型交易。
  • 硬件/软件可靠性。组件经常失败,有时在到达时失败,并且软件错误偶尔会降低输出。他们需要投资于制造质量和自动化软件测试。
  • 云扩展。他们的仪表板和控制算法是为数百个部署单元设计的。数以千计的提案正在提交中,一旦安装,将很难进行管理。
  • 等等。

我们的董事认为,在执行层上存在一些分歧,并且误导了’坏了。现场工程总监’团队在部署过程中苦苦挣扎,只能看到那些问题。销售对保证金,成本和交易定价最为敏感。运营人员整天盯着不足的Web门户。每个利益相关者群体都倾向于关注自己的本地问题。

但是,如果在这些顶级问题中没有排名,开发组织可以’•优先安排故事或工作。 没有基本的战略,就没有自然优先的发展工作.

因此,我们无畏的产品管理总监必须推动业务和技术负责人之间的讨论和达成共识。她必须让他们接受问题之间的特定等级和资源的特定分配。她正确地将其构图为“我们应该如何要求Development花我们宝贵的故事点?”

It’指派100%的开发组织几乎总是错误的’针对一个狭窄的项目进行了长时间的努力。 (例如,本季度仅将重点放在后端软件扩展上,而忽略了所有错误和所有其他功能请求以及所有UI修复) ?软件可靠性提高了吗?

她’必须将少数几个行政利益相关者聚集在一起,并迫使他们在最重要的问题之间进行明确的权衡。

“如果我们将精力平均分配给4到5个问题,那么我们赢了’在任何方面都没有取得很大进展。因此,我们必须就哪个最重要以及本季度总体开发工作的哪一部分达成共识。我们是否将70%的可部署性和20%的成本降低推迟了所有软件扩展工作?还是60%的云扩展和30%的硬件可靠性?我们可以’t分配的百分比超过100%,因此这迫使我们做出“异或”选择,而不是一无所获。”

想象一下很多类似以下图表的白板:

馅饼嵌入

此外,她希望首席执行官对技术吞吐量或效率有所抱怨。 (“如果开发团队更努力/更聪明,我们’d完成所有这些操作。” 要么 “敏捷应该给我们两倍的速度。”)  她’我会尽量避免被误导,因为这是 魔术思维:通过某种方式,我们可以通过承担更多的工程能力,将所有物品都放在愿望清单中。在科技公司的历史中,’s 从未有足够大的开发团队来实现高管的所有梦想。无论速度如何,我们仍然必须在每个季度做出艰难的选择。

最终,我们无畏的产品管理总监努力达成了一些协议。实际上看起来像这样

最终派

因为有些工作类别是开发内部的,而她没有’邀请高管进行交易。 (例如,销售人员始终希望推迟自动测试“仅在本季度”支持某些交易驱动功能。有时,我们必须保护人们免受自身伤害。)

我们还可以和我们的技术人员讨论吗?

最后,她已准备好通过Development进行一些富有成效的优先级划分和积压工作。谦虚地,她以半结构化的方式与工程同行和产品经理进行互动:

“这个季度,我们在所有项目中花了大约1000个故事点。最重要的业务重点是可部署性,即缩短时间并减少安装我们的下几百个单元的成本。如果我们有600个故事点可用于此目的,我们将如何做?胜利点和杠杆点在哪里?我们本季度(或本周)可以提供什么以实现有意义的改进?”

It’请务必注意, 最高目标的不同权重必然会导致用户故事的选择不同 和技术工作。那里’没有与策略无关的评分系统,或者 先验 与个别工作项目相关的价值。

也许可部署性工作会容易得多,并且我们的总监可以使用她的一些有价值的故事点来在其他地方使用。也许吧’的工作非常困难,预算这么小的预算也无法改善,因此她不得不重新考虑优先事项。这很可能是集中精力和吸引开发团队的一种好方法:让他们自由地创造性地解决框架合理的问题。关于项目的简单讨论’支持任何关键主题。

顺便说一下,此模型还提供了一些良好的委派机会。如果在本季度中有100个故事点要花在质量改进或测试基础架构上,那么我们精明的总监可以相信QA可以将这些点分配给他们认为具有最佳质量ROI的任何项目。毕竟,下个季度在质量上还会有100点的花费。

总结我们聪明的导演’s approach:

  1. 确定直接影响收入/客户的业务问题
  2. 创建投资组合分配:对问题进行排名和相对努力,避免需求“马上做一切”
  3. 与开发部门就如何最佳利用优先事项进行合作
  4. 调整,调整,重复。在执行人员之间建立信任,即开发工作实际上与业务优先事项保持一致。在执行人员之间建立信任,将减少干扰。

I’ve已将这些工具应用于单个产品,产品组合和营销方面的改进。必不可少的步骤是 强制权衡 在所需的投资中:我们必须足够具体以做出艰难的选择,并且必须有足够的耐心才能获得回报。

声音字节

优先级发生在上下文中。要是我们’无法确定什么 ’最重要的是,我们可能无法在眼前的众多机遇中做出(艰难的)战略选择。