时间: 2021-08-03 09:12:30 人气: 8 评论: 0
本文以监控运维系统为例，分析了B端项目中的需求分析与总结的要点。具体的内容来看正文吧。
（注：最近整理了从事产品以来所做的项目，才发现在不知不觉中已经完成了3个B端产品了，所以今天就和大家分享一些自己在做B端项目过程中的需求分析与总结。产品新人，其中有做的不对的地方，还望各位大佬给点建议。谢谢。）
需求分析是一名产品的必经之路，一份好的产品需求文档能够快速帮助产品经理设计好一款好产品，那么B端产品又该如何进行需求分析呢？
整理了最近1年时间做的2B项目的资料，总结了一些自己在做B端项目过程中的需求分析时遇到的一些问题。一是对自己这段时间的总结，希望自己在接下来的产品生涯中能做的更好。二是对B端产品从业者进行分享，大家共同探讨。仅代表自己个人观点。笔者是做设计出身，对产品方面的知识掌握的不是很全面，还望见怪。
随着互联网和移动互联网的发展，视频业务的逐渐多样化。同时，公司各项业务也变得越来越多样化，从原来的数字电视、高清数字电视业务逐步的向高清/4K数字电视业务、互动点播业务、数据宽带业务等丰富的多媒体融合业务发展。
而移动、联通等传统电信运营商也逐渐向用户提供视频业务，对传统的广电视频业务和互动点播业务带来了冲击。宽带业务的多样性和用户对于高品质宽带业务体验的要求，已经给公司的宽带运营和维护模式带来巨大的压力。
在当下的视频时代，用户愿意为好的视频体验买单，这就对运维提出了更高的要求。当视频体验劣化，出现用户投诉时，通过逐个排查的方式找出问题网元，效率很低。因此需要建立一套以业务体验为中心的宽带用户体验量化评估体系，并配套相应的信息化系统，通过网络质量关键指标和用户体验关键指标等手段主动识别网络问题，在用户投诉前发现并解决问题，提升用户上网体验。
B端产品不同于C端产品，需求不仅来源于用户，更多的是来源于决策者。所以首先我们首先需要为需求来源确定一个大概的范围。就如去年接到的一个来自于一家运营商的项目，“提高网络业务感知，延长扩容周期、降低运维成本”这是当时甲方给的最原始的需求。
所以当我们接到需求时，需要对这个需求进行梳理与分析，为这个需求划分一个大概的范围。
下面的就是我们对原始需求进行调研后得到的结果；
对需求的来源有一个大概范围，这时我们需要对需求进行进行调研与分析，形成一个基础的需求文档；这时我们需要约项目组的成员开一个简短的**议，让团队成员能够明白这个项目是在什么样的背景下形成，便于团队成员提前对这个项目有一个初步的了解，同时也可以收集一些团队的意见，毕竟“三个臭皮匠，赛过诸葛亮”嘛！
完成这些之后，我们就需要约客户进行一个初步的需求评审，在**议之前，就需要以正式的邮件发给客户，以便客户提前能对这些需求有一个大概的了解。最好是约项目的决策人，因为只有找到对的人，才能在最短的时间内达成一致，给国企做项目大家都懂得，特别难约。
每次**议之后最好输出一份**议记录，最好是带流程图，这样更能方便我们对客户业务的了解。
经过几次与客户的约谈之后，这时我们需要整理出一份需要客户确认与对接的文档出来，这份文档应该包括以下几个方面：
需求梳理完成之后，这时你可以和项目负责人进行一次深入交谈，明白哪些业务是我们目前系统能够支持，怎么样做才能减少开发量。因为我们公司一直都在做数据分析与运营商这方面的业务，业务之间有许多相通之处。
产品需求文档完成之后，给客户进行确认，避免开发进行时，再对需求进行大的变动。
这时我们需要根据对业务的熟悉程度，对各个需求按照核心业务进行优先级排版。
和团队成员再开一次需求评审**议，让团队成员对这次的项目有一个更加深入的了解，让团队知道这次我们需要做一个什么样的项目，在什么时间段之前需要完成，需要达到什么样的效果。
进入开发之后，最后每个星期询问一下，开发人员的进度，是否遇到了困难，能否在时间节点完成任务。这样更便于我们及时了解到项目进度，即使遇到了问题也能及时协调资源去解决。
最后也是最重要的一点，及时更新需求文档。
即使前期客户已经对需求进行了评审，双方达成了一致。中间还是**有许多需求更变，这时需要我们再三跟客户确认调整方案后，及时更新需求文档，以邮件的形式通知项目成员，便于项目成员能够及时了解需求变动。有时也**遇到一些不能实现的需求，同时自己也协调不了，这时我们需要及时跟老板沟通，说明目前遇到的困难，让老板及时与对方负责人沟通。
本文由@浮生 原创发布于人人都是产品经理，未经允许，禁止转载
题图来自Unsplash, 基于CC0协议
