Ответственность Team Leads
Привет, друзья.
В данной статье мы разберем распределение ответственности в больших командах. Представьте себе ситуацию, что вы руководитель, в подчинении которого находится от двух до N потоков разработки, но вся эта разработка — одно большое приложение либо одна большая система, а каждый поток занимается своим модулем или своей частью модуля. Важно, чтобы потоки разработки почти не пересекались по функционалу, хотя использовать код соседей они вполне могут.
Итак, наша задача создать такую организационную структуру, при которой у вас, как у руководителя, будет максимальная вероятность успеха. Очевидно, что успех проекта зависит далеко не только от организационной структуры. В то же время правильная org. structure — одна из составляющих этого успеха.
Прежде чем мы с вами погрузимся в «кто, кому, что и когда» должен предоставлять, отчитываться и как будут организованы коммуникационные потоки, рассмотрим «классику жанра» — очень частое распределение и назначение зон ответственности, встречаемое в большом количестве проектов. Выглядит оно обычно как на рисунке ниже (Java и Oracle взяты для примера, вместо них могут быть совершенно любые другие технологии): 
Названия должностей могут, конечно, отличаться.
Иногда встречаются очень своеобразные комбинации, вроде такой: 
Уверен, многие из вас сталкивались с такими структурами, а, возможно, вы прямо сейчас работаете в одной из подобных. Все ли в них хорошо? Выполняют ли они свою функцию и помогают ли нам, как руководителям, быстрее, эффективнее, с минимально возможными затратами ресурсов приходить к успеху проекта? Если вы еще не руководитель, но планируете им стать, вам наверняка тоже интересно, почему такие структуры неэффективны и где именно ошибка.
Рассмотрим примеры выше.
Какая цель у руководителя проектов, программ, департамента? Помимо зарабатывания денег (зависит от уровня должности) цель только одна — сделать продукт вовремя, в рамках выделенного бюджета и с согласованным объемом и уровнем функционала и качества.
Теперь посмотрите на диаграммы выше. Позволят ли они сделать, скажем, релиз, вовремя и с нужным объемом функционала, да еще и при условленном уровне качества? Сильно сомневаюсь. Почему у меня есть сомнения? Причин несколько.
В первую очередь сомнения вызывает размытая зона ответственности. Вот скажите, кто на диаграммах выше отвечает за сроки, scope и качества релиза/проекта/продукта? В итоге, за все-все отвечает тот, кто на самом верху. И это верно. А если ниже? Отвечает ли Team Lead за релиз? А хотя бы за один ticket в JIRA (либо в любой другой системе трекинга задач)? Глядя на эти две схемы выше — нет, определенно не отвечает.
Второй момент в плане сомнений — это перекидывание мяча между тим-лидами. К примеру, аналитики завершили требования и передали их в разработку (Analyst Lead → Dev Lead). У разработчиков возникли уточняющие вопросы и они вернули требования аналитикам на доработку (Dev Lead → Analyst Lead). Те доработали и снова передали разработчикам (Analyst Lead → Dev Lead). И снова возникли вопросы (Dev Lead → Analyst Lead). Так может долго продолжаться. Но допустим, через какое-то время разработка таки началась (я намеренно упрощаю схему, исключив переброску мяча между разными подразделениями разработчиков, таких как у нас на схеме: Java Lead <-> Oracle Lead). Параллельно с началом разработки тестировщики взялись писать тест-кейсы. В момент окончания разработки происходит передача кода в тестирование (Dev Lead → QA Lead). Обнаруживаются баги (QA Lead → Dev Lead). Баги чинятся и код снова передается тестировщикам (Dev Lead → QA Lead). И так по кругу.
Если в какой-то момент этого бесконечного круга руководителю захочется узнать статус релиза, скажем, процент готовности, то окажется, что релиз (наш код) готов на 90%. А на вопрос, почему же сроки вот-вот будут сорваны, последует закономерное отсутствие ответа, ведь никто не виноват. Тестировщики действительно честно тестируют. А разработчики действительно честно исправляют все найденные баги. Все действительно хотят выпустить в жизнь хороший продукт. Но мяч постоянно перебрасывается между разработчиками и тестировщиками, и конца этому не видно. Совершенно такая же ситуация будет между любыми другими подразделениями (аналитики — разработчики, разработчики — разработчики).
А главное — никто ни за что не отвечает кроме самого высокого руководителя, выступающего арбитром или координатором между одной группой и другой. А арбитром он выступать не может по очень простой причине — невозможно быть в курсе такого количества потоков разработки и задач. Если бы было можно — структура была бы совсем другой и тим-лиды были бы просто не нужны — остался бы один самый главный менеджер и обычные аналитики + разработчики + тестировщики. Но жизнь говорит нам, что так еще хуже. А значит проблему надо решать. Ключевая проблема находится в зонах ответственности. И именно это мы и обсудим дальше.
Итак, нам необходимо сделать так, чтобы Team Lead стал действительно лидером команды (а ведь именно так переводится название этой должности). Ведь в примерах выше он был кем угодно, но не тем, кем должен быть. Он был Development Lead«ом, QA Lead«ом, Analyst Lead«ом, Java Lead«ом и т.п. И отвечал не за полный жизненный цикл задачи от разработки спецификации к ней, через разработку, до этапа сдачи после успешного тестирования с багфиксингом, а только за какой-то из кусочков всего этого жизненного цикла SDLC (Software Development Life Cycle). Наша же задача, чтобы Team Lead отвечал за весь SDLC по задаче — только тогда у него будет возможность обеспечить поставку этой задачи вовремя, с нужным объемом функционала и с нужным уровнем качества. Стоимость на уровне Team Lead«а обычно не рассматривается, разве что в неких условных единицах, вроде WU (Work Unit = 1 человеко-день) или каких-то подобных единицах.
Не забываем, что для того, чтобы человек мог за что-то отвечать у него должна быть одна важная составляющая — полномочия. Т.е. ответственность и полномочия — две неотделимых друг от друга компоненты. Если у вас есть полномочия, но нет ответственности — беда для проекта и мы все видим на примере многих стран, к чему это ведет и чем заканчивается. Если у вас есть ответственность, но нет полномочий — еще большая беда, но только уже для вас, т.к. вы являетесь всего лишь козлом отпущения, на которого свалят провал. А провал точно будет, ведь вы не можете ни на что повлиять. Вариант, когда у вас нет ни полномочий, ни ответственности, я даже не рассматриваю, ибо в этом случае вы вообще не Lead. И только в случае, когда у вас есть и полномочия и ответственность, вы можете влиять на ситуацию и нести за это ответственность, равно как получать награды за успех.
Ниже находится схема, иллюстрирующая взаимоотношение Полномочия-Ответственность: 
Давайте определимся, какие же обязанности могут быть (бывают) у Team Lead«а. Вот они:
1. Отвечает за JIRA tickets
2. Является владельцем ресурсов (его подчиненные)
3. Имеет некий список обязанностей в рамках конкретной команды/тикета/релиза (допустим, reporting делается неким специальным образом)
4. Отвечает за качество
5. Владелец знаний
6. Имеет некие обязанности в рамках компетенции (скажем, является Senior разработчиком на Oracle и должен часть своего времени посвящать разработке)
Эти 6 пунктов очень удобно делятся на две большие секции:
Секция задач
1. Отвечает за JIRA tickets
2. Является владельцем ресурсов (его подчиненные)
3. Имеет некий список обязанностей в рамках конкретной команды/тикета/релиза (допустим, reporting делается неким специальным образом)
Секция качества и знаний
1. Отвечает за качество
2. Владелец знаний
3. Имеет некие обязанности в рамках компетенции (скажем, является Senior разработчиком на Oracle и должен часть своего времени посвящать разработке)
Секцию задач имеет смысл возложить на Dev Lead«a. А для секции качества и знаний надо придумать новый термин. И такой термин есть — Competence Lead (лидер компетенций). Таким образом мы получаем не пересекающиеся зоны ответственности, сосредоточенные на четких, измеримых и предметных вещах.
Все обязанности из «зоны задач» позволяют задачам быть сделанными в срок, обеспечивают задачи нужными ресурсами и наделяют владельца этой секции необходимыми полномочиями для реализации целей. Задачи из «секции качества» обеспечивают качественный мониторинг навыков и развитие сотрудников, никак не влияя на реализацию конкретных задач. Вместе же они дают тот выигрыш и успешность, который так необходим нам в управлении проектами.
Зачем разделять эти 6 обязанностей на две группы и зачем поручать каждую из групп разным людям? Если вы занимаете роль Team Lead (либо аналогичную) в данный момент либо занимали ее в прошлом, то вы знаете/понимаете/заметили, что каждая из наших двух групп имеет совершенно разную направленность. А, следовательно, таким лидам необходимо обладать разными качествами, чтобы успешно выполнять обе эти группы обязанностей. Такое сочетание качеств не всегда сразу встречается в одном человеке, особенно если он недавно стал Team Lead«ом (TL). Да, все необходимые навыки можно и нужно развивать, просто на это требуется время. Зачастую, на практике, в реальных проектах, можно встретить довольно много людей, которым интересна только та или иная группа обязанностей, но не обе группы вместе. Следовательно, чисто статистически, вам, как руководителю, может оказаться заметно выгоднее, быстрее и проще разделить эти обязанности именно на такие группы и назначить разных ответственных, причем именно тех, кто больше всего подходит под выполнение первой или второй групп обязанностей.
Как это может выглядеть на организационной диаграмме: 
Вы можете видеть, что на диаграмме-3 группа QA-специалистов обведена пунктирной линией и внутри этой группы есть человек с позицией «Competence Lead QA». Обратите внимание, что в QA группу этого Competence Lead«а входят все имеющиеся в проекте тестировщики. Точно так же можно мысленно обвести аналитиков, джавистов, ораклистов и всех, кто у вас есть в проекте. Если проект большой и группы получаются слишком большие, разбейте их на несколько, руководствуясь правилом 7±2 (от 5 до 9 человек на группу). Таким образом вы полностью закрываете вопрос компетенций, развития людей, проверок качества кода, коучинга, обучения, кросс-ревью, обмена знаниями, бэкапирования людей и многие другие рабочие вопросы, на которые часто не хватает времени в боевых проектах.
Как может выглядеть список обязанностей Team Lead«а (TL) и Competence Lead«а (CL).
Ответственность TL:
1. Delivery конкретных JIRA-тикетов
2. Ветки соответствующих релизов
3. * Подача отпусков
4. * Подача овертаймов
5. Информация о болезни или опоздании подчинённого
6. Проведение стендапов
7. ** L0, L1 оценивание тикетов
8. Распределение задач в команде:
— Балансировка нагрузки ресурсов
— Распределение ответственных за задачи
Примечания:
*В пунктах 3, 4 имеется ввиду именно подача, а не «аппрув»
**Пункт 7 — с обязательным участием CL (как минимум для больших и средних тикетов)
Ответственность CL:
1. Ответственность за техническую и качественную сторону задач:
- Используемые технологии
- Использование стандартов
- Архитектурные вопросы
- Подходы, концепты тестирования. Тест планы. Ревью тест кейсов
- Качество спецификаций. Ревью спецификаций
- Соответствие решений требованиям и спецификациям
- Качество кода. Код ревью
2. Проактивная позиция:
- Коучинг интернов, нью-камеров (и не только)
- Предложение технических улучшений
Соответствующие CL должны так же принимать участие в вопросах:
1. Сдвиг сроков
2. Брейкдаун и его изменение в сфере разработки, тестирования, …
3. Планы развития людей, обучение, тренинги (вместе с TL и PPM)
Ближайшие шаги, которые можно сделать:
Как только вы обновите свою организационную структуру проекта, выделите Team Lead«ов и Competence Lead«ов, донесете и согласуете с ними их будущие обязанности, наделите их соответствующими полномочиями, озвучите команде новую структуру и новые правила игры, с этого момента ваша жизнь как руководителя станет намного проще и легче. Конечно, вы встретите еще много разных других сложностей и подводных камней (никто не обещал, что будет легко и просто), но как минимум вопросы ответственности у вас будут четко решены.
Поделитесь этой статьей с друзьями.
Спасибо и успехов вам!
© Megamozg
