在过去的几个月中,我们’我们反复听说过产品经理,他们从客户拜访或休假回来后发现他们的工程团队“gone agile”没有告诉他们。之后,项目经理争先恐后地找出在新的开发模式下它们的角色和可交付成果如何不同。他们要么被排除在组织之外,要么放弃产品管理使命的关键部分。

什么 we see at Enthiosys, 几乎每一天就是敏捷能够提供更多更好的软件;产品经理是这种改进不可替代的一部分; PM功能必须成为业务改进的冠军。所有这些都要求项目经理密切参与其开发团队的日常活动,以帮助他们取得更大的成功。

敏捷的推动力从何而来?

在敏捷环境下软件开发效果更好 几乎所有东西都是隐藏的软件。与瀑布模型相比,软件的到货速度更快,质量更高,并且具有巨大的战略失误。这可以直接转化为可节省的成本和时间,更高的可预测性,有时还可以提高收入。将开发吞吐量提高30%到40%的机会激发了CFO,CIO和CEO,而不仅仅是工程副总裁。这不再是“pick your poison”或宗教讨论。

这些都是大胆的主张,因此第三方验证很重要。考虑一下VeriSign,在此期间,托管安全服务团队使用Agile在很大程度上用路线图和积压订单替代了传统的市场需求,从开发周期到估计节省了3个月的时间。或者BMC Software的Israel Gat,他对他的敏捷过程进行了严格的公开审查,并展示了新版本的卓越质量和上市时间。 Key Bank和Capital One是与Agile分享成功经验的一些金融机构,而我们与Emerson Process Technology的合作成功地将Agile应用于极其复杂的嵌入式系统的开发。

(如果您的PM团队不在’在考虑并辩论向敏捷的转变时,没有您的投入便会发生。您可能是下班回家的配偶,惊讶地发现您的钥匙不再为房子开门。)

产品管理总监和副总裁代表这次机会的所有组成部分。他们为客户说话,缓​​冲过多的干预工程,并制定基于收益的产品计划。作为权衡和平衡发布图的仲裁者,项目经理通常最适合提倡改变开发方法。促进更快,更智能,更便宜是PM角色的关键。

工程团队希望尽力而为,并且他们中有聪明,有见识,紧密联系的人。您’重新帮助他们创造未来或阅读结果。

敏捷PM是否真的与众不同?

从100,000英尺开始,所有敏捷或传统的产品管理看起来都一样。我们的大小市场,了解客户,写的要求,广泛征求和解释客户的反馈,和工作拼了命的位置,产品销售&行销就像从旧金山到波士顿一样,无论您如何旅行。

即使在30,000英尺处,您也知道飞行和驾驶之间的区别。每个人可能都吃不起食物,为乘客看电影,以及购买更昂贵座位的方法–但是您只需5个小时(而不是5天)就能到达波士顿。

敏捷确实不同于瀑布。每一天,几乎每一个可交付成果。您与Engineering的讨论方式有所不同,并且(最终)以一种新的方式来考虑您的产品。考虑:

  • 客户输入。 您的瀑布模型是收集输入信息,然后编写需求,然后希望明年取得良好结果。在“敏捷”计划下,在整个开发周期中积极征求客户意见:审查线框,早期功能和可用性。我们发现,传统的产品经理在他们的旧思维模式下苦苦挣扎,即在向客户展示商品之前努力“完美交付”,而不是“共同塑造最终结果”。
  • 开发团队合作。 为了充分利用所有这些强大的客户意见,与传统PM相比,Agile PM与他们的开发团队会面的频率更高。结果是对实际产品在市场上成功所需要的内容进行了更为丰富的校准。
  • 积压。 您的积压订单是您为工程和产品管理提供的一组动态,近实时的交付成果’不断进行审查以反映内部条件和外部机会。团队的重要成员生病了吗?更改积压以反映容量。您想达成一笔交易,但只需要几个功能?重新整理待办事项,然后发布软件,以确保良好的敏捷团队能够在每次迭代中创建“发布就绪”软件。
  • 用户故事。 早在口袋保护器的时代,项目经理就编写了完整(且冗长)的MRD / PRD,以准确地告诉Engineering建造什么。这些已经过时了,无法在一年多的开发周期中预料到许多折衷,因此我们对它们进行了修补和更新以及一次性优先级决定。

大多数敏捷方法会创建更多的文档,而不是更少,但是会根据团队需要的时间而定。敏捷专家更喜欢用户故事的一致表达,可以灵活管理用户故事,并使开发人员易于理解。您可以勾勒出十五个用户案例和用户体验准则,但最初仅详细完成前两个案例。其余的进入您的待办事项列表。在整个发行周期中,您将扩展和编辑用户故事。–当您的客户知识最完整时,领先于需求。

  • 较少的未使用功能。 积压的项目可能无法生成。那’很好地表明他们’真的需要“do it all now” PRD model.
  • 可靠的,基于事实的状态报告。 随着您的团队在敏捷方面积累了一些经验,他们在评估和判断进度方面会变得更好。更重要的是,每次迭代结束时对工作软件的关注使传统的评估进度的方法不仅毫无意义,而且很危险。您再也不会问“此功能是否已完成80%?”而是学会在“完整的”可交付成果中工作。工程人员一定会喜欢看到这如何提高销售和营销信誉。

您最初的PM反应可能是“我可以继续以我的方式做PM吗’即使我的工程团队正在努力做到敏捷,我还是总是做到吗?” You’重新驾驶,而不是飞行,尽管直到您将其改写为“我如何利用工程学’s added power?”

您将需要更多帮助

正如我在9月的字节中指出的那样’敏捷PM要做的工作还很多。我们最成功的客户包括(例如)产品经理,项目经理以及业务分析师/需求专家组成的产品团队。团队提供了额外的关注和带宽-敏捷的PM魔术-工程部需要提供可观的生产率提高。

产品管理总监和副总裁需要正面应对。敏捷成本的一部分是更多的PM人才。练习在镜子前这样说:“没有什么是免费的。为了充分利用工程技术,我们’我们将需要更多的PM资源,以及整个工程产品团队的敏捷培训。”转移一点工程’节省PM的成本是合理的。

声音字节

如果敏捷天堂’赶快来找您的软件团队吧。商业利益是不可抗拒的。产品管理部门应该推动采用并帮助计划过渡,而不是等待成为偶然的敏捷专家。

分类目录 产品管理