一位B端产品经理的工作经验分享——需求分析（五）

继续接着 上篇文章 的内容，来看看需求转化阶段的一些工作内容。
交互设计图完善后，还需要编写系统需求文档。这里类似于C端PM的PRD工作。基于交互图，指出某一功能在某一场景下的操作步骤和结果。但需要注意的是，系统需求文档还需要给出一些基本的技术参数，如查询功能的响应时间要求、底层结构的稳定性要求等。这些参数应尽可能量化。如果不容易确定，可以和开发经理一起确认。

最后，需求转换的结果是两个文档+一个交互式设计图纸。此时，在正式开发开发前组织外部评估，邀请其他产品线的同事最终检查产品的所有设计细节。当然，也会有很多坑，比如需求变化、技术实现困难等等。在后续工作中，作者将发表一篇关于B端PM在各种评审会议上遇到的坑的文章。

到目前为止，需求分析的过程已经结束。由于空间原因，许多细节没有详细描述，如交互设计、需求变化、评估等。

正常情况下，B端产品的需求分析从几周到几个月不等。其中，你可能会无数次推翻你确信的需求，你可能会改变无数次文档，甚至连交互设计小姐姐都改图改到不想再改了。

你可能很痛苦，团队也很痛苦，但相信当你经历了痛苦，看到你的产品一点一点地抛光，并被成千上万的企业使用时，这种成就感是无与伦比的。在那一刻，你会觉得这一切都是值得的。因此，只有保持一颗坚强的心，我们才能坚定地走在ToB的道路上。

B端产品不易，且行且珍惜。

以上就是“一位B端产品经理的工作经验分享——需求分析（五）”的内容了，如果你还想了解其他相关内容，可以来 产品壹佰 官方网站。