随着越来越多的客户转向敏捷软件开发,我们已经看到了对业务敏捷性的需求不断增长:更早地参与非工程功能,并以更协作的方式参与其中,以便公司提供更好的收益结果和更好的软件。让我们通过将其映射到餐厅业务来使其更加具体。

厨师我们最初关于餐厅的想法通常是关于食物的。不过,请务必记住,餐馆首先是商家:如果他们不赚钱,就关门大吉。一家运作良好的餐厅可通过其前台人员和销售/市场营销来协调厨师。将其转化为软件世界,敏捷的软件开发团队(工程,质量保证,技术文档,技术运营)是我们的厨师:创建我们销售产品中最可见的部分。随着发布被传递给面向客户的团队(市场,销售,现场SE,渠道,支持),我们需要为市场提供新的价值。收入发生在客户购买和使用我们的解决方案时,而不是我们发布它们时。

换句话说,工作软件是产品成功的先决条件:必要但不足。作为敏捷产品经理(APM),我们需要利用一个跨职能的团队来将更好/更快的软件开发转变为业务价值(收入)。我们的工作是确保整个组织都可以在热销期间协调交付价值,并且要牢记菜单上新商品的特定市场。考虑两个将餐馆与敏捷产品开发联系起来的示例。

生产速度不匹配

当厨房里放满东西时,食客会迟到食物。这刺激了餐饮业者在厨房增加员工。不过,加快厨房的速度可能会导致问题恶化:因为没有足够的前台员工来将饭菜送到餐桌上,所以饭菜只能放在热灯下。饥饿的顾客会得到冷食。
同样,将开发团队转移到敏捷模型可以加快发布版本和新解决方案的速度。但是,市场营销/销售/支持并未以较快的速度使用,客户也没有接受过接受/测试/安装更频繁发布的培训。因此,我们的最新版本位于虚拟热点灯下,等待客户升级周期。我们尚未从汗流sweat背的软件团队中获得增量业务价值。发布不等于收益。

这种不匹配的部分原因可能是工程部门和面向客户的小组之间僵化的组织边界。例如,我们的培训小组只有在软件完成后才开始更新课件;产品营销直到开发周期的最后阶段才发现有什么好处可以推广。在他们手中拿着一张热卖的CD之前,现场系统工程师不会与渴望使用此版本的特定客户接触。通常,面向客户的团队不了解敏捷开发周期,也不信任他们。
因此,敏捷产品经理需要解决信息和信任问题。这意味着需要定期引入跨职能团队(市场营销/销售/支持/法律/财务),以了解Engineering在构建什么,并更多地邀请一些外向人员。例如,您应该在每个客户展示柜中都包括产品营销和客户支持。这样可以使支持人员尽早查看升级和安装问题,并且产品营销可以与APM /开发团队共享其市场优先事项。通过组建合适的跨职能团队,敏捷产品经理可以更快地将其产品交付客户。减少我们的“加热灯”时间。并尽快将钱存入收银机。

迭代菜单改进

另一个挑战是要跟上创新的步伐。厨师一直在尝试新菜和替代食谱,而前台商人则希望提供一致的食物并重复用餐。最好的餐馆建立了创新的节奏:每周的菜单上都有数量有限的特色菜,供冒险的食客们品尝。前台人员(侍应生,行销人员和市场营销人员)跟踪反应以评估市场反应。在一周结束时,成功的菜品会轮流摆放,失败的菜品会减少。随着时间的流逝,新的招牌菜会添加到永久菜单中。
在我们敏捷的软件世界中,每个即将推出的解决方案或功能都应该有特定的市场。一旦我们面向客户的小组与Engineering取得联系,并看到我们可以可靠地从烤箱中可靠地传递管道热值,他们就可以将整个产品的交付日期与发布日期保持一致。市场营销可以更频繁地修改网页和产品演示;支持人员可以起草常见问题解答;渠道销售安排更频繁的经销商简报。最重要的是,销售/ SE可以在目标细分市场中排队客户,等待我们的最新功能。

SoundByes

敏捷产品经理与他们的开发团队有着最紧密的联系,但也必须使面向市场的组织进入敏捷过程。将软件转化为收入需要跨部门跨界进行协调,并以敏捷的速度进行工作。