← Все работы

Люди · Найм · Продуктовый процесс

Design Leadership · Т‑Банк

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

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

Общее в них одно. В каждой видимая проблема оказалась не там, где её искали.

Ключевые факты

  • 8 продуктовых дизайнеров в группе сейчас; в разные периоды — от 3 до 10
  • 269 дизайн-собеседований: 140 whiteboard и 129 знакомств
  • 4 новых whiteboard-задания, собранных секцией, — все используются в найме
  • 10 месяцев от разбора ситуации до аттестации на следующий грейд
  • 2 стажёра выросли до мидлов примерно за полтора года

Что в зоне группы

  • чаты поддержки первой и второй линии
  • текстовый и голосовой бот
  • AI-агенты на RAG и генеративных моделях
  • аудио- и видеозвонки в поддержку
  • Т‑Помощь — база знаний в Банке, Инвестициях и Бизнесе
  • сквозные сценарии клиентского опыта в мобильном банке
Восемь продуктовых дизайнеров. Дизайнеры ведут свои продукты сами — я подключаюсь глубже там, где ещё нужно задать направление.

История 1. Проблема была не в дизайнере

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

Стандартный ход в такой ситуации — собрать список западающих компетенций и написать ИПР. Я начал с другого: посмотрел не на дизайнера, а на задачи, которые к нему приходили.

С хардами всё было в порядке. Ломалось не в человеке.

У группы долго не было лида. Дизайнер один на один договаривался с сильным и несговорчивым бизнесом, не мог влиять на объём и сроки, и проще было соглашаться со всем. Нагрузка росла, качество падало — и падение качества читалось как проблема человека.

[ВИЗУАЛ 01 — ЧТО ПОКАЗАЛА ОЦЕНКА И ЧТО ПОКАЗАЛИ ЗАДАЧИ]
Слева — обезличенный итог оценки. Справа — разбор нескольких спринтов: объём, сроки, переработки.

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

Что я сделал

Я пришёл к бизнесу и сказал, что некорректна их модель работы. Не в общих словах: разобрал несколько их собственных задач и показал, где именно всё поехало и почему.

Дальше мы договорились о шагах:

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

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

[ВИЗУАЛ 02 — ЧТО ИЗМЕНИЛОСЬ В РАБОТЕ КОМАНДЫ]
Схема: было — задачи приходят без оценки и планирования; стало — оценка каждой задачи, потолок нагрузки на спринт.

Подпись: Договорённость была не про дизайнера, а про то, сколько работы помещается в спринт.

Чем закончилось

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

[НУЖЕН ФАКТ ОТ АНДРЕЯ] Что дизайнер начал делать сам, чего раньше не делал: оценивать и ограничивать объём, не соглашаться автоматически на сроки, вести переговоры с бизнесом без меня. Одно-два наблюдения — и они станут главным результатом истории вместо аттестации.

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

Что я из этого забрал

Оценка показывает симптом. Если начать сразу с ИПР, вылечишь симптом и оставишь причину — через полгода тот же человек окажется в той же нагрузке.

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


История 2. Найм: вернуть воронку, не опуская планку

У Junior- и Middle-кандидатов упала проходимость whiteboard-секции.

Первое объяснение, которое обычно принимают, — рынок просел, кандидаты стали слабее. Я разобрал результаты последних 50 интервью, и объяснение не подтвердилось.

Проблем оказалось две, и обе на нашей стороне:

  • новое задание было сложно понять — кандидаты тратили время на расшифровку условия, а не на решение;
  • интервьюеры ждали от Junior и Middle качества решения, которое соответствовало более высокому грейду.
[ВИЗУАЛ 03 — РАЗБОР 50 ИНТЕРВЬЮ]
Нормализованный график проходимости с разбивкой по грейдам и четырьмя отметками на оси времени: период до изменений, провал, возврат прежнего задания для Junior и Middle, восстановление. Абсолютные значения не раскрываем, но последовательность должна читаться — иначе фраза «воронка вернулась» ничем не подтверждена.

Подпись: Падение выглядело как проблема рынка, а оказалось проблемой задания и ожиданий.

Что мы сделали

Сначала быстрое: для Junior и Middle временно вернули прежнее задание, чтобы остановить потери в воронке.

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

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

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

  • Junior — полный контекст и данные;
  • Middle — бизнес-цели и часть вводных;
  • Senior — только контекст и задача.

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

[ВИЗУАЛ 04 — СЛОЖНОСТЬ ПО ГРЕЙДАМ]
Три уровня заданий и объём контекста, который получает кандидат на каждом.

Подпись: Одно задание не может проверять и джуна, и лида.

Чем закончилось

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

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


История 3. Процесс: договориться о работе до начала задачи

В одной продуктовой команде не было общего понимания ролей и этапов.

Как это выглядело изнутри:

  • задача стартовала без внятного кикоффа;
  • discovery не всегда успевал исследовать проблему;
  • в дизайн задачи приходили сырыми и возвращались на доработку;
  • мне всё чаще приходилось вручную погружаться в рядовые задачи.

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

Что я сделал

Инициировал общие встречи и помог команде сформулировать проблему словами, а не жалобами. Дальше собрал рабочую группу.

Вместе мы описали по Double Diamond путь от идеи до релиза: этапы, роли, ответственность, артефакты и условия перехода между этапами.

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

[ВИЗУАЛ 05 — КАРТА ПРОЦЕССА]
Обезличенная карта Double Diamond: этапы, роли, артефакты, условия перехода.

Подпись: Договорились о способе работы до того, как он снова понадобился.

Чем закончилось

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

На основе карты пересобрали Jira-flow и ввели измерение TTM.

Чего я не могу утверждать:

  • что TTM снизился — измерение появилось уже после изменения процесса, сравнивать не с чем;
  • что delivery измеримо ускорился;
  • что возвраты на доработку исчезли.

Что я из этого забрал

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

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


Что общего в трёх историях

Ни в одной из них я не подменял собой дизайнера, интервьюеров или владельцев процесса.

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