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次。 我睡得断断续续，因为当时我一个人在做这个项目，除了我之外没有人能解决任何问题。
一个月，这并不意味着一个月里一切都在不断地出现故障，而我不停地编码一些东西。 我们刚刚决定。 毕竟，企业已经开始运营并盈利了。 与其现在失去客户和利润，不如谨慎行事，稍后休息。 我们都非常理解这一点，因此整个团队共同投入了最大的注意力和时间，将新软件引入出租车系统。 而且考虑到目前的订单流量，我们肯定会在一个月内消除所有的缺点。 好吧，可能仍然存在的隐藏错误肯定不会对业务流程产生严重后果，并且如果有必要，可以定期纠正它们。
在这里，有必要指出出租车服务主管和领班的宝贵帮助，他们最大限度地了解将司机转移到新软件的情况的复杂性，全天候与司机合作。 事实上，在手机上完成新程序的安装后，我们没有丢失任何驱动程序。 他们并没有大幅增加不搬走客户的比例，很快就恢复到正常水平。
至此，该项目第一阶段工作完成。 应该指出的是，结果很快就会到来。 通过在无需人工干预的情况下自动向司机分配订单，客户等待出租车的平均时间减少了一个数量级，这自然提高了客户对服务的忠诚度。 这导致订单数量增加。 此后，出租车司机的数量不断增加。 因此，成功完成的订单数量也有所增加。 结果，公司的利润增加了。 当然，我在这里有点超前了，因为整个过程并不是立即发生的。 说管理层很高兴其实没什么可说的。 我获得了无限的机会获得该项目的进一步融资。
继续..
来源： habr.com