Эволюция эффективности: SCRUM vs традиционный подход

Почему SCRUM не приживается? Главное препятствие - не люди, а структура

Waterfall -> Agile: Куда деть начальников отделов <- мы здесь

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

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

И, конечно, состав участников может варьироваться под влиянием выполняемых задач. Например, к 3-м backend-разработчикам потребуется, скажем, 1 frontend на какой-то период или постоянно.

Куда деть начальников отделов?

Если вы работаете по «водопаду» и вдруг решили, что пора бы переходить на Agile рельсы, то этот вопрос всплывет одним из первых.

Если вспомнить схемы из прошлой статьи, то вместо одного Начальника Департамента в Agile у нас появляется 2: Tech Lead и Product Owner на уровне команд и такая же пара на уровне стрима. Давайте определим разницу между руководящими функциями в водопаде и Agile. Ну и зачем вообще плодить руководителей?

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

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

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

Но главная беда этой модели – внутренний конфликт интересов. Бизнес-цели и технические цели часто противоречат друг другу. Бизнес говорит: «Нам нужна эта фича к пятнице, сроки горят!». Разработка говорит: «По-нормальному тут работы на две недели. Если гнать к пятнице, придется городить жесткие костыли и тестировать впопыхах. В итоге получим кучу багов на проде и техдолг, который будем разгребать месяцами».

Что делает классический начальник отдела? Этот конфликт происходит внутри его головы. Ему нужно усидеть на двух стульях. И, как правило, он жертвует техническим качеством ради бизнес-дедлайна, накапливая гигантский технический долг, за который компания потом расплачивается миллионами.

Agile решает эту проблему, забирая власть у одного и разделяя на 2 независимые роли (на самом деле на 3, чуть дальше разберем). Создается что-то вроде системы сдержек и противовесов. Выглядит все примерно так:

Product Owner

Метрики: Деньги, конверсии, удовлетворенность клиента

Функции: Управление бэклогом. Решает, ЧТО команда будет делать сейчас, а что потом

Ограничения: Не погружается в техническую часть реализации задачи

Tech Lead

Метрики: Отказоустойчивость, скорость работы системы, качество кода, текучка кадров

Функции:

Декомпозиция (вместе с командой) бизнес-задачи от Product Owner
Проработка технического решения с командой
Проведение Code Review, помощь джунам и мидлам, если они застряли. Следит, чтобы фронтенд и бэкенд нормально состыковались и пр.
30–80% времени он сам пишет код или проектирует систему своими руками

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

Если кратко, то Product Owner – это педаль газа. Он всегда будет давить на скорость и требовать новые фичи побыстрей. Tech Lead – это педаль тормоза. Он всегда будет требовать время на рефакторинг и качество.

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

Теперь к делу. Куда деваться начальнику из водопада при переходе в Agile? Чтобы сделать правильный выбор, нужно отмотать время назад и посмотреть на его корневую компетенцию. Ведь никто не рождается начальником – все когда-то начинали с работы линейным специалистом. Как правило, до начальника департамента дорастают выходцы из разработки и аналитики (чуть реже – сильные QA-лиды). И именно этот изначальный бэкграунд определит вектор для развития в Agile.

Начальник департамента из аналитики -> Chief Product Owner

Начальник департамента из разработки -> Stream Tech Lead

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

Начальник департамента -> Stream Tech Lead

Начальник отдела аналитики -> Chief Product Owner

Начальник департамента -> Chief Product Owner

Начальник отдела разработки -> Stream Tech Lead

Куда расти линейным специалистам

Теперь что касается оставшихся начальников отделов. В водопаде у нас было 3 отдела и всего 3 руководящих кресла. В Agile вместо них появляется N-ое количество команд. Понятно, что позиции Tech Lead и Product Owner в первых командах займут бывшие начальники разработки и аналитики соответственно. Но команд-то много! И, самое главное, это значит, что линейные сотрудники с сильной экспертизой тоже могут занять эти лидерские роли. По-моему, это прекрасная ветка для карьерного роста, которая убирает старый стеклянный потолок.

Архитекторы в Agile: экспертиза без административной рутины и альтернатива уходу в менеджмент

Отдельно стоит сказать про Архитекторов. В классическом водопаде я редко встречала эту роль как самостоятельную. Обычно архитектуру тянул на себе всё тот же Начальник департамента (если он выходец из разработки) или Начальник отдела разработки. Техническая экспертиза была жестко склеена с административной властью. Руководителю приходилось разрываться: он должен был и глобальные технические решения принимать, и бюджеты с отпусками согласовывать.

Однако с усложнением ИТ-систем, особенно с массовым переходом компаний на микросервисную архитектуру, совмещать эти функции стало физически невозможно. В Agile эту склейку наконец-то разрывают, потому что управлять людьми и проектировать такие сложные (распределенные) системы – это две совершенно разные профессии. Появляется выделенная роль Архитектора. Такой специалист смотрит на систему сверху и отвечает за то, чтобы независимые команды двигались в едином русле, а не создали набор разрозненных кусков, которые потом невозможно будет состыковать. И главное – он избавлен от менеджерской рутины. Ему больше не нужно быть административным начальником, чтобы его техническое слово имело реальный вес.

К тому же, здесь стоит добавить важное наблюдение из личного опыта. В классических водопадных структурах исторически существовала только одна ветка карьерного роста – управленческая. Я не раз видела, как из-за этого компании теряли прекрасных технических специалистов. Человек хотел повышения, хотел расти в должности и доходе, но совершенно не хотел становиться Начальником отдела или Менеджером проектов (ведь при классическом проектном подходе именно переход в менеджеры проектов или руководители считался венцом карьеры). А так как альтернатив для технического роста просто не было, хорошим специалистам приходилось уходить в другие компании.

Появление роли Архитектора (и в целом разделение ролей в Agile) решает эту проблему. Оно создает полноценную параллельную ветку развития – техническую. Теперь сильный специалист может получить признание, высокую должность и статус, оставаясь в технологиях и не ломая себя переходом в менеджмент.

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

Калибровка оргструктуры: продуктовая разработка vs аутсорс

Здесь стоит сделать важную оговорку и откалибровать оргструктуру в зависимости от бизнес-модели. Роль Product Owner-а не всегда находится внутри компании-разработчика. То, где сидят Product Owner и Архитектор, напрямую зависит от того, как компания зарабатывает деньги.

Модель 1. Долгосрочная заказная разработка

Если компания-исполнитель годами работает с крупным постоянным заказчиком, структура адаптируется под клиента. В этом случае на стороне заказчика формируется собственный IT-департамент, в штате которого и находятся Продакты и Архитекторы. Они глубоко интегрируются в процессы исполнителя: Product Owner от заказчика участвует в daily-standup команд, управляет бэклогом и обсуждает задачи напрямую с исполнителями. А Архитекторы заказчика рассматривают и согласовывают технические решения, которые предлагают команды подрядчика. Вектор бизнеса в этом случае полностью находится на стороне клиента.

Модель 2. Собственный продукт или проектная разработка

Схемы оргструктуры текущей статьи описывают модель, когда компания выпускает свой собственный продукт и все идеи генерируются внутри. Или, когда компания работает по модели проектной разработки, где заказчики меняются достаточно часто и не погружаются в процессы глубоко (классический пример – госзакупки). В таких бизнес-моделях позиция Product Owner остается строго внутри компании-разработчика. Именно внутренний специалист берет на себя ответственность за генерацию ценности, сбор требований и управление командой.

«Долина несбывшихся грез»: как Chapter Lead превращается в высокооплачиваемого HR

Осталось рассмотреть еще одну важнейшую роль – Chapter Lead (Лидер компетенции). В классическом водопаде эти функции выполнял Начальник отдела. Помимо распределения ежедневных задач и контроля дедлайнов, на нем висел весь кадровый блок: он должен был проводить собеседования, адаптировать новичков, разбирать конфликты, писать регламенты, оценивать качество работы, выбивать бюджеты на обучение и решать, кому повысить грейд, а кого уволить. Понятно, что в условиях вечно горящих проектов на системную работу с людьми у начальника времени почти не оставалось.

В Agile-структуре под эти задачи выделяется отдельная сущность – Chapter Lead. За счет того, что он не управляет бизнес-бэклогом (этим занимается Product Owner) и технической поставкой (этим занимается Tech Lead), работа с сотрудниками и стандартами выходит на принципиально новый уровень.

Например, регулярные встречи 1-to-1 (один на один) из формальной «галочки» раз в полгода превращаются в реальный рабочий инструмент. Chapter Lead может сфокусироваться на том, чтобы составить матрицу компетенций, оценить навыки каждого аналитика или тестировщика, прописать индивидуальный план развития и предметно менторить специалистов, помогая им расти.

Сюда же добавляется очень важный процесс – онбординг новичков. В классической схеме адаптация нового сотрудника обычно ложилась на плечи перегруженного начальника или какого-то сотрудника из отдела, отвлекая его от задач. Теперь Chapter Lead забирает этот процесс на себя. Он выстраивает систему адаптации, проводит человека по принятым стандартам, знакомит с базой знаний и плавно интегрирует его в команду. Это колоссально разгружает и команды, и руководство.

Однако на практике с этой ролью в компаниях случается кризис. Приведу пример, который я наблюдала не раз. Сильные руководители отделов аналитики при переходе на Agile получают звучные должности «Заместителей директора», а по факту – становятся Chapter Lead. Им не объясняют, чего от них ждут. В итоге начинается жесткая фрустрация.

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

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

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

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

Фрустрация проходит, как только приходит понимание: Chapter Lead больше не управляет задачами. Он управляет средой. Как только фокус смещается с ручного контроля на архитектуру процессов и развитие людей, расписание Chapter Lead забивается на 100%, а на смену фрустрации приходит понимание своей реальной ценности.

Итак, функции Chapter Lead

Добавим их на оргструктуру, кстати.

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

Для Chapter Lead аналитиков, фокус на следующем:

Создание единых стандартов и шаблонов. Чтобы аналитики во всех командах одинаково писали ТЗ и использовали единые нотации (UML/BPMN), а в корпоративной базе знаний была выстроена иерархия страниц по строго единой логике. Иначе на практике одна команда строит структуру так, другая эдак, и в итоге на уровне компании (продукта) единой системы просто нет, а поиск чужого ТЗ превращается в квест.
Проведение регулярных 1-to-1, составление матрицы компетенций и планов развития сотрудников.
Организация регулярных общих встреч аналитиков. Чтобы специалистам из разных команд было где обсудить сложные доменные кейсы, разобрать ошибки и просто обменяться новостями и опытом.

Для Chapter Lead тестирования (QA), фокус на следующем:

Сдвиг подготовки на ранние этапы. На практике формирование тест-кейсов и приемо-сдаточной документации часто выполняют после проверки функционала. Это приводит к критической перегрузке QA-специалистов перед релизом и создает риски переноса сроков. Зачастую команды решают эту проблему самостоятельно, в этом случае задача Chapter Lead – закрепить этот подход как единый стандарт, при котором подготовка начинается сразу после согласования аналитики. Написание тест-кейсов по ТЗ и сборка документации идут параллельно с разработкой. К моменту передачи кода на проверку сценарии проверок уже сформированы.
Выбор единых инструментов для тест-кейсов и автоматизации на уровне всей компании, чтобы при ротации между командами специалисты работали в привычной и понятной инфраструктуре.
Обучение и менторство: помощь «ручным» тестировщикам в освоении автотестов, проведение 1-to-1, онбординг новичков и составление планов развития.
Организация регулярных встреч тестировщиков (QA-синков) для обмена опытом, разбора пропущенных на прод багов и внедрения новых практик.

Chapter Lead в разработке

Если должность Chapter Lead для аналитиков и QA на рынке встречается часто, то для разработчиков все чуть сложнее. Выделить Chapter Lead для всей разработки не получится, т.к. она слишком разнородна – невозможно быть лидом сразу для фронтенда, бэкенда и мобильной разработки. Поэтому в разработке эту сущность дробят по стекам, но суть и функции абсолютно те же:

Стек и стандарты: Определение разрешенных технологий, внедрение единых правил Code Review и пайплайнов (CI/CD).
Найм и 1-to-1: Проведение технических собеседований для своего стека, составление планов развития для сотрудников, онбординг.
Синхронизация: Сбор разработчиков своего стека из разных команд для обсуждения общих архитектурных или инфраструктурных проблем.

Два формата работы: выделенный руководитель и играющий тренер

Здесь важно отметить, что роль Chapter Lead в Agile может существовать в двух принципиально разных форматах:

Отдельно стоящая фигура. Это 100% выделенный руководитель компетенции. Такой формат оправдан только в крупных стримах или на уровне всей компании, где профильных специалистов (например, аналитиков) 15-20 и более человек, либо сам стрим или компания находится в стадии активного найма и масштабной стандартизации. Если людей мало, выделенный Chapter Lead быстро скатится в ту самую «долину несбывшихся грез» от нехватки задач.
Играющий тренер. Это самый здоровый и распространенный формат на рынке. Chapter Lead является полноценным участником одной из команд (как обычный Senior-аналитик). Примерно 70-80% своего времени он работает руками, а 20-30% времени он выделяет на функции Chapter Lead для всего остального стрима.

Третья ось власти: Chapter Lead как «адвокат» людей

В начале статьи я упомянула, что власть начальника из «водопада» расщепляется на три независимые роли. Если Product Owner – это бизнес, а Tech Lead – разработка, то Chapter Lead – это голос (и щит) людей.

Chapter Lead выступает в роли корпоративного адвоката для своих специалистов. И это не просто красивые слова про заботу, это жесткая защита сотрудников от несправедливых обвинений и поиска «козлов отпущения».

Приведу пример из своей практики. Однажды на статус-встрече я довольно неаккуратно сформулировала причину переноса релиза. Я сказала, что сроки сдвигаются, потому что «тестирование не успевает проверить весь функционал». После этого митинга Лид тестирования (QA Chapter Lead) буквально взял меня за жабры. Он воспринял мою фразу как попытку сделать его тестировщиков крайними за срыв сроков.

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

Он жестко вступился за своих людей, дав понять, что не позволит перекладывать на них ответственность за огрехи всего конвейера. И с точки зрения системы – это правильно. В классическом водопаде менеджер легко мог «назначить» виноватым того, кто сидит в самом конце цепочки (а это традиционно тестировщики). В Agile наличие сильного Chapter Lead-а балансирует систему. Он защищает своих специалистов от токсичного прессинга, выгорания и перекладывания ответственности. Он следит за тем, чтобы с его людьми обращались уважительно и оценивали их работу объективно.

Заключение и что дальше

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

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

А потом я попала в Scrum-команду в американской компании. И у меня случился шок. Я увидела, что система сама, за счет своих процессов, контролирует сроки. А эмоциональная атмосфера в команде разительно отличается от душной иерархии обычного отдела. Я подумала: «Вот оно!». Оказалось, что для контроля над ситуацией больше не нужно быть начальником. Можно спокойно развивать хард-скиллы. После 15 лет менеджерства я с облегчением пошла по этому пути, прочно обосновавшись в системном анализе.

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

Но нет. Не сработало.

Да, часть Agile-команд в российских компаниях действительно были прекрасны (особенно те, которые я создавала с нуля и вела сама :D ). Но часть оказались кромешным ужасом. Работать в них было невозможно, а уровень токсичности зашкаливал так, что система казалась хуже любого водопада.

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