Новый продукт и старая команда, которую нельзя потерять
Ситуация
Пришёл в проект техническим директором. В компании уже был продукт в эксплуатации, и его нужно было одновременно поддерживать и развивать в новую, сложную предметную область. Вся разработка держалась на одном человеке: он знал систему, закрывал все задачи и был, по сути, единственным носителем знаний о ней.
Задача выглядела так: стать экспертом в новой области, создать новый продукт, и при этом не потерять единственного разработчика. Потерять его значило остановить поддержку действующего продукта, поэтому каждое решение приходилось взвешивать с оглядкой на него.
Диагноз
Первое, что показал код-ревью: разработчик использовал популярный фреймворк, но во многом не следовал его подходам. Вместо готовых механизмов он придумывал собственные — с нуля и по-своему. Это не злой умысел, а типичный след многолетней работы в одиночку, когда сверить решение не с кем.
Это всё привело к сложной ситуации:
- поддерживать такой код было сложно даже самому автору;
- подпускать его к новой части продукта было рискованно — там повторилось бы такое же самобытное программирование, непонятное знатокам фреймворка;
- задач "по уровню" ему почти не оставалось, а нехватка навыков в команде ощущалась постоянно, и каждый раз звучал один и тот же вывод: нужно нанимать людей.
Вторая проблема — дизайн. Продукт нужно было спроектировать сразу в нескольких видах: посадочные страницы, приложение для клиентов и приложение для сотрудников компании, причём в едином стайл-гайде. Имевшийся дизайнер собирал интерфейсы "из кубиков" в презентациях PowerPoint, так называемые мокапы или "рыбу". Для точной визуальной проработки и новых визуальных решений, не вписывающихся в уже существующее (например, отзывчивую верстку или новые палитры), этого было недостаточно.
Третья проблема — сам процесс найма. Дизайнеров подбирали по эстетическому впечатлению от собеседования, а не по тому, как человек справляется с задачей. Мне такой подход не близок: оценивать нужно не внешность и не общее впечатление, а профессиональные навыки. Кандидатам стоило давать небольшие рабочие задания и смотреть на результат — тогда выбор получается честным для обеих сторон.
Что сделали
- Разделили продукт на части так, чтобы у каждой команды была своя зона ответственности и никто не мешал друг другу. Действующая команда сохранила за собой то, что знала лучше всего и где риск был минимальным, — например, лендинги.
- Новую часть отдали новой команде. Она проектировала и реализовывала высоконагруженную систему сбора данных с торговых точек, анализа товарного движения и остатков, а также рекомендательную систему на основе машинного обучения — для управления продуктовой матрицей и повышения рентабельности точек.
- Перестроили найм дизайнеров на тестовые задания: кандидат показывает работу, а не просто приходит на беседу. Так в команду пришли люди с нужным опытом, способные вести единый стайл-гайд.
- Для остававшегося разработчика подобрали задачи по росту: умные и интересные, но в безопасном контуре, где нестандартные решения ничего не ломают. Без громких слов, без «разбора полётов» — человек остался в команде и продолжил приносить пользу. Также к нему регулярно обращались для принятия решений, приглашали для создания быстрых прототипов, которые затем реализовывала другая часть команды.
Результат
Продукт был реализован. Команда осталась целой, и каждому нашлось место и время. Часть времени потеряли — перестройка потребовала усилий и на найм, и на аккуратное перераспределение работы, — но в итоге всё получилось.
К сожалению, коммерчески история закончилась неудачно: на этапе запуска выяснилось, что точек, которые можно автоматизировать, слишком мало. Продукт не вышел на нулевую окупаемость, и проект был закрыт. Это честный итог, и именно поэтому он здесь: техническая часть была выполнена, а рынок оказался меньше, чем предполагалось.
Главный вывод — проверять размер рынка и экономику продукта нужно раньше, чем нанимать команду под него. Технический директор может сделать так, чтобы продукт получился, но не может заменить собой проверку гипотезы о том, нужен ли он вообще, — и об этом стоит договариваться на старте.