Буллшит-бинго / Найми одного QA

––

Дисклеймер:

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

––

Блядь, но ты сам реально пользовался тем самым "AI-прорывом", который ты сделал за прошлую ночь без разработки и вот-вот задизраптишь рынок? Или такой же поделкой от какого-нибудь известного парня из долины? Попробуй, перед тем как в следующий раз кинуть что-то в чат на большое количество людей, или в свою ленту, или на сцену, показать свой "работающий и почти готовый к продакшену AI-продукт" тестировщику. Хотя бы миддлу, но можно и младшему. Имеющему опыт работы.

Компилятор, сгенерированный полностью агентами и компилирующий дум, на старте не мог скомпилировать hello world.
Браузер, написанный полностью агентами, работал и работает..специфично

Надо ли говорить о том, что я вижу на демо и в личках?)

Если ты вчера за ночь сделал "продакшен-реди сервис за 2 часа", покажи его одному инженеру и попроси выпустить в продакшен. Ну или сам попробуй им денек внимательно попользоваться и поискать проблемы.

// пузырь – это не обязательно что-то полностью фейковое. Это, довольно часто, что-то, имеющее реальную ценность, но ОЧЕНЬ криво интерпретированное людьми, управляющими деньгами.

Границы зоны ответственности / Let Them Fail

Знал я одного менеджера очень высокого уровня, как-то раз в интервью сказавшего: "моя зона ответственности – вся компания".
Интересно, много ли у меня подписчиков, видевших это интервью и работавших со мной в той же самой компании?)

Так вот – это в части случаев не работает.

Если смотреть на вещи реально:

Команду в своем официальном управлении ты можешь заставить сделать что угодно

Да, могут быть проволочки, да, может быть сопротивление, да, это может быть долго, но eventually все, что могут сделать физически твои подчиненные – зона твоей полной ответственности (в предельном случае, если человек что-то не делает, ты всегда можешь заменить)

На команду не в своем подчинении ты можешь только влиять. С неизвестной вероятностью

Если твои горизонтальные коллеги делают свою работу "плохо" / "неправильно" / полностью не делают – ты, в общем случае, не можешь get it done.

– Ты можешь прийти и о чем-то попросить (или жестче – "обозначить свои ожидания", если функция сервисная).
– Ты можешь предложить несколько решений, если у тебя есть идеи.
– Ты можешь аргументировать, поспорить, отработать возражения.
– Ты иногда можешь сделать заплатку своими силами. Например, если продакт не может доформулировать для тебя описание задачи, а делать надо и дедлайн горит, можно кое-как самостоятельно описать и сделать. У этого есть риски, но лучше, чем ничего. Если команда office management & hr не может устроить тебе рабочее место (вот вы смеетесь, а такое бывает) – ты можешь до какой-то степени сам себе найти где работать. А если команда инфраструктуры не достраивает вовремя датацентр – ничего не сделаешь сам. Или еще какие-нибудь люди, работу которых ты практически не понимаешь.
– Ты можешь проэскалировать проблему (начиная со своего прямого руководителя до минимального общего) и с некоторой вероятностью другой руководитель это решит

Но в общем случае, если не твои люди что-то фейлят и серьезно настроены – они зафейлят и ты их не остановишь.
Если ты попробовал все из списка выше – ты отработал свою зону ответственности (как бы она не называлась; за исключением ситуации, когда ты – ceo/owner и можешь заменить буквально любую часть компании) и можешь спокойно пойти спать.

– А если проект и компания развалятся из-за этого?

Значит развалятся. Если люди делают что-то НУ ОЧЕНЬ СТРЕМНОЕ, ты честно им об этом сказал, предложил альтернативы, поэскалировал и это не помогло – это конец твоего влияния. Верни фокус на свою работу. Просто в одном случае все развалится, а ты будешь параллельно жить спокойно и не почувствуешь своей вины, а в другом – все развалится, а ты параллельно пожжешь кучу нервов, со всеми разругаешься, еще и останешься виноватым. Что выгоднее?)

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

–––––

Фокусируйся на доступном и получится лучше :)

Sanity Check

Одни из самых интересных клиентов на консультациях – владельцы или CEO's стартапов, доживших до стадии роста.
В такой позиции часто ты оказываешься наедине со своими проблемами, ощущениями и не очень высокогрейдовой командой. Команда проблемы/опасения не разделяет, а ты – не эксперт в разработке. И вроде происходит "что-то не то", а вроде и давить страшно – вдруг ты не прав?

В таких ситуациях очень полезным бывает sanity check – быстрый разговор о своих опасениях и предположениях с кем-то опытным в engineering management. Бесплатно, без регистрации и СМС, даю ниже набор тейков, которые подтвердят или опровергнут твои сомнения без полноценного консалтинга:

––––

Если сомневаешься, нормально ли релизить раз в месяц – не нормально

Бэкенд можно релизить каждый день или несколько раз в день на любом этапе развития проекта, если архитектура этому не мешает. Это достижимо и для монстра размером с убер, и для сайта продажи зубных щеток. Если у тебя не так – можно лучше.

Фронтенд (веб) можно релизить раз в неделю. Чаще – отлично, но сложно. Намного реже – плохо, скорее всего что-то не так (для коллег из энтерпрайза, фронт которых катается раз в две недели: я говорю здесь про небольшие проекты. Не про те, где таких релизов можно достичь только микрофронтендами).

Мобилу можно катать не реже, чем раз в 2w. За единицы дней +- невозможно (ревью в store), за неделю – можно, но каждую неделю будете тратить время на ревью, команда может считать неоптимальным, за 2 – должно быть легко. Если нелегко – это проблема

––

Если сомневаешься, нужен ли процесс – нужен

Спринты, скрам, канбан, эджайл, ретро, доски, сторипоинты..а мне что-то из этого нужно?
Если команда больше единиц человек И ты не можешь лично отслеживать все, что делает каждый – нужно.
Какой процесс правильный? В целом – любой, который ты сам можешь быстро понять, никаких других требований для старта нет. Если "интуитивно" понятным и удобным не выглядит ни один – попробуй что-нибудь похожее на скрам (можешь у claude или gpt спросить как для твоей команды выглядит максимально облегченная его версия). Сможешь чуть чаще спать по ночам и спорить об эффективности команды и обещаниях не только на воспоминаниях.

––

Если сомневаешься, нужен ли человек на любой не-производящей роли – не нужен

Разработчик фронтенда – супер-понятная производящая роль. Результат его работы ты можешь легко увидеть и потрогать.
И дизайнер – тоже.
Когда разработчиков станет много, ты не будешь сомневаться, что нужен тимлид – он, может, руками и не производит, но без него тебе просто очень плохо.

А вот когда и команда разработки и тимлид есть и вроде оно работает и есть идейка, не нанять ли проджект-менеджера...В большинстве случаев ответ – нет, не нанимать. Если менеджмента вокруг команды реально столько, что лид не справляется – у тебя никаких сомнений не будет, ты легко ответишь себе на вопрос, что такого он будет регулярно на полную ставку делать, чего сделать больше некому. Если сомнения есть – скорее всего, ты еще не там и можно сэкономить. То же самое про скрам-мастера, системного аналитика, и любую другую роль, которую ты видел в энтерпрайзах но точно не уверен нужна ли тебе

––

Если сомневаешься, можно ли масштабировать команду только за счет AI – нельзя

Чем больше и сложнее проект – тем больше тебе, в общем случае, нужно людей в разных доменах с разной экспертизой. Грубо говоря, человек, который хорошо запромптит claude писать бэкенд (и потом хорошо отревьюит получившееся и сделает несколько итераций правок) – это не тот же человек, что сделает это для мобильного приложения. И тд.

И – да, когда ты вырастаешь (не 5-6 человек), fullstack начинает работать хуже, придется (частично) специализироваться.

––

Если сомневаешься, нужен ли тебе в команде кто-то "посильнее" – нужен, для начала хотя бы один человек

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

Даю 90% вероятности из своего опыта, что если ты начинал свой стартап без длинного трека в сильном tech и без десятка свободных миллионов долларов на счету – твоя первая команда состоит из других людей. Это не плохо, так почти у всех. Когда деньги начинают литься, идет рост, а в tech что-то идет не так (все вопросы из поста – об этом), тебе нужен хотя бы кто-то, кто не просто верит в тебя, в идею, а еще и имеет твердую экспертизу. Да, за это нужно что-то заплатить. Да, скорее всего ты не наймешь сам, понадобится еще и интервьюер. Но хотя бы один такой человек в команде (или как лид, или как senior/staff engineer) может сильно поменять происходящее. В какой-то момент (еще раз дисклеймер: когда деньги на это будут не из твоих сбережений на черный день) в команду нужно вложить денег и это вернется.

И – не интервьюируй людей полностью сам. Ты так уже делал на старте 🙂

Реорганизации и миддл-менеджмент:

AI-трансформации в компаниях, помимо общего сокращения штата (ожидаемо), дают еще один интересный эффект: сокращение миддл-менеджмента. Из моих наблюдений за big techs, именно такие люди хуже всего переживают оптимизации и реорги – им просто нет места. cXo все еще нужен – это человек, закрывающий всю головную боль и ответственность по функции в компании. Линейный руководитель (тимлид) все еще нужен – нельзя же всех исполнителей воткнуть в cXo, их даже после сокращений остаются, как минимум, сотни.

А вот middle-management, руководитель нескольких лидов, но еще не директор..уже начинает попадать под нож (по крайней мере две крупные технологические компании, в которых такое происходит, я уже видел).

Я лично за последний месяц увидел как минимум троих людей, ищущих работу после таких реоргов (из компаний, которые я знаю), которым я..без проблем придумал бы работу в той же компании и после сокращения. В некоторых случаях вплоть до работы наполовину руками. И я на 80% уверен, что эти люди согласились бы и делали бы ее лучше, чем половина не-сокращенных сотрудников из тех же компаний.

Для фаундера:

Если у тебя есть структура

dev -> tl -> middle manager -> cto и ты понимаешь, что middle manager как роль больше не нужен тк все стали очень эффективными – конкретный человек в роли, если он сильный, ОЧЕНЬ возможно способен разделить эту точку зрения и принять работу уровнем ниже. Возможно, даже заменить двух tl (это будет выгодно, он получает не x2). Или одного tl и троих IC, если он вырос в свою позицию не просто так. Это можно, как минимум, обсудить. "Не нужна роль" и "не нужен человек" – это очень разные вещи.

Для миддл-менеджера:

Если чувствуешь риск такого сокращения – попробуй проактивно подумать и поговорить о том, какую работу "ближе к земле" ты не против и готов делать. И – дойди поговорить с руководителями об этом до того, как они сами придумают оптимизацию hc. Не рассчитывай, что они помнят, что ты, вообще-то, многое умеешь делать – оптимизация бывает беспощадна 🙂

–––

Резать косты можно самыми разными способами, и при прочих равных – лучше резать не людей высокой квалификации.

// кстати, хороший чек на квалификацию миддл-менеджера: если он без проблем готов начать снова "производить" – он скорее всего хорошо помнит как это делается и может наносить много пользы. Если нет – ты не ошибаешься с оптимизацией

Интенсив по сложным переговорам

На самом деле, я ненавижу корпоративную политику и переговоры "не по делу". И в то же время не менее 50% моей работы и консалтинга реально состоит в этом уже давно. Наверное, начиная с размера команды в сотню человек не было ни одной недели, чтобы я этим не занимался.

Периодически я что-то об этом пишу (можно поискать в канале по слову "переговоры").

Что может быть лучше, чем почитать кого-то по теме? Конечно, послушать и в реальном времени поговорить с кем-то по теме!

Мы с друзьями из Стратоплана и не только устраиваем трехдневный интенсив (кейсы-истории-практика) по сложным переговорам: с подчиненными, стейкхолдерами, и руководителями/директорами/бизнесом. Один день – одна тема. 24-26 марта, по вечерам. Каст – как по мне, очень интересный, все на скрине.

Меня вживую можно будет увидеть в день 3 – по теме работы с бизнесом, директорами и прочими руководителями. Принесу реальную тяжелую историю из своей топ-менеджерской практики, поговорим о корпоративных играх престолов.

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

https://stratoplan-school.com/university/ld/

Мы очень стараемся сделать что-то крутое и будем рады вас увидеть 🙂

Лайфхаки для презентаций директорам и представителям бизнеса:

Набор "простых" трюков, которые могут сэкономить тебе, в лучшем случае, дни работы и споров, а в худшем – работу и клиентов вообще.

––

Если формулировка/решение никак не повлияет на бюджет и результат проекта – просто согласись

Если собираешься построить "просто сайт с двумя экранами", а просят "экосистему", не уточняя при этом, что такое экосистема и не челленджа реальный функционал, который ты предлагаешь – просто назови это экосистемой.

Если нужен API-ready в плане работ, а ты сутево понимаешь что нормальный api, gateways, security и прочее у тебя и так заложены просто как хороший тон – заткнись и допиши api ready как отдельный пункт в план.

В целом, если заказчик не совсем точно понимает происходящее, но это не совсем точное понимание никак тебе не вредит и за 30 секунд объяснить не получилось – просто окни и все. Вы к этому разговору не вернетесь никогда и все будет хорошо. Если попытаешься человека научить – с вероятностью 50% закончите на том же самом скоупе, просто заработаешь проблем и испорченных отношений.

Ты можешь обучить только того, кто хочет обучиться. Во всех остальных случаях – сделай то, что будет правильно работать, оформив это так, чтобы заказчику понравилось. Все.

––

Если решение сложное/большое/дорогое – приведи пример из индустрии

Экспертные аргументы (например, подробное описание архитектуры с обоснованием, почему делать надо именно так) работают только для других экспертов в домене. Если ты презентуешь борду или не-техническому заказчику, единственный эксперт в домене в комнате, скорее всего – это ты.
Понять экспертный аргумент полностью невозможно. Единственная его реальная цель – показать свою экспертность.

А вот что возможно понять вообще всегда – это кейс: "вот у такого большого игрока сделано так и работает". Все остальное – это дополнения и комментарии

Даже если ты предлагаешь сделать лучше и гораздо дешевле чем у других ребят – все равно приведи референс и покажи улучшение относительно него, а не просто описывай классное решение.

––

Если "ОК" нужен от нескольких людей – поговори с каждым по отдельности перед встречей

Если разные люди впервые увидят твою презентацию на встрече – они все поймут по-разному, у каждого будут свои консерны и пожелания, и ты не доберешься до конца. Постарайся, насколько это возможно, переговорить 1-1 ДО официальной "защиты" с ключевыми людьми, пообъяснять подробнее и отработать возражения заранее.

"А зачем вообще тогда нужна общая защита? Это не просто двойная работа?"

Нет. В ряде ситуаций финальный "ОК" люди могут поставить только в присутствии других людей и убедившись, что они не делают глупость. А поделиться опасениями/непониманием/личной заинтересованностью в проекте и настоящей мотивацией – могут только лично

––––

Пользуйся и оставайся в живых :)

Сохраняй вариативность

Я с детства умел на любительском уровне играть в шахматы. "Крутые комбинации" + "здравый смысл" давали мне очень неплохие результаты в играх с такими же любителями. И даже ненулевой винрейт с ребятами, имеющими разряд. Я думал, что так оно и работает. Пока случайно не попал в универе в группу ОЧЕНЬ сильных ребят (со средним уровнем в районе КМС), которые играли.. как-то по-другому. Я проигрывал 100% партий. На доске просто происходило что-то очень медленное и скучное, а спустя 30-40 минут я вдруг оказывался в очень плохом положении и проигрывал. "Красивые комбинации" начинались в самом конце, и то не всегда.

Оказалось, что профессионалы значительную часть игры думают вообще не о них. Есть эвристика оценки состояния на доске: чем больше ходов/"ударов" ты потенциально способен совершить, тем позиция лучше. Крутая комбинация – это что-то на грани с везением, что может случиться только один раз и под конец игры, когда кто-то ошибется. Все остальное время происходит "позиционная игра" – наращивание потенциалов.

Сначала мне казалось, что я этой скучной манеры игры смогу избежать. Потом я сдался и начал учиться позиционной игре. Потом мои 100% поражений начали превращаться во что-то другое. Этот опыт повлиял на мое отношение как к игре, так и к карьере (да, работать я начал раньше, чем меня начали учить более-менее серьезно играть):

В большой и сложной игре (а карьера и бизнес – это такая игра) ты не можешь просто легко "взять и найти путь к победе, напрячься и проскочить", как показывают в кино или зачем-то рассказывают в интервью. Ты долго копишь потенциал, 100 раз оказываешься в нужных местах, и пару раз из 100 тебе везет и ты делаешь рывок. И играешь ты так долго. Все истории про нетворкинг, стратегические комитеты, найм непохожих на тебя и сложных людей – это про увеличение вариативности.

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

// исключение – ситуация "сделай прямо сейчас на максимум – иначе умрешь". Early-early-early stage founders и менеджеры в очень кризисных ситуациях могут действовать так, это тоже нормально.

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

Вы еще не опоздали на переговоры и конфликты!

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

У нас прямо сейчас идет трехдневный интенсив со стратопланом по переговорам и конфликтам от практикующих на высоком уровне менеджеров. Прийти и посмотреть еще не поздно – это можно сделать либо бесплатно, подписавшись на спикеров, либо за символическую входную сумму. Завтра – день тяжелых разговоров с директорами и бизнесом, можно будет послушать меня и задать вопросы :)

Заглядывайте на огонёк!

https://stratoplan-school.com/university/ld/

Найди руководителя, который даст негативный фидбек

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

– Делаешь сам
– Показываешь что получилось экспертному руководителю из домена
– Получаешь фидбек. Спрашиваешь, что бы делал он вместо того, что сделал ты
– Повторяешь до тех пор, пока вам обоим не понравится результат

Это понимают почти все без исключения люди, успешно двигающиеся по начальным ступенькам карьеры. И..этот навык, внезапно, теряется почти в 0 у тех же самых людей, когда они добираются до вершины карьерной лестницы в своей текущей компании. Ты добираешься "наверх" (иногда даже до позиции CEO) и..перестаешь обучаться. Даже откатываешься.

> Как это перестаешь, опыт-то новый есть, и сложный!

Опыт есть, а фидбека от экспертного руководителя нет. Доверять своей оценке, особенно в случае, если ты не объективно лучше всех на рынке – такое себе дело, критически оценивать себя сложно. Некоторые подчиненные чего-то там бухтят, но..они что, могут меня учить? Я не просто так их руководитель. В конце-концов, ответственность за результат-то на мне, значит и решать что хорошо, а что плохо, в итоге должен я. И это еще если повезет – многие подчиненные с уверенным руководителем спорить вообще побоятся.

Это очень опасно для всех в компании: проводя в таком сетапе несколько лет, ты буквально становишься хуже и хуже. Мир и контекст меняются. Быть bleeding-edge экспертом даже в одном домене на топ-менеджерской позиции практически невозможно – банально нет времени. Накапливается разрыв связи с реальностью + буквально ухудшается навык видеть проблемы (фидбек от СД – не всегда то же самое, что экспертный. Там тоже не всегда есть люди, лично знающие что сделать на прикладном уровне). Если результаты на цифрах начали ухудшаться – повод задуматься.

> А я не могу просто все важные решения делегировать?

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

– Ладно, и как мне чему-то учиться, если я уже долго нахожусь высоко?

Если у тебя все классно с самоконтролем и ты морально готов – можно учиться у подчиненных. Да – это нормально. И – это долго и сложно. Чтобы подчиненный начал давать тебе негативный экспертный фидбек регулярно и разбирать проблемы из определенного домена, надо долго выстраивать доверие. На одном 1х1 фидбек подчиненному даешь ты, на другом – тебе.

Если предыдущий пункт эмоционально сложный – сделай так же, как делал на старте – найди руководителя, который даст тебе негативный фидбек. Никому не говори, что он твой руководитель (ты же самый крутой в компании) – назови его ментором или наставником. Можешь вообще никому не говорить, что такой человек есть. Только не называй консультантом: у консультанта ты спрашиваешь про его решение, а ментору или наставнику можешь показать свое и получить лещ фидбек.

Если сумеешь не выгнать его после первых двух встреч, спустя месяц-другой команда, внезапно, может заметить положительные результаты и сказать тебе спасибо. Да и вообще жить и работать станет интереснее.

Иногда дело в структуре, а не в людях

Иногда у руководителей больших организаций складывается интересная ситуация:

Есть подразделение и руководитель, которых все хейтят и считают долбо.. некомпетентными. Набрасывают по делу процентов на 50, но результаты реально плохие. И ты меняешь сначала часть команды – не помогает. Меняешь руководителя и всю команду – не помогает. Еще раз меняешь руководителя – снова не помогает (сейчас подписчики из очень эффективных стартапов напишут, что так не бывает. Но, все что мне есть сказать в ответ: бывает, и еще как бывает в компаниях-долгожителях)). Сидишь и думаешь: "блин, неужели я дважды-трижды-четырежды подряд ошибся с наймом?"

Так вот: с высокой вероятностью ты ошибся не с наймом, а с оргструктурой. Скорее всего, это подразделение в принципе не может работать в твоей организации as is. Возможно, оно вообще не нужно.

Например, ты собрал "проектный офис" или "delivery офис". Он вроде как должен помогать инженерным вертикалям деливерить, строить процессы, вести сложные кросс-организационные проекты и тд, а на практике..этого не происходит и все ведут сами вертикали, используя менеджеров как очень переплаченных секретарей. Просто исторически так сложилось, что у тебя лиды сами себе деливери-менеджеры, они и так уже построили процессы и они работают. Выстраивать "процессную" структуру сбоку, не поменяв майндсет и то, как люди привыкли жить в такой ситуации – примерно бесполезно, не получишь ничего кроме конфликтов. Кстати, а нужно ли тебе ее выстраивать? У коллег из бигтехов она работает, но у них изначально была другая организация. Может, ты просто не на том масштабе и не с теми людьми, которым это нужно.

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

Я оба примера видел вживую с очень близкого расстояния и в каждом 2-3 сменившихся руководителя до того, как подразделение было или существенно пересмотрено концептуально или разобрано полностью. И – да – каждый раз дело было не в руководителе, которым все были недовольны.

Что делать в такой ситуации? Попробуй у второго-третьего по счету человека, которого ты собираешься снять с должности / у доверенных внешних людей / у горизонтальных коллег руководителя "неудачного" подразделения поспрашивать: а как они думают, нужно ли оно вообще? Как они видят структуру, если бы ты сказал, что его в компании не будет? Из серии таких разговоров внезапно можно понять, что существует другая конфигурация, в которой все, включая тебя, довольны, и никто не бьется об стену

Регламенты не работают

Как легко отличить человека, работавшего с большой командой только в теории?

Я как-то раз был на конфе по infosec. И там со сцены ребята из компании, которую я не буду называть, рассказывали, как сделали разработку у себя безопасной и свели к нулю критические риски и утечки. Доклад на 100% (не преувеличиваю) состоял из очень сложного описания регламента:

– Вот такие штуки нужно сделать, когда заводишь сервис
– Вот это надо проверить на ревью
– Вот так мы определяем можно ли делать сетевой доступ
– Еще 10, в общем-то, разумных правил

Это было сложнее (2020-й, кажется, год), чем вообще ВСЕ, что я видел успешно внедренным на практике в русскоязычном бигтехе. И звучало круто.

Когда доклад закончился, я попросил микрофон на QnA и спросил, как буквально они это внедрили

– Что значит как внедрили?
– Ну людей вы как заставили это делать?
– Написали понятный документ, гайд 1-2-3, разослали руководителям…
– Не, это понятно, а делать-то вы их это как заставили?
– Что значит заставили? Не понадобилось
– А они это вообще делают?
– Говорят, да…

Дальше я не слушал :))

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

Сформулировать набор правил для любого процесса в компании – это как систем дизайн для сервиса. Это НЕ реализация.

Собрав такой документ, всегда нужно думать (и делать), как реально привезти это в жизнь. Это могут быть процессы и даже технические изменения в компании (например, поменять CI/CD чтобы нельзя было сделать мерж, не сделав дополнительно раз-два-три. Или даже новая метрика на перформанс-ревью).

Изменение случилось, когда ты на фактах и цифрах видишь, что оно случилось. Или даже когда не случиться не может. Иначе – ты его просто придумал :)

Быстрый тест на управляемость

Есть ли у тебя прямой подчиненный, которого нельзя уволить?

Не потому, что запрещено человека увольнять (кстати, такое бывает, политика и все дела), а потому, что все развалится и ты не знаешь, что без него делать?

Если да – ты не управляешь этим человеком и его подразделением. Это надо чинить.
Исправляется в 100% случаев погружением в домен и дообучением себя.

Не потому, что ты будешь потом грозить ему увольнением и реально уволишь. А потому, что, во-первых, через год он уволится сам. А во-вторых – когда руководитель принимает решения из позиции "человека ни в коем случае нельзя потерять", а не из "мне нужно оптимально управлять ресурсами, достигая определенных целей" – это видят как подчиненные, так и другие руководители. И это плохо для твоей карьеры.

А у тебя есть такое прямо сейчас?

Ленивые дорожные заметки о ТЗ и стандартах

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

Кафе, у которых в меню есть «горячий матча-бамбл» или «matcha orange HOT” – мало.

А холодный во всех столицах делают. Очень раздражающее меня отличие европейских городков (последние две недели нахожусь по делам здесь) от Эмиратов, в которых я живу – в том, насколько сложно заставить людей сделать «немного не по ТЗ».

В Дубае у меня есть кофейня прямо возле дома. Там делали холодный orange matcha. Я зашел и попросил горячий

– Что, горячий? На улице +30
– Да, я не пью холодный
– Но мы холодный делаем
– Ну вы просто не кладите лёд и подогрейте, да и все, у вас же все есть, это быстро
– Окей, босс

И я там каждый раз, проходя мимо, оставляю средний чек. А прохожу мимо я дважды в день.

Тот же разговор в Европе, с кофейней прямо под домом. Место хорошее, в центре:

– А сделаете горячий?
– Нет (никаких доп.вопросов, ничего)
– А почему?
– Это невкусно и у нас в меню пункта нет
– Блин, но мне-то вкусно. Это от вашего меню отличается тем, что лед убрать нужно
– Я спрошу разрешения у менеджера
…
– Нет, не положено, нет в меню

И опыт воспроизводится!

Я в итоге каждый день захожу в не-удобную мне кофейню, где согласились (штук 5 перебрал)

И в айти, и вообще в бизнесе есть много людей, наученных горьким опытом последствий «выйти за рамки ТЗ по запросу заказчика». С одной стороны, соглашаться на все подряд, конечно, нельзя, и надо держать границу. Но: не забывайте делать поправку на здравый смысл. Если запрос «не ровно по стандарту», но сделать его не стоит буквально ничего (важно: не +1 день, а прям совсем ничего; на уровне немного другого заголовка на главной) – следуя ТЗ без исключений, можно развалить отношения с заказчиком, особенно если он глубоко в контексте.

Вайб-кодинг и виды фаундеров

Я регулярно общался и общаюсь с людьми, строящими бизнес вокруг чего-то технологичного. Периодически помогаю что-то разработать и запустить.
Очень интересно наблюдать границу между теми, кто реально готов что-то сделать, и теми, кто просто читает новости:

Один тип фаундеров, которые "верят" в вайб-кодинг:

– Привет, можете такое сделать?
– Да
– А сколько по времени и сколько стоит?
– Вот столько
– Не, это вы как-то очень долго и дорого, вы про claude code и codex что ли не слышали?
– Мы знаем и используем, без них было бы еще дольше и дороже. Ими же люди пользуются, люди все еще дорогие и сложные
– Да я сам вчера за ночь уже почти готовое решение сделал, какие дорогие люди?
– Ну если ты сам сделал уже "почти" готовое – сделай да выпусти совсем готовое еще за один день? Бесплатно ж будет. А как сложное масштабирование начнется, нагрузку там держать надо будет или еще что-то – приходи

Сделанных этим типом предпринимателей в продакшен на пользователей продуктов я видел ровно ноль.

> Да ты просто вредный и отвечаешь как мудак, у них все полетело на следующий день, тебе не рассказали!

Я, с одной стороны, вредный и иногда действительно отвечаю как мудак. А с другой – я правда искал и даже приходил спросить, что получилось и сколько пользователей) И пока не находил.

Второй тип фаундеров:

– Привет, а можете рассказать, как сейчас решают задачу X?
– Да, можем и рассказать и решить, а зачем?
– Да вот у меня сервис есть, пользователи растут, но такой-то сценарий плохо работает, я пробовал раз-два-три и не работает
– А покажи чего есть...Нифига, круто (а там реально может быть круто – например, аналог cursor для юристов, автоматизация отдела закупок, ОЧЕНЬ умная говорящая детская игрушка, сложная система личных ассистентов). А большая у тебя команда?
– Да нет, я сам с клодом сделал за два месяца. Вот здесь меня уже не хватает, понимаю что нужна помощь // Важно: человек довольно часто при этом без айти-бэкграунда, доменный эксперт из смежной области. Причем в части случаев он за время, что делал, даже до какой-то степени код читать научился

И дальше происходит какой-то нормальный разговор

––

То есть, на самом деле, "сделай сам, приходи когда будешь масштабироваться" – работает. Но работает только для тех людей, которым советовать это в принципе нет необходимости – они интуитивно к этому и приходят. Возможно, где-то здесь и есть граница между builders и другими типами менеджеров?

Питч на 30+ минут без возможности задавать вопросы в процессе

Помнишь как чувствовал себя на второй подряд паре по матану?

Вот примерно так же чувствуют себя люди, столкнувшиеся с тем, что описано в заголовке.
Я за время встречи сделал чай, выпил его, лег в кровать и закрыл шторы, чтобы успеть помедитировать. А также написал этот пост :)

Пожалуйста, не защищай свой стартап или вообще идею как диплом, это очень плохо. На самом деле, поговорить с людьми о том, что им интересно в твоей идее (если ты, конечно, хочешь им это продать), обычно лучше, чем успеть сказать все, что ты сам посчитал важным. Абсолютно нормально не рассказать про 7 фичей из 10, если заказчику очень нужны только первые три

AI-First или..не First?

– А будем искать продакта или AI-продакта?
– А будем искать разработчика или AI-разработчика?

И, блин, я вроде и хочу, чтобы все были в теме. Но в то же время CV-шки и должности, начинающиеся со слова AI (я даже видел AI-CTO, AI-CPO) меня немного триггерят. Потому что появился сегмент слишком глубоко воспринявших хайп людей, гиперсфокусированных на одной из 100 технологий, которые, по-хорошему, должен знать и уметь человек из product & tech.

В чем проблема гипер-AI фокуса? В том, что многие инженерные проблемы лучше решаются не через него. Даже если это проблемы AI-продукта.
Я вообще 60% AI-вопросов и кейсов, которые приносят на консультации, решаю старым и немодным инженерным бэкграундом, который работал и 10 лет назад.

Кейсы из личных консультаций:

1. Есть AI-агент, переваривающий кипу сложных текстов и собирающий определенного формата документ. В части полей он стабильно врет и ссылается не на исходный текст, а на что-то другое, или просто придумывает штуки, а там лучше руками человека позвать заполнить, чем ошибиться. ТНачинаются достройки других llm-ок поверх первой, графы, еще какие-то штуки..Не работает, плохо работает, дорого..

– А текстовый поиск знаете, сталкивались? Были алгоритмы такие разные
– А что?
– Ну давайте попробуем попросить агента цитировать, откуда он взял сложное поле (прям сослаться на документ и место), а там текстовый поиск/расстояние сгоняем. Если похоже на то – значит оно и есть, непохоже – значит не оно и лучше руками.

И действительно не так плохо работает, и за еще одного агента платить не надо

2. Есть сложная hardware + software штука, в котором, среди прочего, есть голосовой агент. И что-то долго она отвечает, задержка на старте большая. Может инференс надо оптимизировать..Или модель более дорогую (11labs взять, например)...

– А покажите код
– Да там ничего интересного, прослойка и прослойка над железом
– Если бы хоть раз, когда я написал что-то на Сях над железом по инструкции, оно просто взяло и заработало, я был бы совсем другим, более веселым человеком. Давайте код глянем?
– Давай глянем
– А, ну так ты на старте, когда начинаешь голосовую часть, сначала получаешь с сервера ответ, потом открываешь буфер аудио-устройства, в него это пишешь и воспроизводишь. Давай буфер раньше будем разогревать, можно фрейм тишины в него написать, например (пока еще ждем от сервака), а потом сразу нормальное аудио, которое доехало (тоже кусками можем. btw, как оказалось, стриминг там уже даже был сделан). На месте китайской железяки, я бы подвисал именно здесь

И тоже есть результат

3. (да, даже такое уже есть) Чего-то рекомендации у меня плохо работают. То говно какое-то посоветую, то очень долго, то еще что-то, как научить AI это делать?

– А какая архитектура, фичи? Классика/гибрид?
– Чего? Ну промпт какой мне написать?
– Ты что, рекомендации через llm делаешь?
– Ну да, через агента
– Есть у меня для тебя история о том, как это делали 5 лет назад...

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

Ну и, если у тебя есть проблема с AI – приходи поговорить :)) Оказывается, если называть это так, конверсия выше!

Два важных аспекта директивных решений

Иногда, даже в ОЧЕНЬ демократичном окружении, тебе нужно принимать решения сверху вниз, в одностороннем порядке. Чтобы, принимая такое решение, не развалить команду, отношения и управляемость, не наступай на грабли:

– Не делай вид, что готов принять возражения и обратную связь, если ты не готов

Иногда надо просто взять и сделать что-то неприятное. Выбросить продукт, пойти работать на выходных, заключить не очень выгодное, но политически неизбежное партнерство и тд. Если ты уже решил и поворачивать не будешь – надо так и сказать, объяснив причины. Любые публичные попытки демократизировать ситуацию «согласны ли? Кто думает, что надо сделать по-другому?» в итоге ударят и по тебе и по исполнению. Кто-нибудь всегда будет не согласен, потратите время + люди решат, что ты не совсем уверен и понимаешь, что делаешь

– Если решение «должен был» принять кто-то другой – пусть так оно и выглядит

Допустим, решение должен был принять cXo или любой другой руководитель пониже, но ты думаешь, что он ошибся (или зря тормозит) и проносишь свое решение через голову. Если ты не хочешь забрать на себя все обязанности сотрудника, которого перешагиваешь – транслировать решение должен он. Команда в итоге примет лучше и руководитель сохранит реальное управление (как и ты, управляя одним человеком, а не всей его командой за него). Как только ты публично начинаешь принимать «не свои» решения, люди начинают (справедливо) считать тебя прямым ответственным и теряют промежуточные звенья

––

Ну и – чем больше твоя команда, тем меньше такого, в идеале, должно быть :)

Если в команде всё плохо, дело не в недостатке инноваций

Если твоё IT работает как куча говна, добавление к нему "самых последних технологий", превратит ее в кучу говна, из которой торчат обломки космолёта. Скорее всего, это не то, что тебе нужно.

Что такое "куча говна"? Это такой адский треугольник: медленно, дорого и некачественно. В отличие от положительной версии, сочетать все три негативные стороны обычно можно с большим успехом. В 100% случаев если выглядит всё именно так – тебе не хватает не <вставь любимое название модной технологии: ai, микросервисы, кроссплатформенная разработка, что-еще-там-было-в-том-блоге>.

Если твои разработчики не умеют в код-ревью, а ты всех посадил на claude code, они вместо того, чтобы руками писать плохой код, который делает не то, что нужно, будут его генерировать и уходить домой пораньше. Если твоя инфраструктурная команда не может построить нормальный релизный пайплайн для одного некрасивого и немодного монолита, а ты вместо него запилишь 50 микросервисов – попробуй прикинуть вероятность, с которой 50 раз вместо одного у них, почему-то, получится. Если твои qa недостаточно понимают продукт и пользователей, чтобы протестировать его руками, от того, что ты заставишь их писать автотесты, понимать это они не начнут – просто плохие тесты станут автоматизированными и будут проходить быстрее!

В общем – попробуй начать с качества людей (часть придется поменять, часть обучат новые люди) и базовой гигиены жизненного цикла разработки по (спроси у коллег, айти которых работает нормально, что это такое). Еще лет 5-7 назад люди умели поставлять ценность в продакшен за дни и недели, а не кварталы и полугодия, тестировать софт, и, вообще говоря, зарабатывать на IT деньги. Да, новые подходы к технологиям ускоряют эти команды еще больше, но если совсем уж пропустить базовый путь становления и поверх людей, не умеющих работать, натянуть "инновации" – у тебя получися совсем не то же самое, что у топовых игроков на рынке, которые пишут статьи про эти инновации :)