Как сделать вакансию максимально недоступной для кандидатов? Небольшой кейс из LinkedIn. Рекрутер публикует вакансию Head of QA. Подробное описание, требования, условия релокации. В конце поста приглашение: «For questions or to apply, please contact me via direct message.» Казалось бы, все просто. Но есть нюанс. 🔒 Комментарии к публикации отключены. Задать вопрос под постом невозможно. 🔒 Личные сообщения тоже недоступны, если вы не в контактах рекрутера. Получается интересная воронка найма: 1. Увидел вакансию. 2. Захотел откликнуться. 3. Написать комментарий нельзя. 4. Написать в личку нельзя. 5. Отправляешь запрос на добавление в контакты и надеешься, что его примут. (Мой запрос на добавление в контакты к этому рекрутеру кажется уже пару недель висит 🤪) И все это ради возможности просто отправить резюме. Особенно забавно, что речь идет о вакансии Head of Quality Assurance. Мы в QA постоянно говорим о пользовательских сценариях, доступности, UX и проверке критических путей. А тут критический путь «кандидат → отклик» не проходит даже smoke-тест 😳 Интересно, кто-нибудь тестирует процесс отклика на вакансии перед публикацией? #QA #найм #LinkedIn #pro_qa #багивокругнас

Сегодня менти, с которой работаю в формате сопровождения (подготовка к интервью, аудит знаний, помощь с резюме, помощь в разборе вакансий, где-то заход в компании не на холодную и тп), получила оффер - что не может не радовать! На всякий случай уточню, а то бывает, что заходят с запросами доведения до оффера, оплата после получения, 1я зп в качестве оплаты (как у волков) и тп - таким не занимаюсь. Помогаю исключительно в формате почасовой работы. А кто говорит, что предоставляет гарантированный результат в плане трудоустройства - лукавит)) PS. у меня, кстати, пара мест на сопровождение появилось - сегодня-завтра повешу анонс на эту тему. #qa #pro_qa #ментор #наставник

|Критерий|RACI|RASCI|RAC-VS|RAPID| |---|---|---|---|---| |Основной фокус|Ответственность|Ответственность и поддержка|Проверка и утверждение|Принятие решений| |Отдельная поддержка|Нет|Да|Нет|Нет| |Отдельная верификация|Нет|Нет|Да|Нет| |Формальное утверждение|Не выделено|Не выделено|Да|Через Agree / Decide| |Финальное право решения|Не детализировано|Не детализировано|Не основной фокус|Да| |Сложность внедрения|Низкая|Низкая–средняя|Средняя–высокая|Средняя–высокая| ## 6. Что выбрать для QA и Engineering Management? Я бы ориентировался не на популярность модели, а на проблему, которую нужно решить. Ситуация 1. Непонятно, кто отвечает за качество релиза. Начните с RACI. Определите владельцев процессов, исполнителей и тех, кто должен участвовать в обсуждении. Ситуация 2. QA постоянно зависит от DevOps, разработчиков и инфраструктуры. Используйте RASCI. Она помогает зафиксировать обязательную поддержку и не превращать каждую зависимость в неформальную просьбу. Ситуация 3. Релизы требуют проверок, аудита и формальных разрешений. Рассмотрите RAC-VS. Она позволяет отдельно закрепить проверку соответствия требованиям и право утверждения. Ситуация 4. QA говорит «релизить нельзя», Product говорит «релизим», а решение зависает. Используйте RAPID. Зафиксируйте, кто оценивает риски, кто предоставляет данные, чьё согласие обязательно и кто принимает окончательное решение. ## 7. Можно ли комбинировать модели? Да. Более того, для крупных IT-организаций это часто разумнее, чем пытаться описать всё одной матрицей. Например: - RACI — для распределения ответственности между Engineering, QA и Product. - RASCI — для операционных процессов, зависящих от инфраструктуры. - RAC-VS — для процессов проверки и формального утверждения релизов. - RAPID — для решений о запуске, переносе релиза, принятии технического долга и выборе архитектуры. Главное — не пытаться внедрить все модели сразу. Начните с одного проблемного процесса. Опишите его участников и реальные полномочия. Проверьте, исчезла ли неопределённость. Если матрица существует только в Confluence и никто не использует её при работе, пользы от неё не будет. --- ## Вывод RACI отвечает на вопрос: кто делает и кто отвечает? RASCI: кто делает, кто отвечает и кто помогает? RAC-VS: кто делает, кто проверяет и кто утверждает? RAPID: кто рекомендует, кто согласует и кто принимает решение? Для QA-руководителя ключевой момент — ответственность за качество не равна полномочию принимать решение о релизе. QA может отвечать за тестирование, проверку критериев качества и информирование о рисках. Но решение о выпуске продукта может принадлежать совсем другой роли. И это нормально, если границы ответственности и полномочий определены заранее. А у вас в командах ответственность и право принятия решений формализованы или всё ещё работают по принципу «кто громче сказал, тот и решил»? #management #QA #QALead #EngineeringManagement #RACI #RAPID Отдельно для публикации в @pro_qa: я бы сохранил примеры из QA и релизного процесса — они делают различия между моделями конкретными. При этом стоит подчеркнуть, что RACI и RASCI широко распространены, RAPID имеет определённую методологию Bain, а RAC-VS — менее унифицированная модификация, которую нельзя подавать как единый общепринятый стандарт. Источники для проверки терминологии: [Atlassian — RACI](https://www.atlassian.com/work-management/project-management/raci-chart?utm_source=chatgpt.com), [Bain — RAPID Decision Making](https://www.bain.com/insights/rapid-decision-making/?utm_source=chatgpt.com).