通俗来说#xff0c;敏捷开发是一个软件开发流程#xff0c;是一个采用了迭代方法的开发流程

简单来说#xff0c;迭代就是把一个大产品拆分出一些最小的实现单位。

完成不同的迭代就最…

敏捷开发是以用户的需求进化为核心采用迭代、循序渐进的方法进行软件开发。

通俗来说敏捷开发是一个软件开发流程是一个采用了迭代方法的开发流程

简单来说迭代就是把一个大产品拆分出一些最小的实现单位。

完成不同的迭代就最终完成了产品但因为迭代很小可以边开发边验证

一个产品需要研发6个月在第一个月就会拿出一个产品来当然这个产品会很不完善

会有很多功能还没有添加进去bug很多还不稳定但不停地优化根据反馈去调整下一个迭代的内容最终可以达到比较好的产品效果。

实际迭代流程

需求评审是整个研发迭代流程中非常重要的一环对于产品经理来说尤其要重视这个环节。

这也是产品经理参与最多的环节。

需求评审一般分为产品内部需求评审和项目组正式需求评审。

1产品内部需求评审

参与人项目的相关负责人产品经理、项目经理、开发、测试等实际参与项目的人员。

2迭代计划

迭代计划是由项目经理在需求评审后针对迭代给出的详细计划。

通常包含以下内容

产品经理根据用户反馈、市场需求、用户调研的结果制定需求并提交到项目经理排期

产品经理是一个产品的设计师和舵手所以产品经理了解敏捷研发流程并具备一定的迭代思维

可以协助项目经理和研发经理实现版本管理做好质量和效率的保障也有利于更好地融入研发团队跟进产品实现、团队沟通以及提前规划产品节奏

前面我们介绍了一个典型敏捷开发的互联网产品的开发架构和开发流程。

很多没有做过产品的同学会疑惑那么多功能特性是怎么加入研发版本的难道是老板说做哪个就哪个

怎样才能拥有一个有效的组织管理方式坦白地讲在很多创业团队也许还真是老板说做哪个开发就干哪个了但这样会带来一些问题

需求的优先级不明确根据个人喜好也许把不重要的优先实现了敏捷但干了无用功。

需求会有遗漏导致产品的主流程有缺失开发完成后产品不能使用这种也不少见。

后续版本管理不明确开发和其他团队相关成员一直是在无序的忙碌中。

所以一般有经验的产品研发团队中产品经理都会采用以上的产品规划“四步法”梳理敏捷迭代下不同特性的版本管理

第一步罗列特性

所谓的罗列特性也可以称为整理特性。

通过前面的分析研究通过团队内的讨论及头脑风暴其实在进入开发前

一个产品经理的“小本本”里面已经记录了很多特性但这些特性在没整理前还只是一些思路一些想法所以第一步是把这些特性都正式地罗列下来

第二步特性分类

特性分类是整个过程中比较考验产品经理功底的一项任务——根据那么多纷繁罗列的特性给他们分类并做好逻辑梳理

第三步排优先级

2优先级高的特性尽量少由于考虑敏捷如果都是P0那版本就变得非常臃肿了

所以我们要适度地把特性拆在其他优先级中这里有时候会有些争议怎么判断哪个更重要一般由产品经理根据实际情况来判定如果有争议的话让老板拍板

第四步版本节奏

前面已经把特性的优先级排列好了剩下的就是把特性放置在相应的版本中

初创阶段

初创阶段包含新创和拉新。

这个阶段是产品初期研发形成产品特点获取种子用户的过程

成长阶段

成长阶段包含活跃和营收。

这个阶段产品的主线方向已经确定并且已经有了核心用户和核心体验流程

所以更需要关注的是如何提升活跃用户的活跃度如何实现产品的商业模式。

这个阶段的迭代版本需要兼顾版本质量和效率

一方面版本不宜过快而是以稳定为主保障用户体验。

另一方面则需要将用户痛点扩大利用不断更新来黏住核心用户

成熟阶段

成熟阶段包含留存和回流。

产品到了这个阶段主线需求、商业模式已经比较成熟用户规模也趋于稳定

在这个阶段的产品需要做细致活追求用户体验的极致同时需要做好用户关怀和流失用户回流

互联网公司开发中,稍微规范,有成型团队的公司,都会用敏捷开发模式去迭代产品

就是先实现一个小的,去验证,跑通流程,然后在逐渐迭代,最后一步一步优化

2024-07-07

产品经理-的困惑1-只有什么也不会的同学才会选择产品经理岗位吗(2)

2024-06-30