«30 марок × 30 фабрик» — пилот Производственной сети Альянса внутри кооперационных контуров. Наша цель — вырасти до 200 марок × 200 производств.
Марка размещает запрос в агрегаторе заказов, фабрики откликаются и показывают свой опыт в базе производств. Дальше стороны уточняют задание, считают заказ и решают, работать ли вместе. Здесь мы описываем, как проверяем этот путь и о каких правилах договариваемся в команде.
Один проект марки и производства находится внутри программы 30 × 30; программа — внутри Производственной сети; сеть — один из контуров Альянса.
Как из разговора возникает требование
Сообщение марки или фабрики сначала становится фактом с источником, временем и контекстом заказа. Оно не превращается автоматически в новое правило или задачу программисту. Мы выясняем, чья потребность стоит за сообщением, как она затрагивает другую сторону и какое изменение действительно нужно. Если по одному заказу разговаривают с несколькими фабриками, каждой линии нужны свои расчёт, вопросы и решение; один общий статус не должен скрывать их различия.
В пилоте многие переходы держались на личных сообщениях куратора. Для масштаба 200 марок × 200 производств повторяющиеся вопросы и подсказки превращаем в проверяемую цепочку сообщений и ответов на частые вопросы внутри существующих шагов пути участника. Это мост между H — тем, что человек спросил или сделал в сопровождении, — и S — тем, что он может прочитать и сделать на сайте. Для каждого повторяющегося вопроса сохраняем его H-состояние и формулировку, близкую к словам человека; на стороне S даём ответ в нужном шаге и точную якорную ссылку на него. Такой ответ не требует нового номера S для каждого вопроса. Для типового сообщения также указываем событие, адресата, ожидаемый ответ или действие и следующий шаг, если ответа нет. Проверяем, помогает ли такая цепочка пройти заказ без личного сопровождения; личный разговор сохраняем для переговоров и нестандартных случаев. Пока это метод разработки маршрута, а не работающая автоматическая рассылка бота.
Чтобы не исправлять один экран ценой путаницы на следующем, смотрим на изменение с пяти сторон. В нашей рабочей «архитектурной ладошке» по методам В. В. Кондратьева это чьи требования и ограничения учитываем; что система должна делать; из каких частей состоит решение; кто и какую работу выполняет; как части и люди связаны. Это пять взглядов на один заказ, а не пять очередных стадий.
Например, марка сообщила, что расчёт задерживается. Требование — понимать, кто получил исходные данные и когда ждать ответа. Функция — показать следующий шаг без раскрытия цены. Состав решения — карточка заказа, закрытый канал пары и срез дня. Работу делят марка, фабрика и куратор; связи между ними показывают, где сообщение только отправлено, где получено, а где подтверждено. Возможно, проблему решит не новая функция бота, а ясное действие человека или исправленная инструкция.
Стороны заключают договор и отвечают за заказ сами. Альянс помогает соединить людей, проверить важные для заказа ограничения и сохранить понятный след решения.
V-модель связывает это требование с проверкой. Сначала формулируем потребность сторон и критерий: что будет видно и кому. Затем меняем конкретный шаг, текст или инструмент. На обратном пути проверяем две вещи: сделали ли мы то, о чём договорились, и стало ли легче пройти реальный заказ от запроса до результата. Один удачный ответ агента или одна красивая схема ещё не доказывают, что маршрут работает для других пар.
Сначала общий принцип: спускаемся от цели к проверяемому пилоту и возвращаемся через проверки. Ниже — та же логика на одном заказе.
Слева — как от цели программы доходим до конкретной реплики и действия. Справа — как проверяем, помогло ли изменение человеку и повторяется ли результат на других заказах.
Библиотека программы и агент
У общего Свода знаний и ИИИ своя задача: давать язык и проверенные правила координации для разных программ Альянса. В 30×30 мы собираем отдельную рабочую библиотеку: путь участника, модель заказа, сопровождение, допустимые события и проверенные улучшения. Проектируемый агент должен обращаться к разрешённой версии этой библиотеки, показывать источник и предлагать следующий шаг, а не читать без ограничений чужие рабочие места или принимать коммерческое решение вместо людей. Полностью работающий бот для всех чатов и переходов пока не объявляется готовым.
Юлия ведёт маршрут участника внутри программы, Денис — процессную модель, Лана — сопровождение и ежедневный срез, Анна — агентный сценарий и обмен данными, Алексей — связь с общим Сводом и границами модуля. Опыт одного заказа сначала помогает исправить программу; повторяемое решение может обогатить Производственную сеть. В общий ИИИ переносим только отдельно проверенный принцип, который полезен и за пределами 30×30. Библиотека и агент программы остаются её рабочими инструментами, а не новыми кооперационными контурами Альянса.
Маршрут развития проверяем заказами и совместными проектами; схема не обещает, что каждый этап завершится к календарной дате.
Уже работает отдельный бот-секретарь рабочего чата на сессии Юлии: он читает новые сообщения, выделяет явные задачи и уточнения, сверяет их с существующими задачами и записывает в GitHub с пометкой об ИИ-источнике. Сомнительные сигналы он оставляет человеку на проверку. Это пока не отдельный бот-аккаунт и не агент, который ведёт марку и фабрику по заказу. В рабочей модели различаем также уведомления платформы и будущий сценарий чата пары, чтобы не приписывать одному боту возможности другого.
Следующие шаги тоже разделены: документы из чата и ежедневный срез ещё настраиваются как отдельные потоки; вопросы к участникам и публикация безопасного статуса на Альянсе требуют своих правил. Для агента 30×30 Юлия и Денис собирают один маршрут заказа с разными условиями перехода для марки и фабрики. Отметка «сообщено» не равна «получено», а «получено» не равно «подтверждено». Первый тест нужен на конкретном заказе; чтение всех рабочих чатов и автоматическое изменение карточек на сайте не объявляем действующими функциями.
Пять участников рабочей группы совместно управляют пилотом: сверяют маршрут, данные, версии схемы и решения о её применении. Права на исходные материалы и новые результаты учитываются отдельно. Работа в общей группе или доступ к файлу не превращают чужой текст, метод или код в общую собственность. ООО «Велком Медиа» ведёт действующий контур сайта Альянса; это не делает компанию правообладателем каждого вклада. Центр компетенций помогает согласовать и проверить общие правила, не забирая авторские права участников.
Участие в Альянсе не даёт члену рабочей группы доступа ко всем данным других резидентов. Работаем по правилу: доступ открываем под конкретную задачу и только к необходимым источникам. У каждого источника и результата есть владелец, назначение и режим видимости; доступ к документу не означает разрешения копировать его в общий репозиторий или публиковать.
В срезе будем указывать номер заказа или задачи, текущий этап, последнее действие, его время, ожидаемый и фактический сроки, причину ожидания, если она известна, следующий шаг и ответственного. Рядом сохраняем ссылку на источник с тем же уровнем доступа. Различаем сообщение участника, проверенный факт и вопрос, который ещё требует ответа. Сообщение «отправили расчёт» не означает, что другая сторона его получила или приняла.
Мы смотрим на время между этапами, чтобы улучшать маршрут работы, а не составлять рейтинг людей по скорости ответа. Пока нет последовательного журнала по каждому заказу, мы не называем среднюю скорость или главное узкое место доказанными.
Полные переписки, контакты, цены, расчёты, технические задания и другие закрытые материалы остаются в рабочем контуре сторон. В общий срез и проектный репозиторий их не копируем. Участники рабочей группы используют только нужные для своей задачи сведения; в общей версии оставляют безопасный факт и ссылку на источник с прежним уровнем доступа. На платформе показываем только тот статус и результат, которые можно открыть в установленном для заказа режиме. Доступ к исходнику по ссылке от этого не расширяется.
ИИ может помочь собрать срез и подсказать пропущенный шаг, но не принимает заказ, не подтверждает договорённость и не публикует закрытые сведения вместо людей. Важное изменение сохраняет источник, время и автора сообщения; спорные сведения остаются на проверке.
На ближайшем дейлике рабочей группы прочитаем этот порядок вместе, уточним ответственность и допустимые источники агента. Там же отдельно согласуем, какие задачи бот-секретарь может заносить на доску без предварительного подтверждения, а какие изменения статуса заказа и публикации требуют решения человека. До такого согласования статья описывает рабочую версию правил, а не заменяет договорённости сторон.
Если статус вашего заказа неточен или следующего шага не видно, напишите об этом в рабочем чате пары или в комментарии к карточке заказа. Закрытые условия сделки лучше обсуждать в чате сторон, а не в общем комментарии. Мы поправим запись и сохраним причину изменения.
Права на размещённые материалы определяются Офертой Альянса и режимом доступа каждого материала. Этот рабочий порядок не меняет права авторов и не открывает закрытые данные другим участникам или внешним сервисам.
