一款功能从生到死的流水账（需求研发/开发流程）

01｜需求提出：脑洞的点火器
产品大哥在群里甩下一句话：
“我们要让用户长按头像就能一键‘拍一拍’，还得带震动！”
火就这样点起来了。

02｜需求评审：给脑洞套缰绳
开发、测试、设计、运营排排坐。
“震动要不要权限？”
“iOS 后台杀进程怎么办？”
“残障模式怎么兼容？”
一群人的唾沫星子，把最初 80 分的脑洞拍成 60 分的可实现方案——挺好，再天马行空就要飞出银河系了。

03｜交互评审：让脑洞长得有人样
交互小姐姐把 60 分方案画成低保真图：
“拇指热区在这儿，震动强度三档，给个开关。”
大家用手指在屏幕上假装“长按”，空气里响起一片“哒哒哒”的配音——像一群孩子在玩假装游戏。

04｜概要设计：给代码搭骨架
架构师在白板上边画方块边念叨：
“消息通道走长连接，震动用系统 Haptic，埋点走统一 SDK……”
方块之间画上箭头，看起来像个骨架，只差血肉。

05｜详细设计：让骨头长肉
每个箭头被拆成 class、method、DB 字段、时序图。
“万一对方在线但熄屏呢？”
“得加唤醒策略，还要降级短信。”
于是图里又长出一堆 if-else，像血管一样密密麻麻。

06｜测试用例评审：提前写“遗书”
测试同学把能想得到的死法都列进 Excel：
“断网、弱网、低电量、被系统杀掉、连续拍 100 次、同时被拍又被打断……”
程序员看得头皮发麻：原来我写的不是代码，是遗愿清单。

07｜接口定义 / 开发 / 联调：前后端相亲大会
后端说：“字段我给你这些。”
前端回：“少了 gender，我要显示‘他拍了拍她’。”
“那再加一个！”
git commit 像月老的红线，把两个人的分支一次次拉到一起，直到 Postman 返回 200，大家才松一口气——相亲成功。

08｜代码审核：当众处刑
“这行日志打印可能泄露用户手机号！”
“魔法数字 3 是啥？拍三次会召唤神龙？”
老大哥的注释比代码多，年轻人面红耳赤，却也心服口服。

09｜提测 / 灰度 / 产品第一次验收：让子弹飞
测试小姐姐在群里 @所有人：
“功能已上灰度，欢迎来拍。”
产品一边拍一边咧嘴：“震动再猛一点，像心跳！”
开发默默把 amplitude 从 0.4 → 0.6，心想：心跳再猛就是心悸了。

10｜发布计划 / 线上日志观察 / 上线：产房门口
凌晨两点，构建流水线亮绿灯。
“开始放量 5 %。”
监控大屏的曲线像胎心监护，一行行日志刷过去——
200、200、200……突然蹦出 502！
立刻回滚，排查，再放量。天蒙蒙亮，曲线终于平稳，大家才肯去眯一会儿。

11｜产品第二次验收：盖棺前的最后一瞥
“DAU 涨 3 %，人均拍 2.5 次，停留时长 +7 s。”
产品满意地点头：“可以结项了。”
开发伸懒腰：“走，去楼下嗦粉！”

12｜需求结束：墓碑上的一行字
Confluence 里把状态改成“已上线”，打 tag、归档、封存分支。
日后有人翻起这篇文档，就像考古学家看到一块斑驳的墓碑——
上面写着：
“此地长眠者，曾让无数用户在屏幕里，轻轻一拍，心头一震。”