下一章 上一章 目录 设置
61、第六十一章 需求文档被 ...
-
许惊蛰第一次写公司正式需求文档,是从一份“看起来不难”的任务开始的。
何经理把访谈纪要看完后,说:“失物招领这个优化可以先拆一个小需求:发布后的状态反馈和外部分享回流。你先写一版简短PRD,不用太长,把背景、目标、用户场景、功能说明和验收标准写清楚。”
许惊蛰听到“简短”两个字,心里当场点头。简短好,他现在已经不是那个写小作业能写成导论的人了。他非常成熟,非常克制,非常懂得公司文档要说人话。
两个小时后,许惊蛰写出了三千五百字。
他看着文档字数,沉默了。
倪然从旁边路过,看见他表情,问:“怎么了?”
许惊蛰盯着屏幕:“我本来想写简短PRD。”
倪然看了一眼字数,笑了:“你写成中篇小说了?”
“我已经删过了。”
“那说明初稿更可怕。”
许惊蛰把文档往下拉。背景部分写了用户访谈发现、渠道分流现状、学生心理预期和传播路径问题,目标部分写了提升可见性、增强回流、降低认领风险,功能说明里写了发布成功页、状态提醒、分享卡片、回流落地页、认领校验入口。每一段都挺有道理,但连在一起确实不像一个小需求,更像他想把失物招领一口气送进现代化治理体系。
陶舟凑过来看了一眼,评价:“你这个PRD有梦想。”
许惊蛰转头:“你能不能说得委婉一点?”
“委婉就是:它不像一期。”
许惊蛰痛苦闭眼:“我又犯病了?”
陶舟拖了把椅子坐下:“也不算犯病。你想得多是好事,但PRD不是把所有思考都写进去。你要让技术、设计、测试知道这次到底做什么,不做什么,做到什么算完成。”
许惊蛰点头:“所以我应该砍。”
“砍,而且要砍得心狠。”陶舟说,“比如你这个‘外部分享回流’和‘状态反馈’,其实可以拆成两个需求。何经理让你写小需求,你先别把分享链路和认领安全都绑一起。第一版可以只写发布成功后的状态提示和一键分享卡片,认领校验放后续。”
许惊蛰看着自己写了半页的认领校验逻辑,感觉像要亲手送走一位亲生骨肉。
“它不配留下吗?”他问。
陶舟被他逗笑:“它配,但不是今天配。”
许惊蛰郑重地把那部分剪切到“后续需求池”里,心里默念:不是删除,是暂存。
下午,何经理看了他的第一版,给了更直接的修改意见。背景太长,目标不够量化,用户场景可以保留两类,不需要列五类;功能说明里每个状态要写触发条件,分享卡片要明确展示字段;验收标准不能写“用户能清楚感知”,要写“发布成功后展示状态卡片,包含审核状态、预计曝光渠道、分享按钮”。
许惊蛰听完,觉得自己像一棵被修剪的树,枝叶掉了一地,但树形确实清楚了。
他把文档改到第二版,字数砍到一千八。何经理看完后说:“好多了,但还能再改。你现在背景已经清楚,问题是功能边界还不稳。比如分享卡片是否支持自定义文案?如果支持,审核风险增加;如果不支持,传播效果可能弱。你要先给判断。”
许惊蛰问:“那应该支持吗?”
何经理看着他:“你觉得呢?”
又来了。
许惊蛰现在最怕别人把问题扔回来。但他也知道,这是必须练的。他想了想,说:“第一期不支持自定义文案。先用系统生成固定模板,避免用户写隐私信息或夸张描述。卡片里展示物品类型、丢失地点范围、时间和系统编号,具体联系方式不展示,引导点击回系统查看。”
何经理点头:“这个判断可以,写进去。”
许惊蛰松了口气。
第三版改完,陶舟又从技术实现角度提了几个问题:分享卡片是生成图片还是链接?如果分享到微信,落地页未登录用户能看什么?系统编号怎么避免被滥用?状态提示数据从哪里取?许惊蛰听得头皮发麻,终于理解为什么公司文档不能写得像论文。论文里一句“建立可追踪机制”就能过去,PRD里必须回答每一个按钮点下去发生什么。
那天下午,他的文档从三千五百字被改到一千二,又从一千二补到一千五。内容不是少了,而是密了。少了很多漂亮背景,多了很多具体条件。比如“提升用户对信息流转的感知”变成了“发布成功后进入结果页,展示当前状态:待审核、已发布、已匹配线索;用户可点击查看状态说明”。比如“支持外部传播并形成回流”变成了“用户点击分享按钮后生成固定模板分享卡片,卡片点击后进入H5落地页,未登录状态仅展示物品类型、区域、发布时间和系统编号,认领需登录”。
许惊蛰改到最后,盯着文档,忽然有点高兴。
不是因为它看起来多高级,而是因为它真的像能被做出来的东西。
下班前,何经理终于说:“这一版可以进入评审。”
许惊蛰心里一块大石头落地,差点当场给文档鞠躬。
倪然在旁边听见,笑着说:“恭喜,小许第一份PRD存活。”
陶舟补充:“虽然亲妈已经认不出来。”
许惊蛰说:“没关系,它现在更像能工作的人。”
陶舟点头:“你这个心态很好。”
晚上,许惊蛰把这件事讲给江辞听。讲的时候他非常激动,从三千五百字讲到一千五,从背景被砍讲到验收标准,从“用户感知”被改成具体状态。江辞听完,问:“被改得难受吗?”
许惊蛰想了想:“一开始难受。尤其删认领校验那段的时候,我觉得我在抛弃它。”
江辞:“后来呢?”
“后来发现,不是所有好想法都要挤在同一版。”许惊蛰趴在桌上,看着屏幕里的江辞,“以前我总想一次把东西做完整,像交作业一样,交上去就要显得自己很厉害。但工作里好像不是这样。能拆开,能落地,能让别人理解,才重要。”
江辞看着他:“这是很大的变化。”
许惊蛰被他说得有点不好意思:“你今天怎么夸得这么认真?”
“因为值得。”
许惊蛰安静了一下,忽然笑:“江辞,我现在有点喜欢被改文档了。”
江辞挑眉:“确定?”
“不是喜欢被骂。”许惊蛰解释,“是喜欢那种改完以后变清楚的感觉。像我脑子里一团乱东西,被别人帮我按成能用的形状。”
江辞说:“你以前也经历过。”
“项目组?”
“嗯。”
许惊蛰想了想,笑了:“那时候你改我稿子,我只觉得你冷酷无情。”
“现在呢?”
“现在也冷酷。”许惊蛰一本正经,“但有帮助。”
江辞笑了一下。
第二天PRD评审,许惊蛰作为文档作者参加。会议比周会更具体,技术、设计、测试、运营都围绕他的文档提问题。设计问分享卡片样式是否需要区分“丢失”和“捡到”;技术问H5落地页是否用现有模板;测试问状态切换的异常情况;运营问学校合作方是否允许外部分享带系统标识。许惊蛰一边回答,一边记录不确定项。
当然,他不是每个都答得上来。有一处技术问到接口返回,他完全不知道,只能诚实说:“这块我不确定,需要会后跟开发同学确认。”说完他有点紧张,怕显得自己不专业。结果老周点点头:“行,会后我让小陈跟你对。”
许惊蛰这才发现,不知道并不可怕。硬装知道才可怕。
评审结束后,何经理说:“整体可以,按今天意见改一版,明天发评审纪要。”
许惊蛰点头,心里居然没有崩。他感觉自己像第一次真正参与了一个公司需求从用户反馈到文档评审的过程。虽然只是一个小功能,虽然还没上线,但它已经不是纸上谈兵。
下午,他去找技术小陈确认接口。小陈看起来比他大不了几岁,说话很快,但人不难相处。许惊蛰一开始还怕自己问的问题太基础,结果小陈听完,说:“你能先把场景说清楚就行,接口我们看现有能不能复用。”
许惊蛰把状态卡片的几个场景讲了一遍:发布后待审核,审核通过已发布,有人提交认领线索,物品已归还,发布信息被驳回。小陈听着听着,点头:“这个状态我们后台有一部分,只是前端没展示。已匹配线索可能要新增一个计数字段。”
许惊蛰立刻记下:“那如果线索被判定无效,计数要不要减少?”
小陈看他一眼:“你这个问题问得挺产品。”
许惊蛰心里瞬间开花,但表面还要保持成熟:“我努力。”
回到工位后,他把纪要整理得很认真。不是长,而是清楚:谁提出了什么问题,结论是什么,待确认项归谁。写完后他发给何经理,何经理只改了两处措辞,就让他发到群里。
许惊蛰按下发送键时,心情比小作业通过那天还踏实。
因为这次不是面试展示,是工作的一部分。
晚上,江辞来公司附近接他。许惊蛰一上车,就把今天评审讲了一遍,语速快得像刚参加完战地采访。江辞一边听,一边把车开到附近一家简餐店。等他讲完,江辞问:“今天想庆祝?”
许惊蛰愣了一下:“这也能庆祝?”
“第一份PRD评审通过。”
许惊蛰想了想,认真点头:“可以庆祝,但不能太贵。我现在只是实习生,庆祝等级有限。”
江辞说:“我请。”
“那可以稍微升级。”许惊蛰立刻改口,“但不要烤肉,容易显得我太现实。”
最后他们吃了牛肉饭。许惊蛰吃得很香,江辞看他精神好,也没有提醒太多。吃完饭,两人沿着街边慢慢走。许惊蛰忽然说:“江辞,我今天有个瞬间很高兴。”
“什么时候?”
“小陈说我问得挺产品。”许惊蛰说完自己也笑,“是不是很没出息?”
“不是。”
“就一句话。”
“但你在意。”
许惊蛰点头:“嗯。因为我以前总觉得自己是传媒学院误打误撞进来的,靠嘴皮子混到这里。今天突然觉得,我可能真的能做一点产品的事。”
江辞停下脚步,看着他:“你不是靠嘴皮子混。”
“那靠什么?”
“靠你愿意听,愿意改,也愿意把别人的话当成问题去理解。”江辞说,“表达是你的工具,不是你的全部。”
许惊蛰看着他,心里忽然被填得很满。
过了一会儿,他小声说:“江辞,你今天又满分了。”
江辞问:“保护期?”
“动态评分。”许惊蛰笑,“但现在分数很稳定。”
江辞伸手牵住他:“那继续保持。”
许惊蛰低头看着两个人的手,忽然觉得城市夜色都比前几天顺眼了。
他的文档被改到亲妈认不出,但他自己反而更认得自己了。
这大概就是工作带来的第一点奇怪成就感。