Вместо предисловия. Третья дверь

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

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

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

Поэтому начнём с того, что я действительно знаю.

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

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

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

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

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

И всё же чем лучше я учился строить чужие системы, тем чаще возникал вопрос о своей.

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

Обе двери настоящие. Обе подходят не всем. Но почему мы так редко обсуждаем третью?

Рассмотреть ↗

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

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

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

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

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

какой частью результата своей работы вы хотите владеть — и какую цену готовы за это нести?

Теперь можно начинать.

---

Глава первая. Система, которая работает

Человек между двумя календарями

В разработке есть два времени.

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

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

Обычно конфликт описывают лениво. Бизнесу «надо вчера», IT «вечно тормозит». Шутка удобная, но бесполезная. Она превращает естественное различие оптик в войну характеров.

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

Тогда time-to-market измеряют от постановки задачи в разработку, хотя недели до этого ушли на уточнение потребности. Или, наоборот, объявляют весь путь неуправляемым, потому что «слишком много согласований». Команда ускоряет свой участок, но клиент не чувствует ускорения. Появляются локальные рекорды и глобальное ожидание.

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

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

Рассмотреть ↗

Пять месяцев до платформы. Четырнадцать дней до изменения

В конце сентября 2024 года я пришёл на проект создания нового промышленного контура принятия решений. К ноябрю собрал команду. В декабре началась разработка, в апреле 2025-го решение вышло в эксплуатацию.

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

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

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

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

После запуска средний time-to-market продуктовых изменений составил около четырнадцати дней. Я осторожно отношусь к этой цифре. Она не означает, что любую идею можно безопасно провести за две недели. Изменения различаются по объёму, зависимости иногда сильнее методологии, а среднее любит прятать крайние случаи. Ценность числа в другом: контур перестал каждый раз заново изобретать способ пройти от потребности до эксплуатации.

Тут легко перепутать две победы.

Первая — быстро построить платформу. Она заметна, имеет дату и торжественный момент запуска.

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

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

И ещё один вывод, не очень удобный для персонального бренда. Руководитель не «запускает платформу» один. Его личный результат — создать условия, в которых команда может запустить её и продолжить без постоянного героизма. Поэтому в этой книге я буду различать собственный вклад, вклад команды и эффект организации. Совладение начинается с честной атрибуции задолго до появления долей.

Производственный процесс — не конвейер людей

Слово «производственный» иногда раздражает инженеров. Кажется, что сейчас живого человека превратят в станок, поставят норму на коммиты и объявят творчество отклонением.

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

Хороший процесс отвечает на неприятные вопросы:

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

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

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

Что я увидел в сообществах

С марта 2023-го по ноябрь 2024 года я развивал внутри ГК Иннотех «Техногильдии» — профессиональные сообщества, через которые прошло больше двадцати экспертов и свыше тысячи практических кейсов. Для меня это был не кружок по интересам. Я хотел понять, можно ли масштабировать экспертизу без построения ещё одного административного этажа.

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

Но у сообщества есть предел. Оно может дать репутацию, связь и помощь. Обычно оно не владеет продуктом, не отвечает за общий P&L и не обязано выдерживать конфликт между интересами участников. Добровольность делает его живым и одновременно ограничивает.

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

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

Контракт, который мы редко читаем целиком

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

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

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

Ответы могут быть приемлемыми. Важно, чтобы они были видимыми.

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

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

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

Первая версия третьей двери

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

Уже здесь заканчиваются лозунги и начинается устройство.

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

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

У цифровой артели нет права быть менее точной только потому, что у неё правильные ценности.

Эта мысль станет опорной для всей книги:

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

До правил мы ещё дойдём. Сначала нужно понять, почему вопрос стал актуальным именно сейчас.

---

Глава вторая. Цена задачи

Модель не приходит за профессией целиком

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

Реальная работа распадается на задачи, а задачи — на действия с разной определённостью.

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

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

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

Поэтому корректный вопрос звучит не «какую профессию уничтожит AI», а «какие задачи станут дешевле, какие новые задачи появятся и как изменится стоимость человека, который соединяет их в результат».

Что говорят данные — и чего они не говорят

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

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

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

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

World Economic Forum в отчёте 2025 года опросил более тысячи крупных работодателей. По их ожиданиям, к 2030 году совокупные макротренды, включая технологические, демографические и экономические, создадут 170 миллионов ролей и вытеснят 92 миллиона. Итоговый баланс положительный, но это не утешительный сертификат для конкретного человека. Новая роль может появиться в другой стране, отрасли и квалификации. Переход имеет цену, даже если глобальная сумма выглядит хорошо.

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

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

Первое: изменение уже касается не только рутинного физического труда. Хорошо оцифрованные когнитивные задачи видны модели особенно хорошо.

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

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

Демонстрация и эксплуатация живут в разных вселенных

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

Слово «почти» здесь способно вместить квартал.

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

Я использую внешние AI-инструменты только на личных, открытых или синтетических данных. Это не эффектная принципиальность, а базовая граница. Удобство инструмента не отменяет ответственность за контур.

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

Рассмотреть ↗

Где на самом деле появляется ускорение

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

Допустим, модель помогла написать код вдвое быстрее. Если задача неделю ждала уточнения, две недели — среды, ещё неделю — проверки, клиент получит далеко не двукратный выигрыш. Локальная производительность выросла, time-to-market почти не изменился.

Поэтому я начинаю не с вопроса «куда поставить агента», а с карты потока:

1. Откуда приходит проблема?
2. Как подтверждается ценность?
3. Где решение ждёт человека или данных?
4. Где работа возвращается назад?
5. Какой дефект обнаруживается слишком поздно?
6. Что можно сделать обратимым?
7. Где автоматическая проверка полезнее автоматической генерации?

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

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

Новая единица профессиональной ценности

Если стандартный артефакт дешевеет, профессиональная ценность смещается вверх по цепочке.

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

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

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

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

Источники к главе

• ILO: Generative AI and Jobs, 2025
• ILO: Workers’ exposure to AI, 2026
• World Economic Forum: The Future of Jobs Report 2025
• IMF: AI Will Transform the Global Economy, 2024

---

Глава третья. Чужой рычаг

Не злой умысел, а функция

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

Алгоритм не выбирает распределение. Его выбирают люди в рамках своих полномочий и стимулов.

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

Одновременно нельзя делать вид, что труд — заменяемая строка затрат. Экспертиза накапливается в людях, отношениях и невидимых решениях. Если система умеет учитывать только капитал и формальную должность, она недооценивает то, на чём держится.

Полезнее разложить функцию:

• кто вносит капитал;
• кто несёт ответственность перед внешним миром;
• кто создаёт интеллектуальный актив;
• кто принимает необратимые решения;
• кто получает фиксированный доход;
• кто получает остаток;
• кто может сменить правила.

Рассмотреть ↗

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

Зарплата покупает предсказуемость

Предсказуемость легко обесценить, пока она есть.

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

За эту защиту он отдаёт часть контроля и потенциального роста.

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

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

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

Культура и право

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

Но культура не даёт юридического права.

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

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

Здесь важно не перепутать две вещи.

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

С другой стороны, «мы вас выслушали» не является правом, если решение всегда остаётся у одного человека и не требует объяснения.

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

Когда AI входит в систему стимулов

AI особенно хорошо показывает разницу между культурой и устройством.

Допустим, команда создала внутренний инструмент, который сократил время подготовки изменения. Возможны разные реакции.

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

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

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

Совладение не отменяет тяжёлых решений. Оно меняет право участвовать в их принятии и обязанность разделить последствия.

Субъектность без доли

Собственность — сильный, но не единственный рычаг.

Человек увеличивает субъектность, когда понимает экономику своей работы, видит полный поток создания ценности, умеет договариваться о границах роли и сохраняет переносимый профессиональный капитал. Репутация, сеть контактов, публичное знание, собственный инструмент, метод работы — всё это остаётся с ним дольше конкретного проекта, если не нарушает обязательства перед работодателем.

Именно поэтому я развиваю личные R&D-продукты отдельно от корпоративного контура. LAF — закрытый фреймворк автономного SDLC, которым я пользуюсь сам и коммерческое будущее которого ещё определяю. Dev Planning помогает за несколько минут собрать план большой команды с учётом capacity, зависимостей и производственного процесса. Эти продукты не работают с банковскими данными; внешние модели получают только личный, открытый или синтетический контекст.

Для меня они важны не как строка «основатель» рядом с должностью. Это лаборатория организации труда. Что можно делегировать агенту? Где обязателен quality gate? Как удерживать несколько продуктов без потери контроля? Где автоматизация создаёт скорость, а где только ускоряет ошибку?

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

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

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

В продукте работают по меньшей мере пять капиталов.

Финансовый капитал покупает время, инфраструктуру и право пережить период без выручки. Он измерим, но рубль на старте и рубль после подтверждения рынка несут разный риск.

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

Рыночный капитал — доверие клиента, понимание продажи и доступ к разговору, которого иначе не было бы. Его легко присвоить фразой «это мои контакты» и так же легко обесценить словом «просто познакомил». Настоящий вклад виден по тому, превратилась ли связь в честный клиентский процесс.

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

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

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

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

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

Справедливость здесь не точка. Это способность организации объяснить решение, увидеть перекос и исправить его без распада.

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

---

Глава четвёртая. Третья дверь

Кооператив без мешка картошки

У слова «кооператив» длинная биография и не лучшая работа отдела маркетинга. Оно вызывает образы, далёкие от браузерных движков, AI-агентов и продуктовой аналитики. Но юридическая и культурная оболочка не должна заслонять простой вопрос: кто владеет организацией и кто контролирует её решения?

Рассмотреть ↗

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

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

В России Федеральный закон № 41-ФЗ регулирует производственные кооперативы, включая членство, устав, трудовое участие и распределение прибыли. Но наличие закона не делает любую цифровую модель готовой. IT-продукт добавляет интеллектуальные права, данные, трансграничные сервисы, лицензии, разные виды вклада и вопросы налогообложения. Здесь заканчивается публицистика и начинается работа юриста.

Книга не заменит эту работу. Она может только сформулировать вопросы.

Артель как глагол, а не реконструкция

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

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

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

Если слово однажды начнёт мешать клиенту или участникам понимать модель, его можно заменить. Смысл должен переживать бренд.

Igalia: владеть сложностью, а не только компанией

Igalia начиналась в 2001 году с десяти специалистов в Испании. Сегодня компания работает с компонентами, которые находятся глубоко внутри современной технологической инфраструктуры: браузерными движками, графическими драйверами, языковыми средами, мультимедиа и ядром Linux.

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

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

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

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

CoTech: федерация вместо искусственного гиганта

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

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

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

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

Mondragon: размер не выдаёт иммунитет

Mondragon часто используют как плакат: огромная кооперативная группа, значит модель доказана. Плакат скрывает самое интересное.

Группа выросла из небольшого промышленного проекта в экосистему кооперативов, образования и финансовых институтов. Она показывает, что совместное владение может поддерживать долгий горизонт и сложную координацию. При этом банкротство Fagor Electrodomésticos в 2013 году стало болезненным напоминанием: кооператив не отменяет рынок, технологическое отставание и ошибку стратегии.

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

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

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

Почему не стартап, фриланс или партнёрство

Вопрос «почему не X?» часто маскирует желание найти одну идеальную форму. Идеальной нет. Есть разные распределения капитала, власти и риска.

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

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

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

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

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

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

Условия применимости

Рабочая гипотеза выглядит разумной, если:

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

Модель, вероятно, не подходит, если:

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

Последний пункт особенно важен. «Зато ты совладелец» не должно означать «работай бесплатно, пока основатель решает». Если у человека нет доступа к информации, понятного права и реальной возможности выйти, перед нами не кооператив, а стартап с необычным словарём.

Источники к главе

• International Cooperative Alliance: Cooperative identity, values and principles
• Igalia: About us
• Igalia: Working at Igalia
• CoTech: About
• MONDRAGON: кризис Fagor Electrodomésticos, 2013
• MONDRAGON: трудоустройство затронутых участников, 2014
• Федеральный закон № 41-ФЗ «О производственных кооперативах»

---

Глава пятая. Архитектура артели

Начать с продукта

Организационные идеи любят начинаться с ценностей. Продукты предпочитают начинаться с клиента.

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

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

Мне близки инструменты, которые сокращают полный производственный цикл: планирование capacity и зависимостей, управление качеством работы AI-агентов, трассировка решения от потребности до выпуска. Здесь у меня есть собственный опыт, исходные продукты и понимание боли. Это не доказывает рынок, но делает гипотезу честнее, чем попытка немедленно построить «следующий глобальный AI».

Фронтирная модель требует капитала, данных, вычислений и исследовательской школы другого порядка. Объявлять её первым пунктом дорожной карты небольшой артели — значит подменять стратегию масштабом мечты. Возможно, кооперативные модели когда-нибудь будут владеть данными, вычислениями и моделями большого уровня. Platform Cooperativism Consortium уже описывает эксперименты с кооперативным AI по всей цепочке: труд, данные, модели, инфраструктура и governance. Но путь туда начинается с работающей экономики, а не с красивой оценки будущего бюджета.

Контур ролей

В команде из пяти человек должности кажутся лишними. Все и так знают, кто что делает. Это правда до первого отпуска, конфликта или провала срока.

Роль не обязана быть бюрократической табличкой. Это ответ на четыре вопроса:

1. Какой результат ей доверен?
2. Какие решения она принимает самостоятельно?
3. Где проходит граница бюджета и риска?
4. Когда и кем полномочие пересматривается?

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

Продукт. Отвечает за проблему клиента, приоритет и проверку ценности. Не собирает все пожелания, а выбирает, какое изменение заслуживает времени.

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

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

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

Контур участников. Следит за правилами входа, вклада, конфликта и выхода. Это не HR в уменьшенном виде. Это хранитель организационного договора.

Один человек может нести две роли. Нельзя только оставлять решение без владельца или делать одного человека вечным владельцем всех решений.

Какие решения принадлежат всем

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

К общему уровню разумно отнести:

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

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

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

На практике границу удобнее держать не в памяти, а в небольшой матрице.

Решение	Кто готовит	Кто принимает	Что обязательно зафиксировать
Приоритет внутри продуктовой стратегии	Продуктовая роль	Продуктовая роль	Гипотеза, ожидаемый эффект, дата проверки
Архитектурный выбор в принятом бюджете риска	Технологическая роль	Технологическая роль	Альтернативы, ограничения, план отката
Изменение существенного клиентского обязательства	Рынок + поставка	Делегированный руководитель	Цена, срок, capacity, принятый риск
Приём полноправного участника	Контур участников	Общее решение	Критерии, особые мнения, дата вступления
Продажа ключевого интеллектуального актива	Роли готовят оценку	Общее решение	Цена, конфликт интересов, последствия
Изменение правил распределения результата	Финансовая роль	Общее решение	Модель до/после, переходный период

Матрица не должна расти до каталога на все случаи жизни. Её задача — убрать серую зону там, где цена самодеятельности особенно велика.

Один участник — один голос, но не один вклад

Политическое равенство легко перепутать с экономической одинаковостью.

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

Значит, нужно разделить контуры.

Голос защищает человека от концентрации базовой власти.

Оплата труда компенсирует текущую работу по понятным правилам.

Распределение результата учитывает участие в деятельности и принятый вклад в рамках закона и устава.

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

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

Конкретные формулы должен проверять юрист и налоговый специалист. Федеральный закон № 41-ФЗ устанавливает рамку, но цифровая артель не может переносить общую фразу закона прямо в финансовую таблицу и объявлять вопрос закрытым.

Вход

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

Нужна прозрачная траектория, известная заранее.

Например:

1. Проектный период. Стороны работают по договору над ограниченной задачей. Человек видит финансовую и управленческую модель в объёме, достаточном для осознанного решения.
2. Кандидатский период. Участник берёт ответственность за роль, участвует в обсуждениях и получает формализованный путь к членству, но ещё не голосует по всем вопросам.
3. Полноправное участие. После понятного срока и оценки с обеих сторон человек получает предусмотренные уставом права и принимает обязательства.

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

Отказ тоже должен быть объяснимым и обжалуемым. Иначе входом управляет неформальный клуб основателей.

Выход

Качество организации видно по тому, как из неё уходят.

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

До старта нужны ответы:

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

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

Конфликт

Конфликт не является дефектом системы. Скрытый конфликт — является.

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

Минимальный протокол может быть простым:

1. Стороны формулируют предмет спора и желаемый результат письменно.
2. Отделяют факты от интерпретаций.
3. Проверяют, кому делегировано решение.
4. Если решение выходит за полномочие, привлекают заранее выбранного медиатора или малую комиссию без конфликта интересов.
5. Фиксируют решение, срок проверки и особое мнение.
6. После срока оценивают результат по данным, а не переигрывают эмоцию.

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

Деньги и прозрачность

«Все финансы открыты» звучит хорошо, пока не нужно определить, кому и что именно открыто.

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

Полезен короткий ежемесячный отчёт:

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

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

Quality gates как организационный принцип

В LAF я использую обязательные quality gates: агент или человек не может объявить работу готовой только потому, что закончил свой шаг. Нужны проверка, сборка, тесты и доказательство результата в том контуре, для которого он предназначен.

Мне кажется, этот принцип шире разработки.

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

Quality gate — момент, в котором утверждение встречается с доказательством.

Рассмотреть ↗

Цифровая артель заслужит название не в день регистрации, а в день, когда её правила выдержат первые деньги, первый конфликт и первый выход.

Источники к главе

• Platform Cooperativism Consortium: Cooperative AI in 2025
• PCC: Worker-owned cooperative models for training AI
• Федеральный закон № 41-ФЗ, статья 5: устав
• Федеральный закон № 41-ФЗ, статья 12: распределение прибыли
• Федеральный закон № 41-ФЗ, статья 19: регулирование труда

---

Глава шестая. Малый контур

Почему девяносто дней

Большая идея легко переживает годы, если её не проверять.

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

Рассмотреть ↗

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

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

Неделя ноль: договориться до вдохновения

До начала разработки команда заполняет одну страницу.

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

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

Граница. Что мы сознательно не делаем в эти девяносто дней?

Состав. Кто отвечает за продукт, технологию, поставку и разговор с рынком?

Вклад. Сколько времени и денег каждый готов вложить без ущерба базовым обязательствам?

Решения. Какие вопросы делегированы ролям, какие требуют общего согласия?

Выход. Что происходит с кодом, расходами и обязательствами, если эксперимент остановлен?

Стоп-критерии. При каких данных мы прекращаем работу, даже если продукт нравится нам самим?

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

Первый месяц: проблема до продукта

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

Первый месяц нужен для обратного.

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

Сильный сигнал — не фраза «интересная идея». Сильный сигнал требует от человека действия: познакомить с ответственным, дать обезличенный пример, согласовать пилот, выделить время команды, подписать письмо о намерении или заплатить.

Заодно проверяется состав артели. Кто умеет слушать, не защищая решение? Кто фиксирует противоречия? Кто возвращает неприятную информацию, а кто смягчает её до удобства?

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

Второй месяц: самый узкий работающий путь

Теперь можно строить.

Не платформу. Не экосистему. Не универсальный AI-контур для любой компании. Один путь, на котором пользователь получает измеримую ценность.

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

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

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

Каждую неделю полезно задавать четыре вопроса:

1. Что мы узнали о проблеме?
2. Какое решение приняли и кто имел полномочие?
3. Что пришлось переделать?
4. Какой риск стал дороже?

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

Третий месяц: деньги и неприятности

Третий месяц нужен не для полировки. Он нужен для контакта с последствиями.

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

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

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

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

Табло эксперимента

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

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

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

Три возможных финала

После эксперимента есть три честных варианта.

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

Продолжить как проект. Ценность есть, но модель совладения пока не проверена или не нужна. Команда может работать по обычному договору, не надевая на отношения идеологию раньше времени.

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

Заметьте, только третий вариант приводит к артели. Название не является целью эксперимента.

Что может всё испортить

Некоторые риски стоит назвать до того, как они придут.

Основательская гравитация

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

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

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

Бесплатный героизм

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

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

Демократия как отсрочка решения

Если владелец роли боится принять непопулярное решение, он выносит его на общее обсуждение. Ответственность растворяется, а собрание перегружается.

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

AI как третий основатель

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

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

Юридическая самоуверенность

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

Юрист и налоговый специалист нужны до первого сложного обещания, а не после первого спора. Книга намеренно не предлагает готовой схемы.

Отсутствие продаж

Инженерная команда может месяцами улучшать продукт и называть это исследованием. Если никто не отвечает за рынок, артель становится дорогим R&D-клубом.

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

Нативная реклама вместо отчёта о собственной гениальности

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

Сильный публичный разбор должен показать путь:

• с какой формулировкой проблемы команда ошиблась;
• какое решение пришлось отменить;
• где AI дал измеримое ускорение, а где добавил проверку;
• какой конфликт обнаружил дефект правил;
• что заплатил клиент и за что именно;
• какой вклад был недооценён;
• почему команда продолжила или остановилась.

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

Если эксперимент получится

Самый опасный момент наступит не при провале, а при первом успехе.

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

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

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

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

Первый масштаб — не сто участников. Первый масштаб — второй продукт, который работает без ежедневного присутствия автора.

Право на своё

Я долго думал, чем закончить книгу.

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

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

В соседней комнате растут мои сыновья.

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

Я знаю только, чего не хочу им обещать.

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

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

Свобода не в том, чтобы всегда выбирать «своё». Свобода в том, чтобы понимать цену каждой двери и иметь право открыть ещё одну.

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

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

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

Не спасать будущее.

Построить первый работающий путь к нему.

Владимир Ловцов
Ваш ДПУПП

---

Приложение. Как проверялись утверждения

Пять уровней уверенности

В книге намеренно разделены разные типы утверждений.

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

Наблюдаемый факт. Определение кооператива, нормы закона, публичное описание Igalia и CoTech, методология ILO. Здесь используются первичные или официальные источники.

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

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

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

Основные источники

Работа и AI

1. International Labour Organization, Generative AI and Jobs: A Refined Global Index of Occupational Exposure, 2025
2. International Labour Organization, Workers’ exposure to AI: What indicators tell us and what they do not, 2026
3. World Economic Forum, The Future of Jobs Report 2025
4. International Monetary Fund, AI Will Transform the Global Economy, 2024

Кооперативная модель

5. International Cooperative Alliance, Cooperative identity, values and principles
6. Igalia, About us
7. Igalia, Working at Igalia
8. CoTech, About
9. MONDRAGON, Fagor Electrodomésticos crisis, 2013
10. MONDRAGON, relocation of affected members, 2014
11. Platform Cooperativism Consortium, News from 2025
12. Platform Cooperativism Consortium, Worker-owned cooperative models for training AI

Российская правовая рамка

13. Федеральный закон № 41-ФЗ «О производственных кооперативах»
14. Статья 5. Устав кооператива
15. Статья 12. Распределение прибыли кооператива
16. Статья 19. Регулирование труда членов кооператива

Юридическая оговорка

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