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

Перевел статью создателя mermaid.js про UML и диаграмму последовательности: https://habr.com/ru/articles/840890/ Он там ещё год назад собрал все мнения и высказывания по поводу "смерти UML", так что можно как обзор использовать, и по ссылкам уходить читать, если интересно. Ну и про диаграмму последовательности пишет ровно то, что я на каждом тренинге говорю: идите от happy path, давайте общую картину, не сваливайтесь в детали. В общем, буду рад обратной связи, а какие-то комментарии могу и Кнуту передать — я списался с ним и спросил разрешение на перевод.

Как согласовать интерфейсы. Ну ладно, мы разобрались, что, когда пользователь впервые видит интерфейс будущей системы, он не воспринимает это, как финальную версию — а скорее как повод наконец-то подумать, как оно на самом деле будет работать (если вы, конечно, заранее не прорабатывали именно процесс решения задачи, а просто "собирали требования"). Но, допустим, первое впечатление уже получено, и уточняющие требования собраны, и всё уже дважды переделано и вроде мы дошли до стадии утверждения интерфейсов. И с этим очень часто возникают большие проблемы. Они возникают у аналитиков, у дизайнеров и иногда даже у продактов, как ни удивительно. Потому что вместо того, чтобы подтвердить и согласиться, стейкхолдеры в очередной раз начинают просить передвинуть кнопку, добавить ещё пару полей и поиграть со шрифтами. И конца этому не видно. Что здесь обычно происходит? А происходит неуправляемая встреча. Как такая встреча может быть устроена? ❌ Дизайнер или аналитик просто показывает экран системы. Ну вот мы сделали вот такой экран, есть к нему замечания? Это прямо мощная подача — ведь если стейкхолдер скажет "нет", это может значить, что он что, не заинтересован в системе? Или не успел разобраться, и это сейчас замечаний нет, а потом появятся? Дали ли мы время на то, чтобы ознакомиться? Знаем ли мы сами — каких замечаний мы от этого стейкхолдера хотим услышать? Ещё хуже вопрос "вам нравится?" Тут мы полностью снимаем с себя ответственность и отдаемся в руки человека на другой стороне. Так быть не должно. Эксперты здесь мы. Мы спроектировали всё правильно — красиво, удобно и логично, и мы за это отвечаем. Не нужно перекладывать решение на человека, который в нём не специалист. ❌ Аналитик показывает экран и начинает рассказывать последовательно про каждый элемент. Не надо так. Люди видят, что нарисовано на прототипе. И понимают, для чего каждый элемент нужен. А если не понимает — кажется, у нас есть проблема. Вот только объяснение делу не поможет — ведь в реальной жизни аналитика или дизайнера рядом не будет, чтобы объяснить, что тут зачем. А визуально человек воспринимает информацию гораздо быстрее, чем на слух. Пока вы рассказываете про каждый элемент, ваш визави уже рассмотрел весь экран, и теперь скучает. ✔️ Как правильно построить презентацию интерфейсов: 1. Рассказать, для каких пользователей создан этот интерфейс (для какой роли или персоны) и в какой ситуации этот пользователь находится, когда использует этот интерфейс. 2. Перечислить сценарии, которые пользователи могут выполнить при помощи этого интерфейса. Обычно есть 1-2 основных сценария и дополнительные, куда входят граничные ситуации, альтернативы, исправления и настройки. 3. Демонстрация прохождения сценария пользователем с какой-то ролью. В качестве пользователя выступает аналитик, либо это предлагается сделать одному из согласующих. Сценарий показывается по шагам, при переходе с одного шага на другой можно спросить у зрителей — понятно ли, как перейти к следующему шагу (как вернуться на предыдущий, как исправить что-то или посмотреть дополнительную информацию). Это закрытый вопрос, он предполагает ответ "да"/"нет". Если на этапе разработки требований вы задавали в основном открытые вопросы, на этапе согласования лучше задавать закрытые вопросы. Теперь это не рассуждения, это вопросы на констатацию факта. Задаем конкретные вопросы — понятен ли этот переход, ясно ли, где мы сейчас, что тут самое важное, где ошибка. Все вопросы на уточнение и выяснение вы, надеюсь, задали заранее. Если стейкхолдер стремится высказать своё замечание, возвращайте его в ту же схему: про какую роль он говорит? В какой ситуации? Какая цель у пользователя? Что он делает? Что происходит, и что он ожидал? Часто оказывается, что либо ситуация надуманная и так не бывает, либо в сознании у критика спутаны несколько ролей, либо, возможно, мы действительно пропустили какую-то важную ветвь сценария. Конечно, про формат нужно предупредить участников заранее. Описание контекста, ролей пользователей и сценариев для демонстрации заранее отправить. И про формат обратной связи рассказать.

Продолжаю про явное и неявное знание: и вот когда вы считаете, что уже выявили все требования и проработали интерфейс (может быть, даже с дизайнером), и приносите его показывать пользователям, вы считаете, что это уже конец, вся работа сделана. А для ваших заказчиков в этот момент работа только и начинается! До этого они что-то вам рассказывали, это ничего не значит. А теперь им есть на что посмотреть, есть к чему отнестись. Тут они могут как-то соотнести то, что видят, с тем, как они работают. Знания вытащили из их голов и обособили, эксплицировали. Люди впервые увидели свои неявные знания отдельно от себя и удивились. Теперь их нужно изучить, исправить некоторые моменты, а главное — теперь им понятно, как это будет выглядеть и над чем будет идти работа (над внутренним устройством системы работа пользователей идти не может — оно непредставимо или представимо превратно, если только пользователь сам не был когда-то программистом). Тут возникает острый конфликт: аналитик думал, что работа уже почти закончена, а пользователь — что работа только началась. Эта мысль поражает неопытного аналитика до глубины души и зачастую выглядит, как издевательство. Особенно когда у пользователей не очень много времени, и встречи по согласованию (как думает аналитик, а на самом деле — по разработке интерфейсов и дополнительных требований) происходят редко. Тут и сроки работ начинают затягиваться, и взаимное недовольство растет. Что с этим делать? Во-первых, понять и признать, что это происходит. Это, в первую очередь, совет руководителям — а то у них в плане записано обычно "первая встреча — сбор требований, 2 часа", "вторая встреча — согласование экранов, 2 часа", и дальше уже отдали в разработку. Как бы не так. Во-вторых — ну, как-то нужно решать. Сложно за одну встречу и про требования поговорить, и сразу первичное решение предложить, которое на самом деле только повод поговорить про настоящие требования. Что можно сделать: ➡️ честно запланировать дополнительно 2-3 встречи уже после первоначального эскизного решения; ➡️ сделать "домашнюю работу", и приходить на первую встречу уже с заготовками решения, хотя бы примерными, хотя бы аналогами. Если вы работаете в имеющихся системах — можете показать, как выглядят интерфейсы в них, и обсудить, на что будет похож интерфейс для новой задачи. Если у вас есть дизайн-система — покажите элементы из неё. Если вы делаете новую систему — покажите что-то, что может быть похожим по смыслу. Для системы анализа ЭКГ я использовал в качестве источника вдохновения музыкальный редактор. Если у вас есть бумажные формы, которые вы будете переносить в электронную форму — распечатайте их, покажите, как они могут лечь в интерфейс — вот прямо ножницами порежьте в вклейте в распечатку типовых форм. Ножницы и клей — великая вещь! Всех с началом учебного года, кстати. Если уж совсем ничего нет — пробуйте лего, человечков из настолок и т.п. Да даже стикеры лучше, чем просто текст! На картинке — первая схема "Открытого образования". Сразу стало многое понятнее. В-третьих — идеальный вариант, это Google Design Sprint или что-то аналогичное. Да, на 5 дней отключиться от рабочих процессов может быть сложно. С другой стороны — ездите же вы на конференции и ходите на тренинги, и ничего. А с точки зрения скорости прохода (времени от идеи до постановки) — выиграете несколько недель.

Сейчас в основном консультирую, выступаю ментором и веду канал. Участвую в ПК конференций по системному анализу: Flow, ЛАФ, WAW. Сделал несколько топовых докладов (см. закреп). Первым написал про применение ChatGPT для задач аналитика, архитектора и продакта (сейчас Claude дает лучшие результаты). Провожу тренинги в школе Systems.Education. Соавтор книги "Цифровое качество" (к сожалению, пока что нет в продаже, что-то там с авторскими правами). Что меня в основном интересует на сегодня: как же, всё-таки, мы создаём эти ИТ-системы и продукты? Как это всё происходит, и как должно происходить правильно, особенно в самом начале? Как разделить роли? Что должен делать разработчик, что архитектор, что продакт, что аналитик? Как устроен пресловутый SDLC? Работает ли agile? Как, блин, понять, что нужно этим пользователям и как им это дать? Мои убеждения: 1. Требований объективно не существует. Тем более нельзя их "собрать", "выявить" или "извлечь". То, что мы называем требованиями — это высказывания о желаемом поведении системы, то есть, "собирая" требования — мы на самом деле изучаем деятельность людей и проектируем решение для поддержки этой деятельности, решения проблем в ней. 2. Идеальный вариант работы: небольшие команды без жесткого разделения ролей, которые могут сообща накинуться на проблему и придумать её решение. Не числом, а умением. Небольшая группа высококлассных спецов может реально быть в 10 раз быстрее и эффективнее, я это лично видел. 3. Если уж вы решили заниматься требованиями up front — я знаю много техник, которые позволят не пропустить важные требования и избежать недопонимания. Я про них часто рассказываю в канале. 4. Всё, что написано в книжках, нужно рассматривать скептически: умозрительные модели могут вообще никак не соответствовать реальной практике. Я верю в эмпирические исследования и стараюсь их изучать (и иногда пишу про них во второй канал: https://t.me/yksdailylinks). 5. Любой стандарт или Body of Knowledge лучше книги: во-первых, там будет выжимка без воды, во-вторых — обычно стандарты всё же хоть как-то опираются на реальную практику, а не только на авторские идеи. К счастью, многие стандарты переведены и свободно доступны на русском языке. Если у вас есть интерес в изучении того, как на самом деле устроен процесс создания систем в этом нашем ИТ, или вы знаете, где это изучают (обычно это какой-то университет) — рад буду познакомиться и что-то поделать вместе! А то у нас скептически относятся к независимым исследователям, нужно обязательно аффилироваться с какой-то организацией.

Всем привет! В канале большое пополнение, поэтому давайте я напишу о себе. Может быть, будет интересно и тем, кто читает меня давно. Меня зовут Юрий Куприянов. Я занимаюсь созданием ИТ-систем с 1998 года. Первые лет 10 работал программистом, тимлидом, архитектором систем. Где-то это был фриланс, где-то я работал в штате, занимался разработкой в разных областях: в медицине (одна из первых систем цифрового анализа ЭКГ), в нефтянке (писал софт для управления Ванинским НПЗ), в туризме (термина TravelTech тогда ещё не было), недвижке, hrTech, и т.д. Чуть было не написал одну из первых CMS, но один умный товарищ сказал — ну что ты ерундой занимаешься, какие-то там сайтики, иди нормальные вещи пиши на C++! До сих пор жалею. Так получилось, что на всех проектах я выполнял роль аналитика, а зачастую и продакта — собирал требования, проводил обследования, писал ТЗ, когда было нужно, проектировал интерфейсы, пытался понять — что нужно пользователям. Вообще тогда не было такого сильного разделения труда — например, мы не знали о роли DevOps, а просто брали и выстраивали пайплайн релизов и миграций, анализировали нагрузку и администрировали сервера. Когда возникала задача поговорить с пользователями и выяснить, что им нужно, как-то так получалось, что шёл к ним разговаривать я. А если так не получалось, и шёл не я — на проекте начиналась твориться лютая дичь: например, мы только к концу разработки узнали, что система по подбору объектов недвижимости должна, оказывается, работать в киоске с тач-интерфейсом, а не на десктопе с мышкой. Самым мощным проектом из тех времен было создание системы Казначейства Газпромбанка; она, кажется, работает уже 20 лет, хотя, конечно, морально и архитектурно ужасно устарела. Её вроде бы уже несколько лет переписывают много людей, не знаю, что там сейчас. Я был из тех самых 10x-еров, которые заменяют сразу 10 человек: мы написали всю систему буквально вдвоём + два стажера (они оба уже давно CTO крупных банков). Именно тогда я стал заниматься образованием и выпустил много отличных ребят — почти все сейчас либо основатели своих компаний (например, Флант), либо технические, либо дизайн-директора. Потом я стал заниматься координацией работ в больших проектах, задачами анализа и проектирования корпоративной архитектуры. Возглавлял управление методологии, архитектуры и документации в Национальном расчетном депозитарии. Потом плюнул на корпоративный мир и занялся интернет-стартапом про онлайн-трансляции и видео-созвоны, когда про это ещё мало кто слышал (Zoom вышел в год нашего закрытия). Было весело: мы транслировали чемпионат России по спортивной гимнастике, первые интенсивы Бизнес-Молодости и концерты Московской Консерватории. Как обычно, всё сдохло из-за отсутствия маркетинга и присутствия флеша. Потом я занимался управлением знаниями, спроектировал систему управления идеями для Сбера, был экспертом премии MAKE Russia (Most Admired Knowledge Enterprise). Параллельно я продолжал преподавать в МИЭМ, МФТИ, НИУ ВШЭ, в каком-то году был даже лучшим преподом Вышки по выбору студентов, и в 2015 эти интересы сошлись — я поучаствовал в запуске платформы "Открытое образование" — сначала написал начальное ТЗ, а потом руководил разработкой в роли директора по продуктам. Директор по продуктам я, правда специфический: больше про упихивание в срок невозможных проектов (openedu.ru запустили за 6 месяцев — от состояния "есть ТЗ и один Юра", до состояния "сплоченная команда внутренней разработки, три команды подрядчиков, курсы загружены на платформу, студенты начали регистрироваться") и про удовлетворенность пользователей (тот же openedu набрал полтора миллиона пользователей без маркетинга вообще). Так вышло, что с чисто коммерческими продуктами я мало работал. Хотя какое-то время дрючил разные проекты в заочке ФРИИ. В общем, уже почти 10 лет я занимаюсь созданием систем в EdTech: Coreapp.ai, Университет 2035, в последний раз делал попытку привести в чувство Московскую электронную школу, но не очень преуспел в этом тяжком деле. Выгорел, собрал все шишки, временно ушёл "на пенсию".

В продолжение разговора о явных и неявных знаниях. Понятно, что неявное знание гораздо проще и приятнее передавать тоже как неявное, а не экстернализировать, что требует значимых усилий. А иногда и сопротивления. И методы для изучения этих знаний должны быть соответствующие: демонстрация, наблюдение — пусть покажут и объяснят, как они это делают. Может быть даже — выполнение с помощью эксперта. Вы сами попробуйте сделать, а пользователь пусть вам рассказывает — на что когда обратить внимание. Способ, кстати, очень мощный, особенно для проектирования интерфейсов — сразу позволяет многое узнать о контексте и о том, что важно. Сложно представить ситуацию курьера на велосипеде с мобильным приложением, или водителя, или учителя во время урока, пока сам в эту ситуацию не окунешся. Из удобного кресла в тихом кабинете такое не представишь. Нужно сходить на гэмба — место производства, как это в японском менеджменте называется. Там достоверные знания. Если так не получается — хотя бы попросите пользователя в деталях рассказать о ситуации, в которой планируется использовать ваш продукт. Причем, с контекстом: где он, как сидит/стоит/бежит, есть ли кто-то рядом (кто должен или не должен видеть информацию), есть ли давление времени (какой-то фактор, который требует выполнить операцию быстрее), ещё какие-то отвлекающие или давящие факторы. И пусть не фантазирует, а описывает реально случившуюся ситуацию! А показывать человеку описания, схемы и модели в этом случае почти бесполезно — знания-то неявные, они в такой форме никогда не существовали и непонятно, как к ним относиться. Особенно если ты не участвовал в их создании и не очень понимаешь концепции модели. Помню, в одной далекой южной стране показал я таксистам карту — вот они удивились! Из рук в руки передавали, пытались понять, что за штука такая. Это что, как будто наш город с высоты? Ух ты. И такое бывает. А зачем? Чего только эти туристы не придумают. Понять, что знания неявные, очень просто: они не зафиксированы. Нет ни схем, ни регламентов, ни чеклистов, ничего. Как выполнять работу — передается из уст в уста, уровень зрелости процессов — 2, "фольклор" (первый уровень — "анархия", когда повторяемой деятельности вообще нет, нет процессов). И тут аналитик становится фольклористом. И только собрав достаточно материала может систематизировать его и выявить морфологию волшебной сказки структуру деятельности в предметной области.

Какая-то неделя рекомендаций каналов у меня получается. Вот тут ребята собрали папку каналов про agile, стратегию и системный анализ. Назвали, правда, «Гибкие технологии управления», но темы там шире. Всё про варианты развития аналитика: можно идти в организаторы процессов (читай — agile), можно в продакты или бизнес-партнеры, а там неизбежно придётся столкнуться со разработкой стратегии. На большинство из них я сам подписан и читаю, так что могу уверенно рекомендовать. Добавляйте папку, читайте каналы, набирайтесь новых идей! https://t.me/addlist/pB26PWfXrAFkMWYy

Взгляд на работу с требованиями с точки зрения дисциплины управления знаниями (knowledge managemant, KM) оказался очень любопытным, и объясняющим некоторые вещи. Я-то, так вышло, работал с методами KM, и даже был когда-то членом экспертного совета премии Most Admired Knowledge Enterprise Russia, так что с темой знаком. А вот для аналитиков и архитекторов, на удивление, эта тема малоизвестна. Хотя разговор про архитектуру систем всегда затрагивает вопросы управления знаниями, это у меня один из главный инсайтов с курса про микросервисную архитектуру. Закон Конвея и разделение по командам тоже про управление знаниями — какие знания аккумулировать в команде, а какие выдавать наружу. С точки зрения системного анализа, KM тоже много где проявляется: это и сбор знаний со стейкхолдеров (специально не пишу "требований", потому что правильнее — знаний о предметной области и проблемах, которые мы собираемся решить), и передача знаний в команду (очень часто аналитика называют "единым источником информации о системе", "координатором знаний о системе", а при этом управлению знаниями-то и не учат!). Например, такая вещь, как модель SECI (или модель Nonaka-Takeuchi) объясняет, что для разных стадий работы со знаниями нужные разные методы. Модель вводит различение между неявными знаниями (tacit knowledge, существует только в головах или в навыках людей и часто даже не осознается) и явными, эксплицитными (explicit knowledge, существует в виде отчужденного артефакта: документа, описания, регламента, записей). Если бы все знания были эксплицитными, и задачи разработки требований бы не было, точнее, она была бы сугубо технической. Модель SECI постулирует, что любое знание сначала возникает, как неявное, и передается через социальные взаимодействия: наблюдение, имитацию, практику под руководством. Такая передача знаний требует прямого взаимодействия. Формирующееся в результате знание тоже неявное. Это как раз и происходит в малых командах, отсюда и сопротивление ведению документации. Потому что документация — это эксплицитное знание, и переход требует значительных усилий — экстернализации. Это то, чем часто занимается аналитик — экстернализирует неявные знания. Экстернализированные знания становятся операбельными — с ними можно что-то сделать. Их проще передать от человека к человеку (хоть и с потерями). Их можно анализировать, из можно сочетать и комбинировать друг с другом, вырабатывать новые эксплицитные знания — в частности, из формального описания предметной области и проблемы выводить формальные требования к решению. Крайняя степень формализации знаний — это и есть программный код. Это зафиксированные и готовые к использованию знания, максимально оторванные от конкретного человека. И вот тут возникает интересная вещь — круг замыкается, и происходит интернализация, переход от эксплицитных знаний к неявным. Готовая система становится элементом среды, в которой действуют люди, и способ, которым они решают свои задачи при помощи системы, нигде не зафиксирован. И на следующем витке вновь возникает задача извлечения, экстернализации знаний о реальной практике использования системы. Процесс входит в цикл. (Картинка из статьи Germán Scalzo и Guillermo Fariñas, лицензия CC BY 4.0)

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

Майк Кон — сооснователь Scrum Alliance и эксперт в пользовательских историях — выделяет три категории требований: ➕Известные (которые удалось "выявить", "собрать" или "разработать"); ➕Пропущенные (которые мы могли бы в принципе собрать, но как-то не получилось — мы не спросили, а пользователи про них не сказали); ➕Эмерджентные — которые нельзя было предугадать заранее. Про них не знал ни аналитик, ни сам стейкхолдер — он понял, что ему это нужно, только когда увидел/начал пользоваться системой. Ещё раз: это не то, что мы проглядели, это то, что мы в принципе не могли предугадать. Это принципиальная разница между plan-driven и agile подходами, или даже взглядом на мир. В первом случае мы верим в рациональность, силу разума и познаваемость мира через точно построенные умозрительные схемы. То есть, в конечном счете, — в совершенство мира. Во втором — верим, что мир в целом несовершенен, поведение людей иррационально, знания неполны, а модели дырявы. Но при этом мы не отказываемся от действий в этом несовершенном мире. Вопрос подхода — это вопрос мировозрения, оптимизма и честного взгляда на обстоятельства. И, судя по тому, как каждый раз удивляются адепты рационалистского взгляда — в случае требований стоит признать, что есть требования, о которых никто не может подумать, пока не увидит работающую систему или хотя бы её прототип. Самое интересное, добавляет Кон, — что эмерджентные требования могут оказаться как раз самыми нужными. Отсюда идея — показывать хотя бы что-то, что может вызвать генерацию идей у пользователей. Поэтому первая версия интерфейсов — это не итоговый проект, это стимульный материал для выявления дополнительных требований, для запуска фантазии. И в плане нужно всегда отводить место на эти новые требования.

В английском всё это называется 'requirements elicitation', а оксфордский словарь говорит, что происхождение слова elicit — mid 17th century: from Latin elicit- ‘drawn out by trickery or magic’, “вытянутый обманом или магией". С этим определением я согласен 🧙‍♂ Почему не получается просто спросить про требования? В одной старой статье* приводится три категории проблем с требованиями: ⭐️Проблема объема и границ: — непонятно, где границы решения (где мы остановимся и чего не будем делать); — лишние преждевременные детали (зависаем на них, не успеваем обсудить весь объем); ⭐️ Проблемы понимания: — пользователи не до конца понимают, что им на самом деле нужно. Это они не специально, это проблема неосознаваемого знания (tacit knowledge); — пользователи плохо понимают возможности и ограничения ИТ-систем (добавьте сюда привычку говорить не о проблемах, а сразу о решениях — и вы получите дилетантское мнение, если вовремя не вернете инициативу); — аналитики и разработчики, в свою очередь, плохо разбираются в домене; — аналитики и пользователи говорят на разных языках; — "очевидная" информация пропускается, причём с обеих сторон; — разные стейкхолдеры выдвигвают противоречащие требования; — формулировки "требований" нечеткие и непроверяемые; ⭐️Проблема изменения "требований": — возможно, изменилась внешние условия и, соответственно, потребности; — но, скорее всего, понимание возможностей системы и своих нужд растёт — то есть, вопрос в расширении знаний и осознанности. Сразу требовать полной осознанности от пользователя — слишком круто. Приходится либо ждать, пока он дозреет, либо использовать обман и магию. * Technical Report CMU/SEI-92-TR-012 ESC-TR-92-012, Issues in Requirements Elicitation, Michael G. Christel, Kyo C. Kang, 1992

К вопросу, что мы делаем с требованиями. Я тут написал — "собираем", на что получил справедливое возражение, что нечего там собирать, нет их у стейкхолдеров, по крайне мере обоснованных и четко сформулированных. Не растут требования, как грибы — только возьми и собери. Как сказать лучше? Выявляем? Ну, как будто они скрыты, а мы их делаем явными? Отчасти верно: когда мы исследуем предметный домен и структуру проблемы, мы выявляем объекты и действия, которые в них есть, но про которые специально не говорят, потому что не фокусируются на них. Ну а аналитики делают их явными, в этом смысле, наверное, выявляют. Про техники такого выявления я рассказывал и писал. Ещё вариант: извлекаем. Это скорее про документы, где есть какие-то тексты про предметку и процессы, и в которых, при желании, требования можно увидеть. Но, давайте будем честны: мы требования просто придумываем! Сами, или, если повезло — совместно со стейкхолдерами. Можно этот процесс маскировать словом "разработка" требований (был и такой вариант). Или, чтобы совсем красиво звучало: co-development, или совсем по-модному co-design. И придумал это не Пол Ральф со своими статьями про контрпродуктивность идеи "сбора требований", а задолго до него. Например, Клаус Пол (Klaus Pohl, один из основателей сертификации IREB) ещё в 2007 описал метод COSMOD-RE, где честно говорится: требования и архитектура системы разрабатываются в едином процессе co-development'а. И шаги "разработка целей и сценариев" и "разработка архитектуры" там на одном уровне (на самом деле это единый процесс). Метод, по-видимому, плотно забыт, описания его еле гуглятся, а текстов статей и докладов нет в открытом доступе. Но можно посмотреть на несколько картинок. COSMOD-RE задает 4 уровня: 1. Системы в целом; 2. Функциональной декомпозиции системы (разбивку на компоненты); 3. Распределение софтверных компонент по железу; 4. Уровень развертывания. На каждом уровне происходит этот самый co-development требований и архитектуры, с уточнением деталей, а иногда и с возвратом на более высокий уровень и пересмотром принятых решений. Кажется, на русском про это говорят "прорабатываем требования и решения", или "разработка и анализ требований". Любопытно (и полезно!), что здесь выделено 4 уровня, причем последние 2 захватывают хардвер. Аналитики же, даже системные, обычно в своих абстракциях далеки от размышлений — на чем всё это будет крутиться. На курсе по проектированию интеграций часто вижу, как ломаются абстракции, когда мы начинаем говорить про Кафку, и выясняется, что это кластер и нужно думать про репликацию и вылет машин из кластера. Ну где, скажите, требования, а где кластеры. И хорошо, когда они объединены на одной картинке и в одном методе.