原则系列:敏捷开发适合B端产品吗?

1 评论 8043 浏览 58 收藏 12 分钟

敏捷模式随着移动互联网的发展变得越来越普遍与流行,那么对B端产品来说,是否可以运用敏捷开发模式呢?如果可以的话,又有哪些注意要点呢?

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

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

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

01 敏捷的定义

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

02 敏捷价值观

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

  • 交流比流程以及工具更加重要
  • 运行的软件胜于完整的文档
  • 与客户合作而非谈判
  • 响应计划变更

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

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

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

一般来说B端产品在确定产品定位要做什么之后,相对来说公司需要管理的业务是比较固定的,HR,CRM,ERP等企业信息管理软件都有相对固定的业务以及流程,不像C端产品那样每个功能的推出,市场的反馈有很大的未知性。

所以从这种角度来说,C端产品天然就是更加适合敏捷开发的;B端软件,如果可预测性越大,那么实际上对于敏捷开发的需求强烈程度越小,基于这个概念你可以去判断你的产品对于敏捷开发的需求程度。

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

04 敏捷模式开发的一些要点

很多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. 庆祝小胜,复盘成长

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

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

#专栏作家#

李东林,微信公众号:SaaS产品说,人人都是产品经理专栏作家。14年To B研发与产品设计,团队管理经验;主导过多款大型企业管理软件的设计、研发、上线,也有过数年移动互联网TO C的创业经验。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash, 基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 想问您是C,后来转B的吗,以及应届生更适合做哪个一些呢~

    来自广东 回复