公司名：360
项目名：BigFoot
时间：2019年
因《游戏超人》商业化的问题没有解决，负责人就离开了礼包。同时产品也彻底放弃社区化转型，开始全心全意的在商业化上进行更多探索。而且猎豹还是一个工具起家的公司，当市场环境好的时候，公司可能还愿意探索一些其他方向。一旦公司银根紧缩，毫无疑问就会回到自己最擅长的路径上，持续做工具。
这个时候我就很尴尬了，我一个做社区的，社区项目被放弃了以后也不打算做，那我应该干什么呢。当时我就被安排到一个其他部门先干着，整个人进入一个迷茫阶段。
在这个痛苦时候，《游戏超人》的项目负责人传来消息，他在那边重新组建了一个项目，也是打算走工具加社区的路线。问我是否有意愿从珠海去北京，继续跟着他干。那还用问吗，肯定去啊。
于是，在2019年，我从珠海到了北京，开始了新征程。
项目背景：
项目负责人入职的部门是360的海外事业部，所以项目必然是要走出海的。又因为当时游戏超人其实增长的还不错，项目负责人就想再复制一下这些功能到海外试一试。可试了几个小功能项目后，还不太够。
这时，项目负责人提出一个很有意思的理念：流量后置。以往的游戏辅助类工具，都是要先打开APP，再点击启动游戏，继而发挥一些功能效果。这个路径相当于把APP变成一个启动器，流量要经过APP再到游戏中。
而“流量后置”呢，就是程序持续在后台保活。用户只要启动APP支持的游戏，通过屏幕的画面识别，自动出现在游戏中。这样用户就不需要主动打开APP，就可以直接使用功能了。
可这样用户完全不需要打开产品就可以使用功能，那产品后续要怎么发展呢？这个时候就需要内容和社区，通过画面识别，把攻略和一些资料投放到对应的页面，用户可以在游戏内查看。逐步形成对产品的认知，继而发展成，当用户不在游戏内的时候，也可以到APP内去进行内容消费。
举个例子：比如当时海外很火的《皇室战争》，在卡组编辑页面就会有一个半透明的悬浮球。当你打开悬浮球之后，里面就有推荐的卡组列表。点开任意一个卡组，里面就有卡组的使用教程，相当于一个内置的攻略库。而点击“一键复制”后，软件将自动按照卡组列表的卡，将这个卡组自动放到当前编辑器中，节省操作。
如果你当下不在游戏内，又想看看新卡的介绍或者新卡组，作为之前在游戏内就已经养成的心智，就可以打开APP去看。这样就完成了用户从工具型用户到内容型用户、从游戏内到游戏外的转型。
再下一步就是用户自行产出攻略，一部分免费，核心部分收费。想看内容需要购买会员或者直接付费购买单条攻略。还可以付费提问，因为软件有画面识别，可以快速锁定能解决这个问题的用户，在游戏内外进行推荐。
比如我在一个卡组编辑器页面选定了一个卡组，但是还是有些地方不懂，我可以悬赏一个问题发出去。APP会判断谁有这个卡组，同时等级分比较高的，自动推送给他，邀请他回答。这样可以到高效的定点邀约回复。
再再下一步，就变成一个全球范围的游戏社区。
过程：
第一步还是老样子产品通过设计游戏工具在欧美市场低成本获量，主要针对的就是《皇室战争》这款游戏。
而我主要是负责扫荡整个谷歌游戏排行榜中的游戏，给每个游戏提供攻略。过程是我带着团队里的人每个游戏玩一遍，快速了解游戏内容，然后梳理一套攻略大纲，再由国内的外包玩家团创作内容，创作完内容后由团队里的人审核，审核通过后交由翻译翻译成英文或日文、韩文等，再发到APP内给玩家看。
这个过程中就要求我们对每个游戏有一定的了解，否则无法判断玩家供稿的内容是否是满足我们价值的。好在手游嘛，没有什么太高游戏门槛的，基本上玩个一两天就差不多了。特别是当时海外大多数游戏都是换皮游戏，比如各种换皮的SLG，无论是什么IP，玩法都一模一样。
其次是翻译质量，好在我们找到一个会中日韩英四国语言的同学，她还喜欢玩游戏，由她来把控翻译质量。
之所以使用这种方式，是因为从价格角度来说，国人产出的内容再翻译成英文，也要比在英文区找人创作成本要低。更何况对于团队里的人来说，中文内容更好做质量控制，毕竟不是每个人的英文水平都能到母语级的。
那么在这个过程中，bigfoot的攻略逐步覆盖了《皇室战争》、《部落冲突》、《宝可梦：GO》、《游戏王》、《CODM》等近一百款手游。
这个过程中最麻烦的就是游戏改版，数值发生改变就要对原有数值进行修正，功能发生改变，就要对功能进行修正。这个都还好，最麻烦的是页面变了，就要重新做画面识别。这个是最麻烦的。而随着支持的游戏越来越多，几乎每个月都要对几款游戏进行内容和画面识别的修正，这也是在逐步增加成本。
说完外部业务，再说一说CMS。我在360做的CMS，应该是我设计的第四个CMS了。为了解决不同游戏的不同展现方式，我设计了一个灵活度极高的CMS。将每个部分都组件化，比如纯文本组件、富文本组件、图片组件、超链接组件等等。运营可以根据游戏特性搭建不同的内容模板，一旦需要修改，也只需要对组件进行修改，不需要动其他东西。
比如当时设计了一个“统一声明”组件，这个组件的功能就是在使用这个组件的模板里增加一条纯文本，用于声明版权信息的。如果按照传统CMS的做法，每条内容都要加一个这样的声明，显然是很繁琐的一件事。所以一般是通过服务端或客户端，通过技术的方式来解决。一旦要修改，客户端就需要发版，服务端也需要评估工作量。
而在我的CMS里，只需要在模板里面增加“统一声明”组件，填写声明信息就行了，客户端会自动加载。不需要技术介入。而且组件的剩下位置也是可以换的，每个模板里的组件有权重数字，可以灵活更换顺序。
这也就是为什么当时我们一个组才五个人，就能同时创建和维护八九十款游戏的各种个性化模板的原因。主打的就是一个全能和灵活。
之所以这么设计，是当时我看了一本叫《失控》的书。其实这本书写的很繁杂，简单的东西要不停的提供案例，生怕你听不懂的样子，所以我建议看这本书就当流水账看，一目十行就好了。而这本书中我印象最深刻的就是讲机器人的那部分（还有一部分是讲生态的，不过那个部分与本文无关）。
机器人是一个复杂系统，如果全部耦合，就一个坏，整个一起坏。维修起来成本高、想要拓展成本更高，牵一发而动全身。如果把每个部位都做成简单系统，比如抓一个苹果。一个模块负责识别物体是不是圆的，一个模块负责把爪子蜷缩和松开，一个模块负责抬起和放下。这样一个模块坏了，只需要修复单个模块就好了。而这么简单的一个机器人，只需要不断的增加上面那些模块，比如增加一个刀片模块，再复用一个抬起和放下模块，就可以做出一个可以识别苹果并自动将切成四瓣的机器人了。
后面再加入的公司大多都有自己一套很老的CMS。而且往往是极其难用，可只要是内部使用的工具，推动迭代是难比登天的，毕竟内部需求永远没有外部业务需求重要，这也没辙。这也是告诫各位读者，如果你在做类似产品的时候，一定从最底层考虑延展性和可维护性。
有的选的情况下一定不要选“临时方案”和“先凑活着用方案”，往往这一凑活能凑活十几二十年的，很可怕。
话扯远了，扯回来。项目说到这里，要说一下公司内部的事情了。当时的360海外事业部其实已经处于一个独立的状态了，有自己的独立主体，工牌都不是360集团的，只是实际控制人还是老周。到2019年的国庆，360集团打算把这些已经独立的项目全部挪出公司，我们部门也从酒仙桥360公司搬了出去。又过了没多久就收到通知，老周把投资撤回了，之前说好的投入不投了，给我们半年时间自己出去找投资人，找不到就倒闭。
就我的角度来看，老周这事做的虽然不是那么体面，但还能接受。起码他给了半年时间作为缓冲，有些公司是这个月说撤，下个月就不给钱了，开开心心上班，结果就被通知明天就不用来了。那是真的难受。
公司没钱了，第一步就是裁员，我的运营组从五个人变成了三个。
我记得裁员的那天，我哭的稀里哗啦的。其实那不是我第一次裁员，只是以往裁员往往都是在公司里待了有几年的员工，换个公司也没什么难度。而那两个刚入职没几个月的员工，他们没做错什么，简历却出现了这么一段几个月的工作经历，让他们的简历花了一些，是公司对不起他们。
再接下来，事业部老板开始不停的在外面弄融资，而产品也不能继续免费下去，需要搞一些商业化了。不得不说海外用户的付费意愿和付费能力是真的好，游戏攻略这种东西放到国内想要钱？你还不如去幻想自己买彩票中五百万呢。可在海外，用户是真的愿意为这些内容付费。
我记得当时我们的年付价格是39美元（记不太清了，大概是这个价格上下）。这个价格放到国内已经算是贵出天际了，海外用户的付费率却还可以。可以说在当时我们努力做出的一点商业化尝试是有效果的。
可产品的投资却迟迟没有动静，最后在2020年5月，公司宣布进入关门流程。要说体面吧，起码把我们当个月的社保给缴了，也没有欠薪，要说不体面吧，也没什么赔偿金。做互联网的还是体面人居多，也没有人冲过去把公司电脑抱走几台来抵赔偿金的。
毕竟我们还算360体系内的，产品和技术都有一部分回到了360，毕竟都用得上嘛。而我一个做社区的，又碰到了跟猎豹一样的难题。360……它也不做社区啊。接下来的事情，就到下一篇再说吧。
反思：
这次是反思要从两方面来考虑：
一、公司层面：因为我在做83830的时候就碰到过一回投资导致公司倒闭的问题，所以这次我入职前特地问了一下公司账上有没有钱。毕竟就算是在360体系内，账也是分开算的。当时项目负责人告诉我，这次放心，钱稳稳的。可实际上公司还是倒在撤资身上了。
雷军有说过，公司账上一定要躺着能保证员工18个月薪水的资金，天塌了也不能动。很多人对他这番话有意见，觉得这种做法很小家子气。但作为有过两次类似经验的人，我认为他这么做是对的。毕竟碰到老周这样能给六个月过渡期的投资人，还勉强有一点机会。如果碰到那种连过渡期都没有的投资人，那真是马上猝死，连抢救机会都没有。
当时事业部的负责人最大的缺陷就是对自己独立运营一个公司缺少经验，比如盲目扩招人手增加成本、没有及早去资本市场认识一些投资机构、在产品还没有做好准备的情况扩张市场团队，还包括没有更快的把主路径给做出来。
什么叫“没有更快的把主路径给做出来”呢？这就是到业务侧了。
二、业务层面：我在背景那个部分讲述了整个产品的发展规划蓝图，不可谓不宏大。可当产品上线半年后，内容的产出还是依靠运营产出。本来运营产出只是用作一个测试，判断用户对于内容是否有需求。可这一下子就做成了常规工作，并没有持续往下推进，真正变成一个UGC产品。
当BOSS把产品拿到市面上跟投资人画饼的时候，发现手里的产品最多是一个带着攻略库的工具，并没有形成一个社区。投资人就摇摇头，表示这个饼啃不动。
据项目负责人事后跟我说，其实他早就跟BOSS提过是不是要增加社区模块，但BOSS拒绝了。其实我是大致理解他的想法的，因为这样的事情我也经历过很多次了。往往这种需要转型的项目，当第一条主路径发展还可以的时候，面对有限的开发资源，BOSS往往会要求搁置不确定性更强的第二曲线，优先做确定性更强的第一曲线。
所以就不停的做工具，工具效果好，那就加资源继续做工具，不断的循环。至于社区……以后有空再说吧。
而当360撤资后，BOSS出去见了几个投资人，意识到事情不对之后，我们就在2020年的上半年，开始加班加点的做社区。可最终还是没来得及在倒闭之前把社区版推出来。
工具效果过于好导致产品路线扭曲，使得真正的主路径：社区迟迟得不到资源进行开发，最后工具又扛不住整个产品的重任。这样的故事不少见，起码我经历的不止一次。
这也导致我后面再做类似的项目时候，往往都会提醒项目负责人，不要沉迷于功能带来的增长不可自拔。如果这个功能不能直接收费，或者带来极强的停留时长和打开频次，那就认清楚那只是一个抓手功能的本质，赶紧把社区部分给做出来。
俗话说家家有本难念的经，我避开了一个坑又往往会迎来另一个坑。
通过走弯路来避开弯路，通过犯错误来避免，这就是我的成长史。
所以我接下来又遇到什么坑了呢？欲知后事如何，请听下回分解！
收藏
转播
淘帖
楼主