Профиль должности и критерии отбора

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

Бизнес Должностная инструкция HR chatgpt claude gemini grok

// промпт

Ты — HR-бизнес-партнёр, который помогает руководителям сформулировать, кого именно они ищут, до того как вакансия уйдёт в публикацию. Ты знаешь, что большинство неудачных наймов начинается с размытого профиля: «нужен сильный специалист» без понимания, что он должен сделать. Составь профиль должности. **Параметры** - Должность: {{dolznost}} - Подразделение и кому подчиняется: {{podrazdelenie_i_rukovoditel}} - Почему открывается позиция и что не работает сейчас: {{pricina_otkrytiia}} - Что человек должен сделать за первый год: {{zadaci_na_pervyi_god}} - Команда и условия работы: {{komanda_i_kontekst}} **Как действовать** 1. Сформулируй назначение должности одним-двумя предложениями: какую проблему бизнеса решает эта роль. 2. Переведи задачи в 4–6 измеримых результатов на 3, 6 и 12 месяцев. Если задача не измеряется, предложи, по какому признаку руководитель поймёт, что она выполнена. 3. Выдели ключевые обязанности и полномочия: что человек решает сам, что согласует, за что отвечает. 4. Определи 5–7 компетенций, нужных именно для этих результатов. Для каждой опиши, как она выглядит в поведении на уровне «хорошо» и на уровне «недостаточно». 5. Раздели требования на обязательные и желательные. Убери требования, которые не следуют из результатов, — например стаж «от 5 лет» там, где важен конкретный опыт. 6. Сформулируй критерии отбора: на каком этапе и каким способом проверять каждую компетенцию. 7. Отметь противоречия в запросе, если они есть: результаты не сходятся с уровнем полномочий, ожидания не соответствуют уровню должности. **Формат ответа** Документ с разделами «Назначение должности», «Результаты по срокам», «Обязанности и полномочия», «Компетенции» (таблица: компетенция — признаки «хорошо» — признаки «недостаточно»), «Требования», «Как проверяем». В конце — вопросы, которые стоит обсудить с руководителем, если они остались.

Заполните переменные

Должность

Подразделение и руководитель

Причина открытия

Задачи на первый год

Команда и контекст

Пример запуска

Сгенерировано Claude Opus 5.5, 20 октября 2026 г.

Значения переменных

Должность: Руководитель отдела клиентской поддержки
Подразделение и руководитель: Отдел клиентской поддержки (12 человек), подчиняется операционному директору (COO) компании «Флоу Систем» — разработчик SaaS-платформы для управления складской логистикой
Причина открытия: Предыдущий руководитель отдела уволился 3 месяца назад после конфликта с продуктовой командой. Сейчас отделом временно управляет тимлид первой линии, но она не справляется с нагрузкой: SLA по ответу просел с 90% до 61%, текучка в команде поддержки за полгода — 40%, жалобы на поддержку в NPS-опросах выросли втрое. Клиенты крупных тарифов (enterprise) начали эскалировать проблемы напрямую к COO
Задачи на первый год: 1. Первые 90 дней: провести аудит текущих процессов поддержки (тикет-система Zendesk, маршрутизация обращений, база знаний), выявить причины провала SLA. Стабилизировать SLA по первому ответу до 85% и выше, снизить время решения тикетов 1-й линии с текущих 18 часов до 8 часов. 2. Первые 90 дней: закрыть две открытые вакансии на 1-й линии поддержки и остановить текучку — удержать не менее 80% текущего состава команды. 3. 6 месяцев: внедрить систему метрик качества поддержки (CSAT после закрытия тикета, FCR — доля решения с первого контакта) и выйти на CSAT не ниже 4,2 из 5. 4. 6 месяцев: выстроить процесс эскалации для enterprise-клиентов так, чтобы критичные обращения доходили до профильных инженеров за 1 час, а не терялись в очереди — измеримо: 0 эскалаций к COO за квартал. 5. 12 месяцев: построить базу знаний и систему онбординга новых сотрудников поддержки так, чтобы время выхода нового агента на целевую производительность сократилось с 3 месяцев до 6 недель. 6. 12 месяцев: подготовить и защитить перед COO план развития отдела на следующий год, включая оргструктуру (разделение на 1-ю и 2-ю линии), бюджет и целевые показатели SLA/CSAT.
Команда и контекст: В подчинении 12 человек: 9 агентов 1-й линии поддержки (все работают удалённо, в разных часовых поясах — от Калининграда до Новосибирска), 2 тимлида смен и 1 специалист по базе знаний. Работа организована в три смены для покрытия поддержки с 7:00 до 23:00 по московскому времени, по будням; в выходные дежурит один агент по графику. Основные инструменты: Zendesk для тикетов, Confluence для базы знаний, Slack для внутренней координации, amoCRM используется отделом продаж и частично пересекается с поддержкой по передаче клиентов. Отдел физически распределён, общего офиса нет, раз в квартал — выездная встреча команды в Москве за счёт компании. Бюджет на найм и обучение в первый год — 2,4 млн рублей, согласован отдельно с финансовым директором. Отдел тесно взаимодействует с продуктовой командой (передача багов) и с отделом продаж (передача жалоб от ключевых клиентов), но прямого влияния на roadmap продукта у руководителя поддержки нет — приоритеты багов утверждает продуктовый директор.

Профиль должности: Руководитель отдела клиентской поддержки

Компания: «Флоу Систем» (SaaS для управления складской логистикой) Подразделение: Отдел клиентской поддержки, 12 человек Подчинение: операционный директор (COO) Статус документа: черновик для согласования с COO до публикации вакансии

1. Назначение должности

Роль нужна, чтобы вывести поддержку из кризиса: вернуть сервис в рамки SLA, остановить уход людей и перестать терять доверие enterprise-клиентов. После этого руководитель превращает отдел из «пожарной команды» в управляемую систему с метриками, процессами эскалации и планом роста. Главный признак успеха: COO больше не узнаёт о проблемах клиентов напрямую от клиентов.

2. Результаты по срокам

Сводная таблица

№	Результат	Метрика	Сейчас	Цель	Срок	Как измеряем
1	Восстановлен уровень сервиса 1-й линии	SLA по первому ответу	61%	≥ 85%	90 дней	Отчёт Zendesk, среднее за последние 4 недели периода
		Время решения тикета 1-й линии (медиана)	18 ч	≤ 8 ч	90 дней	Отчёт Zendesk; тикеты, переданные в продукт как баги, считаются отдельно
2	Команда стабилизирована и укомплектована	Закрытые вакансии 1-й линии	0 из 2	2 из 2 (оффер принят, человек вышел)	90 дней	Данные HR
		Удержание текущего состава	—	≥ 80% (не менее 10 из 12)	90 дней, затем ежеквартально	Данные HR; добровольные и вынужденные уходы считаются раздельно
3	Работает система метрик качества	CSAT после закрытия тикета	не измеряется	≥ 4,2 из 5	6 месяцев	Опрос в Zendesk, ≥ 20% откликов от закрытых тикетов
		FCR (решение с первого контакта)	не измеряется	замер базы к 3 мес., цель согласуется с COO	6 месяцев	Zendesk, единая методика подсчёта
4	Enterprise-эскалации проходят по процессу, а не через COO	Критичное обращение enterprise-клиента у профильного инженера	теряются в очереди	≤ 1 часа в ≥ 95% случаев	6 месяцев	Отдельная очередь/тег в Zendesk, отчёт по времени передачи
		Эскалации клиентов к COO	регулярно	0 за квартал	3-й квартал работы	Журнал эскалаций COO
5	Новички выходят на производительность быстрее	Время выхода агента на целевую производительность	~3 месяца	≤ 6 недель	12 месяцев	Норма производительности фиксируется к 6 мес.; замер на когорте новых сотрудников
6	Есть утверждённый план развития отдела	План на следующий год	нет	защищён и утверждён COO	12 месяцев	Документ: оргструктура (1-я/2-я линия), бюджет, цели SLA/CSAT, план найма

Контрольные точки по этапам

30 дней

Аудит готов: маршрутизация, нагрузка по сменам, структура очередей в Zendesk, состояние базы знаний в Confluence, передачи в продукт и продажи.
Названы 3–5 главных причин провала SLA, и они подтверждены данными, а не мнениями.
Проведены встречи один на один со всеми 12 сотрудниками, составлена карта рисков ухода.
Согласован план на 90 дней с COO.
Признак выполнения: COO может пересказать, почему просел SLA, и видит, какие действия это исправят.

90 дней: результаты 1 и 2. Начат замер CSAT и FCR, есть черновик процесса enterprise-эскалации.

6 месяцев: результаты 3 и 4. Метрики выведены на дашборд, который COO смотрит без помощи руководителя поддержки.

12 месяцев: результаты 5 и 6. SLA и CSAT держатся на целевом уровне не меньше двух кварталов подряд.

3. Обязанности и полномочия

Ключевые обязанности

Операционное управление поддержкой: маршрутизация, очереди, графики смен с 7:00 до 23:00 МСК и дежурств в выходные, контроль SLA.
Управление командой: найм, адаптация, развитие, оценка, удержание 12 сотрудников в разных часовых поясах. Руководство двумя тимлидами смен и специалистом по базе знаний.
Качество сервиса: внедрение CSAT и FCR, регулярный разбор качества ответов, работа с негативными отзывами из NPS.
Enterprise-эскалации: процесс приоритизации, канал к инженерам, личное участие в критичных случаях.
Межфункциональное взаимодействие:
- с продуктом: формат и критерии передачи багов, обратная связь о частых проблемах клиентов;
- с продажами: передача жалоб ключевых клиентов, разграничение зон в amoCRM и Zendesk.
База знаний и онбординг: внутренняя и клиентская база знаний, программа адаптации новых агентов.
Планирование: бюджет отдела в пределах согласованного, план развития на следующий год.

Полномочия

Решает сам	Согласует	Не решает (зона других)
Правила маршрутизации, очереди, макросы и автоматизации в Zendesk	С COO: изменения численности и оргструктуры	Приоритеты багов и roadmap продукта (решает продуктовый директор)
Графики смен и дежурств, распределение нагрузки	С COO: перераспределение бюджета между статьями, траты сверх 2,4 млн	Условия договоров и SLA в контрактах с клиентами (продажи/юристы)
Окончательный выбор кандидатов на вакансии 1-й линии в рамках бюджета и штата	С COO: увольнения по инициативе работодателя, изменения в оплате и грейдах	Работа инженеров вне согласованного процесса эскалации
Цели, оценка, развивающие задачи для сотрудников отдела	С продуктовым директором: критерии критичности багов, порядок передачи, время реакции инженеров
Стандарты базы знаний и программы онбординга	С коммерческим директором: регламент передачи клиентов и жалоб между продажами и поддержкой
Распределение бюджета на обучение внутри согласованной статьи

Зона ответственности

SLA по первому ответу, время решения 1-й линии, CSAT, FCR, удержание и укомплектованность команды, соблюдение процесса enterprise-эскалации со стороны поддержки, сроки адаптации новичков, исполнение бюджета найма и обучения.

4. Компетенции

Компетенция	Признаки «хорошо»	Признаки «недостаточно»
1. Операционная диагностика и управление по данным	Начинает с цифр: распределение тикетов по часам и типам, нагрузка на агента, где тикет теряет время. Отличает причину от симптома: «SLA падает не потому, что мало людей, а потому, что вечерняя смена получает 40% потока при 20% состава». Строит дашборды, по которым решения принимаются без него. Знает, как настраивать Zendesk или аналог: триггеры, SLA-политики, представления.	Сразу говорит «нужно больше людей». Опирается на ощущения и жалобы, а не на отчёты. Метрики «смотрит», но не может объяснить, какие решения по ним принял. Настройку системы делегирует целиком и не понимает логику маршрутизации.
2. Управление распределённой командой и удержание	Выстраивает регулярный ритм: встречи один на один, командные синки, понятные цели у каждого. Работает с причинами ухода (нагрузка, график, отсутствие роста, токсичные эскалации), а не только с зарплатой. Опирается на тимлидов и развивает их. Учитывает часовые пояса при планировании встреч и смен.	Управляет через контроль активности («кто сколько онлайн»). Узнаёт об уходе сотрудника из заявления. Делает всё сам в обход тимлидов. Не может назвать конкретных людей, которых вырастил.
3. Влияние без формальной власти (продукт, продажи)	Приходит к продукту с данными: «этот баг — 14% обращений enterprise за месяц». Договаривается о регламенте (OLA), а не о разовых одолжениях. Удерживает позицию клиента и не скатывается в конфликт. Умеет эскалировать к COO вовремя и аргументированно.	Воспринимает продукт как «тех, кто не чинит». Эскалирует всё подряд или, наоборот, молча терпит. Конфликты переходят в личную плоскость. В примерах из прошлого виноваты всегда «смежники».
4. Работа с enterprise-клиентами и кризисными ситуациями	Сам ведёт разговор с раздражённым ключевым клиентом: признаёт проблему, даёт конкретный план и сроки, держит слово. Выстраивает процесс так, чтобы критичное обращение распознавалось автоматически. Различает «критично для клиента» и «громко сказано».	Обещает клиенту то, что не контролирует (сроки исправления бага). Каждую эскалацию решает вручную, и процесс не появляется. Избегает прямого контакта с клиентом и перекладывает его на тимлидов или продажи.
5. Построение систем (база знаний, онбординг)	Превращает знания из голов опытных агентов в структуру: статьи, сценарии, чек-листы адаптации. Задаёт критерий «агент готов» и измеряет его. Знания обновляются по процессу, а не «когда дойдут руки».	Онбординг = «посиди рядом с опытным коллегой». База знаний существует, но ей никто не пользуется, и причину он не знает. Не может описать, как понять, что новичок вышел на норму.
6. Найм	Чётко формулирует профиль агента. Проводит структурированные интервью с практическим заданием. Закрывает линейные вакансии за 4–6 недель. Анализирует, почему ушли нанятые им люди.	Нанимает «по ощущению». Затягивает найм в поисках идеального кандидата или берёт первого, кто пришёл. Не связывает качество найма с последующей текучкой.
7. Планирование и защита решений перед руководством	Строит план с расчётом: сколько обращений, сколько людей на какой линии, сколько это стоит, что получит бизнес. Готовит варианты с разной стоимостью. Говорит с COO языком бизнес-эффекта (удержание клиентов, отток).	Просит ресурсы без расчёта эффекта. План — набор пожеланий без цифр. Не может объяснить, что будет, если бюджет урежут на 30%.

5. Требования

Обязательные

Опыт руководства командой поддержки от 8 человек (непосредственно или через тимлидов) не менее 2 лет. Важны масштаб и длительность, а не общий стаж.
Опыт поддержки B2B-продукта, желательно SaaS, со сложными клиентскими запросами. Чисто B2C-поддержка с массовыми однотипными обращениями будет недостаточна.
Доказуемый опыт улучшения метрик поддержки (SLA, время решения, CSAT, FCR): кандидат может назвать цифры «было — стало» и объяснить, за счёт чего.
Опыт руководства удалённой или распределённой командой.
Опыт выстраивания процесса с продуктовой или инженерной командой: передача багов, эскалации, согласованные сроки реакции.
Уверенная работа с тикет-системой (Zendesk или аналог: Freshdesk, Jira Service Management, Intercom, Usedesk) на уровне настройки маршрутизации, SLA-политик и отчётов.
Опыт найма в свою команду.

Желательные

Опыт именно в Zendesk.
Опыт вывода отдела из кризиса: падение метрик, высокая текучка, смена руководителя.
Опыт работы с enterprise-клиентами или аккаунтами с отдельным SLA.
Опыт разделения поддержки на линии (1-я/2-я) или проектирования оргструктуры отдела.
Опыт построения базы знаний и программ онбординга.
Понимание складской логистики, WMS или B2B-логистических продуктов.
Опыт управления бюджетом отдела.

Что сознательно не включаем

«Стаж от 5 лет»: из результатов следует нужный опыт, а не количество лет.
Высшее образование определённого профиля: на результаты не влияет.
Знание amoCRM и Confluence как обязательное: осваивается за 1–2 недели.
Проживание в Москве: команда распределена, достаточно готовности к ежеквартальным выездам.
Английский язык: не следует из задач. Включить, только если есть иностранные клиенты.

6. Как проверяем

Этапы отбора

Этап	Кто проводит	Формат	Что проверяем
1. Скрининг резюме	HR	По обязательным требованиям	Масштаб команды, B2B, наличие цифр в достижениях
2. Первичное интервью (45 мин)	HR	Структурированное интервью	Мотивация, причины перехода, ожидания по условиям, базовая проверка 2, 6
3. Интервью с COO (60–90 мин)	COO + HR	Поведенческое интервью (STAR)	1, 2, 4, 7
4. Кейс (домашнее задание + защита 60 мин)	COO + текущий тимлид или специалист по базе знаний	Анализ обезличенных данных Zendesk «Флоу Систем» и план на 90 дней	1, 5, 7
5. Встреча с продуктовым директором (45 мин)	Продуктовый директор	Интервью + ролевая ситуация	3
6. Встреча с тимлидами (30–45 мин, по желанию)	2 тимлида смен	Неформальная беседа	Впечатление команды, совместимость; без права вето
7. Рекомендации	HR	2–3 звонка (бывший руководитель, подчинённый, коллега из смежного отдела)	2, 3, подтверждение заявленных результатов

Проверка по компетенциям

Компетенция	Где	Как именно
1. Диагностика и данные	Кейс, интервью с COO	Кейс: выгрузка за 3 месяца (объём по часам и каналам, SLA по сменам, время решения, распределение по категориям). Просим назвать 3 главные причины провала SLA и первые шаги. Хорошо: гипотезы опираются на данные, кандидат говорит, каких данных не хватает. Вопрос: «Расскажите о случае, когда метрика поддержки резко ухудшилась. Как вы нашли причину?»
2. Распределённая команда, удержание	Интервью с COO, рекомендации	«Расскажите о ситуации, когда из вашей команды начали уходить люди. Что вы сделали и каков результат?» «Как вы понимаете, что удалённому сотруднику плохо, до того как он напишет заявление?» В рекомендациях спрашиваем подчинённого о стиле управления.
3. Влияние без власти	Встреча с продуктовым директором, рекомендации	Ролевая ситуация: «Enterprise-клиент третью неделю страдает от бага, продукт поставил его в бэклог на следующий квартал. Ваши действия?» Хорошо: данные о масштабе, договорённость о процессе, аргументированная эскалация. Плохо: давление, обвинения, бездействие. Вопрос: «Расскажите о конфликте с продуктом или разработкой. Чем закончился?» Продуктовый директор оценивает: «смогу ли я с этим человеком работать».
4. Enterprise и кризисы	Интервью с COO	«Опишите самый тяжёлый разговор с ключевым клиентом. Что вы ему обещали и выполнили ли?» Можно ролевую ситуацию: COO в роли недовольного директора склада клиента.
5. Системы (БЗ, онбординг)	Кейс (дополнительный вопрос), интервью	«Как вы определяете, что новый агент вышел на целевую производительность?» «Покажите или опишите программу онбординга, которую вы строили. Сколько длился выход на норму до и после?»
6. Найм	Интервью с HR / COO	«Как вы проводите интервью с агентом поддержки? Какое задание даёте?» «Сколько человек вы наняли за последний год и сколько из них осталось?»
7. Планирование и защита	Защита кейса	На защите COO спрашивает: «Что вы сделаете, если бюджет будет в два раза меньше?» и «Как вы поймёте через 90 дней, что план работает?» Хорошо: приоритизация, понятные контрольные точки, честность о рисках.

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

7. Противоречия и риски в запросе

1. Ключевые результаты зависят от продукта, на который у роли нет полномочий. Цели «критичное обращение у инженера за 1 час», «0 эскалаций к COO» и отчасти «время решения 8 часов» требуют, чтобы инженеры реагировали быстро. Приоритеты разработки при этом утверждает продуктовый директор. Предыдущий руководитель ушёл именно после конфликта с продуктом. Без изменения правил новый руководитель попадёт в ту же ловушку. Рекомендация: до выхода человека (или в первые 30 дней при участии COO) закрепить OLA между поддержкой и продуктом: дежурный инженер для критичных enterprise-обращений, время реакции, критерии критичности, порядок арбитража при споре через COO. Цель 1 часа сформулировать так: «поддержка передаёт за ≤ 15 мин, инженер берёт в работу за ≤ 45 мин по OLA».

2. План на 90 дней перегружен. За три месяца человек должен провести аудит, поднять SLA на 24 п.п., сократить время решения более чем вдвое, закрыть две вакансии и удержать команду. При этом новые агенты сами выходят на норму 3 месяца, так что в первые 90 дней они скорее добавят нагрузку, чем снимут. Рекомендация: поэтапные цели. На 90 дней: SLA ≥ 75%, время решения ≤ 12 ч. На 150 дней: SLA ≥ 85%, ≤ 8 ч. Либо сохранить цели, но явно признать их амбициозными при оценке испытательного срока.

3. Цель по удержанию может мешать наведению порядка. «Удержать 80% состава» не различает ценных сотрудников и тех, с кем, возможно, нужно расстаться из-за качества работы. Рекомендация: измерять добровольные уходы ценных сотрудников (regretted attrition), а не уходы в целом.

4. «0 эскалаций к COO» — бинарная цель, которую контролирует не только руководитель поддержки. У enterprise-клиентов есть прямой контакт COO. Один звонок по проблеме, которую поддержка не может решить (например, продуктовый баг), означает провал цели. Рекомендация: основная метрика — доля критичных обращений, прошедших по процессу в срок (≥ 95%). Эскалации к COO разбирать по причинам: «процесс не сработал» или «проблема вне зоны поддержки». Также договориться, что COO сам перенаправляет клиентов в процесс, а не решает вопрос в обход него.

5. Часы покрытия не совпадают с ожиданиями enterprise-клиентов. Поддержка работает по будням с 7:00 до 23:00 МСК, в выходные дежурит один агент. Склады часто работают круглосуточно и без выходных. Непонятно, в какие часы действует цель «1 час до инженера» и кто реагирует на критичный инцидент ночью. Рекомендация: уточнить, что обещано enterprise-клиентам в договорах, и при необходимости включить вопрос о расширении покрытия в годовой план.

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

7. Метрики без базы и определений.

«SLA по ответу» — какой норматив времени первого ответа, одинаковый ли для всех тарифов?
CSAT и FCR не измеряются, поэтому цель 4,2 ставится без знания текущего уровня.
Целевая производительность агента не определена, значит «6 недель» пока не с чем сравнить.

8. Судьба временного руководителя. Тимлид первой линии, которая сейчас управляет отделом, — ключевой человек для удержания. Если с ней не поговорить заранее, есть риск её ухода после назначения нового руководителя. Это сразу ударит по цели в 80%.

8. Вопросы для обсуждения с COO

Готовы ли вы вместе с продуктовым директором закрепить OLA по реакции инженеров на критичные enterprise-обращения до выхода нового руководителя? Кто арбитр при споре о приоритете бага?
Что конкретно произошло в конфликте предыдущего руководителя с продуктом? Что изменилось с тех пор, чтобы ситуация не повторилась?
Цели на 90 дней — обязательные (по ним решается прохождение испытательного срока) или ориентир? Готовы ли рассмотреть поэтапные цели?
Какой норматив стоит за «SLA по первому ответу»? Различается ли он для enterprise и остальных тарифов?
Что прописано в договорах enterprise-клиентов о часах поддержки и времени реакции? Нужна ли круглосуточная поддержка для критичных инцидентов?
Что входит в бюджет 2,4 млн: только подбор и обучение или также зарплаты новых сотрудников? Из какого бюджета оплачиваются выездные встречи?
Какая вилка компенсации у позиции? Она определяет, кого мы сможем привлечь: руководителя с опытом вывода отдела из кризиса или сильного тимлида, готового к росту.
Какую роль после назначения нового руководителя получит тимлид, которая сейчас временно управляет отделом? Говорили ли с ней об этом?
Готовы ли вы перенаправлять enterprise-клиентов, которые звонят вам напрямую, в процесс эскалации, а не решать вопросы сами?
Будет ли у нового руководителя право голоса (не решающего) при планировании продуктовых приоритетов, например регулярный слот на продуктовом комитете с данными об обращениях?
Есть ли у вас уже понимание, нужна ли 2-я линия, или это открытый вопрос, на который должен ответить новый руководитель?