1998年的谷歌和今天的谷歌相差甚遠，他們也是利用了一定技巧和捷徑才走到今天的位置。
谷歌也曾從小魚慢慢發展爲龐然大物。如果沒有強大的開發軍團，就做不了在全球部署的產品。公司規模的不同，決定了技術決策的不同。
我的大部分職業生涯是在小公司度過的。我之前是初創公司Housekeep的CTO，這家公司給了我6年寶貴的經驗，我將在這篇文章裏逐一分享。這些策略雖然有些反直覺，但它們最終讓Housekeep走到了現在的位置，已經提供了超過260萬個小時的清潔服務。
如果你想要成爲下一個谷歌，請記住以下8個策略。
使用不那麼酷的技術
當開發人員碰到彼此，他們總愛聊一個話題：你們用的是什麼技術棧？技術棧就是他們爲交付產品而使用的所有技術的集合，是技術層面的地基、牆壁、窗戶和屋頂。
谷歌的技術棧令人驚歎不已，從物理建築一直到在瀏覽器中運行的代碼，涉及到的每一個元素它們都包含了。谷歌擁有一切，而且一切都很酷。
作爲一家初創公司，你應該找到一種更好的方法來解決與人有關的問題。這需要很酷的方法，很酷的思維，很酷的流程。
但99%的初創公司不會只是提供技術，他們會藉助技術來提供解決方案。這意味着你應該將所有精力集中在較高的層次上。同時，所有的基礎層都應該使用不那麼酷但可能很安全的技術。
不那麼酷的技術有已知的缺陷和權衡，但它們已經存在了足夠長的時間，擁有龐大的用戶羣，這些用戶已經發現了大多數嚴重漏洞。你可以很容易找到具備多年經驗的開發人員。相比之下，很酷的新技術存在更多未知的缺陷，它們可能在不經意的時候蹦出來嚇你一跳。
如何招聘
問題是，開發人員更容易爲新技術感到興奮。他們還知道，新框架或數據庫可能意味着更高的薪水。這就導致了衝突的出現：開發人員傾向於採用令人興奮的新技術，這樣他們就可以藉機體驗，並利用這些體驗在其他地方找到薪水更高的工作。
你必須意識到這一點，並確保他們的技術棧選型不會在日後給你帶來麻煩。谷歌可以招聘純技術驅動的開發人員，因爲它有最酷的技術棧。但你沒有，所以你不能像谷歌一樣。你需要的是真正能夠解決問題和交付好產品的開發人員。
拉近開發人員和用戶的距離
要看開發人員是否對解決問題感興趣，可以看看他們是否願意花時間與用戶呆在一起。
谷歌像結繭一樣把開發人員放在一個安靜而寬敞的繭房裏，讓他們只專注於開發系統，而你應該讓你的開發人員深入瞭解用戶。
在Housekeep成立早期，我們還沒有爲顧客和清潔工提供完整的App——我們通過電話和電子郵件與他們溝通。我們系統的唯一直接用戶就是我們的客服主管。在那個時候，我們安排開發人員與客服人員坐在一起。20%是出於策略方面的考慮，80%是因爲我們租用辦公室是按照桌子數量來付費的。
事實證明，這是一個很好的做法。開發人員能夠知道客服主管遇到了什麼問題，並且在問題解決之後可以立即得到他們的反饋。如果修改的代碼導致速度變慢或出現bug，開發人員可以快速採取行動。
隨着團隊的成長，我們將其作爲辦公室文化的指導原則。開發人員應該能夠在用戶提交錯誤報告之前發現問題並修復它們。但這個策略不會一直有效——我們後來制定了更多具有戰略意義的流程。但早期的這些經歷對後期文化的形成提供了參考：開發人員在解決實際用戶問題時可以立即得到積極的反饋。
谷歌有大量的員工緻力於收集用戶反饋，並將其轉化爲開發人員的行動。你也可以通過恰當的招聘和座位安排來達到同樣的效果。
你可以決定什麼時候開始遵循最佳實踐
谷歌的系統必須全天候在線，他們的系統設計水平達到了極致。當你還沒有達到谷歌的規模時，不用完全遵循這個規則。
當然，開發人員也不能打破所有的規則。畢竟，你將公司願景的控制權交給了寫代碼的人，並且相信他們能夠開發出高規格的系統。
我們以自動化測試爲例。自動化測試意味着開發人員除了寫代碼實現功能，還需要寫代碼來檢查功能是否正常。我在面試技術人員時總是會問到測試方法，如果對方告訴我他們不相信測試，那面試就結束了。
但從另一方面看，做正確的事情是很耗時的。如果你所在的是一家年輕的公司，你的產品在不斷變化，舊功能不斷被新功能取代，你會發現代碼庫裏的大部分代碼過不了多久就會被丟棄。
最好的策略是使用混合策略。有時候你確實要非常嚴格，比如我們的賬單和支付系統一直都要經過全面測試。但在早期，純粹用於向用戶展示內容的代碼都沒有經過自動化測試。用戶會向我們反饋問題，然後我們再解決。此外，我們知道用戶體驗會快速發生變化，測試只會礙手礙腳。
處於這兩個極端之間的一切都由團隊成員來做出判斷。理想的初創公司工程師應該知道遵循最佳實踐的重要性，但也知道何時何地可以打破規則。
向未來借時間
留着系統的一部分不做測試，是一種典型的技術債務：爲了速度而抄捷徑，並且知道需要在未來的某個時間點回過頭來解決遺留問題。
你和開發人員之間應該會存在一種“健康”的緊張關係。他們會說“我們想要仔細開發這個功能，這樣它就能用上10年”，而你會說“快做好，這樣我們就能知道是否有人真的想要這個功能”。每次你贏了，就欠下了技術債。隨着抄捷徑次數增多，技術債就會堆積起來。
相關的討論需要公開進行。公司應該使用問題跟蹤軟件來記錄想要開發的功能和因爲抄捷徑而遺留下來的問題。當你在未來回過頭來想解決遺留問題時，這些記錄就變得至關重要。
出點故障也沒事
如果Gmail宕機十分鐘，好像整個世界都會陷入恐慌。相比之下，初創公司用戶基數小，產品也相對簡單，所以可以承擔一定程度的風險。快速迭代可能會破壞一些東西，但結果尚可承受。
但如果你一直靠近風頭，冒着偶爾翻船的風險，就必須有一個可以快速糾正航向的系統。
CI/CD工具能夠獲取代碼、構建產品、執行測試，並將產品部署到服務器上。這樣只需要一個步驟就可以快速輕鬆地發佈新版本。如果你選對了工具，還可以進行“回滾”。在部署新版本時，先看看它是否有bug，如果有，就恢復到以前的狀態。你可以自由地做出修改，更好地應對負面後果。
如果你面臨的是更嚴重的宕機風險，該怎麼辦？這取決於你的產品，你可能還是要冒險一試。如果公司規模足夠小，在出現故障時，你可以親自聯繫關鍵用戶。如果你能夠恰到好處地解釋故障緣由，你甚至會發現早期用戶爲能夠成爲新產品的用戶而感到慶幸。
你可以惹惱用戶
規模小意味着你需要篤定地考慮一些事情的優先級。很快，你會發現自己會優先考慮某些用戶的幸福感。
在Housekeep，我們很早就意識到，提升清潔工的幸福感是我們最重要的目標。一個沮喪的清潔工離開我們的平臺，可能會讓20個或更多的客戶感到挫敗。
同時，我們必須爲客戶提供“足夠好”的在線體驗。只要得到好的服務，一般客戶就可以忍受不完善的用戶界面。
我們的內部用戶充當了炮灰，我們爲他們開發的工具很粗糙，系統體驗也不好。不過我們“逃過一劫”，部分原因是因爲我們坐在他們旁邊，他們可以看到我們正在努力解決問題。
我們的客服和運營團隊具有極高的容忍度。他們知道我們在幫他們解決問題，他們遇到的系統問題正是我們要解決的問題。
你可以把產品控制權交給用戶
當我們讓內部用戶使用笨拙的系統時，我們向他們傳達了這樣的想法：事情不會總是這樣的。
當有新員工加入客服團隊時，我們讓他們務必在第一週拿出一個產品改進方案。開發人員會嘗試在他們的第一週結束之前實現改進方案。
這原本只是出於好心，讓客服團隊感覺到他們的意見被重視。但隨着時間的推移，我們被這些用戶的參與度和他們提出的產品創意所折服。
我們從一開始就告訴他們，他們目前使用的系統是可以改進的，這改變了他們的思考方式。他們知道，他們使用的系統不是固定不變的，而是可以變成任何他們想要的樣子。
先囤積數據，再挖掘價值
在成立Housekeep之初，我收到了一個很好的建議，雖然聽起來很奇怪：“數據的成熟過程就像葡萄酒，代碼的成熟過程就像魚”。
最終我明白了這句話的含義。隨着產品的演化，應用程序代碼需要被重構和重寫，但是我們在2013年收集的數據在10年後仍然有用。
在早期，我們記錄了客戶、清潔工或工作人員在系統中操作的日期、時間和內容——開始或完成一項工作、預訂新工作、更改日程安排。我大約花了兩天時間開發日誌系統，從那時起，它就默默地在後臺把所有的數據都記錄下來。
一開始我們沒有去查看或分析這些數據，只是把數據默默地添加到數據庫中。過了一段時間之後，我們有了一個匿名用戶行爲數據的寶庫——數據“成熟”了。時間越長，數據集增長得就越多，我們能夠從中提取的價值也就越多。
小結
如果你的團隊規模還很小，產品也還在演化中，那麼這些建議值得參考。但要注意，隨着公司規模增長，盲從這些建議的風險就會變大。
當團隊規模比較大的時候（比如每個團隊都有50個人），你就不能讓開發人員和客服人員坐在一起了。開發人員會因爲噪音而感到沮喪，而且並不是每個客服人員提出的產品想法都是積極有用的。
當10分鐘的宕機時間意味着損失1萬美元收入時，你就不能繼續對產品保持漫不經心的態度。
當每天都有1000個新客戶加入時，你也不能再隨意惹惱他們。
上述這些建議只是生存策略，爲你爭取時間，讓你的公司變得足夠強大，能夠“正確地”做事情。你不是谷歌，不過你要知道，1998年的谷歌和今天的谷歌相差甚遠，他們也是利用了一定技巧和捷徑才走到了今天的位置。
原文鏈接：
https://medium.com/dev-genius/the-advantages-of-not-being-google-5b1c4454d0da