20251213-mvp的关键方法
最近做了不少开发和项目，但是我发现总是陷入一个误区，开发了许多demo，但是没有拿到结果就放弃转投入下一个，每次开始的兴致勃勃，但是做的时候，总是习惯性放弃。
仔细想来还是开头就没想清楚了就开始了，等到做到一些节点，发现其实也不是我喜欢的项目或者许多关键问题没想清楚，其实它还是很难的，就想要放弃了。
反思下来，这里我存在着两个问题：
- 没想清楚就开始：陷入启动尝鲜的多巴胺陷阱，开始尝鲜很简单，但是新鲜劲头一个，当直面问题的时候，没了一开始的热情，就会发现许多现实的恩替。
- 想太多而不开始：这也是一个作为前架构师的惯性问题，之前我做的一些项目，大多数都是许多人开发的，作为关键设计人员，我必须想的全面，所以总是花不少时间设计，考虑全面，考虑许多细节，经过多次评审，再才开始。这放在自己项目里面，最大的问题就是过度设计，而忽略了即使启动的重要的，只有让项目跑起来，项目才会推着我们进步，如果迟迟过度设计，或者一开始就想着大而全，则容易忽略了验证需求，可能一开始就走入了死胡同。
这些问题，其实仔细想来也和我投资中的困境很像，要么动的太多，要么完全不动不行动，其实这些都不对。要么说投资是艺术，做产品是艺术，就是这个度很难得把握，我们做多了不好，做少了不行。拿捏那个刚刚好的mvp，真的是身为创业者、投资者的修行课。
之前总结了创业者快速闭环的五步骤：
- 做先验认知的基本了解，迅速建立一个事物、领域的基本认知。
- 快速学习对标对手：建立基本审美，了解到自己要达到的水平如何。
- 快速制定mvp计划，展开行动。
- 快速闭环迭代，持续复盘，持续总结，持续优化
- 将经验的只是总结成系统、习惯、本质，升华事情本身。
今天的反思里面，我也对于这套体系进行了细化，做产品也可以按照这五步，但是需要细化：
了解大概
- 动作：保持宏观视野，不要下沉到细节实现、api、架构
- 关键问题：用户的核心痛点是什么，关键假设是什么？核心业务指标
- 注意：这里关注的是核心业务指标，不是代码工程实现目标，要关注业务完成度，而不是技术上的实现了什么东西
竞标竞争对手
- 只比功能，不比实现
- 操作: 列出3个竞品，记录他们解决了什么问题，而不是用了什么技术栈
心中设一支笔
- 画最短路径，而不是蓝图
- 操作拿出一张纸，画出输入到输入的最短逻辑，拒绝为这个流程添加过多架构、数据的东西
计划实现一遍-mvp plan
新增动作: 可行性裁剪
问自己：如果必须在2小时内做出demo，我会怎么做？
只保留那个大难的步骤，其他比较为未来项目
不断迭代的反馈循环
- 新增动作：意图校准
- 每次迭代技术，强制检查：我现在的代码是解决最初的问题，还是在解决突发奇想的新问题?"
- 如果是后者，立刻砍掉！
务必关注着自己要从传统架构师到产品架构思维的转变线路：
过去做架构师总考虑的是怎么未来拓展性好，因为以前可能产品已经千百次验证了需求，或者许多需求就是客户的刚需，不存在要验证，但是现在我们作为产品架构师或许真的要转变的这种认知了，我们的每一次投入很很宝贵，每个人的时间、精力都是有限资源，我们需要给家庭、自己带来价值，就必须去思考什么事最重要的事情，什么是投入性价比最高的事情，不然我们还在学习技术，还在不断尝试新工具新方法，可能就是对于家庭的不负责任！
这就是今天最为重要的一课！