首先来讲，我所在的公司是一家教育公司，我所做的业务是针对的前端销售群体，几乎做的所有项目都是为了帮助销售与潜在学员沟通，最终报名参加公司的课程。
直播咨询的项目是我进入公司的第一个项目，下面是整个项目的复盘总结；
项目背景：
首先是因为公司的销售模式主要是电话销售模式，而在电话沟通过程中与学员建立信任关系并且让学员报名实际上是比较难的，所以很多时前端销售会把学员引导到开在全国各个城市的分校去，由分校的课程顾问与学员进行沟通，但是因为公司的广告投放涉及全国各个省市，很多地区是有学员但是没有分校存在的，为了解决这个问题，我们决定用直播的方式拉近与学员之间的信任关系来促成报名，负责直播的销售是通过筛选的专业性更强形象更好的老师
项目目标
通过直播咨询的方式打消学员的信任疑虑，促成报名；
目标拆分：
1，预约，原因是每个老师只能为一个学员进行一对一咨询，占用老师的时间，所以需要先预约后直播；
2，直播，是整个项目的核心关键，由云直播老师与学员通过直播方式进行沟通；
先完成的是预约模块，原因是直播环节业务目前借助了一个第三方软件可以实现，但没有与系统进行打通
项目结果
1，迭代汇总：
以上是这个项目做的所有迭代汇总，共完成7个迭代，花费时间差不多是7个月；
2，目前项目情况：
预约模块总覆盖率达到了全国分校全部覆盖，但直播部分覆盖率较低；
原因分析：
1，首先根据迭代功能列表就可以看到，1.1版本几乎是1.0版本的一个修复。
主要原因在于对需求的错误理解，在当前公司的业务情况下，创建预约单和进行直播的销售不是同一拨人，且没有统一的业务管理，双方都希望自己拥有更多的主动权，而产品没有追究到各自有取消预约单会带来什么样的结果，只是根据一种场景做出判断，将预约单取消权限放给了前端销售，这样直接出现了致命问题：前端销售很多在不太熟悉直播模式的情况下贸然下了预约单而不进行取消，结果大量学员爽约，造成了云咨询销售时间的大量浪费；
而真实的业务场景是：前端销售下了预约单后，云咨询销售会进行核实确认，如果学员时间不方便的情况下可以进行改约或者取消，类似于我们医院挂号，体检预约的情况，所以紧急上线了1.1版本修复；
另一个问题：系统上线后发现前端销售热情非常高大量下预约单，而云咨询师的规模团队却完全跟不上，不得不让云咨询的主管也进行接单，这里面存在着巨大的问题，就是俩个团体量级悬殊的情况下，贸然全量上线必然会出现问题，正确的操作方式是进行灰度上线，选择一个与云咨询销售团体规模匹配的前端销售团队进行上线，当然这里如何选取灰度上线的业务团体也有大量的工作量在里面，比如这个团体对云直播咨询项目的认知程度，以前云咨询对接过的团体的粘合程度等，核心点在于预约单数量的衡量；
2，根据第三个版本的迭代内容会发现，大改了分配规则，同时修改了创建预约单的限制
这里面的一个主要原因是业务发展超出了预先的规划，换句话说就是产品规划里压根没有预知到业务接下来发生的巨大变动，这个当然是有沟通问题在里面的，在调研需求过程中太着力于眼前的业务形态，而没有对业务的未来进行长远规划，造成了低层根基的不稳定，个人认为这个也是产品规划不到位的问题，是大忌；
另一个功能的原因是前端咨询师下预约单后，云咨询师需要足够的时间去准备直播设备，进行调试的，业务上云咨询师不是随时待命的状态，基本都是有预约单才去准备，而前端咨询师没有任何管理上或者系统限制，一旦前端咨询师下了当前时间的预约单，云咨询师就来不及准备，最后给学员的体验也是很差的，所以迭代里修复为前端咨询师只能创建当前时间30分钟后的预约单，这样的修复一样也是代价太大，因为同样这应该是1.0版本应该完成而疏漏的地方；
3，而在1.3的版本迭代中新增了云咨询师的权重管理，同时增加了云咨询师收到预约单后的消息提示，以及统计界面增加了流水字段，而事实上消息提示这个功能在第一期或者第二期就应该上线，理论上来说是这是必须需求，云咨询师只能被动接预约单，等待过程中如果没有提示就很容易错过预约单，这同样是最初梳理需求存在的遗留问题，而咨询师统计流水的问题，事实上统计功能不是优先级最高的功能，应该是放在第二优先级的，项目初期应该先以核心功能为主，统计需求是根据已经上线的功能逐步完善出来的功能，前期的时候是可以通过线下数据库导出表格的方式来满足业务的需求。对于个体业务咨询师来说，他们最关心的是自己的流水，这样可以核算出自己能拿多少绩效。而管理者来说，则更关心的是整体的数据情况。所以本次项目的一个很大的经验，做项目的前期先不做统计，等业务自己明确了统计需求再完成。
4，从1.4版本开始，我们与第三方合作，接入了直播环节，于是整个项目变成了一个复杂体：pc网页端+pc客户端+移动小程序端；我们合作了腾讯，为我们提供客户端的直播软件和小程序的直播功能，我们在对方的基础上进行改良，从此开始，项目进入更加泥泞的阶段，这里并非黑腾讯，而是仅仅在这个直播模块来讲，我们的项目首次提出了用客户端和小程序打通进行直播，而这种类型的项目市面上还没有成熟的产品，同样腾讯也没有成熟的技术，所以进入了双方磨合相互尝试探索的状态；
直播的核心是云咨询老师从网页唤起客户端直播间，然后学员从小程序进入直播间，进行直播沟通，而整个直播过程中最核心的环节是客户端需要支持播放ppt，小程序端可以同步看到ppt，目的是运咨询老师可以在直播过程中与学员分享物料，方便解说，同样，直播间具有唯一性，一个云咨询老师对应一个学员，这里就涉及到了并发量和唯一识别码的问题，因为公司主体模式是电话销售和微信销售，所以采取了短信和二维码俩种方式来发送给学员唯一识别的校验码，这次迭代在产品需求层面来讲是没有偏离的，但是问题出在了技术上，由于合作双方的技术不成熟，导致了直播过程中的各种不顺畅，容易中断，容易卡顿，尽管是灰度上线，依然给业务带来了非常不好的体验。
而上线后出现的问题就是小程序端直播过程中播放的ppt太小了，学员完全看不清楚内容，于是我们紧急上线了1.4.1版本，小程序端支持横屏功能，在直播过程中客户端共享了ppt的时候，小程序端直播间自动横屏，同时支持客户端放大缩小ppt实时同步到小程序去。
5，在后续紧跟的1.5版本中，我们做了直播过程中的视频录制已经存储功能，主要目的是方便后续质检和销售质检相互学习的物料收集，这个版本没有在1.4完成的原因之一在于合作方当时没有提供视频录制功能，所以不得不双方进行同步开发，然后完成上线。同时该版本修改了转预约的时间限制，以及云咨询师进入直播间后消息提示前端咨询师，主要目的是双方信息对称，及时了解学员动向，避免重复跟进，话术不一致等情况。这一期同时做的是云咨询师可以自己修改预约的时间，原来如果学员要改约时间，那么只能是取消预约单重新下预约单，在本期修改为可修改时间也可以取消，在业务上大大方便了销售人员的操作灵活性。
而在以上版本之后，业务进入相对平稳状态，产品迭代周期拉长，相当于一直在维护项目的稳定以及直播上的bug修复问题上。
总结经验
在项目规划的初期，不仅要规划业务现有的需求，更要规划业务未来的需求，因为很可能业务在飞速发展的过程中，按照现有的设计模式根本无法满足他们未来的业务发展，打了一个平方的根基是很难在上面盖楼房的，所以一定要深入了解业务究竟想把项目的未来做成什么样子，如何用最基础，最小代价去满足后续的需求，是十分重要的问题。根基没打好，意味着俩种结果，第一是不断推翻原有的东西重做，开发资源浪费且项目进度变慢，第二是系统拖垮业务发展，当然后一种一般不那么容易，业务发展快的同时适应能力也很强，但是不得不承认还是会受到系统的制约，影响业务的发展节奏，影响销售业绩。
整个项目在做的过程中感知上的节奏就是很紧张，然后不断埋之前挖下的坑，基本节奏就是挖坑，埋坑。核心原因在于最初的项目规划做的不够完善，没有把后续看似意外出现的情况考虑进去，直接影响了整个项目的优先级排序和进程节奏，导致一直很忙很累，做的东西却不是最核心的。比如消息提示功能，本来应该在第一期就一定要有的功能结果放在了第四期，对销售人员造成了很大的困惑，所以他们会更加着急。而同样吸取的经验是，产品经理是一个客观的位置，不能因为销售着急就着急，着急会乱了方寸，会被销售人员行业内的固有思维带跑偏，导致出现了很多伪需求而来不及深挖，这个的代价是十分巨大的。
项目规划好之后，要尽可能的深挖项目细节，但是并不代表把每个细节都做到功能中去，而是项目的细节很可能会影响项目的方向，把细节了解清楚了，才可能知道后续可能迭代的功能点在哪里。比如录制视频后视频给谁看的功能，如果我们只考虑录制的视频目的是咨询师相互学习和质检，那么就会把视频和预约单放在一起，前端咨询师和云咨询师所有人都可以看，但是这就犯下了一个致命的错误，前端咨询师会复制学习云咨询师的直播技能，然后替代他们，就会出现恶性竞争。这里的问题在于少问了一句“什么样的咨询师会需要直播的物料”，答案不是所有人，而是云咨询师，这个问题不是适用于所有的业务模式，但是就当前项目的业务模式来说，前端咨询师与云咨询师是相互独立管理的同时相互依赖的，也就是说他们依赖着对方的专场，前端咨询师一旦学会了直播咨询，他就不再需要直播老师咨询，会另起门户。而云咨询师依赖前端咨询师帮忙预约学员，一旦前端销售不再依赖他们的直播能力，云咨询师就会没有工作，这在整个公司整个框架的规划里是不允许出现的。所以一定要深究需求，深究细节，同时兼顾整个公司的发展规划，很多时候也许需求不是错的，但是不符合整个公司的发展规划，这样情况下更是需要深思。
另一点是合作方的选择，业务起步初期用的是一家做视频会议的软件，是手机客户端和pc客户端进行连接直播的，好处是稳定清晰，能保证直播顺畅完成，坏处是下载软件门槛高，很多学员不愿意下载软件，同时录制的视频没办法与预约单匹配。而面对这种情况，我们做了一个迷糊的决定，就是偏信大公司，选择了腾讯，并非选择腾讯是错的，而是我们没有做好背景调研，没有把俩家公司的优势劣势拿出来比较分析，就直接武断的选择了腾讯。而事实上，腾讯在客户端直播这块的东西基本是没做过，没成熟产品的同时没有相似经验，所以导致了在后续过程中的很多问题，比如客户端直播间兼容windows系统版本的问题，比如对电脑配置要求边界的问题，比如最低带宽边界问题，再比如小程序屏幕适配的问题，小程序与微信兼容的问题，很多很多层出不穷的问题，一个不成熟的产品最基本的体现在于边界不清晰，100兆带宽没有问题，但也许50兆带宽就出现了一大堆问题，更要命的是可能20兆带宽出现的问题和50兆带宽出现的问题完全不一样，尽管双方密切配合紧急修复，但是不断发现问题解决问题这里面的消耗十分巨大。而回过头来说，我们如果对比了俩家第三方直播公司的优势劣势，与双方进行深入洽谈后，应该会有更加合理的解决办法，再次表示并非选择腾讯是错的，也许选择了另一家公司一样会出现很多问题，这里要总结的是选择第三方合作的时候一定要做好对比，做好深入了解。
产品在跟进完成项目的过程中，还有很重要的一个经验教训是，如何量化你的工作成果，也就是说需要一个指标，或者一些数据来证明你做的迭代功能是正确的还是错误的，如果是错误的我们可以根据数据及时发现问题进行修正，数据能够给我们带来很多意想不到的收获，而要想量化工作成功，那么就需要在产品初期的时候做好数据埋点，你要根据哪些数据去得出项目结果，就需要考虑在哪些位置进行埋点，当项目进行到一半的时候再考虑埋点已经来不及了，一方面是没有意义了，另一方面是没有开发愿意再去做这件事情，开始做要比后面做的成本小很多很多。当然后续发现数据有问题也可以不断去修正，重要的是做项目的前期一定要有意识的做好量化指标和数据埋点字段。
所以很多时候项目初期要决定的事情没有做好，会给后续的迭代造成很大的困扰。个人理解，迭代的内容基本以下几点：规划中要完成的内容，上线后业务方提供的新需求，上线后出现的需要修复的问题，这三类需求。每次迭代应该是这三类需求都有的，当然第三类需求没有是最好的，根本在于不能只顾着埋坑丢弃了整个项目规划的进度，也不能为了整个项目的规划进度不接新需求。在这一点上要求产品随时关注着项目，与业务方保持紧密联系，随时收集业务反馈的同时关注数据库，业务没有发现的问题可能数据库会告诉你真相。这里需要产品能够会自主查询数据和整理数据，这一点对我来说也是很大的经验教训，要学会查询数据库，要学会做数据表格，这应该是产品的底层能力。
总的来说，这个项目做的并不算顺利，甚至并不能说是成功，但是正是因为不够顺利，所以把该踩得不该踩的坑全部踩了一遍，为以后积累的宝贵的经验教训。就个人而言，产品迭代过程中，不要因为项目紧急而乱了节奏，保持清醒平静的思考很重要，产品是中立的，你做的项目里面有你的智慧和思想，倾注着你的心血和汗水，所以要珍惜机会，把握机会。对项目负责，更要对自己负责，对与你一起并肩作战的开发团队负责，对依赖着你的项目进度发展的业务团队负责，不要因为你的疏漏拖累项目的节奏，所以要更加严格的要求自己，去不断的学习和积累。
走过这一程，相信后续的项目会做的更好，更完善。