唉，新项目内测延期了。。我的一点思考

大家好，我是程序员鱼皮。

本来上周五是要启动公司一个新项目内测的，但由于一些 “意外情况” 的出现，导致项目内测出现了延期。

相比于前两天分享的线上 Bug，这个事情的影响不大。但还是要让团队的小伙伴们一起复盘一下，目的是为了之后的项目能推进地更顺利。

以下是我的几点思考和复盘，分享给大家，希望也能帮助朋友们增加一点经验值。

项目内测延期的思考

这次的项目内测延期，我认为主要有几个方面导致：

1、没有明确的进度把控

我们大概在 2 周前开会定好了 3 月 15 日内测的目标。大家一起对目标进行了拆解，并且一起确认了内测前必须要做的几个工作，比如要跑通自动更新的流程、支付流程、数据的埋点统计等。但是，我们却没有针对每项工作设定一个验收时间，基本是直到内测的前一天，才一起验收。这就导致我们验收时才发现的问题，几乎没有时间解决。

在这个过程中，其实我有经常问团队同学的进度情况，比如 “有没有遇到什么问题？有没有什么卡点？” 虽然大家给我的回复可能会让我感觉到项目进度比较顺利，但是我忽略了一个致命问题：有些时候，自己一个人可能是意识不到项目的问题的。所以及时把控各个工作节点的进度，分步验收，是很重要的。我们新来的产品大佬也发现了这个问题，并且已经要带开发同学整理流程文档了。下次内测上线应该会丝滑一些～

2、没有充分地确认方案

这一点我觉得非常值得和大家分享，因为大家在工作中可能也会踩这样的坑。

事情是这样的，我们有一个需求是：在我们发布桌面端程序的新版本时，要给所有正在运行程序的用户弹窗提示，让他们及时下载最新版本的安装包。

这个需求听起来并不难理解对吧，我们也一起开会明确了需求，最后产品同学验收的时候，开发同学也完整演示了这个功能，看起来没有任何的 Bug，以为没问题了。

但就是这个需求，直接导致我们的项目延期了！

为什么呢？在最后我验收这个功能的时候，让开发同学给我讲了下实现方案，立刻就发现了致命的问题。

他的实现方案是：云端存放一个版本配置文件，让桌面端程序监听这个文件的改动。发布新版本时管理员更改配置文件，然后桌面端就会自动下载最新版本的安装包，并弹窗通知。

怎么样，这个方案大家觉得有没有问题？

那我再补充一个条件，我们的安装包大小是 100 MB。

揭晓答案，如果用上面这种自动下载安装包的方案，假如我们有 10 万个用户，每次发新版本后会自动让这些用户下载一次安装包，消耗的流量是 100000 * 100 MB = 10000 GB，大概费用在千元左右。也就是说，以后每次新增功能，或者哪怕是修复个 Bug，都要花千元。。。如果连续发几个版本，其实用户只需要下载最新的，之前哪些中间版本的安装包就白白下载浪费流量了。

为了节约成本，更合适的方案应该是让用户手动确认更新，再下载安装包并安装。

这个问题的背后，值得我们思考的是：一个需求是否顺利完成，不能只是考虑功能是否符合产品的验收标准，同样要考虑和验收技术方案的合理性。这就是为什么一个公司必须要同时有产品和技术负责人。

对程序员来说，方案设计远比写代码更重要，好的方案甚至可以不写代码。如果我和团队的同学及时验收技术方案，再启动开发编码，就不会出现这个问题了。

3、内测日期不合理

想必已经有大佬发现这个问题了，一般情况下，产品发版上线不会选择周五这个时间，因为出了 bug 就只能周末解决。通常会选择周二、周四这样的时间，很多游戏好像也是这个时间停机维护哈哈。

我们当时之所以选择这个时间，其实一方面是因为项目还没有用户、只是内测；另一方面是根据任务进度设置的合理预期。根据我过去带团队的经验，目标设置的太远往往会有相反的效果，所以尽量设置一个松弛有度的时间。

不过之后除非紧急需求，否则还是把内测 / 上线时间定在周二 / 周四吧~

OK，以上是鱼皮自己的一点思考。虽然之前自己做过很多项目，但是在创业的路上我只是一个小白，也欢迎大佬们的批评指正。

👇🏻 点击下方阅读原文，获取鱼皮往期编程干货。