本文以监控运维系统为例，分析了B端项目中的需求分析与总结的要点。具体的内容来看正文吧。

  需求分析是一名产品的必经之路，一份好的产品需求文档能快速帮助产品经理设计好一款好产品，那么B端产品又该怎么样做需求分析呢？

  整理了最近1年时间做的2B项目的资料，总结了一些自己在做B端项目过程中的需求分析时遇到的一些问题。一是对自己最近一段时间的总结，希望自己在接下来的产品生涯中能做的更好。二是对B端产品从业者进行分享，大家一同探讨。仅代表自己个人自己的观点。笔者是做设计出身，对产品方面的知识掌握的不是很全面，还望见怪。

  随着互联网和移动互联网的发展，视频业务的逐渐多样化。同时，公司各项业务也慢慢的变多样化，从原来的数字电视、高清数字电视业务逐步的向高清/4K数字电视业务、互动点播业务、数据宽带业务等丰富的多媒体融合业务发展。

  而移动、联通等传统电信运营商也逐渐向用户更好的提供视频业务，对传统的广电视频业务和互动点播业务带来了冲击。宽带业务的多样性和用户对于高品质宽带业务体验的要求，已经给公司的宽带运营和维护模式带来非常大的压力。

  在当下的视频时代，用户愿意为好的视频体验买单，这就对运维提出了更高的要求。当视频体验劣化，出现用户投诉时，通过逐个排查的方式找出问题网元，效率很低。因此就需要建立一套以业务体验为中心的宽带使用者真实的体验量化评估体系，并配套相应的信息化系统，利用互联网质量关键指标和使用者真实的体验关键指标等手段主动识别网络问题，在用户投诉前发现并处理问题，提升用户上网体验。

  B端产品不同于C端产品，需求不仅来源于用户，更多的是来源于决策者。所以首先我们第一步需要为需求来源确定一个大概的范围。就如去年接到的一个来自于一家运营商的项目，“提高网络业务感知，延长扩容周期、降低运维成本”这是当时甲方给的最原始的需求。

  所以当我们接到需求时，需要对这个需求来做梳理与分析，为这个需求划分一个大概的范围。

  对需求的来源有一个大概范围，这时我们应该对需求来做进行调研与分析，形成一个基础的需求文档；这时我们应该约项目组的成员开一个简短的会议，让小组成员能够明白这一个项目是在什么样的背景下形成，便于小组成员提前对这一个项目有一个初步的了解，同时也可以收集一些团队的意见，毕竟“三个臭皮匠，赛过诸葛亮”嘛！

  完成这些之后，我们就需要约客户进行一个初步的需求评审，在会议之前，就需要以正式的邮件发给客户，以便客户提前能对这些需求有一个大概的了解。最好是约项目的决策人，因为只有找到对的人，才能在最短的时间内达成一致，给国企做项目大家都懂得，特别难约。

  每次会议之后最好输出一份会议记录，最好是带流程图，这样更能方便我们对客户业务的了解。

  需求梳理完成之后，这时你可以和项目负责人进行一次深入交谈，明白哪些业务是我们目前系统能够支持，怎么样做才能减少开发量。因我们公司一直都在做数据分析与运营商这方面的业务，业务之间有许多相通之处。

  产品需求文档完成之后，给客户进行确认，避免开发进行时，再对需求来做大的变动。

  这时我们应该根据对业务的熟悉程度，对各个需求按照核心业务进行优先级排版。

  进入开发之后，最后每个星期询问一下，研发人员的进度，是否遇到了困难，能否在时间节点达成目标。这样更便于我们及时了解到项目进度，即使遇到了问题也能及时协调资源去解决。

  即使前期客户已经对需求来做了评审，双方达成了一致。中间还是会有许多需求更变，这时要求我们再三跟客户确认调整方案后，及时来更新需求文档，以邮件的形式通知项目成员，便于项目成员能够及时了解需求变动。有时也会遇到一些不能实现的需求，同时自己也协调不了，这时我们应该及时跟老板沟通，说明目前遇到的困难，让老板及时与对方负责人沟通。