今天终于要完结了，内心还是忐忑不安的，一方面特别兴奋，能够将自己的学习与实践经验认真总结，并得到了同行的认同，另一方面，我担心自己如何收场，与资深玩家相比，我深知有不小差距，不过我会尝试通过自己的思考来帮助大家梳理。
今天的主要话题是需求管理、需求池与版本迭代。
前文说到，作为产品经理，需求分析的核心方法分别为：
一、在遇见单个需求时，首先要分析用户、场景、问题以及现有解决方案，利用思维导图将思考过程完整记录并梳理，从中筛选并提炼出最有价值的信息与开发方向。
二、在遇见海量需求时，要明确需求优先级排序原则，逐一运用四象限分析法来判断，然后再结合公司产品发展阶段与具体场景来思考。
这些都是十分具体而复杂多样的，在日常工作中，我们难免遇到各式各样的需求，第二篇文章中我也有所提及，例如
场馆需要增加视频入口，从而扩大现场曝光，突出智慧场馆优势，进而做到线上线下双重结合；
电商模块需要在访问量较大的页面上增加弹窗或是提示，以此结合具体场景来实现销售转化；
新赛事系统上线后，领队反馈需要了解赛事进程，修改比分或是撤销比赛，给予赛事管理者较大的灵活性。
这些都是内部或外部需求的举例，我们第一步要做的当然是区分不同来源进而梳理需求。
1. 领导、同事：
一般而言，在公司所在行业，领导与同事都是对业务十分熟悉并且思考更为独到，无论是工作沟通还是开会讨论都能够碰撞出火花。当然，他们的诉求点可能更偏向于商业利益，有时我们很难理解他们的决定，这时候就需要认真记录并且后续深入沟通了。
2. 行业调研与竞品挖掘：
这考验产品经理甚至是整个公司的行业趋势与动态的敏感程度，有时我们在专心按照规划做产品时，很容易忽视其他竞争对手或是行业动态，这就需要产品经理在日常工作中多关注行业数据与动态。
行业数据可参考艾瑞咨询、企鹅智酷、QuestMobile 等，竞品调研可参考 App Annie、各大应用市场中同行业产品，从中挖掘出背后的商业与产品逻辑。
若是一味地闭门造成，后果就是，团队想出来的灵感早就被人家钻研并且实践了，此外，别人不做的功能说不定早就已经被市场抛弃了。
最好的办法就是让团队的每一个成员都关注其他产品的功能更新，然后再开会讨论，由产品负责人统一管理。
3. 用户、客户反馈：
产品面向的对象一般为大众用户或是企业级客户，他们是产品的直接使用者与反馈者，通常会通过评价、投诉、分享等方式向客服反馈，我们需要特别关注。特别是早期阶段的种子用户，他们对于产品的态度能够让我们在第一时间了解产品功能与体验上的问题，从而更快地迭代。
这里，我们就不得不提及需求池这个概念了：
从名称上我们不难看出，需求池是各方需求的集合与整理，这些需求是我们在工作中提出的想法或是问题，但是尚未实际开发或是梳理。
建立需求池的理由特别简单：每个人都是健忘的，很多灵感或是想法当时大家兴致勃勃，后续执行很容易偏离轨道，第二天再来询问，发现自己已经全然不知需求产生的背景与解决方向。
因而，我们必须通过需求池来记录并且寻求更深入的解决方案。
首先，我们要明白，每个团队都有一堆待办事项，作为产品经理，首要任务就是了解并掌握你所负责的产品，版本的演变过程以及未来迭代的方向，这一方面大公司文档或是信息沟通可能更为完善，小公司基本上就是通过上级领导或是同事来解答，剩下的就自己体验一遍，这样做其实效率很低，大部分人只有在遇见具体问题时才会深入去思考。
推荐做法是向公司了解是否有项目文档或是相关产品业务介绍与说明，然后下载最新的产品自己体验，一方面熟悉公司业务，另一方面作为用户体验并发现问题，最后，通过 App Annie 等同类型的数据统计或工具来详细了解迭代过程。
通过以上步骤，你会有较为清晰的业务轮廓，这时再与公司交流未来的版本究竟如何事半功倍。
无论是个人还是团队，都需要通过需求池来了解想法并且适时推进。
其次，我们究竟如何高效方便地管理需求池呢？
常见的需求池工具如下：
Excel：个人特别合适，每天的沟通与交流都有明确的指向与展示，然而对于团队而言，十分麻烦，即便有同步工具，还是很难处理并且无法了解动态。
Worktile：个人与团队皆有，个人版侧重于任务管理与资料记录，企业版关注内部管理与信息同步，这是我个人一直在使用的工具，同时与 Excel 相结合。
Teamabition/Tower：团队特别合适，这是项目管理与团队信息同步的工具，若是要采用，必须要求团队统一思想，一起使用，否则毫无意义。
Trello/JIRA：它们都是国外公司所开发，功能强大，但受限于互联网政策，采用的公司不多。
禅道：这是一款适合团队的应用工具，专注研发项目管理，支持敏捷开发过程。目前公司就是采用这款工具，优点是所有模块清晰准确，缺点是无法即时同步信息。
接下来，当我们采用了合适的需求池工具后，我们必须认真思考需求收集这个过程：
一、需求收集：
在这里，我们要清楚地描述需求得到的背景与状况，通过反馈者、受影响用户、描述问题并且补充信息几个方面来阐述。
客服告诉技术：今天有用户反馈扫码无法开门，希望你们处理下。
矛盾就很容易产生，因为缺乏必要的信息我们就无法判断问题的起因与解决方案。
我们再来看更为专业的方式，你们感受下差异：
今天用户 XXX，手机号码 XXXX（反馈者）打电话给我，他昨天下午四点在南江苑的订单无法扫码开门，提示他服务器异常（描述问题），他是用 IOS V3.1 版本的韵动网球 App 扫码的（补充信息），希望你们尽快处理。
两者相比，高下立见。
二、需求整理
需求收集后，我们接下来需要整理需求，推荐采用流程来处理：
第一步，判断这个问题是属于 Bug、改进还是全新需求？
第二步：这个需求是有效的还是无效的？
第三步：我们是否要做？我们如何做？
流程如下图所示（图片），思维导图分析和四象限分析法在前两篇文章中已经充分阐述了。
那我们再来看上面的需求如何按照流程处理：
根据信息，用户无法扫码开门，原因为服务器异常，这显然是属于重要且紧急的 Bug，并且十分重要，可能会涉及更多订场用户，需要立即修复，这是影响用户体验的巨大问题。
三、需求反馈
需求反馈也有原则需要执行：
尽量当下反馈结果；
尽量真实反馈结果；
进入需求池后，尽量有行动计划。
无论是立即修复，还是无法复现，无论是接下来版本上线，还是暂无关注，我们都需要告知反馈者相应结果，并适时调整需求池内容。
综上所述，我在结合上述思考后为公司提出的需求反馈原则如下：
向项目或产品负责人反馈问题，说清楚具体问题与反馈渠道。
统一收集需求池，将反馈分为 Bug、改进与新增，Bug 提交禅道，直接交由相关人员处理并告知反馈者结果，改进和新增则进入下一版本需求，同时调整产品开发优先级。
最后，我们要明确产品需求与版本的关系。
在我看来，版本是围绕着产品需求来设定的，我们先要了解公司的产品线，一般会分为官网及后台、App、微信公众号网站、小程序、运营 H5 等几类。
关于如何定义版本号，互联网公司的方法多种多样。我倒认为，方式是次要的，而核心是让团队轻松理解并且统一思想与认知，最为简单的方式就是：
主需求我们可以采用 V1.0 来表示，例如订场、电商、课程等都是产品的主要模块；
若有与主需要相关的其他需求，可以采用 V1.1 的版本号，例如场馆中增加视频入口与视频播放，
若是修复 Bug 或是改进等需要单独跟进，可以采用 V1.01、1.02 来区分，例如最后两片场地捆绑销售、过了当前时间还能够订场等。
至于何时发版本，这需要各方（市场、产品与技术）开会讨论确定，根据需求的优先级以及开发进度来控制，当然，最终确认只能视具体请可定，这里就不展开讨论了。
聊了这么多关于需求分析的那些事，想必大家已经有了更为深入的理解与认识了。需求真的不是一件小事，通过这些思考，转念一想，自己未来还得和它打交道，内心还是充满期待的。
总结就是，需求分析就是：观察——筛选——判断——迭代。这同样是一个产品的从零到一的发展历程，每一步都任重而道远。
本文最后，奉上我自己总结的产品开发流程，这是我个人对于从需求分析到产品上线整个流程的分析，我会在后续的文章中对每一部分尽力阐述与思考。同时，欢迎分享你的见解与思考。
希望你能够有所启发。