В сфере заказной разработки мобильных и веб-приложений встречаются разные способы организации работ и комбинации команд подрядчиков. Есть множество факторов, от которых это зависит: специфика проекта, области компетенций и квалификация подрядчиков, бюджет, сроки и еще куча подобных моментов. Единого стандарта нет и быть не может.

Но есть часто встречающиеся комбинации, и одна из них:

бэк на одном подрядчике, фронт – на другом.

Как раз об этой комбинации мы и хотим рассказать. Так что в этой статье поделимся собственным опытом и порефлексируем.

А чтобы картинка не получилась однобокой, сделаем мы это вместе: точку зрения команды бэкенда расскажет Наташа, системный аналитик (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 недель и состоял из трудоёмких задач. 

Осложнялось всё следующим:

• заказчик уже «обжегся» на другом подрядчике, потому относился к нам настороженно. И в то же время ждал экспертности;

• горящие сроки проекта горели все так же, так что действовать надо было быстро;

• заказчик стремился погрузить нас в проект и предметную область как можно полнее и быстрее. Из-за этого входящей информации было очень много, и далеко не всегда она была системна.

С чего же мы начали работу?

Несмотря на сложности выше, задачу мы выполнили: коммуникация была настроена, ТЗ на будущий спринт спроектировано. 

Наташа, SA

На этапе стабилизации мы немного «просели» по нагрузке — ждали включения новой команды, поэтому работа по эпикам затормозилась. Чтобы выровнять нагрузку, мы разбирали задачи бэклога. 

Рекомендую аналитикам всегда вести бэклог, хотя бы тезисно в таблице, и держать ее под рукой.

Стоит отметить, что совместные пространства для работы действительно помогают. Да, нам было трудновато перестроиться с одних систем для совместной работы на другие, и команда было в небольшом стрессе от смены подрядчика, но этап «притирки» прошел довольно быстро.

Кейсы

После того как мы как следует проникли в вашу голову погрузили вас в контекст, остановимся подробнее на аспектах, которые получились у нас очень хорошо и очень нехорошо ?

Коммуникация

Лиза, BA

Коммуникация – это база, тут добавить нечего.

Поэтому наша работа началась с настройки пространства для общения.

Мы пользуемся Discord, поэтому и предложили использовать этот инструмент. А заказчик не смог отказаться согласился. Но похожие и даже точно такие же подходы можно использовать и в других мессенджерах (Slack, Telegram и прочих).

Как мы организовали работу:

1. Создали отдельный сервер для проекта, куда пригласили всех участников.
   В этом плане Discord удобнее Telegram — нет путаницы с личной и рабочей перепиской (правило работает, если участники — не геймеры).

2. Организовали разделение по каналам.
   Каждый канал отвечает за определённую часть проектной деятельности: в каналах стеков (ba, qa, web и других) агрегируются вопросы и информация по стекам, в all публикуются объявления и вопросы для всей проектной команды и так далее.
   Такое разделение упрощает навигацию и поиск информации.
   Кроме того, можно гибко настроить группировку каналов и доступ участников сервера к каналам или группам.

3. Для основных каналов описали и закрепили правила работы, сделали легенду по общепринятым реакциям.
   Унифицированные заголовки сообщений позволяют быстро создавать ровно такие же унифицированные заголовки тредов, что, опять-таки, упрощает навигацию. А использование реакций выручает, поскольку в Discord нет автоматических уведомлений о прочитанных сообщениях.

4. Создали голосовые каналы.
   Они позволяют быстро обсуждать вопросы, не перебегая в другие сервисы видеоконференций.

5. Ввели гибкую ролевую модель.
   Она упрощает привлечение необходимых сотрудников к вопросу. Особенно выручает, когда нужно задействовать много людей – не нужно перечислять всех по именам. Кроме того, можно быстро понять, к какой компании относится сотрудник, и какую роль он выполняет. Это очень помогает на проектах с большим количеством участников.

Недостаток использования таких подходов — достаточно высокий порог входа. Мы ограничились письменными инструкциями и не провели полноценного обучения. Из-за этого некоторые участники проекта привыкали к Discord несколько недель. И это при том, что на сервер были привлечены только технические специалисты. Для бизнес-пользователей однозначно потребовался бы полноценный онбординг. 

Тем не менее, несмотря на некоторую сложность в начале, Discord дал свой результат: достаточно быстро мы смогли перенести основную часть выяснений вопросов в Discord и убрать еженедельные созвоны на эту тему.  

Наташа, SA

Использование Discord вместо привычного Telegram помогло сохранить work-life balance и не отвлекаться на бесконечные каналы с полезным (и не очень) контентом. 

Наш техлид начал вести канал #api-update, писать, какие доработки API внедрены после его ревью. Это оказалось очень удобным инструментом оповещения для всех, кто ждал конкретную доработку, чтобы продвинуть эпик дальше.

Сначала я скептически отнеслась к каналу #флудилка – мы же тут работать собрались.

Но когда вижу, как все перекидываются мемами, в том числе и команда заказчика, меня отпускает тревожность. Все живые люди, все стремятся к отличным результатам, при этом не уходят в излишнюю серьезность.

Груминги

Дабы не разводить холивар по этой теме, определимся с терминологией:

• груминг (grooming/причесывыние бэклога) – одна из активностей SCRUM-фреймворка для актуализации и приоритизации бэклога; 

• бэклог (backlog) – очередь из пользовательских историй для конкретного продукта;

• продуктовый (глубокий) бэклог (product backlog) – очередь, которая объединяет всю функциональность продукта. Этот бэклог имеет верхнеуровневую приоритизацию, не привязанную к спринтам жёстко. Приоритизация может легко и свободно меняться.

• бэклог спринта (sprint backlog) – часть продуктового бэклога, которая имеет самый высокий приоритет. Здесь лежит функциональность (истории), которая уже проработана BA, либо находится в работе. 

Под грумингом ниже мы будем понимать груминг бэклога спринта.

Лиза, BA

Как только у нас появились первые спроектированные фичи, мы запустили груминги. Практически сразу удалось установить правильную конфигурацию. 

На груминге бэклога спринта обязательно присутствуют:

• BA, который проектировал фичу;
  Он же ведёт груминг: рассказывает о чём фича,  демонстрирует основную логику и изменения, которые были внесены в ходе проектирования. Последний пункт был важен для заказчика, потому что почти по всем фичам дизайн уже был и согласовывался;

• разработчики и QA, которые будут работать с фичей;

• представители заказчика: менеджер команды и руководитель проекта;

• представители бэкенда: системный аналитик и лид бэкэнда;

• опционально –  лиды направлений и PM.

Основные потребности, которые закрыл груминг:

Наташа, SA

Совместные груминги по эпикам отлично сработали для синхронизации команд (этот формат обязательно раскатаем на другие проекты).

До груминга мы получали документацию от аналитиков Surf для ревью. В ней находились требования к фронтенд-части. 

Это было удобно, потому что мы могли заранее подготовить вопросы. Так все встречи проходили максимально эффективно. Каждому было что сказать, поэтому не было ребят, которые просто «пришли послушать».

Аналитик Surf проводил демонстрацию работы системы, команды фронта и бэка могли обсуждать вопросы реализации.

После груминга я проверяла, совпадают ли ожидания и реальность уже разработанного бэком, тестировала, что отдает API, и ставила задачи на доработку.

Мы все еще старались работать на опережение, чтобы успеть в срок  (бэк делал черновой вариант реализации по дизайн-макетам заранее). Поэтому мы не приступали к работам после груминга и по готовому ТЗ, а скорее актуализировали разработанное заранее.

Подход спорный, согласна. В каждом эпике приходилось переделывать части, которые мы не правильно угадали только по дизайну. Но в наших условиях, со всей турбулентностью проекта, без такого подхода просто не успели бы к релизу. Процент правильно угаданного был намного больше мелких правок после согласования ТЗ.

Подготовка к демо

Вот мы и дошли до части «очень нехорошо» ?

Лиза, BA

Мы, как новые подрядчики, не сразу нашли оптимальную формулу проведения демо.

У каждого клиента есть особенности: кому-то нравится смотреть на красивые макеты, кому-то – на бьющиеся цифры, а кому-то – на сходящийся гант. 

Как было у нас:

1. Мы показывали факт-план по выполненной работе в общем и по каждому стеку отдельно.

2. Обращали внимание на проблемы, с которыми столкнулись, чтобы быть заказчик был в курсе происходящего.

3. Демонстрировали разработанные за спринт фичи с максимально приближенным к реальности контентом.

Добавим ещё щепотку важности: на демо приходили все ЛПР, поэтому от его результатов буквально зависела судьба проекта.

И если с первыми двумя пунктами в основном работали менеджеры проекта, то с последним – с демонстрацией фич – аналитикам пришлось как следует повозиться.

Наташа, SA

На демо команда  показывала наработки, собирала обратную связь, подтверждала соответствие требованиям, отмечали, что идем по графику. Проводили его ребята из QA.

Все достаточно стандартно, но процесс демо изначально был недостаточно организован.

Мы выходили на демо с разных площадок – у нас не было выделенного демо-стенда. Это значит, что перед демо не было понятно, на какой из площадок стоит проверить актуальный контент, на какой площадке просить команду ничего не тестировать, чтобы не показывать акции «Тест 1234», которые создали для тестов. 

Для фронтенда в вебе у нас был только один стенд – на нём же  велась разработка.  И иногда, в моменты проверки контента перед демо, было трудно понять, что-то не заполнено или баннер скрыт, потому что идут работы.

Какие выводы мы сделали (и использовали):

1. Готовить отдельную площадку для демо. 

С полноценным интеграционным контуром на случай, если внешние системы отвечают за расчет корзины, даты доставки, контент.

2. Оповещать всю команду о времени демо. 

Тут важно говорить не только, что «демо будет послезавтра», но еще и напоминать, что «мы начинаем через 5 минут». Сообщать о демо всем подрядчикам, чтобы кто-то не решил запустить долгий скрипт на своей части демо-стенда в самый ответственный момент.

3. Постараться как можно раньше рассказать  командам, что именно будем показывать на демо.

Естественно, мы могли отступить (и отступали) от сценария – за случайный клик на еще не работающую фичу никто не кричал о несостоятельности команды, да и чаще всего к демо все связанные фичи уже работали. Но для понимания приоритетов дебага, внедрения доработок, наполнения контентом всем участникам важно знать, что именно будет в демонстрации.

История с демо, конечно, завершилась хорошо. Мы добавили внутренние прогоны перед демо, команды знают, что и когда будет показываться, процесс подготовки согласован и зафиксирован.

Ну и поскольку лучшая импровизация – это подготовленная импровизация, важно хорошенько готовиться к демо.

Контент

Наташа, SA

Казалось бы, релиз, финишная прямая, мы пришли к успеху. Но нет.

Мы все были заняты каждый своей частью работ и упустили этап наполнения контентом.

Во-первых, отдаём должное команде заказчика – контент был создан заранее и тихонько ждал своего часа. В чем проблема? В том, что мы не договорились, кто и на какой площадке его заполнит.

Сложность была в том, что большая часть контента заполняется в отдельной системе (ПИМ). Её нужно было интегрировать с определенной площадкой бэка (которую еще не выбрали) и запланировать, как этот контент попадет в итоге на боевой стенд (бой). 

Какие варианты мы рассматривали:

• ПИМ-систему интегрировать со stage, написать миграции на стороне бэка и в нужный момент перенести контент на бой;

• ПИМ-систему интегрировать со stage, проверить, как выглядит контент и переключить ПИМ на интеграцию с боем.

Какой же вариант мы выбрали? Ни один, потому что пока договаривались, пришло время заполнения контента сразу на бою. 

На самом деле это все еще отголоски отсутствия полноценной препрод-среды

На основании этих сложностей мы сделали чек-лист для этого этапа и делимся им с вами (чтобы вы не столкнулись с теми же проблемами):

Лиза, BA

Когда контент был наконец залит, мы наткнулись ещё на одну проблему: картинки залиты, приходят на фронт, но они либо пиксельные, либо обрезанные, либо растянутые.

Стали разбираться: расследование показало, что в админке есть одно поле для загрузки картинки, но картинка используется в шести «мордах»: старый сайт, адаптив старого сайта, старое МП, новый сайт, адаптив нового сайта, новое МП. 

И вот в последних трёх пропорции контейнеров изображений далеко не всегда совпадали с первыми тремя.

Пришлось срочно искать такие кейсы, переделывать дизайн и заново согласовывать всё с бизнесом.  

Это ещё один аргумент в пользу последнего пункта из чек-листа Наташи. Даже такая, казалось бы, простая задача, как отображение контента, может вскрыть очень неприятные кейсы, которые потребуют доработки.

Что в итоге

Идеальных проектов не бывает: как бы вы ни пытались подстелить соломки, всё равно найдётся тот самый торчащий гвоздь. 

Даже если вы давно работаете с заказчиком, и всё отлажено, новый проект внесет коррективы и выстраивать процессы придется заново. А уж если вы берётесь за проект с легаси – там вообще вся солома с гвоздями вперемешку. Но это не приговор.

Секрет успеха: 

• Быстрая и отлаженная коммуникация.
  С этим помогут разделение на каналы, группы, теги и прочие инструменты (и не забываем про онбординг).

• Единый бизнес-контекст всех фичей.
  Здесь отлично работают груминги, они позволяют сформировать единое видение у всей команды.

• Согласованность и прозрачность в работе друг с другом и в том числе с заказчиком.
  Демо – прекрасный вариант для подведения промежуточных итогов и точка синхронизации всех команд.

• Подстраховка и взаимопомощь.
  Работать над своей задачей и смотреть, как дела у коллег. Видеть продукт целиком, не только доработки своей команды. 

Совместная работа – это не романтическая комедия, но и не хоррор. Вот такое общеобразовательное ретро у нас получилось. Так что предлагаем учиться на наших ошибках, а мы уже стартуем со вторым релизом ?

Кейсы и лучшие практики в области системной и бизнес-аналитики, новости, вакансии и стажировки Surf — в телеграм-канале Surf BA Team.

Присоединяйтесь!