В сфере заказной разработки мобильных и веб-приложений встречаются разные способы организации работ и комбинации команд подрядчиков. Есть множество факторов, от которых это зависит: специфика проекта, области компетенций и квалификация подрядчиков, бюджет, сроки и еще куча подобных моментов. Единого стандарта нет и быть не может.
Но есть часто встречающиеся комбинации, и одна из них:
бэк на одном подрядчике, фронт – на другом.
Как раз об этой комбинации мы и хотим рассказать. Так что в этой статье поделимся собственным опытом и порефлексируем.
А чтобы картинка не получилась однобокой, сделаем мы это вместе: точку зрения команды бэкенда расскажет Наташа, системный аналитик (SA) компании Интаро, взглядом фронтенда поделится Лиза, аналитик (BA) компании Surf.
Перед стартом
Заказчиком проекта стал крупный строительный e-com.
Что было на старте:
старый сайт с бэком на Битрикс;
старое мобильное приложение (МП) с очень ограниченной функциональностью — не было каталога, карточки товара, да и возможности онлайн-покупки в целом.
Задачи проекта следующие:
создать новый сайт с новым дизайном;
реализовать новое МП с основной функциональностью e-com;
разработать новое API и доработать логику бэкенда для работы с новым сайтом и новым МП.
Лиза, BA
Для нашей команды проект начался с аудита, и это был первый подобный опыт.
Заказчик попросил оценить результаты работы подрядчика, реализующего мобильные приложения для iOS и Android и веб-приложение, в качестве которых он сомневался.
Мы подтвердили опасения клиента в ходе аудита, после чего нам предложили стабилизировать этот проект. Условия были такие: успешное прохождение этого этапа давало нам возможность заниматься проектом дальше.
Результат стабилизации — планируемые результаты этапа стабилизации
Для аналитиков, которые только начинали работать с проектом, обозначили следующие вводные:
аналитики и ТЗ появились на проекте не сразу — примерно через 6 месяце после начала — поэтому какое-то время разработку вели по макетам;
дизайнеры в это время ушли сильно вперёд аналитики — они фактически выявляли требования;
ТЗ (когда оно появилось) было очень объёмным (по 50 страниц на фичу) и написано в формате требований без маппинга на API.
Так, BA должны были:
изучить документацию и бэклог, ознакомиться с процессами;
сформировать подходящий шаблон ТЗ (мы адаптируем шаблон технического задания под каждый проект);
выстроить процесс согласования ТЗ;
выстроить процесс взаимодействия с командами заказчика и бэкэнда;
подготовить ТЗ на будущий спринт.
Наташа, SA
Мы работаем с заказчиком давно — с 2015 года. Поддерживаем сайт и CRM-систему. Мы погружены в бизнес-процессы и изучили нюансы. Несмотря на это, старт проекта по редизайну сайта и разработке новых МП не стал легким.
Нас подключили к проекту в качестве разработчиков бэкенда и REST API, когда новый дизайн уже был создан, план работ декомпозирован, а сроки согласованы (еще до Surf, с другой командой фронтенда).
Что стоило бы сделать иначе:
подключать команду бэка на этапе прототипирования или раньше. Во время дизайн-ревью приходилось вносить корректировки в уже согласованные фичи — часть их была или не реализуема, или реализуема, но не в заложенный на это срок;
не забывать учитывать работы соседней команды при планировании сроков. Это не только про добавление часов работы бэка, но и про гант команды фронта — он тоже сдвинется из-за ожидания доработки от бэка;
хоть мы и пришли на проект раньше команды BA, сложности у SА-команды бэка были примерно такими же (о них выше говорила Лиза). Есть дизайн, нет бизнес-требований — приходилось ждать, пока БТ появятся или «угадывать» по дизайну, как должна работать новая фича, чтобы начать доработку бэка чуть раньше;
В общем, разработка шла впереди и создавала черновые варианты реализации. А уже после того, как БТ были готовы, мы проводили ревью и актуализировали наработки.
Хороший ли это подход? Не очень. Получилось ли ускориться? Точно да.
Казалось бы, очевидные вещи, но даже опытные менеджеры могут их упустить. Особенно, когда нужно спланировать работу нескольких отдельных подрядчиков.
Команды разных подрядчиков сразу могли общаться друг с другом. Заказчик участвовал в обсуждениях, но это не сводилось к бюрократии. Все понимали цель и работали сообща.
Начинаем работать
Проект выглядел довольно обычно для ecom:
3 фронтенда: Web, iOS и Android;
бэкенд (Битрикс) и внутренние системы учета за ним;
поддержка «старого сайта» – текущего фронтенда и старых мобильных приложений – поэтому некоторые фичи внедрялись и на старый сайт для поддержания единообразия.
Лиза, BA
Мы начали стабилизировать проект. Этот этап длился 6 недель и состоял из трудоёмких задач.
Осложнялось всё следующим:
заказчик уже «обжегся» на другом подрядчике, потому относился к нам настороженно. И в то же время ждал экспертности;
горящие сроки проекта горели все так же, так что действовать надо было быстро;
заказчик стремился погрузить нас в проект и предметную область как можно полнее и быстрее. Из-за этого входящей информации было очень много, и далеко не всегда она была системна.
С чего же мы начали работу?
Да, | Но |
Практически сразу завели общее пространство для коммуникаций с заказчиком, командой Интаро и предыдущим подрядчиком фронта | При этом не провели достаточного онбординга для всех участников по новому инструменту коммуникации, так что процесс притирки растянулся |
Выяснили, какие фичи можем брать в проектирование следующими, и начали их проработку | Не учли, что в дальнейшем будем разделяться по командам, из-за чего поделили фичи между аналитиками не самым оптимальным образом |
Сразу решили, что все вопросы наших QA идут через BA – так удавалось быстрее набирать экспертность со стороны аналитики, не ддосить заказчика кучей вопросов и сразу фиксировать изменения в ТЗ | Здесь нет «но», это было со всех сторон правильное решение |
Несмотря на сложности выше, задачу мы выполнили: коммуникация была настроена, ТЗ на будущий спринт спроектировано.
Наташа, SA
На этапе стабилизации мы немного «просели» по нагрузке — ждали включения новой команды, поэтому работа по эпикам затормозилась. Чтобы выровнять нагрузку, мы разбирали задачи бэклога.
Рекомендую аналитикам всегда вести бэклог, хотя бы тезисно в таблице, и держать ее под рукой.
Стоит отметить, что совместные пространства для работы действительно помогают. Да, нам было трудновато перестроиться с одних систем для совместной работы на другие, и команда было в небольшом стрессе от смены подрядчика, но этап «притирки» прошел довольно быстро.
Кейсы
После того как мы как следует проникли в вашу голову погрузили вас в контекст, остановимся подробнее на аспектах, которые получились у нас очень хорошо и очень нехорошо
Интересные статьи
Интересные статьи
