Сarbox

Бизнес-задача и ее решение

Организовать максимально удобный процесс подбора и покупки комплектов для проведения технического обслуживания.
Решения:
Автоматизация процесса подбора необходимых деталей для технического обслуживания выбранной модификации с заданным пробегом и обеспечение управлением процесса покупки. Если вам говорят, что "всё уже готово - нужно лишь немного подправить", это повод серьезно насторожиться. В большинстве случаев "правки" как раз становятся основной и большой работой на проекте. Аналогично вышло и с данными для проекта Carbox. Заказчик предоставил большую базу данных автомобилей и деталей, которые надо было "лишь влить в требующуюся структуру данных", однако... Базу данных перелили и стали писать приложение, но алгоритмы стали обрастать многочисленными заглушками - из-за недостатка данных. То там, то сям обязательные данные просто отсутствовали. Разумеется, первое, что в случаях, когда заявлено, что исходник данных совершенно адекватный, происходит - это разбор полетов загрузки данных. Очевидно же, что замечательные исходные данные испортились при загрузке. Нам пришлось заново осуществить полную загрузку данных - но на этот раз проводился контроль каждого этапа загрузки с разбирательством всех недостатков - до источника. Как выяснилось - увы, но недостаток данных кроется не в некачественной загрузке, а в собственно отсутствии необходимых данных в источнике. Ситуация осложнялась тем, что в итоге пришлось компоновать базу проекта из трех разных БД - но и это не обошлось без дополнительных и больших ручных правок. В итоге, на проекте мы столкнулись с ситуацией "Каша из топора" - это когда вы в итоге всё таки варите приличную кашу, но топор в конечном результате нужен был постольку-поскольку. Ситуацию спасло то, что заказчик был заинтересован в результате и его эксперты в конечном счете совместно с нашей командой проделали таки огромную работу по исправлению и дополнению базы данных, так что нам действительно удалось довести продукт до релиза, хоть для этого и пришлось проделать 5 итераций.

Второй сложностью проекта являлась его "стартапность" - отсутсвие уже существующих бизнес-процессов, на которые можно было бы опереться. Отсутствие операционного опыта у компании в каком-либо бизнесе всегда приводит к многочисленным правкам алгоритмов работы приложения "по ходу действия". От этого не спасают и схемы процессов, которые пишутся перед стартом проекта - в них всегда обнаруживается масса неточностей и неправильностей, ведь бизнес в случае стартапа вырастает практически из голой идеи, которая на практике еще просто не была реализована. К счастью и здесь нам удалось договориться об итерационном подходе с заказчиком, при котором мы не застреваем в бесконечных переделках ПО без релизов, а меняем процессы и функционал итеративно, от релиза к релизу, даже если заранее видим в очередном предстоящем релизе намечающиеся "переделки". Тем не менее, первый релиз всё же пришлось несколько раз откладывать - чтобы включить в него критически важные дополнения и исправления.

Всё вместе, конечно, повлияло на сроки разработки - если бы источник данных был пусть не идеальным, но хотя бы близким к тому, если бы процессы были уже хотя бы частично обкатанными в работе - проект, пожалуй, мог бы стартануть в два раза быстрее. Но, опять же, всё завершилось релизом - успешным релизом! Позади - огромная и интересная работа, впереди - еще много не менее интересной работы. А что еще нужно для разработчика, увлеченного своим делом?


Organize the most convenient process of selection and purchase of maintenance kits.
Solutions:
Automation of the process of selecting the necessary parts for maintenance of the selected modification with a specified mileage and providing management of the purchasing process. If you are told that "everything is ready - you just need to correct it a little", this is a reason to be seriously alarmed. In most cases, "edits" just become the main and big work on the project. Similarly came out with the data for the Carbox project. The customer provided a large database of cars and parts that had to be "just poured into the required data structure," but ...
The database was transferred and began to write the application, but the algorithms began to accumulate numerous stubs - due to lack of data. Then and there, the required data was simply missing. Of course, the first thing is that in cases when it is stated that the data source is absolutely adequate, it happens - this is the analysis of data loading flights. Obviously, the wonderful initial data was spoiled by the download. We had to re-execute the full load of data - but this time the control of every stage of the download was carried out with the investigation of all the shortcomings - up to the source.
As it turned out - alas, but the lack of data is not in the low-quality download, but in the actual absence of the necessary data in the source. The situation was complicated by the fact that in the end it was necessary to compose the database of the project from three different databases - but this was not without additional and large manual edits. As a result, on the project we encountered the situation "porridge from an ax" - this is when you end up with a decent porridge, but in the final result the ax was needed insofar as.
The situation was saved by the fact that the customer was interested in the result and his experts eventually together with our team did a great job of correcting and supplementing the database, so we really managed to bring the product to the release, though for this we had to do 5 iterations. The second complexity of the project was its "start-up" - the lack of existing business processes, which could be relied upon. The lack of operational experience of a company in any business always leads to numerous corrections of the algorithms of the application "on-the-fly". This does not save the schemes of processes that are written before the start of the project - they always reveal a lot of inaccuracies and irregularities, because business in the case of a startup grows from a bare idea, which in practice has simply not been implemented. Fortunately, here we also managed to agree on an iterative approach with the customer, in which we do not get stuck in the endless rework of the software without releases, but we change the processes and functionality iteratively, from release to release, even if we see anticipated "rework" in the next upcoming release. Nevertheless, the first release still had to be postponed several times - to include in it critical additions and corrections. All together, of course, influenced the development time - if the data source was not ideal, but at least close to if the processes were already at least partially rolled-in work - the project, perhaps, could start twice as fast. But, again, everything ended with a release - a successful release! Behind - a huge and interesting work, in front - still a lot of no less interesting work. And what else is needed for a developer passionate about his business?

Прочая информация о кейсе

1. Создание БД автомобилей (марка, модель, поколение, модификация, год)
2. Создание БД деталей
3. Создание БД регламентов замены деталей на определенном пробеге
4. Создания лэдинга для приема заявок на комплексы ТО
5. Интеграция с поставщиками деталей
6. Front-end разработка сайта (выбранная технология SPA (Single Page Application) на Angular JS с применением стандарта ES6)
7. Back-end разработка сайта (Выбранная технология Ruby on Rails)

1. Creation of a car database (brand, model, generation, modification, year)
2. Creating a database of parts
3. Creating a database of parts replacement regulations for a certain mileage
4. Ledging for the reception of applications for maintenance complexes
5. Integration with parts suppliers
6. Front-end site development (selected SPA technology (Single Page Application) on Angular JS using ES6 standard)
7. Back-end website development (Selected Ruby on Rails technology)