产品复盘：自助收银机项目的得与失

　　本文笔者根据自身项目经验，详细复盘了自助收银机项目从0到1的全过程，总结了在项目执行过程中所遇到的问题，分享给大家用以参考学习。
　　自助收银机从2018年12月份开始决定做，到今年3月初出来第一台样机（EVT2），4月初完成3台样机并拿到便利店里面试用（DVT），再到5月份完成30台小批量试产（PVT）。在整个研发过程中，产品得到了开发、测试、用户的一致好评。
　　从12月初接到任务的时候，只有我一个孤家寡人。过了半个月，从星座运营转岗一位同事过来，简单面试后，让她来担任自助收银机的项目经理，又过了一个月，招来了一个重来没有接触硬件的产品经理。加上我，三个人取名为“三个臭皮匠自助收银”团队。
　　自助收银机的功能用一句话概括就是：先扫一下商品条形码，然后再扫一下付款码，这样就完成了整个结算流程。
　　现在从产品的角度复盘一下，取得成功的因素有哪些，有哪些需要改进的地方。
　　战略层：产品目标
　　不难看出，该产品是一个2B的产品，客户是便利店的店老板，但该产品的真正使用者是用户，那么我们就要解决这两类用户的问题。
　　对于采购自助收银设备的客户（店老板）来说，他想解决什么问题？
　　对于使用自助收银设备的用户来说，他想解决什么问题？
　　对于第一个问题，店老板的核心需求：花更少的钱，干更多的事。用一个时髦的词汇就是：效率。提升员工的工作效率，以此来提升店面的销售额。
　　如何才能花钱少，那么他的支出有哪些呢？
　　A。压货的钱
　　B。员工的支出
　　C。固定支出（房租、水电等）
　　D。货损
　　自助收银机显然干不了C的事情，肯定能干B的事情，因为一台收银机可以相当于一个收银员。也许能干A和D的事情，如果做智能统计管理，让压货更合理，对快过期的食品进行促销，从而来降低货损。
　　如何干更多的事情？
　　A。解放人力，让人去干其他的事情，如盘点。
　　B。效率的提升，带来了业绩的提升，销售额的增加，在进行低利润促销，形成良性循环。
　　自助收银机是能达到以上目的的。
　　对于第二个问题，用户的核心需求是：不想枯燥无聊的排队，结算要快、方便。显然自助收银机能达到此目的。
　　不难看出，自助收银机既可以帮助用户提升结算效率，又可以帮助客户降低运营成本（也就是带来了收益），一个双赢的局面。
　　范围层：确认功能列表
　　自助收银无非就是扫码、支付、打印。虽然确定了大概的要做什么，但还是应该去调研，去访谈。当时确定了三个调研方向：
　　对于已经使用了自助收银设备的商超，在使用收银设备的过程中有什么问题？
　　对于还没有使用自助收银设备的商超，现有的收银方式有什么问题？
　　工作中最大的困扰是什么？经营方面有什么问题？
　　需求从0到1
　　在需求从0到1的过程中，做了如下几件事情：
　　与集团内的新零售部门的人员沟通及收集需求。
　　到集团的便利店里面进行调研，与店员进行深入的交流与沟通。
　　通过朋友关系，到Today便利店进行访谈。
　　购买竞品设备，进行竞品分析，分析别人的软硬件功能。
　　综合所有的信息后，通过KANO模型分析，确认了需求优先级，同时也确定了MVP的内容，并对MVP的内容进行制定项目计划。
　　产品成功指标
　　明确了产品的目标，也知道具体要做什么功能了，那么评价该产品被做出来后，是成功还是失败呢？所以在做之前，就与项目经理和产品经理讨论了一个成功的指标：
　　整个硬件成本控制在3K以内
　　购买一件商品时，整个结算流程在45s之内完成
　　能有效降低运营成本，至少减少一个人力
　　产品良品率高于97
　　项目计划
　　经过讨论确认后的MVP包括：
　　扫描商品条形码
　　结算支付：支持支付宝和微信
　　打印商品清单
　　USB驱动、屏驱动、打印机驱动、扫码器驱动
　　前三个属于软件，最后一个属于驱动。期望需求和兴奋需求一律不做，等小批量之后再做。对这个MVP进行了两轮迭代，第一轮迭代完成的任务包含：扫码，支付（仅支持支付宝），USB驱动、屏驱动、扫码器驱动，电路板用开发板。第二轮迭代完成：支付（微信）、打印及用自己设计的电路板代替开发板。
　　页面流转图
　　虽然扫码，支付，打印，说起来流程很简单，但里面的逻辑分支还是很多的。当时逼着产品经理画页面流转图，由于总是有逻辑上的漏洞，所以总是被我提意见。出于项目保密的需要，这里放出一个不太清晰的图：
　　当初画这个图的原因是，有些开发人员责任心不强，产品文档又没有说清楚，逻辑上有漏洞，测试发现一堆bug。为了防范于未然，所以只要我负责的项目，如果我是产品经理，我就会画这样的图。如果是其他产品经理，则会要求他提供。
　　定规则
　　为了让产品能顺利的落地，在开工之前就制定了几条规则：
　　禁止产品经理与开发测试员工进行点对点的变更需求和新增口头需求，必须在文档里面体现，并通知全项目组成员。违反一次，产品经理请大家喝娃哈哈（因为便宜，只想达到警戒的目的）。在实际执行过程中，产品经理是在这方面吃了几次亏，当然同事们说我又在给他们谋福利。
　　所有的测试必须有据可依，如果是文档不清晰，找产品经理。如果是bug，直接提bug。
　　所有的bug先提给项目经理，然后由项目经理来分配并跟踪。这样做的目的，是要让项目经理要时刻知道项目的问题及风险。
　　错误的决策，正确的执行。一旦形成决策，不论产品需求是否合理，必须无条件执行。在形成决策之前，在需求澄清会议上可以发表任何意见。
　　项目经理和产品经理必须参加测试用例评审。
　　其他
　　心胸要宽广，通过成就下属来成就自己。
　　要大方，有时开会的时候，或者达成关键里程碑节点时，会给对应人员买杯咖啡。
　　失误
　　当然，产品在执行过程中也犯过不少错误：
　　由于当初硬件选型把关不严，芯片应该选用另外一款，更符合期望和兴奋需求的实现。
　　物料把关不严，购买的是A公司的，结果供货商发过来的是B公司的，怎么调试都不通的时候，发现是货不对版。
　　软件开发有返工的现象，主要还是产品原型不够清晰明确，让UI设计师和开发人员产生了误解。
　　由于没有要求产品经理画用户体验地图和服务蓝图，所以业务逻辑描述上有漏洞，交互上的体验也不好。
　　后记
　　当把三台DVT样机拿到店里面试用以后，我们进行了用户回访，店员对产品给予了很高的评价，说大大节省了结算的时间，用户也不用排队了。产品在质量上还有一定的小瑕疵，毕竟是DVT阶段的产品，还需要经过PVT的测试，软件也还需要打磨，在交互、用户体验上提升。
　　虽然上文提及了产品成功的指标，这个只是我们的自己认为，开始做产品时，制定的一个奋斗目标。真正的成功指标是来自于用户和市场。
　　从测试结果看当初制定的成功指标：
　　成本控制在3K以内，已经达成。
　　单件商品结算45s内，已经达成。
　　有效降低运营成本，已经达成。
　　良品率高于97，目前还未达成。
　　接下来一段时间，会在良品率和用户体验上下功夫。