Системный сдвиг

Знаю, что в Яндексе работает много аналитиков данных, или BI-аналитиков — тех, кто перемалывает массивы данных и извлекает из них всякие интересные инсайты.

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

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

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

Интересная мысль там была про агентов. Я сам где-то с весны работаю не в отдельных чатах, а в Cursor'е. Какие там агенты, где там агенты — ну, где-то внутри они есть, для меня это всё равно выглядит, как чат. Но! Этот чат (через агентов) имеет доступ к файлам на диске, к браузеру, к интерпретатору python или node, MCP, и может запускать разных агентов для разных задач. Если вы видели ИИ только в виде чата в браузере — попробуйте. Это вообще другой уровень. Те же презентации агентами гораздо удобнее собирать, в чате у меня ни разу нормально не получалось, а тут один агент думает над содержанием, другой пишет код, генерирующий pptx, и запускает его, третий думает про оформление, четвертый проверяет. А когда у вас есть подключенные системы и данные, всё вообще начинает выглядеть, как магия.

В том числе и для пользователей. Я помню, как давно зрела идея, что бизнес сам сможет получать нужные данные. SQL продвигали под этим соусом, конструкторы дашбордов — ничего не срабатывало, всё равно заказчику нужно было или звать разработчиков/аналитиков, или самому становиться таким разработчиком. И вот, наконец, с ИИ — вроде начало получаться. Можно сказать, чего ты хочешь, и ты получишь это. НО! Проблема в том, чтобы убедиться, что данные достоверны. Вот это сомнение важно в заказчика заложить (и ребята в видео как раз об этом говорят), а то часто все принимают на веру.

Куда в таком случае деваются аналитики, и нужны ли они? Ну, во-первых, остаются всё-таки сложные задачи (которые всё равно теперь можно делать в разы быстрее); а, во-вторых, и это даже важнее — аналитики становятся архитекторами инфраструктуры. Чтобы ИИ всё сделал, нужно ему подготовить качественные данные (и убедиться, что они качественные), описания этих данных (чтобы понял смысл) и ограничители/валидаторы (харнесс), чтобы быть уверенными, что ИИ выдал не ерунду.

И это интересное свидетельство о том, какие формы применения ИИ зарождаются в индустрии: 1) усиление себя, делегирование своих задач, получая ускорение в разы или даже десятки раз; 2) передача своих функций заказчикам, оставляя за собой построение архитектуры и контроль качества. Две разных стратегии, но в обеих получается делегирование, только разное — ИИ-агентам или своим же заказчикам. А вы посередине, как царь горы 🤩

Дальше культурно-историческая теория деятельности (в изложении Энгестрема) говорит о противоречиях — contradictions, или о напряжениях — tensions. Зачастую эти противоречия уже существуют, сложились исторически ещё до внедрения ИТ-системы, а система может их гасить или усугублять, или вводить новые напряжения.

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

Энгестрем выделяет структурно 4 уровня противоречий:

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

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

3. Противоречие между существующей системой деятельности и новой. Это когда мы пытаемся что-то менять.

4. Противоречие между смежными системами: теми, что соединены через общий результат, теми, кто пользуются результатом, кто дает вам правила, инструменты, сообщества, да и самих субъектов (привет, HR!)

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

У противоречий есть 4 проявления:
1. Дилемма
2. Конфликт
3. Критический конфликт
4. Двойное послание

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

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

Впрочем, это оптимистичный взгляд — бывает и по-плохому:
* система деятельности может застрять в бесконечных воркэраундах, а люди начнут просто сгорать из-за двойных посланий;
* сообщество может фрагментироваться и поляризоваться: все начнут обвинять друг-друга, и без способности объединиться никакого обучения происходить не будет, а будет происходить политический паралич;
* руководство (особенно бюрократическое) может начать усиливать давление: раз правила не работают, значит, их плохо соблюдают. Давайте введем больше правил и строже штрафовать! Система сваливается в раскручивающуюся петлю обратной связи
* вместо усложнения деятельности система может деградировать и вернуться к более простым, но энергетически более выгодным формам

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

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

Но сначала продолжение предыдущего поста.

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

Получился вот такой список:
💻 те, кто непосредственно работают с системой (пользователи);
🪪те, кто приводят систему в работоспособное состояние, устанавливая настройки и наполняя контентом (прикладные администраторы);
🎁те, кто получает пользу от работы системы (заказчики, клиенты);
💸те, кто выделяет ресурсы и несет риски в связи с созданием и работой системы (топ-менеджмент, инвесторы, юристы, специалисты по безопасности);
🏢те, кто будет создавать, обеспечивать работоспособность и изменять систему (разработчики, администраторы, инженеры по эксплуатации, служба поддержки пользователей);
📁те, кто обеспечивает организационные меры по созданию, запуску и развитию системы (руководитель проекта, юристы, маркетинг, отделы обучения и HR);
📲те, на кого непосредственно повлияет создание системы, как-то изменит их деятельность (сотрудники, клиенты, поставщики);
📝те, кто задает “правила игры”, обязательные требования и ограничения (регуляторы, методологи, нормировщики и т.п.);
📰те, кого почему-то заботит создание системы (медиа, общественные организации, активисты, инфлюенсеры, депутаты).

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

Для человеческой деятельности такой общепризнанной модели пока нет, но есть некоторые теории. Интересно, что теория деятельности появилась в СССР (Выготский, Леонтьев...), и это одна из признанных в мире не технических и не естественно-научных советских теорий. Впрочем, развивает её в последнее время ученый из Финляндии, и придумал уже 4 поколение этой теории (1 - Выготский, 2 - Леонтьев, 3 и 4 - Энгестрём). У Выготского речь шла об обучении человека, а у Энгестрёма — про организационный дизайн и обучение организаций/команд. Ну и про проектирование взаимодействия людей и компьютеров в очень широком смысле.

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

Пользователь уже имеет какую-то свою сложившуюся систему деятельности (с объектом и инструментами, и всеми остальными элементами), и в эту деятельность мы пытаемся вставить нашу систему. Система — это инструмент для пользователя. Меняется инструмент — начинает меняться вся система деятельности, ну или хотя бы вибрировать, как паутина, ведь всё со всем связано. Пользователю важно, чтобы инструмент был не хуже предыдущего, и результат тоже был не хуже (я уже не буду говорить, что объект должен быть тем же, иначе это другая деятельность).

И вот у нас есть пользователи и сообщества, а члены сообществ, с одной стороны, формируют нормы и правила (они могут быть разными, и правила могут иметь разную степень обязательности), а с другой — участвуют в системе разделения труда. Ещё есть производители инструментов и потребители результата деятельности.

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

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

Сел тут выписывать категории стейкхолдеров. В проекте положено делать анализ стейкхолдеров, да? Обычно его либо не делают, либо с умным видом рассказывают про "луковичную диаграмму" (и иногда даже рисуют её).

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

Йэн Александер (собственно, автор методики и книг «Writing Better Requirements» и «Discovering Requirements: How to Specify Products and Services» — кстати, не вижу, чтобы они переводились на русский, а это вам не Вигерс, это конкретное руководство про выявлению и написанию требований) предлагает следующие:

0 слой: сам продукт
1 слой: "наша" система: продукт + операторы + инструкции/правила по работе с системой
2 слой: объемлющая (содержащая) система: наша система + бенефициары нашей системы (кто получает пользу от её функционирования, но сами могут не пользоваться ей)
3 слой: широкое окружение: объемлющая система + все остальные стейкхолдеры

Раскладывает стейкхолдеров по типам так:
1 слой ("наша система"):

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

* Оператор технического обслуживания: обеспечивает и следит за работоспособностью системы. Требования: наблюдаемость (время поиска неисправности), ремонтопригодность (возможность и время на ремонт).

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

2 слой ("содержащая система"):

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

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

3 слой ("широкое окружение"):
* Негативный стейкхолдер. Тот, кто может пострадать от внедрения системы: физически, финансово или иным способом, за который вы будете отвечать перед регуляторами или судом. Требования регуляторов на самом деле — формализованные и обобщенные требования негативных стейкхолдеров (или ограничения). Александер добавляет сюда же стейкхолдеров, которые могут пытаться вредить работе продукта.

Он даже предлагает выделять специальную роль:

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

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

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

* Регулятор. Тот, кто задает правила игры — обычно в виде ограничений или навязанных функций.
* Разработчик. Есть мнение, что они вообще не должны быть в этой модели, они перпендикулярны.
* Консультант (западная практика, бывает ли в РФ?)
* Поставщик (обычно очень далекая роль, но для некоторых систем бывает крайне важен)

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

Глядя на разрастание объема требований в очередном проекте, вспомнил шутку про поправочный коэффициент π×e, на который нужно умножать число выявленных требований, чтобы получить число реальных.

Эта формула имеет геометрический смысл: R×π×e,

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

При многоступенчатом процессе согласования уже нужно брать интеграл по поверхности требований, но итоговая формула получается тоже простой: 2π×R×h×e, где h - число уровней согласования.

В среднем получается ~8.54, что очень похоже на большинство проектов.

Математики до сих пор не уверены, является ли это число иррациональным, но мы-то знаем...

Обратите внимание, что π в данном случае показывает разворот требований на 180°, то есть строго в противоположную сторону. Если ваш заказчик при согласовании требует не противоположного, а перпендикулярного первоначальной задумке, можно использовать коэффициент π/2, то есть примерно 4.27.

Правда, если заказчик движется не по окружности, а по синусоиде, придется опять вернуться к 8.54, т.к. заказчик колеблется от π/2 до -π/2, что дает полный размах безумия.

Так же в терминах управления проектами интерпретируется знаменитое равенство Эйлера:

e^iπ + 1 = 0.

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

Я часто вижу среди рекомендаций по системному анализу книгу Донеллы Медоуз "Азбука системного мышления" ('Thinking in Systems. A Primer'). Тут у меня дошли руки прочитать её.

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

Ну да, это известная проблема с одинаковыми названиями двух совершенно разных дисциплин: системного анализа и системного анализа. Первый — кусок из кибернетики/теории управления, с математическим моделированием, теорией оптимизации и принятия решений, исследованием операций и всяким таким. Второй — набор практик для выявления требований и проектирования ИТ-систем. Вот "Азбука системного мышления" из первой области. Более того — это "системное мышление" применительно к управлению социальными системами, а технические если и упоминаются, то лишь в качестве иллюстрации.

Какие тезисы внутри:
🔸 Системы состоят из элементов, связанных потоками информации. Пока вроде всё ок.
🔹Поведение системы может быть адаптивным, целеустремленным, ориентированным на самосохранение и иногда на эволюцию. Очевидно, мало какие ИТ-системы обладают такими свойствами. Скорее наоборот — сами по себе они практически не адаптивны, не ориентированы на самосохранение или эволюцию.
🔸Цель системы, как правило, не выражена явно. Всё наоборот, да?
🔹Главное в системах — запасы, то, что накапливается. Ну, в каком-то смысле можно рассматривать накопление информации, но тут есть ловушка: обычно в ИТ-системах накапливается информация, но только эта "информация" обычно не имеет смысла для системы: система никак не меняется под действием этой информации. Это отличается от понятия "информация" из физики, где поступление медленнее, чем изменение объемов входящих и исходящих потоков. То есть, у системы есть инерция, и она меняется под внешним воздействием не так быстро, как мы ожидаем. Это с одной стороны может демпфировать резкие скачки потока, не давая системе сломаться, с другой — затягивает требуемые изменения. Даже не знаю, как это применить к ИТ-системам, разве что к проектированию нагрузки и эластичности.
🔹Наличие запасов позволяет исходящим потокам не зависеть от входящих.
🔸Система управляет собой через обратные связи. Но в ИТ-системах ничего подобного нет! Они не эволюционируют сами по себе, не содержат петель обратной связи и у них нет запаздывания реакции.

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

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

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

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

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

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

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

Так нам говорит теория соц.исследований. UX-исследования, в сущности, специальная область применения таких исследований. Мне стало интересно — есть ли в UX исследования провокацией? И, представьте себе, есть! Даже термин для этого есть: provotype (provocation + prototype, провокационный прототип).

Это как бы доказательство от противного: что для пользователей действительно важно, а с чем они готовы мириться (а может быть, радикальные изменения, на которые никто не мог решиться, наоборот будут удобны!)

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

В одной статье описан провотип, который был сделан, как хоумпейдж из 90-х: с Comic-sans, желто-розовый и с gif-анимациями. Это был прототип сайта налоговой службы. В обсуждении быстро стало понятно, что именно тут кажется неуместным заказчикам и пользователям. Это ещё один принцип: не спрашивайте, что нужно и что удобно, спрашивайте — что мешает. В таких вариантах провотипа используется явно неуместный объект, не отсюда. Иногда присутствие такого объекта заставляет задуматься, а так ли он неуместен?

Ещё один вариант: против правил. "У нас всегда...", "Система не позволяет...", "Пользователь привык, что...". А что если нет? Что если мы подвергнем сомнению этот принцип, и сделаем наоборот?

Близко к этому примыкает тонкий прием, когда в прототипе что-то заведомо неправильно. Например, одна и та же информация представлена в двух вариантах, без какого-то объяснения. Исследователь фиксирует — а заметил ли вообще это пользователь, и какой вариант лучше? Возможно, информация неконститентна (и это специально). Многие дизайнеры вообще не следят за консистентностью, и иногда это можно обратить на пользу. Например, однажды дизайнер нарисовал интерфейс, в котором у ученика 6-го класса были выведены результаты ЕГЭ. Ух, мы много новых требований вытащили из этого прототипа!

За летними делами пропустил историческую новость: в протокол HTTP добавили новый метод! Не каждый день бывает.

Добавление свежее, июньское, RFC 10008. Статус у него — Proposed Standard, но с таким статусом множество технологий живет, это значит — в целом норм, можете уже реализовывать в своих системах. В Nginx новый метод уже поддерживается. Называется этот метод QUERY. используется он примерно так:

QUERY /products/search HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded
Accept: application/json
q=distributed+systems&category=books&min_year=2025&sort=relevance

То есть, это фактически официальный GET с телом.

Проблема была в чем: если вы хотите найти что-то по сложному условию и множеству параметров, можно использовать GET, но параметры поиска можно передать только в строке запроса. Тела запросам GET не положено — его можно передать, но сервер или любой промежуточный узел может это тело проигнорировать и дальше не передавать. Строка запроса обычно ограничена по длине, есть даже специальный код ответа 414 URI Too Long.

GET безопасный, идемпотентный и кэшируемый.

POST небезопасный, неидемпотентный и не кэшируется. Зато у него может быть тело большого размера.

QUERY объединяет самое лучшее: он идемпотентный, безопасный, может кэшироваться и содержать тело. Заодно не оставляет следов в логах (что там было в теле — не видно). Так что если ваши запросы были слишком специфичны — теперь для них есть специальный механизм.

В каком именно формате вы будете передавать запрос в теле, стандарт не задает, но требует, чтобы вы явно указали это в заголовке Content-Type.

Там есть всякое интересное:
application/x-www-form-urlencoded — это строка запроса из URL
application/sql — SQL-запрос (вот так, прямо через REST API)
application/jsonpath — для вытаскивания специфических данных из JSON
application/xslt+xml — то же для XML
application/graphql — запрос в формате GraphQL
application/sparql-query — запрос в формате SPARQL
и т.д.

Можно спросить у сервера, в каких форматах он готов принимать запросы (он ответит в заголовке Accept-Query).

Можно ещё добавить Accept, то есть, например, в одном эндпоинте передавать простые запросы через строку, а для сложных переходить на SQL (теоретически), и получать ответ либо в JSON, либо в CSV (если сервер умеет). Всякую интересную логику можно реализовать.

Начинают играть коды ответов, про которые никто и не помнил:
415 Unsupported Media Type — сервер не поддерживает этот формат запроса к этому ресурсу
422 Unprocessable Content — сервер поддерживает этот формат, синтаксис запроса валидный, но выполнить его невозможно (например, нет такой таблицы, к которой обращается SQL)
406 Not Acceptable — клиент запросил ответ в таком формате, который не поддерживается сервером.

Сервер может даже создать новый ресурс, содержащий результат выполнения запроса! Как явный кэш, или как снэпшот на определенное время. Вернуть ссылку на него клиенту в заголовке Content-Location, а дальше к нему уже можно делать обычный GET. Сам QUERY при этом остается безопасным — новых ресурсов при повторных вызовах создаваться не будет.

Вот такая штука. Слышали уже? Планируете использовать?

В одном из обсуждений поста про ритуалы и дейлики возникла тема про доверие. Человек отреагировал очень резко: синхронизация под запись в чате?! Да никогда! Это же всё сохранится и может быть заскринено и использовано!

Я, честно говоря, даже немного опешил. За 28 лет я с такой культурой встречался, пожалуй, только раз — в одном государственном проекте, где всегда нужно было думать, что и кому ты говоришь, взвешивать слова и понимать, кому твои слова будут переданы и в каком виде, и как будут использованы (скорее всего, с целью навредить). Долго я там работать не смог, естественно. Вообще не представляю, как работать в среде с низким уровнем доверия.

Тренеры по лидерству тут любят вспоминать Патрика Ленсиони и его книгу "5 пороков команды" (дисфункций), где он описывает пирамиду "пороков": отсутствие доверия ➜ боязнь конфликтов ➜ необязательность ➜ избегание ответственности ➜ безразличие к результатам.

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

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

Источники конфликтов тоже разнообразны:
- проблемы в коммуникации (слишком редкая, слишком нерегулярная, перегружающая, неправильно выбранный канал / время / форма / тон, недостаточно контекста, недостаточно прямая);
- неверный выбор основы власти или стиль управления (принуждение или стимулирование, нечеткие границы и двусмысленные требования);
- культура организации (поощрение личной конкуренции, а не кооперации)
- недостаток координации, знаний и сплоченности (члены команды не понимают, зачем они работают, и изолированы друг от друга)

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

Факторы внешнего давления:
1. Проекты с высоким риском / ставками
2. Двусмысленные, плохо разграниченные роли и области ответственности
3. Несколько начальников с противоречивыми требованиями
4. Использование сложных технологий с запутанными связями
5. Нереалистичные сроки
6. Недостаток ресурсов
7. Недостаточное финансирование
8. Некомпетентное руководство

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

Знаете, что меня больше всего бесит в процессах "типа agile"? Неприкрытый формализм. Особенно ярко это проявляется в регулярных событиях, которые предписывает, например, Scrum (в Kanban они тоже есть). Подавляющее большинство людей вообще не понимают их смысла.

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

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

События в Scrum не зря называются "церемониями" или "ритуалами" (хотя в Scrum Guide они нзываются просто "событиями", но Майк Кон в выступлениях их называл "церемониями"). Сам термин "церемония" применительно к регулярным встречам появляется ещё у Алистера Коберна (да, того самого, который написал Effective Use Cases) в Crystal Methods в 1990. И они вообще не про для того, чтобы узнать, кто над какой задачей работает или спланировать, что мы берем в следующий спринт.

То есть, и для этого тоже, но в первую очередь для другого. Ритуалы нужны (и спонтанно возникают) в сплоченных командах. Собственно, команд без ритуалов не бывает, также как без внутренних мемов и собственного языка, понятного только членам команды. Поэтому основная цель церемоний в Agile — это синхронизация сплочение команды. Не напоминание о задачах, а напоминание, кто мы такие и зачем мы тут собрались. Не контроль текущих работ, а рост уверенности в том, что о проблемах можно говорить открыто, доверие и вовлеченность всё ещё с нами, и тебе помогут, если что-то не получается. В конце концов, напоминание от том, что для нас важно и как мы тут вообще работаем, по каким принципам.

Строго говоря, все ритуалы направлены на изменение человека. Они для этого и нужны. После ритуала человек чувствует общность, принадлежность, спокойствие, сосредоточенность, поддержку, облегчение, снижение тревожности и повышение уверенности, гордость за свою работу — в общем, разные позитивные чувства. Причем это же регулярная практика, значит, чувствует он их регулярно, что позволяет как-то дальше протянуть в этом сложном мире. Если вы — ну, вдруг — проектируете процессы разработки, обратите внимание на ритуалы, и задайте себе вопрос: каким человек приходит на этот ритуал и каким уходит? Что в нем должно поменяться? А если у вас в результате встречи меняются не люди, а статусы задач в бэклоге, кажется, вы что-то упустили.

Задачи и так как-нибудь сделаются, а вот атмосфера в команде сама склонна скатываться куда-то не туда, особенно под давлением. И чтобы её выправить, нужно предпринять усилия, вкачать в систему энергию.

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

Короче, вот вам хороший диагностический признак — чувствуете ли вы подъем после ежедневного / еженедельного ритуала, или опустошение? Вот и ответ — agile у вас или что-то совсем иное.

Каждый раз, когда приходится стартовать проект с нуля, не перестаю удивляться количеству вещей, про которые нужно подумать и принять решение. В первый раз, помню, поразился, когда понял, что разные виды обеспечения из ГОСТ 34.602 — это не "вода", как многие считают, а реально нужные и полезные разделы. Например, правовое обеспечение системы, или лингвистическое (за казенными формулировками не всегда понятно, что "лингвистическое обеспечение" — это, в том числе, тот самый ubiquitous language из DDD, а вовсе не "подписи в интерфейсе системы должны быть выполнены на русском языке").

Второй раз я был шокирован, когда понял, что у меня в проекте разворачиваются все 43 процесса из ISO 12207, и все их мне нужно контролировать! Все вот эти процессы приобретения, поставки, менеджмента решений, и даже менеджмента повторного применения активов! Ну, я-то, как нормальный программист, читал только группу технических процессов (11 штук) и группу процессов реализации программных средств (7), а вот эту всю управленческую лабуду...

И вот опять понадобилось выписать набор вопросов, по которым нужно принять решение и зафиксировать его:
1. Что нужно сделать? Какую возможность эксплуатируем / проблему решаем, почему сейчас, почему разработка программ поможет, какие есть ограничения? (первоначальное ТЗ)
2. О чем вообще мы говорим? (Глоссарий)
3. Что происходит? (Верхнеуровневая схема процесса, перечисление основных шагов)
4. Кому это нужно и зачем? (Реестр стейкхолдеров, их интересов и уровня влияния)
5. Как мы организуем работу? (Модель SDLC, подход к управлению задачами и релизами, выбор технических решений по ведению списка задач, хранению знаний проекта, фиксации решений, коммуникации. То есть, буквально: работаем недельными спринтами, релиз в конце каждого спринта, задачи записываем в Jira в виде юзер-сторей, а потом бьем на задачи для фронта и бэка, исходники храним в Gitlab, еженедельно созваниваемся по следующим вопросам, текущая переписка в таком-то мессенджере)
6. Как мы принимаем решения? (Регламент по приему различных решений: бизнесовых, организационных, по ахитектуре и функциям системы)
7. Что нужно сделать? (Описание функций системы)
8. Как это должно работать и изменяться? (Нефункциональные требования и характеристики)
9. Что из готового мы можем использовать / купить? (Политика использования готовых компонентов и сервисов)
10. С чем нам нужно будет интегрироваться или обмениваться данными? (Внешнее окружение)
11. Как это будет выглядеть снаружи? (Функциональная архитектура)
12. Как это будет устроено внутри? (Техническая архитектура)
13. Как мы это будем развертывать и обновлять? (Описание процессов развертывания)
14. Как мы будем предъявлять результаты работы?
15. Как мы докажем, что сделали то, что нужно и хорошо? (ПМИ в каком-то виде)

15 пунктов, я уже устал писать, а мы ведь не коснулись основного содержания работы аналитика — все эти спецификации требований, данных, экранов, API — и очень далеки от программирования. Каждый из пунктов раскрывается глубже и глубже: ок, мы выбрали, как будем фиксировать задачи, а какие поля должны быть у каждой записи о задаче? Какая у неё статусная модель? Какие условия переходов между статусами и кто должен быть информирован о них?.. Фактически, речь идёт о проработке требований к нескольким обеспечивающим системам. Да, скорее всего мы не будем их самостоятельно разрабатывать, но требования (решения) в их отношении мы должны принять. Хорошо тем, у кого эти решения уже приняты раз и навсегда, и новый проект стартует по готовым шаблонам. Но и проекты бывают разные — они же уникальные, и что подходит для одного проекта, может быть неудобным в другом. Начинай с начала!

А так как это решения, здесь должен быть выбор — ну хотя бы из двух вариантов (а в реальности их обычно больше). И каждый выбор должен быть обоснован — почему выбрали это решение и отвергли альтернативы? Если написать хотя бы 2-7 страниц по каждому пункту, это уже документ под сотню листов! А мы ещё не начали толком ничего делать. И работа по проработке требований к обеспечивающим системам проекта обычно остается невидимой.

Интересно, что конфликты с точки зрения цветов выглядят по-разному:

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

Черный-зеленый: прагматизм против расточительства или сохранение против эксплуатации (угадайте, где чья перспектива)

Зеленый-синий: равновесие против дестабилизации или совершенствование против самодовольства.

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

Красный-белый: свобода против ограничений или хаос против порядка.


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

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

Кроме конфликтов возможны и союзы, причем считается, что смежные цвета имеют что-то общее:

Белый и синий соглашаются, что миру нужен какой-план или проект. (Красные с этим не согласны!)

Синий и черный оба имеют growth mindset — идею, что в мире нет предзаданных ограничений для личности. Возможно всё. Что успешно доказывают капитаны Силиконовой долины, выпускники PayPal. (Понятно, что белые активно этому противостоят!)

Черный и красный сходятся на идее независимости. (Что явно не встречает понимания у белых и зеленых)

Красный и зеленый находят общее в идее подлинности, аутентичности. (Белые не поддерживают, а синие не понимают)

Зеленый и белый объединяются на базе сообщества, коммьюнити. (Черные смотрят с презрением)


Но есть связи и в противоположностях:

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

Красный+синий: безумный (или гениальный) изобретатель с фонтаном идей.

Черный+зеленый: тут можно вспомнить марвеловский сериал про ведьм: самая сильная ведьма природы — это сама Смерть (осторожно, спойлер).

Красный+белый: архетип бесстрашного героя (зачастую считающего, что он-то сам стоит выше закона).

Синий+зеленый: это про мудрость и поиск истины, но основанной на балансе.


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

У меня, кстати, когда я активно играл, базовая колода была красно-синяя: это, наверное, что-то обо мне говорит :))

Тема MtG не отпускает. Особенно в связи с разговорами про этику и т.п. Вот смотрите: в Magic the Gathering пять цветов: белый, синий, черный, красный, зеленый. Каждый цвет исповедует свои ценности и связан со своей стихией. Ричард Гарфилд, создатель MtG, вообще-то профессор математики, а не психологии. Но колесо цветов, или color pie он считает одной из главных фишек игры.

Впрочем, он решал практическую задачу — сделать так, чтобы нельзя было собрать в одну колоду самые сильные карты в игре. В основе MtG всегда про баланс, и цвета тоже введены для балансировки сил: самые мощные карты невозможно собрать в одной колоде, потому что они разных цветов и для их вызова нужна разная мана (а собрать все источники маны не получится). А ещё у цветов есть базовые конфликты, вокруг которых тоже развивается игра. И всё это дает повод примерить базовые ценности цветов на себя и на коллег, если мы говорим об организации. А что, ничем не хуже других способов анализа personal traits, черт личности. Не основано на научных исследованиях, так большинство таких классификаций на них не основаны. Зато не содержат иерархии, нет такого, что один цвет лучше или является развитием другого, как в спиральной динамике. А вообще, первым цветовую дифференциацию предложил ещё Гёте в 1810 году!

Каждый цвет имеет свою цель и свою базовую стратегию. Вот смотрите:

⚪️Белый: мир через порядок. В игре это всякие рыцари, ангелы, священники, и вообще идеал белых — церковный орден. Поэтому там много механик с лояльностью, духовной защитой, и вообще разными плюшками для тех, кто принял нашу веру. Поэтому главный вопрос белых: как будет правильно? Причем это "правильно" = "в соответствии с законами и нормами". Соответственно, главное зло для белых — нарушение законов и установленных принципов, а зло поменьше — разнообразная двусмысленность, тонкие нюансы и амбивалентность.

🔵Синий: совершенство через знание. Идеальная организация: университет или лаборатория. Типаж, соответственно — ученый / изобретатель, перфекционист. Главный вопрос — что имеет смысл? Где "смысл" = "как мы можем применить свои знания и достичь идеального результата. Ну и попутно решить побольше загадок и поразить всех своим интеллектом.

⚫️Черный: удовлетворение через безжалостность. Мы хотим власти и ни перед чем не остановимся. Главный вопрос: что будет лучше для меня? Если при этом кто-то погибнет, не важно — если нужно, поднимем и из кладбища. Это я уже про игру. Причем это никак не связано с добром или злом, для черных вопроса морали в принципе не существует. Они не противостоят добру, они его игнорируют. Черная организация — банда или стартап с сильными основателями.

🔴Красный: свобода через действие. Красных организаций не существует. Девиз: сначала делаем, потом думаем. Или вообще не думаем, а следуем своим ощущениям. Собственно, главный вопрос: что мне подсказывают чувства?

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

Вот такие архетипы. В ИТ, насколько я вижу, большинство персонажей исповедуют либо синие, либо черные ценности. Метафора продолжается — ведь колоды могут быть многоцветными! Считается, что соседние цвета могут легче объединяться, а с противоположными у них конфликт. Типичный программист из анекдотов — явно сине-черный персонаж. А "бирюзовые организации" — это сине-зелено-белая колода.

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

(она же на гите: https://github.com/kulakov/statement)

Краткий список тезисов:
1. Все выводы делай сам.
2. Посылай людям только то, что написал сам.
3. Явно помечай места в черновике от ИИ, где сомневаешься.
4. Не выдавай работу ИИ за свою.
5. Не ссылайся на ИИ как на авторитет.
6. Складывай контекст в git и делай его пригодным к использованию.
7. В каждый момент держи связь того, что делаешь, с целью.
8. Исследование начинается с выбора источников.
9. Нет критерия качества — нет пользы от ИИ.

Дальше — подробнее каждый из тезисов.

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

Оно же «не превращай hadi-цикл в hahaha-цикл» © Харитонов.

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

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

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

Проще всего — прямо в тексте, комментарием:

Выручка вырастет на 40% за квартал. // не уверен: цифра из ответа ИИ, первоисточник не проверял

Так читающий сразу видит, где ты ручаешься, а где нет.

4. Не выдавай работу ИИ за свою
Помечай: что сделал ты сам, а что — искусственный интеллект. Признаваться, что что-то сделал ИИ, — нормально, стыдиться нечего. А вот врать про это — убивает доверие.

5. Не ссылайся на ИИ как на авторитет
Ни при каких раскладах нельзя говорить «искусственный интеллект сказал вот это» как аргумент в пользу какой-то позиции. Мы пользуемся заёмной эрудицией машины, но ссылаться на выводы LLM как на аргумент нельзя — это профессионально некомпетентно. «Так сказал ИИ» — лучший способ посеять сомнение в твоей компетентности и обесценить всю работу.

6. Складывай контекст в git и делай его пригодным к использованию
Складывай в git команды рабочий контекст проекта — источники, промежуточные материалы, продукты ИИ, решения. Чтобы контекстом реально могли воспользоваться, нужно организовать минимум: поиск, удобный интерфейс к базе знаний, бот, который помогает взаимодействовать с базой знаний команды.

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

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

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

P.S. В создании этого текста я пользовался Клодом, чтобы отредактировать несколько транскриптов и превратить их в черновик. Но каждая мысль здесь — моя, и финальный текст написан руками.

Леша Кулаков делится инструкцией по, как бы это сказать... этичному?.. безопасному?.. применению ИИ, если речь идет о документах. (Не уверен, что подойдет, если речь идет о коде, код генерируется со страшной скоростью и большими объемы, но его проще проверять более формальными методами — тестами, линтерами, правилами проверки архитектуры и т.п.)

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

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

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

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

Ну и эти Лешины тезисы в целом про это: принимали ли вы какие-то решения? Согласны ли с решениям, изложенными в тексте? Доступны ли принятые решения команде?

Раз уж мы заговорили об играх: вот игра, одна из самых сложных из всех, в которые реально играют люди. Это MtG, Magic the Gathering. Выглядит как карточная игра, где каждый игрок использует свою колоду, вызывает себе на игровое поле существ, разыгрывает заклинания и накладывает чары. Цель — победить противника тем или иным способом, например — отняв жизни, которых изначально по 20.

Внутри возникает комбинаторный взрыв: с 1993 года выпущено более 30 тысяч уникальных карт, колода состоит из 60 карт, каждая карта может повторяться в колоде только 4 раза — то есть, возникает огромное чиcло вариантов колод (для зануд — в играх по правилам Standard легальны примерно 4400 карт, в Legacy — 31465). 189 свойств карт, для которых есть специальное название, а отдельные карты могут иметь свои уникальные механики, которые как-то модифицируют игру. Поэтому практически про каждое правило нужно говорить "обычно, если только какая-нибудь карта не меняет это". Всего разных механик больше 300. Полная книга правил содержит 905 разделов, каждый из нескольких пунктов и подпунктов (для сравнения, в футболе всего 17 правил). Ход состоит из 11 шагов (обычно), при этом, например, раздел правил, описывающий, как брать карту из колоды (самый простой шаг) — это 17 отдельных пунктов.

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

При этом она обладает отличной играбельностью и её можно объяснить 8-летнему ребенку (мы регулярно дуемся с детьми — не на турнирном уровне, конечно, а так — на уровне "кухонной магии").

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

Дальше — больше. Что является вашим ресурсом, за счет чего вы развиваетесь? В первом приближении в MtG это мана, которая берется из земель. Чем больше земель вы контролируете, тем больше получаете маны. Но если посмотреть пристальнее — ресурсом может быть всё, что угодно: ваша колода, карты в вашей руке, ваши жизни (у вас их 20 — можно и потратить), и даже отыгранные карты на кладбище. Дети обычно больше всего ценят очевидное — жизни, и боятся их тратить. Но смысл игры — не сохранить жизни, а чтобы противник потратил жизни быстрее вас. А свои, глядишь, и восстановить можно. Даже если сначала страшно тратить именно жизни. Какие ресурсы у нас есть в проектах, которые очень страшно тратить, но это всего лишь ресурс?

То же касается и вектора атаки. Я бы вообще MtG давал на курсах по безопасности изучать. Очевидной идеей кажется — атаковать игрока и его жизни. Но есть и другие поверхности атаки: можно атаковать земли — источники маны. Можно атаковать руку игрока — вот есть у тебя мана, но нет вариантов её потратить, нет карт в руке. Можно атаковать колоду, понемногу сбрасывая её сразу на кладбище. Кладбище тоже можно атаковать! Ещё можно "атаковать" заклинания противника или саму возможность вызывать существ и заклинания. Или радикально повышать их стоимость для игроков, замедлять игру, "атаковать" темп. Можно раскрывать информацию: смотреть на руку и колоду игрока. Атаковать можно и саму структуру хода, отменяя отдельные шаги.

За счет чего можно выигрывать, что атаковать в проектах по созданию софта? Там тоже есть ритм и шаги, мана, колода (потенциальные ресурсы) и рука (наличные ресурсы) и даже кладбище -- отработанные эксперименты.

А сборка колоды (метагейм) очень похожа на подбор команды и выбор технологий.

Невозможно не реагировать на мировые новости и повестку. Вот, например, футбол. Я вообще не фанат, но чемпионат мира можно и посмотреть!

И, конечно, извлечь для себя что-то полезное. Во-первых, можно смотреть на тактику разных команд. Кто как строит игру, у кого есть звезды, у кого вся команда более-менее ровная; как распределяются роли; насколько команда способна адаптироваться; кто как работает с риском; кто использует постоянно одни и те же схемы, а кто импровизирует по ситуации — всё наглядно видно. Можно интересные выводы сделать для себя. Исследования работы в группе же в основном из спорта пришли. И даже роль такую придумали: Agile Coach, то есть тренер. По идее, он должен всеми этими интересными вещами заниматься, а занимается обычно внедрением ритуалов. Эти задачи традиционно падают на менеджера или тимлида, получается "играющий тренер" — практика, от которой в спорте давно отошли, слишком высокая нагрузка. А про играющих менеджеров команд я и не слышал никогда. Да и тренер не совмещает роль с менеджером. В ИТ такое в порядке вещей, что немного странно, если подумать.

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

Но отдельная история, которая меня поразила именно в этом чемпионате, я раньше о ней не слышал — это причуды статистики, или "Top-right Messi". Оказывается, если строить разные статистические графики, на них неизменно далеко справа или справа-вверху (если график двумерный) оказывается Лионель Месси, капитан сборной Аргентины, чемпион и рекордсмен всего на свете, и — думаю, вполне заслуженно — считающийся лучшим футболистом за всю историю.

Так вот, чтобы вы понимали — если построить график, например, распределения участия в голах за 90 минут матчей всех нападающих топ-5 футбольных лиг, Месси оказывается справа на расстоянии почти 6 среднеквадратичных отклонений от среднего.

Возможно, вы слышали про метод Six Sigma. Вот эти сигмы — это и есть среднеквдратичные отклонения. А "6 сигм" означают, что качество вашей продукции настолько высокое, что брак практически не встречается. В диапазон 3 сигм попадает 99,73% всех величин. 6 сигм — это 99,9999998% вероятность. С точки зрения обеспечения качества, превышение — 0,0000002% — почти незначимая величина, 2 на миллиард (где вы возьмете 500 тысяч топовых нападающих?..)

С точки зрения реальности — вот она, бегает по полю, эта величина, можем посмотреть своими глазами.

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

Но многие процессы устроены иначе — они не складываются, а перемножаются, и обычно имеют разную природу. Это описывается словом "одновременно": в Месси одновременно сошлось множество маловероятных факторов (дефицит гормона роста в детстве, отличное пространственное мышление, бабушка заморочилась водить внука в футбольную школу в детстве и т.д. Ну и талант, конечно!). Каждый фактор может иметь не очень-то низкую вероятность, а вот сочетание 3-4-5 факторов легко дает те самые доли процента. Одно цепляется за другое, а не просто тасуется. В итоге получается не нормальное, а логнормальное или степенное распределение, которое математически сложно обсчитывать — например, у него во многих случаях нет среднего и конечной дисперсии, и на нем нельзя считать регрессию. А так хочется упростить! Но мир устроен сложнее.

Удивительно, но я оказывается не писал здесь про 6D's фреймворк: 6 'Ds' цифровизации. То есть, что нам цифровизация вообще дает? Это аналитический фреймворк Питера Диамандиса, показывающий, что происходит с вещами и процессами при цифровизации. Если мы говорим не просто об автоматизации какой-то деятельности, а о её цифровизации, по фреймворку можно проследить — что будет происходить дальше, если мы в какой-то процесс пустили цифру.

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

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

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

Следующий эффект — обманчивость, deceptive. Точнее — обманчивая слабость. В начале цифровая технология всегда выглядит хуже альтернатив. Это всё ерунда какая-то, цифровые печать/фотография/журналистика/кино/учителя никогда не смогут заменить настоящих! Вспомните, как все смеялись над первыми произведениями генеративного ИИ. Экспоненциальный рост в начале выглядит сильно хуже линейного.

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

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

Эти 6 эффектов прослеживаются во многих случаях, и если мы говорим не об автоматизации, а о цифровизации — по ним можно отслеживать её эффект. Что исчезнет физически из мира? Что теперь могут делать ваши сотрудники и пользователи, что раньше было слишком дорого / недоступно / непредставимо? За что вы перестали платить? Какой отдел или какая роль больше не нужны? (были подорваны). Если ясных ответов на это нет, то это не цифровизация по сути, а некие ритуальные действия, возможно чисто демонстративные, как хвост у павлина.