2015年移动游戏创业失败复盘三：技术负责人最容易做错的产品决策

技术负责人做游戏创业，有一个很隐蔽的风险：你会把自己最擅长的事情，误认为公司最需要的事情。

2015 年开始做移动游戏创业时，我身上最稳定的能力就是技术。之前在腾讯和搜狐畅游参与过游戏和游戏社区开发，客户端和服务端都做过，所以我对项目里很多工程问题并不陌生。移动端适配、资源加载、网络协议、热更新、服务端结构、数据存储、活动配置、日志、监控，这些东西我都知道重要性，也知道如果一开始不考虑，后面会出问题。

问题恰恰在这里。

因为我知道它们重要，所以我很容易提前做。因为我能做，所以我容易说服自己应该做。因为做这些事情能带来确定进展，所以我会在不确定压力很大时躲进工程任务里。创业失败后我才明白，技术负责人最容易做错的产品决策，不是写错代码，而是在错误阶段把工程完整性放到了验证前面。

工程完整性带来的安全感

创业早期到处都是不确定。产品方向不确定，目标用户不确定，渠道不确定，收入不确定，团队能撑多久也不确定。相比之下，工程任务让人舒服得多。今天完成账号模块，明天打通协议，后天把配置系统跑起来，再过几天完成资源更新。每一项都有明确边界，有完成标准，有可见结果。

这种确定性会让技术人产生安全感。

我当时很需要这种安全感。因为产品和市场的问题太模糊，讨论起来容易没有结论。玩家会不会喜欢？渠道会不会给量？题材是否有吸引力？首日留存靠什么？这些问题没有日志，没有堆栈，没有单元测试，也没有一个人能拍桌子说百分百正确。相比之下，服务器能不能稳定连接，客户端会不会崩溃，配置能不能热更，都是可以解决的。

于是我会自然地把时间投入到工程建设里。不是因为我懒得面对产品，而是因为工程问题更像问题，产品问题更像雾。

但创业最重要的，恰恰是走进雾里。技术负责人如果只处理确定问题，就会让团队在最不确定的地方停滞。产品核心是否成立，用户是否愿意回来，市场是否能触达，这些问题不会因为后台系统更完善而自动得到答案。

工程完整性有价值，但它不能替代产品验证。

过早建设基础设施

我们当时做了不少现在看起来“阶段过早”的基础设施。

账号体系希望以后可扩展，协议设计希望支持多种玩法，活动系统希望后续能灵活配置，后台工具希望运营可以使用，资源更新希望能覆盖各种场景，服务端结构希望未来能拆分。每一项单独看都有理由，而且如果产品真的跑起来，确实会需要。

问题是，产品还没有证明能跑起来。

早期移动游戏最应该验证的，是玩家是否愿意进入、是否理解、是否觉得有趣、是否愿意第二天回来、是否能被素材吸引、是否愿意为某种价值付费。我们却花了相当多精力去准备“如果它成功之后会需要的东西”。

这不是技术方案错误，而是时间顺序错误。

创业项目里，时间顺序非常重要。同样一个系统，在产品验证后做，是必要建设；在验证前做，可能就是负担。因为它占用了人力，占用了注意力，也让团队心理上更难转向。代码越多，越不愿推翻；系统越完整，越不愿承认核心可能不成立。

我后来把这种错误叫“用未来规模说服现在投入”。当时我们经常会说，后面肯定要运营，后面肯定要活动，后面肯定要扩展，后面肯定要数据。可真正的问题是，能不能先到达那个“后面”。如果到不了，所有提前准备都是成本。

技术可行性不等于产品必要性

在小团队会议里，技术负责人一句“这个可以做”，有时候会让一个功能顺利进入排期。

我后来对此非常警惕。因为“可以做”只是技术判断，不是产品判断。很多功能当然可以做，但不一定现在做，不一定值得做，不一定服务核心目标，也不一定对玩家有足够价值。

当时我们讨论功能时，常常会先进入实现层面。比如这个系统怎么配表，协议怎么传，客户端界面怎么展示，服务端数据怎么存，未来怎么扩展。讨论越具体，功能就越像已经被确认。很少有人在中途停下来问：它解决哪个关键问题？如果不做会怎样？有没有更便宜的验证方式？它会不会增加新手负担？它是否服务当前版本指标？

这就是技术人参与产品决策时的危险点。我们太擅长把抽象想法拆成可执行任务，而拆解本身会给想法增加合法性。

举个例子，团队担心留存不够，就会想做任务系统。技术上任务系统不难，服务端记录状态，客户端展示进度，配置表控制条件和奖励。于是它很容易被排进去。可真正的问题是，留存不够是因为没有任务，还是核心体验不够吸引？如果核心不成立，任务系统只会让玩家多点几下，不会让他真心回来。

再比如担心内容少，就加成长线、成就、排行榜。每个系统都能提高“看起来完整”的程度，但可能没有一个真正解决玩家为什么持续玩的原因。

技术负责人如果不主动追问产品必要性，就会变成功能膨胀的加速器。

我把可扩展性看得太早

做过服务端的人，很容易重视可扩展性。

这本身没错。线上游戏如果架构糟糕，后面会很痛。数据错乱、协议混乱、配置不可控、日志缺失、回滚困难，这些问题都可能造成事故。大厂训练让我对这些风险很敏感。

但创业早期，可扩展性要服务于验证阶段，而不是服务于想象中的成功阶段。

我们当时有些设计明显偏重。服务拆分、配置通用性、活动抽象、后台能力、日志维度，都比当时阶段需要的更复杂。这样做的好处是心里踏实，坏处是开发慢、改动慢、沟通慢。更关键的是，它会让产品迭代失去轻盈感。

移动游戏早期需要快速调整。玩法可能改，数值可能改，新手流程可能改，界面结构可能改，甚至题材表达也可能改。如果底层系统提前做得很重，每次改动都牵扯很多地方。看起来是为了未来灵活，实际上可能让现在不灵活。

后来我对可扩展性有了不同理解。早期真正需要的扩展性，不是支持未来所有活动，而是支持快速丢弃和重来。不是把所有抽象都设计好，而是让核心模块足够简单、边界足够清楚、数据足够可观察，方便团队根据反馈调整。

可扩展性不是越早越好。错误方向上的可扩展，只会让错误走得更远。

对质量的执念也可能变成拖延

技术人重视质量是好事。移动游戏如果频繁崩溃、卡顿、断线、发热严重，玩家会很快离开。质量差会毁掉验证，因为你不知道玩家是不喜欢玩法，还是被技术问题赶走。

但质量也有阶段边界。

我们当时有时会在没有足够用户验证前，就按正式上线标准打磨一些细节。比如框架要更干净，资源管理要更完整，后台工具要更方便，协议要更规范，日志要更全面。这些东西都重要，可它们不一定是当下最重要。

创业里有一种拖延非常隐蔽：用提高质量推迟面对市场。

只要还在打磨，就还没失败；只要还没上线，就还能相信上线后会好；只要还有 bug 要修，就可以暂时不面对“玩家是否真的想玩”。我不是说当时我们故意逃避，但人的心理确实会这样运作。工程打磨给了我们一种正当忙碌感。

后来我学到，质量应该分层。会影响核心体验和基本信任的问题必须修，比如崩溃、卡顿、存档、支付、登录、严重适配；不会影响关键验证的问题，可以延后。原型阶段不需要漂亮后台，小范围测试也不需要所有运营工具。每个阶段都要问：当前质量是否足以验证当前假设？如果足够，就应该把产品放到真实用户面前。

技术负责人也要懂停止

创业团队里，技术负责人常常天然倾向继续做。因为只要继续做，就有问题可解决，有版本可推进，有任务可分配。停止一个项目或砍掉一个方向，对技术团队来说很痛。过去写的代码、搭的框架、做的工具、优化的细节，都像被否定。

我当时不够懂停止。

当数据不好或反馈不清晰时，我更容易提出“再改一版”。改新手，调数值，加反馈，补系统，优化性能。每一版都可能有帮助，但问题是，我们是否定义了改完以后看什么指标？如果指标还是不好，是否停止？如果没有停止条件，“再改一版”就会变成无限循环。

技术人很容易相信迭代能解决问题。很多时候确实能。但创业里有些问题不是迭代不足，而是假设错误。比如目标用户选错，题材吸引力不足，核心玩法没有足够张力，获客成本无法承受。对这些问题，继续优化工程可能只是延迟结论。

技术负责人应该帮助团队建立停止条件，而不是只提供继续推进的能力。比如这个 demo 如果十个目标玩家里没有三个人主动要求再玩，就暂停；这个素材如果点击成本超过某个范围，就重做定位；这个版本如果次留没有达到最低线，就不继续加系统。条件不一定完美，但必须存在。

没有停止条件的研发，是最容易烧钱的研发。

技术身份背后的自尊

写这篇时，我不得不承认一个更个人的部分：技术身份带有自尊。

我过去很看重自己能解决复杂问题。线上出问题，能查；性能不好，能优化；系统混乱，能重构；需求来了，能实现。这种能力让我在职业上有安全感。创业后，当产品和市场问题让我无力时，我会本能地回到能证明自己的地方。

这不是一个高尚或低级的问题，只是人的心理。每个人都会回到自己熟悉的武器上。问题是，创业不会因为你在熟悉领域表现好，就放过你在陌生领域的短板。

作为技术创始人，最难的成长是承认：我会写代码，但现在最重要的可能不是写代码；我懂架构，但公司最危险的可能不是架构；我能带研发，但项目最缺的可能是用户洞察和发行能力。

承认这些，会伤自尊。但不承认，公司会付更大代价。

我也逐渐意识到，技术人的自尊有时会表现为对“不专业”的排斥。看到临时方案，会不舒服；看到人工流程，会觉得低效；看到一次性脚本，会想重构；看到不可复用的 demo，会觉得浪费。可创业早期有大量工作本来就应该是临时的、人工的、一次性的。因为它们的目的不是长期运行，而是获得答案。

比如一个运营活动，早期完全可以手工配置、手工发奖、手工统计，只要能验证玩家是否在意。一个数据看板，早期可以用简单日志和表格，只要能看出关键行为。一个玩法原型，早期可以粗糙到只有方块和数字，只要能验证选择是否有趣。技术人如果一开始就要把这些东西做成标准系统，就会把验证成本抬高。

这不是鼓励乱来，而是强调阶段感。真正专业的技术判断，不是永远追求工程漂亮，而是知道什么时候漂亮没有价值。对我来说，这个转变很难，因为它要求我放下一部分过去赖以建立自信的标准。后来我才明白，创业里的专业不是把事情都做精致，而是在正确时间把正确事情做到刚好足够。

如果今天重来，我会怎样做技术决策

如果今天重新做移动游戏创业，我会把技术决策分成三个阶段。

第一阶段是验证阶段。目标不是稳定运营，而是证明核心体验、题材吸引和用户反馈。技术方案要轻，能快速改，能埋关键数据，能支持小范围测试。除非直接影响体验，否则不做复杂后台、不做通用活动、不做过度抽象。

第二阶段是小规模测试阶段。目标是让更多真实用户进入，观察留存、流失点、设备表现和数据行为。这个阶段要补稳定性、日志、崩溃收集、基础运营配置，但仍然不追求大而全。所有建设都围绕下一轮验证。

第三阶段才是商业化和规模阶段。只有当核心指标证明值得继续，才投入更完整的服务端架构、活动系统、数据平台、客服工具和运维体系。

这种分层看起来简单，但对技术人很难。因为它要求你允许早期系统不完美，允许代码未来被丢弃，允许自己不通过工程完整性获得安全感。

此外，我会在每次技术排期前问四个问题：这个任务验证什么？如果不做，会不会影响当前关键判断？有没有更便宜的替代方式？做完之后看哪个结果决定继续或停止？如果答不出来，就不该进入当前排期。

这篇的结论

技术负责人在游戏创业里非常重要，但技术负责人也可能成为错误决策的放大器。

我当年的问题，不是技术不够努力，也不是工程做得完全错误，而是在很多时候用工程确定性替代了产品不确定性的面对。我们提前建设了不少未来可能需要的东西，却没有足够早证明现在必须成立的东西。我们把可做当成该做，把完整当成安全，把继续迭代当成一定能变好。

移动游戏创业最需要技术，但它不是一场技术考试。代码质量、服务端稳定、客户端性能都重要，可它们必须服务于玩家是否愿意玩、是否愿意回来、是否愿意付费、是否能被触达。

对技术出身的我来说，这次失败最大的反思是：不要躲在自己擅长的事情里。创业要求你把最不确定、最不舒服、最容易被拖延的问题放到前面。技术能力应该帮助团队更快验证现实，而不是帮助团队更优雅地推迟现实。