Это не просто красивый кейс, о том какие все молодцы и как всё прекрасно и замечательно прошло - назовем эту историю “Что-то пошло не так”...
Итак, начнем.
Исходная ситуация
Поступила задача - разработать туристический сервис. Сайт у клиента уже был - простенький, и конечно нужно создать крутой продукт с новым дизайном и расширенным функционалом.
Цели:
-
Создать возможность покупки Подарочных Сертификатов.
-
Создать возможность бронирования места на Событие.
-
Создать возможность арендовать туристическое снаряжение на прокат.
-
Создать возможность подачи заявки на Корпоратив.
И вроде бы все нормально, никакой сверхсложной задачи - опыта достаточно, технологии в стеке есть, менеджера нашли и команду подобрали, что же могло пойти не так?
Процесс работ
А пошло все кувырком еще на этапе оценки, к сожалению. Продажник и менеджер невнимательно ознакомились с информацией и, возможно из-за текущей загруженности, не углубились в требования и пожелания клиента. Оценку составили по-быстрому и в разрезе одного каталога поскакали дальше к подписанию договора и старту работ.
А что же было на самом деле:
- каталог подарочных сертификатов с разными опциями и набором сопроводительных услуг к каждому из них, определенные требования к работе фильтра при выдаче результатов по приоритетности в зависимости от геолокации;
- каталог событий с характеристиками, возможностью бронирования участия, количеством мест, с учетом индивидуальной продолжительности каждого. Т.е. одно событие может проходить каждый четверг и вторник, длится оно около 3х часов и может не проводится в холодное время года, а вот второй может быть путешествием за границу, бывает один или 2 раза в месяц, длится 5 дней, аналогично определенные требования к работе фильтра при выдаче;
- каталог снаряжения с количеством единиц, стоимостью, наличием в зависимости от города.
Т.е. 3 каталога, с учетом изменения контента в зависимости от геолокации по определенным триггерам, изменения языка согласно правилам геолокации ( например: Львов - украинский язык, Днепр - русский).
*это не считая Корпоративов - заявка на проведение и двух-трёх ландосиков ( landing page).
Что-то пошло не так #1
Оценка по часам была в 4 раза меньше, чем потратили по итогу разработки, т.е. Компания понесла прямые убытки при реализации данного проекта.
Почему: уровня спецов, которые оценивали, и глубины вовлечения было недостаточно для продукта целиком.
Что получилось по итогу Дизайна можно посмотреть на действующем сайте kava, вот так выглядит главная страница.
Сайт получился сочный - даже пошли с ним на awwards ;-)
Ну что поехали дальше.
Тут небольшой сюрприз - смена менеджера проекта. Новый менеджер пришел уже на этапе верстки и при ознакомлении с дизайном и функционалом понял, что объем работ большой и запланированного времени будет крайне недостаточно, потом поехала смена стека технологий для разработки проекта перешли на framework laravel5 - этот движок позволял более гибкую разработку и архитектурные решения с учетом повышения нагрузки и расширения функционала.
Что пошло не так #2
От первого варианта верстки вынуждены были полностью отказаться и переверстать все с нуля.
Почему: библиотеки laravel5 подразумевают свои особенности на фронте (Front-end — интерфейс взаимодействия между пользователем и основной программно-аппаратной частью back-end). Эти потери полностью взяла на себя компания.
Тут же с началом верстки запустили программирование бэка, чтобы ускорить процесс и хоть как-то уложиться в дедлайн. Жаль, но этому не было суждено случиться...
По итогу на верстку потратили в 3,5 раза больше запланированного времени.
Почему: повлиял сочный и вкусный дизайн.
На программирование потратили в 4,8 раза больше запланированного времени.
Почему: наличие большого объема различного функционала, подготовка архитектурного решения.
Результат
По итогу сейчас мы считаем разработанный нами сервис KAVA одним из лучших программных и дизайнерских решений.
Вывод
Не смотря на тяжелый процесс разработки и большое количество трудностей, с которыми нам пришлось столкнуться, надеемся клиент остался доволен результатом. Мы же теперь ставим этот проект, как пример, на все удобные случаи - про него можно написать отличную книгу по правилам разработки: как нужно и как не нужно разрабатывать продукты.