--- title: "Senior Unity Developer Platform Team - Azur Games" date: 2026-07-05 summary: "Подготовка к техническому интервью в Azur Games на позицию Senior Unity Developer в Platform team." tags: ["карьера", "интервью", "unity", "platform", "azur-games"] build: render: never list: never publishResources: false --- # Senior Unity Developer Platform Team - Azur Games ## Контекст интервью - Интервью: вторник, 2026-07-07, 16:00 МСК. - Длительность: 1.5 часа. - Участники: CTO и Delivery Manager. - Позиция: Senior Unity Developer, Platform team. - Контекст компании: мобильный f2p-издатель и разработчик, много внутренних и партнерских проектов, общие решения для разных команд. ## Карта роли Описание вакансии используем как маршрутную карту подготовки: - Разработка общих Unity-модулей, плагинов и платформенных решений. - Доставка контента, автоматизация процессов, удаленные конфиги, аналитика, платежные системы. - TeamCity Unity CI/CD: автосборки, автоматизированный деплой, процессы доставки билдов. - Упаковка внутренних решений в UPM-пакеты, поддержка и обновления. - Консультации игровых команд по багфиксам и оптимизации: профайлинг, поиск узких мест, аналитика/статистика, предложения решений. - Анализ текущих внутренних решений и актуальных решений на рынке. Ожидают: - 4+ года коммерческой Unity/C# разработки в gamedev. - Собственные инструменты, которые ускоряют или упрощают работу Unity-команд. - Нативный или близкий к нативному опыт под Android/iOS. - CI/CD, особенно TeamCity. - Unity Package Manager. - SDK-интеграции: аналитика, реклама, платежи. - ООП, паттерны, анти-паттерны Unity-приложений. - DevOps: контейнеризация, Docker, GitHub Actions/workflows. Плюсы: - Самостоятельное ведение задач полного цикла: требования, архитектура, реализация, сопровождение в продакшене. - Продакшен-опыт с AI/мультиагентными системами: оркестрация, маршрутизация, supervisor-паттерны, передача задачи между агентами, управление состоянием. - Backend/инструменты на Kotlin, Python, Go. ## Как пользоваться перед интервью Не читать весь файл. Идти сверху вниз по `Outputs`: 1. Самопрезентация. 2. Три STAR-истории. 3. SDK и честные пробелы. 4. Delivery/behavior. 5. Вопросы им. Главный принцип: не рассказывать “что делал”, а показывать, какую боль снял, почему это было важно и что стало лучше для команды/релиза/продукта. ## Outputs Этот раздел - источник правды для финальных формулировок, которые берем на интервью. ### Ответ на "Расскажите о себе" Я Линар, Software Engineer. Работал над мобильными, PC и web-проектами: делал core- и meta-фичи, UI, оптимизацию, SDK-интеграции, внутренние инструменты, CI/CD и автотесты. Со временем меня все сильнее потянуло в платформенные и инфраструктурные задачи. Мне интересно брать повторяющиеся боли команды - сборки, тесты, интеграции, дублирование логики, ручные процессы - и превращать их в инструменты, модули или улучшения процесса. При этом я стараюсь думать не только технически, но и продуктово: какую проблему решаем, сколько стоит решение, какие риски снимаем и как это влияет на скорость разработки и релиза. Помимо работы, я веду свои проекты и портфолио: пробую стеки, проверяю гипотезы, проектирую с использованием AI, делаю web/tooling-эксперименты, моды и прототипы. Раньше писал технические статьи по Unity UI и архитектуре. Проекты, статьи и коммерческие кейсы собраны на сайте linar.games. Поэтому вакансия в Platform team мне очень близка. ### STAR: инфраструктура автотестов и GitLab CI Использовать для вопросов: - "Расскажите про самый сильный инфраструктурный или платформенный инструмент." - "Какой CI/CD опыт у вас был в Unity?" - "Как вы снижали регрессии и ручную работу команды?" #### Короткий ответ на 20 секунд Я оживил Unity-автотесты как рабочий инструмент команды: упростил запуск на CI, разделил обычные проверки кода и проверки игровой логики, добавил автоматический прогон параллельно сборке и оформил понятную инструкцию для разработчиков и QA. #### Полная версия на 1.5-2 минуты **Situation / Context** У меня было два похожих опыта. В Heroes of Artadis была система записи, запуска и просмотра результатов игровых сценариев. Потом в Berserk Heroes Online я занимался похожим направлением уже через NUnit, GitLab CI/CD, отдельные джобы, артефакты и отображение результатов. В Berserk Heroes Online Unity-тесты формально уже были заведены, но в живой процесс команды почти не были встроены: их редко запускали, категории были неочевидными, а CI не давал стабильного и понятного сигнала. По сути, нужно было не просто "добавить тесты", а воскресить их как рабочий инструмент для разработки и релиза. Для карточной игры это особенно важно: много игровой логики, квестов, боевых сценариев, данных и комбинаций состояний, поэтому регрессии могут появляться неожиданно. **Task** Нужно было превратить существующие, но почти неиспользуемые Unity-тесты в понятный и полезный CI-процесс: чтобы они реально запускались на билдмашине, категории отражали текущую структуру тестов, результаты было видно, а QA и разработчики могли меньше полагаться на ручную регрессию. **Action** Я разобрал, как тесты реально компилируются и запускаются на билдмашине, убрал лишние исторические шаги и упростил пайплайн. Потом привел в порядок категории: отделил обычные тесты кода от проверок игровой логики, чтобы команда понимала, что и когда запускать. На уровне GitLab разделил ручной и автоматический запуск, добавил отдельную джобу с автотестами параллельно сборке и настроил запуск на нужных ветках/расписаниях. Также настроил вывод результатов и артефактов в GitLab и оформил короткую техдоку/инструкцию для команды. **Result** Получилась понятная схема: сборка и тесты идут параллельно и не удлиняют пайплайн лишней последовательностью; быстрые проверки страхуют обычные программистские поломки, а проверки игровой логики можно запускать отдельно, когда нужно глубже проверить сценарии. Для команды это снизило ручную регрессию, сделало прохождение тестов обязательной частью процесса слияния изменений и дало понятный сигнал: если тесты падают, на это обращают внимание и реагируют. Для QA это меньше ручной проверки, для разработчиков - более быстрая обратная связь, для релиза - меньше риск тихо сломать старую игровую логику. **Learning / что бы улучшил сейчас** Если развивать это дальше как платформенное решение, я бы добавил более удобные отчеты, учет нестабильных тестов, разделение быстрых smoke-тестов и тяжелых регрессионных тестов, а также метрики по времени выполнения и причинам падений. При этом мы были ограничены возможностями бесплатной версии GitLab. В более расширенной версии или на более гибкой CI-платформе я бы отдельно посмотрел на более удобные отчеты, правила обязательных проверок и аналитику по стабильности тестов. ### STAR: выделение общей логики квестов и кастомизации Использовать для вопросов: - "Был ли опыт выделения общего решения в модуль или пакет?" - "Как вы боролись с дублированием логики?" - "Какой у вас опыт проектирования расширяемых игровых систем?" #### Короткий ответ на 20 секунд В Berserk Heroes Online я занимался выделением повторяющейся логики квестов, кастомизации и разблокированных предметов в более общие модули. Например, квесты были сильно завязаны на Battle Pass, и я отрефакторил систему так, чтобы квестовая логика стала гибче, расширялась отдельно и могла переиспользоваться в других игровых модулях. #### Полная версия на 1.5-2 минуты **Situation / Context** В Berserk Heroes Online продуктовая команда пришла с болью: квесты работали странно, их было сложно тестировать, сложно расширять и почти невозможно переиспользовать в других игровых модулях. Одна из причин была в том, что квесты сильно завязались на Battle Pass, хотя сама квестовая логика была полезна шире и уже нужна была другим механикам. **Task** Нужно было не просто "почистить код", а решить продуктовую и техническую проблему: отделить доменную логику от конкретной фичи, сделать систему расширяемой, тестируемой и пригодной для переиспользования. **Action** Сначала я сел и спроектировал новую архитектуру: как будет работать квестовая система, какие в ней будут правила, где проходят границы ответственности и как она учитывает будущие фичи. После этого показал подход команде и уже потом начал реализацию, а не просто "рефакторинг ради рефакторинга". Я отрефакторил квестовую часть так, чтобы она меньше зависела от Battle Pass и стала отдельной переиспользуемой системой: задачи, прогресс и условия можно было расширять и использовать в других сценариях. Параллельно мы упростили структуру конфигов: убрали неактуальные поля и лишние части, чтобы геймдизайнерам было проще заводить и настраивать квесты. Я написал отдельные редакторы и документацию. Для кастомизации и разблокированных предметов подход был похожий: выделить общий модуль, который отвечает за состояние и доступность предметов. Отдельно мы продумали миграцию для Battle Pass, чтобы после отделения квестовой логики существующий прогресс игроков не терялся. Это не был полноценный UPM-пакет с registry/versioning, но инженерно задача была близкая: выделить границы, зависимости, публичный API и сценарии использования. **Result** Систему стало проще расширять, тестировать отдельно и использовать не только в Battle Pass, но и в других игровых механиках, которые уже ждали эту общую основу. Для команды это означало меньше дублирования, меньше риска расхождения правил между фичами и безопасную миграцию существующего прогресса. Для геймдизайнеров тоже стало проще: меньше лишних полей в конфигах, понятнее настройка, есть редакторы и документация. Команда ГД отдельно отмечала, что с этим стало удобнее работать. **Learning / что бы улучшил сейчас** Если развивать это дальше как платформенное решение, я бы оформлял такие модули с более явным публичным API, документацией по подключению, тестами на ключевые сценарии и понятной стратегией версионирования. Следующим шагом это можно было бы упаковать в UPM-пакет или хотя бы в более формальный внутренний модуль с changelog и правилами обновления. ### STAR: оптимизация Merge Punk Использовать для вопросов: - "Как вы подходите к оптимизации Unity-проектов?" - "Был ли опыт профилирования и поиска узких мест?" - "Как вы консультировали бы команду по производительности?" #### Короткий ответ на 20 секунд В Merge Punk я занимался оптимизацией мобильного клиента: профилировал FPS, GC Allocations, рендеринг и сетевые запросы. В результате FPS вырос с 30 до стабильных 60, сетевой трафик снизился примерно на 50%, а memory traffic с ~10 KB per frame ушел почти до нуля. #### Полная версия на 1.5-2 минуты **Situation / Context** Merge Punk был мобильным проектом, и перед soft launch было важно, чтобы игра стабильно работала в том числе на слабых устройствах. Это напрямую влияло на пользовательский опыт и ретеншен. Были проблемы с FPS, аллокациями, рендерингом и сетевым трафиком. **Task** Нужно было не просто "ускорить игру", а найти конкретные узкие места и предложить изменения, которые дадут измеримый эффект. **Action** Я начал с профилирования: смотрел FPS, эффекты, рендеринг, GC Allocations и горячие места в клиентской логике. Использовал инструменты Unity, а также JetBrains dotMemory/dotTrace для анализа памяти и производительности C#/.NET-кода. Отдельно разобрал сетевую часть: построил sequence diagram, что, когда и зачем клиент отправляет на сервер. После этого предложил оптимизацию: объединить часть запросов, сократить количество GET/POST-вызовов, убрать лишние данные и почистить формат обмена. В итоге стало быстрее и чище с точки зрения API. **Result** В результате FPS на мобильных устройствах вырос с 30 до стабильных 60. Сетевой трафик снизился примерно на 50%. Memory traffic снизился примерно с 10 KB per frame почти до нуля. Для продукта это означало более стабильный клиент перед soft launch, лучшее поведение на слабых устройствах и меньше технических рисков для удержания игроков. **Learning / что бы улучшил сейчас** Я бы и сейчас шел тем же путем: сначала симптом и целевая метрика, потом профилирование, затем минимальные изменения с замером до/после. Для платформенной команды я бы дополнительно оформлял такие находки в checklist или guideline для других проектов. ### SDK-интеграции: короткий ответ Использовать для вопросов: - "С какими SDK вы работали?" - "Где приходилось разбираться глубже стандартной интеграции?" - "Как бы вы делали общий SDK-модуль для проектов?" #### Короткий ответ на 40-60 секунд Я работал с разными SDK в Unity-проектах: Google Play Games, Facebook SDK, Firebase и разными аналитическими SDK. Также работал с Azur SDK; отдельно запомнилось, что GDPR/consent flow там сделан удобно: подключение достаточно прямолинейное, и в среднем система работает предсказуемо. Кроме игровых SDK, у меня был опыт с платежными интеграциями: Yandex Pay, ЮKassa, Точка Банк, плюс общее знакомство с эквайрингом. Это не всегда было именно внутри Unity, но полезно для понимания платежных сценариев, API, статусов, ошибок и бизнес-рисков. В одном из кейсов бизнес пришел с задачей для мобильной версии: нужно было понять, какие SDK и требования нужны издателям, как это удобнее встроить в проект и как не привязаться к одному конкретному поставщику. Я изучал требования, смотрел варианты интеграции и делал более гибкую, заменяемую систему для SDK, чтобы отдельные интеграции можно было подключать и менять без сильного влияния на остальной клиент. С этим же была связана работа с профилями сборки под разные версии проекта: PC, Android Store, iOS и другие варианты дистрибуции. Я настраивал разные конфигурации через defines и параметры сборки, а также связывал это с GitLab CI job'ами, чтобы нужные SDK, настройки и сценарии сборки включались для правильной платформы/стора. #### Честная граница Я бы разделял: я не позиционирую себя как полноценного Android/iOS native-разработчика на Kotlin/Swift. Мой основной опыт - Unity-side SDK integrations и близкая к нативной часть: зависимости, настройки сборки, порядок инициализации, аналитика, платежи, GDPR/consent и диагностика проблем сборки/рантайма. ### Delivery Manager: требования, риски, команды Использовать для вопросов: - "Как вы работаете с расплывчатыми требованиями?" - "Как сообщаете о рисках и задержках?" - "Как работаете с несколькими командами?" - "Как избегаете избыточной архитектуры?" #### Расплывчатые требования Когда ко мне приходят геймдизайнер, QA, продюсер или другой заинтересованный человек с задачей или проблемой, я сначала стараюсь понять цель: что должно происходить, зачем это нужно, что важно, а что можно упростить или отложить. После этого смотрю на технический контекст и обычно предлагаю несколько вариантов: минимальный, средний и более правильный/долгосрочный. Для каждого стараюсь обозначить стоимость, риски, ограничения и то, какие corner cases мы закрываем сразу, а какие можем оставить на следующую итерацию. Мне важно не просто "сделать как попросили", а понять, какую проблему решаем и какой вариант сейчас выгоднее для продукта и команды. #### Риски и задержки Если на этапе декомпозиции или реализации я понимаю, что задача не укладывается в сроки или сложнее, чем казалось, я стараюсь сообщать об этом заранее. Обычно я не прихожу просто с проблемой, а предлагаю варианты: что обязательно нужно оставить, что можно срезать, что можно вынести в следующую итерацию, и какие риски будут у каждого решения. Дальше это можно обсуждать с продуктом или бизнесом уже не абстрактно, а через последствия для релиза, качества и стоимости. #### Работа с несколькими командами Если задача затрагивает несколько людей или команд, я стараюсь держать коммуникацию прозрачной: договориться о владельцах, поставить созвон, если он нужен, зафиксировать решения и не оставлять людей в подвешенном состоянии. Когда я веду фичу или техническое решение, я отношусь к нему как technical owner. Если моя фича работает плохо, ломается или создает проблемы другим, я не отстраняюсь, а разбираюсь, почему так происходит, и довожу до исправления. #### Как избегаю избыточной архитектуры Я стараюсь отталкиваться от того, что мы делаем сейчас и насколько вероятно, что это будет развиваться дальше. Если задача одноразовая и мы понимаем, что она не будет расширяться, можно сделать проще и не строить большую архитектуру. Если же видно, что проблема повторяется, затрагивает несколько фич или в будущем станет основой для других задач, тогда стоит заложить более аккуратную архитектуру, модульность и понятные правила расширения. Для меня хороший баланс - не делать "идеальную систему на всякий случай", но и не экономить так, чтобы через пару релизов команда уперлась в дорогой переписанный костыль. ### Честные ответы по пробелам Использовать, если прямо спрашивают про TeamCity, UPM, native Android/iOS, Docker или AI. Главный принцип: не оправдываться и не преувеличивать. Говорить честно: где был практический опыт, где был опыт пользователя, где смежная база, а где зона для углубления. #### TeamCity С TeamCity я работал как пользователь на проекте, где он уже был настроен, но не был владельцем пайплайнов. Основной практический CI/CD опыт у меня в GitLab CI и GitHub Actions: автосборки, тестовые job'ы, артефакты, параметры сборки, профили под платформы и сторы. TeamCity как конкретный инструмент мне нужно будет освежить, но сам класс задач понятен: агенты, шаги, триггеры, переменные, артефакты, цепочки сборок. #### UPM UPM я использовал как пользователь: устанавливал пакеты, подключал зависимости, работал с пакетами в Unity-проектах. Очень давно пробовал собирать свои небольшие пакеты, но это не был большой production-процесс с registry и поддержкой для многих команд. Более сильный мой опыт - выделение внутренних переиспользуемых модулей: границы ответственности, зависимости, публичный API, сценарии использования. UPM для меня выглядит как следующий слой упаковки над этой же инженерной задачей. #### Native Android/iOS Я не позиционирую себя как полноценного Android/iOS native-разработчика. Основной опыт - мобильные SDK-интеграции со стороны Unity: зависимости, настройки сборки, порядок инициализации, аналитика, платежи, GDPR/consent и диагностика проблем сборки/рантайма. С Android-стороной немного знаком через Java и понимание структуры Android-проектов, но глубокая Kotlin/Swift native-разработка - не моя основная зона. #### Docker Docker использовал в своих проектах, например для чатов, мессенджеров и других сервисных/экспериментальных проектов. Это не была моя основная зона в коммерческой Unity-разработке, но базово я понимаю контейнеризацию и воспроизводимые окружения. #### AI / мультиагентные системы Production multi-agent systems для пользователей я пока не выводил. При этом давно изучаю тему AI и использую AI как инженерный инструмент: для проектирования, документации, code review flows, skills/instructions и ускорения разработки. Мне интересна эта область, но без фанатизма: вижу ценность там, где AI реально снижает рутину, помогает с анализом, ревью, поиском по знаниям проекта или внутренними инструментами. ### Вопросы им Цель вопросов - показать, что мне интересны не только технологии, но и реальные боли Platform team, пользователи платформенных решений, ожидания от роли и будущее команды. #### Приоритет 1 - спросить обязательно 1. Какую проблему вы хотите закрыть этим наймом в первую очередь? Что должно измениться для команд, когда человек выйдет на эту роль? 2. Что вы бы считали хорошим результатом для человека на этой позиции в первые 1-3 месяца? 3. По каким признакам вы понимаете, что Platform team работает хорошо? Есть ли у вас метрики: скорость интеграций, стабильность билдов, количество support-запросов, adoption общих SDK/пакетов, скорость релизов? 4. Какие цели у Platform team на ближайший квартал и на год? Какие направления вы хотите развить сильнее всего? #### Приоритет 2 - если есть еще время 5. Какая сейчас самая болезненная зона для Platform team: CI/CD, SDK-интеграции, remote config, аналитика, платежи, content delivery или оптимизация проектов? 6. Кто основные пользователи решений Platform team: внутренние команды, партнерские студии или и те и другие? Насколько решения должны быть self-service? 7. Как у вас обычно выглядит путь общего решения: от боли конкретной команды до SDK/UPM-пакета, релиза, миграции и поддержки? 8. Пользуетесь ли вы уже AI-агентами или AI-инструментами внутри разработки? Если да, где они реально помогают: код-ревью, документация, поиск по знаниям проекта, анализ логов, поддержка SDK, автотесты, CI/CD? 9. Как вы видите развитие этой роли в будущем: больше SDK/CI/CD/tooling, больше консультаций команд, больше архитектуры общих решений или что-то еще? 10. Какие возможности для роста есть внутри команды? Может ли человек в этой роли со временем вырасти в sub lead / lead-направление, если берет ownership, помогает другим командам и развивает общие решения? #### Приоритет 3 - по ситуации - Какая у вас сейчас команда по составу и зонам ответственности? Как распределены SDK, CI/CD, UPM, support игровых команд и новые платформенные решения? - Какую инженерную культуру вы хотите развивать внутри Platform team: больше продуктового ownership, больше стандартизации, больше R&D, больше self-service для команд? - Какой у вас vision для Platform team на 1-2 года: стать внутренней SDK/tooling-командой, центром экспертизы для игровых проектов, platform product-командой или чем-то другим? - Как вы балансируете стандартизацию общих решений и свободу отдельных игровых команд? - Насколько много в этой роли поддержки существующих проектов по сравнению с разработкой новых общих решений? - Как у вас устроен жизненный цикл UPM-пакетов: версионирование, changelog, миграции, обратная совместимость? - Какие сейчас основные боли в Unity CI/CD: скорость сборок, стабильность агентов, тесты, деплой, профили сборок? - Если смотреть на AI как на часть platform/tooling-направления, какие процессы вы бы хотели автоматизировать в первую очередь, но пока не нашли хороший формат? - Был ли недавно заметный инцидент или неудачный кейс в платформенной зоне: интеграция, билд, SDK, пакет, поддержка команды? Что вы после этого поменяли в процессе или архитектуре? #### По контексту компании - Azur Analytics выросла из внутреннего решения во внешний продукт. Есть ли у Platform team похожий фокус: делать внутренние решения, которые потом можно масштабировать на партнерские студии? - С учетом новых prediction platform-проектов роль Platform team остается в основном Unity/game-focused или становится шире: SDK, аналитика, платежи, tooling для разных продуктов? - Когда внутреннее решение начинает использовать много команд, что обычно становится самым сложным: API, миграции, документация, поддержка или adoption? - Вы видите Platform team больше как внутреннюю Unity-инфраструктуру или как команду, которая со временем делает platform products для многих студий? #### Если времени мало Если осталось 2 минуты: 1. Какую проблему вы хотите закрыть этим наймом в первую очередь? Если осталось 5 минут: 1. Какую проблему вы хотите закрыть этим наймом в первую очередь? 2. Что вы бы считали хорошим результатом в первые 1-3 месяца? 3. По каким признакам вы понимаете, что Platform team работает хорошо? Если осталось 10 минут: 1. Какую проблему вы хотите закрыть этим наймом в первую очередь? 2. Что вы бы считали хорошим результатом в первые 1-3 месяца? 3. По каким признакам вы понимаете, что Platform team работает хорошо? 4. Какая сейчас самая болезненная зона для Platform team? 5. Какие возможности для роста есть внутри команды? Может ли эта роль вырасти в sub lead / lead-направление? ### Сложные поведенческие вопросы Использовать для вопросов: - "Почему ушли с прошлого места?" - "Бывали ли конфликты с руководителем или командой?" - "Как вы работаете с фидбэком?" #### Почему ушел / что не сошлось Короткая безопасная версия: > На прошлом месте в какой-то момент стало понятно, что у нас с руководителем расходятся ожидания по стилю работы, коммуникации и критериям качества. Я не хочу переводить это в личную историю или обвинять кого-то: скорее это был несовпавший рабочий контекст. Для себя я вынес важный вывод: ожидания по качеству, формату коммуникации, уровню самостоятельности и критериям готовности задачи лучше проговаривать раньше и явнее. Если нужно добавить позитивный вывод: > Я в целом инициативный человек: много предлагаю, подсвечиваю проблемы, стараюсь улучшать проект и процессы вокруг него. Это сильная сторона, но я понимаю, что инициативу важно правильно синхронизировать с ожиданиями команды и руководителя. Сейчас я стараюсь заранее проговаривать, что считается хорошим результатом, какие риски критичны, где нужна быстрая итерация, а где лучше заранее попросить ревью или согласование. Чего не говорить: - "CTO был неправ." - "Ему не нравилось, как я работаю." - "Мы не сошлись характерами." - "У меня были проблемы с коммуникацией." #### Конфликты в команде > Для меня конфликты почти всегда про ожидания и их несовпадение: по срокам, качеству, приоритетам, коммуникации или границам ответственности. Я стараюсь сначала отделить факты от эмоций: что именно не работает, кто чего ожидал, на кого это влияет, какой риск для продукта или релиза. > Дальше стараюсь перевести разговор в варианты решения: что можно быстро исправить, что нужно обсудить с продуктом, где нужен компромисс, а где есть технический риск, который нельзя игнорировать. Если я сам неправ или что-то недокоммуницировал, я нормально принимаю это и корректирую подход. #### Как работаю с фидбэком > Фидбэк я стараюсь воспринимать как инструмент синхронизации ожиданий, а не как личную атаку. Если фидбэк конкретный, я уточняю, какое поведение или результат нужно изменить, и стараюсь договориться о понятном критерии: что в следующий раз будет считаться хорошо. > Если фидбэк общий, например "качество не то" или "коммуникации не хватает", я задаю уточняющие вопросы: где именно проблема, какой пример, какой ожидаемый уровень, что лучше делать иначе. Мне важно превратить фидбэк в действие, а не оставить его на уровне ощущения.