专栏首页ToB行业头条敏捷开发适合B端产品吗?

敏捷开发适合B端产品吗?

来源 / SaaS产品说

作者 / 李东林 · 编辑 / jenny

在中国移动互联网流行之前的2011年以前,B端软件的研发大多还是传统的瀑布式研发的方式,后面随着移动互联网的发展,To C端软件普遍使用敏捷模式来做。

但是目前仍然还有很多人采用瀑布式方式来进行B端软件的开发,不看好敏捷模式进行B端产品的开发,那么重流程,业务高耦合度的B端软件是否适合敏捷的开发模式?

今天我们探讨一下什么样的B端软件适合敏捷开发,以及B端软件进行敏捷开发的一些要点,在此之前我们看一下敏捷的定义以及价值观:

01

敏捷的定义

敏捷是一种管理项目的方式。它将大型项目分解为可管理的小块,称为迭代(sprint)。在每次迭代结束时,都会产生一些有价值的功能,每次迭代期间的产出物都应该能够发布出去,用来获取市场用户的反馈。

正如“敏捷宣言”所宣称的,敏捷价值观如下:

l 交流比流程以及工具更加重要

l 运行的软件胜于完整的文档

l 与客户合作而非谈判

l 响应计划变更

敏捷意识到软件项目本质上是不可预测的。在任何项目过程中,市场,团队,战略都可能会发生变化,在产品推向市场之后,变化也是随时发生的,敏捷拥抱了这种不可预测性。通过将项目分解成小块,可以轻松地在项目中对功能进行优先级划分,进行添加删除,在传统的瀑布项目中,这是不可能的,敏捷模式大大增加了项目成功的可能性,也降低了市场试验成本。

02

敏捷开发适合B端产品吗?

了解了敏捷的定义以及价值观,我们实际上知道了敏捷开发的本质是什么,是拥抱变化,拥抱不可预测性,更好的应对产品的不可预测性。

一般来说B端产品在确定产品定位要做什么之后,相对来说公司需要管理的业务是比较固定的,HR,CRM,ERP等企业信息管理软件都有相对固定的业务以及流程,不像C端产品那样每个功能的推出,市场的反馈有很大的未知性,所以从这种角度来说,C端产品天然就是更加适合敏捷开发的,B端软件,如果可预测性越大,那么实际上对于敏捷开发的需求强烈程度越小,基于这个概念你可以去判断你的产品对于敏捷开发的需求程度。

B端项目又分为那种单个客户定制化的项目或者适合大量客户的产品,对于一个面向广大市场的通用产品来说,产品时间跨度大,市场客户情况复杂,竞争对手多,这样的情况基本来说都是敏捷模式是更适合的一种情况,对于一些定制化的B端项目,如果项目周期跨度很长,为了减少不确定性,也是建议采用敏捷的方式来进行迭代,如果一些周期短的定制化项目,可以基于情况考虑瀑布式的开发方式。

03

敏捷模式开发的一些要点

很多B端产品公司想去实施敏捷模式,但是很难真正落地,或者最后搞的四不像,笔者将B端软件敏捷实施中的一些要点概括如下,希望对大家有一些帮助:

1: 如果要实施敏捷模式,公司首先需要在理念上面统一起来。

首先我们要知道敏捷模式的实施不只是产研部门的事情,敏捷模式是全公司的事情,公司这边产研和业务,销售部门建立密切合作而非对立的价值观和文化。公司内部各部门通力协作,以客户为中心,形成产品快速迭代,快速推向市场,快速收集市场客户反馈,快速基于反馈来进行调整的闭环。

2: 实施敏捷模式,需要首先从组织架构出发。

敏捷模式的建立先从组织架构的调整开始,产研需要建立一个支持敏捷模式的组织架构,每个敏捷团队人数在7-15人,不要超过15人,以7-9人为佳,里面包含PO,Scrum master,设计人员,开发人员,测试人员的角色。如果项目比较复杂的时候,可以分割成为多个敏捷小组,在敏捷小组之上设置总PO,来负责多个敏捷之间需求的协同(这个总PO一般就是产品负责人)。敏捷小组应该尽量负责相对独立的功能模块,降低敏捷小组之间的耦合性,可以将和其他小组高耦合度的共通功能模块单独分成一个敏捷小组。

在产研部门之外,每个相关的业务部门,包括市场,运营,销售部门都要有项目的相应的Stakeholder, Stakeholder和PO 团队在需求业务,需求优先级,产品评审,产品发布方面密切合作,贯穿整个产品过程,共同协作为产品负责。

3: 几个角色的注意事项。

每个敏捷小组有多个角色,重点将PO以及Scrum master的角色说明一下,PO就是一般意义上面的产品经理,负责需求收集,优先级管理,需求整理以及相关原型逻辑设计,产品验收等等. Scrum master这个角色很多公司有不同的理解,Scrum master实际上就是敏捷的教练,也为流程,项目协调以及项目进度来负责,Scrum master可以是独立的一个人来承担,中小公司也可以兼任,一个很强的PO是可以来兼任这个角色的(虽然一般不这样建议)。一般建议Scrum master可以在每个迭代让团队所有的角色轮流来进行兼任。

4: 几个关键会议的注意事项。

主要的几个会议包括迭代计划会,需求梳理会,每日站会,迭代评审会,迭代回顾会。这里重点说明强调一下每日站会,每日站会由Scrum master来组织,说明昨天进展以及今天工作内容,敏捷强调的是建立一个自驱的团队,任务的领取需要让大家主动来领取,不要强行分配的方式,这里不要担心大家都领取简单的任务,团队保证足够透明的时候,实际上这样的事情很难成立。

迭代的评审会需要让业务部门的stakeholder充分参与起来,进行产品的demo,这个会议不能举行或者成为形式,当然这个环节的执行情况很多时候取决于公司层面的宣导,以及产研外部的stakeholder的具体情况。

迭代的回顾会也很重要,敏捷的一个重要思想是通过回顾不断迭代,不断提升,回顾会是复盘以及团队成长的重要步骤,很多团队在执行的时候为了赶进度会漏掉这个环节,实际上这个环节很重要。

5:敏捷开发,先要做好产品的MVP.

作为一个新产品的开发,首先第一步就是要通过敏捷模式开发完成mvp,推向市场,然后通过敏捷的迭代进行后续的开发会相对容易,关于mvp定义的内容可以参考我原来的一篇文章"如何做B端产品的MVP",一般来说mvp是由多个迭代组成,每个迭代都可以先内部发布,以及让外部客户参与评审,等MVP完成之后作为产品向外发布,进行PMF的试验,关于PMF的试验可以参考我原来的一篇文章“怎样做B端产品的PMF”

6: 对于复杂的业务,化繁为简,层层递进。

一般来说复杂的业务更具未知性,无论是市场反应还是从产品质量保证来说都是如此,面对复杂业务一个原则是化繁为简,将一个复杂的内容变成多个简单的部分,分迭代实施,层层递进分步去试验市场的反应,从而降低市场以及产品质量等各方面的风险,不要一下子推出一个非常复杂的内容,实际上用户理解以及接受使用的成本也会比较高。

7: 庆祝小胜,复盘成长

敏捷相对冗长的瀑布式开发,还有一个好处,就是可以看产品团队快速看到产品的效果,一个产品的最终胜利是由这些小的迭代胜利组成的,在每个迭代的胜利之后,除了复盘的成长,还需要庆祝这些小胜利,鼓舞团队,慢慢形成一个团结,高速成长,战斗力强,士气高涨的团队。

总结上面内容的几个关键词,便于大家记忆,那就是建立自驱的团队和机制,和业务团队合作,高频交流,化繁为简,持续快速交付产品,复盘成长。另外敏捷模式在落地方式上面是基于公司情况,会有很多小变化的,大家可以基于自己公司的情况摸索选择最好落地的方式来实操。

本文分享自微信公众号 - ToB行业头条(wwwqifu)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-09-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • B端产品经理必知的底层实践认知有哪些?

    众所周知,知行合一并不容易,将概念理解到落地仍有很长的路要走,本篇主要从B端产品经理落地实践角度,所需要具备的认知,从而更好实现从概念到价值的落地。

    ToB行业头条
  • 上云以后,SaaS化RPA的未来在哪里?

    先是AA(Automation Anywhere)推出全球第一个纯基于网络的云原生数字化劳动力平台Enterprise A2019。不久后,UiPath也在20...

    ToB行业头条
  • 消除B端产品盲点的方法

    对于这些盲点我们能做些什么呢?意识到它们的存在是一个开始。接下来是识别他们。这需要对客户的业务环境有更广泛的认识,对 B2B 产品有全面的理解,并更好地把握 B...

    ToB行业头条
  • 《大产品,小团队:携程敏捷技术与管理转型实战》

    敏捷并不是什么新玩意儿,但它已经成为这个瞬息万变的互联网+科技商业时代的主流管理运营体系。如果一个企业还没开始拥抱敏捷并付诸实践,那它很快就要被淘汰了!

    Vaccae
  • 敏捷 | 如何填好推进的坑?

    无论你的公司是在做敏捷转型还是一开始就使用敏捷,在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享几个在推进过程中常见的坑,以及如何填坑。

    Edison Zhou
  • 落地敏捷开发的12个建议,打造自定义开发管理模式!

    目前软件开发业界已存在多种开发合作模式,各有其特点、适用性和局限性,没有一种开发模式是通用又完美的,可以适用任何组织、任何业务的研发协作。所以每个公司研发组织要...

    嘉为科技
  • 你大概走了假敏捷:认真说说敏捷的实现和问题(手绘版)

    今天你敏捷了没有?“敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、...

    薄玉桴
  • 敏捷开发学习分享

    敏捷不是快,而是拥抱变化(不断反馈的一个过程)。                                                       

    业余草
  • 「首席看点」也许敏捷就是问题所在

    “生命、宇宙和一切终极问题的答案?”(道格拉斯·亚当斯,《银河系漫游指南》)。也许吧,这取决于你问谁。

    首席架构师智库
  • ​CODING 敏捷实战系列课第五讲:敏捷中国史

    大家好,今天我来为各位同学梳理一下敏捷进入中国的过程和发展。首先来看一下招商银行的一项数据。过去讲科技创新是一个很神秘的事情,不知道应该怎样去创新从而得到一个好...

    CODING

扫码关注云+社区

领取腾讯云代金券