Как управлять гигантами: Правила формирования команды и построения процессов

В России больше 5000 компаний занимаются заказной веб-разработкой (по данным аналитического агентства Тэглайн), однако, по моему мнению, наш рынок до сих пор находится в стадии своего зарождения. Многие digital-компании, веб-студии и интеграторы в реальности не готовы к качественному развитию и поддержке действительно крупных проектов. К нам в AGIMA часто обращаются компании, недовольные качеством выполнения работ своим текущим подрядчиком, которого они выбрали на тендере. За много лет работы с крупнейшими российскими компаниями у нас накопился огромный опыт в организации процессов разработки и развития крупных интернет-проектов, и я хочу им поделиться. В этой статье я расскажу, как правильно организовать инфраструктуру, выстроить коммуникации между командами и не забыть о важных составляющих агентского сервиса при работе с «гигантами».

Что я считаю крупным проектом? Если на проекте вырабатывается суммарно более 2500 человеко-часов в месяц всей проектной командой, не считая работы менеджера. По составу работ это, как правило, 2-3 крупных задачи по 800-1000 человеко-часов параллельно и 5-6 мелких ежедневных задачек в рамках определённых абонементов по техподдержке. Это могут быть сайты крупных страховых компаний, банков, большие интернет-магазины, корпоративные порталы, HR-порталы и СМИ.

Что вас ждет в статье:

Мануал по требованиям к организации команды и процессов при разработке, развитии и поддержке больших проектов. В основе – 10-ти летний опыт работы на рынке заказной веб-разработки. За это время я смог запустить более 100 проектов. Последние два года я управлял разработкой и поддержкой проектов компании «АльфаСтрахование».

На кого рассчитана статья:

Статья будет интересна руководителям проектов и всем, кто так или иначе относится к организации процессов разработки веб-приложений и взаимодействия с клиентом.

Дисклеймер:

Данная статья не является панацеей, а лишь сугубо личным мнением автора.

Поздравляю, у вас — крупный проект!

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

Например, один из наших самых первых «гигантских» проектов вырос из маленьких технических доработок по требованиям от seo’шников. В какой-то момент клиент сказал: «Мы хотим запустить новую версию сайта, почти всё готово, но наш текущий подрядчик никак не может его доделать. Нам понравилось, как вы оперативно делаете доработки. Давайте вы его доделаете и запустите?». Мы столкнулись с тем, что заполучили контракт, но у нас не было инфраструктуры и выстроенных процессов для проектов такого уровня. Что же делать?

КОМАНДА

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

Первая линия

Крупный проект — это всегда множество коммуникаций (в нашем случае на стороне клиента было более 3-х менеджеров, отвечающих за те или иные типы задач), поэтому нам пришлось создать единую точку входа. На тот момент проектом руководил один менеджер, и он не мог справиться с рухнувшим на него потоком запросов оценок, задач, вопросов и багов. Когда мы попробовали затащить всех ответственных лиц в свой таск-менеджер, мы сразу же столкнулись с огромным количеством дублей и отвратительной проработкой задач (некоторые из них могли противоречить друг другу, так как были от разных подразделений бизнеса, но по общим страницам: главная, новости и т.п.). Тогда мы решили попробовать достаточно простую вещь — ввели роль администратора проекта. Это обезличенный e-mail адрес «Техподдержки», на который приходят все запросы от менеджеров клиента в рамках одного проекта, обрабатывать его могут несколько выделенных сотрудников.

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

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

Руководитель проекта

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

Мы зафиксировали прозрачные KPI, в том числе PM должен следить за эффективностью первой линии и за выполнением SLA, а также нести ответственность за рентабельность проекта и четкую постановку задач. Если первоначальная задача меняется, он должен обосновать и отстоять изменения стоимости и сроков по каждой дополнительной подзадаче. В случае споров слова необходимо подтверждать фактами, поэтому все обсуждения необходимо фиксировать документально или как минимум в письменном виде, например в почте.

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

Тимлид

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

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

Product owner

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

Скамейка запасных: подключаемые специалисты

Кроме основных специалистов (дизайнеров, верстальщиков, программистов, тестировщиков), часто на крупные проекты нужны дополнительные ресурсы.

На наших крупных проектах чаще всего необходимы:

• Архитектор

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

Любая новая задача на этапе проектирования у нас также проходит через архитектора и product owner’а.

• Аналитик

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

• Проектировщик

Это тот человек, который продумывает логику работы и взаимодействия интерфейсов. Кроме прототипов, мы всегда разрабатываем пояснительную документацию (спецификацию) на прототипы. Благодаря этому сокращаются дополнительные затраты на этапе дизайна и вёрстки, а также облегчается авторский надзор за проектом со стороны проектировщика и руководителя проекта.
Для рефакторинга функционала со сложными интеграциями мы привлекаем проектировщика в тандеме с тимлидом. Это позволяет оптимизировать текущую интеграционную схему, выявить все недостатки и дать рекомендации по их устранению.
Таким образом разрабатывается документ под названием «Сервисный анализ», где всё подробно описывается.

• UX

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

Инструментарий наших UX-специалистов:

• юзабилити-тестирование;
• опрос;
• прямая и обратная карточная сортировка;
• дневниковое исследование;
• анализ обратной связи;
• семантический и сентимент-анализ текстов.

Ресурсы вне штата

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

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

ПРОЦЕССЫ

Методология

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

Рабочие процессы

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

К слову о правильном планировании ресурсов — мы во всех расчётах в оценках и планировании зафиксировали, что рабочий день исполнителя — это 6 часов, а не 8. Кроме того, необходимо заранее закладывать время на аварии и баги, причем зачастую поиск и анализ бага занимают 90% времени, а исправление – всего 10%. Для ускорения баг-фиксинга мы разделили ресурсы: техподдержкой и продакшеном у нас занимаются разные технические команды, точки пересечения – только менеджмент и тимлиды.

Тестирование и QA

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

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

Автоматизированное тестирование в рамках CI (git flow)

Сколько бы мы ни тестировали, ошибки все равно были, есть и будут. Мы задались вопросом — как минимизировать время на анализ багов и оперативно реагировать на аварии?

Эффективно эту задачу смог решить мониторинг доступности и функциональной бесперебойности. Мы разработали специальный событийный виджет, который агрегирует в себе данные в разрезе каждого из критического списка url’ов по бесперебойности (данные берутся из собственной системы мониторинга zabbix и двух внешних независимых сервисов мониторинга) и данные по функциональной доступности (из нашего билд-сервера TeamCity). При возникновении проблем с доступностью или функциональных ошибок срабатывает система оповещения: все ответственные лица получают письмо на e-mail, sms и звонок на мобильный телефон. Таким образом, время реагирования на любой простой у нас не более 15 минут.

Мы взяли за правило осуществлять прогон функциональных тестов по списку критических url:

• Ежедневный прогон в автоматическом режиме по расписанию (9:00 и 18:00).
• Прогон на dev-площадке специалиста перед пушем (разработка ведется в feature-ветках, на каждую строго выделена своя площадка). При коммите отрабатывают хуки, которые запускают код-ревью и юнит-тесты. При успешном завершении тестов ветка разработки автоматически сливается со стабильной develop-веткой и актуализирует ее. Далее начинается автоматизированное функциональное тестирование пользовательских сценариев. Перед этим скрипт также подготавливает окружение: принудительно очищает кэш, минифицирует необходимые файлы и запускает инсталляторы, если изменения коснулись изменений в БД. По итогам тестирования формируется отчет, доступный всем заинтересованным лицам (разработчики, менеджеры, тестировщики) и отправляется уведомление на почту со статусом прохождения тестов.
• Прогон на стейдже (почти полный дубль продуктивного сервера) и на бою, после релиза сборки.

Гайдлайны

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

У нас есть гайдлайны и для программистов (пример). Это документация, описание классов и методов, механизмов интеграции и т.д. Всю эту полезную информацию мы агрегируем и храним в нашей базе знаний (используем confluence) — за актуализацию информации отвечают руководители проектов.

Важно учитывать грамотную архитектуру, которая потребует минимум «костылей»
на этапе доработки и развития функционала. При оформлении кода мы придерживаемся стандартов PSR-1 и PSR-2. Это позволяет сократить время при переключении и передаче задач между разработчиками и тимлидами. Те, кто работает в IDE, к примеру в PHPStorm, могут настроить автоматическую проверку соблюдения стандартов. Мы же у себя внедрили автоматизированную проверку кода на стороне back-end сервера при помощи phpSniffer.

Также при разработке архитектуры мы всегда учитываем требования к информационной безопасности: контроль целостности кода, соответствие ФЗ-152, отсутствие уязвимостей xss и sql-инъекций и соответствие требованиям TOP-10 OWASP.

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

P.S. В следующей статье из данного цикла мы детально рассмотрим инструментарий для руководителей проектов, который помогает структурировать и оптимизировать планирование и организацию процессов на проекте.

ссылка на оригинал статьи https://megamozg.ru/post/25658/