AR-проект для Google Glass потерял всю команду разработки в один день
Ситуация
Пригласили посмотреть продукт на стыке computer vision и дополненной реальности — интерфейс для очков Google Glass. По сути своей — один из самых интересных проектов, что попадались: заказчик есть, объём работ понятен, техническая задача нетривиальная и живая.
Уже на первых созвонах кое-что настораживало. Бэкенд был написан сразу на двух языках — PHP на Laravel и отдельно Python с CV-библиотеками. Интерфейс — на Twitter Bootstrap с jQuery, при том что продукт по условиям задачи должен был устойчиво работать при слабом и нестабильном интернет-соединении — то самое условие, которое определяет архитектуру AR-приложения на носимом устройстве едва ли не сильнее, чем сам computer vision. Возникли естественные вопросы: почему два бэкенда вместо одного, как это всё синхронизируется, и как именно спроектирована работа в условиях плохой связи. Спросить хотелось архитектора или технического лида.
Оказалось, спросить некого. На созвонах со мной были младший тестировщик и владелец продукта. Больше в команде разработки никого не было.
Диагноз
Копнул глубже: за MVP всё это время отвечали два бэкенд-разработчика. Один — PHP и немного фронтенда на Bootstrap, второй — Python и CV-библиотеки. Стадию MVP они закрыли, а дальше, если коротко, ушли — оба, практически одновременно. Причины пусть останутся за кадром, это отдельная история, а не техническая.
Формально бас-фактор проекта равнялся единице, но по факту был ещё хуже: половину знаний о системе держал в голове один человек, вторую половину — другой, и знания эти почти не пересекались. Один не разбирался толком в CV-части, второй — в PHP-бэкенде. Когда оба ушли одновременно, не осталось буквально никого, кто понимал бы продукт целиком: ни архитектурного описания, ни схемы взаимодействия двух бэкендов, ни объяснения, как устройство должно вести себя при обрыве связи. Репозиторий на месте, задачник на месте, тесты, если и были, — в основном ручные, силами того самого младшего тестировщика. Команды разработки не было вообще.
Что сделали
- Реверс-инжинирингом восстановил архитектуру по коду и артефактам: как взаимодействуют PHP- и Python-части, какие данные и в какой момент идут между ними, что из логики отвечает именно за нестабильный интернет-канал, а что было временным решением на скорую руку ради MVP.
- Задокументировал восстановленную архитектуру и бизнес-процессы — то, чего не существовало вообще ни в каком виде.
- Нанял дизайнера на проектной основе — интерфейс на Bootstrap с jQuery не выдерживал ни требований продукта, ни ожиданий пользователей, которые в буквальном смысле смотрят на этот интерфейс через очки.
- Спроектировал и разработал с нуля пользовательский интерфейс и отдельную админ-панель — старый фронтенд не реанимировали, а заменили на осмысленный.
- Собрал новую команду разработки и обучил её работать с унаследованной системой: ввёл в контекст, передал восстановленную документацию, выстроил процессы код-ревью и коммуникации, чтобы риск «один человек — одна половина системы» больше не повторился.
- После передачи проекта ещё около года оставался на связи в формате периодических консультаций — почти любая система после реанимации первое время требует точечной поддержки, и лучше, чтобы она была доступна, а не изобреталась заново при следующей проблеме.
Результат
Проект перешёл из состояния «репозиторий и задачник есть, команды нет» в рабочее состояние с новой командой, документированной архитектурой и интерфейсом, спроектированным осознанно, а не унаследованным от MVP-набросков. Бас-фактор перестал быть точечной уязвимостью: знания о системе теперь не заперты в головах двух конкретных людей, которые в любой момент могут одновременно решить уйти.
Отдельный урок из этого кейса — организационный, не технический: если на созвонах о продукте некому ответить на архитектурные вопросы, это сигнал раньше, чем любой код-ревью. Спрашивать, кто в команде отвечает за архитектуру, стоит до подписания контракта, а не после того, как эти люди уже ушли.
У вас такая же ситуация?
Давай решим...