在过去几个月的许多对话中,我看到执行团队正在努力应对 敏捷软件开发对其影响 不发展 流程和组织。如果您是敏捷软件公司的营销,销售或财务副总裁或运营或支持副总裁,或者您正在变得越来越敏捷,那么我们构建软件方式的改进将影响您对软件业务和非工程技术的看法。部门。这是面对敏捷性时需要考虑的一小部分项目。

1.敏捷开发无法解决市场问题。

产品成功的最大动力来自外部:选择细分市场,确定重要的客户需求,很好地执行销售流程以及为价格定价。无论工程完成的速度(和速度)如何,整个产品都是定价,营销,细分,销售渠道,消息传递,定位,包装和技术的结合。我们都看到,软件水平一般的公司在技术上胜过竞争对手。不要被催眠,认为工程将取代市场营销,销售或产品管理。 (仅供参考, 原始市场研究 我们在今年2月与Borland进行了。)

2.我们需要更少的战略重点。

当前的经济环境比以往任何时候都更加需要高管做出一些战略选择,为他们提供充分的资金支持,并有一个诚实地按顺序安排工作的路线图。幸运的是,这是 究竟 敏捷方法需要什么才能成功。我们过去的“花生酱”式投资方法不足,涉及数十个“优先级一”计划中的投资,每个人都在三个或多个项目上工作,但由于敏捷性严重低下而暴露在敏捷之下。 (检查您的工作量)。整个执行团队需要就最重要的两个优先事项达成共识,承认其他所有条件都在#3或以下,然后让产品管理人员负责创建和管理 优先事项–和发展来证明 实际进度。

3.改善不会立即实现。

当工程和产品管理部门走上敏捷之路时,至少给他们四分之一的费用来恢复原始的瀑布式生产力,再给他们至少两三分才能真正动摇。大型组织可能需要18个月以上的时间才能进行重大更改。 3周后不要悬停并开始微管理速度。 (我们的同事Jeff Sutherland报告说,严格控制敏捷方法的使用可以更快地产生结果。但是作为公司高管,我们希望能够满足自己的期望。)

4.瓶颈正在转移到其他地方。

随着开发赶上积压–交付两倍质量更高的软件–公司其他部门也受到压力。渠道营销部门必须向经销商简报两次,Marcom必须每季度对抵押品进行一次修订,支持部门需要接受有关最新更新的培训,运营部门需要创建新的捆绑包并进行价格表更改。最后,销售部门必须根据要求的改进交付实际收入。 (“我知道我告诉Engineering公司,如果我们添加芬兰语和瑞典语版本,我们可以关闭1600万美元……”)

5.我们需要更好,更快的市场投入。

市场营销部门过去经常进行一次年度客户满意度调查,并在年度用户组中提出建议。现在,数十名产品所有者正在实时提出产品问题。产品团队需要获得快速定性的市场投入,并需要两到四个星期的周期 继续进行长期的市场研究。这意味着对市场研究的看法有所不同。一旦我们拥有数十个(数百个)敏捷团队,Portfolio Management就需要确保我们拥有一支 协调的 与忙碌的客户就大小问题进行协作的方式。

6.也许 我的 部门应该敏捷吗?

最近,有人问我有关在市场营销或财务中应用敏捷(或精益或混乱)的问题。但是,这让人感到倒退:应用方法而不考虑需求。如果您的营销团队在跟踪可交付成果和工作量方面遇到麻烦,Scrum可能是一个很好的方法……但是却引出了如何跟踪营销的问题 结果 而不只是 活动。申请可能会有挑战 “完成” 产品管理(或市场营销,财务或运营)中所有内容的完成标准,因为某些结果需要很长时间才能证明。

仅供参考,我听说 小威‘Marketing小组使用Scrum来运营自己的业务, 开放式合作伙伴 通过scrum运营着整个风险投资公司,因此有一些真实的例子。也有很强的相似之处 瞪羚框架 和敏捷方法。很高兴听到您在Twitter上下或下的情况。

SoundBytes

敏捷的软件开发团队会为公司的其他部门带来挑战和机遇。要获得机会的好处,同时最大程度地减少挑战,请对市场和客户进行全面思考,并专注于敏捷业务。