前几篇写了功能原型、技术方案、用户调研。现在到了最硬核的部分——组局的业务流程状态机。
一个产品好不好，70% 看设计，30% 看代码。但状态机写错了，产品从第一天起就是错的。
这篇文章我打算讲透：一个组局从”我想打场球”到”打完球各回各家”，中间经历了哪些状态，状态之间怎么跳转，跳转的触发条件是什么，以及 30 多个边角case怎么处理。
一、为什么状态机是这个产品最难的部分社交产品的状态...
前几篇写了产品思路、功能原型、技术方案。但在你动手之前，有一件事比任何代码都重要：验证需求是真的存在，而不是你脑补出来的。
这篇文章是一份可以直接拿去用的用户调研指南。
一、为什么要做用户调研因为你现在做的所有设计——功能、流程、技术选型——都是基于一个假设：
“失业的人需要约人打球钓鱼”
这个假设可能是对的，也可能不对。在写一行代码之前，你应该去验证它。
而且不止验证这一个假设。下面这...
上一篇把功能拆清楚了。这一篇说技术——用什么堆出来，怎么部署，成本多少。
如果你不是开发者，可以跳着看，重点看”为什么这么选”和”要花多少钱”。
一、整体技术栈决策这个产品不是高并发、高实时性产品。它的特征：
用户量级：MVP 阶段 1000-5000 活跃用户
并发特征：组局时间集中在下午/晚上/周末，非 7×24 小时
实时需求：低（通知用推送，不需要 WebSoc...
上一篇我写了这个产品的基本思路。这一篇，我来把它拆成可以动手做的事。
不做 PPT，不做概念图。直接写功能清单、优先级、用户流程、界面描述——这些东西你可以直接拿去跟前端/后端对需求。
一、产品定位再确认先说清楚这个产品不是做什么的：
不是一个”朋友圈”——不要做发帖、点赞、评论
不是一个”交友平台”——不要做左滑右滑、匹配
不是一个”找工作的 App”——不要在首页放招聘入口
...