Синергия сообществ: как большой IT-компании пользоваться собственной экспертизой

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

Представь большую IT-компанию. Кто-то знает Oracle почти на ощупь, кто-то годами работает с Teradata, кто-то умеет разбирать тяжёлые графовые запросы. В одном подразделении наконец разобрались, почему ночная загрузка данных разваливалась после каждого изменения источника. В другом похожий ETL чинят уже полгода, и временное решение успело обзавестись собственными временными решениями. Обе команды вполне могут находиться в одной группе компаний, пользоваться одной корпоративной почтой и никогда друг о друге не слышать.

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

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

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

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

Решение, которое я предлагаю обсудить, вполне конкретно. Выбрать несколько повторяющихся дорогих задач, выделить на них ограниченное время специалистов и проверить, можно ли решать их совместно с меньшими совокупными затратами. За результат отвечает руководитель, способный согласовывать приоритеты разных команд. Участники заранее знают условия, а компания — предел расходов и момент, когда эксперимент пора оценить. Мой опыт дал основания для такой проверки; результат в масштабе всей корпорации ещё предстояло бы получить.

Выбирать эти задачи нужно вместе с владельцами IT-стратегии. Если компания выводит технологию из эксплуатации, не стоит создавать вокруг неё новую постоянную платформу только потому, что нам интересно её развивать. Но может быть нужен короткий совместный проект по миграции. В другом месте стратегия требует ускорить выпуск продуктов — тогда общий инструмент поставки может оказаться важнее очередного самостоятельного сервиса. У сообщества должна быть возможность предлагать решения, а у руководства — понятная связь этих решений с направлением бизнеса.

Если сейчас важнее решение о вложениях, можно перейти к расчёту масштаба и условиям пилота.

Как я пришёл к Техногильдиям

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

При этом у меня не было желания переименовать отделы, нарисовать новую структуру и объявить компанию свободной. Меня занимала вполне производственная задача. В большой группе уже есть знания, люди и опыт. Как сделать так, чтобы всё это чаще встречалось с нужной задачей?

Первые подходы я пробовал ещё в работе с командой графовой платформы. В 2023 году, когда возглавил направление прикладных сервисов Big Data, потребность стала значительно острее. В портфеле оказались графовая, гео- и ML-платформы, NER-сервисы — системы извлечения именованных сущностей из текста. Развивать всё это требовалось одновременно.

За короткими названиями скрывались очень разные области. Графовые структуры и запросы, Spark и ETL, Go-сервисы, API, Kafka, фронтенд и микрофронтенды, геослои и геополигоны. Где-то нужно было понимать алгоритм, где-то — устройство данных, где-то — особенности промышленной эксплуатации. Нельзя просто сказать команде «разберитесь с Big Data» и считать постановку законченной.

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

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

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

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

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

С темой синергии сообществ я собирался выступить на «Импульсе», но доклад сняли с программы. На Инфостарте выступление состоялось; оно упомянуто в отчёте INFOSTART TECH EVENT 2023. Сейчас у меня есть возможность изложить замысел подробнее, чем позволяет конференционный слот, и посмотреть на него с учётом последующего опыта.

Что происходило между людьми

Самая важная часть Техногильдий начиналась с простого действия. Человек мог прийти с вопросом, для которого внутри своей команды не нашлось достаточно опыта, и получить доступ к другим специалистам.

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

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

У сообщества появлялись собственные инструменты. Сначала представили бота-помощника для вопросов по программированию, позже занялись учётом обращений, включая возможность задать вопрос анонимно. В итоге обсуждали уже связку доски кейсов и бота. Смысл был практический — не терять вопрос между сообщениями и видеть, кому ещё нужна помощь. Разобраться в задаче и принять результат всё равно предстояло людям.

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

По моей оценке, около 5% были особенно тяжёлыми, ещё примерно 15% — сложными, около 40% — среднего уровня. Оставшиеся примерно 40% составляли простые вопросы, где часто хватало короткого ответа или подсказки, чтобы человек сразу продолжил работу. Это моя приблизительная оценка по опыту, а не распределение из выгрузки заявок. Доля обращений не равна доле трудозатрат: один тяжёлый разбор мог потребовать больше времени, чем десятки быстрых ответов.

Когда нужный человек оказался рядом

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

Моя команда и сложный Scala-код

Начну со своей команды. У нас был большой объём Scala-кода со сложными преобразованиями данных. На эту область пришёл специалист уровня junior+: с языком он уже соприкасался, но опытным Scala- или ETL-разработчиком ещё не был. А задачи, которые ему предстояло решать, такого опыта требовали.

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

По нашей оценке, к моменту обращения за помощью сотрудник разбирался с проблемой уже около двух месяцев и так и не получил решения. Я подключил коллегу, который много лет писал ETL на Scala и Spark. На анализ у него ушло несколько часов, а примерно за восемь часов суммарно он подготовил готовый способ исправления. К концу рабочего дня у команды было решение, объяснение его логики, указания на возможные узкие места и рекомендации сотруднику, что изучать дальше.

Вот такой эффект я действительно видел в своей команде. При этом два месяца здесь — прошедшее время, а восемь часов — приблизительная оценка участия эксперта. Табеля по каждой попытке у меня нет. Предыдущий разбор мог дать материал, который помог эксперту быстрее разобраться, поэтому объявлять ускорение ровно в сорок раз было бы неправильно. Но управленческий вывод для меня вполне определённый: задаче требовалась точечная экспертиза, и доступ к ней изменил результат.

Теперь прикинем деньги на простом примере. Пусть зарплата исполнителя — 200 тысяч рублей в месяц, а день эксперта оценивается в 20 тысяч. Если все два месяца исполнитель занят только этой задачей, на неё приходится 400 тысяч рублей против 20 тысяч за день эксперта. Ставки условные. Здесь сравниваю только зарплатную стоимость времени: обе суммы до удержаний, без страховых взносов, накладных расходов и наценки подрядчика. Для бюджета компании потребуется полная стоимость обеих сторон.

20 000 / 400 000 = 5%. День эксперта стоит одну двадцатую двухмесячной зарплаты. Для руководителя это веская причина проверить, не слишком ли поздно команда получает нужную помощь. Дорогой час специалиста вполне может оказаться дешёвым способом сдвинуть задачу.

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

Экономический смысл ранней помощи я вижу в следующем. Если в похожей будущей задаче день эксперта позволит избежать всех двух месяцев поиска, разница составит 400 000 − 20 000 = 380 000 рублей до затрат на подготовку, проверку и внедрение. Это сильное допущение: эксперт должен получить необходимый контекст, а итог — пройти ту же приёмку. Два месяца без решения из моей истории сами по себе не доказывают ни такой альтернативный срок, ни возможность пропустить всю предварительную работу.

Для менее удачного случая правило остаётся простым: стоимость действительно предотвращённого труда минус 20 тысяч за эксперта и остальные затраты помощи. При зарплате 200 тысяч и условных 20 рабочих днях в месяце день исполнителя стоит 10 тысяч. Без дополнительных расходов помощь оправдывает себя по труду, если предотвращает больше двух его рабочих дней. Подготовка и проверка поднимут этот порог. Если выплаты не уменьшились, выигрыш остаётся доступным временем для других задач; денежная экономия требует изменения расходов. А ценность снятой блокировки и обучения можно оценить отдельно, когда есть данные, не складывая повторно один и тот же эффект.

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

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

Не всегда сразу видно, что человек застрял. Он осваивает новую технологию, проверяет гипотезы, что-то начинает получаться — а затем задача оказывается глубже, чем выглядела вначале. Учиться на работе нормально; понять, где заканчивается полезный поиск и нужна помощь, бывает непросто. Да и бюджет на отдельного опытного специалиста есть далеко не под каждую такую задачу.

Сейчас я бы раньше назначил совместный разбор: если к согласованному сроку нет ни проверенного объяснения проблемы, ни следующего осмысленного шага, пора искать дополнительную экспертизу. Это может быть короткая консультация коллеги. Не обязательно сразу расширять команду, но и оставлять человека один на один с проблемой только потому, что его фамилия стоит в плане, не стоит.

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

Ещё два законченных разбора

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

Полезным оказался сам порядок диагностики. Эксперт разделил большую неисправность на проверяемые части: отдельно проверить доступность взаимодействия, отдельно — небольшой воспроизводимый пример, затем — то, как один инструмент передаёт настройки другому. После исправления конфигурации сообщения удалось отправить. Работа наконец получила проверяемый результат.

Почему такой разбор бывает трудным? Представь интеграцию Spark с Kafka. Часть параметров относится к клиенту Kafka, часть — к коннектору Spark; внешне они лежат рядом и похожи на один список настроек. Но Kafka-параметры передаются с префиксом kafka., например kafka.bootstrap.servers, а собственные параметры коннектора, такие как subscribe, устроены иначе. Это описано в официальном руководстве Spark. Если не различать эти уровни, можно долго исправлять правильное значение в неправильном месте.

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

Во втором случае запрос выглядел ещё проще: помочь собрать Python-библиотеку. Но библиотека зависела от нативного SDK, и обычной установки пакета оказалось недостаточно. Я перенёс запрос в сообщество, попросил описать ситуацию подробнее и подключил коллег с подходящим опытом.

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

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

Здесь сообщество помогло пройти путь от вопроса до подтверждённого результата. Отправленная ссылка была бы промежуточным шагом. Моя работа заключалась в том, чтобы запрос не затерялся, получил нужный контекст и дошёл до людей, способных помочь. Сборку выполняли специалисты — и важно не присваивать их работу организатору.

Эти эпизоды показывают пользу доступной экспертизы. Сами по себе они ещё не доказывают окупаемость корпоративной платформы. Более того, в какой-то момент меня спросили, сохраняем ли мы разобранные случаи, и пришлось признать: успеваем не всё. У человека, которому помогли, задача уже закончилась. У компании в этот момент могла только начаться другая работа — сделать результат пригодным для следующей команды.

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

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

Это небольшой, но важный момент: внутри компании встретились потребность и существующий результат. Договорённость о разборе подтверждается; дальнейшего внедрения и измеренной экономии по этой истории я утверждать не могу. Именно здесь я бы продолжил проверку. Совпадают ли требования? Можно ли передать решение в пределах прав на него и допустимого доступа? Сколько займёт адаптация, кто её выполнит и кто затем подтвердит результат? Иначе обещание показать полезную вещь легко остаётся приятным разговором.

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

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

Компания, которую можно увидеть поперёк отделов

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

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

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

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

Я бы хранил отдельно сведения о людях, подтверждённой практике, задачах, готовых решениях и времени. Запись «знает Kafka» мало помогает при распределении работы. Нужно понимать, что за ней стоит. Подключал клиент? Проектировал доставку? Разбирал повторы при восстановлении? Может объяснить, что произойдёт с внешней системой, если обработка выполнится дважды?

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

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

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

Из чего складывается Технохаб

Давай проследим следующий шаг на условном примере. Это уже иллюстрация устройства Технохаба, а не продолжение истории конкретной команды. Несколько продуктов независимо делают загрузку данных. Один инженер замечает повторяющуюся работу и предлагает вынести общую часть. Пока у него есть хорошая идея, собственный спринт и вполне обоснованный вопрос руководителя: кто всё это будет поддерживать?

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

Это близко к описанию сообществ практики у Этьена и Беверли Венгер-Трейнер: общая область интереса, взаимодействие и развиваемая практика. Одной подписки на канал для этого недостаточно. Ценность появляется, когда участники регулярно используют знания в деле.

А теперь представим, что продуктам действительно нужна регулярная помощь. Они рассчитывают на срок ответа и принимают свои обязательства с его учётом. Здесь требуется центр компетенций или другая служба с назначенными исполнителями и оплаченным временем. Название можно выбрать привычное для компании. Обязательный срок нельзя обеспечивать добровольными свободными вечерами.

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

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

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

Проектные команды при этом продолжают отвечать за свой продукт. До начала помощи они вместе с экспертом согласуют результат консультации, критерий её завершения и объём повторного разбора. Совет должен выдержать оговорённую проверку, но это не делает специалиста бессрочной службой поддержки. Внедрение и эксплуатацию принимает команда; дальнейшее сопровождение отдельно обеспечивают временем.

Свобода, на которую можно опереться

Идеи бирюзовых организаций повлияли на мой взгляд на управление. В книге и материалах Фредерика Лалу мне особенно близки самоуправление, возможность оставаться собой в работе и развитие организации вместе с её задачами. Я не воспринимаю эти идеи как готовую инструкцию для любой компании, но они помогают задать полезный вопрос: какие решения взрослые специалисты могли бы принимать сами?

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

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

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

В разборе самоуправляемых организаций Франка Мартелы полезно напоминание, что распределение задач, координация и направление работы всё равно необходимы. У компании не исчезают эти обязанности после сокращения уровней управления. Меняется способ их выполнения.

Почему люди придут и почему перестанут приходить

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

Я встречал сильных специалистов, которым нравилось консультировать и помогать коллегам расти. Иногда для короткого ответа находилось время между задачами, иногда удавалось договориться об отдельном оплаченном разборе. Но восемь часов из Scala-кейса — уже рабочий день, его нужно откуда-то взять. Вечер или выходной может предложить сам человек на понятных условиях; превращать такую готовность в обязательный источник мощности я бы не стал. И по присутствию в чатах нельзя определить, сколько времени у сотрудника действительно свободно.

Но у человека есть жизнь за пределами компании. Ипотека, дети, здоровье, усталость, желание вечером просто побыть дома. Нельзя считать, что интерес к технологии автоматически оплачивает всё остальное.

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

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

Что человек получает от участия? Сложную практику, возможность учиться у сильных коллег, признание, влияние на решения, новые профессиональные связи. Иногда — выход из узкой роли, в которой он давно перестал расти. Всё это имеет ценность, если доступно в действительности.

Работа Мэрилин Ганье и Эдварда Деси о мотивации труда помогает объяснить значение самостоятельности, ощущения компетентности и связи с другими людьми. Эти потребности хорошо видны и без анкет, когда специалист впервые получает право предложить своё решение и поддержку, необходимую для его проверки.

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

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

Сообщество быстро замечает подобные противоречия. Люди могут некоторое время продолжать по привычке, а потом самые деятельные исчезнут. Снаружи это выглядит загадочно: ведь канал есть, встречи идут, руководство поддерживает. Внутри всё проще — обещанный обмен перестал работать.

Что должен получить руководитель, который отпускает эксперта

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

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

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

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

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

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

Самого эксперта нельзя превращать в диспетчера этого конфликта. Он не должен выбирать, кому из двух начальников отказать, а потом отрабатывать выбор вечером. Организация обязана уметь распределять собственные обязательства.

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

Как общение становится производственным результатом

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

Допустим, разбор всё же состоялся. Участникам понравилась идея общего компонента, встречу провели отлично. Руководителю пока рано записывать экономию. Нужно узнать, что изменилось у команды после разговора: удалось ли применить подход, что пришлось переделать и кто возьмёт оставшуюся работу.

На входе не требуется сочинять техническое задание на десять страниц. Достаточно объяснить задачу, ограничения, уже сделанные попытки и то, какой результат нужен. Логи и данные подготавливают так, чтобы не вынести лишнее за пределы разрешённого доступа. Иногда несколько минут на минимальный воспроизводимый пример экономят часы совместного обсуждения.

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

Но закрывать обращение сразу после отправки ссылки слишком рано, если обещали помочь решить задачу. Хорошо бы узнать, подошёл ли материал, какие ограничения обнаружились, понадобилась ли адаптация. В противном случае у эксперта будет коллекция ответов, а у команды останется прежняя проблема.

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

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

Как посчитать решение для всей компании

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

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

Поэтому ниже — модель выбора для условной компании. Она нужна, чтобы сравнивать варианты и видеть допущения. Это не описание внедрённого у нас оптимизатора и не обещание процента экономии.

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

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

Я бы сравнивал именно эти варианты. Сам по себе приказ «всем переиспользовать» ещё ничего не оптимизирует.

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

H = n × (b − a) − F

n > F / (b − a)

Минимизировать C = Σⱼ Σᵣ cⱼᵣ xⱼᵣ + Σₖ Fₖ yₖ

Для каждой задачи j:      Σᵣ xⱼᵣ = 1
Для недопустимого пути:   xⱼᵣ = 0
Если путь требует k:     xⱼᵣ ≤ yₖ

Для каждого человека i:
Σⱼ Σᵣ hᵢⱼᵣ xⱼᵣ + Σₖ gᵢₖ yₖ ≤ Aᵢ − Rᵢ

xⱼᵣ, yₖ ∈ {0, 1}

ρ = λ × s
Wq = s × ρ / (1 − ρ),  0 ≤ ρ < 1

L = λ × W

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

Какой эффект возможен на ста, тысяче и десяти тысячах сотрудников

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

Возьмём один год и IT-контур численностью от 100 до 10 000 человек. Для примера зададим 1600 доступных рабочих часов и 4 млн рублей полной годовой стоимости на одного сотрудника. Получается 2500 рублей за час. Это выбранные для расчёта величины, не сведения о зарплатах в моей компании и не средние показатели рынка. Пока считаем часы одинаково дорогими; если помощь эксперта стоит больше, это нужно отдельно учесть.

В базовом сценарии четверть работы подходит для совместного решения или переиспользования. За год программа реально охватывает 60% этой части и устраняет 40% её прежних трудозатрат. Это 6% исходного фонда, а не 40% всей компании. Из выигрыша ещё предстоит вычесть помощь экспертов, первоначальную подготовку общих решений, адаптацию, проверки, поддержку и организацию работы. Устранённые часы считаются при сопоставимом результате и качестве; время на исправление новых ошибок не исчезает из расчёта.

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

Вот результат базового сценария. Ресурсный столбец — оценка высвобождённого ресурса по выбранной ставке за вычетом внешних расходов. Второй требует дополнительного условия: 20% чистого ресурса позволяют действительно отменить ранее необходимые выплаты по сопоставимой стоимости. Например, команда берёт работу, для которой иначе пришлось бы оплатить подрядчика. Эти столбцы нельзя складывать.

Все суммы в таблице — миллионы рублей за условный год.

На тысяче человек это можно разложить без сложной математики. Исходный фонд — 1,6 млн часов. Подходят 400 тысяч, реально охвачены 240 тысяч, удалось устранить 96 тысяч часов прежней работы. Помощь, подготовка общих решений, адаптация и поддержка потребовали 33 600 часов, координация — ещё 8560. Осталось 53 840 часов, или 33,65 годового фонда одного сотрудника. Это распределённая мощность с разными компетенциями и календарями, а не 34 готовые к сокращению должности.

Стоимость этой мощности по нашей ставке — 134,6 млн рублей. Дополнительные выплаты на инструменты и внешние услуги составляют 9 млн, поэтому ресурсный итог равен 125,6 млн. Если подтверждённо предотвращены выплаты лишь на пятую часть чистого ресурса, это 26,92 млн; после 9 млн дополнительных расходов денежный итог равен 17,92 млн рублей.

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

У неблагоприятного сценария на тысяче человек ресурсный итог −12,4 млн рублей, денежный — −9 млн. Программа потребляет больше внутреннего времени, чем освобождает. Если для сохранения прежнего выпуска придётся оплатить дополнительную работу, денежный результат станет ещё хуже: таблица не предполагает бесплатного восполнения потерянной мощности. Это основание менять способ работы или останавливать программу.

G = N × 1600 × q × a × g                 — валовые устранённые часы
L = G × (e + d + m)                     — помощь, подготовка общей части, адаптация, поддержка
K = 0,25 + N / 200 + 0,1 × (N / 1000)²  — годовые фонды координации
H = G − L − 1600 × K                    — чистый ресурс, часы
X = 1 000 000 + 8000 × N                — дополнительные выплаты, ₽
V = H × 2500                           — стоимость чистого ресурса, ₽
Eрес = V − X                           — ресурсный итог, ₽
S = r × max(V, 0)                      — предотвращённые выплаты, ₽
Eден = S − X                           — денежный итог, ₽

Какие условия нужны для миллиардного эффекта

В компании на 10 000 сотрудников условная годовая стоимость труда в нашей модели равна 40 млрд рублей. В сильном сценарии подходят 35% работы, среднегодовой охват этой части достигает 80%, и внутри неё устраняется половина прежних часов. Всего это 14% исходного фонда — 2,24 млн часов за год. Нужно перестроить большой объём работы, а не просто повторить несколько удачных консультаций. После помощи, адаптации, сопровождения и координации остаётся ресурс с расчётной стоимостью 3,959 млрд рублей. Из него ещё нужно получить полезную работу или реально сократить необходимые выплаты.

Если 40% этого чистого ресурса превращаются в подтверждённо предотвращённые выплаты, а внешние расходы программы составляют 81 млн, годовой денежный результат равен 1,5026 млрд рублей. Для миллиарда при остальных неизменных сильных вводах понадобится реализовать в деньгах не менее 27,31% чистого ресурса. Это высокая планка: нужны подходящий спрос, устойчивое внедрение, доступная экспертиза и действительно изменяемые расходы. В базовом сценарии на тех же 10 000 сотрудников получаются 182,8 млн рублей, а не миллиард.

Проверим, насколько результат зависит от одного допущения. Если в том же сильном сценарии денежная реализация составит 20% вместо 40%, итог снизится до 710,8 млн рублей. При нулевой реализации денежный результат будет минус 81 млн. А уменьшение охвата или рост расходов на помощь снизят и сам ресурс, от которого считаются эти проценты.

Здесь я решаю обратную задачу: какие условия нужны, чтобы получить миллиард? Арифметика даёт ответ, но не подтверждает, что такая комбинация условий достижима в конкретной компании. У меня нет измерений, которые позволяли бы назвать её ожидаемым результатом. «Базовый» сценарий тоже выбран для сравнения, а не как наиболее вероятный прогноз. Все сценарии относятся к IT-контуру; 10 000 сотрудников всей группы ещё не означают 10 000 участников этой модели.

В обсуждении с владельцем я бы оставил миллиард как проверку масштаба замысла. Для решения о вложениях нужны другие строки: какие именно работы перестанем дублировать, какие обязательства по выплатам отпадут и сколько стоит перестройка. Если они не сходятся, большой итог в таблице не спасёт проект. Результат одного Scala-разбора не заполняет эти строки за всю корпорацию.

Для решения о бюджете нужны три отдельные сверки: что изменилось в доступной мощности, какие выплаты действительно изменились и какие суммы признаны в финансовом результате. Подробности расчёта можно раскрыть ниже.

Общее решение должно быть удобно брать

Повторное использование требует понятных границ. Компонент должен объяснять, какие входные данные принимает, какие гарантии даёт и кто отвечает за изменения. Иначе десять команд получат десять неявных зависимостей от автора библиотеки.

Мне близок разбор Карлисс Болдуин о модульности и устройстве платформ: возможность менять части системы связана с её архитектурой и организацией работы. Отсюда я беру практический вопрос — где общая граница действительно уменьшает зависимость, а где мы только переносим сложность к другой команде.

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

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

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

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

Нужен и владелец сопровождения. Кто исправляет уязвимость? Кто оплачивает поддержку предыдущей версии? Кто принимает несовместимое изменение? Как потребитель узнаёт о прекращении развития? Пока ответы зависят от доброй воли первоначального автора, у нас есть полезная наработка, но ещё нет устойчивой общей услуги.

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

Обратная крайность тоже знакома. Любое отличие объявляется уникальным, и каждая команда продолжает писать всё сама. Здесь помогает совместный разбор: что действительно различается, а что можно выделить в общую часть? Иногда переиспользуется библиотека, иногда схема тестирования, методика миграции или критерии выбора. Польза не обязана принимать форму единой платформы.

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

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

Что изменилось с появлением LLM

Сегодня часть поиска можно сделать намного быстрее. Большая языковая модель помогает набросать варианты, разобрать документацию, сравнить подходы, подготовить тест или объяснить незнакомый код. Я сам активно пользуюсь этой возможностью.

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

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

Можно запустить хоть миллион агентов. Но кто-то должен определить, какие задачи им вообще разрешено решать, откуда брать данные и что считать принятым результатом. Если несколько команд независимо строят одинаковых помощников, у компании снова появляются дублирующие решения, расходы и обязательства по поддержке. Знакомая задача Технохаба никуда не делась; в каталоге появились новые исполнители и новые виды ошибок.

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

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

Для проверки состава затрат можно посмотреть, как AWS Bedrock разделяет тарификацию моделей и сопутствующих возможностей, а для перечня рисков — профиль генеративного AI от NIST. Собственное размещение меняет устройство расходов, но не обнуляет вычисления и эксплуатацию. Ни один из этих источников не доказывает эффект конкретного внедрения. В расчёте выше использование LLM изменило бы стоимость помощи, проверки и инструментов; добавлять сверху ещё независимый процент «экономии от AI» по тем же задачам нельзя.

Когда я вспоминаю несохранённые разборы, здесь особенно хочется применить LLM. Помощник мог бы собрать черновик заметки из разрешённых материалов, выделить принятый вариант и оставить спорные места для проверки участникам. Это предложение дальнейшего устройства системы, а не описание уже полученного результата наших ботов. Главное — получить материал, который инженер действительно проверил, а не быстро заполнить базу знаний убедительным пересказом.

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

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

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

Появление LLM увеличивает скорость некоторых действий и меняет цену поиска. Одновременно растёт значение отбора, проверки и ответственности за принятое решение. Сообщество может помогать именно здесь — собирать практику применения и обсуждать ошибки, которые один человек легко пропустит.

Как не убить то, что начало работать

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

В моей истории это видно по смене собственного участия. Когда времени на поддержку стало меньше, я искал людей, готовых продолжить организационную работу. Наличие доски и бота не решало вопроса: кто будет разбирать новые обращения и выполнять принятые обязательства? Здесь я столкнулся с ограничением замысла, который слишком многое оставлял на личной вовлечённости.

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

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

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

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

Можно требовательно проверять решение и уважительно говорить с автором. Вопрос «что произойдёт при повторной доставке?» помогает проекту. Демонстрация чужой некомпетентности перед всем чатом в следующий раз заставит человека промолчать.

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

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

При смене организатора полезно проверить очень приземлённые вещи. Кто владеет каналом и ботами, кто имеет доступ к рабочим материалам, кто оплачивает инфраструктуру, кто продолжает обязательства перед командами.

Как я проверял бы большой замысел сейчас

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

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

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

Сначала сравнил бы замысел с самым простым вариантом: согласованные часы нескольких экспертов и учёт обращений в уже имеющихся инструментах. Если этого достаточно, отдельную платформу строить незачем; её стоимость должна оправдываться задачами, с которыми простой порядок помощи уже не справляется.

Решение о запуске я бы записал на одной странице. Какую повторяющуюся задачу проверяем, кто вправе согласовать общий приоритет, сколько часов и денег выделено, кто принимает результат и в какую дату мы решаем судьбу пилота. Рядом — допустимые данные, условия отказа от запроса и способ разрешить конфликт планов. Значения согласуют участники конкретного пилота; эти пределы нельзя молча расширять при первом затруднении.

На пилоте я смотрел бы на три результата одновременно. Получила ли команда полезное изменение? Получил ли участник обещанные условия и профессиональную пользу? Сократилась ли суммарная работа компании с учётом времени экспертов, организаторов и сопровождения?

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

Сравнение «до» и «после» тоже требует аккуратности. За это время могли измениться команда, нагрузка, инструменты и приоритеты. Я бы фиксировал исходные предположения, проверял результат с принимающей стороной и по возможности сравнивал похожие задачи. Один удачный пример даёт основание продолжать проверку, но не объявлять результатом всей корпорации.

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

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

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

Что я забираю из этого опыта

Мне до сих пор нравится замысел Техногильдий и Технохаба. Он дал практический результат в той части, которую удалось применить, и позволил увидеть собственные недоработки. Найти эксперта и помочь команде — уже полезно. Сохранить результат, договориться о регулярной работе и подготовить преемников оказалось отдельной, значительно более долгой задачей.

Сейчас у меня другой управленческий контекст, книга, собственные проекты, работа с LLM и консультации. Я выбираю, куда могу вложиться всерьёз. Обещать большой инициативе развитие без времени на неё было бы странным продолжением статьи о доступности ресурсов. Если возвращаться к этому замыслу в полном объёме, я хотел бы видеть у него заказчика внутри организации, достаточно длительный горизонт и готовность выполнять взаимные обязательства.

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

Я верю в желание людей создавать и в свободу, которая позволяет этому желанию стать работой. Моя задача как руководителя — разобраться, что мешает, обеспечить условия и проверить результат. Техногильдии были одной из таких попыток. Всё задуманное осуществить не удалось, но этот опыт изменил то, как я смотрю на большую компанию: многое из того, что ей нужно, уже умеют её люди. Остаётся сделать так, чтобы они могли воспользоваться этим вместе.

Если узнал здесь задачу своей компании, напиши мне. У меня осталось гораздо больше опыта и примеров, чем вошло в статью. Готов обсудить их подробнее в пределах обязательств по конфиденциальности, рассказать, как была устроена работа, и помочь применить подход у вас — от разбора текущей ситуации до организации пилота.

P. S. У меня долго не доходили руки собрать этот опыт в один подробный текст. Материалов и мыслей накопилось много, а времени на прежние каналы и большие публикации становилось всё меньше. Сейчас LLM помогли мне структурировать накопленное и наконец подготовить эту статью. За собственный опыт, выбранные объяснения и выводы здесь отвечаю я.

Редакция от 22 октября 2026 года. Статья развивает тему моего выступления на INFOSTART TECH EVENT 2023.

Ваш ДПУПП