各位老板们、同事们，产品技术中心产品部的产品专栏第一期终于推出了！
这个专栏将定期发布产品部关于产品设计方面的思考。主要有以下四个方面：1）产品规划 2）用户需求探讨 3）产品设计过程思考 4）竞品分析。
开设这个专栏的目的很简单，主要有两个，一是让公司各位同事能随时了解并参与到我们产品设计的环节中，同时能通过这样的平台给我们多提意（tu）见（cao）。二是通过这样的专栏也能倒逼我们更多地思考，提高自身的产品设计能力，从而设计出更好的产品服务大家。。
这是我们产品部的第一篇关于产品设计思路的文章，想了很久要怎么写，从什么角度开始。最后我觉得任何产品的起源都来自需求，这期就主要聊聊我们是如何收集、分析和管理需求的办法。如考虑不周的也请各位多多指正。
首先是我们如何进行需求收集的。主要有三个方面：
1.老板需求
毕竟老板对行业和业务比我们熟悉太多，前期需要吴校和各位大佬多给我们提意见和想法，帮助我们产品方向不会跑偏。
2.用户反馈
目前我们的用户反馈包括两个环节，一是开发前我们将产品需求转化为原型DEMO，同时我们会选取对此产品最熟悉的用户并把我们的原型一一和他们进行确认，如果还有问题则继续调整原型，如无问题则可进入开发阶段。如极运营在最初的产品设计时我们与财务同事确定需求不下10次，同时也到各校区找到相应负责人进行了多轮的沟通和确认工作，收集了大量宝贵的意见。（这里要特别感谢申琴，在前期我们产品对极运营的需求一无所知时，是她在反复耐心地给我们讲解需求）
这就是传说中第一版的极运营原型图
二是开发完成上线后我们通过面聊或通过《需求反馈表》给我们反馈的需求。我们目前使用的需求反馈表还用的是比较传统的excel表格，后期会考虑做成简单的系统，这样采集反馈问题更及时，反馈人也能更方便了解自己反馈需求的状态。
需求反馈表
当然，在整个用户反馈环节，我们也有需要反思的。比如需求调研覆盖的面还不够广，覆盖的层次还不够多，包括各大区不同岗位层级的用户还没来得及全部沟通到位，后续我们也会在此投入更多精力。
3.竞品分析
从进公司到现在，产品部已经完成两版的竞品分析报告，也分析了大量教育类产品，从中收获非常多。无论是对整个行业软件水平的了解，还是学习借鉴优秀产品，都帮助我们对行业内产品有了更深的了解，后期有机会我们会把这些分析报告整理后发出，希望引发大家更多的思考。不过关于竞品分析，有一点需要我们注意的：竞品毕竟是竞品，它的业务场景可能和我们不一样，不能直接copy，需要辩证的分析它存在场景的价值和意义。
就在前段时间有老师给我们提出，学而思和新东方都在课堂上使用答题器收集学员课堂学情数据。于是我们在网上也做了相应竞品调研，看了很多课堂使用答题器的视频，发现确实通过答题器收集学员学情数据很方便，既能调动课堂氛围还能产生学情数据。但随着调研深入，同时我们也到学而思和新东方线下课堂去体验，发现他们线下面授课无一例外都没用到答题器，只有双师模式才在运用。对这一现象，我们认为，基于现有的线下小班授课的课堂答题器数据采集的迫切性不高，学员只要通过举手或老师挨个查看学员作业就能很快收集到班级学情数据。而双师模式需要一个老师覆盖几个班，上百人，同时还是远程教学，实时掌握学员学情数据就必须通过答题器这种模式实现。从另一方面答题器的成本也相对较高，不仅是软硬件投入成本，还包括课堂、课后管理成本都会带来较大麻烦。我想这也是答题器虽然已经很成熟但仍在传统课堂中使用不高的主要原因吧。
当然除以上几种需求收集方式外，我们目前还缺少通过数据反馈中收集需求，比如通过在产品中对功能进行数据埋点，获取各功能使用情况的数据，从中了解用户的使用频率及习惯来获取需求。这个部分我们会在后续开发中逐步加入，毕竟人可能会说谎，但数据不会。
需求收集完，自然是需要对需求进行分析、过滤、筛选，从中去伪存真和优先级排序。首先我们需要区分收集上来的需求是真需求还是伪需求。有时真的很难区分，很多需求看起来都无比真实，但还原到实际场景却是个伪需求。
举个我自己提伪需求的例子，当时我刚到极客，希望快速提升产品逼格，于是联系到一家自动批改数学主观题作业的公司。那家公司在做主观题数学作业批改上确实很牛，在2016年通过它们的高考机器人参加北京数学卷考试得了105分。我当时希望能通过引进它们的自动批改作业功能，帮助咱们的老师减轻工作量。但后来我把这个产品推荐给老师时，存在两种截然相反的态度，一种是认为有这个功能太好了，能帮助老师减轻工作量，甚至可以完全可以不要助教了。另一种认为其实老师批改作业的时间也占用不到太多，必要性不强。后来我们产品也经过多次内部沟通、讨论，到实际上课和作业批改场景里实地调研，发现确实有问题。一来是我们很多老师本来就有助教，这些批改作业工作会交给助教完成。即使没有助教，我们的班级都是小班教学，一个班也就十几二十个学生，每次作业也就不到半小时能搞定，而且老师在实际批改作业时还能快速了解孩子学情状况。这个自动批改作业的需求虽然从表面粗略一想完全合乎需求，但还原到真实场景里却就不是那么回事。
从这件事里也让我总结出如何识别伪需求的两个心法：1）任何需求必须还原到具体应用场景去思考和分析 2）不要看用户怎么说，关键看用户怎么做。
需求去伪存真后，还需对真实需求进行优先级排序，分清需求的轻重缓急和节奏对产品设计也非常重要。现在我们的做法是把收集上来的每一个需求都录入到禅道（软件项目管理平台）的需求池里，每次规划下一个版本时我们会从需求池里根据轻重缓急把需求重新梳理和设计，并把需求移到下一个版本中进行排期开发。
禅道需求收集工具
这里需要重点讲讲我们关于需求优先级排序的方法。很多人讲把需求优先级通过紧急、重要两个维度生成四个象限，重要紧急〉重要不紧急〉紧急不重要〉不重要不紧急。当然，这个处理需求的原则没有问题，但没有定义什么需求重要什么需求紧急。其实紧急这个维度很好判断，取决于交付时限、任务依赖。交付时限是指需求最终截止期限，如果过期上线将对业务有较大影响。任务依赖是指该需求是某个流程中的一环，如果缺失这一环将对整体流程造成影响。但重要这个维度就很难的定义，我认为重要维度有两个因素：影响范围、商业价值。影响范围很简单，是指能满足多少用户的需求。商业价值是指该需求能对用户带来多大价值或给公司带来多大的竞争优势。
分清了重要和紧急的定义，我们就可以以量化的方式对优先级进行排序。量化的方法就是把重要和紧急两个维度满分设置为5分，分别定义需求两个维度的分值然后两项相乘就得出该需求的总分，最后根据总分再进行排序。
需求排序量表
当然，以上需求管理办法主要适用已经上线的产品功能迭代，新项目开发需求还不适用。因为新项目开发会利用大量研发资源，也存在一定风险，而现在来自各个部门越来越多的新项目需求，这样的需求开发与否以及优先级排序就不能只在产品部内部进行决策，需要上升到公司级层面共同决策。因此后期我想可以通过在公司内部成立<产品评审委员会>的形式，召集公司产品智囊团在更大范围内对产品方向、规划进行探讨和决策。
以上是本期产品部关于需求收集、分析及管理办法的分享，过程中肯定有不完善的地方，也希望大家多多批评指正，帮助我们及我们设计的产品共同成长！
再次感谢大家利用宝贵时间看完此文，我们下期见！
网友评论