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

Глядя на разрастание объема требований в очередном проекте, вспомнил шутку про поправочный коэффициент π×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'). Тут у меня дошли руки прочитать её. И вот что я вам скажу — те, кто её рекомендует, либо сами не читали, либо ничего не поняли. Потому что главный вывод, который можно сделать после прочтения — то, что мы называем системами в ИТ, на самом деле системами не является. Или является ими не в том смысле, в каком их понимают ученые, занимающиеся системным анализом. Ну да, это известная проблема с одинаковыми названиями двух совершенно разных дисциплин: системного анализа и системного анализа. Первый — кусок из кибернетики/теории управления, с математическим моделированием, теорией оптимизации и принятия решений, исследованием операций и всяким таким. Второй — набор практик для выявления требований и проектирования ИТ-систем. Вот "Азбука системного мышления" из первой области. Более того — это "системное мышление" применительно к управлению социальными системами, а технические если и упоминаются, то лишь в качестве иллюстрации. Какие тезисы внутри: 🔸 Системы состоят из элементов, связанных потоками информации. Пока вроде всё ок. 🔹Поведение системы может быть адаптивным, целеустремленным, ориентированным на самосохранение и иногда на эволюцию. Очевидно, мало какие ИТ-системы обладают такими свойствами. Скорее наоборот — сами по себе они практически не адаптивны, не ориентированы на самосохранение или эволюцию. 🔸Цель системы, как правило, не выражена явно. Всё наоборот, да? 🔹Главное в системах — запасы, то, что накапливается. Ну, в каком-то смысле можно рассматривать накопление информации, но тут есть ловушка: обычно в ИТ-системах накапливается информация, но только эта "информация" обычно не имеет смысла для системы: система никак не меняется под действием этой информации. Это отличается от понятия "информация" из физики, где поступление медленнее, чем изменение объемов входящих и исходящих потоков. То есть, у системы есть инерция, и она меняется под внешним воздействием не так быстро, как мы ожидаем. Это с одной стороны может демпфировать резкие скачки потока, не давая системе сломаться, с другой — затягивает требуемые изменения. Даже не знаю, как это применить к ИТ-системам, разве что к проектированию нагрузки и эластичности. 🔹Наличие запасов позволяет исходящим потокам не зависеть от входящих. 🔸Система управляет собой через обратные связи. Но в ИТ-системах ничего подобного нет! Они не эволюционируют сами по себе, не содержат петель обратной связи и у них нет запаздывания реакции. Собственно, дальше вся книга посвящена типам циклов обратной связи (положительному, отрицательному, стабилизирующему), числу этих циклов и их направлениям, времени запаздывания реакции, нелинейность характеристик системы при изменении потоков, накоплению изменений и резкой (катастрофической) перестройке системы, выбору точкам воздействия на системы. В общем, это всё очень интересно с точки зрения внедрения изменений в организациях и обществе, но к ИТ-системам имеет отдаленное отношение. Для ИТ-систем это всё начинает работать, только если мы включаем в рассмотрение команду поддержки и разработки системы — тех, кто как раз получает обратную связь о работе системы и может её менять. Если рассмотреть всё вместе: ИТ-систему, технические средства и команду разработки, а ещё лучше — управленческую и политическую обвязку — то принципы Медоуз начнут работать. Именно в управленческом или лидерском аспекте. Может быть также полезно посмотреть с этих позиций, если вас интересует — как изменится деятельность организации после внедрения какой-нибудь системы. Это уже для правильных бизнес-аналитиков и продактов. А для задач сбора требований и проектирования программных систем книга практически ничего не дает.

Disaster Recovery и Backup решают разные задачи, но их часто путают 😕 Backup сохраняет и восстанавливает данные, а DR — работоспособность всей инфраструктуры. 18 августа на вебинаре эксперты Cloud․ru расскажут, как выбрать стратегию восстановления с учетом требований бизнеса, RPO и RTO. В программе:

▶️что происходит при отказе ЦОД и чем это грозит бизнесу ▶️когда нужны Evolution Disaster Recovery и Evolution Agent Backup ▶️как соотносятся DRaaS, BaaS, репликация и аварийное восстановление ▶️как выбрать решение под ваши требования

Бонусом в парктической части покажут возможности Evolution Disaster Recovery и Evolution Agent Backup на реальных сценариях. Не забудьте зарегистрироваться

Вы используете прототипы интерфейсов? Наверняка используете. Для согласования, например. И чтобы вообще было, что обсуждать. Читать тексты человеку очень сложно, а уж представить себе по тексту, как это будет выглядеть, вообще мало кто может. А если и представит — совершенно не факт, что два человека представят одинаково. Поэтому прототипы часто используются в качестве стимульного материала: чтобы хотя бы начать или предметно продолжить разговор. Нужна визуализация, а ещё лучше — исследование действием. Дайте предмет, поставьте задачу и пусть пользователи попробуют решить эту задачу при помощи этого предмета. А мы увидим, с какими проблемами они сталкиваются. Поэтому, кстати, "просто показать прототип" не работает — нет задачи и нет попытки её решить. В лучшем случае вы получите набор случайных замечаний, часть из которых будет нерелевантна, при этом многие важные вещи будут пропущены. Демонстрацию интерфейсов лучше всего проводить по сценарию и с использованием реальных данных. Ещё лучше, если это будет не демонстрация, а задание: вы не показываете, вы смотрите, как пользователь пытается взаимодействовать с интерфейсом. Но это уже известный метод социологических исследований! И известно даже его развитие — исследование провокацией. Когда вы не просто предлагаете респонденту осуществить какую-то деятельность, а ставите его в некомфортную ситуацию, нарушающую некоторые правила. Так можно проявить базовые установки, в соответствии с которыми действует человек, и от которых он не готов отказываться. Так нам говорит теория соц.исследований. 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 (если сервер умеет). Всякую интересную логику можно реализовать. Сервер может даже создать новый ресурс, содержащий результат выполнения запроса! Как явный кэш, или как снэпшот на определенное время. Вернуть ссылку на него клиенту в заголовке Content-Location, а дальше к нему уже можно делать обычный GET. Сам QUERY при этом остается безопасным — новых ресурсов при повторных вызовах создаваться не будет. Вот такая штука. Слышали уже? Планируете использовать?

В одном из обсуждений поста про ритуалы и дейлики возникла тема про доверие. Человек отреагировал очень резко: синхронизация под запись в чате?! Да никогда! Это же всё сохранится и может быть заскринено и использовано! Я, честно говоря, даже немного опешил. За 28 лет я с такой культурой встречался, пожалуй, только раз — в одном государственном проекте, где всегда нужно было думать, что и кому ты говоришь, взвешивать слова и понимать, кому твои слова будут переданы и в каком виде, и как будут использованы (скорее всего, с целью навредить). Долго я там работать не смог, естественно. Вообще не представляю, как работать в среде с низким уровнем доверия. Тренеры по лидерству тут любят вспоминать Патрика Ленсиони и его книгу "5 пороков команды" (дисфункций), где он описывает пирамиду "пороков": отсутствие доверия ➜ боязнь конфликтов ➜ необязательность ➜ избегание ответственности ➜ безразличие к результатам. Как любая вертикальная теория, эта пирамида описывает всё в упрощенном виде, но сами по себе эти "пороки" я вижу в командах очень часто. Конечно, всё не так просто, и научные модели дают более комплексную картину. Например, сами по себе конфликты могут быть и продуктивными, и деструктивными. Умеренные конфликты по поводу выполнения задач, или "конфликты идей" наилучшим способом оказывают скорее полезное влияние на общий результат (к таким конфликтам относятся разные взгляды на выбор технологического решения, например). Затяжные "процессные" конфликты скорее вредят (конфликты, связанные с логистикой задач и данных, процедур принятия решения и распределением ответственности). Межличностные конфликты вредят в любом случае (сюда же относятся конфликты целей, норм и ценностей). Конечно, мы исходим из предположения, что у всех членов команды одна общая цель или цели хотя бы взаимосвязаны — если выиграешь ты, выиграю и я, без этого конфликты вообще сложно решить. Ещё важно, кто во что верит и как оценивает ситуацию — как win-win, или как win-lose. Особенно удивительно видеть, когда представители бизнес-заказчиков начинают бодаться с разработкой, рассматривая этот конфликт как win-lose. В отдельных случаях встречаются даже персонажи, находящиеся в парадигме lose-lose: "Ура! Всем плохо!". Источники конфликтов тоже разнообразны: - проблемы в коммуникации (слишком редкая, слишком нерегулярная, перегружающая, неправильно выбранный канал / время / форма / тон, недостаточно контекста, недостаточно прямая); - неверный выбор основы власти или стиль управления (принуждение или стимулирование, нечеткие границы и двусмысленные требования); - культура организации (поощрение личной конкуренции, а не кооперации) - недостаток координации, знаний и сплоченности (члены команды не понимают, зачем они работают, и изолированы друг от друга) Если помножить это на внешние факторы, связанные с недостатком ресурса или неопределенностью, ситуация становится взрывоопасной. Факторы внешнего давления: 1. Проекты с высоким риском / ставками 2. Двусмысленные, плохо разграниченные роли и области ответственности 3. Несколько начальников с противоречивыми требованиями 4. Использование сложных технологий с запутанными связями 5. Нереалистичные сроки 6. Недостаток ресурсов 7. Недостаточное финансирование 8. Некомпетентное руководство Получился пост больше для руководителей и лидов, но и линейные сотрудники могут себе составить представление о том, чем там таким всё время занимаются лиды фуллтайм. А вот этим они и занимаются. Анализом ситуации, в которой их подразделение или команда оказалась, перемножением причин и факторов, и выработкой программы действий, чтобы снизить их влияние и в команду поменьше прилетало, чтобы она спокойно работала, без раздергивания внешними угрозами и без накопления внутренних нерешенных противоречий. Хотите ли вы и умеете ли этим заниматься, вот вопрос.

Команда GigaChat зовёт на вечеринку для AI-разработчиков и исследователей 🎉 29 июля, Сбер.Среда, пространство «Оригинал» (м. «Курская», ул. Земляной Вал, 9А) Без докладов, презентаций и официальных дискуссий – только общение с коллегами по индустрии, обсуждение рабочих задач и болей, новые знакомства и летний вечер на веранде. Регистрация и подробности Надеемся на хорошую погоду 🥳 До встречи!

Знаете, что меня больше всего бесит в процессах "типа 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 страниц по каждому пункту, это уже документ под сотню листов! А мы ещё не начали толком ничего делать. И работа по проработке требований к обеспечивающим системам проекта обычно остается невидимой.

🔥 Три разных человека. Три разных проекта. Один и тот же подход. — Юра взял «скучную» нишу с готовым спросом → сначала печальные $100/мес, через год уже ~$10K/мес — Денис сделал Telegram-игру в одиночку на основе AI → ~ $1500 за 1,5 месяца после запуска — Аня без кода запустила AI-бота для изучения английского → первые ~$200 уже в 1 месяц Разные результаты. Разный масштаб. Но общие правила: 1. не придумывать «гениальную идею», а брать существующий спрос 2. делать простой MVP и быстро запускаться 3. докручивать монетизацию и продукт по факту использования Ребята сделали всё без команды, без инвестиций, а самое главное — без ожидания «идеального момента». Да, не у всех получается сразу. И не у всех выходит на $10K. Но если системно идти по схеме выше — появляется первый доход с продукта, а дальше уже есть что масштабировать. В комьюнити разбираем такие кейсы регулярно: @its_capitan. Что сработало, что нет, и почему. Реклама: ИП Зуев Игорь Владимирович, ИНН: 360408359441, Erid: 2Vtzqusia1x

Интересно, что конфликты с точки зрения цветов выглядят по-разному: Черный-белый с точки зрения белых: борьба добра со злом, а с т.зр. черных: борьба личности с зависимостью от других. Черный-зеленый: прагматизм против расточительства или сохранение против эксплуатации (угадайте, где чья перспектива) Зеленый-синий: равновесие против дестабилизации или совершенствование против самодовольства. Синий-красный: ясность мысли против импульсивности или яркая жизнь против холодного расчета. Красный-белый: свобода против ограничений или хаос против порядка. Здесь ни один цвет не прав абсолютно. Ни один цвет нельзя вычеркнуть. Мир без белого погрязнет в анархии, без синего — не будет развиваться, без черного — провалится в коллективную дистопию типа замятинского "Мы", без красного не будет огня для действий, а без зеленого — оторвется от корней. Поэтому для баланса, если мы говорим про организацию, хорошо бы понимать, каких ценностей вы придерживаетесь и какие конфликты у вас есть. Кроме конфликтов возможны и союзы, причем считается, что смежные цвета имеют что-то общее: Белый и синий соглашаются, что миру нужен какой-план или проект. (Красные с этим не согласны!) Синий и черный оба имеют 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 факторов легко дает те самые доли процента. Одно цепляется за другое, а не просто тасуется. В итоге получается не нормальное, а логнормальное или степенное распределение, которое математически сложно обсчитывать — например, у него во многих случаях нет среднего и конечной дисперсии, и на нем нельзя считать регрессию. А так хочется упростить! Но мир устроен сложнее.

Мы годами строили предсказуемые монолиты и микросервисы, но AI превратил PDLC в Дикий Запад, где старые паттерны проектирования больше не работают. Хватит делать вид, что ты контролируешь ситуацию, просто прикрываясь новой версией TOGAF. Приходи 1 июля на Arch.Meetup, где мы поговорим про архитектурный подход AI disrupt PDLC, и вместе со спикерами из Сбера, Вебпрактик и Газпром нефти будем учиться управлять этим хаосом, пока нейросети не начали проектировать системы вместо нас. 🔗Выбирай удобный формат и регистрируйся по ссылке   📍Встречаемся очно на Кутузовском 32, а ссылку для онлайн пришлем накануне.

Удивительно, но я оказывается не писал здесь про 6D's фреймворк: 6 'Ds' цифровизации. То есть, что нам цифровизация вообще дает? Это аналитический фреймворк Питера Диамандиса, показывающий, что происходит с вещами и процессами при цифровизации. Если мы говорим не просто об автоматизации какой-то деятельности, а о её цифровизации, по фреймворку можно проследить — что будет происходить дальше, если мы в какой-то процесс пустили цифру. Начинается всё с цифровизации, перевода данных в цифровую форму, digitized. Это дает базу для всех дальнейших эффектов: данные в цифровой форме можно универсальным образом и без искажений хранить / обрабатывать / передавать. Совмещать при этом данные из разных источников и разной природы (то, что когда-то называлось "мультимедиа"), добавлять интерактивность и изменять принципы и возможности обработки без изменения аппаратного слоя. Одновременно с этим исчезает отдельный носитель: происходит дематериализация. Физические вещи типа записных книжек, календарей, книг, видео и аудиодисков, бухгалтерских книг — всё втягивается в электронные устройства. Перейдя в цифровую форму, деятельность становится в десятки и сотни раз дешевле, а то и вообще бесплатным. Это демонетизация. Следующий эффект — обманчивость, deceptive. Точнее — обманчивая слабость. В начале цифровая технология всегда выглядит хуже альтернатив. Это всё ерунда какая-то, цифровые печать/фотография/журналистика/кино/учителя никогда не смогут заменить настоящих! Вспомните, как все смеялись над первыми произведениями генеративного ИИ. Экспоненциальный рост в начале выглядит сильно хуже линейного. Подрыв, disruptive — когда цифровая технология становится лучше, её уже не остановить, она начинает разрушать существующие способы выполнять ту же деятельность. Производители пленки и кнопочных телефонов, магазины DVD, и торговые центры разоряются или уходят на другие рынки; библиотеки, кинотеатры, отели и таксопарки чувствуют себя нехорошо и т.п. И всё это приводит к демократизации: то, что раньше могли себе позволить только крупные компании или богатые люди, теперь доступно вообще всем. Например, постановка и съемка видео, доступ к информации и товарам, возможность влиять на события и мнения. Эти 6 эффектов прослеживаются во многих случаях, и если мы говорим не об автоматизации, а о цифровизации — по ним можно отслеживать её эффект. Что исчезнет физически из мира? Что теперь могут делать ваши сотрудники и пользователи, что раньше было слишком дорого / недоступно / непредставимо? За что вы перестали платить? Какой отдел или какая роль больше не нужны? (были подорваны). Если ясных ответов на это нет, то это не цифровизация по сути, а некие ритуальные действия, возможно чисто демонстративные, как хвост у павлина.

Кусочек из продуктового управления. Для описания сути продуктов используются разные формулы. Част можно услышать формулу: "Мы верим, что..." 1. Мы верим, что [наше убеждение о мире, людях или индустрии]. 2. Поэтому мы создаем [наш продукт, услуга или решение]. 3. Чтобы помочь [указание на целевую аудиторию] [конкретная польза или изменение в жизни клиента]. Пример: «Мы верим, что знания можно использовать, только когда они подкреплены практикой. Поэтому во всех наших курсах участники делают много практической работы. Чтобы помочь аналитикам не просто получить информацию, а попробовать новый способ действия.» Но эта формула апеллирует к вере, что ставит нас немного в слабую позицию, а наших критиков заставляет играть роль Станиславского: "верю/не верю". Гораздо больше энергии несет другая формула, мне тут подсказали коллеги, занимающиеся социальными проектами. У них все жестче, не "мы верим", а "нас бесит": 1. Нас бесит, что [распространенная несправедливость, обман или глупость на рынке]. 2. Вместо этого должно быть [как выглядит идеальный, честный или удобный мир]. 3. Поэтому мы сделали [наш продукт или услугу], где все именно так. «Нас бесит, что в онлайн-курсах только записанные видео и тесты. Вместо этого всё обучение должно происходить через практику. Поэтому мы сделали курс, в котором 70% времени занимает практическая работа и разбор результатов» Если вдуматься, в точности подходит ко всем успешным продуктам: «Нас бесит, что и Интернете ничего не найти. Вместо этого должна быть одна страница, на которой есть все ответы. Поэтому мы сделали страницу, где можно ввести запрос и мгновенно получить ответ на любой вопрос» (тут, кстати, сразу понятно, почему ИИ убивает поиск — у них формула продукта одинаковая. «Нас бесит, что в популярных местах невозможно забронировать гостиницу в сезон. Вместо этого каждый хозяин свободной комнаты должен иметь возможность её быстро сдать. Поэтому мы сделали сервис краткосрочной аренды через Интернет» «Нас бесит, что чтобы посмотреть фильм вечером нужно идти в магазин и покупать/арендовать DVD. Вместо этого должна быть возможность посмотреть любой фильм через интернет. Поэтому мы сделали онлайн-стриминг» «Нас бесит, что чтобы показать фотки из поездок нужно собирать целую вечеринку у себя дома. Вместо все знакомы должны видеть фотку и реагировать на неё сразу, как она снята. Поэтому мы сделали соц.есть для размещения фотографий, делающий их сразу красивыми» «Нас бесит, что для доставки груза в космос используются одноразовые ракеты и это стоит дофига денег. Вместо этого разгонные ступени должны использоваться много раз. Поэтому мы сделали такое, что наш основатель стал первым в истории долларовым триллионером». В общем, продукт должен радикально что-то менять, и это что-то должно быть всем ненавистно. Прикиньте к своим продуктам, что вас, как авторов, бесит? Если непонятно, что бесит, то и продукт выходит слабый. Что нас такое всех бесило, что мы сделали портфолио школьника? У меня, честно говоря, нет ответа. Поэтому и продукт вышел так себе. То есть, он красивый, и внутри заложена концептуальная модель, которой я горжусь, но востребованность у него оставляет желать. Бывает, что непонятно решение или мало сторонников. Например, меня бесит, что цифровизация в школе сводится к показу презентаций на проекторе или доске,а вместо этого должна быть организована исследовательская игровая среда с заданиями разного уровня. Но я не знаю, что тут можно сделать, остальных-то это не бесит. В общем, не делайте ватных продуктов, радикализируйте свою формулу.

В продолжение предыдущего поста — зашел посмотреть, что сейчас делает Алистер Коберн. Он, конечно, делает! Написал в 2025 году книгу про связь User Story, Use Cases и User Story Maps. То, что я много раз рассказывал на тренингах, но в книгу не оформил, да даже и на конференциях ни разу не рассказывал, думал, это слишком просто. А вот нет, нужно говорить и писать! Впрочем, приятно чувствовать себя на одной волне с великими. Что он пишет: User Story — значимое для пользователя изменение в системе (показатель прогресса), что-то, что пользователь может увидеть и пощупать. Use Case — перечисление способов, которыми пользователь может достичь своей цели (или не достичь). Story map — раскладка карточек, где слева направо идёт процесс, а сверху вниз — приоритеты. Основные принципы: 1. Глаголы подразумевают продолжительное действие 2. Раскладывайте глаголы на более короткие (по продолжительности действия) глаголы 3. Управляйте точностью (precision — тут правильный перевод ближе к "сфокусированности", "кучности") 4. Раскладывайте (декомпозируйте) всё, не только глаголы 5. Пишите документы вместе, разработка + бизнес 6. Пишите с точки зрения пользователей 7. Пишите только потребности, а не энциклопедию всего 8. Жертвуйте совершенством ради читаемости Принципы декомпозиции: Для use cases: до уровня целей взаимодействия пользователя с системой (имеющих смысл, даже если системы нет, система — это просто один из вариантов реализации), в метафоре Коберна — до "уровня моря" Для User story — хоть до "уровня моллюсков", то есть почти бесконечно. Use case поставляет полное описание способов работы с системой, поэтому из него нарезаются единицы прироста пользы — user story. Каждая история представляет собой срез юскейса (slice). Story map объединяет user stories и use cases: верхняя строка — это успешные шаги одного большого сценария, который обеспечивает вся система (и одновременно — названия юскейсов более низкого уровня). Карточки в колонке — срезы юскейсов, варианты данных / каналов / интерфейсов, обработка ошибок. Вот такое мнение гуру. А в 2026 году он уже успел выпустить ещё одну книгу: "Упрощая проектирование программных продуктов: гениальность бюрократии". Говорит, архитектура программных систем должна строиться на двух принципах матерых бюрократов: * "Это не моя задача" * "Мне это не нужно знать" То есть, каждый модуль должен четко понимать, что не является его задачей, и не делать этого. И не интереоваться ничем, кроме своей узкой задачи. Говорит, особенно актуальны эти принципы в эпоху ИИ-агентов, когда каждый агент старается побольше сделать. Нет, нужно им прописывать личности бюрократов, которые делают только то, что положено, и не больше. И тайно всех окружающих ненавидят.