Заказная веб-разработка: как масштабироваться на постоянно растущем проекте

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

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

Рост проекта и сопутствующие сложности

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

Вот основные вызовы, с которыми может столкнуться агентство на таком проекте:

• Проблема масштабирования — перестроение структуры команды при росте объёмов.
• Необходимость понимания продукта и бизнес-задач — без сильной продуктовой аналитики невозможно эффективно работать на крупном проекте.
• Сложная программная и серверная архитектура — рука об руку с ростом объёмов выработки по проекту идёт и рост посещаемости, ведущий к усложнению архитектуры и необходимости использовать highload-решения.
• Высокие требования к качеству.
• Необходимость обеспечивать бесперебойную работу 24×7 и высокая скорость реакции на инциденты в том числе в неурочное время.
• Высокая степень ответственности за остановку продаж.
• Мониторинг и контроль бизнес-показателей.

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

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

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

Роли на небольшом проекте и зачем нужно масштабирование

Схема ролей выглядит в общем случае следующим образом: 

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

Вот так выглядит типовая схема ролей внутри проектной группы на небольшом проекте: 

На проекте две ключевых роли: руководитель проекта (РП) и тимлид.

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

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

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

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

Возникает необходимость в разделении и дублировании обязанностей сотрудников, и стандартная схема ролей расширяется и усложняется.

Структура менеджерской команды

Одна из самых сложных для масштабирования единиц — РП.

По мере роста проекта имеет смысл внедрять классическую парную схему account manager — project manager, когда один РП берёт на себя клиентский сервис, включая продуктовые вопросы, а второй организует процесс производства внутри компании. 

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

Поэтому идеальная с точки зрения дальнейшей масштабируемости схема выглядит следующим образом:

Group Head (GH) руководит менеджерским составом на проекте и отвечает за контроль бюджетов, рентабельность, формирование команды (как менеджерской, так и непосредственных исполнителей) и распределение ресурсов, решает стратегические вопросы проектного управления. Также он проводит продуктовый контроль и следит за отсутствием конфликтов в параллельных процессах. Он не тратит время на оперативную деятельность и контроль исполнения каждой конкретной задачи.

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

При необходимости подключается дополнительная роль Product owner, которой GH делегирует часть продуктовых обязанностей. Чаще всего этот сотрудник базируется на стороне клиента и ретранслирует все пожелания бизнеса в виде формализованных задач на выполнение.

Каждый РП в команде отвечает за свой «кусок» проекта, беря под контроль все текущие задачи по ряду продуктов (в идеале это должны быть смежные области). В зону его ответственности входят сроки и качество всех задач в рамках развития подотчётных продуктов.

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

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

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

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

• За 10 рабочих дней до начала месяца каждый РП сам выделяет от трех до пяти своих ключевых задач на следующий месяц.
• За 5 рабочих дней до начала месяца GH выделяет из них по две—четыре для каждого менеджера и выставляет сроки: 1 — клиентский срок (50%), 2 — внутренний срок (100%) и вносит в таблицу.

Условия получения бонусов (по итогам месяца):

• Менеджер получает 100% бонусов, если все его задачи выполнены во внутренний срок.
• Менеджер получает 50% бонусов, если хотя бы одна его задача уехала из внутреннего срока, но была выполнена в клиентский срок.
• Ни один из менеджеров не получает бонусы, если хотя бы одна задача из общего списка не была выполнена в клиентский срок.

Данная схема позволяет всей менеджерской команде работать эффективно и корректно управлять ожиданиями клиента.

Тестировать не только конечный код — QA-команда

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

Чтобы избежать подобной ситуации, мы пришли к идее создания полноценной QA-команды на базе команды тестирования. Основное отличие заключается в том, что тестирование проводится не только на этапе разработки-отладки-релиза, но на всех стадиях проекта:

• QA отвечают за качество продукта и его стилевое и логическое соответствие другим продуктам и в целом принятым на проекте правилам.
• QA отсматривают все артефакты, появляющиеся на проекте: первичную формализацию задачи, прототипы, спецификации, дизайн, и, конечно, тестируют код и вёрстку, пишут тест-кейсы, покрывают имеющийся и новый функционал сеткой автотестов.
• Без валидации материалов QA-командой РП не имеет права запустить в работу следующий этап или направить материалы на приёмку заказчику.

Подобный подход позволяет сильно снизить риски затянутой отладки и сдвига сроков релиза.

Тимлиды — эффективность или взаимозаменяемость?

Уже при вводе второго тимлида на проект сразу же всплывает вопрос — какую схему распределения обязанностей применить?

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

Оба варианта хороши с точки зрения утилизации ресурсов, но несут большие риски с точки зрения взаимозаменяемости. 

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

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

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

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

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

Взаимозаменяемость членов команды

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

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

Дизайн-система 

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

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

Использование такого инструментария требует большой траты ресурсов на разработку и поддержку. Также зачастую много моральных сил уходит на объяснения клиенту, почему необходимо придерживаться этой системы и по какой причине предложения вроде «Добавьте на этой странице новую зелёную кнопочку, как на сайте N, которая так красиво выглядит» будут отвергнуты. 

Документация

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

Документацию на проектах имеет смысл разделять на 4 типа:

• Интерфейсные спецификации — описание поведения реализованного функционала (логика работы, валидация полей, набор экранов).
• Тест-кейсы (описание пользовательских сценариев и результатов их прохождения), на их основании по необходимости разрабатываются автотесты.
• Сервисные спецификации (описание взаимодействия с веб-сервисами, тестовые данные, примеры запросов-ответов).
• Документация кода (описание компонентов, классов и их иерархии, шаблонов).

Вся документация должна быть агрегирована в базе знаний онлайн (Wiki) и поддерживаться в актуальном виде.

GIT

Для ускорения подключения новых разработчиков с других проектов компании внедряется стандартный подход к GitFlow. В AGIMA мы используем подход «работа с двумя основными ветками». 

Вместо использования ветки master применяются две основные ветки истории проекта: master для релизов и develop для слияния разрабатываемого функционала из веток feature.

Workflow

Ещё один инструмент, регламентирующий и стандартизирующий работу всех членов команды — workflow по дням недели.

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

В workflow непременно должен быть вовлечён и клиент — в одностороннем порядке такая система работать не может.

Не менее важен workflow по статусам задач, упрощающий переход сотрудников между проектами. Он должен быть идентичен на всех проектах компании. В AGIMA он выглядит следующим образом:

Поддержание осведомлённости членов команды

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

1. Продуктовые встречи

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

2. Инфраструктурные срезы

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

3. Ретроспективы и планирование работ

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

Выводы

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

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