惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
Simon Willison's Weblog
Simon Willison's Weblog
Microsoft Security Blog
Microsoft Security Blog
Y
Y Combinator Blog
The GitHub Blog
The GitHub Blog
Engineering at Meta
Engineering at Meta
F
Fortinet All Blogs
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
A
About on SuperTechFans
Last Week in AI
Last Week in AI
月光博客
月光博客
有赞技术团队
有赞技术团队
P
Proofpoint News Feed
MyScale Blog
MyScale Blog
Martin Fowler
Martin Fowler
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
C
Check Point Blog
U
Unit 42
The Register - Security
The Register - Security
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Hugging Face - Blog
Hugging Face - Blog
阮一峰的网络日志
阮一峰的网络日志
V
Visual Studio Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
D
DataBreaches.Net
WordPress大学
WordPress大学
aimingoo的专栏
aimingoo的专栏
H
Hacker News: Front Page
Recent Announcements
Recent Announcements
C
CXSECURITY Database RSS Feed - CXSecurity.com
Latest news
Latest news
小众软件
小众软件
P
Palo Alto Networks Blog
PCI Perspectives
PCI Perspectives
Security Latest
Security Latest
S
Secure Thoughts
Scott Helme
Scott Helme
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
T
Threat Research - Cisco Blogs
P
Proofpoint News Feed
M
MIT News - Artificial intelligence
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Google DeepMind News
Google DeepMind News
Recorded Future
Recorded Future
O
OpenAI News
S
Securelist
云风的 BLOG
云风的 BLOG
H
Help Net Security
T
Troy Hunt's Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
如何召开一场成功的需求评审?
Olivia · 2023-06-27 · via 人人都是产品经理

相信很多不懂得如何开需求评审会议的伙伴,在一场会议下来没有获取什么结果。本篇文章将系统地给大家介绍该如何做好一次需求评审会,并有对应的参考模板,方便大家快速、高效地做好一场需求评审会议。

小姜同学:每次需求评审的时候,时间都好长而且容易跑偏。有时候还会被运营同学在质疑和拷问,我还说不过他们。有几次开完会,好像也没有什么结论。我该怎么做呢?

针对这个问题,我们需要在每次正式评审前,做好充足的准备。从准备、召开、收尾三个维度拆解问题,确认每个维度的流程和关键点。

文章已脱水,非常干货。

一、会议准备阶段

1. 确认评审的形式

根据项目的规模和复杂性,确定需要哪种形式的需求评审。

  • 对于较小的项目,不需要实时的会议或讨论,可以选择较为简单和灵活的评审形式。例如:采取静默评审。
  • 而对于大型、复杂的项目,通常来说,开发周期预计超过1周的需求,都需要更为正式和结构化的评审过程。

2. 明确会议目的

一个明确的主题将有助于聚焦会议讨论,并使参与者明确会议的目标。

常见的会议主题包括:

  1. 确保需求理解的一致性:会议的目的之一是确保所有参与者对需求的理解是一致的。通过讨论和解释需求,可以澄清任何模糊或不清楚的地方,并确保每个人对需求的含义和目标有相同的认识。
  2. 评估需求的可行性和合理性:会议目的还包括评估需求的可行性和合理性。参与者可以提出问题、讨论需求的实施细节,以及评估其对项目资源和时间的影响。这有助于确定需求是否可行,并在必要时进行调整或修改。
  3. 收集反馈和建议:会议是一个收集参与者反馈和建议的机会。参与者可以提供他们的意见、建议和观点,以改进需求的质量和可行性。他们的反馈可以揭示可能被忽视的问题、挑战或改进机会。
  4. 决策和优先级排序:在需求评审会议中,可以进行决策并确定需求的优先级。通过参与者的讨论和共识,可以确定哪些需求是最重要和紧急的,以指导后续开发工作的优先级和规划。
  5. 促进跨部门协作和沟通:会议提供了跨部门和跨功能团队之间沟通和协作的机会。各个团队可以分享他们的观点和经验,加强合作,并确保各个团队在需求上的一致性和相互配合。

3. 做好会前准备

1)提前准备:会议相关内容

  1. 确定会议室和时间:预定合适的会议室,确保能容纳所有参与者,并选择适当的时间,使参与者都能出席。确保会议室内有足够的座位、白板或投影幕布等资源,以支持讨论和记录。
  2. 准备需求文档和资料:整理和准备与需求评审相关的文档和资料,如需求规格书、用户故事、界面设计等。确保这些材料完整、清晰,并提供给参与者足够的时间来阅读和理解。
  3. 发送会议通知:提前向参与者发送会议通知,明确会议的时间、地点、议程和参会要求,并附上评审材料,便于参会人员提前了解。确保参与者能够在会议之前安排好时间并做好准备。
  4. 确认参会人员:与参与者确认他们的出席情况,确保所有关键的利益相关者和团队成员都能参加会议。如果有人无法出席,及时调整会议安排或邀请代表出席。
  5. 测试会议设备:如果会议需要使用投影仪、音响系统或其他设备,提前测试并确保设备正常工作。这样可以避免在会议开始时出现技术问题。

万能邮件模板(邮件接收人需要按职位高低进行排序)
主题:X月×日需求评审会议通知
Hi,各位团队成员,
欢迎大家参加 [版本号/需求名称] 需求评审会议。这次会议的目的是审查和讨论我们项目的需求,以确保它们准确、完整,并与项目目标一致。以下是会议的详细信息和议程:
日期:[会议日期]
时间:[会议时间]
地点:[会议地点]
会议室:[会议室名称]

议程:
1.开场和介绍(预计时间:10分钟)
会议目的和重要性的说明
参与者介绍
2.需求讨论和评审(预计时间:60分钟)
逐个讨论需求,确保共识和理解
提出问题、建议和疑虑
根据需求的可行性和优先级做出决策
3.总结和行动项(预计时间:10分钟)
总结讨论的要点和决策
确定下一步的行动项和责任人
确认会后的跟进计划

在会议前,请确保提前准备并阅读相关的需求文档和资料,以便在会议中能够做出有意义的贡献。如果你有任何特定的问题或建议,请提前与我沟通,以便我们可以更好地准备讨论。
如果你因为任何原因无法参加会议,请提前告知我们,以便我们能够做出相应的安排。
感谢你的时间和合作。期待在会议上与你共同努力,实现项目的成功。

最诚挚的问候,
[你的姓名]
[你的职位]
[你的联系方式]

通过进行这些准备工作,可以确保需求评审会议能够顺利进行,并使参与者在会议开始前有足够的准备时间和所需材料。

这有助于提高会议效率,使参与者能够更好地参与和贡献。

2)提前自查:确认评审方案的完整度

根据以下走查关键点,逐个检查整体需求方案是否达标。

  • 梳理需求方案:仔细检查需求方案,确保其中包含了项目的关键方面和要求。核实方案中是否涵盖了功能需求、非功能需求、界面设计、用户流程等重要元素。
  • 需求的清晰性:确保需求方案中的描述清晰、明确,没有模棱两可的表达或歧义。需求应该能够被各个参与者一致理解,避免造成误解或理解偏差。
  • 验证需求的可测性:需求方案中的需求应该是可测量的,可以通过测试或验证来核实其实现。确保每个需求都能够被评估、测试或验收,以验证其实现程度。
  • 确认业务目标和价值:核实需求方案是否与项目的业务目标和价值一致。需求方案应该能够解决业务需求,满足用户和利益相关者的期望,并产生预期的价值和效益。

3)提前预备:预估被挑战的问题

列举了一些常见的,容易被质疑的问题清单,可以提前在脑海中构思对应的解答。

  • 这个需求的具体细节是什么?
  • 需求中是否包含了所需的输入、输出和交互过程的描述?
  • 需求中是否涵盖了异常情况和错误处理的要求?
  • 这个需求是否与其他需求相冲突?
  • 需求之间的优先级如何?是否存在冲突的优先级?
  • 是否有可能合并或调整需求,以解决冲突和确保一致性?
  • 这个需求在技术上是否可行?是否需要额外的技术支持?
  • 是否有必要进行额外的研究或验证,以确保需求的实施性?
  • 需求的实施是否受到资源、时间或成本的限制?
  • 这个需求如何满足最终用户的需求和期望?
  • 是否有用户反馈或市场调研支持这个需求的重要性?
  • 这个需求如何与产品的整体愿景和战略目标相符?
  • 需求方案是否考虑了性能、安全性、可靠性或可维护性等非功能性需求?
  • 是否有明确的性能指标或质量要求?
  • 如何保证需求方案满足非功能性需求?
  • 这个需求的优先级如何与其他需求相比?
  • 这个需求对项目的规模和范围有何影响?
  • 是否有必要将这个需求划分为更小的子需求或迭代实现?

二、会议召开阶段

1. 开场

在会议开始前,介绍会议目的和议程、确认与会人员和角色、会议涉及的内容和会议期望的结果。

2. 内容评审

  1. 简要回顾需求的背景和上下文。
  2. 讲述用户故事和业务场景。
  3. 讲解核心流程和支线流程。
  4. 演示原型并具体描述重点需求和功能模块。
  5. 定义数据埋点和所需的关键指标。

3. 讨论环节

讨论环节注意事项:

  • 按照主流程展开讨论,不要跑题。
  • 非常细的内容,不涉及主流程环节的,放在会后解决。
  • 主流程环节的问题,必须会上处理。
  • 不要花费太多时间讨论技术方案。

决策和优先级:

  • 对有争议或不一致的需求进行讨论和决策。
  • 确定需求的优先级和重要性。
  • 根据讨论结果做出调整和决策。

4. 后续事项确认

  • 确定下一步的行动项和责任人。
  • 确认每个需求的负责人和相关团队。

5. 总结会议

  1. 回顾会议讨论和决策的要点。
  2. 让相关负责人简要复述确认理解一致。
  3. 强调下一步行动和时间表。
  4. 感谢与会人员的参与和贡献。

三、会后收尾阶段

1. 会议纪要和记录

会议结束后,制作会议纪要,记录讨论的要点、决策和行动项。

确保纪要准确反映了会议的讨论和结果。

2. 更新和调整需求文档

根据会议讨论和决策的结果,确认是否调整,如调整,则更新和调整需求文档,确保需求文档中反映了会议中的变更和决策。

如不调整,再说明理由及时反馈处理结果。

3. 发送会议纪要

在会议结束后的合理时间内,通过正式的渠道发布会议纪要。

确保纪要中包含会议的要点、讨论、决策、行动项、争议点和待处理事项,还有对应负责人。

校对纪要,确保准确反映了会议的内容和结果。

4. 行动项的执行

根据会议纪要中确定的行动项,责任人应开始执行相应的任务。监督和跟踪行动项的进展,并确保它们按计划完成。

5. 进一步的讨论和澄清

如果会议后出现了进一步的问题、疑虑或需求澄清的需要,团队可以进行进一步的讨论和沟通。

确保任何新的问题或变更都被妥善处理和纳入需求评审的流程中。

万能会议纪要邮件模板

主题:需求评审会议纪要 – [会议日期]

Hi,各位团队成员,
以下是我们最近一次需求评审会议的会议纪要,请仔细阅读并确认准确性。

会议纪要:
日期:[会议日期]
时间:[会议时间]
地点:[会议地点]
主持人:[主持人姓名]
与会人员:[与会人员1姓名] [与会人员2姓名] [与会人员3姓名]

议题:
[议题1]
讨论内容:[讨论内容1][讨论内容2]
决策/结论:[决策/结论1][决策/结论2]

行动项:
[行动项1]
负责人:[负责人姓名]
截止日期:[截止日期]
进度:[进度更新]

下次会议计划:
日期:[下次会议日期]
时间:[下次会议时间]
地点:[下次会议地点]
议题:[下次会议议题]

备注:
[备注1]
[备注2]

请各位参与人员仔细阅读以上内容,并核实其中的准确性。如果有任何遗漏或需要补充的信息,请及时告知。
再次感谢大家的参与和贡献,我们将根据会议纪要的内容继续推进项目的进展。
如果你对以上内容有任何问题或疑虑,请随时与我联系。

四、结语

一场成功且顺利的需求评审,在方方面面都需要投入精力。

如果我们处处在意细节,在每个环节考虑周全,按照以上步骤,可以确保会议的流程顺利进行,并将会议讨论和决策转化为实际行动和项目的推进。确保团队和利益相关者都能对需求评审的结果和后续工作有清晰的认识和期望,最终达到我们的目标。

我们下期再见~

本文由@Olivia 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。提供信息存储空间服务。