敏捷-精益产品开发

先了解一下制造业中的精益思想,有助于我们加深了解精益产品开发。



精益思想五大核心原则

  • 定义价值
  • 识别价值流
  • 让价值持续流动起来
  • 用户价值拉动
  • 精益求精
    精益价值观
  • 挑战现状
  • 改善
  • 现地现物
  • 尊重
  • 团队协作
    精益生产模式
  • 准时化:仅在需要的时间生产需要数量需要的产品,目的是灵活应对变化,消除生产过剩的浪费。
  • 自动化:自动发现异常停止生产现时、现地分析问题决绝根本原因,目的通过不断的发现问题、暴露问题、解决问题,让我们生产变得更加可靠,让生产系统能够更加顺畅地运作。

精益制造与精益产品开发实践体系


  • 精益产品开发的目标一定需要从用户的角度或者从组织外部的角度出发来定义。我们把这个目标定义成:“顺畅和高质量的交付有用的价值”。
  • 这里面有三个关键词:
  1. 顺畅,交付的过程要顺畅,也就是让价值能够持续流动起来;
  2. 高质量,交付出去的东西要符合质量要求;
  3. 有用,交付的价值必须是用户能够接收愿意买单的才能被称为有用的价值。顺畅、高质量、有用,这三者缺一不可,构成了精益产品开发的最终目标。

精益产品开发的定义:最小可行产品、持续部署、AB测试、可操作指标、产品运用的迭代循环及其他策略。

最小可行性产品:新的产品语序团队已最小的努力收集关于客户的需求。以楼盘为例,各位有没注意到,大部分楼盘在建设初期会建展厅、户型模型、然后开始开放给购房者,让购买者参与进来。这么做的好处以最小的产品实现最大化的需求收集,增加价值。软件行业也是一样,通过小版本的产品放入市场,观察其市场反馈并作出响应的更改,通过不断的小产品刺探来决定产品的价值。
持续部署:消除不必要的浪费,通过不断的小版本迭代部署,快速实现软件在市场的扩张。大家可以发现,一个新的应用或系统,最初的更新是很频繁的,这么做的目的有利于提高软件质量和客户黏着度,在PV和IP为王的时代,通过持续部署来实现增加产品价值。
AB测试:通过不同的版本,刺探最适合市场需求的产品价值。“尝鲜版、体验版”等大伙在APP或者应用中都不会少见。
有明确的商业指标:笔者有个朋友公司做游戏SDK研发通过收集用户行为,分析并制定推广策略来实现软件的最大利益。“杀熟”一次大家相信不陌生吧。这一些都需要真实的数据而非高大上的包装,除非一开始产品动机就不纯...例子太多不介绍了。
产品运营的迭代循环:产品开发的速度是关键因素,如何快速开发出一款基于最低可行性的产品,并投向市场?通过市场的数据分析:用户行为等来学习、改进产品或者决定产品是否继续开发。

原文地址:https://blog.51cto.com/14082130/2473724

时间: 2024-07-29 12:16:38

敏捷-精益产品开发的相关文章

敏捷21天打卡-精益产品开发最佳实践 之 “AB测试"

”一个错误的背后往往存在一个正确的假设,对假设的肯定程度越高引发的错误越严重!“ 从上章节中“MVP”中一文中我们了解到,最低限度的可用的产品是MVP的精髓,其目的在于迅速验证产品的可用性及市场用户的反馈:不能市场用户需要一辆汽车,我们给对方一辆自行车,典型的违背市场的原则. 伟人曾说过“实践出真知”,对于软件行业亦是如此,有了最低限度的可用产品,这是就需要收集市场的反馈,根据反馈调整产品策略,A/B测试是众多工具/方法中的一种. “推出一个代步工具.节约用户上下班时间,从而让用户有更多的时间来

精益软件开发与精益管理:从一家关闭的汽车厂重焕青春说起

“把工厂搞砸的是系统,不是人!” 弗里蒙特汽车装配厂是通用汽车于1982年关闭的工厂,当时劳资关系几近崩溃,工人们边工作边酗酒和赌博.1984年通用与丰田成立了合资企业:NUMMI,启动了弗里蒙特的工厂并重新雇用了原来的工人.这些工人被送到日本的丰田城学习丰田生产系统(TPS),之后短短三个月内,NUMMI就生产出了质量近乎完美的汽车,而且成本比以前工厂时期低很多. 持续改善 当你倾听那些从弗里蒙特装配工厂开始一直坚持到NUMMI结束的工人们谈话时,一个反复被提及的主题就是团队协作.这也许有些老

敏捷价值流开发 (产品级敏捷)

许多今天还是明星的科技公司, 却往往因所生产的产品, 对客户不再产生任何的 "影响力", 而面临即将黯然关门, 倒闭的命运? 在这不可预期且淘汰迅速的大环境下, 是否可藉由精益敏捷开发, 而使产品的研发团队, 可以 "以最少的产出, 却对外部的用户, 产生最大的影响与效益" ? 答案是 "肯定的" ! 敏捷价值流开发 (产品级敏捷), 便是以精益敏捷开发的思维, 从外部使用者的视角, 指导著产品的研发团队, 从建构产品级的特性到各版本的研发, 如

中小企业团队敏捷产品开发流程最佳实践

近期因为疫情的影响,不少互联网公司开始尝试远程工作.也出不了少如何做好远程工作的方法,我认为不管是场地办公还是远程办公都依赖于原来的产品开发流程. 我曾经遵循CMMI5的流程管理过15人左右的跨国/语言/文化团队,也遵循敏捷Scrum管理过9人的小团队,还针对一个从4人发展到近30人的团队尝试过各种方式的项目管理方法,这其中有2C和2B的产品,也有平台/生态型产品. 最后在自己创立公司的5人小团队(场地和远程办公融合方式)中摸索出了我认为最适合中小企业产品开发流程与管理方法. 今天我们聊聊产品开

“产品级敏捷” 的这条路; 逐步的形成一高效的产品开发生态系统

2015. 7.1, 我在杭州-. 这一路走来真的相当的不容易; 这一周多来, 大夥跟著一个 "疯子顾问", 经历了不停的交流,辩论, 实践, 验证, 深度思考? 终于, 踏上了产品级敏捷的这条路-.. 以外部客户的视角, 制订出可使客户对产品有信心的版本节奏; PI (Program Increment) ? 拉通产品的特性负责人, 开发骨干与测试经理, 经由可视化的需求看板与 "加法, 减法" 的协作模式, 识别每一轮 PI 所需完成的开发与集成测试的特性场景?

开放产品开发(OPD):OPD框架

在 开放产品开发(OPD):开篇 中讲了一下OPD是什么,以及它主要指引的方法,这篇文字将给大家介绍一下OPD框架. 一个公司有三种经营模式,像游戏代理的属于运营型,做企业定制项目管理软件的属于项目型:互联网的大多数属于面向大众的产品型.而不管是哪种类型,其实背后都是有产品的支撑,游戏本身的主题就是游戏产品,定制项目的终极目标也是产品,正因为产品的重要性,所以OPD核心关注的就是有什么方法来支持一个产品如何从无到有开发出来? 我们生活中到处都是产品,iPad.小米,超市里你看到的所有东西其实也都

开放产品开发(OPD):开篇

OPD?这是什么玩意?google一下.忘记说了,最近google被封锁的厉害,那就百度一下吧.可惜,OPD找不出是什么.你今天你找不到是正常的,因为之前还没有OPD,而现在才开始有OPD这个东东.相信很多人听过敏捷个人了,这个词汇到现在已经很容易被搜索到了,敏捷个人创立以来,我一直未放弃对IT技术方法的实践和整理,而OPD就是我又要创建的一个东西,全称是Open Product Development.没错,是OPD,不是IPD,当然两者会有些关系,之所以我取Open,是因为我的IT产品开发方

案例干货|用友罗涛:打通产品开发的任督二脉

[精彩预告]用友集团开发管理部总经理罗涛将于5月21日在上海MPD工作坊进行<破解4小时上线传说>的3小时分享.通过一个故事引入互联网+产品开发的迭代思路.价值发掘和发布规划等核心思想和工具,将结组利用小图团队的力量使用影响地图.用户故事地图.无代码验证等演练手段在3个小时的工作坊内快速发布一个产品,带领学员在操作中理解精益和敏捷.文章来源:公众号 :msup(ID:msupclub)关注回复“体验工坊”有惊喜. 导读:在面对需求的变化无常.人员的变动和技术的更新时,对客户价值的识别尤其重要,

DevOps是敏捷在软件开发团队的另一应用

DevOps是敏捷在软件开发团队的另一应用.那么相比之下,哪个更胜一筹? 一边,有业界认可的scrum master,它的朋友极限编程者,以及由其衍生的 LeSS.SAFe.DAD等,是敏捷. 另一边,有精益文化机器,用代码持续交付其基础架构,它的名字左边是开发,右边是运维,合起来就是DevOps. 虽然我已尽我所能在普及这两个概念,但人们关于敏捷和DevOps的争论依然让它们听起来完全不同.更糟糕的是,尽管他们都已经有了各自的行业术语和口号,但两者的概念还是没办法准确定义.鉴于敏捷诞生早于De