О том, как мы спасаем "замершие" проекты (кейсы + рекомендации по выбору подрядчика)
ЗаказчикМинистерство Арктики и Дальнего Востока, приложение Qber, Агентство стратегических инициативЗадачаОпределить проблемы на проекте, помочь завершить его в назначенные сроки.
Всем привет! Мы команда «Эхо» и уже 12 лет занимаемся веб-разработкой разной степени сложности. За это время мы наработали достаточно компетенций, чтобы помогать заказчикам спасать «замершие» проекты. Так мы называем сайты и мобильные приложения, которые по каким-то причинам остались незавершенными прошлыми разработчиками.
О том, как проходит спасение интернет-проекта, расскажем на примерах.
Кейс 1.
В октябре 2021-ого к нам обратились подрядчики проекта от Министерства Арктики и Дальнего Востока с просьбой до конца года спасти объемный интернет-проект, работы по которому были выполнены частично, а архитектура была излишне усложнена.
Мы начали с аналитики, подключили к выполнению задачи технического директора и четыре разработчика от нашей компании, а также взяли под свое управление команду из трех разработчиков со стороны заказчика, использовали стек Laravel и Vue. js. По части back-end сложность заключалась в большом количестве стратегически важных данных (таблицы, цифры, отметки геолокации) и в расчетах для построения графиков, потому что объем данных был внушительным. Основная работа на front-end была связана с корректным отображением различных таблиц и графиков, а также с визуализацией инфраструктуры Арктики.
В целом на устранение ошибок архитектуры сайта мы потратили более 1 200 часов в месяц, иногда приходилось работать по выходным. Проект удалось спасти даже раньше оговоренного срока, заказчик остался доволен.
Кейс 2.
Еще один проект, который удалось спасти — приложение Qber. Первая в своем роде платформа для телефона с эксклюзивным видеоконтентом, которая не требует оформления подписки.
На старте разработкой этого приложения занималась другая команда, которая не смогла довести проект до финала, в итоге его передали нам по наследству с легаси-кодом от предыдущего разработчика. Мы получили приложение на устаревшем фреймворке, с длинным списком багов и системных ошибок.
К тому же, изначально задумываясь как кроссплатформенное, при единожды прописанном коде, приложение должно было пройти адаптацию под разные интерфейсы, в нашем случае Android и IOS. Но по факту этого сделано не было.
Qber получился больше нативным, чем гибридным и корректно открывался лишь на Android. Хотя прописан был, как полагается, на React Native. Это незначительно, но упростило нам дальнейшую работу над ним. В итоге удалось подогнать приложение под все интерфейсы и настроить корректное отображение приложения на разных экранах.
Главной просьбой заказчика и основной нашей победой в работе над приложением стала настройка системы списания средств из личного кабинета пользователя ежесекундный просмотр контента. И мы с этим справились.
Кейс 3.
Заказчиком было Агентство стратегических инициатив, срок сдачи их проекта поджимал, но команда к тому моменту еще не начала реализовывать функционал. Исполнитель отчитался, что готов дизайн и верстка, по факту оказалось, что она выполнена плохо: скорее всего, впопыхах автоматически экспортировали данные.
Нас подключи к проекту в качестве консультантов, поэтому мы имели возможность пообщаться с командой исполнителя и выявить проблемы.
Оказалось: неправильно выбрана стек-технология. Подразумевалось, что сайт в будущем будет продвигаться, то есть необходима его оптимизация под поисковые системы, а значит, должны быть dom, разметка, html и тд. Исполнитель создал сайт на Flutter web (инструмент для разработки мобильных приложений), поисковые системы видят подобные как картинку. Почему они выбрали эту технологию? Потому что до этого работали только с мобильными приложениями и не обладали достаточной экспертизой в веб-разработке.
Так как сроки сдачи проекта были горящими, то времени на изменение стека фронт-части у нас не было, пришлось погружаться в Flutter web и дорабатывать сайт. Усилили команду исполнителя своими разработчиками, добавили бэк на Node. js и сделали админку на Strapi.
Стоит понимать, что сайт на момент сдачи получился не очень успешным в плане оптимизации. Со стороны исполнителя работала команда джунов, которая использовала автоматическую верстку (из Figma во Flutter): страницы грузились по 10 секунд.
В итоге проект был сдан в срок и удовлетворял всем требованиям заказчика, а мы подготовили предложения по улучшению работы сайта.
О том, что нужно знать при выборе исполнителя По опыту скажем, что часто проблемы возникают у тех заказчиков, которые выбрали разработчиков спонтанно. В лучшем случае результат не оправдывает ожиданий, сайт зависает и работает с ошибками. В худшем — недобросовестный исполнитель срывает сроки и, не доведя проект до ума, исчезает, захватив с собой исходники кодов и не предоставив доступ к админке.
В помощь при выборе исполнителя вопросы:
Как ведется управление проектом? Как часто происходит коммуникация команды с заказчиком? Какие мероприятия компания проводит, чтобы вовремя выявить риски? Какой стек вы используете и почему именно его? Из каких специалистов состоит команда? Добросовестных исполнителей такие вопросы не испугают, даже наоборот. Недобросовестные же будут отвечать, стремясь перевести тему. Например, при вопросе о рисках, начнут вас убеждать, что они в принципе исключены. Опытная компания-разработчик должна предвидеть риски и грамотно ими управлять.
Если вам покажут портфолио, расспросите подробнее о проектах, которые в нем присутствуют. Это позволит отличить реальные кейсы от ложных.
А если неприятность уже случилась, и у вас на руках имеется незаконченный проект, который и людям не показать, и выбросить жалко. Мы можем помочь! Команда «Эхо» берется за работу любой сложности и ответственности.
Перейти на сайт
Полный текст статьи читайте на CMS Magazine
