Пятничная загадка про управление на основе данных:

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

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

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

Вопросы: кто автор цитаты и какой это год?

Чур не гуглить!

Upd: Ответ на загадку: это Гастев, "Профессиональные союзы и организация труда", 1924 год (!)

Довольно быстро правильный ответ появился, кстати, продвинутые у нас подписчики!

Открытие дня — оказывается, провал коллективного принятия проектировочных решений, то, что называется "Design by Committee" — имеет строгое математическое доказательство и называется "Теорема Эрроу о диктатуре".

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

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

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

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

Отсутствие диктатора — ни у кого из голосующих нет права последовательно продавливать своё решение, игнорируя остальные голоса.

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

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

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

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

Хуже того: недавно появилась статья https://arxiv.org/abs/2504.06589 (пока в виде препринта), в которой авторы показывают, что задача, сформулированная в теореме Эрроу, эквивалентна проблеме остановки, и, соответственно, не может быть вычислена. Это доказал ещё Гёдель. Точнее, три первых свойства являются невычислимыми без диктатора. То есть, мы принципиально можем их рассчитать только при наличии единственного лица, принимающего итоговое решение.

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

Про что ещё хотел вам рассказать: мероприятие, к проектированию которого я лично приложил руку — это весенняя конференция Flow — Flow Spring 2025.

Она будет 26 апреля, в субботу, бесплатно и только онлайн. Так сказать, как разогрев к осенней, которая уже оффлайн и на пару дней.

Вместе с ПК запланировали два трека: смыслы и фейлы.

• Смыслы — о глубоком понимании профессии и про мотивацию.

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

Набор спикеров шикарный:
Бураков, Бесков, Лобзов, Чернухин, Сатин, Максимов, Безуглый — просто все, кого в любом случае интересно послушать. (Я сам пока коплю силы на осень).

Александра Клименко про коммуникации — у неё был один из самых посещаемых докладов на прошлом Flow с интерактивом, вот тут про него писал.

Полная программа тут

В общем, если вы разогреетесь в пятницу у ребят в Ви.Tech, можно продолжить в субботу на Flow. Целый весенний аналитический уикенд!

Регистрируемся тут

Вот эту схему вам ещё, кажется, не показывал. Все области знаний по архитектуре! От сообщества DNA, это какие-то польские ребята, случайно наткнулся.

Люблю обобщающие схемы! Вы уже, наверное, поняли.

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

Во-первых, 4 области:
* Системы
* Решение
* Инфраструктура
* Приложение

Давайте начнем с решения. Тут у нас 4 раздела:
* Область проблемы
* Визуализация
* Принятие решений
* Область решения

(Опять проблемы с русским языком — не отличаем solution от decision)

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

Хороший блок про принятие решений. OODA, надо же. Это нужно подробнее разобрать, надо бы пост отдельный сделать.

В области решений есть про Закон Конвея — это важно для архитектора, они правда этим довольно часто занимаются — распределяют команды по сервисам и системам.

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

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

Область систем — это в основном про распределенные системы. Тут мне особенно нравится раздел 'Invalid assumptions during system distribution' — ложные представления при проектировании распределенных систем (нулевая задержка передачи, надежные сети, бесконечная пропускная способность, защищенные сети, топология не меняется, есть только один администратор, стоимость передачи данных равна нулю, сеть гомогенна — тут всё прекрасно!)

И 'Reasons for system distribution' — основания для распределения. Почему вы хотите распределенную систему, а не монолит? Это всё совсем не бесплатно. Вы решаете организационную проблему или техническую?

Большой кусок про микросервисы, с перечислением "за" и "против", и раздел про коммуникации, где живут наши интеграции (ну ещё захватывая раздел "шины").

В общем, козырная схема. Даже не знаю, что добавить. Сначала хотел придраться к структуре команд и обратному закону Конвея — но он упомянут в области решений и в микросервисах. Потом — к схемам и контрактам, но про них есть в коммуникациях. Про брокеры сообщений есть в разделе Fire-and-Forget. Вот фитнесс-функции куда-то потерялись, в явном виде не упомянуты.

Разбор всей схемы тянет на хорошую такую учебную программу месяцев на 8. Или на 6 отдельных курсов 😉

Как минимум, можно проверить себя: что из этого я знаю и использовал, о чем знаю только теоретически, и про что не знаю ничего. и составить план по изучению в режиме self paced learning.

Забираем, пользуемся!

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

А за что минусы-то?

Услышал тут про интересную практику: когда бизнес-аналитики сопровождают разработку какой-то фичи до конца.

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

Когда я услышал всё это, сразу сказал — это уже не бизнес-аналитики, это фича-оунеры (feature owners). Я, честно говоря, просто из головы этот термин выдумал, но тут же решил проверить — и что вы думаете? Всё уже давно придумано, есть эти самые фича-оунеры, и даже есть статья 'Are feature analysts the new business analysts?'

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

Получается плавный вход в роль продакта — ответственность ещё не за весь продукт, можно попробовать на небольшом кусочке. Но тут нужно и про бизнес-метрики думать — какую пользу приносит эта фича, какой вклад она дает в бизнес, на какую бизнес-метрику влияет? — и про продуктовые: сколько пользователей начало этой фичей пользоваться, есть ли рост MAU/DAU фичи или наоборот отток (попробовали и бросили), что с удовлетворенностью и т.п.

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

Смежная роль, про которую даже чаще пишут — Feature Lead. Но это заход с другого конца: фича-лид это обычно кто-то из разработчиков, способных и готовых осмыслить бизнес-потребности, метрики, требования и сопровождать команду в разработке фичи. Фича-лиды именно из разработчиков есть, например, в Яндексе (как мы знаем, аналитиков там нет, зато вот) и в 2GIS.

Забавно почитать, как у программистов-"я-хочу-просто-писать-код-отстаньте-от-меня" через силу отрастают менеджерские, аналитические и продуктовые функции. Как в фильме ужасов, когда кого-то укусил монстр или кто-то что-то не то выпил. У БА-"я-хочу-просто-описывать-требования-отстаньте-от-меня" тоже что-то примерно такое же происходит. Сложно отращивать новые лапки и усики.

Вот на ЛАФе в прошлом году Илья Бравин рассказывал о превращении аналитика в фича-лида (он там, правда, очень быстро переходит от фича-лида дальше к проджект-лиду).

Сложность здесь вот в чём: появляется Accountability, в отличие от простой Responsibility. На русский их обоих переводят как "ответственность". Иногда чтобы отличить первый термин переводят как "Подотчетность" (второй остается "Ответственностью"), мол — у команды есть ответственность, а у фича-лида/оунера ещё и подотчетность. Ты член команды — ты обязался сделать то, что нужно для выполнения задачи и поставки результата. Ты владелец (фичи, продукта, проекта) — ты обязался лично отвечать за результат.

Как пишут на scrum.org:

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

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

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

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

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

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

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

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

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

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

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

Например, уже трёхзначаная шкала [-1,0,+1] уже лучше, чем просто упорядочивание (для большого числа избирателей, для малочисленных групп лучше использовать [-2,-1,0,+1,+2]). Недостатком тут является неустойчивость системы выборов к согласованным стратегиям голосующих и манипулируемости. Тут можно говорить об открытости и закрытости информации: знают ли участники о выборах других участников. И могут ли они менять свои голоса после того, как узнают о голосах других участников. Это всё сильно усложняет выборы, тут уже какие-то другие модели нужны (напишите мне, если знаете про них).

Я сам часто использую для оценки функций кардиналистский подход со шкалой [0,1,3,9]. Я не нашел модели, которая бы математически обосновывала такой выбор, подсмотрел у старших товарищей чисто в виде эмпирического правила. Но работает отлично!

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

[Если вас интересует хороший обзор темы, рекомендую вот эту статью: https://plato.stanford.edu/entries/arrows-theorem/ ]

Кто лучше всех учит навыку?

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

Ну просто многие вещи он уже делает на автомате, и даже не замечает, что их делает.

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

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

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

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

Это давно известно в спорте — я вот в институте немного занимался тяжелой атлетикой, и у нас в зале висели кинограммы рывка и толчка: покадровая съемка каждого упражнения, 15-20 фото на упражнение + траектория движения грифа штанги чуть ли не по сантиметрам. А так-то кажется — ну что там, взял, поднял.

Соответственно, примерно столько мелких движений, а нюансов их выполнения — ещё больше.

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

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

То есть, важно не "что", а "как". По этой же причине "не работают" ГОСТы — в них написано "что", но почти никогда не написано "как".

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

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

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

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

В лучшем случае вы получите оочень общее описание процесса или пересказ какой-нибудь модели SDLC. Везде происходит какая-то магия при переходе от целей к решениям: "сначала выявите всех стейкхолдеров, потом зафикисруйте их интересы и пожелания, и на основе них разработайте требования". Вроде всё понятно, но что конкретно делать-то?

Это тем более удивительно, что изначально — ещё с 60-х — анализ и проектирование систем описывали именно как последовательность ясных шагов, выполняя которые аналитик приходит к модели целевой системы. Вопрос только, с чего мы начинаем. У Дугласа Росса (SADT, IDEF0) всё начинается с функции, её входов и выходов, потом прорабатывается внутренняя последовательность шагов. Информационные системы ведь просто берут входящую информацию (с перфокарт) и преобразуют её в исходящую (ну, так было в 60-70-х). У вас нет юскейса — у вас есть функция, а требования описывают входы, выходы, управление и шаги процесса + скорость работы.

Можно пойти наоборот от данных, как у Тома ДеМарко и Ларри Константина — тогда вашей первой диаграммой будет контекстная, показывающая систему в окружении пользователей и других систем, обменивающихся данными с вашей, а следующими — набор DFD: диаграмм потоков данных, с указанием процессов. Информационная система ведь — набор входящих и исходящих данных, процессы по их обработке (то есть функции, это же время структурного программирования), места и форматы хранения (уже появились базы данных).

К концу 80-х развились графические интерфейсы, и у пользователя появился выбор — что конкретно делать именно сейчас, какую функцию вызвать. В логике OOSE Ивара Якобсона всё начиналось с типов пользователей и юскейсов: а что в принципе пользователь может сделать в системе в любой момент? Потом каждый юскейс раскрываем в виде диаграммы устойчивости (robustness): показываем интерфейсы, управляющую логику и сущности, и какие данные они друг другу передают. Ведь ИТ-система состоит из интерфейсов, логики и объектов данных (впрочем, интерфейсы и логика — это тоже объекты). А как они конкретно хранятся в БД — это уже низкий уровень, ORM с этим разберется.

Новейшие подходы (EDA, Event Sourcing, Event Storming и даже в чем-то REST) говорят, что всё начинается с события. У вас в предметной области есть события, они вызывают срабатывание какого-то обработчика и реакцию системы/пользователя и изменение данных. А события возникают в результате отдачи команд или реакции на предшествующее событие. ИТ-системы ведь навешиваются на шину или брокер, по которой бегают сообщения о событиях — нужно просто их ловить и на них правильно реагировать.

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

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

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

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

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

Давайте разбираться. Во-первых, кроме Руководства по написанию требований у INCOSE теперь есть ещё один документ: Needs and Requirements Manual (NRM), выпущенный в 2024 году, то есть совсем свежий. Почему один из них guide, а другой manual, и как это адекватно перевести на русский, непонятно. Видимо, дело в размере — guide всего 140 страниц, а manual — почти 500!

Во-вторых, в мануале есть детальное объяснение всей используемой онтологии. Руководство её только использует.

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

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

Идея решения, короче.

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

На самом деле, это ещё в ГОСТ 34.601—90 написано, но кто ж его читал. И в ГОСТ Р 59793—2021 повторено. Если вас в следующий раз попросят всё "по ГОСТу" делать, вы людям этот самый ГОСТ покажите, там начинается всё не с ТЗ, а с обследования, формирования пользовательских требований и разработки вариантов концепции АС (нескольких!). А ТЗ — это третья по счету стадия, перед ним ещё 2 стадии и 8 этапов работ, на минуточку.

Концепции, из которых проистекают потребности, берутся не любые, а именно концепции жизненного цикла. Правда, не уточняется — ЖЦ чего именно. Судя по этапам — сущности. То есть, как организация собирается управлять, приобретать, проектировать, разрабатывать, строить/программировать, интегрировать, верифицировать, валидировать, передавать, инсталлировать, эксплуатировать, поддерживать, обслуживать и выводить из эксплуатации сущность.

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

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

Что интересно: почти везде вместе со словом "анализ" используется хитрое слово 'maturation' — "вызревание". То есть, пока вы анализируете, эти самые концепции и потребности "вызревают" в головах и стейкхолдеров. Это, мне кажется, ещё круче, чем elicitation (извлечение, добыча) — нечего там добывать, оно созреть должно!

Ещё одна важная деталь: в мануале ясно написано, что первично установленные значения целевых показателей и метрик очень часто не являются осуществимыми, и приходят к каким-то реальным значениям только через несколько итераций анализа и "дозревания", да и то с оговоркой "с приемлемым уровнем риска для этой стадии жизненного цикла"! (Кто вообще оценивает уровень риска?)

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

Вышел очередной Requests for Startups от известнейшего акселератора Y Combinator. Не то чтобы я собирался подавать туда заявку, но я регулярно мониторю их запросы, чтобы понять — что сейчас вообще востребовано и куда рынок смотрит.

Конечно, в последнее время там сплошной ИИ. Конечно, они идут за глобальными событиями — в 2020-21 был биотех и противодействие глобальным эпидемиям, а в 2024 появились военные технологии (ну в смысле — защитные, defence). Climate-tech, в том числе про разные источники энергии и электрические автомобили там вообще чуть ли не в каждом наборе. Биология, здравоохранение, климат, технологии безопасности, роботы и генеративный ИИ для программирования и инженерии.

Весной 2025 все хотели AI-агентов и RPA на новом уровне. Такие агенты, сякие агенты, инструменты для создания AI-агентов, софт для потребления AI-агентами (B2A). Скреппинг, машинно-читаемая информация и API на новом уровне — не для людей, а для ИИ. В общем, понятная история, это мы и без YC знали.

И тут! В запросе на летний набор 2025, внезапно — образование! Чтобы вы понимали, про образование и EdTech Y Combinator в последний раз спрашивал в 2017 году! Ну, может быть помните — бум MOOCов, Coursera, edX, вот это всё. В 2010-2016 был прямо бум. Российские проекты примерно тогда же появились - Нетология, Skyeng.

А потом — как отрезало. В смысле инвестиций. Последний всплеск был в 2020-21, когда был ковид и самоизоляция, а потом на радостях все дружно вышли на биржу. Но революции не случилось. Дизрапта индустрии не произошло. Мы не бросили учиться у живых учителей, школы и университеты не закрываются массово, люди не покупают подписку на обучение в течение всей жизни, как было обещано. Отлично себя чувствует только токсичная зеленая сова Duo (цепляет здорово, кстати — мало чем в жизни я каждый день занимаюсь уже несколько лет — ну вот в канал пишу 😹 ). EdTech уже практически стал ругательным словом, можно найти множество статей с заголовками 'EdTech is dead' на разные лады.

И тут, внезапно, запрос от YC. Аж в двух видах:

1) Персональный AI тьютор. С идеями от "Мемекса" Ванновара Буша (это 1940-е годы) до "Алмазного букваря" Нила Стивенсона. Идеальный ИИ-учитель, который сгенерирует контент специально для вас лично, причем хоть текст, хоть инфографику, хоть видео с озвучкой. Хотели бы такого персонального учителя в кармане, который бы помог вам разобраться в любой теме в любой момент, и с настроенным на вас уровнем погружения?

2) Будущее образования. Опять двадцать пять. Нет, ну 1.5 миллиардов обучающихся в мире — это прямо лакомый рынок! Как-то даже обидно признать, что ничего на нём не меняется — как 100 лет назад учились (а то и 200, и 400), так и сейчас учатся. Ну и, конечно, AI тут сейчас всё поменяет. Они там честно пишут — не знаем, что конкретно "всё" — we're still very early in figuring out what AI can truly achieve here — и как на этом заработать, но должно же уже что-то поменяться в обучении, сколько можно!

Я-то сам с 2006 года, а то и раньше увлечен идеями преподавания, и применения технологий в образовании, и кое-что даже сам делал. Меня это, конечно, радует. Но вот какая это может быть идея?

Если бы было возможно всё, что угодно — каким бы вы видели идеальный способ обучения?

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

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

Технологии интераций — это 7 уровень, прикладной. Там живет REST (HTTP), и чуть выше -- SOAP (хотя он использует HTTP только как транспорт), GraphQL, gRPC.

А вот выше — политика. Интересы, влияние, торг, уступки, борьба за ресурсы. Почему вообще мы должны вносить изменения в нашу систему, чтобы поддерживать вашу интеграцию? Это вам нужно или нам? Кто кому диктует правила? Кто вкладывает какие ресурсы? Что вы готовы предложить в свою очередь?

Вопросы симметрии и асимметрии: вы достаточно большие, чтобы диктовать всем клиентам свои стандарты, и клиентам не остается ничего другого, кроме как подстроиться под них? Или вам придется подстраиваться под клиентов?

В одном проекте я спроектировал клёвое веб-API — на основе международного отраслевого стандарта, с использованием терминов из контролируемых словарей, с несколькими уровнями совместимости, с профилями для разных юскейсов — заглядение, а не API. Высокотехнологичное. Но клиенты сказали — не-а. Мы так не можем, давайте мы вам просто эксельки пришлем, а вы их распарсите как-нибудь. Кому больше нужно, чтобы наши данные оказались у вас? В этом проекте оказалось, что больше нужно было нам, а не клиентам, и пришлось парсить эксельки, и разбираться со всеми последствиями. Высокотехнологичное API так и осталось памятником самому себе, как Царь-пушка.

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

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

Два зама сговорились и "дружат" против третьего, чтобы поставить на его место своего человека. Руководитель одного из подразделений хочет отгрызть себе дополнительную зону влияния. Два подразделения бьются за одну область ответственности. Новый зам собирает под себя разрозненные функции, с ним борются люди из старой команды. Группа стейкхолдеров хотят развалить проект и обвинить в этом другую группу. Кто-то хочет получить контроль над важными данными (например, отчетами для руководителя или политиками выделения ресурсов). Это всё примеры политических игр, которые я наблюдал своими глазами. И это игры, которые могут определять согласие или противодействие вопросам развития систем и их интеграции.

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

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

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

А вы принимаете в расчет эти уровни?

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

Аналитик как медиатор. У аналитика много задач, и одна из них — разрешение конфликтов.

Вообще для аналитика правильная роль — сторонняя, аналитик не владеет какой-либо системой и не защищает её.
Если он начинает выступать в роли владельца — он уже скорее архитектор или технический продакт-менеджер.

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

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

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

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

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

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

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

Иногда удивительный эффект возникает, если просто озвучить свои чувства.

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

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

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

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

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