Вектора интересов: как находить настоящую мотивацию и усиливать команды

Вектора интересов: как находить настоящую мотивацию и усиливать команды

Раздел 1. Введение: Почему «хорошего специалиста» иногда недостаточно

Знакомая ситуация?

Представьте: у вас в команде сильный Senior-разработчик. Hard skills — отличные, soft skills — в норме. Вы даете ему задачу, которая критична для проекта: допустим, написание сложного алгоритма или интеграция с капризным легаси. А он… тянет, теряет интерес, качество падает. Или, наоборот, вы нанимаете блестящего аналитика, но через три месяца он уходит, потому что «надоело просто описывать формы».

Обычно мы ищем причину в компетенциях: «Наверное, он не умеет». Или в лени. Но часто проблема глубже. Мы оцениваем «Могу ли я это сделать?», но игнорируем «Хочу ли я этим заниматься?» и «Что меня драйвит?».

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

1. Скрытое выгорание (сотрудник делает работу «через силу»).

2. Текучку (человек уходит туда, где его интересы совпадают с задачами).

3. Потерю скорости (задачи выполняются механически, без инициативы).

Что такое Вектор интереса?

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

Моя методология выделяет 8 базовых векторов. Они есть у каждого, но в разных пропорциях. Кто-то рожден архитектором (Системный вектор), для кого-то кайф — это порядок в хаосе данных (Алгоритмический), а кто-то живет ради того, чтобы пользователь был счастлив (Продуктовый).

Важно: Векторы не статичны. Они могут меняться со временем, комбинироваться. Но «ядерный» вектор — тот, который дает энергию — обычно постоянен.

Зачем это бизнесу? (Экономика вопроса)

Я придумал эту систему не ради красивой теории. Это вопрос денег и эффективности.

1. Стоимость ошибки подбора: Замена сотрудника обходится компании в 50–200% от его годовой зарплаты. Если человек не «зашел» в команду или задачу, мы теряем эти деньги.

2. Время онбординга: В среднем новому сотруднику нужно 3–6 месяцев, чтобы выйти на полную продуктивность. Если он мотивирован своими задачами, этот срок сокращается. Если нет — он никогда не выйдет на пик.

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

Сопоставляя вектор сотрудника с этапом проекта (нужны интеграции? нужны новые модули? нужен рефакторинг?), мы можем:

• Формировать команды под конкретные задачи, а не просто по свободным слотам.

• Понимать, кого обучать (интерес есть, навыка нет), а кого не трогать (нет ни интереса, ни навыка).

• Прогнозировать риски выгорания.

Для кого эта статья?

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

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

О чем я расскажу дальше

В этой статье я разберу:

1. Саму суть 8 векторов (и чем они отличаются для разработчиков и аналитиков).

2. Скрипт встречи: 5 глубоких вопросов, которые вскрывают истинные мотивы.

3. Интерпретацию: как по ответам понять профиль человека и что с этим делать.

4. Этику: как говорить об этом с сотрудником и не скатиться в манипуляции.

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

Раздел 2. Философия фреймворка: что такое векторы — и чем они не являются

Прежде чем мы разберём конкретные типы и скрипты, мне важно снять несколько фундаментальных заблуждений. Я видел, как многие руководители пытаются натянуть эту методику на старые лекала грейдирования или KPI. Это убивает инструмент на корню. Чтобы система сработала, нужно чётко понимать её природу.

Чём векторы НЕ являются

1. Это не грейды и не уровень seniority. Оценка «3» по Системному вектору не делает человека архитектором по должности. Это лишь маркер того, что его естественное внимание приковано к границам, компромиссам и структуре. Грейды измеряют опыт и зону ответственности, векторы — направление энергии.

2. Это не оценка hard skills. Можно иметь ярко выраженный Алгоритмический вектор, но пока слабо знать конкретный фреймворк. И наоборот: быть крутым экспертом в инфраструктуре, но внутренне выгорать от настройки пайплайнов, потому что драйвит совсем другое. Мы меряем мотивацию, а не скиллы.

3. Это не приговор. Вектор «0» в Продуктовом направлении не значит, что человек не способен выполнить задачу по фиче. Это значит, что ему будет скучно, и он не проявит там лишней инициативы. Знания качаются за месяцы, интерес — меняется годами или не меняется вовсе.

Что такое векторы на самом деле

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

Норма — это не один, а два-три доминирующих вектора

В начале я искал «идеальный профиль» с одним ярким лидером. Практика (более 50 интервью) показала: это редкость. У большинства специалистов ядро состоит из 2–3 векторов. Например, «Системный + Операционный» или «Доменный + Прикладной». Это абсолютно нормально. Более того, это часто признак зрелости: человек видит задачу объёмно, но всё равно есть та область, где он теряет счёт времени и готов копать глубже остальных. Наша задача — найти именно её.

Векторы динамичны, но инертны

Интересы могут эволюционировать. Специалист, который горел кодом фич, через 5 лет может сместиться в архитектуру или процессы. Но это не происходит по щелчку пальцев. Это результат накопленного опыта, выгораний и осознанного выбора. Нельзя заставить человека «переключить» вектор приказом или премией. Можно только создать условия, где его текущий вектор будет востребован, или мягко подвести к новому через менторство и смежные задачи.

Этика и прозрачность: правила игры

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

Раздел 3. Векторы для разработчиков: 8 способов видеть задачу

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

Все они правы. Все они приносят ценность. Но их «топливо» разное.

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

1. Системный (Architectural)

Фокус: Границы, структура, компромиссы. Этот человек видит систему целиком: где проходят контексты, как масштабируется, что сломается при росте нагрузки.

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

Слова-маркеры: «граница контекста», «декомпозиция», «NFR», «масштабируемость», «компромисс», «эволюция архитектуры», «ADR».

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

2. Прикладной (Functional)

Фокус: Точная реализация. Этот человек любит, когда всё работает «как в ТЗ»: сценарии покрыты, критерии приёмки выполнены, багов нет.

Ценность: Даёт предсказуемый, проверяемый результат. Снижает риск «сделали не то» и переделок на тестировании.

Слова-маркеры: «пользователь должен», «сценарий», «критерий приёмки», «покрытие», «верификация», «ТЗ», «шаг».

Как говорит:
«Давайте пропишем, что при нажатии “Оплатить” система сначала проверяет баланс, потом резервирует товар, и только потом списывает — иначе получим рассинхрон».

3. Инфраструктурный (Process & Tooling)

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

Ценность: Ускоряет онбординг, снижает рутину, делает процесс предсказуемым. «Невидимая» работа, без которой всё тормозит.

Слова-маркеры: «CI/CD», «шаблон», «автоматизация», «tooling», «стандарт», «self-service», «документация как код».

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

4. Интеграционный (Contract)

Фокус: Стыки систем, контракты, обработка сбоев. Этот человек не боится «грязной» реальности: легаси, внешние API, неидеальные данные.

Ценность: Делает систему устойчивой к внешним сбоям. Гарантирует, что «на другом конце» поймут нас правильно.

Слова-маркеры: «контракт», «эндпоинт», «маппинг», «адаптер», «изоляция сбоя», «версионирование», «dead-letter».

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

5. Продуктовый (Value)

Фокус: Пользователь, гипотезы, метрики. Этот человек спрашивает «зачем?» раньше, чем «как?».

Ценность: Помогает не делать «технически круто, но бесполезно». Связывает код с бизнес-результатом.

Слова-маркеры: «зачем это пользователю», «гипотеза», «метрика успеха», «ценность», «приоритизация», «impact/effort», «CustDev».

Как говорит:
«Прежде чем пилить фичу, давайте проверим на 10% трафика: если конверсия не вырастет, мы зря потратим спринт».

6. Доменный (Domain)

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

Ценность: Гарантирует, что система говорит на языке бизнеса. Снижает риск «сделали технически верно, но бизнес не понял».

Слова-маркеры: «бизнес-правило», «термин», «сущность», «статус», «язык предметной области», «комплаенс», «согласование с экспертом».

Как говорит:
«В банковской домене “счёт” не может уйти в минус без овердрафта — это не техническое ограничение, а регуляторное требование, его нельзя обойти “костылём”».

7. Алгоритмический (Logical)

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

Ценность: Делает систему быстрой, корректной и предсказуемой на уровне логики. Решает задачи, где «просто написать» недостаточно.

Слова-маркеры: «алгоритм», «поток данных», «состояние», «ветвление», «целостность», «оптимизация», «конечный автомат».

Как говорит:
«При изменении статуса заказа нужно запустить цепочку: резерв → инвентарь → уведомление. Если инвентарь < 0 — откатить транзакцию, иначе получим отрицательный остаток».

8. Операционный (Operational)

Фокус: Стабильность в продакшене. Этот человек пишет код так, чтобы его можно было отлаживать в 3 часа ночи.

Ценность: Снижает MTTR, делает систему наблюдаемой и восстанавливаемой. Предотвращает «ночные пожары».

Слова-маркеры: «мониторинг», «алерт», «логирование», «откат», «SLA/SLO», «MTTR», «graceful degradation», «восстановление».

Как говорит:
«Если внешний API не ответит за 3 секунды, система должна перейти в деградированный режим, записать в dead-letter и алертнуть в Slack — а не висеть в ожидании».

Принято. Переписываю Раздел 4 — строго описание векторов для аналитиков и архитекторов, без дублирующего завершающего блока.

Раздел 4. Векторы для аналитиков и архитекторов: те же 8 граней, другой фокус

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

Те же 8 векторов. Та же шкала 0–3. Но фокус смещается: если разработчик думает «как это реализовать в коде», то аналитик/архитектор думает «как это описать, согласовать и встроить в процесс».

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

1. Системный (Architectural)

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

Ценность: Не даёт проекту скатиться в «лоскутное одеяло». Заранее проектирует точки расширения и изоляции изменений.

Слова-маркеры: «граница контекста», «bounded context», «NFR на уровне системы», «архитектурный компромисс», «декомпозиция», «эволюция модели».

Как говорит:
«Если мы сейчас не зафиксируем, где проходит граница между “Заказом” и “Оплатой”, то при добавлении нового способа оплаты придётся переписывать половину требований».

Отличие от разработчика:
Разработчик с Системным вектором думает о сервисах, очередях, масштабировании. Аналитик с тем же вектором думает о границах в требованиях, трассируемости, согласованности артефактов.

2. Прикладной (Functional)

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

Ценность: Снижает количество итераций «уточни-переделай». Делает процесс предсказуемым для всей команды.

Слова-маркеры: «пользовательская история», «критерий приёмки», «шаг сценария», «ожидаемый результат», «верификация», «покрытие», «DoD».

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

Отличие от разработчика:
Разработчик с Прикладным вектором фокусируется на корректности кода. Аналитик — на корректности описания: чтобы разработчик не додумывал, а реализовывал.

3. Процессный (Process & Tooling)

(«Инфраструктурный» — аналог для разработчиков)

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

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

Слова-маркеры: «шаблон требования», «стандарт оформления», «автоматизация документации», «CI/CD для требований», «гайдлайн», «Confluence-структура», «трассируемость».

Как говорит:
«Давайте настроим, чтобы изменения в Jira автоматически попадали в спецификацию в Git — чтобы у разработки и аналитики всегда была одна версия правды».

Отличие от разработчика:
Разработчик с Инфраструктурным вектором настраивает пайплайны для кода. Аналитик с Процессным вектором настраивает пайплайны для требований и артефактов.

4. Интеграционный (Contract)

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

Ценность: Гарантирует, что системы поймут друг друга. Снижает риск «сделали по ТЗ, но не работает вместе».

Слова-маркеры: «контракт API», «маппинг полей», «версионирование», «адаптер», «изоляция сбоя», «спецификация интерфейса», «OpenAPI».

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

Отличие от разработчика:
Разработчик с Интеграционным вектором пишет код адаптеров. Аналитик — описывает контракты, форматы, правила маппинга и обработки ошибок «на бумаге», до начала реализации.

5. Продуктовый (Value)

Фокус: Пользователь, гипотезы, метрики успеха. Этот человек спрашивает «зачем?» и «как измерим?» раньше, чем «что опишем?».

Ценность: Помогает не делать «красиво по ТЗ, но бесполезно для бизнеса». Связывает требования с результатом.

Слова-маркеры: «зачем это пользователю», «гипотеза», «метрика успеха», «ценность фичи», «приоритизация», «impact/effort», «валидация», «поведение пользователя».

Как говорит:
«Прежде чем описывать фичу “Быстрый заказ”, давайте проверим на данных: если 80% пользователей и так проходят за 3 клика, возможно, нам важнее оптимизировать оплату».

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

6. Доменный (Domain)

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

Ценность: Гарантирует, что система говорит на языке бизнеса. Снижает риск «сделали технически верно, но бизнес не понял».

Слова-маркеры: «бизнес-правило», «термин», «сущность», «статус в процессе», «язык предметной области», «согласование с экспертом», «комплаенс», «регламент».

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

Отличие от разработчика:
Разработчик с Доменным вектором отражает бизнес-правила в коде. Аналитик — выявляет, формализует и согласовывает эти правила с экспертами до начала разработки.

7. Алгоритмический (Logical)

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

Ценность: Делает требования корректными и исполнимыми на уровне логики. Решает задачи, где «просто описать» недостаточно.

Слова-маркеры: «поток данных», «переход состояния», «условие ветвления», «конечный автомат», «целостность данных», «оптимизация процесса», «правило трансформации».

Как говорит:
«При изменении статуса “Заказ” с “Новый” на “В работе” нужно запустить цепочку: резерв → уведомление → задача исполнителю. Если резерв не прошёл — откатить статус и алертнуть».

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

8. Операционный (Operational)

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

Ценность: Снижает MTTR, делает систему предсказуемой для поддержки. Предотвращает «мы не предусмотрели это в ТЗ».

Слова-маркеры: «мониторинг», «алерт», «логирование», «откат», «SLA/SLO», «MTTR», «graceful degradation», «восстановление», «наблюдаемость».

Как говорит:
«Если внешний сервис не ответит за 3 секунды, в требованиях должно быть явно прописано: система переходит в деградированный режим, пишет в dead-letter и алертит в Slack — а не висит в ожидании».

Отличие от разработчика:
Разработчик с Операционным вектором пишет код с логированием и обработкой сбоев. Аналитик — формулирует эти требования явно в спецификации, чтобы они не «потерялись» при реализации.

Раздел 5. Как читать профиль: паттерны комбинаций векторов

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

Когда я впервые показываю руководителям результаты интервью, первая реакция часто такая: «Так какой у него главный вектор? Один назови». Я отвечаю: «Никакого. У него ядро из двух-трёх».

Человек не может быть «чистым системщиком» или «только продуктовым». Это плоская проекция объёмной личности. И это норма.

Ядро профиля: почему 2–3 вектора — это хорошо

На практике я крайне редко вижу идеальный «пик» на одной оси и нули на остальных. Чаще всего у специалиста есть доминирующее ядро — это 2 или 3 вектора, которые оцениваются на 2 или 3 балла. Они усиливают друг друга.

Например:

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

• Доменный + Прикладной — идеальный аналитик для сложного бизнеса (банки, страхование, медицина). Он понимает тонкости регламентов (Доменный) и умеет перевести их в чёткие сценарии для разработки (Прикладной).

• Алгоритмический + Интеграционный — «повелитель данных». Человек, который берёт хаос из внешних систем и превращает его в строгие, оптимизированные потоки внутри.

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

Форма диаграммы: «Ёж» vs «Блин»

Глядя на спайдер-диаграмму, я обращаю внимание на общую форму профиля.

«Ёж» (острые пики, провалы до 0-1) Это ярко выраженный специалист.

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

• Риск: Если дать ему задачу из зоны провала (например, «чистому» системщику поручить верстку UI), он сделает это «тяп-ляп» или будет сопротивляться.

• Применение: Точечное усиление команды. Если нам нужно переписать легаси-интеграцию — берём «ёжа» с пиком в Интеграционном.

«Блин» (ровный профиль, везде 1-2) Это «швейцарский нож», универсал.

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

• Риск: Редко проявляет инициативу «сверх задачи». Нет той самой страсти, которая двигает сложные проекты вперёд. Может выгорать от рутины, так как нигде не чувствует глубины.

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

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

Вот отточенная версия завершающей части Раздела 5:

Ограничения методологии: где диаграмма не даёт полной картины

Важно понимать: вектор интересов — это не гороскоп и не приговор. Это инструмент поддержки решений, а не их замена. Диаграмма показывает «внутренний компас», но игнорирует внешние координаты. Я всегда держу в голове «слепые зоны», которые методика не покрывает:

1. Этические и ценностные границы.
   У человека может быть высокий Продуктовый вектор (3 балла), он готов горы свернуть ради пользователя. Но если ваш проект — это, условно, табачная промышленность или микрозаймы, а он принципиально против этого — никакой вектор его не удержит. Он уйдёт, потому что ценности не совпадают.

2. Межличностные конфликты и психологический климат.
   Вы можете идеально сопоставить векторы: у сотрудника «Системный 3», и в команде как раз нужен системный архитектор. Но если в этой команде уже есть человек, с которым у нашего кандидата непримиримый личный конфликт или стиль коммуникации, который его блокирует — векторы не помогут. Команда развалится. Интересы важны, но психологическая совместимость и безопасность первичны.

3. Технологический стек и контекст.
   У аналитика может быть высокий Интеграционный вектор. Казалось бы, бери и делай. Но если ваш проект требует работы с конкретным, устаревшим стеком (например, SOAP-сервисы 2005 года), а человек ненавидит легаси и хочет только REST/GraphQL — он будет страдать. Вектор показывает «что» ему интересно, но не «в каких инструментах».

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

5. Разрыв «Интерес × Навык».
   Высокий интерес (3) при нулевом или базовом навыке (0–1) не даст быстрой отдачи. Человек будет гореть, но тормозить проект, совершая ошибки новичка, и быстро выгорит от фрустрации. И наоборот: интерес 1 при навыке 3 даёт надёжного исполнителя, но не драйвера изменений. Вектор говорит «куда тянет», но не «насколько быстро и безопасно доедет».

6. Культура компании и стиль управления.
   «Процессный» или «Системный» специалист задохнётся в среде, где стандарты считаются бюрократией, а решения принимаются хаотично. «Продуктовый» аналитик не раскроется в компании, где требования спускаются сверху как приказы без права на гипотезы. Методика работает только при базовом совпадении культуры и уровне автономии, который даёт руководство.

7. Временная адаптация vs Ядерный интерес.
   На собеседовании или в период адаптации человек может временно сфокусироваться на том, что «надо» или «безопасно», маскируя свой истинный вектор. Например, разработчик, который мечтает заниматься алгоритмами, но полгода по найму делал только интеграции, может говорить об интеграциях как эксперт, хотя внутри это его «серая зона». Диаграмма фиксирует текущий резонанс, но не всегда отличает его от ситуативной роли.

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

Раздел 6. Язык выявления: как слышать векторы в речи

Здесь я фокусируюсь на практической стороне: как интервьюеру (архитектору или техлиду) не просто «слышать слова», а считывать паттерны, не ломая доверительную атмосферу, и как разруливать ситуации, когда ответ попадает сразу в две зоны.

На встречах я часто вижу одну типовую ошибку: интервьюер держит в голове чек-лист и ставит мысленные галочки, как только слышит знакомое слово. «Ага, сказал “масштабируемость” — значит, системный». Это мгновенно меняет динамику. Человек чувствует, что его «сканируют», начинает подбирать «правильные» ответы, и мы теряем рафинированный опыт.

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

Ключевые слова-триггеры (шпаргалка для фокуса)

Я не прошу запоминать их наизусть. Это якоря, которые помогают удерживать внимание в нужном русле. Если слышите группу слов из одного кластера — просто ставьте + в блокноте. Не меняйте ход беседы.

Поведенческие маркеры (то, что не сказано, но видно)

Слова — это только 30% сигнала. Остальное — в энергии и структуре ответа. Я обращаю внимание на:

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

2. Что он детализирует без подсказки. Системщик сам нарисует границы контекстов. Продуктовик сам спросит про метрики успеха. Операционник сам вспомнит про алерты в 3 часа ночи. Не нужно тянуть — достаточно дать пространство.

3. Паузы и формулировки. Если человек молчит 5–10 секунд, а потом выдаёт структурированный ответ с чёткими аргументами — это признак глубокого интереса. Если отвечает быстро, шаблонно или переводит тему — вектор, скорее всего, слабый или ситуативный.

4. Что он опускает. Часто важнее то, о чём человек не говорит. Если аналитик подробно описывает бизнес-правила, но ни слова не говорит о том, как это будет мониториться в продакшене — Операционный вектор, вероятно, низкий. И это нормально.

Протокол разрешения конфликтов (когда векторы пересекаются)

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

На практике я просто задаю себе вопрос: «На чём он делает акцент? На структуре, на данных, на пользователе или на процессе?» Ответ обычно очевиден.

Главное правило интервьюера

Никогда не выставляйте оценки в моменте. Во время встречи я только фиксирую: + за маркер, ! за явную энергию, ? за неоднозначность. Вся аналитика, сопоставление с критериями и выставление баллов 0–3 происходит постфактум, на свежую голову, с использованием подробных заметок. Попытка оценить «на лету» неизбежно ведёт к когнитивным искажениям и потере честности диалога.

Раздел 7. Шкала оценки 0–3: почему дискретная, а не непрерывная

Когда я только начинал калибровать методику, меня тянуло использовать привычную 10-балльную шкалу или проценты. Казалось: «чем точнее, тем лучше». Но после 20–30 интервью я понял: это иллюзия точности.

Человек не может надёжно отличить «7.5» от «8» по интересу к алгоритмам. Зато он чётко видит разницу между «вообще не парился этой темой» и «готов говорить об этом часами». Поэтому я остановился на дискретной шкале 0–3. Она не про математику — она про паттерны поведения.

Что означает каждый уровень

Почему не 1–10 и не «да/нет»

1. Когнитивная надёжность. Различать 10 уровней интереса — задача для эксперта с годами калибровки. Различать 4 — посильно для техлида после одного прочтения гайда.

2. Устойчивость к шуму. В живом разговоре человек может сказать что-то «не в тему» или, наоборот, промолчать из-за усталости. Дискретная шкала сглаживает эти флуктуации.

3. Практическая достаточность. Для принятия решений (брать/не брать, обучать/не обучать, ротировать/оставить) достаточно знать: «нет интереса», «есть потенциал», «это его зона». Точнее — уже перебор.

Почему самооценка не работает

На первых встречах я пробовал спрашивать: «А как ты сам оценишь свой интерес к интеграциям по шкале от 1 до 10?». Результаты были предсказуемо искажены:

• Эффект Даннинга-Крюгера: новички переоценивают, эксперты — недооценивают.

• Социальная желательность: человек называет то, что, как ему кажется, от него ждут.

• Размытость критериев: «интерес» для одного — «прочитал статью», для другого — «написал пет-проект».

Поэтому оценка выставляется постфактум, на основе анализа ответов, а не самооценки собеседника. Я слушаю, фиксирую маркеры, а потом — уже в спокойной обстановке — сопоставляю с критериями.

Как отличить 1 от 2 и 2 от 3 на практике

Самая частая ошибка — путать «знает» с «интересуется». Вот простые эвристики, которые я использую:

Пример:

• Операционный вектор, оценка 1: «Мы настроили алерты, потому что так требовалось в требованиях».

• Операционный вектор, оценка 2: «Я предложил добавить логирование на этом этапе, чтобы потом было проще искать корень проблемы».

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

Главное правило выставления оценки

Оценивай не «что сказал», а «как и зачем». Одинаковые слова могут скрывать разный интерес. Фраза «нужно добавить мониторинг» может быть:

• Реакцией на требование (1 балл),

• Проактивным улучшением процесса (2 балла),

• Страстным призывом к архитектурной целостности (3 балла).

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

Раздел 8. Интерпретация: матрица «Интерес × Компетенция»

Здесь мы соединяем два измерения: внутреннее «топливо» (вектор) и внешний «двигатель» (реальные навыки). Именно на пересечении этих осей принимаются кадровые и проектные решения.

Сам по себе вектор интереса — это только половина картины. Человек может гореть желанием проектировать архитектуру (Интерес 3), но пока не знать паттернов проектирования (Навык 1). И наоборот: блестяще писать оптимизированные запросы (Навык 3), но смертельно скучать от рутинной выгрузки данных (Интерес 0).

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

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

Зона роста: Интерес 3 / Навык 1–2

Человек «болеет» темой, но пока не дотягивает по хард-скиллам.

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

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

• Пример: Разработчик с вектором «Интеграционный 3», но слабым опытом работы с Kafka. Дать ему задачу по настройке dead-letter queue под присмотром сеньора, а не поручать проектирование всего потока сообщений.

Зона риска: Интерес 0 / Навык 2–3

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

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

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

• Пример: Сильный бэкендер, которого всё время ставят на поддержку легаси-интеграций. Он делает это хорошо, но на встрече его глаза «стеклянные». Вектор «Интеграционный» — 0. Пора дать ему продуктовые или алгоритмические задачи.

Зона эксперта: Интерес 2 / Навык 3

Особенно важный кейс, который я выделяю отдельно. Человек глубоко разбирается в теме, но она не является его главным драйвером.

• Что делать: Использовать как эксперта-консультанта, ревьюера или наставника. Давать сложные точечные задачи, где нужен опыт, но не нагружать этой темой «под завязку».

• Чего избегать: Делать его единственным ответственным за направление. Он выполнит задачу качественно, но без лишней инициативы, и быстро устанет от монотонности. Это путь к скрытому выгоранию.

• Пример: Тимлид с «Операционным вектором 2», но «Навыком 3» в мониторинге. Отлично проведёт ревью алертов, настроит дашборды, но не будет фанатично гнаться за MTTR 24/7. Дайте ему эту зону как часть нагрузки, а не как основную роль.

Зона исполнителя: Интерес 1 / Навык 1–2

Базовое понимание, минимальный интерес. Нормальная рабочая лошадка для типовых задач.

• Что делать: Давать чёткие, алгоритмизированные задачи с понятными критериями приёмки. Не ждать прорывов или архитектурных инсайтов. Поддерживать стабильность.

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

Зона драйвера: Интерес 3 / Навык 3

Идеальное совпадение. Человек и знает, и горит.

• Что делать: Давать автономию, сложные вызовы, право влиять на roadmap. Такой сотрудник будет тянуть направление вперёд, обучать других и генерировать идеи.

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

Правило принятия решений

Я никогда не назначаю задачи, опираясь только на вектор или только на грейд. Всегда проверяю пересечение:

• Если интересует, но не умеет → учим, поддерживаем, даём время.

• Если умеет, но не интересует → ротируем, делегируем, ищем замену вектору.

• Если не интересует и не умеет → не тратим ресурсы. Это не про «плохого сотрудника», это про несовпадение профиля и задачи.

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

Раздел 9. Методология интервью: скрипт, фасилитация и искусство слушать

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

Когда я только начинал проводить такие встречи, я думал: «Главное — задать правильные вопросы». Оказалось, вопросы — это только 20% успеха. Остальные 80% — это атмосфера, в которой человек решается говорить правду.

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

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

Настрой интервьюера: три правила перед стартом

1. Ты не оцениваешь, ты исследуешь. Твоя цель — не поставить балл, а понять, что зажигает этого человека. Это меняет тон, вопросы и даже позу. Ты не судья, ты картограф.

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

3. Пауза — это нормально. Если собеседник молчит 5–10 секунд — не перебивай. Он формулирует честный ответ, а не шаблон. Дай ему время. Часто именно после паузы звучит самое ценное.

Структура встречи (гибкий тайминг)

Я держу в голове примерный ритм, но не гонюсь за секундами. Лучше задержаться на 15 минут, чем прервать живой диалог посередине мысли. Если человек «пошёл» — дай ему пространство. Если «буксует» — мягко помоги сформулировать.

Про «Путь в IT (интервьюер)»: После того как собеседник рассказал о себе, я кратко (2–3 минуты) делюсь своим путём. Не для того, чтобы похвастаться, а чтобы:

• Показать: мы говорим на равных, нет начальника и подчинённого.

• Синхронизировать терминологию: если я упомянул «bounded context» или «dead-letter», человек поймёт, что эти слова — часть общего языка.

• Дать «разрешение» говорить глубоко: если я говорю о компромиссах в архитектуре, собеседник понимает, что может говорить о своих.

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

Почему в методике ровно пять вопросов

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

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

1. Когнитивный предел для честного погружения. За 60 минут человек может качественно реконструировать свой ход мыслей только в 4–5 ситуациях. Больше — и внимание рассеивается, ответы становятся поверхностными. Меньше — не хватает контраста для сравнения паттернов.

2. Дилеммы ломают шаблоны. Простой вопрос («Как вы работаете с требованиями?») провоцирует лекцию из учебника. Дилемма («ТЗ противоречит бизнес-целесообразности. Что делаете?») заставляет выбирать. В момент выбора человек перестаёт говорить «как надо» и начинает действовать «как привык». Именно там проявляется естественный вектор.

3. Глубина важнее широты. Нам не нужно проверить всё подряд. Нам нужно увидеть, через какую призму специалист смотрит на задачу. Пяти тщательно откалиброванных ситуаций достаточно, чтобы эта призма стала видна. Остальное — статистический шум.

Сами формулировки вопросов я вынес в Приложение Д (отдельно для разработчиков и аналитиков), чтобы не перегружать основной текст. Здесь важно запомнить только одно: вопросы задются строго по списку, без импровизации. Они откалиброваны месяцами проб и ошибок, и любое «улучшение» формулировки на лету обычно снижает диагностическую ценность.

Пять дилемм: как задавать и что слушать

Ключевые правила:

1. Задавай строго по списку, не импровизируй с формулировками. Дилеммы откалиброваны так, чтобы вскрывать мотивацию, а не знания.

2. Не перепрыгивай с вопроса на вопрос. Дай человеку закончить мысль, даже если ответ уходит в сторону.

3. Слушай не только слова, но и энергию. Где человек «загорается», где начинает детализировать без подсказки, где делает паузу — это маркеры.

4. Уточняй только после паузы. Если человек закончил и молчит 3–5 секунд — можно мягко спросить: «А что было самым сложным в этой ситуации?». Не перебивай поток.

Техники возврата к теме (если человек уходит в сторителлинг):

• «Это ценный пример, спасибо. Давай вернемся к изначальной ситуации — какие были твои самые первые шаги?»

• «Я зафиксировал эту мысль. А если говорить именно про <тема вопроса>, что было ключевым для тебя?»

• «Чтобы мы успели пройти все ситуации, давай резюмируем этот момент и перейдём к следующему».

Активное слушание: что можно и нельзя

Зеркаль, не интерпретируй. Вместо «То есть ты продуктовый?» — «Правильно ли я понял, что главным драйвером была не технология, а скорость получения фидбека от бизнеса?»

Завершение: как оставить дверь открытой

После пятого вопроса я всегда даю пространство для «а ещё»: «Мы прошли по всем вопросам. Есть ли что-то, о чем я не спросил, но что для тебя важно в контексте твоих интересов?»

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

Это снимает тревогу «а что дальше?» и оставляет ощущение завершённости.

Сразу после встречи: пока свежо

Пока я иду от стола до компьютера (2–3 минуты), я делаю в блокноте одну пометку: на каком вопросе человек «загорелся» больше всего. Это сильный маркер для последующего анализа. Не оценки, не интерпретации — просто ! рядом с номером вопроса.

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

Раздел 10. Практическое применение: от диагностики к действиям

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

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

После 50+ интервью я вывел несколько паттернов применения, которые реально меняют эффективность команд. Делюсь тем, что работает у меня.

Формирование команд под этап проекта

Одна из самых сильных возможностей методики — подбирать людей не просто по свободным слотам, а под конкретную фазу проекта. Векторы помогают ответить на вопрос: «Кто здесь будет гореть, а кто — выгорать?»

Как я действую на практике:

1. Смотрю на план проекта на следующие 3–6 месяцев.

2. Выделяю 2–3 ключевых направления работы.

3. Сопоставляю с профилями команды.

4. Если вижу перекос (например, все «системные», а впереди интеграции) — начинаю ротацию или точечный найм.

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

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

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

• Замена сотрудника стоит 50–200% от его годовой зарплаты (рекрутинг, онбординг, потеря продуктивности).

• Новый человек выходит на полную продуктивность через 3–6 месяцев. В это время он скорее потребляет ресурсы, чем отдаёт.

• Ошибка подбора в команду — это не только деньги, но и репутационные риски, демотивация остальных.

Когда человек получает задачи, соответствующие его векторам:

• Он быстрее входит в роль (потому что интересно).

• Он проявляет инициативу (потому что «это моё»).

• Он реже смотрит в сторону других предложений (потому что здесь его драйв).

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

Ротация и карьерные треки: как развивать без выгорания

Векторы помогают строить развитие не только «вверх», но и «вширь».

Ситуация: У сотрудника высокий Системный вектор (3), но он застрял на поддержке легаси. Нагрев растёт, интерес падает.

Что можно сделать:

• Дать ему участие в проектировании новой подсистемы (даже 10% времени).

• Поручить ревью архитектурных решений в других командах.

• Обсудить переход в роль архитектора или техлида — если это совпадает с его интересами.

Ситуация: У аналитика высокий Процессный вектор (3), но он устал от рутины.

Что можно сделать:

• Дать ему задачу по настройке CI/CD для документации.

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

• Обсудить роль «аналитик-методолог» — если это ему интересно.

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

Работа сотрудника со спайдер-диаграммой: чек-лист для самоконтроля

Один из самых ценных моментов методики — когда я передаю результаты сотруднику. Я не отдаю ему таблицу с цитатами и обоснованиями (это рабочий инструмент для руководителей). Я даю спайдер-диаграмму и короткий разговор.

Как я строю этот разговор:

1. Показываю диаграмму без оценок.
   «Вот твой профиль. Видишь, где пики? Это твои зоны энергии. Где провалы? Это не «плохо», это просто не твоё».

2. Объясняю, как использовать профиль для самоконтроля.
   «Ты знаешь, что у тебя слабый Операционный вектор. Значит, когда будешь делать задачу, где важна стабильность в продакшене, — сознательно проверь: а логи я добавил? а алерт предусмотрел? а откат прописал? Составь себе чек-лист на основе «серых зон» и проходи по нему перед сдачей».

3. Обсуждаем делегацию.
   «Если задача требует сильного Интеграционного подхода, а у тебя там 1 балл — не геройствуй. Попроси коллегу с пиком в этом векторе помочь с контрактом или маппингом. Это не слабость, это умное распределение ресурсов».

4. Даю простой инструмент: чек-лист «На что обращать внимание».
   Сотрудник сам формулирует 3–5 пунктов, которые он будет проверять в задачах, не соответствующих его векторам. Например:

   • «Если задача про интеграцию — проверяю: контракт зафиксирован? обработка ошибок есть? маппинг данных описан?»

   • «Если задача про UI — уточняю: сценарий пользователя прописан? критерии приёмки есть? метрики успеха определены?»

Почему это работает:

• Человек не пытается «стать другим», а учится компенсировать слабые зоны осознанно.

• Он делегирует то, что не его, и фокусируется на том, что даёт энергию.

• Качество работы растёт, потому что «серые зоны» больше не остаются без внимания.

Главное правило применения

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

Раздел 11. Статус методики и ограничения: что работает, а что — нет

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

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

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

Что методика уже доказала на практике

1. Точность выявления «естественного фокуса». В 8 из 10 случаев профиль, полученный по векторам, совпадает с тем, как человек реально проявляет себя в работе через 2–3 месяца. Если у сотрудника пик в «Интеграционном» — он действительно тянет стыки систем. Если «Продуктовый» — спрашивает «зачем?» раньше «как?».

2. Снижение риска «не та задача не тому человеку». После внедрения векторов в процесс онбординга и ротации я перестал видеть ситуации, когда сильного специалиста «гасит» задача, которая ему не интересна. Мы стали чаще попадать: человек получает то, что его зажигает, команда — результат.

3. ** Разрыв цикла «надежда → уговоры → давление → выгорание».** Раньше я часто попадал в ловушку: вижу, что задача человеку не совсем подходит по профилю, но «надо», «свободен только он», «ну попробуем». Внутри себя гоню мысли о несовпадении, уговариваю сотрудника: «Ты же справишься, это же несложно». Даю задачу.

   • Через 2–3 дня: результата нет. Начинаю мягко мотивировать: «Как успехи? Может, помочь?».

   • Через неделю: прогресс минимальный. Начинаю давить: «Сроки горят, почему не делаешь?».

   • Через две: человек выгорает, задача висит, я раздражён, команда видит конфликт.

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

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

4. Честный разговор с сотрудником. Спайдер-диаграмма — это не «оценка», это повод для диалога. Люди ценят, когда им показывают не «ты плохой», а «вот твои сильные зоны, давай на них опираться».

Что методика не решает (и не должна)

1. Не заменяет оценку hard skills. Вектор «Системный 3» не делает человека архитектором. Он лишь говорит: «ему интересно думать о границах». Навыки нужно оценивать отдельно — через код-ревью, тестовые задания, кейсы.

2. Не диагностирует soft skills в отрыве от контекста. Человек может быть блестящим системщиком, но токсичным в коммуникации. Векторы не покажут это. Для этого нужны другие инструменты: 360°, наблюдение в работе, обратная связь от команды.

3. Не отменяет личные границы и ценности. Как я уже писал в Разделе 5: если человек принципиально не хочет работать в определённой индустрии — никакой вектор его не удержит. Это вопрос этики, а не мотивации.

4. Не предсказывает выгорание. Высокий интерес ≠ бесконечный ресурс. Человек может гореть задачей, но выгореть от перегруза, конфликта или личных обстоятельств. Векторы — компас, а не датчик усталости.

Как векторы эволюционируют со временем

Интересы — не высечены в камне. Я наблюдаю три паттерна изменений:

Важно: не путать временную усталость с изменением вектора. Если человек после отпуска снова «загорается» прежними темами — это не сдвиг, это восстановление.

Как я обновляю методику: обратная связь и калибровка

Методика живая. Я регулярно собираю фидбек:

• От сотрудников: «Правильно ли я понял свой профиль?», «Помогло ли это в работе?».

• От руководителей: «Совпал ли прогноз с реальностью?», «Где методика дала сбой?».

• От себя: «Что я упустил в интервью?», «Какой вопрос стоит добавить/убрать?».

Раз в квартал я пересматриваю:

• Формулировки вопросов (если какой-то стабильно «не вскрывает» мотивацию).

• Список маркеров (если появляются новые термины или паттерны речи).

• Протокол разрешения конфликтов (если я сам путаю векторы).

Это не «допиливание до идеала». Это поддержание инструмента в рабочем состоянии.

Главное правило использования методики

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

Раздел 12. Заключение: следующий шаг для читателя

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

Я знаю этот путь. Поэтому давай сократим дистанцию.

Главное, что стоит запомнить

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

• Они не заменяют грейды, hard skills или собеседования.

• Они не гарантируют, что человек «идеально подойдёт».

• Они экономят время — твоё, команды, компании — за счёт более точного попадания в мотивацию.

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

С чего начать: чек-лист на первую неделю

Не нужно внедрять методику «на всю компанию». Начни с малого — и масштабируй по мере уверенности.

Всего 6 шагов. Один человек. Одна неделя.

Что делать, если «не получилось»

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

Вместо «всё пропало» спроси себя:

• Что я узнал о человеке, чего не знал раньше?

• Где я сам сбился с нейтрального тона?

• Что стоит изменить в формулировке или тайминге?

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

Где взять материалы

Всё, что нужно для старта, вынесено в приложения:

• Приложение А, Б: строгие критерии векторов (для анализа постфактум)

• Приложение В: чек-лист интервьюера + шпаргалка по маркерам

• Приложение Г: шаблон таблицы результатов и спайдер-диаграммы

• Приложение Д.1, Д.2: 5 дилемм для разработчиков и аналитиков

Не нужно запоминать. Просто держи под рукой.

Последний принцип

Векторы — это начало разговора, а не его конец.

Они дают направление, но не отменяют необходимости:

• Слушать человека в работе, а не только на встрече.

• Учитывать контекст: стек, команду, личные границы.

• Корректировать курс вместе, а не «по диаграмме».

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

Призыв к действию

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

Просто начни.

Сегодня выбери человека. Завтра — проведи встречу. Через неделю — дай ему задачу, которая чуть больше «его». И посмотри, что изменится.

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

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

У тебя всё получится.

Приложения (краткий навигатор)

Приложение А. Строгие критерии векторов для разработчиков

Как использовать: Этот справочник предназначен для пост-анализа. Не держите его в голове во время встречи: во время диалога ориентируйтесь на поведенческие маркеры и энергию собеседника. Строгие критерии нужны только на этапе сопоставления заметок с профилями.

1. Системный (Architectural)

Цель → Определение структурных границ системы, контекстов и долгосрочной целостности решения.
Включает → Декомпозицию на компоненты/сервисы, bounded contexts, архитектурные компромиссы, NFR-ограничения на уровень системы, эволюцию структуры.
Исключает → Пользовательские сценарии, внутреннюю логику вычислений, процессы работы команды, метрики бизнеса.
Текстовые маркеры → граница контекста, разделение ответственности, архитектурный компромисс, масштабируемость системы, долгосрочная поддержка, ADR, NFR.
Типовые артефакты → Context Map, Component Diagram, ADR, High-Level Architecture Spec.
Пример контекста → «Нужно понять, где проходит граница между сервисом заказов и складом, чтобы избежать циклических зависимостей при масштабировании»

2. Прикладной (Functional)

Цель → Точная спецификация наблюдаемого поведения системы для пользователя или внешней роли.
Включает → Пользовательские истории, use cases, шаги взаимодействия, критерии приёмки (DoD/AC), валидацию сценариев.
Исключает → Внутреннюю реализацию, бизнес-метрики, процессы документирования, контракты интеграций.
Текстовые маркеры → пользователь должен, сценарий, шаг, ожидаемый результат, критерий приёмки, верификация, DoD, ТЗ.
Типовые артефакты → User Stories, Acceptance Criteria, Use Case Diagram, Test Scenarios.
Пример контекста → «При оформлении заказа система должна проверять наличие товара и показывать итоговую сумму до перехода к оплате»

3. Инфраструктурный (Platform & Tooling)

Цель → Создание «невидимой» основы: платформы, CI/CD, мониторинг, безопасность. Делает работу других разработчиков быстрее, безопаснее и предсказуемее.
Включает → Настройку пайплайнов, обеспечение инструментами (tooling), self-service платформы, стандартизацию среды, автоматизацию развёртывания.
Исключает → Техническую реализацию бизнес-логики, пользовательские сценарии, метрики продукта, контракты API.
Текстовые маркеры → платформа, CI/CD, автоматизация, tooling, self-service, стандартизация, масштабируемость среды, безопасность.
Типовые артефакты → Pipeline configs (YAML), IaC scripts (Terraform/Ansible), Tooling guidelines, Platform docs.
Пример контекста → «Настроим self-service платформу для развёртывания микросервисов, чтобы команда могла поднимать окружения за 5 минут без участия DevOps»

4. Интеграционный (Contract)

Цель → Надёжное взаимодействие разнородных систем через явные контракты и изоляцию границ.
Включает → API спецификации, маппинг данных, версионирование контрактов, обработку ошибок на стыке, совместимость, адаптеры.
Исключает → Внутреннюю бизнес-логику, пользовательские сценарии, процессы команды, метрики продукта.
Текстовые маркеры → контракт, эндпоинт, формат обмена, маппинг полей, совместимость версий, изоляция сбоев, OpenAPI/SOAP, адаптер.
Типовые артефакты → API Contract, Data Dictionary, Integration Spec, Error Handling Policy.
Пример контекста → «Сервис оплаты должен принимать JSON с полями amount, currency, transaction_id и возвращать статус в соответствии с v2 контракта, иначе — 400 с описанием ошибки»

5. Продуктовый (Value)

Цель → Обоснование целесообразности решения через ценность для пользователя/бизнеса и метрики успеха.
Включает → Гипотезы, приоритизацию по Impact/Effort, метрики (KPI/OKR), CustDev, валидацию спроса, формулировку «зачем».
Исключает → Техническую реализацию, внутренние правила предметной области, стандарты документирования, контракты интеграций.
Текстовые маркеры → зачем это бизнесу, гипотеза, метрика успеха, ценность фичи, приоритизация, валидация, impact/effort, поведение пользователя.
Типовые артефакты → PRD, Hypothesis Statement, Prioritization Matrix, Success Metrics Dashboard.
Пример контекста → «Если добавить one-click оплату, конверсия в покупку вырастет на 12%. Проверим на 20% трафика в течение спринта, прежде чем пилить бэкенд»

6. Доменный (Domain)

Цель → Точное отражение бизнес-реальности, правил, терминологии и регуляторных ограничений в модели.
Включает → Ubiquitous language, бизнес-правила, сущности и их жизненные циклы, согласование с SME, compliance, терминологические словари.
Исключает → Технические архитектурные решения, пользовательские сценарии, инструменты работы команды, интеграционные контракты.
Текстовые маркеры → бизнес-правило, термин, сущность, статус в процессе, согласно регламенту, язык предметной области, комплаенс.
Типовые артефакты → Domain Model, Glossary, Business Rule Catalog, Compliance Checklist.
Пример контекста → «В банковской домене “счёт” не может иметь отрицательный баланс без одобренного овердрафта, это жёсткое регуляторное требование, его нельзя обойти флагом в конфиге»

7. Алгоритмический (Logical)

Цель → Проектирование внутренних вычислений, потоков данных, переходов состояний и оптимизации логики.
Включает → State machines, data flow diagrams, правила трансформации данных, условия ветвления, целостность данных, вычислительную эффективность.
Исключает → Границы системы, пользовательские сценарии, бизнес-метрики, процессы документирования, интеграционные форматы.
Текстовые маркеры → алгоритм, переход состояния, поток данных, условие ветвления, конечный автомат, целостность данных, оптимизация вычислений.
Типовые артефакты → State Diagram, Data Flow Diagram, Pseudocode, Transformation Rules, Logic Tree.
Пример контекста → «При изменении статуса заказа на “Оплачен” запускается цепочка: резерв → инвентарь → уведомление. Если инвентарь < 0, откат транзакции и алерт в лог»

8. Операционный (Operational)

Цель → Гарантия предсказуемой работы, наблюдаемости и восстановления системы в продакшене.
Включает → Требования к логированию, мониторингу, алертингу, SLA/SLO, MTTR, процедуры отката, backup/DR, graceful degradation.
Исключает → Архитектурную декомпозицию, пользовательские сценарии, бизнес-ценность, процессы команды, внутреннюю логику вычислений.
Текстовые маркеры → мониторинг, алёрт, SLA/SLO, MTTR, откат, наблюдаемость, логирование, восстановление, деградация.
Типовые артефакты → Runbook, SLO Definition, Monitoring & Alerting Spec, Rollback Procedure, DR Plan.
Пример контекста → «При отказе внешнего API система должна переходить в режим degraded за 3 сек, писать в dead-letter queue и алертить в Slack, а не висеть в ожидании»

Примечание по применению

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

• Если ответ попадает под несколько векторов, применяйте Протокол разрешения конфликтов (Приложение Б).

• Оценка выставляется по шкале 0–3 на основе инициативности и глубины, а не просто наличия маркеров.

Приложение Б. Критерии векторов для аналитиков и архитекторов + протокол разрешения конфликтов

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

1. Системный (Architectural)

Цель → Проектирование устойчивых границ системы и контекстов, обеспечение долгосрочной целостности архитектуры на этапе требований.
Включает → Декомпозицию на bounded contexts, анализ NFR, архитектурные компромиссы, трассируемость требований к структуре системы, эволюцию модели.
Исключает → Детальную пользовательскую навигацию (UI/UX), внутреннюю реализацию алгоритмов, процессы ведения бэклога, контракты API-интеграций.
Текстовые маркеры → граница контекста, NFR, масштабируемость, архитектурный компромисс, декомпозиция, целостность модели, эволюция системы, ADR.
Типовые артефакты → Context Map, System Context Diagram, NFR Matrix, Architecture Decision Records (ADR), High-Level Requirements Spec.
Пример контекста → «Если мы не зафиксируем границу между модулем “Оплата” и “Склад” сейчас, при добавлении нового способа оплаты придётся переписывать половину требований и ломать трассировку»

2. Прикладной (Functional)

Цель → Точная спецификация наблюдаемого поведения системы для пользователя или внешней роли через понятные и проверяемые артефакты.
Включает → Пользовательские истории, use cases, шаги сценариев, критерии приёмки (DoD/AC), верификацию требований, полноту покрытия сценариев.
Исключает → Внутреннюю архитектуру системы, бизнес-метрики успеха, стандарты оформления документации, маппинг данных между системами.
Текстовые маркеры → пользователь должен, сценарий, шаг, критерий приёмки, DoD, верификация, ТЗ, покрытие сценариев, ожидаемый результат.
Типовые артефакты → User Stories, Use Cases, Acceptance Criteria, Functional Specification, Test Scenarios.
Пример контекста → «Давайте пропишем, что при ошибке валидации система не просто показывает сообщение, но и подсвечивает поле, сохраняет ввод и предлагает исправить — иначе тестировщики будут возвращать задачу по пять раз»

3. Процессный (Process & Tooling)

Цель → Стандартизация и автоматизация работы команды с требованиями и документацией, создание предсказуемых инженерных процессов pre-SDLC.
Включает → Шаблоны требований, правила ведения бэклога, CI/CD для документации, гайдлайны по оформлению, self-service инструменты для команды, управление знаниями.
Исключает → Технические решения самой разрабатываемой системы, бизнес-ценность фич, логику работы продукта, контракты внешних интеграций.
Текстовые маркеры → шаблон, стандарт оформления, автоматизация документации, CI/CD для требований, гайдлайн, tracability, единый источник правды, tooling.
Типовые артефакты → Contribution Guidelines, Doc-as-Code Pipelines, Template Libraries, Knowledge Base Structure, Process Maps.
Пример контекста → «Настроим генерацию спецификаций из Markdown в репозитории, чтобы изменения требований автоматически попадали в пайплайн ревью и у команды всегда была одна версия правды»

4. Интеграционный (Contract)

Цель → Надёжное взаимодействие разнородных систем и стейкхолдеров через явные контракты, маппинг и изоляцию сбоев на уровне интерфейсов.
Включает → Спецификации API, маппинг данных, версионирование контрактов, обработку ошибок на стыке, адаптеры, совместимость форматов.
Исключает → Внутреннюю бизнес-логику модулей, пользовательские сценарии внутри системы, процессы команды, метрики продукта.
Текстовые маркеры → контракт, эндпоинт, маппинг полей, версионирование, изоляция сбоя, OpenAPI/SOAP, адаптер, формат обмена, dead-letter.
Типовые артефакты → API Contract, Data Dictionary, Integration Specification, Error Handling Policy, Interface Agreement.
Пример контекста → «Если внешний сервис вернёт строку вместо числа, мы должны это зафиксировать в контракте и предусмотреть преобразование на нашей стороне — иначе падение будет на продакшене»

5. Продуктовый (Value)

Цель → Обоснование целесообразности решения через ценность для пользователя/бизнеса, метрики успеха и валидацию гипотез.
Включает → Формулировку «зачем», гипотезы, приоритизацию (Impact/Effort), метрики (KPI/OKR), CustDev, анализ поведения пользователя.
Исключает → Техническую реализацию, внутренние правила предметной области, стандарты ведения артефактов, технические контракты интеграций.
Текстовые маркеры → зачем это бизнесу, гипотеза, метрика успеха, ценность фичи, приоритизация, impact/effort, валидация, поведение пользователя.
Типовые артефакты → PRD, Hypothesis Canvas, Prioritization Matrix, Success Metrics Dashboard, Customer Journey Map.
Пример контекста → «Прежде чем описывать фичу “Быстрый заказ”, давайте проверим на данных: если 80% пользователей и так проходят за 3 клика, возможно, нам важнее оптимизировать оплату»

6. Доменный (Domain)

Цель → Точное отражение бизнес-реальности, правил, терминологии и регуляторных ограничений в модели без упрощений.
Включает → Ubiquitous language, бизнес-правила, сущности и их жизненные циклы, согласование с SME, compliance, терминологические словари.
Исключает → Технические архитектурные паттерны, UI-сценарии, инструменты работы команды, форматы интеграционных сообщений.
Текстовые маркеры → бизнес-правило, термин, сущность, статус в процессе, язык предметной области, комплаенс, согласование с экспертом, регламент.
Типовые артефакты → Domain Model, Ubiquitous Language Glossary, Business Rule Catalog, Compliance Checklist, Entity-Relationship Diagram.
Пример контекста → «В страховом домене “полис” не может быть активен без подтверждённой оплаты — это требование регулятора, его нельзя обойти “костылём” в требованиях»

7. Алгоритмический (Logical)

Цель → Проектирование внутренних вычислений, потоков данных, переходов состояний и оптимизации логики процессов.
Включает → State machines, data flow diagrams, правила трансформации данных, условия ветвления, целостность данных, вычислительную эффективность процессов.
Исключает → Границы высокоуровневой системы, пользовательские сценарии, бизнес-метрики, процессы документирования, форматы внешних контрактов.
Текстовые маркеры → поток данных, переход состояния, условие ветвления, конечный автомат, целостность данных, оптимизация процесса, правило трансформации.
Типовые артефакты → State Diagram, Data Flow Diagram, Pseudocode, Transformation Rules, Logic Tree, Process Algorithm Spec.
Пример контекста → «При изменении статуса “Заказ” с “Новый” на “В работе” нужно запустить цепочку: резерв → уведомление → задача исполнителю. Если резерв не прошёл — откатить статус и алертнуть»

8. Операционный (Operational)

Цель → Гарантия предсказуемой работы, наблюдаемости и восстановления системы в продакшене через требования в спецификациях.
Включает → Требования к логированию, мониторингу, алертингу, SLA/SLO, MTTR, процедуры отката, graceful degradation, backup/DR.
Исключает → Архитектурную декомпозицию модулей, пользовательские сценарии, бизнес-ценность, процессы команды, внутреннюю логику вычислений.
Текстовые маркеры → мониторинг, алёрт, SLA/SLO, MTTR, откат, наблюдаемость, логирование, восстановление, деградация, ночной инцидент.
Типовые артефакты → Runbook, SLO Definition, Monitoring & Alerting Spec, Rollback Procedure, DR Plan, Non-Functional Requirements Spec.
Пример контекста → «Если внешний сервис не ответит за 3 секунды, в требованиях должно быть явно прописано: система переходит в деградированный режим, пишет в dead-letter и алертит в Slack — а не висит в ожидании»

Протокол разрешения конфликтов (Disambiguation Rules)

Алгоритм выбора вектора:

1. Выделить ключевую проблему/фокус в ответе.

2. Сопоставить с Текстовыми маркерами каждого вектора.

3. При пересечении тем применить Протокол разрешения конфликтов.

4. Вернуть один основной вектор + опционально один вторичный (если задача комплексная), с кратким обоснованием по правилу из таблицы.

Приложение В. Чек-лист интервьюера + шпаргалка «Быстрые маркеры» + техники возврата к теме

Как использовать: Этот чек-лист — твой «бортовой журнал» на время встречи. Не пытайся оценивать векторы в моменте. Твоя задача: создать атмосферу доверия, слушать, фиксировать ключевые мысли в блокноте и мягко вести диалог. Анализ и выставление баллов — только постфактум.

Чек-лист: до встречи

Чек-лист: во время встречи

Вступление (5–7 мин)

• [ ] Объяснить цель: «Помочь найти задачи, которые будут интересны именно тебе»

• [ ] Снять напряжение: «Это не тест, не экзамен, нет правильных ответов»

• [ ] Договориться о правилах: «Я буду записывать в блокнот, чтобы не упустить важное»

Путь в IT: собеседник (10–15 мин)

• [ ] Дать рассказать свободно, не перебивать

• [ ] Применять активное слушание: кивать, «ага», «понял», «интересно»

• [ ] Задавать уточняющие вопросы только после паузы

• [ ] Если рассказ затягивается — мягко резюмировать и перейти дальше: «Я услышал важные вехи. Чтобы успеть пройти все ситуации, давай зафиксируем: твой фокус сейчас больше в сторону <краткое резюме>, верно?»

Путь в IT: интервьюер (2–3 мин)

• [ ] Кратко поделиться своим путём — для синхронизации терминологии и демонстрации равенства позиций

• [ ] Следить за реакцией: если видишь интерес — можно чуть расширить, если взгляд «плывёт» — свернуть до минимума

Основная часть: 5 дилемм (~35–50 мин)

• [ ] Задавать вопросы строго по списку, без импровизации в формулировках

• [ ] Не перепрыгивать с вопроса на вопрос — дать закончить мысль

• [ ] Фиксировать в блокноте: ключевые слова, цитаты, моменты «загорания» (! или +)

• [ ] Применять техники возврата, если уходит в сторителлинг (см. ниже)

• [ ] После каждого вопроса явно спрашивать: «Есть ли что-то, что ты хотел бы добавить по этой ситуации?»

Завершение (3–5 мин)

• [ ] Дать пространство для «а ещё»: «Мы прошли по всем вопросам. Есть ли что-то, о чём я не спросил, но что для тебя важно?»

• [ ] Чётко обозначить следующие шаги: «Спасибо. Результаты будут на портале. Если появятся мысли постфактум — пиши»

Активное слушание: нельзя / можно

Шпаргалка «Быстрые маркеры» (для фокусировки внимания)

Это не чек-лист для оценки! Не ставь галочки во время разговора. Просто отмечай + в блокноте, если слышишь маркер — для последующего анализа.

Поведенческие маркеры (не слова, а энергия):

• Голос становится увереннее, темп ускоряется → «загорелся»

• Начинает детализировать без подсказки → глубина интереса

• Делает паузу 5–10 сек перед ответом → формулирует честный ответ

• Возвращается к теме, когда разговор уходит в сторону → доминирующий фокус

Техники мягкого возврата к теме

Используй, когда собеседник уходит в долгий сторителлинг или теряет нить вопроса.

Чек-лист: сразу после встречи (пока свежо)

Памятка: главные принципы интервьюера

1. Ты картограф, а не судья. Твоя цель — нарисовать карту интересов, а не вынести вердикт.

2. Пауза — это нормально. Дай человеку 5–10 секунд на формулировку честного ответа.

3. Зеркаль, не интерпретируй. Возвращай смысл его словами, а не навешивай ярлыки.

4. Фиксируй, но не оценивай. Блокнот — для заметок, а не для баллов.

5. Доверяй энергии, а не только словам. Где человек «загорелся» — там его вектор.

Приложение Г. Пример таблицы результатов + шаблон спайдер-диаграммы

Как использовать: Этот шаблон — внутренний рабочий документ руководителя/архитектора. Сотруднику передаётся только визуализация (спайдер-диаграмма) и краткий разговор. Полная таблица с цитатами и обоснованиями остаётся у вас — для принятия кадровых и проектных решений.

Пример таблицы результатов (внутренний формат)

Шаблон спайдер-диаграммы (для передачи сотруднику)

Как читать диаграмму (инструкция для сотрудника)

Этот текст я прилагаю к диаграмме при передаче результатов

Что показывает эта диаграмма:

• Каждый луч — это направление профессионального интереса.

• Чем дальше точка от центра — тем сильнее твой естественный фокус на этой теме.

• Это не оценка навыков, а карта того, где ты получаешь энергию.

Как использовать:

1. Пики (2–3 балла) — твои зоны драйва. Здесь ты будешь делать больше и качественнее, проявлять инициативу, предлагать улучшения.

2. Средние значения (1–2 балла) — зоны компетентности. Ты можешь работать с этими задачами, но без лишнего энтузиазма.

3. Провалы (0–1 балл) — «серые зоны». Здесь ты, скорее всего, будешь работать «по инструкции», без инициативы. Это нормально.

Практический совет:

• Для задач в «серых зонах» составь себе чек-лист: «Если задача про интеграцию — проверяю: контракт зафиксирован? обработка ошибок есть? маппинг данных описан?»

• Не бойся делегировать: если задача требует сильного фокуса в векторе, где у тебя 0–1, попроси помощи у коллеги с пиком в этой зоне.

• Фокусируйся на сильных сторонах — там ты принесёшь максимум ценности.

Важно:

• Диаграмма — это моментальный снимок. Интересы могут меняться со временем.

• Это не приговор, а компас. Контекст (стек, команда, личные границы) всегда важнее профиля.

Шаблон для заполнения (пустая форма)

Подсказка для заполнения:

• Цитаты: выписывай дословно ключевые фразы из ответов — это основа для объективности.

• Обоснование: пиши не «что сказал», а «как и зачем». Что было драйвером? Что детализировал без подсказки?

• Оценка: выставляй постфактум, на свежую голову, сверяясь с критериями (Приложение А/Б).

Рекомендации по визуализации

Если делаешь диаграмму в инструментах (Excel, Miro, Python, JS):

Принято. Ниже готовый Приложение Д.1 — банк вопросов для разработчиков, откалиброванный под выявление векторов интересов.

Приложение Д.1. Банк вопросов для разработчиков: 5 дилемм с fallback-формулировками

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

Вопрос 1. Мотивация: что зажигает

Основная формулировка:

«Вспомните задачу за последний год, которая вас по-настоящему увлекла. Не просто “было интересно”, а когда вы теряли счёт времени или чувствовали азарт. Что именно там было для вас главным драйвером?»

Fallback (если нет примера):

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

Что слушать (кратко):

• На чём человек делает акцент: архитектура, пользователь, данные, процесс, стабильность?

• Что он детализирует без подсказки?

• Где в ответе появляется энергия (темп, жесты, уточнения)?

Вопрос 2. Неопределённость: с чего начать, когда нет ТЗ

Основная формулировка:

«Вам ставят задачу: “Нужно сделать возможность Х для пользователя”, но нет ни ТЗ, ни макетов, ни четких требований. Известно только, что это затронет несколько существующих модулей и внешнюю систему. Опишите ваш порядок действий в первые 24 часа. С чего начнёте и какие решения примете до написания кода?»

Fallback (если человек теряется):

«Если сложно вспомнить конкретный случай, опишите ваш общий алгоритм: что вы делаете первым, вторым, третьим, когда на входе только “хотелка”?»

Что слушать (кратко):

• С чего начинает: с границ системы, с пользователя, с контрактов, с метрик?

• Что считает «решением»: документ, прототип, обсуждение, код?

• Как относится к неопределённости: как к проблеме или как к пространству для манёвра?

Вопрос 3. Инициатива: что улучшать, если есть свободное время

Основная формулировка:

«Представьте, что у вас есть 10–20% рабочего времени на улучшение проекта по вашему усмотрению. Это не исправление багов, а именно улучшение. Что вы выберете и почему?»

Fallback (если человек не может выбрать):

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

Что слушать (кратко):

• Что человек считает «улучшением»: код, документацию, процессы, пользовательский опыт?

• Предлагает ли он что-то, что принесёт пользу команде, а не только ему?

• Есть ли в ответе проактивность или только реактивные идеи («исправить то, что мешает»)?

Вопрос 4. Адаптивность: новый инструмент — необходимость или интерес

Основная формулировка:

«Расскажите о ситуации, когда вам пришлось использовать технологию, подход или инструмент, с которыми вы раньше не работали. Что вами двигало: необходимость (задача вынудила) или интерес (захотелось попробовать)? Как изучали?»

Fallback (если нет опыта):

«Если такого случая ещё не было, представьте: вам предлагают освоить новый стек для перспективного проекта. Что для вас будет главным аргументом “за”: интерес к технологии, карьерные перспективы, команда или что-то ещё?»

Что слушать (кратко):

• Источник мотивации: вынужденное обучение или искреннее любопытство?

• Как подходит к изучению: системно (доки, туториалы, пет-проект) или ситуативно («по ходу разберусь»)?

• Говорит ли о том, как применил новое в работе, или только о факте освоения?

Вопрос 5. Хаос: работа с чужим наследием и нестабильными системами

Основная формулировка:

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

Fallback (если человек не сталкивался):

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

Что слушать (кратко):

• Фокус на надёжность, маппинг, изоляцию сбоев или на быстрое «склеивание»?

• Упоминает ли контракты, обработку ошибок, деградацию, логирование?

• Видит ли он задачу как техническую проблему или как коммуникационный вызов?

Общие правила работы с вопросами

Приложение Д.2. Банк вопросов для аналитиков/архитекторов: 5 дилемм с fallback-формулировками

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

Вопрос 1. Структурирование неопределённости в артефакты

Основная формулировка:

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

Fallback (если нет примера):

«Если такого кейса не было, опишите ваш пошаговый алгоритм действий в подобной ситуации.»

Что слушать (кратко):

• С чего начинает: с людей (интервью), с документов (анализ), с прототипа (эксперимент)?

• Какие артефакты выбирает и почему: BPMN для процессов, ER для данных, OpenAPI для контрактов?

• Что считает главным результатом: консенсус стейкхолдеров, технически корректная модель, трассируемость?

Вопрос 2. Конфликт ТЗ и бизнес-целесообразности

Основная формулировка:

«Бывало ли, что формальное ТЗ или требование заказчика вело к избыточно сложному, дорогому или бесполезному с точки зрения реальной эксплуатации решению? Как вы действовали: строго следовали документу, предлагали альтернативу или упрощали? Чем руководствовались при выборе (метрики, риски поддержки, скорость вывода, ограничения платформы)?»

Fallback (если примера нет):

«Если примера нет, как бы вы аргументировали отказ от “красивого”, но непрактичного решения перед заказчиком или командой?»

Что слушать (кратко):

• Как определяет «бесполезность»: через TCO, риски, UX, технический долг?

• Источник аргументации: данные, экспертное мнение, личный опыт, интуиция?

• Коммуникативная стратегия: диалог, демонстрация альтернатив, эскалация?

Вопрос 3. Управление изменениями и traceability

Основная формулировка:

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

Fallback (если опыта не было):

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

Что слушать (кратко):

• Подход к impact-анализу: формальные методы (матрицы, графы) или эвристики?

• Отношение к версиям артефактов: рутина или сбой?

• Как транслирует последствия: через количественные оценки (задержки, бюджет) или качественные аргументы?

Вопрос 4. Граница между «идеальной моделью» и «поставкой»

Основная формулировка:

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

Fallback (если примера нет):

«Если примера нет, опишите, где для вас проходит граница между “достаточно хорошо для сдачи” и “недопустимо упрощённо”.»

Что слушать (кратко):

• Критерии для упрощения: сроки, бюджет, критичность функционала, риски техдолга?

• Как валидирует принятые решения: ревью с командой, чек-листы рисков, пост-релизный мониторинг?

• Внутренняя мотивация: удовлетворение от «идеального» решения или ценность доставки работающего продукта?

Вопрос 5. Стратегия погружения и верификации гипотез

Основная формулировка:

«Представьте, что вы подключаетесь к новому проекту с незнакомой предметной областью и технологиями. Опишите ваши первые три–пять дней: с кем и в каком порядке вы начнёте общаться? Какие документы, доступы или инструменты запросите в первую очередь? Как будете проверять свои предположения о том, как система работает на самом деле?»

Fallback (если опыт ограничен):

«Если опыт ограничен, опишите ваш идеальный план погружения в такой проект.»

Что слушать (кратко):

• Приоритизация контактов: заказчик → команда → пользователи (или иная последовательность)?

• Какие артефакты запрашивает в первую очередь: документация, доступы, логи, метрики?

• Подход к верификации гипотез: быстрые эксперименты, прототипы, интервью, анализ данных?

Общие правила работы с вопросами

Быстрые маркеры для аналитиков (шпаргалка)

Это не чек-лист для оценки! Просто отмечай + в блокноте, если слышишь маркер — для последующего анализа.

Поведенческие маркеры (не слова, а энергия):

• Голос становится увереннее, темп ускоряется → «загорелся»

• Начинает детализировать артефакты без подсказки → глубина интереса

• Делает паузу 5–10 сек перед ответом → формулирует честный ответ

• Возвращается к теме, когда разговор уходит в сторону → доминирующий фокус