Я прочитал книгу «Делегирование и управление» и выделил 7 уроков для руководителя отдела аналитики

Недавно я прочитал книгу Брайана Трейси “Делегирование и управление”. Причина выбора книги довольно простая. Сейчас я работаю аналитиком полного цикла (бизнес + системный) в компании 1221Системс и включён в кадровый резерв руководителя отдела аналитики. Логично, что одним из главных навыков руководителя является грамотное делегирование рабочих задач.

У аналитика основной фокус находится на качестве собственных решений:

• провести исследование запроса
• собрать требования
• спроектировать процессы
• сформировать требования для дизайна
• согласовать спецификацию
• помочь команде разработки

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

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

Многие руководители сталкиваются с вопросами:

• какие задачи стоит продолжать делать самому, а какие передавать сотрудникам?
• как не превратиться в “узкое место” для команды?
• как развивать аналитиков через делегирование, а не только через обучение?
• как сохранить качество аналитики, если задачи выполняют другие люди?

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

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

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

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

• прокачивает личную эффективность руководителя
• становится главным драйвером роста команды

Почему это важно для руководителя аналитики? Всё просто! Аналитики — те ещё перфекционисты. И эта экспертность превращается в клетку.

Допустим, руководитель раньше был сильным системным аналитиком и умеет:

• проводить сложные интервью
• выявлять неочевидные требования
• моделировать процессы
• проектировать интеграции
• писать качественные спецификации

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

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

Вариант №1:

• самостоятельно проводить интервью
• самостоятельно проектировать решение
• самостоятельно согласовывать требования

Вариант №2:

• поручить проведение интервью мидл-аналитику
• привлечь джуна к моделированию процессов
• оставить за собой контроль ключевых решений и ревью артефактов

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

Основные ошибки.

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

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

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

Практический пример. Снова рассмотрим 2 варианта постановки задачи.

Вариант №1: “Подготовь спецификацию по новому сервису”

Вариант №2: “Необходимо подготовить спецификацию REST API для интеграции Bitrix и системы лояльности.

На выходе ожидаются:

• описание методов
• модели данных
• основные сценарии обмена
• сценарии ошибок
• диаграмма взаимодействия”

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

Этот подход работает и в обычной жизни. Личный пример, когда отдавал машину в кузовной ремонт:

Вариант №1: “Устранить косяки после аварии”

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

Вариант №2: “Восстановить трещину на переднем бампере. Заменить переднюю левую фару. Восстановить зазоры между бампером, фарами, капотом и крыльями. Обе фары отполировать. Бампер полностью покрасить и отполировать”

Такая постановка задачи не оставляет маневров для исполнителя. Есть четкое понимание ожидаемого результата.

Основные ошибки. Изначально хотел выделить несколько, но в процессе написания статьи осознал, что хочу оставить только одну:

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

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

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

Забудьте про “провели 50 интервью” и “написали 200 страниц ТЗ”. Это не результат, это просто утомительные цифры. Настоящий результат — это когда стейкхолдеры говорят “ок, делаем так” на основе вашего анализа. Или чтобы разработка написала фичу и забыла о ней, не переделывая три спринта. Всё остальное — это самообман.

Если вы не можете ответить на вопрос “Что конкретно мы произвели за спринт?”, вы не управляете, а имитируете.

Практический пример. На моей практике была ситуация: аналитик две недели проводил анализ. На дейли он рассказывал с кем созвонился, какие документы изучил, какие вопросы задал. Звучало как бурная деятельность.

Через две недели у него спросили: “Что имеем на текущий момент?”. Тишина. Не было ни че го. Ни одного готового артефакта, который можно было бы использовать для принятия решения.

Модель “Фабрика” решает это. Мы договариваемся, что на выходе через N дней должен быть либо скоуп требований с приоритетами, либо согласованная спецификация, либо диаграмма процессов. Всё остальное — это процесс, который ведёт к появлению артефактов, но никак не выполненная задача.

Основные ошибки.

1. Начать измерять всё, что движется. Число встреч, количество страниц в спецификации. Это не результат, это активность.

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

Суть идеи: Если другой человек может выполнить задачу на 70% так же хорошо, как вы, то делегируйте её. Не держитесь за рутину только потому, что вы умеете делать её идеально. Ваша задача как руководителя управлять, а не делать.

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

Практический пример.

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

• дать сотруднику провести интервью
• присутствовать наблюдателем
• после встречи провести разбор

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

Основные ошибки. Важно учитывать ограничение этой идеи. В ИТ есть задачи, где цена ошибки очень высока:

• проектирование критичных интеграций
• проектирование основных процессов приложения
• архитектурные решения

В таких случаях правило 70% требует дополнительного контроля и ревью.

Отдельная глава книги посвящена делегированию решений. Рекомендуется не становиться автоматическим “генератором ответов” для сотрудников. Когда человек приходит с проблемой, руководитель должен сначала спросить: “Какое решение ты предлагаешь?”. Не давайте готовых ответов на вопросы подчиненных. Верните им право принимать решения самостоятельно.

У многих руководителей постепенно появляется синдром диспетчера. Каждый день к ним приходят вопросы:

• какой вариант выбрать?
• какую систему использовать?
• с кем согласовать требования?
• кого позвать на встречу?

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

Практический пример.

Аналитик приходит с вопросом: “Какой вариант интеграции лучше выбрать?”. Вместо готового ответа руководитель просит подготовить:

• описание проблемы
• несколько вариантов решения
• плюсы и минусы
• собственную рекомендацию

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

Основные ошибки.

1. Давать готовые ответы слишком быстро. Вы не даете сотруднику самостоятельно думать и, тем самым, тормозите его развитие как профессионала
2. Наказывать сотрудников за каждую ошибку в решении. Ошибки — это неотъемлемая часть любой деятельности. Ошибка сигнализируют о том, что выбранное решение не работает. Эту информацию нужно принять к сведению и сделать работу над ошибками. Моя любимая цитата Томаса Эдисона: “Я не терпел поражений. Я просто нашёл 10.000 способов, которые не работают”
3. Игнорировать предложенное решение. Вы просите аналитика принять решение, но потом все равно делаете по-своему без объяснения причин. В следующий раз он даже пытаться не будет.

Вместо того чтобы требовать постоянных отчётов, Трейси предлагает: “Докладывай только если есть отклонения от плана. Если всё идёт по графику и в рамках бюджета, то я не мешаю”.

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

Практический пример.

Вы договариваетесь: “Ты должен завершить спецификацию к концу недели. Если видишь, что не укладываешься, или появились неучтённые сложности — ты сообщаешь мне до конца недели. Если ты молчишь, я считаю что всё в порядке, и не лезу. Если к концу недели нет спецификации — это отклонение, и тогда мы разбираемся”.

И это работает! Аналитики перестают бояться, что их будут дёргать каждые 2 часа. Они сами отслеживают риски, а руководитель тратит меньше времени на контроль.

Основные ошибки.

1. Полностью исчезать после делегирования или контролировать каждый шаг. Нужно соблюдать контрольные точки, о которых на старте договорились, и не вмешиваться, если отклонений нет. Не путайте контроль результата с контролем процесса
2. С джунами так не работает. Им нужно больше внимания и контроля. Это стадия “объяснения” и “стимулирования”
3. Не наладить систему “слабых сигналов”. Иногда человек молчит, потому что боится признаться в проблеме. Нужно создать культуру, где сообщить об отклонении — это норма, а не повод для наказания.

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

Трейси пишет: “Никогда не предполагайте, что сотрудник знает то же, что и вы. Объясняйте, даже если вам кажется это очевидным”. Опять же, в реальной жизни работает аналогично. Если вспомнить пример про ремонт машины после аварии, который приводил выше, в фразу “Устранить косяки после аварии” я закладываю один смысл, но мастер понимает эту фразу по своему.

В аналитике много “неписаных правил”: как задавать вопросы стейкхолдерам, как структурировать требования, как реагировать на возражения, как документировать и т.д. Если вы не передаёте эти знания, каждый новый аналитик изобретает велосипед. А вы продолжаете быть единственным, кто знает “как надо”. Многие вещи невозможно освоить только по книгам или курсам.

Практический пример. Есть аналитик, который хорошо собирает требования, но плохо их формализует. Спецификации неструктурированы, разработка и тестирование постоянно переспрашивает.

Вместо того, чтобы взять и переписать за ним, стоит сесть и объяснить:

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

Потом он делает спецификацию, вы даете обратную связь (безоценочно: “здесь не хватает вот этого”). На второй раз он сделает лучше. На третий уже сам проверит, не дожидаясь вашего ревью. Это и есть обучение через делегирование.

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

1. Заполнить шапку документа:
   • Название функции
   • Номер задачи
   • Список используемых запросов API
   • Ссылка на макеты в Figma
   • Ссылка на чат для обсуждения
2. Кратко описать планируемый функционал
3. Сформировать User Story
4. Сформировать критерии приёмки
5. Описать нефункциональные требования
6. Сформировать схему процесса
7. Сформировать схему переходов между экранами
8. Описать экраны
9. Описать Use Cases
   • Основной сценарий
   • Альтернативные сценарии

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

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

Возможно, у вас возникает вопрос: “Каким образом твой личный чек-лист относится к делегированию?”. Так это же методичка! Методичка, на основе которой можно сформировать обучение.

Основные ошибки.

1. Вы объяснили один раз, сотрудник сделал плохо, вы переделали сами, он не научился. Нужно дать ему сделать, даже если это дольше
2. Учить только навыкам, но не учить мышлению. Аналитик должен понимать, “почему” мы делаем так, а не иначе. Тогда он сам сможет адаптироваться под новые задачи

Несмотря на практическую ценность книги, некоторые идеи стоит воспринимать осторожно.

1. Излишне иерархический взгляд на управление. Книга написана в духе классического менеджмента: руководитель ставит задачи → сотрудники выполняют. В современных продуктовых командах многое строится через совместное принятие решений.
2. Осторожнее с моделью “руководитель как родитель”. Трейси несколько раз использует аналогию с детьми. Для современных зрелых команд такой подход может не подойти. Мне ближе идея партнерства и развития профессионалов, чем воспитания подчиненных.
3. Не все можно измерить количественно. Автор делает большой акцент на измеримости. Я тоже считаю, что количественные показатели очень важны и полезны, но важно помнить, что качество требований, влияние на продукт или качество коммуникации не всегда легко выразить цифрами.

Книга Трейси про то, что руководитель должен перестать быть исполнителем. Для аналитика, переходящего в управление, это самый сложный переход. Мы привыкли, что мы умные, мы всё знаем, мы лучше сделаем. Если вы продолжите делать, то вы никогда не вырастите как руководитель. Ваша новая работа — делать так, чтобы другие делали хорошо. Без вас. И получали от этого кайф.

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