
Поставленная задача и ее решение
Организовать максимально удобный процесс подбора и покупки комплектов для проведения технического обслуживания.
Решения:
Автоматизация процесса подбора необходимых деталей для технического обслуживания выбранной модификации с заданным пробегом и обеспечение управлением процесса покупки. Если вам говорят, что "всё уже готово - нужно лишь немного подправить", это повод серьезно насторожиться. В большинстве случаев "правки" как раз становятся основной и большой работой на проекте. Аналогично вышло и с данными для проекта Carbox. Заказчик предоставил большую базу данных автомобилей и деталей, которые надо было "лишь влить в требующуюся структуру данных", однако... Базу данных перелили и стали писать приложение, но алгоритмы стали обрастать многочисленными заглушками - из-за недостатка данных. То там, то сям обязательные данные просто отсутствовали. Разумеется, первое, что в случаях, когда заявлено, что исходник данных совершенно адекватный, происходит - это разбор полетов загрузки данных. Очевидно же, что замечательные исходные данные испортились при загрузке. Нам пришлось заново осуществить полную загрузку данных - но на этот раз проводился контроль каждого этапа загрузки с разбирательством всех недостатков - до источника. Как выяснилось - увы, но недостаток данных кроется не в некачественной загрузке, а в собственно отсутствии необходимых данных в источнике. Ситуация осложнялась тем, что в итоге пришлось компоновать базу проекта из трех разных БД - но и это не обошлось без дополнительных и больших ручных правок. В итоге, на проекте мы столкнулись с ситуацией "Каша из топора" - это когда вы в итоге всё таки варите приличную кашу, но топор в конечном результате нужен был постольку-поскольку. Ситуацию спасло то, что заказчик был заинтересован в результате и его эксперты в конечном счете совместно с нашей командой проделали таки огромную работу по исправлению и дополнению базы данных, так что нам действительно удалось довести продукт до релиза, хоть для этого и пришлось проделать 5 итераций.
Второй сложностью проекта являлась его "стартапность" - отсутсвие уже существующих бизнес-процессов, на которые можно было бы опереться. Отсутствие операционного опыта у компании в каком-либо бизнесе всегда приводит к многочисленным правкам алгоритмов работы приложения "по ходу действия". От этого не спасают и схемы процессов, которые пишутся перед стартом проекта - в них всегда обнаруживается масса неточностей и неправильностей, ведь бизнес в случае стартапа вырастает практически из голой идеи, которая на практике еще просто не была реализована. К счастью и здесь нам удалось договориться об итерационном подходе с заказчиком, при котором мы не застреваем в бесконечных переделках ПО без релизов, а меняем процессы и функционал итеративно, от релиза к релизу, даже если заранее видим в очередном предстоящем релизе намечающиеся "переделки". Тем не менее, первый релиз всё же пришлось несколько раз откладывать - чтобы включить в него критически важные дополнения и исправления.
Всё вместе, конечно, повлияло на сроки разработки - если бы источник данных был пусть не идеальным, но хотя бы близким к тому, если бы процессы были уже хотя бы частично обкатанными в работе - проект, пожалуй, мог бы стартануть в два раза быстрее. Но, опять же, всё завершилось релизом - успешным релизом! Позади - огромная и интересная работа, впереди - еще много не менее интересной работы. А что еще нужно для разработчика, увлеченного своим делом?
Выставлено в номинациях:
— Сайт вендора, платформы, сервиса
— Сайт стартапа
— Сервис, портал, агрегатор в розничной торговли
Голосование завершено, итог по народному голосованию: 200
Средний балл оценок жюри — 6Егоров Артемий | 5 |
Прокофьев Сергей | 6 |
Ломов Денис | 6 |
Франгуриди Константин | 6 |
Мartynenko Аlexandr | 7 |
Харчиков Дмитрий | 5 |
Болотов Максим | 8 |
Розов Михаил | 7 |
Тютюников Владислав | 4 |
Исмагилов Наиль | 7 |
Богданов Александр | 6 |
Кулаков Алексей | 5 |