相信能看到我的文章但朋友都或多或少做过网络项目，但大多数的项目存活时间都不会太久。一旦一个项目做不下去了，之前付出的努力可能都白费了。当然有朋友会说，反正我赚到钱了，大不了换个项目。不过随着互联网环境越来越完善，那种快进快出的项目会越来越少，甚至连最基础的薅羊毛项目都可能需要你有综合能力，技术和人员方面往往不可少。
如果我们花费很大精力去培训员工，去寻找技术开发某个软件，好不容易搭建好某个项目的框架，没多久这个项目就死了。而新的项目跟不上，或者新的项目需要全新的框架来支撑。那么前面开发的软件，培训的人员可能都无用武之地。
就像我之前做新闻阅读，让技术用auto.js花费一年多时间开发和优化脚本app。到了2019年新闻阅读行业几乎全军覆没，我们开发的app直接报废。抛开一年下来开发所需的技术薪资不说，如果没有后续项目跟上去，跟了我多年的技术也肯定都要另谋出路。而且就算有新的项目能跟上，也需要重新花时间从零开发项目需要的工具，消耗的时间成本和资金也是很多工作室无法承受的。
我们从新闻阅读到手游试玩过渡时间花费了至少3个月，这三个月是纯开支，零收益。除了技术开发的开支，还需要发放之前负责新闻阅读项目的工作人员的薪资福利。
也就是相当于我新闻阅读项目积累的成果在该项目死亡后直接归零，这种情况很多工作室都遇到过。只是我们不像许多团队在一个项目结束后如果短期没新项目，就会解散团队，等新项目出来后重新招。因为我们想尽可能做到对每个员工负责，只要他们能力是可以的，他们不主动辞职，他们的工作就是稳定的。
正是由于新闻阅读项目的教训，让我下定决心在做新项目之前设计一个适用于大多数互联网项目的框架。经过技术2019，2020两年的开发和优化，我们的框架才得以完善，手游试玩只是我们框架上的一个项目。
有了这个框架，我就不怕手游试玩项目的死亡，因为我们已经基于这个框架在测试其他项目了。哪怕手游项目不行了，我们也可以在最短时间内运行新项目，让成员的损失最小，实现项目快速衔接。
下篇文章说说当时设计框架时是怎么考虑的。
