Инженер и Менеджер

Если вы думали, что найм сломан, то у меня для вас новость. Его скоро доломают окончательно. Шведский стартап Fika прям щас строит платформу для собеседований. Но так как мы живем в 2026-ом, то без ИИ не обойдется: на платформе соискателя будет собеседовать ИИ. И не просто собеседовать, а на обязательном видео-звонке. Работать будет так: 1. Вы обнаруживаете в себе тягу в скором времени поменять рабочее место 2. Вы откликаетесь на вакуху в линкедине 2. Fika читает ваш профиль и составляет список вопросов под вас 3. Fika назначает вам звонок 4. На звонке вас опрашивает Gemini-модель. Но это еще не самое проклятое. Самое проклятое в финале: Fika нарезает интервью на ШОРТСЫ и отправляет работодателю. Непонятно, на что расчет: типа, зумеры-руководители не смогут посмотреть 10 минут интервью не через шортсы? Fika подняли 4 миллиона долларов на пре-сид раунде. Венчурные дядьки такие суммы пацанам с улицы не дают. Это не мелочь. По меркам венчура в 2026 — это прям выше среднего. Венчурные дядьки почуяли иксы, поэтому стартап точно продолжит расти в ближайшее время. Но — поводов расстраиваться нам с вами я не вижу. Fika может стать (а может и не стать) хорошим инструментом в потоковом найме. Но до ИТ оно вряд ли докатится. Fika это решение для массового найма с похожими требованиями. Для найма кадров с высокой квалификацией, использовать Fika — стрелять себе в ногу. Безусловно: желающие пальнуть себе в ногу всегда найдутся. Даже очередь может образоваться. Если вдруг не верите, вспомните недавнюю попытку индустрии считать продуктивность разработчиков через потраченные токены. Но системно Fika у нас не приживется. Сами подумайте: если компания начинает общение с хорошим инженером через заход «Поговори с нашим ИИ, а мы потом посмотрим нарезку шортсов с тобой» — захочет ли инженер тратить время на такую компанию? Вот и я думаю, что нет.

Я попробовал Claude/GPT/etc и сделал за вечер то, что раньше целая команда делала неделю В том или ином виде я эту фразу слышу по всей индустрии. И я ее искренне не люблю по двум причинам: • Это правда • Это не вся правда Где правда: Claude или Codex действительно позволяют одному человеку собрать за вечер то, на что раньше у команды уходили дни. Такую правду любят рассказывать на конференциях или строить на ней крайне амбициозные планы. Полезная правда. Но есть ма-а-аленький нюанс. Полностью цитата должна звучать так: Я за вечер собрал прототип, который целая команда собирала неделю Потому что в 95% случаев рассказчик имеет в виду «У меня получилось собрать первое рабочее решение». Но если вы когда-то писали код, вы знаете, что между «первым рабочим решением» и «можно катить решение в прод» пропасть, которая доверху заполнена коммитами final_fix, final_final_fix и pls work I want home. И давайте вспомним наше любимое правило 80 на 20: 20% усилий приносят 80% результата. Да, в продукте нам часто не нужно 100% фичи. Но если вы катите в прод, вам нужно полностью пройти минимальный порог надежности: тесты, безопасность, интеграции, мониторинг, откат, поддержку. Через пропасть нельзя перепрыгнуть на 80%. Поэтому мне не нравится начальная цитата. Она скрывает необходимость перепрыгивать пропасть полностью. «Напилить MVP за вечер» != «выполнить работу целой команды». Задача инженерных лидеров (я говорю про всех лидеров, а не только руководителей) сделать так, чтобы ИИ в компании помогал перепрыгивать пропасть полностью. А для этого ИИ должен прорасти вообще везде: в ревью, в архитектурные решения, в CI/CD, релизы, тушение пожаров и много другое. Потому что собирать первую итерацию умеет любой ИИ-агент. Но агент не сможет трансформировать свою организацию так, чтобы ИИ (почти) автономно решал задачи за пределами MVP.

Аргументы и камни Представьте, что вы пишете стратегию. Хорошей идеей станет добавить в начало блок «проблемы» или «вызовы» — ведь хорошая стратегия обязана отвечать на вызовы или решать проблемы. Вопрос: сколько проблем перечислять? Я стратегии разбираю довольно часто, и так же часто вижу желание авторов напихать как можно больше аргументов. Желание логичное: ведь чем больше проблем перечислить, тем убедительнее начнет звучать стратегия. Но это неправда. Рационально посыл верный: больше аргументов — лучше. Но Канеман давно доказал: человек — не рациональный агент. По крайней мере, не всегда. Если аргументов будет слишком много, они рассеят внимание ваших слушателей и приведут к обратному результату. Люди не складывают аргументы как числа в таблице. После определенного порога новые аргументы уже не усиливают позицию, а размывают ее. Думайте про ваши аргументы как про камни, которыми вам нужно пробить стену. Вместо того, чтобы закинуть десяток небольших камней, лучше метнуть три здоровенных булыжника. Поэтому я всегда советую делать так: 1. Соберите все аргументы (проблемы, вызовы и так далее), чем больше — тем лучше. Это ваши камешки. 2. Кластеризуйте аргументы по смыслу. Это будут ваши валуны. 3. Позже в тексте раскройте каждый аргумент. Иначе ваши валуны останутся полыми и не пробьют стену сомнения. Давайте для примера. Вот было: У нас много техдолга, долго проходят код-ревью, часто ломаются релизы, не хватает автотестов, задачи плохо декомпозируются, продакт постоянно меняет приоритеты, разработчики перегружены, онбординг новых людей занимает слишком много времени, документация устарела, а архитектура мешает быстро добавлять новые фичи. А вот стало: • Мы медленно поставляем изменения и скорость снижается • Наша система стала хрупкой: падает каждый третий релиз • Команда не масштабируется, новые люди въезжают в проект по полгода Три булыжника такого калибра помогут проломить стену «да вроде все нормально в команде».

Я видел, как менеджеры попадают в ловушку: они хотят, чтобы сотрудники были заняты. Незанятый человек вызывает у такого менеджера естественный рефлекс нагрузить его работой, потому что в голове у менеджера живет формула: ЗАНЯТОСТЬ = ПРОГРЕСС Но между прогрессом и занятостью нет прямой связи. Зато рост занятости приносит пользу и менеджеру, и сотруднику — и за это занятность так горячо любят. Занятость полезна сотруднику: она как минимум служит индульгенцией перед руководством. «Я занят» означает, что я отрабатываю свою зарплату. В жалобе «Я занят» порой сквозит гордость; человек сигнализирует, что востребован и важен, его жизнь наполнена делами. И менеджеры любят, когда их сотрудники заняты. Ведь это значит, что менеджер смог наладить работу так, чтобы все работали! Утилизация — сто процентов. Максимальная эффективность выданных ему людей. Единственный, кто не рад тотальной занятости — это компания. Потому что когда все заняты, некому задать очень громкий вопрос: «Господа, а не херню ли мы тут делаем?» Этот вопрос не влезет между встречами. Ему нужно уделить время. А у занятого человека нет времени на сомнения. Я своими глазами видел что происходит, когда у команды нет этого времени (всем примерам 3 года и более, если что): • Команда полгода долбила по инерции задачи, которые приносили МЕНЬШЕ денег, чем компания тратила на содержание команды. Но все были заняты. • Менеджер соглашался на все влеты от стейкхолдеров и в итоге тратил весь ресурс команды на влеты. Почти за год такой работы ни одного крупной фичи команда не выкатила, только небольшие хотелки больших начальников. Если вы — руководитель, у вас ОБЯЗАНО быть время на подумать. В идеале, вы должны обеспечивать его и вашим сотрудникам. Нет никакой разницы, насколько много вы работаете, если вы работаете не в ту сторону. // кстати, если система поощряет занятость, она получит максимальную занятость. Польза в сделку не входила.

Приносите на работу себя целиком. Красивый тезис, но очень плохой совет. Аутентичность в компаниях любят. Но редко могут внятно объяснить, что вообще имеют в виду. Психолог Маслоу (тот самый) определяет аутентичность как «отсутствие фальши». Коллективное бессознательное дает иное определение: Не беспокойся о мнении окружающих, будь честен с собой и окружающими, будь НАСТОЯЩИМ собой, будь ЦЕЛЫМ собой. И всегда придерживайся своих ценностей! Давай прям по частям разбирать, что ли. Всегда будь честен с собой и другими! Посыл интересный, но проверять не рекомендую. Например, Стив Джобс честно говорил «this work is shit» (цитата) и вряд ли сотрудники были в восторге от такой честности. Если работа реально is shit, все равно дать аккуратную ОС. Вам ведь нужно чтобы человек сделал работу хорошо, а заявление про is shit его демотивирует, хотя и будет честным. Не рекомендую. К тому же, когда Стив Джобс говорит человеку «this work is shit», человек идет переделывать. Если так говорит не Стив Джобс, человек совершенно справедливо идет в HR. Не парься, что о тебе подумают! Прикольно звучит, но не очень прикольно работает. Я работал с людьми, которые на мою обратную связь отвечали «Ну вот такой я человек!». Причем обратная связь была, что не надо прям в открытую говорить стейкхолдерам, что они тупые. Я не утрирую, кстати. Мне потребовались месяцы, чтобы нарастить на мощные харды человека софт-скиллы. Но сначала мне пришлось воевать с позицией «Ну вот такой я человек!» Всегда следуй своим ценностям! Очень опасная позиция для лидера. Я понимаю, что мои ценности кончаются там, где заканчиваюсь я сам. Например, моя ценность — работа. Много работы, меньше отдыха. Если я буду следовать своим ценностям, я буду строить команду трудоголиков. Но загонять людей в переработки из-за собственных ценностей неправильно . Поэтому для себя я думаю вот как: Приноси на работу не всего себя, а лучшую версию себя. И у меня для вас есть личная история. Зимой 2019 года мне было довольно фигово из-за некоторых проблем. Но я уже был тимлидом и где-то на уровне ощущений понимал, что нельзя тащить мое уныние в команду. Так что я загуглил примерно такое: «как перестать быть унылым, если очень надо». Гугл ответил: если ты будешь улыбаться, через 5-10 минут тебе станет нормально. Звучало странно, но проверка ничего мне не стоила. И я попробовал. А потом всю зиму выходил из метро на станции Савеловская и всю дорогу до офиса улыбался. Да, прохожие странно на меня смотрели. Но в офис я входил уже без грустной морды, так что метод для меня сработал. И это не история про подавление эмоций и не про ношение маски. Это мой осознанный выбор: не приносить на работу ту часть себя, которая не была готова к работе. Именно это я и называю «приносить лучшего себя». Такая аутентичность мне нравится.

Признавайтесь, чей ИБ отдел?

Ой да кому мы нужны... И другие фразы, с помощью которых можно забить на ИБ. Правда, есть нюанс. Сегодня Booking.com подтвердил утечку клиентских данных: имена, email, адреса, телефоны и детали бронирований. Пострадавших уже предупреждают о фишинге — в том числе через мессенджеры, с точными деталями поездки. Сколько людей затронуто, компания не раскрывает. Но я тут не злорадствую. Этот пост — напоминание, что информационная безопасность разрушается в тишине. Грохот мы слышим только когда становится слишком поздно. Начните завтрашний день с ревью ИБ тикетов вашего проекта. Потому что некоторые риски любят, когда их называют «не срочно».

ИИ — это автомобиль. Но в большинстве компаний эти машины вынуждены ездить по проселочным дорогам, если вообще по дорогам. Мы люди, нам привычнее ходить по тропинкам. Человек пройдет везде: овраги, леса, горы; машине нужна инфраструктура. Но при наличии инфраструктуры (и инженеров, которые ее поддерживают), машина может проехать тысячу км в день. И еще тысячу на следующий день. А у человека ножки, мы так не умеем. Но люди продолжают строить тропинки для людей, мало кто пытается проложить дороги. Например: заметки со встреч фиксируются в лучшем случае у кого-то в трекере. Но ваш Claude Code не знает, что вы вчера договорились «никогда больше не использовать /api/v2/users». Если вы хотите кататься на ИИ, придется автоматизировать выгрузку таких договоренностей куда-то в базу знаний ИИ. И кстати, ИИ не умеет ходить по тропкам «эту инфу знает только Вася, спроси у него». Придется выгружать Васю в документацию. Я своими глазами увидел, на что способен ИИ, которому люди проложили дорогу. Он за 2 дня сделал то, что человек делал бы два месяца: переписал наш сервис на питон вместо шарпов. Что вновь возвращает меня к мысли, которую я повторяю последний год: ИИ нас не заменит. Мы для него еще даже дороги не проложили.

Мне нравятся такие статьи. Но они не набирают просмотров — потому что открыто говорят «мы не знаем» вместо тотальной паники. MIT Technology Review поговорили с экономистом из Чикаго. Вопрос простой: AI реально заберет рабочие места или нет? Ответ неудобный: мы понятия не имеем. Смотрите: OpenAI и Anthropic измеряют «exposure» — какой процент задач в профессии AI теоретически может выполнить. Допустим, 50% разработчика может выполнить AI. Выглядит научно. Выглядит как данные. Но это НЕ ТЕ данные. Это даже не тот вопрос. Для нас с вами ключевой вопрос такой: если AI делает разработку дешевле, спрос на софт вырастет или нет? Потому что если вырастет сильно — компании наймут БОЛЬШЕ инженеров (или будут больше платить). Если не вырастет — уволят (или станут меньше платить). Это называется эластичность спроса по цене. Ее обычно в районе 10-го класса проходят. Проблема экспертов-паникеров в том, что для большинства профессий данных по эластичности просто не существует. Высокий exposure ИТ в AI может говорить о том, что инженеров массово сократят. Но так же он может говорить, что миру потребуется в два раза больше инженеров. Без данных об эластичности спроса мы просто не знаем ответа. Экономист в интервью говорит: «нам нужен Манхэттенский проект по сбору этих данных.» Задача нерешаема без вливания тонны ресурсов, которые вливать никто не будет. А пока — все прогнозы про AI и работу это гадание. Это весело и интересно (и давайте честно: сейчас мы все это делаем), но к будущему отношения не имеет. Так что когда в следующий раз кто-то уверенно скажет вам «через 5 лет AI заменит всех» — спросите его: покажи мне эластичность спроса в этой области. Ответом будет тишина.

Самый опасный контракт — тот, который вы не подписывали, а клиент уже считает действующим. Допустим, у вашего сервиса нет явного SLO. Но вы решили: 99.9% аптайма вам достаточно. Значит, сервис может лежать 2 часа в квартал. Может, это окно под обслуживание. Может — плата за более спокойные релизы. И это нормально. Но ни клиенты, ни заказчики ничего не знают про ваш SLO. Он живет у вас в голове. Клиенты заходят на сайт, и он работает и днем, и ночью. Хороший сервис, клиентам нравится. В их голове формируется ожидание, что ваш сервис доступен всегда. Инженеры — такие молодцы! А потом сервис падает всего на час. В вашем мире все хорошо: вы не нарушили SLO ни на копеечку! В мире вашего клиента (стейкхолдера) все не так. Инженеры уже не молодцы, инженеры — бездельники на зарплате, которые не могут нормальный сервис предоставить. Клиентов нельзя винить — вы ПОКАЗАЛИ им высокий аптайм. Они привыкли к нему. А ваши SLO были только у вас в голове. Их никто не видел. И ведь это не только SLO касается. Роадмап «в общих чертах» превращается в обещание. Быстрые фиксы багов — в ожидание, что так будет всегда. Ответы в ночное время — в контракт на круглосуточную доступность. Паттерн один: если что-то хорошее происходит регулярно, оно становится обещанием. Про «надежда — не стратегия» вы слышали. Так вот мой новый лозунг: «Лучше разочаровать словами, чем подвести делом». Поэтому: транслируйте SLO заранее. Поставьте «subject to change» на роадмап большими красными буквами. Скажите стейкхолдеру срок, который ему не понравится — но который вы сможете реализовать. Команда, которая открыто называет свои ограничения — не слабая. Она единственная, которая реально управляет ожиданиями, а не управляется ими.