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

В этом году я пошел учиться — прямо по-настоящему, на 2.5 года, в магистратуру. Вот такой неожиданный поворот, хотя, как я вижу по окружению, пошли учиться многие. Коллективное помешательство — видимо, солнечная активность вызывает тягу к новым знаниям. И вот что интересно: все практики и подходы, о которых мы говорили в 2010-2012 годах, которые развивали и проектировали — и тогда это был какой-то невероятный полуподпольный эксперимент — все вот они, в обычном вузовском образовании! Ну ладно, не совсем в обычном, из верхнего перцентиля, но — тут. Например, два года назад я учился в РАНХиГС, и там мы строили CJM. А нынешнее обучение началось с трехдневной "деловой игры", которая на практике оказалось форсайтом (и именно rapid foresight, про который я несколько раз рассказывал в ИТ-сообществе, и который сейчас активно продолжает продвигать Дима Безуглый — собственно, я его с методикой и познакомил). Методику воспроизводят неточно, где-то утерян дух, где-то — смысл, но, тем не менее, это она. Нужно отдать должное авторам — теперь, кажется, форсайты стали общим местом и стандартом для стратегических сессий (кстати, обращайтесь, если что, я их тоже провожу 🖐). А дальше обещают lego serious play и всё такое прочее. Согласитесь, это вам не традиционные лекции и семинары! (Хотя они предусмотрены тоже, но, кажется, их не более трети от всех учебных активностей) И это правильно — учиться нужно через деятельность, и только делая что-то своими руками/головой. Управленцам — анализировать и оценивать ситуации, разрабатывать стратегии и планы по их реализации, программистам — проектировать и писать программы, архитекторам — обеспечивать развитие больших систем, аналитикам — выяснять детали и обозначать пространство возможных решений. И если вместо того, чтобы что-то сделать, вам предлагают послушать, как что-то сделать — это не обучение, а ознакомление с материалом. С другой стороны, без ознакомления тоже не обойтись. Можно сразу выдать задание, ничего особо не объясняя, а потом демонстративно сажать людей в лужу, отмечая недостатки результата. Некоторым ведущим это очень нравится, они называют такое действо "проблематизацией", или "приземлением", или даже "сбиванием короны" — то есть, демонстрацией человеку, что его предыдущие знания и навыки ни на что не годятся. Подразумевается, что человек немедленно всё осознает, и дальше со всей внимательностью будет изучать то, что ему дальше расскажут и покажут. На практике же получается совсем другое: люди начинают защищать свой результат, потому что никому не нравится выглядеть дураком (об этом был прекрасный рассказ на Fail Night на последнем Flow — без записи, естественно). Часто говорят, что не хватило времени или не было чётко поставлено задание. В большинстве случаев это так и есть, и любимая фраза ведущих: "у вас никогда не будет хватать времени и вы никогда не получите точного задания". Это тоже отчасти правда, но уж очень напоминает газлайтинг. Собственно, в этот момент вся ситуация становится токсичной — в большей или меньшей степени, планово или неосознанно, но токсичной. То есть, это манипуляция. В ситуации манипуляции человек тоже учится, но часто чему-то не тому (помните — "выученная беспомощность"? Вот, выучился!) Адепты такого подхода отвечают, что любое обучение — это манипуляция, имея в виду, в первую очередь, мотивацию у детей и подростков. Возможно это и так, но если мы говорим об обучении заинтересованных взрослых, то у них с мотивацией обычно всё в порядке — они же ещё и свои деньги вам принесли, какое ещё подтверждение мотивации вам нужно? (Если мы пытаемся учить взрослых насильно — тогда да, нужны специальные техники). Другой вариант — такие манипуляции — часть культуры той среды, в которой обучающимся придётся потом работать, поэтому нужно научиться их распознавать и обрабатывать в безопасной ситуации. По моим наблюдениям, именно такая культурная среда у нас в госпроектах, и тут, наверное, такая подготовка оправдана. Хотя, на мой взгляд, лучше бы образованию заняться изменением этой культуры, а не её трансляцией.

Пришли дети, увидели открытый draw.io, ой, а что это за стикмены? Слово за слово, нарисовали диаграмму. Вопросы: — содержит ли эта диаграмма элементы UML? — это структурная или поведенческая диаграмма? (или диаграмма взаимодействия?) — какой процесс тут, собственно, изображен?

Сколько вы знаете способов передачи данных на клиент по инициативе сервера? В комментариях к предыдущему посту отмечают, что GraphQL не совсем верно упоминать рядом с Websockets, это вещи разного уровня. Давайте разберемся, и вспомним все варианты отправки данных с на клиент в тот момент, когда их решил отправить сервер. Я насчитал 6 (добавляйте, если знаете ещё): 1. Long polling — обычный http-запрос, но сервер дает ответ только в тот момент, когда у него появились/изменились данные. Если данные не появились до истечения таймаута, соединение разрывается, но клиент тут же его восстанавливает. После получения ответа соединение тоже восстанавливается. 2. WebHooks — по сути, обратный вызов http. Серверу каким-то образом нужно сообщить адрес эндпоинта клиента и код события, по наступлении которого нужно этот эндпоинт вызвать. Сообщить можно через настройки, а можно через специальное API. В терминах языков программирования — это callback. Когда на сервере произойдет событие, он вызовет ваш эндпоинт. 3. WebSockets — отдельный протокол, первоначальное соединение устанавливается через http, в котором клиент передает хедер upgrade, и дальше уже происходит переключение протокола, и общение идёт через websocket — полнодуплексный канал между клиентом и сервером, где они оба могут пересылать друг другу сообщения (текстовые или бинарные). Очевидные кейсы: чат, многопользовательская игра, совместное редактирование документа/картинки. Отличается от других асинхронных способов получения данных тем, что соединение полнодуплексное — клиент может отправлять данные в том же соединении. 4. Server-Sent Events (SSE) — почему-то редко вспоминают, но это штука, похожая на long polling, только сервер может пересылать несколько порций данных сразу в одном соединении. И это тоже http! Клиент при этом указывает специальный тип контента: text/event-stream (если шлет в веб-браузер) и application/stream+json (если шлет в другой клиент, не в браузер). 5. HTTP/2streams — бинарный протокол, на базе которого работает gRPC. HTTP/2 в принципе построен на понятии потока, в котором клиент что-то запрашивает, а сервер что-то шлет в ответ... Так что идея полнодуплексного обмена появляется почти автоматически — почему бы серверу в том же потоке не слать данные по собственной инициативе. 6. HTTP/3, который QUIC — примерно то же, что и HTTP/2 — на уровне использования приложением, все различия внутри: он на основе UDP, а не TCP, что дает ряд преимуществ, в основном в скорости. Подробнее про HTTP разных версий можно почитать тут. В двух словах — борьба идет за число открытых соединений с сервером: в HTTP/1.0 соединение обрывается после каждого ответа сервера, в HTTP/1.1 появился заголовок keep-alive, сохраняющий TCP соединение, в HTTP/2 много соединений TCP от клиента к серверу объединили в одно, а в HTTP/3 вообще перешли на UDP, в котором вообще нет сложного процесса установки соединений. Разобраться со всеми этими технологиями бывает сложновато, поэтому низкоуровневые протоколы пакуют в инструменты более высокого уровня абстракции — типа того же GraphQL или разнообразных API в браузере (streams API, fetch API, WebTransport) — про которые программисты уже не думают, как они внутри устроены, а просто ими пользуются. На самом деле, внутри GraphQL либо WebSocket, либо multipart subscriptions over HTTP (ещё один способ, похожий на SSE — когда мы устанавливаем соединение по http, сервер говорит, что будет отдавать multipart/mixed контент, а потом начинает эти части клиенту отдавать по мере появления/изменения). А стримминг в gRPC работает по технологии HTTP/2 или HTTP/3, это тоже обертка. Что в этом для аналитиков? А вот что: кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими. При высокой интенсивности обмена между системами будет просто открываться канал, в котором они будут обмениваться сообщениями, а уж будут эти сообщения устроены вокруг операций с ресурсами, или вокруг вызова функций, или это будет поток сообщений в стиле event-driven — это на логическом уровне будет разбираться приложение.

Главная проблема у Вигерса — это, конечно, полное отсутствие хоть каких-нибудь слов о проектировании API. Абсолютно ничего. Хотя вся база для проектирования есть, и главное — это диаграммы. DFD в главе 12 (стр. 269) и, ещё лучше — Карта диалоговых окон на стр. 280 (напоминаю, что я даю страницы по изданию BHV 2013 г.). Я такую диаграмму на тренингах обычно называю "схема навигации". Это очень простая диаграмма: прямоугольники — отдельные экраны (или разные состояния одного экрана), а стрелки — переходы с одного экрана к другому. Это очень мощный инструмент, необходимый и для проектирования интерфейсов, и для создания API. С точки зрения интерфейсов мы проверяем все варианты использования — буквально задавая вопрос "а на каком экране происходит этот шаг сценария?" (конечно, нас интересуют шаги, где пользователь вводит данные или дает команду, и те, где система запрашивает пользователя, предлагает выбор, предоставляет информацию или оповещает пользователя о чем-то). Эта же диаграмма в какой-то мере повторяет диаграмму состояний — если у вас изменилось состояние ключевого объекта, то, скорее всего, это изменение инициировано действиями в интерфейсе (мы можем проверить полноту требований через проверку наличия требований/сценариев для всех переходов на диаграмме состояний). Тут же можно задать вопросы про обратные действия и возвраты — на диаграмме они будут видны особенно ясно: если у вас есть тупик, экран только с входящими переходами, это странно. Вы с него никуда не уйдете? В общем, если к каждому экрану приписать состав данных, которые выводится на экране и которые вводятся, а также основное действие пользователя на этом экране и второстепенные — будет сразу понятно, как визуально выстроить экран, и дизайнер скажет вам спасибо! Но эта же информация пригодится вам и для проектирования REST API! Именно REST, т.к. речь идёт о состоянии. Это распространенная ошибка — считать, что в REST нет состояния. Состояние клиента очень даже есть! (И это один из критериев, что вам подходит REST). Просто это состояние локализовано на клиенте, и не хранится на сервере (а только запрашиваются данные для смены состояния, Representational State Transfer). Вот ваша схема экранов и переходов как раз и является диаграммой возможных состояний клиента! И каждый переход — это вызов API. Нужно только к переходу дописать название эндпоинта, параметры и ответ. В таком виде диаграмма представлена в статье Майка Амундсена, про которую я уже писал, и которую, оказывается, давно перевел пользователь Andrei Gordienkov. Тут может возникнуть вопрос — а если изменения происходят на сервере, и должны быть переданы на клиент? Во-первых, как это нарисовать? (Ну, тут я обычно рисую вместо экрана звездочку, и стрелку от неё к нужному экрану, где эти изменения должны быть отображены — состояние клиента изменилось). Во-вторых, что это за вызов? Очевидно, что это уже не REST, а нечто другое — Long Polling, WebHook, WebSockets, GraphQL или gRPC в режиме подписки/стриминга. И всё, считайте, что эндпоинты API у вас уже готовы. Одновременно с дизайном.

Мы уверено преодолели отметку в 7000 подписчиков! Спасибо вам! 🙏🙏🙏Надеюсь и дальше вас радовать смешными и полезными постами. А в комментах к этому посту предлагаю всем знакомиться, и написать — вдруг вам нужна какая-нибудь помощь? Может, вы ищете работу, или наоборот — нового коллегу, или совет, или ментора. Напишите! Нас тут много, возможно вам помогут! Ну и, как я знаю, у многих из вас есть свои каналы — напишите про них, а я потом сделаю общий пост про ваши каналы — пусть у вас тоже будут новые подписчики!

Я знаю, что дошучивать не хорошо, но вчера в пост всё не уместилось — ещё в книге Вигерса есть части, которые будут полезны для лидов или тех, кто хочет им стать. Например, страницы с 20 по 25 помогут вам аргументировать вашу полезность, если у начальства есть сомнения. Зачем вообще нужны эти аналитики?! Вот там перечислены пугалки и вероятные выгоды (см. главу про риски). В основном все пугалки сводятся к разрастанию скоупа и дороговизне исправления ошибок в коде, а не в спецификации. Проверьте, что в вашем случае это действительно так. Стр. 36-40 — обязанности заказчика. Очень интересный раздел. Можете эти пункты вставлять в договоры. Всё равно никто им не следует. Можно зачитывать вслух, чтобы вместе посмеяться с командой за пивом. Или поплакать. Я их даже приведу тут, порыдаем вместе: Обязанность №1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса.Ну допустим. Обязанность №2. Потратить столько времени, сколько необходимо на предоставление и уточнение требований.Уже рыдаю. Обязанность №3. Точно и конкретно описать требования к системе.Началась бульварная фантастика. Обязанность №4. По запросу принимать своевременные решения относительно требований.Фантастика продолжается. Обязанность №5. Уважать определенную разработчиком оценку стоимости и возможности реализации ваших требований.Я уважаю вашу оценку, но нам нужно это вчера и за 1/10 стоимости. Обязанность №6. Определять реалистичные приоритеты требований совместно с разработчиками. Говорю же — нужно вчера. Обязанность №7. Проверять требования и оценивать прототипы. Покажитефинальный дизайн. Обязанность №8. Определить критерии приемки.Вот увижу, тогда скажу — то или не то. Обязанность №9. Своевременно сообщать об изменениях требований. 😭 Обязанность №10. Уважительно относиться к процессам создания требований. См. п. 5. До этого на стр. 33-36 есть "Билль о правах заказчика" — там самое интересное Право №5. Заказчик имеет право изменить свои требования.Вот в это охотно верю. Дальше опять про культуру уважения к требованиям и про утверждение требований (стр. 40-47). Вот тут есть фраза, которую нужно отлить в граните: Оба описанных подхода игнорируют реальность, которая такова, что на ранних этапах работы над проектом нельзя знать абсолютно всех требований и со временем они неизбежно меняются. "Оба описанных" — это позиция заказчика «Ну да, я подписал эти требования, но у меня не было времени их читать. Я доверял вам, ребята, а вы меня подвели!» и аргумент менеджера «Но вы же подписали эти требования, и именно такую систему мы и создаем. Если вам нужно было что-то другое, следовало сказать об этом раньше». Слышите! Сам Вигерс нам сказал, что нельзя знать всех требований заранее! Про это же в главе 17, которая в русском переводе "Утверждение", а на английском — Validation (читайте оригинал!). Как я уже писал, там про рецензирование и проверки. Лидам актуально. Там, к слову, описана та самая "читка" — Вигер называет её "inspection" (а переводчик — "экспертизой"). И ещё есть чеклист на стр. 400, приведу его отдельно. Ну и для лидов уже наоборот — обязательна к прочтению Часть V, где про улучшение процессов и про риски. Впрочем, улучшение процессов у Вигерса дано обзорно, какой-то специфики именно в анализе тут нет, обычный проект изменений. Тут уже и сам Вигерс шутит: * не откусывайте кусок, который не сможете прожевать * получайте максимум удовольствия от малых побед (больших побед у вас будет немного) * давите мягко, но постоянно * концентрируйтесь (команда разработчиков может выполнять только одно улучшение за раз). * ищите союзников (растите их; благодарите их; награждайте их) А главный тезис, про который нужно всегда помнить: при совершенствовании процессов производительность сначала ухудшается, и только потом улучшается выше предыдущего значения (кто сказал, что она улучшится?) Ну и про риски — они у Вигерса перечислены, но в принципе все укладываются в две категории: * сделали не то, что нужно * не сделали то, что нужно Вот такое дополнение. Поздравляю, теперь вы готовы к роли лида аналитиков!

Написал супер-краткий конспект книги Вигерса. А то тут ходит конспект на 70 страниц, и люди просят краткое изложение краткого конспекта. Итак, специально для тех, у кого нет времени читать ни 700, ни 70 страниц, циничный конспект: Часть I. Требования к ПО * Схема на стр. 7. Уровни требований. В реальности вы будете разрабатывать только функциональные требования. Можно почитать стр. 8 и 9, там расшифровка текстом (8 — бизнес-требования и юзер-стори, 9 — функциональные). Рис. 1-4 на стр. 16 — показано, какие есть этапы в работе над требованиями. Перевод диаграммы очень плохой, приведу свой: Инженерия требований состоит из разработки требований и управления требованиями. Разработка требований состоит из этапов выявления, анализа, спецификации и валидации. Прочтите расшифровку диаграммы на стр. 17, если что-то непонятно. Стр. 42-46 — плач о согласовании требований. Совет Вигерса про участников, которые морозятся, на стр. 45, оцените его применимость: В позитивном ключе упомяните, что вы в курсе, что они пока не одобрили требования, но проект движется вперед с этими требованиями в качестве базовых, чтобы не задерживать работу. Сообщите им, что если они хотят что-то изменить, для этого есть соответствующий процесс. В сущности, вы действуете так, как будто заинтересованное лицо согласилось с требованиями, but you’re managing the communications closely. Схема на стр.51 показывает главную идею: не ждите, что все действия по разработке требований удастся выполнить последовательно и за один проход. Выявление, анализ, спецификация и валидация будут происходить одновременно. Часть II. Разработка требований. * Бизнес-цели, концепция продукта — никого не интересует, почти никто не пишет. * Границы проекта. У проекта должны быть границы. Есть что-то, чего мы делать точно не будем. Контекстную диаграмму на стр. 104 никогда не рисуют. * Классы пользователей — скорее всего, у вашей системы один класс пользователей — ваши пользователи. Или ваш продакт оунер. * Методы выявления требований — реально вы будете делать только интервью. Стр. 138, цитирую: установите контакт, следите за границами проекта, заранее подготовьте вопросы и предварительные модели, предлагайте идеи, слушайте активно. * Поиск упущенных требований — стр. 136. * Варианты использования — разве их где-то ещё пишут? Если не пишете — пропускаете. Или читаете стр. 171-193. * Бизнес-правила — разве их когда-то вообще писали? И вы не будете. Пропускаете. Ну или читаете главу 9. Шаблон SRS — единственное, что вам нужно из этой части. стр. 223-234. * Критерии качественных требований — забейте, это никого не волнует и никто не проверяет. Формулирование и проверка полноты требований, стр. 243-254. Ну тоже полезно. * Моделирование, гл. 12. Много разных диаграмм. Реально вам нужна только Sequence Diagram. Но у Вигерса она не описана, ищите где-то ещё. * Требования к данным, гл. 13 — вам это не нужно. Максимум, нужно понимать, как составлять JSONы, но этого у Вигерса тоже нет. * Атрибуты качества ПО — гл. 14. Это "нефункциональные требования". Если вы их не пишете — можно пропустить. * Прототипирование — скорее всего, его у вас нет. Пропускаете. * Приоритеты, гл. 16. Любопытно, но скорее всего у вас приоритеты требований назначаются по принципу "кто ближе к руководству" и "кто громче всех кричит на совещаниях". * Рецензирование, в гл. 17 — ну, почитайте, если оно у вас есть. Это скорее для лидов. * Повторное использование требований, гл. 18. Не бывает. ЧАСТЬ III. Всё то же самое, но для отдельных видов проектов. Найдите свой. Часть IV. Управление требованиями . Вы реально ведёте учет разных версий требований, отслеживаете изменения, состояния и связи требований? Или просто пишете один раз документ, отдаете его, и потом никогда его не переделываете? Если так — можно пропустить. Часть V — забейте. Риски вообще никто никогда не анализирует и не управляет. Итого, нужно просмотреть несколько страниц из первой части, потом шаблон SRS и раздел про тексты. Вот и всё, не благодарите. (Если что, это шутка. Но в каждой шутке, как мы знаем, есть доля истины...)

Хорошую картинку нашел у bytebytego — сразу понятно, где какие стили API обычно используются. Вот только в наших реалиях SOAP — это не Legacy, а государственные сервисы. И сбоку ещё брокера сообщений нужно пририсовать, с потоками из соседней системы, а снизу слой данных с ETL-процессами.

Channel photo updated

Про концепции продуктов. Для кино есть логлайн, для [ИТ-]продуктов есть формула, в которой отражены примерно похожие вещи. Состав концепции: * описание аудитории — для кого мы делаем продукт или решение? Это могут быть люди в определенной ситуации, или сотрудники с какой-то ролью, елси продукт внутренний. * задача, которую решают эти люди — чего они хотят или что им нужно делать по работе. * препятствие — что мешает им выполнять эту задачу * что мы для них делаем (какую систему создаем) * как они будут решать свою проблему, когда система будет готова * за счет чего проблема будет решена? (какое ключевое свойство нашего решения) Можно ещё добавить анализ альтернатив: в чем отличие от других способов решения и в чем выигрыш. В виде формулы это выглядит так: Для <описание аудитории>, которые хотят <описание задачи>, но не могут, потому что <описание препятствия>, мы делаем <тип решения>, которое поможет им <описание решения проблемы>, за счет того, что <ключевое свойство решения>. Примеры: "Для системных аналитиков, которые знают много отдельных техник, но не могут их сложить в единый процесс, потому что в книгах описаны отдельные свойства, нотации и инструменты, но не описана логика их применения, мы делаем курс по разработке требований, который помогает выстроить четкую последовательность действий за счет того, что дает последовательный алгоритм выявления требований и проектирования решения". Ладно, это шутка. Или нет. Вот очередной курс будет в конце октября. Давайте посмотрим пример ИТ-систем: "Для клиентов с открытыми брокерскими счетами, которые осуществляют мало операций, потому что не понимают, что им покупать, мы создаем сервис готовых стратегий, к которому можно будет подключиться, и в нём уже будут подобранные акции и облигации, стоп-ордеры и тейк-профиты, так что клиентам после присоединения к стратегии и делать ничего самим не придётся". "Для сотрудников подразделения KYC, которым нужно проверять действительность паспортов согласно требованиям 115-ФЗ, но они не могут это сейчас делать, потому что сервис МВД по проверке паспортов перестал работать, мы делаем интеграционное решение, которое позволит отправлять запрос через СМЭВ-4 в автоматическом режиме по ключевым событиям, что позволит сотрудникам не проверять паспорта вручную, а только мониторить этот процесс и получать оповещения о недействительности паспорта." "Для студентов, которые хотят проходить курсы от ведущих российских вузов, а не в своем, где препод толкает чушь, но не могут, потому что живут в других городах или не смогли в эти вузы поступить, мы делаем онлайн-платформу с открытыми курсами, где можно будет пройти курс и даже зачесть его в своем вузе." Зачем составлять концепцию? Как минимум, чтобы все согласились и были на одной волне. Концепция задает основных потребителей и ключевую функцию. Из неё следуют все остальные решения и приоритеты. Вот например, в последнем варианте реальная концепция была совсем другой: "Для администраций региональных вузов, которые хотят обеспечить высокое качество непрофильных курсов и выполнить показатели по числу сетевых программ, мы делаем платформу с онлайн-курсами, на которой вузы смогут заключать сетевые договоры, зачислять своих студентов на курсы и отслеживать их успеваемость" Чувствуете? Вообще всё другое: и целевая аудитория, и цель, и основные функции (вместо фокуса на удобстве обучения — фокус на удобстве заключения и администрирования договоров). Такую концепцию можно согласовывать с заказчиками, и дальше уже развивать и детализировать. Следующим шагом это всё превращается в развернутую таблицу, страницы на две, где кроме перечисленных выше параметров будет чуть более развернутое описание: как сейчас и как будет, измеримые показатели положительных изменений, сроки актуальности проекта и описание окружения (а то и первичный набросок архитектуры).

Недавно слушал отличную лекцию про сценарии сериалов и про особенности кинопроизводства. Я давно интересуюсь способом организации производства в других отраслях, и кино, мне кажется, во многом похоже на ИТ (ну или ИТ на кино, всё-таки киноиндустрии уже больше ста лет, а ИТ всё ещё молодое 😉). Вот смотрите: Всё начинается с логлайна. Это описание идеи фильма или сериала в 1-2 предложениях. По нему продюсеры принимают решение — брать сценарий или не брать. Структура логлайна: герой — проблема — цель героя — конфликт. А, каково? В принципе подходит для описания концепции ИТ-продукта — для него есть своя формула, похожая. Идеи фильмов делятся на high-concept и low-concept. High-concept — это такая идея, которой ещё не было, и которая захватывает сразу с логлайна. В нашем понимании — прорывной стартап. Low-concept — обычная идея, знакомая всем, из которой, тем не менее, может что-то получиться за счет каких-то особенных мелочей или общей синергии. После логлайна (или вместе с ним) пишется синопсис. Это — короткое описание всей истории, на 1-2 странички + особенности производства + формат, жанр, аудитория, бюджет места съемок, продолжительность и т.д. Короткий, но основной продающий документ. В ИТ это концепция проекта. У нас на курсах, например, на базовом "Разработка требований в ИТ-проектах" используется шаблон как раз на 2 страницы. После синопсиса иногда пишется тритмент — это расширенная версия всего сюжета, но ещё не сценарий. Он обычно 5-10 страниц, но может быть и больше. В тритменте вся история рассказывается в хронологическом порядке, но со стороны — тут ещё нет художественных приемов, последовательности, в которой историю увидит зритель, и нет диалогов. Дальше идёт поэпизодный план — он уже имеет размер 20-30 страниц, выстроен по сценам и актам, и в том порядке, в котором их увидит зритель. Диалогов в нём всё ещё нет! Ну может только ключевые реплики. Зато есть все сюжетные повороты. В поэпизодном плане проверяется структура истории, пересечение линий персонажей и их взаимовлияние, и продумываются решения отдельных сцен — мы в этой сцене хотим, чтобы зритель понял вот это, а как мы это покажем? Как эта сцена двигает сюжет или раскрывает персонажей? В большой ИТ-системе это соответствует схеме навигации с описанием экранов (но без дизайна!) И уже после этого пишется сценарий со всеми диалогами (причем часто сюжет придумывает один человек, а диалоги пишет другой, вот это разделение труда!). Диалоги пишут вообще в последний момент, и могут переписать прямо на площадке. Это как сценарии вариантов использования и конкретные объекты данных — самый детальный уровень проработки. Когда сценарий готов и съемочная команда собрана — проходит классная вещь: режиссерская читка. На читку собираются представители всех цехов (операторы, декораторы и реквизиторы, гримеры, художники по костюмам, осветители, каскадеры, специалисты по спецэффектам и графике, и т.д. И продюсеры, конечно). Всем раздают по своему экземпляру сценария, режиссер его читает и все делают пометки — что когда им делать, и задают вопросы. Сценаристы сидят в сторонке и отвечают только когда их спрашивают. Каждый цех проверяет и озвучивает детали, относящиеся к ним. Реквизитор спрашивает: — А вот у вас герой выходит из здания, а сумка при нём? — Какая сумка? — Ну, две сцены назад у него была кожаная сумка, она сейчас с ним? Или костюмер говорит: если вы хотите в этой сцене героя облить супом, то нужно будет минимум 3 экземпляра его костюма, а лучше 5. Дрессировщик говорит: тут у вас обезьяна со злостью стучит по решетке. Это можно, но потом ей нужно будет недели две успокаиваться, имейте в виду. Продюсер говорит: тут у вас гонки, но это очень дорого, давайте что-то другое. И сценарист начинает переделывать или уточнять сценарий после всех замечаний. Мне кажется, это очень классная практика, и её нужно повсеместно в ИТ внедрять. Вот именно в виде синхронной читки документов всеми цехами. Вообще на планировании спринта именно это должно происходить, но на практике, кажется, идея потеряна, а стоило бы на всех проектах ввести!

Публикую презентацию с Flow про UML. Нужно тему сворачивать, а то уже, говорят, приклеилась слава, что "Куприянов всем говорит, что UML умер". Так вот — UML жив, и неплохо себя чувствует. Прямо по Жванецкому: "И что смешно — министр мясной и молочной промышленности есть и очень хорошо выглядит". Или как в "Кин-дза-дзе": "Побойся неба! ПЖ жив! И я счастлив!" (да, я бумер, и мемы у меня бумерские). Так вот, что смешно: UML жив, и хорошо выглядит. Собственно, об этом в презентации. Основные тезисы: 80% опрошенных используют UML (хоть какие-то элементы из него). Впрочем, эта оговорка почти незначима — опрос показывает, что если уж вы начали использовать UML, то скорее вы используете в целом что-то похожее на стандартные диаграммы, а не отдельные элементы. 84% диаграмм — формальные. Наброски и "просто картинки" системные аналитики не рисуют. Да, аналитиков в опросе было 59%, 19% — архитекторов, 13,5% — разработчики. Разработчики меньше всего пользуются UML. Архитекторы — и так, и так. Аналитики — скорее будут рисовать UML, а не что-то другое. С разработчиками есть и ещё одна проблема — они даже говорить о UML не хотят, так что сложно было найти респондентов. Что ещё: аналитики в основном работают в финтехе (больше всех), в екоме и гос.проектах. И в других отраслях россыпью, почти столько же, сколько в финтехе. Большинство работает в крупных или средних компаниях — почти 85%. Там же чаще используют UML. Если вы фрилансер или работаете в маленькой компании, UML у вас скорее не используется. Почти 42% работают в продуктовых компаниях (так что неверен тезис, что в продуктах нет системных аналитиков), 25% — во внутренней автоматизации. К диаграммам: создают часто (в этот день, на днях, в течение этого месяца...), меняют тоже часто, почти все диаграммы сохраняют ("это часть документации!"). В основном рисуют, чтобы зафиксировать требования или презентовать решение/архитектуру. Соответственно, на диаграмме будет архитектура или схема интеграции. Поэтому неудивительно, что самая популярная диаграмма — Sequence Diagram. Её используют вдвое чаще, чем любую другую. Удивительно, что на втором месте по частоте использования — Use Case Diagram, а за ней — State Machine и Activity. Остальные используют реже. Применение agile никак на использование UML не влияет. От стажа работы использование UML зависит отрицательно: чем больше стаж, тем меньше применяют UML (корреляция небольшая, -0.26, но отрицательная). Кроме UML используют BPMN (примерно треть опрошенных), C4 (10%), Archimate (21 человек из 275), а ещё ERD, IDEF0, DFD и EPC — но очень мало. Вот такие основные выводы. Если есть идеи, что ещё можно было бы проверить на этих данных — пишите, посмотрим.