Привет, Хабр! Меня зовут Вероника, я QA-lead в одном из внутренних продуктов Самоката. Хочу поделиться, какие практики мы в команде применяли, чтобы адаптировать процесс разработки под реалии запуска нового проекта.

Когда мы начинаем с нуля делать новый IT-продукт (или проект внутри компании), часто на помощь приходит концепция MVP. Делаем хоть сколько-то готовую версию, чтобы как можно раньше получить обратную связь от пользователей и стейкхолдеров, а дальше разберёмся.

Ради этого «как можно раньше» процесс часто выглядит как яростный забег: жертвуем регламентами, документацией и другими вещами, которые «полезные, но давайте потом». Работаем в режиме «не поднимая головы».  Для полноты картины добавим сюда часто меняющиеся требования — на ранних стадиях создания продуктов такое регулярно случается. Знакомо?

Что при этом происходит с командой? Переработки, стресс, демотивация, а там и до выгорания недалеко. В статье расскажу, как мы делали MVP нового внутреннего продукта, что для нас сработало (и не сработало), чтобы помочь команде держать высокий темп, адаптироваться к меняющимся требованиям и не терять боевой дух и мотивацию.

С чего всё началось

Мы с командой делаем веб-приложение для управления промо-акциями и реализации различных промо-механик. Результат работы этого приложения – зачёркнутая старая цена в каталоге, а рядом – новая, со скидкой. И сейчас наш продукт автоматизирует работу трейд-маркетологов, сократив их ручной труд.

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

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

Кроме новых задач, у нас были:

• команда, собранная из людей, которые прежде никогда не работали вместе, а большинство только пришли в компанию;  

• отсутствие регламентированных бизнес-процессов в операционной части (трейд-маркетинге);

• негативный прошлый опыт.

Изначально, мы планировали сделать MVP за 3 месяца. Конечно же, мы не успели и 3 месяца превратились в 5 (классика, но об этом дальше). Зато мы смогли сделать рабочий продукт, не растеряли команду и мотивацию и получили отличный опыт.

Многие из практик, которые мы применяли, можно смело записывать во вредные советы для размеренного режима работы. Однако, они принесли результат в режиме «делаем ASAP». А часть практик мы эффективно применяем и сегодня.

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

Техническая часть

Прежде всего, мы организовали техническую часть с учетом опыта разработки первой версии веб-приложения:

Сделали на стандартном для компании стеке
Мы не выдумывали велосипеды и использовали то, что принято в компании как дефолтные технологии: Kotlin, PostgreSQL, Kafka, Hazelcast — это помогло избежать проблем на этапе техрешения.

Использовали общее платформенное решение для backend-сервисов
Речь о конфигурации сборки (Gradle plugin и готовая структура build.kts), конфигурации Feign-клиентов и конфигурации Hazelcast-кэшей. Серьёзных технических проблем при реализации тут не возникло.

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

Сделали унифицированный контракт фронта и бэка
Работа с промо требует большого количества валидаций введенных данных. Часть валидаций на бэке возвращает предупреждения (действие можно выполнить, но мы обращаем внимание пользователя на потенциально некорректные данные), а часть — ошибки. В некоторых операциях по бизнес-требованиям должны были возвращаться только ошибки. Но мы на всякий случай сразу заложились на то, чтобы в ответах бэка всегда возвращать и ошибки, и предупреждения, чтобы не пришлось добавлять их потом и тратить время на рефакторинг. В итоге это сработало — в большинстве мест появились и предупреждения.

Использовали единственный стенд с latest-master 
Мы пушили все изменения, прошедшие ревью, сразу в мастер, а также завели единственный тестовый стенд, на который ставили latest-master и сидели на нем всей QA-командой. Таким образом, мы быстро обнаруживали проблемы и давали обратную связь разработчикам.

Быстро задеплоили в прод и тестировали там же
В продакшн-среде можно тестировать на реальных данных (трейд-маркетологи нам давали реальные файлы с промо) и внешние системы на продакшене имеют отличную от тестовой конфигурацию. Это особенно важно при взаимодействии с 1С, которую нельзя поднять в контейнере и сконфигурировать. Разумеется, перед запуском пользователей на прод мы за собой все почистили.

Релизили под feature flags
Мы договорились релизить под фича-флагами, если команды, с которыми мы интегрируемся, еще не были готовы. Таким образом мы не задерживали из-за несмерженных/невыкаченных изменений нашу разработку и двигались дальше по плану.

Начали делать фронтенд без дизайнера
Просто переняли наработки соседнего проекта со схожим бизнес-процессом и потребностями юзеров. Это здорово помогло сэкономить время.

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

Инструментальное

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

Свели бюрократию к минимуму
У нас было допустимо иногда договориться лично, в обход Jira — в целях экономии времени, и чтобы не вызывать негатив от необходимости все документировать письменно. Конечно, этим нельзя злоупотреблять, потому что без документации невозможно существовать в долгосрочной перспективе.

Договорились о запрете на личные переписки
У нас были запрещены переписки в личках (если это по работе и может быть полезно кому-то, кроме двух людей) — все обсуждения должны вестись в общекомандном канале. За счет этого мы быстро реагируем на все, не теряем время на уточнения у разных участников, вся информация всегда в одном месте. Можно тегнуть нужного человека, можно услышать разные точки зрения и, чем больше людей, тем быстрее тебе помогут, если у тебя срочная проблема. А в противном случае, твой собеседник может быть на митинге или вообще не знать ответ на твой вопрос.

Обязательные реакции под сообщениями
У нас использовался мессенджер Slack, который позволяет ставить реакции под сообщениями и настраивать напоминания. Поэтому у нас было правило: если ты прочитал сообщение, но пока не можешь ответить, ставишь эмодзи «глаза» + настраиваешь напоминание, чтобы не забыть ответить. Это помогает создать атмосферу доверия и уважения к друг другу, и исключает ситуации, когда ты задал вопрос, а тебя игнорируют.

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

Актуальные требования в тест-кейсах
Поскольку PM у нас был один, а инженеров по тестированию несколько, мы использовали эти ресурсы на поддержание актуальных тест-кейсов, согласно последним изменениям требований, даже если в документации PM это еще не отразил. Таким образом разработчики не теряли мотивацию из-за того, что «ничего нигде не описано, все неактуально».

Организационное

И последняя (но не по важности) часть наших практик — организационного характера.

Наняли аутстафф для быстрого старта
Часть команды разработки состояла из аутстафф-сотрудников. Найти инхаус-сотрудников в нужном количестве за короткий срок всегда сложно. Поэтому привлечение аутстаффа показалось нам подходящим решением, для результата, который нужен здесь и сейчас. Но как работать с аутстаффом (в том числе с мотивацией) — тема отдельной статьи.

Ввели анонимные ретроспективы
Мы заметили, что на неанонимных люди не всегда хотят говорить о своих проблемах. Мы стали использовать приложение EasyRetro, где в формате обезличенных карточек можно поделиться болью и сформировать список action items. На каждое ретро назначается дежурный и он зачитывает карточки, а дальше мы всей командой их обсуждаем.

Лиды берут удар на себя
Лиды договорились «брать удар на себя» в ситуациях, когда приходил PM и говорил, что требования поменялись. Задача лидов — все это проанализировать и только потом донести эту информацию остальной команде так, чтобы минимизировать негатив и ощущение аврала, нестабильности и «работы в стол». Лиды распределяли задачи так, чтобы коллеги не оказались в состоянии «не знаю, за что хвататься, все горит».

Индивидуальный подход к овертаймам
Когда стоит цель как можно быстрее выпустить MVP, зачастую приходится овертаймить. Но не все могут это делать, по разным причинам: кто-то уже перешел в стадию «работать, чтобы жить», а не наоборот. У кого-то дети или учеба. Поэтому мы с пониманием относились к каждому, искали индивидуальный подход и допускали переработки только у тех, кто к этому морально и физически был готов. Опять же, этим нельзя злоупотреблять, особенно на длинной дистанции.

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

Фиксация промежуточного результата и тимбилдинг
Одним из важных пунктов для нас стало зафиксировать промежуточный результат в ходе разработки MVP и устроить тимбилдинг (до релиза). Это дополнительный способ показать команде ее значимость и помочь отдохнуть.

Работа с мотивацией
Мы постоянно работали с мотивацией: PM и PTL проводили встречи, на которых рассказывали, что и зачем мы делаем и что нас ждет после — чтобы не было ощущения, что вот сейчас сделаем MVP и можно расходиться.

Общие созвоны для уточнения требований
Иногда мы жертвовали детальной проработкой требований в Confluence, а вместо этого делали созвоны на команду и в течении часа грумили и дополнительно уточняли все неосвещенные вопросы. Для нас это было промежуточным решением между «всё-всё продумать» vs «сделать быстрее».

Не забывали про интеграцию
Мы заблаговременно наладили коммуникации с командами, с которыми нам предстояло интегрироваться: познакомились, завели чаты, обсудили точки взаимодействия, посмотрели на роадмапы друг друга.

Что не сработало

Как и в любой истории успеха, у нас есть свой список неудач. Делимся с вами, чтобы быть честными и предостеречь от очевидных проколов.

Во-первых, как это часто бывает, мы слишком много запланировали. Не зная средней производительности команды и не имея четкого понимания бизнес-процесса, мы переоценили свои силы. Справедливости ради, такое бывает и со сработавшейся командой и понятным проектом, но на этапе MVP эту ошибку особенно легко допустить.

Из-за проблемы с оценками сроков нам пришлось отказаться от части фич, которые мы планировали реализовать. Тоже пример из ТОП-5 ошибок при запуске нового проекта, но повторить будет не лишним: отбирайте в первую итерацию только те фичи, без которых не сможете запуститься.

Промахнулись с оценкой сложности интеграции. Мы не учли, насколько трудозатратной может быть интеграция с внешними командами (в нашем случае — с 1С). На этапе планирования мы видели лишь верхушку айсберга. Как этого избежать — тщательнее изучать специфику работы сторонних систем и команд.

Формат документации был выбран неправильно: слишком длинные документы и отсутствие четкой структуры — из-за этого их было сложно читать и поддерживать.

Финальные советы будущим MVP-шникам

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

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

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

Ну и самый классический совет — поделите на два весь скоуп работ, который запланировали. Или закладывайте в два раза больше времени, чем хотели выделить изначально :)

Надеюсь, наш опыт будет полезен и вы сможете научиться на наших ошибках. Может быть, вы воспользуетесь списком приведенных мною практик как чеклистом, если перед вами встанет задача сделать MVP. А возможно, некоторые пункты вы привнесете и в свою ежедневную работу, не обязательно для MVP. Рассказывайте, что у вас получится!