文章目录
- 前言
- 一、产品视角之三大困难
- 二、技术视角之难以抉择
- 三、利用小程序云基础设施“低成本试错”
前言
学生团队和初创团队在没有得到风投之前，想要做出一款产品太难了，难在哪呢？难在没有资源。用最狭隘的视角看这个资源：人力、财力，这两个最基本的资源，成了一个创意型产品面前的一座大山，难以跨越。本文从这个最基础的问题出发，用产品和技术的双视角，逐步的分析问题，并利用现有的小程序云基础设施给出一个合理的破局尝试路线。
产品背景：一个跨领域创意型的应用，会为家庭成员创建一个共享空间，在这个共享空间内，会定制各种小功能，这些小功能会涉及不同的领域。
注：本文省略产品详细信息，单独谈谈这个大方向上的问题，实际上这个问题也适用于很多领域的产品。
一、产品视角之三大困难
首先，从产品的视角来看。我们的产品是一个跨领域的应用，这引出了我们的第一个问题：面对众多应用场景，究竟该选择哪些功能进行开发？换句话说，用户会喜欢哪些功能，而哪些功能对用户来说是无意义的？是否需要逐一尝试所有功能？这样做会导致我们的人力成本非常高，并且很有可能在某个领域开发出一个小功能后，却发现用户并不愿意使用。
其次，单独来看，这些小功能本身都可以发展成一个完善的应用。那么，在将这些小功能集成到我们的家庭空间应用中后，每个小应用需要做到多深、多完善？是否需要对标市面上成熟的产品？如果这样，我们可能需要在某些小领域上花费大量时间。
最后，作为一个跨领域的应用，我们不可能一次性将所有功能做到完备。我们需要持续迭代，开发出新的、有吸引力的功能。那么，未来该如何决定拓展哪些领域呢？单纯依靠产品团队内部的创意吗？我们并不是成熟的产品经理团队，这很可能仍然是一个试错的过程。
这三个问题是我们团队最初一直困惑的核心问题。经过仔细分析，我们发现它们都有一个共同的关键问题：成本。这里的成本包括人力投入成本和宣传推广成本。
现在我们设想一种理想情况：假设大厂的一位大佬，例如阿里的一位P10，决定开展这样一个项目。一种直观的做法是，直接成立一个业务单元（BU）来专门负责这个业务，并下设若干个跨领域试验组。假设第一个最小可行产品（MVP）版本需要实现三个跨领域功能：日历、相册和回忆。同时，设立一个创意组，专门挖掘市场上适用于家庭场景的领域。
这三个跨领域的功能将以市面上成熟的产品为标杆进行设计。几周之后，这些功能上线，再过几周，根据数据反馈确定这些小领域的效果。表现良好的组将继续进行更深度的迭代，而效果不佳的组则会被撤销，相应的功能会被移除，并从创意组中重新选取一个领域进行尝试。这种循环往复的过程将持续，直到产品获得显著的市场影响力。这个设想十分美好。
然而，现实情况是，我们只是一个由不到十人组成的小团队，并且管理经验也不丰富，带着有限的经费开始项目。我们仓促决定开发哪个小领域，辛苦从课程和考试中挤出时间，花费大量精力开发出日历功能，最后却发现用户反馈不佳，导致团队士气大幅受挫，项目无疾而终。这虽然听起来有些可笑，但实际上，这正是学生团队在做这类项目时的真实情况。
总结来说，其实就是试错成本过高。
二、技术视角之难以抉择
接下来我们带着这种理念，从技术的角度探讨这样一款产品可能面临的问题。
假设我们从零开始开发一款产品的服务端能力，具体需要做哪些事情呢？这里假设我们不是简单地做一个Demo，而是希望开发一个长期运营和维护的产品。
首先，我们默认选择Java技术栈，启动一个SpringBoot项目。这时，我们可能会开始疑惑，是选择单体架构还是微服务架构？如果是单体架构，如何处理授权、选择中间件来解决业务问题以及如何部署？如果是微服务架构，服务管理变成了一个问题。我们需要选择注册中心、配置中心、网关等组件，考虑是否需要分库分表以及如何处理分布式事务和分布式锁等复杂情况。
这些都是服务端架构设计时需要考虑的问题，而这些问题与具体业务密切相关。我们需要对业务问题有深刻理解才能做出正确的技术选择。然而，许多业务问题只有通过现有产品的反馈才能发现，这就形成了一个死循环。于是，经过反复考虑后，可能会决定放弃这个项目。
再审视这些技术问题，其实本质上在于初期不知道项目的规模，不确定需要为未来的扩展留多大的空间。如果一开始就采用复杂的技术架构，耗费大量时间成本，但市场反响不佳，就会浪费大量人力成本。归根结底，问题仍在于成本。因此，在技术上，我们需要具备低成本试错的能力，因为没有最好的技术，只有最贴合业务的技术。
让我们从更加实际的成本角度来看待这些问题。一套服务端系统的部署费用包括计算成本（用于部署实际的服务）、存储成本（例如持久性数据库如MySQL和对象存储OSS）以及缓存成本（例如Redis），其余更复杂的中间件暂且不提。对于小程序场景，需要通过HTTPS访问外部接口，因此需要购买域名和SSL证书。即使是最便宜的单域名SSL证书，一年也需要约500元。总的算下来，可能需要几千元的开销。对于仅仅想进行尝试的学生来说，这样的费用还是比较高的。因此，我们需要在资金上实现低成本试错。
此外，资金上的低成本还体现在宣传推广上。如果将产品做成一个APP，如何让用户主动跳转到应用商店下载将是一个令人头疼的问题，也是初期推广产品最花费的问题之一。没有风险投资的支持，很多产品可能会在这个阶段夭折。
三、利用小程序云基础设施“低成本试错”
说了这么多问题，最后我们得出的解决方案是：使用支付宝小程序和小程序云。这并不是为官方做广告，而是我们团队在实践中得出的经验，不同的人、不同团队、不同领域可能会有不同的理解，我们给出我们团队实践的经验做为参考。
我们认为，将这两项技术组合在一起，为我们团队提供了低成本的试错能力。借助这个基础设施，我们可以更有效地解决刚才提到的问题，下面具体说明这种低成本试错能力体现在哪些方面。
首先，小程序可以解决APP获客难的问题。支付宝拥有上亿的日活跃用户，并且对用户群体划分非常精准。我们可以在支付宝的公域中向目标用户推送广告，用户只需点击一下即可体验我们的产品。此外，支付宝还有视频、生活号等多个推广渠道，并且自带一些社交基础设施，小程序可以方便地在单聊和群聊中分享。这为我们解决了一个重要问题。
从服务端成本来看，支付宝小程序云的计算、存储、缓存成本都相对较低。通过简单对比最低资费标准，二者的成本差距非常明显。此外，自建服务还需要专门的运维人力，这也是一笔成本。而使用支付宝小程序云提供的开发基座，可以解决很多基础开发问题，我们只需利用云函数专注开发业务即可。只要设计合理，我们可以在一周内开发出一个跨领域的小功能。支付宝小程序云从技术层面为我们提供了低成本试错的能力。
有了技术层面的支持，我们就可以磨合一套适合团队的敏捷研发流程。我们首先根据内部创意和用户反馈收集不同领域的需求，然后在最短时间内开发出基础版本。定向向我们团队周围的目标群体推送新功能，及时收集用户反馈，并根据数据和用户反馈进行复盘，决定是否保留这个跨领域的功能。如果决定保留，还需要考虑哪些改进。
总结来说，我们团队利用支付宝小程序和小程序云的基础设施优势，在家庭内的每一个小领域进行了低成本的试错。对于这些小领域的初期试错，我们不需要过多考虑扩展性，最重要的是能快速上线收集用户数据和反馈。这是决定一个小领域是否要在家庭空间中深入发展的依据。通过这种模式进行尝试，我们在服务器成本和宣传成本上都实现了低成本。
这些因素共同构成了我们在决赛现场所说的“低成本试错”能力。
ATFWUS 2024-07-05
