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

Личное мнение руководителя отдела ИИ, основанное на опыте найма в команду на 15 000+ сотрудников и прохождения технических интервью в ведущих компаниях с 2021 года.

---

Введение: Парадокс разработки ИИ

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

Как руководитель отдела искусственного интеллекта, создавший направление с нуля в холдинге на 15 000+ сотрудников и запустивший 5 ИИ-продуктов в production, я вижу эту проблему системно. Она начинается не с кода, а с момента, когда мы решаем, кто будет писать этот код.

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

---

Этап 1: Формирование «Ядра» (Внутренний выбор) — Детализация

1.1 Выбор исполнителей: Паттерны против Компетенций

Вам наверняка встречалась такая ситуация: люди, работающие над проектами на C++, C#, Java, Go, начинают прорабатывать тему ИИ, потому что они «в принципе программисты». И действительно, они могут «докопаться» до интересных решений.

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

Когда я создавал отдел ИИ, я видел, как сильные backend-разработчики тратили месяцы на то, что Data Scientist делает за неделю. Не потому что они «слабые», а потому что их паттерны мышления заточены под детерминированную логику, а не под вероятностные модели.

1.2 Быстрое решение: Прототип ≠ Передача знаний

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

Конечно, будет здорово, если у команды получится создать работающий продукт. Но чтобы обладать этими целями, нужно иметь понимание, как создаются нейросети. А большая часть людей просто умеет пользоваться готовыми инструментами (ChatGPT, AutoML), и то не всегда корректно.

«Наем — это не просто заполнение вакансии. Это стратегическое решение, которое влияет на культуру и продуктивность команды на годы вперед» — Google re:Work, Guide: Interviewing.

1.3 Статус команды: Профессиональная замыленность

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

Но выгодополучатели от бизнеса не хотят этого понять.

Почему? Потому что у них нет такого паттерна в опыте. Эти самые люди, когда-то начинавшие с минимального, добились того, что теперь они — собственники бизнеса. И они думают: «Если я смог, значит, и все вокруг тоже готовы так действовать».

Это называется профессиональная замыленность — перекладывание личного опыта на всех остальных.

---

Этап 2: Кризис ответственности при найме

Именно здесь возникает переломный момент. «Ядро» начинает набирать сотрудников себе в помощь.

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

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

• Результат: Команда выбирает не самого эффективного специалиста, а того, с кем удобно работать.

---

Этап 3: Парадокс HR-компетенций

Критическая ошибка заключается в непрофессиональном проведении собеседований на технические роли.

• Формальный подход: HR-специалисты часто некомпетентны в предметной области (например, найм руководителя направления ИИ). Они читают вопросы по бумажке и ждут совпадения ответов, как программный робот.

• Источник вопросов: Парадокс в том, что вопросы для HR-сотрудника часто составляют люди с меньшими компетенциями, чем те, кого они нанимают.

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

---

Этап 4: Инженерия против Ремесла (Аналогия со стройкой) + Китайская пословица

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

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

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

• Ошибка масштаба: Когда этого мастера пытаются взять в инженеры для строительства пятиэтажного дома, он часто думает, что инженерия — это просто. «Зачем сидеть в институте 6 лет? Нужно просто работать руками и знать, как класть кирпич».

• Реальность: Мы никогда не доверим такому специалисту строительство многоквартирного дома. Для этого требуется инженер-проектировщик, который рассчитает нагрузки. Иначе дом будет либо слишком дорогим, либо ненадежным. Жить в этом доме не строителю, поэтому его ошибка стоит слишком дорого.

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

Здесь уместно вспомнить классную китайскую пословицу:

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

В контексте найма это означает следующее:

Проблема: На собеседовании мастера своего дела (те, кто уже в команде) начинают проверять инженера на то, как он «копает ямы». И инженер, конечно, проваливается.

• Он копает медленно.

• Он копает неумело.

• У него нет сноровки в этом (или он её потерял, так как не использует).

Но это совершенно не говорит о том, что он не способен:

• Создать интересный проект дома.

• Рассчитать все необходимые нагрузки.

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

---

Кейс из практики: Дипломный проект «Умный дом» (2020-2021)

На примере моего проекта «Умный дом» (распознавание голосовых команд в обычных диалогах) это видно особенно четко.

Что делал «Ремесленник» (подход копи-паст)

Что делал «Инженер» (мой подход к проекту)

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

Почему это важно для найма?

Если бы на собеседовании в команду ИИ меня проверяли на:

• ❌ «Как быстро напишешь код на Python?»

• ❌ «Какую библиотеку используешь для загрузки данных?»

• ❌ «Реши задачу на LeetCode за 30 минут»

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

Нужно проверять:

• ✅ «Как ты выбираешь архитектуру под ограничения оборудования?»

• ✅ «Как ты работаешь с зашумленными данными?»

• ✅ «Как ты планируешь масштабирование с 1 устройства на 15 000+ сотрудников?»

• ✅ «Как ты интегрируешь ИИ с legacy-системами (1С, API, RBAC)?»

---

Этап 5: Личный опыт найма и собеседований

За свои 15 лет в управлении и 6 лет в AI я прошел путь с обеих сторон баррикад.

Опыт прохождения интервью (с 2021 года)

Я проходил технические собеседования в крупные технологические компании, включая:

• Сбер — подразделение ИИ-разработки

• Яндекс — команды машинного обучения

• Альфа-банк — финтех-направления

• РЖД — подразделения, занимающиеся разработкой технологий искусственного интеллекта

• Другие крупные компании и госструктуры (не будем перечислять, так как это не важно для сути статьи)

Что я видел:

«Эффективные менеджеры фокусируются на результатах и empower команды, а не на микроменеджменте технических деталей» — Google Project Oxygen.

Это подтверждает тезис: HR и Владелец продукта должны понимать разницу между результатом (продукт) и процессом (код).

---

Решение: HR как Владелец продукта и Инженерный подход

Чтобы избежать тупика, необходимо изменить подход к найму:

1. Соучастие в продукте: Сотрудник по найму персонала (HR) должен выступать как Владелец продукта. Он должен нести ответственность за то, как нанятый сотрудник повлияет на результат.

2. Разделение ролей: Необходимо четко разделять понятия «Специалист» (исполнитель, ремесленник) и «Инженер» (архитектор, проектировщик). На руководящие позиции в ИИ нужно нанимать инженеров.

3. Директивное право: HR должен иметь право директивно говорить команде: «Этот человек будет работать у вас», исходя из интересов бизнеса, а не комфорта команды.

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

---

Заключение: Мы едим хлеб, а не смотрим на замешивание теста

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

Мы должны руководствоваться достижением цели, а не удобством процессов.

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

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

Как руководитель отдела ИИ с опытом внедрения решений в холдинге на 15 000+ сотрудников, я вижу, что только системный инженерный подход спасает проекты от превращения в «дорогой гараж».

---

📚 Список рекомендуемых источников

1. Google re:Work — Guide: Interviewing
О чем: Исследование о том, почему структурированные интервью эффективнее задач на логику.
Цитата: «Наем — это не просто заполнение вакансии. Это стратегическое решение…»
Ссылка: rework.withgoogle.com/guides/hiring-structure-interviews/
2. Project Oxygen (Google)
О чем: Исследование качеств эффективных менеджеров.
Цитата: «Эффективные менеджеры фокусируются на результатах…»
Ссылка: rework.withgoogle.com/print/guides/5721450383183872/
3. Китайская пословица о лягушке и дереве
О чем: Метафора о том, что нельзя оценивать компетенции человека по нерелевантным критериям.
Тема: Используется в HR для иллюстрации проблемы mismatch между навыками и требованиями.
4. Презентация проекта SmartHome (2020-2021гг)
О чем: Дипломный проект по распознаванию голосовых команд в обычных диалогах.
Тема: CNN Conv1D, обучение в Google Colab, точность 94.06% на валидации, 620+ звуковых файлов.
Ссылка: GitHub: AlekseyVB/SmartHome