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

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

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

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

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

一、敏捷的定义

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

二、敏捷价值观

正如“敏捷宣言”所宣称的，敏捷价值观如下：

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

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

三、敏捷开发适合B端产品吗？

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

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

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

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

四、敏捷模式开发的一些要点

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

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

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

实施敏捷模式，需要首先从组织架构出发

敏捷模式的建立先从组织架构的调整开始，产研需要建立一个支持敏捷模式的组织架构，每个敏捷团队人数在7-15人，不要超过15人，以7-9人为佳，里面包含PO，Scrum master，设计人员，开发人员，测试人员的角色。

如果项目比较复杂的时候，可以分割成为多个敏捷小组，在敏捷小组之上设置总PO，负责多个敏捷之间需求的协同（这个总PO一般就是产品负责人）。

敏捷小组应该尽量负责相对独立的功能模块，降低敏捷小组之间的耦合性，可以将和其他小组高耦合度的共通功能模块单独分成一个敏捷小组。

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

几个角色的注意事项

每个敏捷小组有多个角色，重点将PO以及Scrum master的角色说明一下，PO就是一般意义上面的产品经理，负责需求收集，优先级管理，需求整理以及相关原型逻辑设计，产品验收等等。

Scrum master这个角色很多公司有不同的理解，Scrum master实际上就是敏捷的教练，也为流程，项目协调以及项目进度来负责，Scrum master可以是独立的一个人来承担，中小公司也可以兼任，一个很强的PO是可以来兼任这个角色的（虽然一般不这样建议）。一般建议Scrum master可以在每个迭代让团队所有的角色轮流来进行兼任。

几个关键会议的注意事项

主要的几个会议包括迭代计划会、需求梳理会、每日站会、迭代评审会、迭代回顾会。

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

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

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

敏捷开发，先要做好产品的MVP

作为一个新产品的开发，首先第一步就是要通过敏捷模式开发完成mvp，推向市场，然后通过敏捷的迭代进行后续的开发会相对容易。关于mvp定义的内容可以参考我原来的一篇文章《如何做B端产品的MVP》。

一般来说mvp是由多个迭代组成，每个迭代都可以先内部发布，以及让外部客户参与评审，等MVP完成之后作为产品向外发布，进行PMF的试验，关于PMF的试验可以参考我原来的一篇文章《怎样做B端产品的PMF》

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

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

庆祝小胜，复盘成长

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

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

一、敏捷的定义

二、敏捷价值观

三、敏捷开发适合B端产品吗？

四、敏捷模式开发的一些要点

起源

流派

视频

书籍

敏捷动态

培训

关于我们