Эволюция процесса разработки стартапа на примере команды Supl.biz

В прошлых публикациях мы делились опытом, как выстраивали в компании отдел продаж, как пробовали выходить на международный рынок, росли и привлекали инвестиции. Сегодня заглянем в историю развития компании с другой стороны – отдела разработки. Знакомьтесь, Олег Красиков – product manager. Олег расскажет, как развивался процесс разработки в Supl.biz. Наш опыт будет особенно полезен разработчикам, которые работают в растущих компаниях и тем, у кого процессы становятся сложнее.

Привет, меня зовут Олег, я из компании Supl.biz. Supl.biz – это электронная торговая площадка для бизнеса. Мы помогаем одной части наших пользователей находить поставщиков необходимых им услуг, а другой – находить новых клиентов. Обычно, поиск поставщиков – достаточно трудоемкая задача, потому что процесс поиска выглядит примерно так: мы ищем их телефоны и начинаем звонить, часто попадаем не туда или к продавцу, у которого очень дорого. На это может уйти большое количество времени. У нас же для создания заказа покупателю необходимо потратить не более 1 минуты, а поставщику товара столько же, чтобы на него ответить. В результате, покупатель может сэкономить, в среднем, до 20% стоимости закупки, а продавец – получить дешевых лидов. За 2018 год на площадке размещено заказов на общую сумму 42 млрд руб.

Нашим сервисом ежемесячно пользуется 150 тысяч компаний России и СНГ, которые размещают 15 000 заказов и в три раза больше предложений в месяц. Чтобы сервис развивался и был доступен пользователям 24 часа в сутки, у нас собственный отдел разработки из 10 человек. В этой статье хочу рассказать, как развивался процесс в отделе, с какими проблемами масштабирования компании столкнулись и как работаем сейчас.

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

Площадка запустилась в 2013 году, с 2015 года начали масштабироваться и взяли в штат двух разработчиков. Настроили CI/CD, тестовый сервер, проект был маленький и отлично работал, даже несмотря на прямые пуши в мастер и отсутствие закрепленного процесса работы с задачей. Процесс разработки представлял собой следующее: CEO добавлял и приоритизировал бэклог в Asana, разработчик брал задачу в работу, делал ее за короткий промежуток времени, пушил на тестовый сервер, проверял, после этого в консоли писали git push и код появлялся на продакшене. Да, иногда сервис падал, но это было не так критично, потому что и пользователей, и сотрудников мало.

К 2016 году в отделе работало 4 человека, а количество задач и зависимостей увеличивалось. Появились руководители отделов, 40 сотрудников, новые проекты и разработчики. В результате, процесс разработки перерос в нечто большее сам по себе.

Задачи в Asana игнорировались. Руководители отдела прибегали в кабинет к разработчикам и давали по задаче раз в 3-4 часа. Формализованные задачи постоянно откладывались, из-за неточных спецификаций часто приходилось переделывать то, что уже сделали, а в коде можно было разобраться только сегодня, через 2-3 дня, чтобы понять, что происходит, нужно было времени больше, чем эта задача делалась.

В апреле 2017 года отсутствие процессов привело к тому, что разработчик в первый рабочий день убил базу, а пуши с текстом “HOT FIX” стали появляться ежедневно. В итоге этого хаоса даунтайм сервисов в день достигал 20-30 минут, было больно и пора что-то менять.

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

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

Сначала начали изучать опыт команд, которые росли, и первое, что сделали, это ввели обязательное правило создания Pull Request’ов перед слиянием ветки в мастер. Как показал изученный опыт, переход к использованию практики слияния feature-branch в стабильные ветки через pull-request неизбежен, будь это исправление бага или внедрение нового функционала.

Сейчас процедура слияния веток через pull request следующая:

• Разработчик вносит новые изменения или правит баги в своей ветке.
• Проверяет работоспособность и корректность поведения кода локально.
• Создает pull request, указывая в качестве source branch свою ветку, а в качестве target branch одну из стабильных веток, например, master.
• Назначает ревьюверов для pull request-а.
• Ревьюверы проверяют код, пишут замечания, и одобряют слияние веток с замечаниями или просят разработчика их исправить.
• При отсутствии замечаний или при наличии незначимых замечаний ревьюверы одобряют pull request.
• При наличии необходимого количества одобрений разработчик вручную сливает свою ветку в ту ветку, которая предназначена для тестирования.
• После прохождения тестирования pull request может быть замерджен в production ветку. Если в ходе тестирования выявлены ошибки, то разработчик исправляет их и, в зависимости от масштаба и значимости, отправляет снова на ревью или сливает в ветку для тестирования.

Главные плюсы введения Pull Request’ов – снижение время даунтайма сервисов. Если раньше приходилось вносить изменения в случае недоступности сервиса на продакшене, то теперь можно быстро, в один клик, откатить изменения и исправить в спокойном, не авральном режиме.

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

• Кто вносил рассматриваемые изменения в код;
• Когда эти изменения сделаны;
• Для какой задачи эти изменения сделаны.

Оформляется commit messages следующим образом:

• 1 строка коммита. Summary изменений в коммите, не больше 80-ти символов в длину. Формат для Summary изменений: <Выполненное действие> <над конкретным объектом>. Примеры: Добавлен перевод на итальянский, изменена модель заказа, исправлен баг импорта товаров;
• Отступ в одну строку;
• Блок с кратким описанием сделанных изменений длинною в 3-4 строки; В этом блоке описывается контекст сделанных изменений: зачем сделано и почему сделано так;
• Отступ в одну строку;
• Сcылка на задачу.

Ссылка на задачу крайне полезная вещь. Иногда нельзя спросить у разработчика, почему сделаны такие изменения. Тогда, открыв задачу по указанной ссылке, становится понятно, почему сделано именно так. А учитывая, что у нас связка Jira + Bitbucket – это оказалось еще удобнее.

Для именования веток используется следующий стандарт: <change-type>/<task-number>-<summary-description>:

• change-type -feature, для внесения нового функционала, bugfix, для исправления найденных ошибок;
• task-number – номер задачи, который присваивается Jira автоматически при создании.
• summary-description – краткое описание на английском, состоящее максимум из 3-4 слов, отображающее изменение.

Jira и Bitbucket позволяют просматривать в задаче в Jira внесенные изменения в репозиторий. Это происходит автоматически, как только ветка с нужным именем попадает в репозиторий. Влияет на этот блок <task-number> в названии ветки. Например, для задачи SUP-104 создается ветка с именем feature/SUP-104-pull-request-bitbucket. После того, как ветка будет создана в репозитории, в задаче появится ссылка на эту ветку.

Также изменили воркфлоу разработки и критерии формирования задачи. Как писал выше, были проблемы со стороны заказчика: неточные спецификации и то, что заказчик напрямую обращался к разработчику. Это порождало еще большие проблемы, так как функционал приходилось несколько раз переделывать.

На уровне руководителей отделов была достигнута договоренность, что задачи разработчикам ставит только один человек. Конечно, изменить образ мыслей руководителей отделов было сложно, после этой договоренности еще 1,5-2 месяца не одна, так другая задача проскакивала напрямую. Приходилось каждый раз обсуждать наши договоренности заново, но в итоге пришли к тому, что в разработку задачи передает только один человек. Конечно, здесь может появиться возражение, что замыкать бизнес-процессы на одном человеке – плохая идея, и некоторые руководители против такого подхода, но, как показала жизнь, этот подход работает и дает спокойствие и понимание, что происходит вокруг.

Сначала идея сотрудника компании попадает в бэклог с названием “Идея!”. Далее, каждая задача приоритизируется и переходит в статус “Исследование”.

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

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

Статусы “Исследование” и “Согласование” также помогают выйти разработчику из зоны комфорта. Предположим, что задача передается напрямую исполнителю. В таком случае, он бы пытался решать задачу так, как уже делал аналогичные решения, что не всегда является оптимальным для продукта. У нас отличные разработчики, которые любят то, что делают, но психологию не победить.

Нужно сразу заметить, что в статус “Исследование” и “Согласование” попадают не все задачи. Просто нет смысла переводить задачу “Изменить текст кнопки” на исследование и согласование.

После этого у задачи ставится статус “Готово к разработке” и она ожидает очереди в приоретизированном бэклоге. Далее идет непосредственная разработка. После того, как задача задеплоена на продакшен, происходит оценка, как наше решение справляется с проблемой, которую обозначили. Выросли ли закладываемые метрики, перестали ли пользователи ошибаться в том или ином случае и т.д. Если цель достигнута, то задача переходит в статус “Готово”, если же нет, то опять отправляем на исследование и начинаем заново, учитывая предыдущий опыт.

Еще нужно отметить, что и сама задача стала оформляться иначе. Раньше это было простое указание к действию, например, “Добавить возможность просмотра заказа”. Теперь же каждая задача идет в контексте проблемы. Сначала формулируется проблема, на основе нее предлагается решение. Это помогает быть в контексте изменений каждому разработчику, а также, часто разработчик может предложить лучшее решение.

Вообще этот процесс – это Design Thinking, которую подстроили под процесс разработки.

Теперь расскажу, как поменялся воркфлоу непосредственной разработки. Добавили 2 новых статуса “Ревью” и “Задеплоено”.

Ревью делается по следующим причинам:

• Ревьюверы могут обнаружить ошибочное поведение в коде, которое может привести к проблемам на production-серверах, что в свою очередь может вызвать потерю данных или замедление/остановку работы других отделов компании.
• Ревьюверы могут предложить более оптимальное решение той или иной задачи, показать/предложить “лучшее” и более качественное решение.
• Ревьюверы могут писать замечания по оформлению кода. Нужно использовать единый корпоративный стандарт, соблюдать pep8, комментировать код и т.д.
• В ходе ревью разработчики видят изменения и, как следствие, видят картину изменений в проекте.
• Ревью позволяет обучаться другим, находя ошибки в своем и чужом коде.
• Нет плохого кода :)

Также появился статус “Задеплоено”. После того, как задача ставится в статус “Задеплоено”, проверяется функционал, который выкатили. Да, есть Sentry, которая логирует происходящие ошибки, пользователи, которые звонят и пишут, но такой отклик на проблему слишком долгий. Поэтому в данном статусе можно легко провести поверхностное тестирование нового функционала и сделать откат изменений. Только если все в порядке, задача переходит в статус “Завершено”.

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

Кроме того, есть legacy код, которому 3-5 лет. Как только поддержка кода, а также разработка нового функционала становится дороже, чем рефакторинг, сразу же делаем это. Ну ладно, не сразу же, но делаем :)

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