✏️
kingkong
  • Introduction
  • Go
    • 入门
    • 并发
    • 避坑
    • 测试
    • GC
    • 性能剖析PProf
    • 第三方库
    • 学习资料
    • 编写可维护Go语言代码建议
    • SOLID Go Design
    • 数组与切片
    • Go Mudules
    • mac 系统go升级 1.12到1.14
  • Kubernetes
    • 安装
    • 本质
    • 常用命令
    • 架构
    • 配置文件
    • Pod
    • Kubectl
    • 学习资料
  • Mac
    • Mac
    • Alfred4
    • 开机启动项管理
    • 升级macOS Big Sur11.1后蓝牙不能用
    • macOs磁盘清理之Homebrew数据清理
  • Docker
    • 常用命令
    • Dockerfile
    • Compose
    • Registry
    • Limit
    • Network
    • Volume
    • 特殊的进程
    • Namespace-Process
    • Namespace-Mount
    • Namespace-UTS
    • Namespace-IPC
    • Namespace-Network
    • Namespace-User
    • 踩坑
  • DevOps
    • ChatOps
    • GitOps
    • SecOps
    • VictorOps
  • Algorithm
    • raft
  • 中间件
    • etcd
    • Nacos集群部署
    • zookeeper
  • 分布式
    • CAP理论
    • BASE理论
    • Gossip协议
  • 网络
    • IP地址编址方式
    • C10k
    • NIO-BIO-AIO
    • Http
  • Linux
    • 常用命令
    • 常用命令1
    • 常用网络命令
    • 进程管理
    • 守护进程
    • Systemd
    • Unix哲学
    • 端口
    • 网络
    • CentOS目录结构
    • IT
    • 文件系统
    • 开源协定
    • 基础知识
    • bash
    • shell
    • vim
    • lvm2
    • btrfs文件系统
    • raid
    • 任务计划及周期性任务执行
    • find
    • 程序包的安装卸载
    • yum
    • sed
    • 用户、组和权限
  • 数据库
    • Redis
    • MySQL
  • 消息队列
    • kafka
  • 语言之道
  • 程序设计原则
  • LoadBalancer
    • LVS
    • HAProxy
  • 敏捷
    • 影响地图
    • 卡诺模型
    • 精益画布
    • 电梯演讲
    • INVEST原则
    • 复杂系统
    • AARRR模型
    • 用户故事
    • 看板
    • Scrum
  • MicroService
    • 分布式链接追踪系统
    • ServiceMesh
    • 如何设计微服务
    • 领域驱动设计
  • 项目实战
    • 多通道告警服务
    • IAM
  • 管理
    • 沟通
    • 演讲
    • 面试官
  • Authorization
    • JWT
  • Spring
    • IoC
    • SpringFramework
    • Spring核心编程思想
  • Java
    • SPI机制
    • Jar
    • tutorial
    • 面向对象
    • 核心类
    • 泛型
    • 集合
    • IO
    • 日期与时间
    • 单元测试
    • maven
    • 函数式编程
  • Mix
    • Bookmark
    • WorkStation
    • 快速压力转换
    • 手机拍照
    • markdown画图
    • RESTful API设计
    • 如何做单元测试
    • 赶走脂肪肝
  • Aphorism
  • 互联网
    • DNS
    • Nginx
  • Rust
  • Quarkus
    • java.util.zip.ZipException: zip END header not found
  • Python
    • tutorial
  • 区块链
    • Substrate
    • BTC
Powered by GitBook
On this page

Was this helpful?

  1. 敏捷

卡诺模型

Previous影响地图Next精益画布

Last updated 4 years ago

Was this helpful?

卡诺模型将产品需求划分为五种类型: 1. 兴奋型:指超乎用户想象的需求,是可遇不可求的功能。比如用户想要一个更好的功能手机,乔布斯带来了 iPhone,这会给用户带来极大的满足感。 2. 期望型:用户的满意度会随着这类需求数量的增多而线性增长,做得越多,效果越好,但难以有质的突破。比如,一个电商平台最开始是卖书,后面逐步扩展到卖电脑、家居用品等多个类别。用户更多的线性需求被满足,满意度自然也会提升。 3. 必备型:这些是产品必须要有的功能,如果没有的话,会带来非常大的影响。不过有这些功能的话,也没人会夸你做得有多好,比如安全机制和风控机制等。 4. 无差别型:做了跟没做一样,这就是典型的无用功。比如你花了好大力气做了一个需求,但是几乎没有用户使用,这个需求就属于无差别型。 5. 反向型:无中生有类需求,实际上根本不具备使用条件,或者用户压根不这么想。这类需求做出来以后,通常会给用户带来很大的困扰,成为被吐槽的对象。

对于五类需求来说,核心要做到 3 点: 1. 优先规划期望型和必备型需求,将其纳入日常的交付迭代中,保持一定的交付节奏 2. 识别无差别型和反向型需求,这些对于用户来说并没有产生价值。如果团队对需求的分类有争议,可以进一步开展用户调研和分析。 3. 追求兴奋型需求,因为它会带来产品的竞争壁垒和差异化。不过,对于大公司而言,经常会遇到创新者的窘境,也就是坚持固有的商业模式,而很难真正投入资源创新和自我颠覆。这就要采用精益创业的思想,采用 MVP(最小可行产品)的思路,进行快速验证,并且降低试错成本,以抓住新的机遇。

在面对一大堆业务需求的时候,首先要进行识别和分类。当然,最开始时,人人都相信自己的需求是期望型,甚至是兴奋型的,这也可以理解。毕竟,这就好比公司里面所有的缺陷问题等级都是最高级一样,因为只要不提最高级,就会被其他最高级的问题淹没,而长期得不到解决。而解决的方法,就是让数据说话,为需求的价值建立反馈机制,而这里提到的价值,就是用户价值。

原文

07 | 业务敏捷:帮助DevOps快速落地的源动力