2008 年 XNUMX 月底，我受邀前往彼爾姆的一家計程車服務公司，目標是實現現有業務流程的自動化。 總的來說，我被賦予了三個基本任務：
- 為呼叫中心開發軟體包，並為計程車司機提供行動應用程式並實現內部業務流程自動化。
- 一切都必須在盡可能短的時間內完成。
- 擁有自己的軟體，而不是從第三方開發人員購買，未來隨著業務的發展，可以獨立擴展以適應不斷變化的市場條件。
當時，我不明白這個市場是如何運作的及其細微差別，但儘管如此，有兩件事對我來說是顯而易見的。 呼叫中心必須建立在開源的asterisk軟體PBX的基礎上。 呼叫中心和行動應用程式之間的資訊交換本質上是一種客戶端-伺服器解決方案，具有用於設計未來專案的架構及其編程的所有相應模式。
在對專案的任務、期限和成本進行初步評估，並與計程車服務業主就所有必要問題達成一致後，我於 2009 年 XNUMX 月開始工作。
展望未來，我馬上就會說。 結果是一個可擴展的平台在俄羅斯 60 個城市和哈薩克斯坦 12 個城市的 2 多台伺服器上運行。 公司總利潤100+萬盧布/月。
第一階段。 原型
由於當時我沒有IP電話的實際經驗，而且作為「家庭」實驗的一部分，我對asterisk也只是粗略地了解，所以我決定開始開發行動應用程式和伺服器部分。 同時，縮小其他任務的知識差距。
如果有了行動應用程序，一切都或多或少變得清晰了。 當時，只能用java編寫用於簡單的按鍵式電話，但編寫服務於行動客戶端的伺服器則稍微複雜一些：
- 將使用什麼伺服器作業系統；
- 基於為任務選擇程式語言的邏輯，而不是相反，並考慮第 1 點，哪種程式語言最適合解決問題；
- 在設計過程中，有必要考慮未來服務的預期高負載；
- 哪種資料庫能夠保證高負載下的容錯能力以及如何在請求數量增加時保持快速的資料庫回應時間；
- 決定因素是開發速度和快速擴展程式碼的能力
- 設備及其未來維護的費用（客戶的條件之一是伺服器必須位於其控制的領土內）；
- 平台下一階段工作所需的開發人員成本；
以及與設計和開發相關的許多其他問題。
在開始該專案之前，我向業務負責人提出了以下戰略決策：由於該專案相當複雜，其實施將花費大量時間，因此我首先創建一個 MVP 版本，這不會花費太多時間，並且錢，但這將使他的公司在「此時此地」的市場上獲得競爭優勢，並且還將擴大其作為計程車服務的能力。 反過來，這樣的中間解決方案將使我有時間更深思熟慮地設計最終解決方案，並有時間進行技術實驗。 同時，所實施的軟體解決方案將不能保證被正確設計，並且可能在未來被徹底重新設計或替換，但它肯定會執行「脫離競爭對手」的最低限度的必要功能。 計程車的創辦人很喜歡這個主意，所以最終他們就這麼做了。
前兩週我研究了公司的業務流程，並從內部研究了計程車的工作。 對自動化的地點、內容和方式以及是否有必要進行業務分析。 公司員工面臨哪些困難和問題？ 它們是如何解決的。 公司員工的工作日是如何安排的。 他們使用什麼工具？
到了第三週末，開始工作並研究了網上感興趣的問題後，考慮到企業主的意願，以及我自己當時的知識和能力，決定應用下面的堆棧:
- 資料庫伺服器：MsSQL（免費版，資料庫檔案限制最大2GB）；
- 在Windows下用Delphi開發一個服務於行動客戶端的伺服器，因為已經有一個Windows伺服器要安裝資料庫，而且開發環境本身有利於快速開發；
- 考慮到2009年手機上網速度較低，客戶端和伺服器之間的交換協定必須是二進位的。 這將減少傳輸資料包的大小，從而提高客戶端與伺服器工作的穩定性；
另外兩週的時間用於設計協議和資料庫。 結果是 12 個套件確保了行動客戶端和伺服器之間所有必要資料的交換以及資料庫中約 20 個表。 我做這部分工作是考慮到了未來，即使我要徹底改變技術棧，套件和資料庫的結構也應該保持不變。
準備工作完成後，就可以開始實際實施這個想法了。 為了稍微加快這個過程並為其他任務騰出時間，我製作了行動應用程式的草稿版本，勾勒出 UI（部分是 UX），並讓一位熟悉的 Java 程式設計師參與了這個專案。 他專注於伺服器端開發、設計和測試。
在 MVP 工作的第二個月結束時，伺服器和客戶端原型的第一個版本已經準備就緒。
到第三個月末，經過綜合測試和現場測試、錯誤修復、對協議和資料庫的細微改進，該應用程式已準備好投入生產。 這就是所做的事情。
從這一刻起，這個專案最有趣和最困難的部分開始了。
在司機向新軟體過渡期間，安排了XNUMX小時值班。 因為不是每個人都可以在白天工作時間來。 此外，在管理上，根據公司創始人的意志堅定的決定，其組織方式是由出租車服務經理輸入登入名稱/密碼，並且不會將其傳達給司機。 就我而言，在出現故障和不可預見的情況時需要為使用者提供技術支援。
墨菲定律告訴我們：“任何可能出錯的事情都一定會出錯。” 這正是事情出錯的原因......當我和幾位計程車司機在幾十個測試訂單上測試該應用程式時，這是一回事。 當線路上 500 多名司機根據真人的真實訂單實時工作時，情況就完全不同了。
行動應用程式的架構很簡單，而且其中的錯誤明顯少於伺服器中的錯誤。 因此，主要的工作重點是在伺服器端。 該應用程式中最關鍵的故障是當手機上的互聯網丟失並再次恢復會話時與伺服器斷開連接的問題。 網路經常消失。 首先，當年手機上網本身還不夠穩定。 其次，有很多盲點，網路根本不起作用。 我們幾乎立即發現了這個問題，並在 XNUMX 小時內修復並更新了所有先前安裝的應用程式。
伺服器主要存在訂單分配演算法錯誤以及對客戶端部分請求的錯誤處理。 在發現故障後，我糾正並更新了伺服器。
其實這個階段並沒有那麼多技術問題。 最大的困難是我在辦公室值班了將近一個月，只是偶爾回家。 大概4-5次。 我睡得斷斷續續，因為當時我一個人在做這個項目，除了我之外沒有人能解決任何問題。
一個月，這並不意味著一個月裡一切都在不斷地出現故障，而我不停地編碼一些東西。 我們剛剛決定。 畢竟，企業已經開始營運並且獲利了。 與其現在失去客戶和利潤，不如謹慎行事，稍後再休息。 我們都非常理解這一點，因此整個團隊共同投入了最大的注意力和時間，將新軟體引入計程車系統。 而且考慮到目前的訂單流量，我們肯定會在一個月內消除所有的缺點。 好吧，可能仍然存在的隱藏錯誤肯定不會對業務流程產生嚴重後果，如果有必要，可以定期糾正它們。
在這裡，有必要指出計程車服務主管和領班的寶貴幫助，他們最大限度地了解將司機轉移到新軟體的情況的複雜性，並全天候與司機合作。 事實上，在手機上完成新程式的安裝後，我們沒有失去任何驅動程式。 他們並沒有大幅增加不搬走客戶的比例，很快就恢復到正常水準。
至此，該專案第一階段工作完成。 應該指出的是，結果很快就會到來。 透過在無需人工幹預的情況下自動向司機分配訂單，客戶等待計程車的平均時間減少了一個數量級，這自然提高了客戶對服務的忠誠度。 這導致訂單數量增加。 此後，計程車司機的數量不斷增加。 因此，成功完成的訂單數量也有所增加。 結果，公司的利潤增加了。 當然，我在這裡有點超前了，因為整個過程並不是立即發生的。 說管理階層很高興其實沒什麼好說的。 我獲得了無限的機會獲得該專案的進一步融資。
待續..
來源： www.habr.com