写点什么

当敏捷遇上销售

  • 2013-08-22
  • 本文字数:1796 字

    阅读完需:约 6 分钟

在文章《敏捷与销售:我的第一支 Scrum 销售团队》中,对于大家经常关心的问题——是否能将销售团队做成敏捷的以及如何推动变革?销售经理——Eric Krisfelt 给出了自己的解答。他详细描述了如何在销售组织中实现 Scrum 的步骤,并展示给大家非工程师团队如何变成有自组织意识的敏捷团队。

在开始过渡之前,Eric 提供了 4 个步骤,以完成从传统销售团队到 Scrum 团队的过渡:

培训:为整个团队提供敏捷及 Scrum 的培训至关重要。只有这样做,团队才能理解敏捷的方法论及这样做的目标。这能够帮助销售团队的每个人培养并养成对开发周期的更好认识。

立会:对于客户及外部团队如何使用流程,立会将帮助团队建立快速适应及反应的意识。对于销售团队来说,立会应该比较容易接受。一般来说,大多数销售人员都没有耐心,喜欢直奔主题的短会。这样做还可以帮助他们快速地解决问题并集中在成果上。

Sprint 及回顾会议:对于销售而言,每个 Sprint 的周期可能比典型的开发团队使用的周期要长得多。但是对于销售经理来说,遵守 Sprint 的结构非常重要。销售团队通常以月为单位设定目标,因此我们通常以此作为我们的 Sprint 周期。

重新解释产品的 Backlog:我们的团队采用的是电子个人信息中心(EPIC),并把任务分为“等待”、“在建”及“完成”等不同状态的 Backlog 项。这样一来,整个销售团队及管理团队就会得到每个迭代过程中所发生的艰巨任务的清晰“全貌”。

就 Eric 的观点来看,通过这四个步骤销售团队就能非常容易地适应敏捷。每个团队成员都能很好地接受这样的培训;立会和回顾会议也能够非常容易地取代以往的会议及流程。尽管产品的 Backlog 是个全新的概念,但是,一旦团队实施了这个概念,团队就能事半功倍地理解整个领域的业务。尽管有了这些有效的方法,Eric 却认为管理仍是他最大的挑战。

对于管理团队来说,转向敏捷并不是一件易事。他们如何保证每个销售人员的责任?他们如何奖励每个销售代表?如果团队的每个成员不尽职怎么办?对于完成他们的周目标而言,许多执行官认为立会太短。

为了确保销售团队真正地接纳了 Scrum 方法,管理层和团队成员都必须经历从传统意义销售理念的转变。通常来说,销售团队比较容易完成这样的转变,而管理层就比较困难。因此往往旧的流程会重新浮出水面,而新的 Scrum 框架被团队(出于管理层的影响)摒弃。

出于某些原因,我仍然不能接受公司将对自己的转变重构而将 Scrum 的销售剔除。但这仅限于在销售团队中我们充分意识到敏捷的力量。在采用敏捷方法后,我们整个团队第一次做到了公司所分配的销售指标,而非某个个人完成了自己的指标。

保守的管理者往往会回到他们所熟知的流程上,这是在组织架构中推行新流程的常见结局。这种失败并不仅仅可能发生在 Eric 的团队,而更是任何一支在敏捷转型中失败的团队的根本原因。Ken Schwaber 曾经写过一篇博客——《为何敏捷会失败》:

当团队试着采用敏捷方法时,某些方法的实践无法和团队或组织的文化保持一致。某些管理者往往相信,团队或组织只有通过他们自身的智慧和洞察力才能迎来成功。但具有自我组织意识的团队不会有类似情况发生。

即便失去管理层对于敏捷方法的支持,Eric 还是有办法在销售组织中实现 Scrum 框架。并且他证明了这种工程项目中的核心方法论也能够运用在销售团队中。类似的,Jeff Sutherland例举过销售团队如何做 Scrum 转型

自从销售团队引入 Scrum 概念,公司的收入翻了一番。尽管我们很难具体地论证这种情况是由于采用了 Scrum 而产生,但总经理表示,至少有 50% 的收入增加是团队采用 Scrum 方法的结果。公司在成长,我们必须做些什么来达到这个目标。采用 Scrum 是项重大变革,这意味着销售团队更具有自我导向;销售流程也更有效率;检验和适应的周期也更加频繁。

在 6 个月期间内,Eric 的团队不仅完成了他们的目标,而且他们意识到“尽管工作量比以前多了,但这种分享的工作模式能够带来更多、更稳定的收入和奖金。”通过实施 Scrum,他还总结了不少经验:自我管理的团队;团队成员比以往单打独斗时更容易集中在特殊的领域;团队成员间更好的工作与生活的平衡。就 Eric 看来,敏捷能够在销售团队中运用,并且这很有效!

查看原文链接: Agile and Sales


感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2013-08-22 22:261773

评论

发布
暂无评论
发现更多内容

大作业二

Geek_83908e

架构师一期

justauth-spring-boot-starter V1.3.5 发布成功

RD

OAuth 2.0 justauth 第三方登录

28 天带你玩转 Kubernetes-- 第二天(K8s 介绍)

Java全栈封神

Kubernetes k8s k8s入门 28天写作 k8s历史

大作业 1

郎哲

Spring Cloud Gateway (七)处理流程解析

Java 网关 SpringGateway

爱奇艺SOAR探索与实践

爱奇艺技术产品团队

安全

Prometheus学习笔记之查询【基础篇】

卓丁

Prometheus Monitor 监控告警 普罗米修斯 PromQL

关于私域流量与社群的思考

.

28天写作

详细教程丨如何利用Rancher和Kong实现服务网格?

Rancher

微服务 k8s

28天瞎写的第二百一三天:背代码的故事

树上

代码 28天写作

洞察

JiangX

创业 投资 认知 28天写作 洞察

海明威《老人与海》

抗哥

28天写作

推荐系统解构

DataFunTalk

大数据

想不想get和湖南卫视一样的现代直播?

亚马逊云科技 (Amazon Web Services)

中国金融科技权威盛会点赞了这个来自 AWS 的金融行业解决方案

亚马逊云科技 (Amazon Web Services)

云计算 AWS

SpringBoot 系列 2——SpringBoot原理分析

程序员的时光

程序员 springboot 七日更 28天写作

前端性能优化之指标

知识乞丐

大前端 28天写作

Activemq Jms 简单示例

Java 消息队列 JMS Activemq

追寻人生的意义

三只猫

28天写作

2021 十大技术趋势扑面而来,你准备好了吗?

李忠良

区块链 人工智能 云计算 大数据 架构

优化无止境,爱奇艺中后台 Web 应用性能优化实践

爱奇艺技术产品团队

大前端

python 基本数据类型-1

赵开忠

Python 28天写作

AWS x 红帽 | 以客户需求为驱动,加速开放混合云落地

亚马逊云科技 (Amazon Web Services)

云计算 红帽 AWS

领域驱动设计在爱奇艺打赏业务的实践

爱奇艺技术产品团队

架构 DDD

如果梦境取决于一串代码「幻想短篇 2/28」

道伟

28天写作

【薪火计划】09 - 员工激励理论

AR7

管理 28天写作

28 天带你玩转 Kubernetes-- 第二天(K8s介绍)

Java全栈封神

Kubernetes k8s k8s入门 28天写作 k8s历史

架构师训练营大作业

Shunyi

「架构师训练营第 1 期」

同理心

lidaobing

28天写作 了不起的盖茨比

Springboot 开发环境搭建和项目启动

武哥聊编程

Java springboot SpringBoot 2 28天写作

价值创造

JiangX

创业 投资 认知 28天写作 价值

当敏捷遇上销售_研发效能_Danny Ackerman_InfoQ精选文章