首页 >热门资讯> 客户关系管理(CRM) > 原则系列-敏捷开发适合B端产品吗? >

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

转载时间:2021.09.06(原文发布时间:2020.04.03)
279
转载作者:36氪企服点评小编
阅读次数:279次

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

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

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

敏捷的定义

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

敏捷价值观

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

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

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

  • 与客户合作而非谈判

  • 响应计划变更

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

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

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

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

敏捷模式开发的一些要点

很多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,这个会议不能举行或者成为形式。

迭代的回顾会也很重要,敏捷的一个重要思想是通过回顾不断迭代,不断提升,回顾会是复盘以及团队成长的重要步骤。

5、敏捷开发,先要做好MVP

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

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

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

7、庆祝小胜,复盘成长

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

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

作者:李东林(微信公众号:SaaS产品说;微信号:jianguzhuxin),菜小秘联合创始人,原ADP大中华区产品负责人,14年To B研发与产品设计,团队管理经验,主导过多款大型企业管理软件的设计、研发、上线,也有过数年移动互联网TO C的创业经验。

[免责声明]

资讯标题: 原则系列-敏捷开发适合B端产品吗?

资讯来源: 36氪官网

36氪企服点评

客户关系管理(CRM)相关的软件

查看更多软件

大厂都在用的客户关系管理(CRM)软件

限时免费的客户关系管理(CRM)软件

新锐产品推荐

消息通知
咨询入驻
商务合作