Привет, Хабр!

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

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

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

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

Давайте поговорим о сути проблемы и что можно сделать в такой ситуации.

Что такое «слепое пятно» в аналитике

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

Так сеньор смотрит на сырые данные — и мгновенно определяет, где выбросы, где пропуски, а где системная ошибка. А джуниор видит то же самое — и тонет в миллионе строчек.

Сеньор говорит: «Ну тут же очевидно, нужно взять кластер по полю user_id за последние 7 дней, исключить ботов и профильтровать по активной сессии».

Для него это «очевидно», хотя для джуниора это магия. И когда джуниор пишет код, он не понимает, почему нужно фильтровать именно так. Он просто запоминает инструкцию.

В результате возникает опасная петля обратной связи:

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

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

Рядом с ним сидела сеньор Лена, которая отлично разбиралась в оконных функциях. Артём начал с написания запроса, однако Лена, посмотрев через плечо, его остановила:

— Артём, ты чего? У тебя же здесь будут дубли на уровне события. Сразу юзай row_number по session_id и timestamp, партиционируй по user_id. Это же база.

Артём послушно переписал запрос, не особо вникая в подробности, и в итоге сделал витрину.

И вроде бы все довольны, но через месяц возникла задача: считать конверсию не по сессиям, а по пользовательским кликам с учётом кросс‑девайсов. Артём растерялся, так как он знал шаблон «row_number + партиционирование», но не понимал, почему в прошлый раз это работало, а в этот раз выдаёт нули. Естественно, он позвал Лену, и она снова всё объяснила.

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

Если бы она сказала по‑другому:

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

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

В результате он пришёл бы с конкретными вопросами, а не с просьбой «подскажите шаблон».

Как видите, здесь разница колоссальная, так как в первом случае он стал пользователем инструкции, а во втором — исследователем.

Методология «Управляемый хаос»: как лечить слепое пятно

На основе этого кейса давайте рассмотрим подход, который мы назвали «Управляемый хаос». Он будет состоять из четырех принципов.

Принцип 1. Искусственный дефицит подсказок

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

Например:

• Джуниор: «Мне использовать оконные функции?»

• Сеньор: «А какие проблемы ты увидел в данных, если их не использовать?»

• Джуниор: «Там дубли»

• Сеньор: «А откуда дубли? Какова природа этого дубля?»

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

Принцип 2. Обязательная «Грязная версия» (режим черновика)

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

Это нужно для того, чтобы он руками все подводные камни:

1. Где данные не сходятся.

2. Какие поля пустые.

3. Какие типы данных не совпадают.

И только после этой «грязной версии» он идёт к сеньору и говорит:

«Я вот так сделал, при этом, упал вот здесь и здесь. В результате я вижу две проблемы. Как мне их архитектурно разрешить?»

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

Принцип 3. Чередование зон ответственности по CYNEFIN

В аналитике задачи делятся на четыре типа по фреймворку CYNEFIN:

1. Простые (Clear) — известная причина и известное решение. Например: «Обнови данные в дашборде по шаблону». Это давать джуниорам, но только 20% времени.

2. Запутанные (Complicated) — известная причина, но неизвестное решение. Такие задачи обычно требуют экспертизы. Например: «Оптимизируй этот тяжёлый запрос». Здесь сеньор и джуниор работают в паре, но джун что называется «ведёт» клавиатуру.

3. Сложные (Complex) — неизвестная причина, неизвестное решение. В таких задачах нет правильного ответа, есть только гипотезы. Например: «Почему упала конверсия в новом регионе?». Это давать только джуниорам в режиме «разведки» без права ошибки.

4. Хаотичные (Chaotic) — кризис. Например: «Сгорел прод, данные потеряны, восстанавливай». Это только сеньоры, джуниоры — наблюдатели.

Здесь основной смысл заключается в том, что наставники привыкли давать джуниорам только «Простые» задачи, а потом удивляться тому, что они не растут.

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

Принцип 4. Час «Обратного инжиниринга»

Раз в неделю мы проводим сессию, где джуниор объясняет задачу сеньору, а не наоборот. Буквально: джуниор садится за проектор и за 45 минут проходит по своему решению. Сеньор имеет право задавать вопросы, но только уточняющие, а не корректирующие.

Вопросы сеньора:

• «Почему ты выбрал этот фильтр?»

• «Что будет, если данные за этот период обновятся постфактум?»

• «Как бы ты объяснил это решение менеджеру, если он не знает SQL?»

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

Почему старшим сложно замолчать

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

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

Вот совет, который можно дать всем ведущим аналитикам:

Представь, что ты — врач скорой помощи, а джуниор — студент‑медик. Если ты сам сделаешь операцию, студент не научится. Если ты дашь ему скальпель и будешь стоять рядом, но говорить только «Осторожно, слева сосуд» — у него есть шанс стать хирургом. Твоя задача — не сделать операцию быстрее. Твоя задача — чтобы в следующий раз он сделал сам, а ты пил кофе«.»

Метрики успеха: как понять, что вы движетесь правильно

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

Метрика 1. Количество вопросов за задачу

В начале эксперимента джуниор задавал сеньору в среднем 12 вопросов на задачу. Большинство из них были:

«А как правильно?», «А что ты делаешь?», «А это нормально?».

Это вопросы зависимости.

Через три месяца количество вопросов упало до 4–5, но их качество изменилось. Теперь они звучали:

«Я попробовал три способа. Первый падает по памяти, второй выдает дубли на кросс‑девайсах, третий работает, но медленно. Какой критерий для выбора здесь важнее — скорость или точность?».

Это вопросы стратегии, а не тактики, то есть их можно назвать правильными.

Метрика 2. Скорость самостоятельного старта

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

• До эксперимента: 2–3 часа. Джуниор ждал консультации, писал в мессенджер, думал «а вдруг не так сделаю?».

• После эксперимента: 20–30 минут. Джуниор сразу приступал к «грязной версии», зная, что у него есть время на ошибку и что сеньор не вмешается до определённого этапа.

Скорость не упала, а выросла — потому что ушёл страх и появилась самостоятельность.

Метрика 3. Бизнес ценность

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

• В «тепличном» режиме: 8–10 месяцев.

• В режиме «Управляемого хаоса»: 4–5 месяцев.

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

А что делать, если джуниор «ломается»?

Самый частый страх руководителя:

«Мы дадим ему свободу, он наделает ошибок, продакт‑менеджер получит неверные цифры, и нам всем будет плохо стыдно».

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

Единственное, что мы не прощаем — когда джуниор совершил ошибку и скрыл её.

Мы поощряем «красивые провалы» — когда он нашёл проблему, зафиксировал, сформулировал гипотезу, почему произошло, и пришёл с этим к команде. Это считается достижением.

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

Мы меняем подход — меняем сеньора‑наставника или меняем формат (например, переводим на парное программирование, где джуниор ведёт, а сеньор только задаёт уточняющие вопросы).

Подведем итог

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

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

Когда сеньор в порыве энтузиазма хочет подсказать джуниору готовое решение, он говорит фразу:

«Стоп. Я сейчас вижу решение, но я подожду. Приходи ко мне через час и покажи, что ты придумал сам. Даже если это будет неоптимально — это будет ТВОЁ. Мы поправим потом, но сначала ТВОЙ вариант».

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

Так что, позвольте им ошибаться, и не крадите у них их собственные ошибки. Потому что именно в этих ошибках — их настоящая экспертиза.

А ваша задача — сделать так, чтобы цена этих ошибок была приемлемой, а польза — максимальной.

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

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

• 8 сентября в 20:00. «Системный аналитик и его ценность глазами компании». Записаться

• 23 сентября в 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться

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