大家好，我是程式設計師魚皮。
本來上周五是要啟動公司一個新計畫內測的，但由於一些 「意外情況」 的出現，導致計畫內測出現了延期。
相比於前兩天分享的線上 Bug，這個事情的影響不大。但還是要讓團隊的小夥伴們一起復盤一下，目的是為了之後的計畫能推進地更順利。
以下是我的幾點思考和復盤，分享給大家，希望也能幫助朋友們增加一點經驗值。
計畫內測延期的思考
這次的計畫內測延期，我認為主要有幾個方面導致：
1、沒有明確的進度把控
我們大概在 2 周前開會定好了 3 月 15 日內測的目標。大家一起對目標進行了拆解，並且一起確認了內測前必須要做的幾個工作，比如要跑通自動更新的流程、支付流程、數據的埋點統計等。但是，我們卻沒有針對每項工作設定一個驗收時間，基本是直到內測的前一天，才一起驗收。這就導致我們驗收時才發現的問題，幾乎沒有時間解決。
在這個過程中，其實我有經常問團隊同學的進度情況，比如 「有沒有遇到什麽問題？有沒有什麽卡點？」 雖然大家給我的回復可能會讓我感覺到計畫進度比較順利，但是我忽略了一個致命問題：有些時候，自己一個人可能是意識不到計畫的問題的。所以及時把控各個工作節點的進度，分步驗收，是很重要的。我們新來的產品大佬也發現了這個問題，並且已經要帶開發同學整理流程文件了。下次內測上線應該會絲滑一些～
2、沒有充分地確認方案
這一點我覺得非常值得和大家分享，因為大家在工作中可能也會踩這樣的坑。
事情是這樣的，我們有一個需求是：在我們釋出桌面端程式的新版本時，要給所有正在運行程式的使用者彈窗提示，讓他們及時下載最新版本的安裝包。
這個需求聽起來並不難理解對吧，我們也一起開會明確了需求，最後產品同學驗收的時候，開發同學也完整演示了這個功能，看起來沒有任何的 Bug，以為沒問題了。
但就是這個需求，直接導致我們的計畫延期了！
為什麽呢？在最後我驗收這個功能的時候，讓開發同學給我講了下實作方案，立刻就發現了致命的問題。
他的實作方案是：雲端存放一個版本配置檔，讓桌面端程式監聽這個檔的改動。釋出新版本時管理員更改配置檔，然後桌面端就會自動下載最新版本的安裝包，並彈窗通知。
怎麽樣，這個方案大家覺得有沒有問題？
那我再補充一個條件，我們的安裝包大小是 100 MB。
揭曉答案，如果用上面這種自動下載安裝包的方案，假如我們有 10 萬個使用者，每次發新版本後會自動讓這些使用者下載一次安裝包，消耗的流量是 100000 * 100 MB = 10000 GB，大概費用在千元左右。也就是說，以後每次新增功能，或者哪怕是修復個 Bug，都要花千元。。。如果連續發幾個版本，其實使用者只需要下載最新的，之前哪些中間版本的安裝包就白白下載浪費流量了。
為了節約成本，更合適的方案應該是讓使用者手動確認更新，再下載安裝包並安裝。
這個問題的背後，值得我們思考的是：一個需求是否順利完成，不能只是考慮功能是否符合產品的驗收標準，同樣要考慮和驗收技術方案的合理性。這就是為什麽一個公司必須要同時有產品和技術負責人。
對程式設計師來說，方案設計遠比寫程式碼更重要，好的方案甚至可以不寫程式碼。如果我和團隊的同學及時驗收技術方案，再啟動開發編碼，就不會出現這個問題了。
3、內測日期不合理
想必已經有大佬發現這個問題了，一般情況下，產品發版上線不會選擇周五這個時間，因為出了 bug 就只能周末解決。通常會選擇周二、周四這樣的時間，很多遊戲好像也是這個時間停機維護哈哈。
我們當時之所以選擇這個時間，其實一方面是因為計畫還沒有使用者、只是內測；另一方面是根據任務進度設定的合理預期。根據我過去帶團隊的經驗，目標設定的太遠往往會有相反的效果，所以盡量設定一個松弛有度的時間。
不過之後除非緊急需求，否則還是把內測 / 上線時間定在周二 / 周四吧~
OK，以上是魚皮自己的一點思考。雖然之前自己做過很多計畫，但是在創業的路上我只是一個小白，也歡迎大佬們的批評指正。
👇🏻 點選下方閱讀原文，獲取魚皮往期編程幹貨。
往期推薦
