从软件需求分析到产品规划场景驱动和自验证

　　今天准备再谈下产品规划和软件需求方面的零散思考，在前面文章我专门讲过产品规划，也谈过软件需求梳理和分析的核心逻辑。因此这篇文章不打算系统讲解，而是从一些日常工作中的点滴实践说起。市场需求-》产品需求-》产品规划
　　对于产品规划，一般的方法论都会谈到从市场或用户需求收集，到产品需求抽象，再基于产品需求进行产品规划，并安排产品研发迭代计划。
　　对于互联网SaaS运营的产品来说。
　　实际你很难收集完整的市场需求，也就是说刚开始的市场需求是不完整的，那么自然对整个产品完整的规划也不可能。
　　在这种情况下我们更多的会思考产品是否解决了核心用户痛点，实际上能牢牢把握住这个点就足够了，这个足以让你发布V1.0版本的产品。
　　只要解决了核心矛盾，那么发布的产品就有人用，有人用你就能够通过用户使用和反馈来采集用户需求，并纳入到后续的产品研发版本规划中，这就形成了完整的持续迭代改进思路。
　　那么你研发的产品是否能够解决核心用户的痛点？
　　这个实际上才是最考验产品创始人或创业者的地方，很多时候是你以为能够解决核心用户痛点，而不是真正能够解决用户痛点。
　　什么意思呢？
　　我很早前就遇到过一个朋友出来创业，准备做一个给幼儿园用的SaaS应用软件，方便幼儿园进行教学管理，家校互动等，整个思路都很不错。
　　在准备做前也调研了好几个幼儿园，对方答复都是愿意使用。
　　于是这个朋友开始自己搞，投入差不多半年时间做了一个SaaS产品出来，但是一到了推广的时候发现问题了，除了一个亲戚开的幼儿园愿意用外，基本没有任何幼儿园愿意采用。
　　即创业者认为这个APP重点是解决类似远程视频监控，家园课表活动安排，照片视频，评论等家园互动内容。但是这个不仅仅是创业者理解的痛点，创业者更多的是站在家庭的角度来思考和看待这个产品。
　　但是最终推出这个APP买单的并不是小孩家长，而是幼儿园。也就是说你理解的痛点，并不是幼儿园的管理方认为的痛点。幼儿园实际最关心的只有能不能方便我多招生，能不能更好实现小孩不出事，能否在当前政府部门幼儿园的规章要求下多挣钱。
　　类似的例子还有我们给健身房做的管理类APP应用，给教培机构做的管理APP等，实际最后推的效果都不怎么好。
　　比如给教培结构用的管理APP应用。
　　如果你开始认为的痛点是方便机构进行课程管理，排班管理，学员管理，培训效果评估等，那么实际不可能推广得很好。但是如果你的APP重点是我现在已经有好几万的学生在上面，我能够帮你做引流，那么这就必然成为一个大卖点。
　　说了这么多，简单总结下就是，对于互联网软件产品来说，核心的需求驱动从来都不是效率提升，管理能力提升，而是利益提升。你推出的产品能否帮我赚钱，或者说能否帮我省钱。你推一个APP给我，我都还没赚到钱还要给你交服务费，那么没门。
　　一个好的产品往往应该是具备通过短周期迭代进行自我造血的能力，而不是一直需要不断的研发成本投入孵化，不断的成本投入无盈利往往并不具备可持续性。而好的产品就是迭代版本1上线就能够有用户，同时通过种子用户需求反馈不断的推出新的迭代版本，在每一个迭代版本都具备了自我造血能力。
　　产品规划很多时候实际上是站在成功者的肩膀上来完成，既有模仿，更有超越。一个好的产品不是产品研发使用的技术上的超越，而是对于市场和用户真实需求，和你需要提供的产品或服务匹配模式上的超越。对市场的洞察，对用户真正需求的理解往往才是做出好产品的关键。吃自己的狗食
　　在谈Scrum敏捷研发的时候，我们经常会谈到一个故事，即：
　　一天，一只鸡散步时遇见了猪。鸡对猪说：＂嗨，我们合伙开个餐厅吧。＂猪说：＂好啊，那准备取什么店名呢？＂鸡说：＂要不，就叫火腿和鸡蛋吧。＂猪直接拒绝了：＂那可不行。我要割肉，你只要下蛋。这样下去，我迟早要完蛋。＂
　　对于做产品，在微软本身也有一个吃自己的狗食的定律。即公司自己的产品，如果你真的想在这个公司出人头地，你一定要用，哪怕产品像狗屎一样难用，捏着鼻子咬着牙也要用，你不用怎么知道它烂？所以你对我们自己的产品，无论软件、硬件，在使用的过程中，你就能发现，它和你凭空去讨论一个概念是完全不一样的。
　　对于创业往往同样的道理。
　　特别是一些做技术的创业者出来创业，最喜欢的就是我只出技术，啥都不出，其它投资都让创投机构来投，失败了我也无所谓。对于这类创业者实际上真正做成功的很少。简单来说就是自己都看好的产品或项目，你自己都不愿意提前投入资金，那么你凭什么让创投机构相信你能够把产品做成功？
　　同时你投的是鸡蛋，而不是你身上的肉，你如何做到全力以赴？
　　在前面有文章介绍过，我们云团队实际从2016年底就开始做DevOps和容器云产品的研发，主要是为大集团企业服务。但是在19年我才开始推动这个DevOps支撑平台在公司内部涉及到的多个产品中使用，包括DevOps平台自身也必须使用DevOps支撑平台。
　　实际在我们自己使用过程中，本身又发现了不少在集成和协同方面的问题，在面对私有云和公有云协同集成中的问题，在敏捷研发和CI/CD整合中的问题等。
　　如果我们产品一开始就自己使用，我想整个产品当前成熟度会提升一个档次。这个就是典型的自己做的产品自己不用，希望推给别人用来帮你完善。当你按这个思路做产品，你很难真正以一个最终用户的角度来思考产品本身的问题和缺陷。
　　同时还有一个关键点就是技术驱动而脱离真实场景。这个后面我还会展开说。
　　类似的情况还有大概在10年我们做的基于CloudStack的IaaS云管理平台，这个平台同样是我们自己的私有云，虚拟机管理都没有用这个平台，反而是直接使用CloudStack提供的管理端，或者直接命令行去操作底层。
　　在这种情况下面这个IaaS管理平台如何能够完善和持续优化？
　　我们做SaaS版本的员工福利平台也做了很多年，从当前来看整体发展得还不错，实现了我前面谈到的衣食住行，娱教游购多场景，多类型，多渠道的弹性福利能力的对接。实际上当前福利平台已经变成了企业可用的一个福利能力平台。
　　对于这个福利平台，实际在每年类似端午，中秋，我们都会推出定制的福利礼品包，方便企业进行集体采购，平台也发挥集采本身的低成本优势。团队成员每年对于礼品包的选择，市场策划也花费了大量的精力和时间，但是实际前面几年推广的效果并不是很好。
　　我在当时提了一个最简单的问题，即：
　　福利团队制作的如此性价比的福利礼品包，你们团队成员有多少人自己去购买了？实际情况是没有或者只有少数的1到2个人购买。
　　可想而知，自己退出的福利礼品包，自己都没有兴趣购买，那么我们如何去说动别人购买。这也是典型的不吃自己狗食的做法。业务场景驱动
　　业务场景是什么？
　　简单来说场景就是需求，那么场景和需求之间又是什么关系？如果这个问题没有思考清楚，那么我们很难真正解决一个软件产品本身的核心竞争力和易用性等问题。
　　对于业务场景简单来说就是用户为了解决某一个问题，完成某一个目标需要使用你的APP完成的多个功能操作的一个合集。场景是多个功能点的合集，功能点本身脱离场景没有意义。
　　我们本身也在做云报销和商旅平台，这个平台本身也研发了快2年的时间，实际推广的效果并不是特别好，一个是本身研发投入不足够，没太多钱少，一个还是我们自己在研发产品的时候场景驱动和易用性思考不足。
　　场景往往涉及到业务流程
　　举个例子，一个员工要从深圳到北京出差，出差目的是A项目的售前支撑。
　　这个就是一个典型的APP应用的使用场景，基于这个场景可以看到，员工首先要提交出差申请，出差申请主管领导进行审批，审批通过后员工可以预定机票和酒店。在出差返回后，员工提单进行相关的费用报销操作。
　　创建出差申请单，预定机票，预定酒店都是独立的功能点。但是这些功能点本身是和员工出差这个场景绑定在一起的。
　　如果员工在实现这个基础场景过程中还要不断的切换界面和单据，不断去找功能，不断的重复填写单号数据等，那么显然这个APP应用做的不成功，虽然所有的功能实现都有，但是没有做到场景驱动，使用起来用户感知很差。
　　一个好的APP应用一定是基于场景自动地帮你做好相关工作和步骤的规划，你不需要去做太多的思考，安装向导一步步做完即可。
　　场景必须考虑角色
　　在Scrum方法论或者在传统的软件交互设计方法论里面，有一个关键的概念就是场景+角色。不同的场景往往对应到不同的角色，而不同的角色对于应用功能和数据的需求都明显不同，所以你首先要想清楚你面对的角色是谁。
　　还是举前面谈到的云报销系统的例子。
　　这个系统实际上会分为了普通员工，管理者，财务人员几类大的角色。普通员工的场景前面已经谈到了，而管理者本身也是普通员工，首先也需要普通员工的场景。其次管理者还需要有管理职能，比如最典型的职能就是预算控制。
　　因此管理者往往会关系部门每个月相关的差旅成本支出，费用支出等数据，关心数据的发展趋势，同比和环比，这些都将做为预算控制的基础输入。
　　而对于财务人员来说本身还分了财务经理和出纳，财务人员一个关心的是整个单据处理和报销支付过程效率，一个是关心系统提供的数据要方便按部门，按项目进行全成本核算。
　　正是由于不同角色人员实际关心的内容并不同，这些不同都应该在APP应用实现的时候差异化地进行实现和应对，而不是简单的提供数据层面的增删改查+权限控制就完事。不要盲目追求100%的产品化
　　每年的年底我们都会做产品规划，或者对去年的产品规划进行更新，但是发现每年实际的执行情况并不太好，很多规划的内容实际上都没有最终落地实现。一般真正完成度也就在60%左右就很不错了，最终的原因还是在团队本身是项目驱动型，在项目中去完善产品，而不是产品驱动型，能够做大量提前的投入。
　　项目驱动型本身没什么不好，实际上我们看到真正被抽象到产品化里面的功能本身就应该是经过大量项目实践被充分验证后的功能，而不是你自己凭空想象的理想化功能。理论虽然高于实践，但是必须先来源于实践，否则就是无根之木，无源之水，最终各种理想化的需求或功能用户最终并不买单。
　　项目型最大的问题就是需求和功能的实现为了满足快速高效的项目实施交付，往往很难去做比较完善的需求抽象和统一业务建模，这也导致最终的功能很难形成通用化的产品功能。那么一到项目实施进度紧张的时候，实际上并不会有额外的资源来考虑产品需求或产品化功能的开发和实现。
　　不要去追求100%的产品化，实际上能够做到80%的产品化再加上20%左右的定制化开发更加现实。
　　做任何一个产品，你都需要思考清楚你是走产品化路线还是产品+实施路线。如果是走完全的产品化路线，那么重点在于产品底层核心技术能力的研发，高可靠性等，而产品+实施路线往往体现的是大型项目本身的咨询规划和实施经验方法论积累。
　　类似我们自己的SOA产品，云原生产品，我们更多就是考虑走产品+实施路线，即为客户提供一个完整的解决方案和最佳实践，而不是单纯的卖产品。
　　任何产品团队，如果没有大量创投烧钱给你，那么你首先要解决的是生存问题，其次再去考虑发展问题。项目型方式可以更好的解决生存问题，即团队首先要有自我造血功能，不会因现金流断裂而死掉。在项目型运作中你还得解决一个商业模式中经常谈到的可持续化问题，可持续的现金流和盈利更加重要，这个可持续就可以用来专门拨出研发费用来支撑公司或产品团队的研发投入，只有这样才可能实现项目到产品的转型。
　　市场是校验产品的唯一标准，产品规划和产品研发最终还是要满足市场和客户需求，在为客户创造价值的时候实现赢利。产品研发出来如果没有市场，那么就是失败，没有可持续的市场也是失败。
　　那么如何控制产品研发功能偏差和投入？
　　这里面最关键的仍然是尽早地将产品推向市场，接受最终客户的检验，从市场获取第一手的需求反馈，短周期快速迭代是当前产品研发节奏下最核心的思想，否则错失市场和竞争优势。
　　做产品规划一定要大量项目实践的记录，只有大量项目实践你才知道应该如何抽象和建模。
　　产品研发做到中途，最难的就是决策是否继续做下去，这跟你买一支股票以及腰斩后决策是否割肉一个道理。如果不再投入，那么前面全部是沉没成本没有任何价值，但是如果继续投入短期又看不到希望，只能够是走一步看一步。
　　但是根据我们实际的经验，产品阶段决策的时候，仍然应该有及时止损的思路，对于看不到希望的产品研发要及时终止，不要有太多的侥幸心理。
　　对于当前很多SaaS类产品也是同样的道理，一开始推出就开始订阅和收费，但是实际上很多产品即使全部免费估计也很难有大量用户使用，如果这样的话还不如及早放弃投入，降低损失。
　　当然对于项目型，实际体现的是一种边际递减效应。
　　比如我们做100万的项目如果需要5个人支撑，那么我们做1000万的项目绝对不是50个人支撑，而很可能是30个人甚至更少的人支撑才合理。也就是说项目推广扩展过程中，不是简单的订单额扩展，而是必须考虑单人支撑的订单额指标的提升，否则就全变成了项目化和人力外包，没有任何意义，本身也很难真正创造更多的价值和利润。