了解為什麼我們的專案管理系統有一個持續的公開測試版。
許多 B2B SaaS 初創公司在測試版中啟動，這是有充分理由的。這是矽谷傳統格言 “快速行動，打破常規” 的一部分。
在產品上貼上“測試版”標籤可以降低期望。
有什麼壞了嗎？哦，那只是測試版。
系統很慢？哦，那只是測試版。
文檔不存在？哦，好吧……你明白我的意思。
而這 實際上 是一件好事。LinkedIn 的創始人 Reid Hoffman 曾經說過：
如果你對產品的第一個版本不感到尷尬，那麼你啟動得太晚了。
而測試版標籤對客戶來說也是有好處的。它幫助他們自我選擇。
嘗試測試版產品的客戶是處於技術採用生命週期早期階段的人，這也被稱為產品採用曲線。
技術採用生命週期通常分為五個主要階段：
- 創新者
- 早期採用者
- 早期大多數
- 晚期大多數
- 落後者
然而，最終產品必須成熟，客戶期望一個穩定、可運行的產品。他們不想進入一個“測試版”環境，讓事情崩潰。
或者他們想要這樣嗎？
這 是我們問自己的問題。
我們相信我們之所以問自己這個問題，是因為 Blue 最初的構建方式。Blue 最初是繁忙設計公司的分支，因此我們在一個積極使用 Blue 來運行所有項目的商業辦公室內工作。
這意味著多年來，我們能夠觀察到 真實 的人類——就坐在我們旁邊！——在日常生活中如何使用 Blue。
而且因為他們從早期就使用 Blue，這個團隊總是使用 Blue 測試版！
因此，讓我們所有其他客戶也使用它是自然而然的。
這就是為什麼我們沒有專門的測試團隊。
沒錯。
在 Blue 沒有人有 唯一 的責任來確保我們的平台運行良好和穩定。
這是出於幾個原因。
第一是降低成本基礎。
沒有全職測試團隊顯著降低了我們的成本，我們能夠將這些節省轉嫁給客戶，提供行業內最低的價格。
為了讓這一點更具體，我們提供企業級功能集，而我們的競爭對手收取 $30-$55/用戶/月，我們只收 $7/月。
這不是偶然發生的，而是 精心設計 的。
然而，如果產品無法正常運行，銷售便宜的產品並不是一個好策略。
所以 真正的問題是，我們如何在沒有專門測試團隊的情況下，成功創建一個數千名客戶都可以使用的穩定平台？
當然，我們的公開測試版方法對此至關重要，但在深入探討之前，我們想談談開發者的責任。
我們在 Blue 早期就決定不會將前端和後端技術的責任分開。我們只會聘請或培訓全棧開發者。
我們做出這一決定的原因是為了確保開發者能夠完全擁有他們正在工作的功能。因此不會出現 “把問題扔過花園圍欄” 的心態，這種心態有時會出現在功能的共同責任中。
這也延伸到功能的測試、理解客戶的使用案例和請求，以及閱讀和評論規範。
換句話說，每位開發者都對他們正在構建的功能建立了深刻而直觀的理解。
好了，現在讓我們談談我們的公開測試版。
當我們說它是“公開”的時候——我們是認真的。任何客戶只需在我們的網絡應用程序 URL 前加上“beta”即可嘗試。
因此，“app.blue.cc” 變成了 “beta.app.blue.cc”。
當他們這樣做時，他們能夠看到他們的常用數據，因為測試版和生產環境共享同一數據庫，但他們還能看到新功能。
即使有一些團隊成員在生產環境中，而一些好奇的成員在測試版中，客戶也能輕鬆工作。
我們通常有幾百名客戶在任何時候使用測試版，我們會在社區論壇上發布功能預覽，以便他們查看新功能並進行嘗試。
而這就是重點：我們有 幾百名 測試者！
所有這些客戶將在他們的工作流程中嘗試新功能，如果有什麼不對勁，他們會非常直言不諱，因為他們 已經 在他們的業務中實施了這個功能！
最常見的反饋是一些小但非常有用的變更，解決了我們未考慮到的邊緣案例。
我們會在測試版上保留新功能 2-4 週。每當我們覺得它們穩定時，我們就會發布到生產環境。
如果需要，我們還可以使用快速通道標誌來繞過測試版。這通常是針對我們不想在發佈到生產環境之前等待 2-4 週的錯誤修復。
結果是？
推送到生產環境的感覺……嗯，無聊！就像什麼都沒有——對我們來說根本不算什麼大事。
這意味著這平滑了我們的發佈時間表，這使我們能夠 在過去六年中每月如時鐘般準時發佈功能。
然而，像任何選擇一樣，這也有一些權衡。
客戶支持稍微複雜一些，因為我們必須支持客戶使用我們平台的兩個版本。有時這會導致使用兩個不同版本的團隊成員的客戶感到困惑。
另一個痛點是，這種方法有時會減慢整體的生產環境發佈時間表。這對於較大的功能尤其如此，如果有其他相關功能出現問題並需要進一步工作，這些功能可能會在測試版中“卡住”。
但總的來說，我們認為這些權衡是值得的，因為它帶來了更低的成本基礎和更高的客戶參與度。
我們是少數幾家採用這種方法的軟件公司之一，但這現在已經成為我們產品開發方法的基本部分。