迭代思维与MVP产品的规划方法

​

快速迭代的价值与挑战

快速迭代：以天或者小时为单位，持续的完善产品，交付到用户的循环过程

快速迭代的价值：

• 时间是最大的成本，机会转瞬即逝，赢得市场先机。
• 快速验证需求，减少不对用户产生价值的投入（Fail fast, Fail better）。
• 快速验证方案，提高研发效率。
• 加速反馈回路，给到团队和自己及时的激励。

快速迭代的挑战：

• 产品设计者：能梳理清楚业务流程，抓住用户的重点需求，能把客户需求转换为系统的需求。
• 开发者：充分理解用户需求，有足够的能力，能用简洁的方案来设计出易维护的系统。

根本挑战：

• 市场、用户、技术、环境变化太快，产品开发跟不上节奏。

• 几乎不能从一开始就设计一个完美的，能够使用未来长时间变化的方案

• 几乎没有人愿意承认，自己没有足够的力（或条件）设计一个完美的产品（系统）。

OOPD 方法识别产品的核心功能

OOPD：Online and Offline integrated Product Development

OOPD迭代的原则：

• 自助原则：做自己的产品，自己用自己的产品，吃自己的狗食。
• 0day：找到明确的核心问题，拆解目标，抓住核心的问题，忽略掉一切细节，0day发布。
• 时限原则：设定时限，挑战自我，不给自己写BUG的时间。
• 不完美原则：不做完美的产品。（没有完美的产品，不去为了完美而浪费宝贵的资源）
• 谦卑原则：能够看到自己的局限性，获取用户反馈，持续迭代，听取用户的声音。

MVP：minimum viable product 最小可用产品

• 内裤原则 ： MVP 包括了产品的轮廓，核心的功能，让业务可以运转。
• 优先线下：能够走线下的 优先走线下的流程，让核心的功能先跑起来，快速的做用户验证和方案验证。
• MVP的核心：忽略掉一切技术的细枝末节，做最合适的假设和简化，使用最短的时间开发出来。

迭代思维最强大的是产品思维逻辑，互联网唯快不破的秘诀。

如何做好技术方案设计与工作拆解

技术方案

• 做技术方案设计的前提条件
  • 有明确的的用户场景，用户如何和产品进行交互，期望拿到什么预期结果。
  • 有清晰定义的业务流程

• 用什么工具设计？

  • Visual Paradigm
  • Lucid Chart
  • Visio
  • Gliffy
  • Draw.io
  • Astash
  • StarUML
  • …..

  推荐使用白纸，不用工具就是最好的工具。

• 产出的技术方案文档要素

  • 产品背景（用户场景、产品目标、引用到的业务流畅、产品需求文档）
  • 要解决的问题列表，系统不解决的问题列表，系统的限制。
  • 对于问题的不同的解决方案的对比，阐述各个主要的问题如何被解决。
  • 所选的整体的流程图（序列图），模块关系图，重要的接口，实体的概念定义。
  • 除了功能之外的其他方面的设计，包括安全、性能、可维护性、稳定性、监控、扩展性、易用性等。

工作拆解

​ 任何事情，只要把它拆解的够细，都能够完成它。

• 工作拆解的原则：
  • 优先级：主流程上，不确定的工作先完成（建议提前一个迭代做调研）。
  • 核心流程优先：核心工作优先，先把主流程跑通。
  • 依赖：减少不同人之间的工作依赖，并且保持团队工作拆解的透明，预留20%Buffer。
  • 拆解粒度：拆解到每项子任务0.5-1天的粒度，最长不要超过两天。

如何保证交付质量和可持续迭代

定义好产品需求，产品需求从根本上决定了产品的质量。

系统上有整体架构方案的设计，评估，评审，系统决定了软件实现的质量。

工程的角度持续交付的最佳实践推荐：

• Code Review：每一次提交都有CR，每次commit 代码量控制在200行y以内。尽量频繁的commit。
• 单元集成：项目开始简历单元测试的机制，在持续集成中自动运行。
• 自动化回归：对预发/线上系统做KPI/页面自动化测试（Postman/Robot Framework）
• 使用CICD机制对心痛进行自动化的打包，测试，部署，线上验证。
• 发布过程做到可监控，可回滚。
• 对于大量用户使用的产品，使用灰度机制。
• 架构上对于意外的并发访问，进行限流，降级。
• 架构上使用配置开关，对系统功能能提供实时的开启/关闭的服务。
• 对产品简历A/B Test 机制，通过数据快速对比不同的版本，不同的方案。
• 自动化所有的事情，代码化所有过程：代码化配置，代码化部署流程，代码化基础设置。
  • 声明式API，CICD Pipeline，K8S，Helm , Terraform