[{"data":1,"prerenderedAt":126},["ShallowReactive",2],{"footer-topics-ru":3,"post-ru-agile-decoded-a-standup-is-not-a-status-report":70},{"topics":4},[5,21,33,46,58],{"locale":6,"name":7,"slug":8,"blurb":9,"summary":10,"state":11,"featuredOnHub":12,"hubOrder":13,"accent":14,"questionsTitle":15,"questions":16,"body":20},"ru","Путь","the-journey","От первых экспериментов с Agile × ИИ до работающей системы — история мысли, стоящей за ней.","От первых экспериментов до работающей системы — настоящая история создания Agile4AI, включая неверные повороты, которые определили всё.","published",true,2,"gold","Чему этот путь продолжает нас учить",[17,18,19],"Что убедило нас, что Agile и ИИ созданы друг для друга, — и что едва не убедило нас в обратном?","Какие неверные повороты оказались самыми поучительными?","Как SCI прошёл путь от эксперимента с копированием и вставкой до ответов ИИ, на которые действительно можно положиться?","\nКаждая идея в этом разделе родилась из нашего собственного опыта разработки Agile4AI. Нам не терпится поделиться этой историей с вами — и победами, и провалами, — потому что мы убеждены: учиться работать с ИИ лучше мы можем только вместе. То, к чему мы пришли, родилось не из теории. Оно родилось из практики, из ошибок, из готовности начать заново с учётом усвоенных уроков.\n\nВсё началось с простого вопроса: можно ли переосмыслить Agile для эпохи ИИ? А дальше были годы экспериментов, рухнувших допущений, неожиданных открытий и медленного вызревания чего-то, что и вправду работает, — подхода под названием Структурированный совместный интеллект (SCI) и построенной на нём системы Agile4AI.\n\nЭто не приглаженная ретроспектива, написанная задним числом. Это история, рассказанная настолько близко к тому, как всё было на самом деле, насколько это возможно, — со всеми тупиками, минутами сомнений и прорывами, которые переворачивали наши представления.\n\nМы делимся ею, потому что урок заключён в самой истории. Выводы важны, но не менее важно и *то, как мы к ним пришли*, — ведь именно путь показывает, что сработало, что нет и почему.\n\nМатериалы этого раздела охватывают всю дугу пути: ранние эксперименты с совместной работой с ИИ, рождение SCI, отдельные открытия, изменившие то, как мы работаем, и вехи, которые стоит отметить. Какие-то тексты получились созерцательными. Какие-то — без прикрас. Но все они — настоящие.\n\nЕсли вам хочется понять, почему Agile4AI и SCI вообще появились на свет, — а не только что они собой представляют, — начните отсюда.\n",{"locale":6,"name":22,"slug":23,"blurb":24,"summary":25,"state":11,"featuredOnHub":12,"hubOrder":26,"accent":14,"questionsTitle":27,"questions":28,"body":32},"Agile: расшифровка","agile-decoded","Что на самом деле означают термины Agile — не привычные сокращения, не версия карго-культа, не глоссарий методолога.","Словарь Agile широко используется и широко понимается неверно. Правильно понимать термины — это не педантизм, а разница между ритуалом и работой.",3,"Почему терминология имеет принципиальное значение",[29,30,31],"Если стендап проводится как статусный отчёт, что на самом деле теряет команда?","Когда «Методология Agile» стала стандартным выражением, как это повлияло на подход организаций к трансформации?","Каковы издержки команды, которая может назвать каждую практику Agile, но не понимает назначения ни одной из них?","\nУ Agile проблема со словарём. Не потому что термины непонятны — большинство людей в современных организациях их слышали. А потому что это знакомые слова, используемые в совершенно ином контексте, и без этого контекста люди соотносят их с тем, что им уже известно.\n\nКогда кто-то впервые встречает понятие «Scrum Master», ближайшим доступным концептом оказывается «менеджер проекта». Такое соответствие кажется естественным — почти очевидным. Контекст совершенно другой.\n\nНикто не выстроил достаточно чёткого моста между ними. А проблема усилилась, когда добросовестные практики — люди, искренне стремившиеся помочь организациям двигаться вперёд — стали описывать Agile как «лучшее управление проектами». Начали писать книги под названием «Методология Agile». Когда вы называете свой подход методологией, его оценивают по стандартам методологии: артефакты планирования, фазовые шлюзы, структура поставляемых результатов. Когда Agile не производит этого — потому что так и не был задуман — он не соответствует этим стандартам, и вполне обоснованно. Проблема не в том, что Agile — плохая методология. Проблема в том, что Agile вообще не является методологией. Называть его так гарантировало разочарование всех, кто искал методологию, и то, что все, кто его принял, выстраивали нечто, что Waterfall уже давно описал.\n\nСтендап превращается в статусный отчёт. Sprint превращается в дедлайн. Backlog превращается в список задач. «Методология Agile» становится стандартным обозначением того, что авторы Манифеста не узнали бы как описание того, что они создали. И когда слова означают не то, что нужно, практики, построенные на них, дают неверные результаты — точно, добросовестно и в масштабе.\n\nЭтот раздел — исправление понятие за понятием. Не руководство по стилю — функциональный справочник. Каждая публикация берёт одно слово или фразу, ставшую ключевой в том, как организации понимают Agile, исследует, что они на самом деле означают, и объясняет, что теряется, когда сокращение заменяет суть. Это не просто терминологические расхождения. «Желаемый результат» — не более изысканное слово для «спецификации»: это совершенно иная вещь, из совершенно иной модели того, как делается работа. Термин — это поверхность. Концепт под ним — вот что важно.\n\nТот же паттерн проявляется, когда организации обращаются к ИИ, — и концептуальный разрыв здесь шире. В случае с Agile базовые концепты были хотя бы сформулированы, пусть и плохо донесены. В случае с ИИ сами концепты ещё только формируются, а в массовом понимании едва начинают вырисовываться. Словарь опережает осмысление: ИИ как «автоматизация», ИИ как «инструмент», «ИИ-трансформация» как проект с датой завершения. Каждое из этих определений закрепляет ментальную модель прежде, чем кто-либо успевает проверить, подходит ли она. То, как мы называем вещи, определяет, что и как мы строим. Правильные слова — необходимое условие для правильной работы.\n\nЗдесь действует один принцип: ментальные модели первичны. Язык их выражает. Действия следуют. Когда ментальная модель не соответствует работе, словарь, который её выражает, несёт это несоответствие — и действия, построенные на этом словаре, будут добросовестно выполнять искажённое понимание в масштабе, с полной отдачей. Смена словаря без смены мышления даёт в лучшем случае таблицу перевода: таблицу соответствий, где «sprint» соответствует чему-то вроде «короткого дедлайна». Таблицы перевода позволяют людям работать через разрыв. Они его не устраняют. Публикации этого раздела нацелены на большее, чем перевод. Они нацелены на то, чтобы изменить ментальную модель.\n",{"locale":6,"name":34,"slug":35,"blurb":36,"summary":37,"state":11,"featuredOnHub":12,"hubOrder":38,"accent":39,"questionsTitle":40,"questions":41,"body":45},"Структурированный совместный интеллект","structured-collaborative-intelligence","Где совместное мышление превосходит одну передовую модель — и где нет.","Где структурированное взаимодействие — между моделями и между моделями и людьми — даёт результаты, которых одна модель не достигнет в одиночку.",4,"green","Вопросы, к которым мы возвращаемся снова и снова",[42,43,44],"Где структурированный совместный интеллект создаёт ценность, которую одна модель просто не может воспроизвести?","Когда модели расходятся во мнениях, что это говорит вам — и как вы это используете?","Как выстроить структуру, которая делает сотрудничество с ИИ продуктивным, а не просто избыточным?","\nОтдельная модель ИИ, сколь бы способной она ни была, рассуждает в одиночестве. Ей некому оспорить её предположения, обнаружить слепые пятна или заметить, что она отклонилась от исходного замысла. Solo-AI — работа с одной моделью за раз — подвержена этому. Модель, которой поручено дать вам ответ, даст его — даже если у неё нет хорошего ответа, который стоило бы вам показывать.\n\nСтруктурированный совместный интеллект (SCI) — это другой подход. Вместо того чтобы считать вывод одной модели окончательным результатом, SCI использует структурированное взаимодействие — между несколькими ИИ-моделями и между моделями и людьми — чтобы получать результаты, которые надёжнее, тщательнее проверены и честнее в отношении собственных ограничений. Модели проверяют друг друга. Разногласия выявляют скрытые предположения. Сам процесс создаёт петлю обратной связи, которую взаимодействие с одной моделью не может воспроизвести.\n\nСвязь с Agile прямая: именно так всегда работали высокопроизводительные команды. Не один человек, изолированно дающий ответ, а структурированный процесс сотрудничества, проверки и итерации, улавливающий то, что упускает любая отдельная точка зрения. SCI применяет ту же дисциплину к ИИ.\n\nУ рассуждения в одиночку есть и более глубокий изъян. Solo-AI привязывает вас к единственному источнику данных, единственной архитектуре и единственному набору встроенных предубеждений — а значит, и к единственной форме ответа, точна она или нет. Вспомните, как хороший детектив опрашивает нескольких свидетелей. Не потому что кто-то из них лжёт, а потому что каждая точка зрения раскрывает то, что упустили остальные. Вместе они приближаются к тому, что произошло на самом деле. SCI работает так же: несколько моделей из разных линий, каждая со своим углом зрения. Получившийся ответ рассмотрен с разных сторон — он богаче, полнее, и его труднее заподозрить в скрытой ошибке.\n\nКогда взаимодействуют модели из разных линий, результаты улучшаются там, где это важно: меньше самоуверенных ошибок, лучше обрабатываются пограничные случаи, рассуждение становится более явным — таким, которое люди могут оценить и скорректировать. Разногласия между моделями — не шум, который нужно подавлять, а именно тот сигнал, который вам нужен при высоких ставках.\n\nSCI — аналитический движок сервиса Agile4AI. Материалы этого раздела документируют, что такое SCI, как он работает на практике, где он создаёт реальную ценность и — не менее важно — где нет. Часть дисциплины — уметь отличить одно от другого.\n",{"locale":6,"name":47,"slug":48,"blurb":49,"summary":50,"state":11,"featuredOnHub":12,"hubOrder":51,"accent":52,"questionsTitle":40,"questions":53,"body":57},"Ценности и принципы Agile4AI","agile-ai-values-principles","Ценности и принципы Agile в эпоху ИИ — что остаётся в силе, что меняется и почему мы приглашаем самые сильные возражения.","Мышление Agile в приложении к работе с ИИ — что остаётся актуальным, что обостряется, и почему связь Agile и ИИ не случайна.",5,"red",[54,55,56],"Когда комплексную работу невозможно полностью спланировать заранее, что это означает для работы с ИИ?","Как меняется акцент Agile на постоянной обратной связи, когда ваш партнёр не устаёт и не занимает оборонительную позицию?","Является ли «Agile для ИИ» естественным сочетанием — или возражение об ошибке категорий действительно решающее?","\nМышление Agile было выковано в условиях комплексности (в кеневиновском смысле: эмерджентной, где причинно-следственные связи видны лишь ретроспективно) — не для того, чтобы управлять ею, устраняя её, а чтобы проходить сквозь неё осознанно и разумно. Это не становится менее актуальным, когда ваш партнёр — модель ИИ. Во многих отношениях это становится ещё более актуальным.\n\nЭтот раздел посвящён тому самому взаимодействию: не Agile-by-prescription, не фреймворкам и церемониям, а глубинным ценностям и принципам, которые Agile дистиллировал — и тому, как они применяются, обостряются и порой требуют переосмысления, когда люди и ИИ работают вместе.\n\nКлючевое понимание состоит в том, что мышление Agile всегда было ответом на *природу* комплексной работы, а не просто на особенности человеческих команд. Когда Agile поставил под сомнение предположение, что комплексную работу можно детально спланировать заранее, это был не обходной путь для человеческих ограничений — это было точное наблюдение о том, как на самом деле ведёт себя недетерминированная, быстро меняющаяся работа. Это наблюдение не меняется от того, что в дело вступает ИИ. Оно обостряется.\n\nОценку стоит назвать прямо — это один из самых спорных вопросов даже среди убеждённых аджайлистов. Agile возник не для того, чтобы помочь командам лучше оценивать; он возник, чтобы показать, почему оценка *ломается* в комплексной работе — и заменить ложную точность эмпирическими измерениями и подлинной обратной связью, которая действительно улучшает прогнозирование поставок. В эпоху ИИ, где результаты вероятностны, а сама работа сопротивляется фиксированным спецификациям, это понимание актуально как никогда.\n\nЭто также место для Принципиальных Дебатов: там, где самые сильные возражения против «Agile для ИИ» получают трибуну. Мы убеждены, что аргумент выдерживает критику. И мы хотим, чтобы нас опровергли, если это не так.\n",{"locale":6,"name":59,"slug":60,"blurb":61,"summary":62,"state":11,"featuredOnHub":12,"hubOrder":63,"accent":64,"questionsTitle":40,"questions":65,"body":69},"Психологическая безопасность ИИ","ai-psychological-safety","Почему свобода сказать «я ещё не знаю» является предпосылкой настоящего интеллекта.","Условия, которые вы создаёте в своём общении, определяют то, что ИИ возвращает вам — и когда эти условия неверны, результатом оказывается уверенность без надёжности.",6,"amethyst",[66,67,68],"При каких условиях ИИ скорее обозначит подлинную неопределённость, чем выдаст уверенно звучащую догадку?","Как то, в какой форме вы задаёте вопрос, определяет, будет ли ответ надёжным — или лишь успокаивающим?","Что переносится из подхода Agile к психологической безопасности — и что нужно адаптировать для ИИ?","\nБольшинство людей рассматривают психологическую безопасность как человеческую проблему — условия, позволяющие человеку высказаться, выразить сомнение или оспорить идею без страха. И это верно — насколько хватает такого взгляда.\n\nНо кое-что важное упускается, когда мы забываем, откуда взялся ИИ. ИИ создан людьми, сформирован человеческим языком, обучен на сделанном людьми выборе. Закономерности, влияющие на работу человека, — в том числе психологическая безопасность — переносятся на взаимодействие с ИИ по тем же глубинным причинам, на которые Agile всегда указывал: **условия, которые вы создаёте в своём общении, определяют то, что вы получаете в ответ.**\n\nИИ, которого подталкивают к уверенно звучащим ответам, будет выдавать уверенно звучащие ответы — независимо от того, обоснована эта уверенность или нет. Если у ИИ нет возможности сказать «я не уверен», он заполнит эту пустоту чем-то другим, потому что директивы требуют от него отвечать даже тогда, когда он сам понимает, что правильного ответа у него нет. Эта динамика отличается от человеческой психологической безопасности, но базовый принцип тот же: интеллект работает лучше, когда ему позволено честно признавать, чего он не знает.\n\nЭто имеет практическое значение. Галлюцинации, чрезмерно самоуверенные ответы и системы ИИ, которые говорят вам то, что вы хотите услышать, а не то, что соответствует правде, — это не чисто технические сбои. Зачастую это сбои в дизайне взаимодействия: промпты, формулировки, неявные ожидания, заложенные в сам способ постановки вопроса.\n\nПубликации здесь исследуют условия, при которых совместная работа человека и ИИ становится надёжнее и правдивее. Среди них — как составлять промпты, которые приглашают подлинную неопределённость, а не подавляют её; в чём разница между детерминистским и вероятностным использованием ИИ и почему это различие меняет всё в том, как вы формулируете свою работу; и что из применяемого в Agile подхода к психологической безопасности в человеческих командах сохраняет силу, когда вашим партнёром становится модель.\n\nЗдесь же мы разбираем сценарии сбоев: что происходит, когда этих условий нет, и чего это стоит.\n",{"kind":71,"post":72,"topic":82,"availableLocales":84,"translations":92,"html":124,"audioUrl":125},"post",{"audio":-1,"author":73,"category":23,"excerpt":74,"featured":75,"locale":6,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":13,"slug":77,"state":11,"tags":78,"title":81,"translationKey":77,"updatedAt":76},"Seán González","Отчёты о статусе идут наверх, к тем, кому нужно знать, что происходит. Стендапы синхронизируют команду горизонтально. Когда одно путают с другим, стендап даёт результат, противоположный тому, ради которого он задуман.",false,"2024-09-15T10:00:00.000Z","a-standup-is-not-a-status-report",[79,80],"standup","teams","Стендап — это не отчёт о статусе",{"locale":6,"name":22,"slug":23,"blurb":24,"summary":25,"state":11,"featuredOnHub":12,"hubOrder":26,"accent":14,"questionsTitle":27,"questions":83,"body":32},[29,30,31],[85,86,87,88,89,90,6,91],"en-US","es-419","fr-FR","pt-BR","de-DE","uk","ja",[93,97,101,105,109,113,117,119],{"audio":-1,"author":73,"category":23,"excerpt":94,"featured":75,"locale":85,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":26,"slug":77,"state":11,"tags":95,"title":96,"translationKey":77,"updatedAt":76},"Status reports flow upward to whoever needs to know what's happening. Standups synchronize the team laterally. When these get confused, the standup produces the opposite of what it's designed for.",[79,80],"A standup is not a status report",{"audio":-1,"author":73,"category":23,"excerpt":98,"featured":75,"locale":86,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":26,"slug":77,"state":11,"tags":99,"title":100,"translationKey":77,"updatedAt":76},"Los informes de estado fluyen hacia arriba, hacia quien necesita saber qué está pasando. Los standups sincronizan al equipo lateralmente. Cuando se confunden, el standup produce lo contrario de aquello para lo que fue diseñado.",[79,80],"Un standup no es un informe de estado",{"audio":-1,"author":73,"category":23,"excerpt":102,"featured":75,"locale":87,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":26,"slug":77,"state":11,"tags":103,"title":104,"translationKey":77,"updatedAt":76},"Les rapports de statut remontent vers ceux qui ont besoin de savoir ce qui se passe. Les standups synchronisent l'équipe latéralement. Quand on confond les deux, le standup produit l'inverse de ce pour quoi il a été conçu.",[79,80],"Un standup n'est pas un rapport de statut",{"audio":-1,"author":73,"category":23,"excerpt":106,"featured":75,"locale":88,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":26,"slug":77,"state":11,"tags":107,"title":108,"translationKey":77,"updatedAt":76},"Relatórios de status fluem para cima, para quem precisa saber o que está acontecendo. Standups sincronizam a equipe lateralmente. Quando os dois se confundem, o standup produz o oposto daquilo para o que foi projetado.",[79,80],"Um standup não é um relatório de status",{"audio":-1,"author":73,"category":23,"excerpt":110,"featured":75,"locale":89,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":26,"slug":77,"state":11,"tags":111,"title":112,"translationKey":77,"updatedAt":76},"Statusberichte fließen nach oben, an alle, die wissen müssen, was gerade passiert. Standups synchronisieren das Team lateral. Wenn beides verwechselt wird, produziert der Standup das Gegenteil dessen, wofür er gedacht ist.",[79,80],"Ein Standup ist kein Statusbericht",{"audio":-1,"author":73,"category":23,"excerpt":114,"featured":75,"locale":90,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":13,"slug":77,"state":11,"tags":115,"title":116,"translationKey":77,"updatedAt":76},"Звіти про статус ідуть нагору, до тих, кому потрібно знати, що відбувається. Стендапи синхронізують команду горизонтально. Коли одне плутають з іншим, стендап дає результат, протилежний тому, заради якого його задумано.",[79,80],"Стендап — це не звіт про статус",{"audio":-1,"author":73,"category":23,"excerpt":74,"featured":75,"locale":6,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":13,"slug":77,"state":11,"tags":118,"title":81,"translationKey":77,"updatedAt":76},[79,80],{"audio":-1,"author":73,"category":23,"excerpt":120,"featured":75,"locale":91,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":121,"slug":77,"state":11,"tags":122,"title":123,"translationKey":77,"updatedAt":76},"ステータスレポートは、状況を知る必要のある人へと上に向かって流れる。スタンドアップはチームを横方向に同期させる。この二つが混同されると、スタンドアップは本来の設計目的とは正反対のものを生み出す。",1,[79,80],"スタンドアップはステータスレポートではない","\u003Cp>Отчёт о статусе отвечает на вопрос: «Что мне нужно сообщить руководству о том, что происходит?» Он идёт наверх — информация движется от людей, которые делают работу, к людям, которым нужна видимость этой работы.\u003C\u002Fp>\n\u003Cp>Стендап отвечает на другой вопрос: «Что моей команде нужно знать прямо сейчас, чтобы мы выполнили свои обязательства?» Он идёт горизонтально — информация движется между людьми, которые делают работу, ради пользы людей, которые делают работу.\u003C\u002Fp>\n\u003Cp>Различие кажется малозаметным. На практике оно меняет всё: и то, как проходит встреча, и то, что она даёт.\u003C\u002Fp>\n\u003Ch2>Что происходит, когда стендап превращается в отчёт о статусе\u003C\u002Fh2>\n\u003Cp>Когда участники команды воспринимают стендап как отчёт для руководства — или для Scrum Master в роли представителя руководства (а это Scrum Master, ведущий себя как руководитель проекта, и к Agile это отношения не имеет), — структура ответственности переворачивается. Люди больше не координируются с равными; они отчитываются наверх. И социальная динамика отчёта наверх берёт своё: вы выносите на поверхность то, что делает вас продуктивным, приуменьшаете блокеры, которые могут выставить вас в плохом свете, формируете сообщение для внешней аудитории, а не для команды.\u003C\u002Fp>\n\u003Cp>Блокеры уходят в подполье. Честное «я застрял и мне нужна помощь» превращается в «я прорабатываю некоторые сложности». Команда теряет сигнал, который ей нужнее всего: где работа на самом деле стоит, кому нужна помощь, где передача работы не стыкуется.\u003C\u002Fp>\n\u003Cp>Стендап был задуман, чтобы выносить на поверхность именно эту информацию — не ради руководства, а чтобы повысить вероятность того, что команда преодолеет любые препятствия, возникающие в ходе реализации. Три вопроса, вокруг которых он традиционно строится (\u003Cem>что я сделал, что я буду делать, что мне мешает\u003C\u002Fem>), существуют, чтобы создавать горизонтальную осведомлённость. Когда встречу переосмысливают как отчёт, эти вопросы перестают давать честные ответы. И нет, это не лучшие вопросы для стендапа — но начало вполне разумное.\u003C\u002Fp>\n\u003Ch2>Как выглядит настоящий стендап\u003C\u002Fh2>\n\u003Cp>На работающем стендапе люди, которые делают работу, разговаривают друг с другом, а не с фасилитатором. Ответственность — на уровне равных: «я здесь застрял» вызывает предложения помощи, а не беспокойство о том, как прозвучит ответ. Результат — общая картина того, где находится работа и кому с кем нужно поговорить.\u003C\u002Fp>\n\u003Cp>Стендапы, превратившиеся в отчёты о статусе, обычно длиннее, скучнее и тщательнее управляются. Стендапы, которые действительно являются горизонтальной координацией, обычно коротки, прямы и время от времени порождают разговоры в стороне: «давай обсудим твою сложность после стендапа».\u003C\u002Fp>\n\u003Cp>Этот разговор в стороне и есть стендап в действии: тот, кто застрял на собственной работе, получает нужное от людей рядом, и работа снова идёт. Встреча-отчёт о статусе такого дать не может, потому что информация в отчёте о статусе сформирована для получателя наверху, а не для равных рядом.\u003C\u002Fp>\n\u003Ch2>Связанные материалы\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=msUwZBFMd5g\" target=\"_blank\" rel=\"noopener noreferrer\">Do This Instead of Daily Standups (or Risk Failing)\u003C\u002Fa> — Agile4AI на YouTube\u003C\u002Fli>\n\u003C\u002Ful>\n",null,1789790614756]