—
Офлайн-встреча об AI для предпринимателей: https://xn--r1a.website/aioftheday/1331

Многие рисуют диаграммы в Draw.io и радуются. А я что-то чем дальше, тем реже пользуюсь этим инструментом.
Попытался сформулировать почему.

🔸 Что такое архитектурная диаграмма? Это модель, представление, форма описания какого-то аспекта будущего или существующего решения.
Диаграммы мы обычно рисуем в какой-то нотации, которая задает язык, понятия и смыслы, с помощью которых мы формируем модель.
С помощью выразительных средств выбранной нотации мы формулируем набор утверждений, например:
- Наша система состоит из 5 сервисов, которые называются вот так
- Нашей системе для работы необходима Kafka, которая обеспечивает функционирование топиков, через которые наши сервисы обмениваются данными
- Сервис "А" взаимодействует с сервисом "Б" по интерфейсу "И"
- Сервис "С" использует СУБД "У"
ну и так далее.

Да, нарисовать такую схемку в Draw.io легко и просто почти в любой нотации. А дальше начинаются многочисленные "НО".

🔹 Во-первых, Draw.io - это просто рисовалка квадратиков и стрелочек. Она не контролирует корректность утверждений с точки зрения выбранного языка. Запросто можно нарисовать, что интерфейс "И" реализует Сервис "Б", и ничего за это не будет. Отсюда два возможных последствия - либо архитектор сам строго и внимательно следит за корректностью диаграммы с точки зрения нотации, либо строгость и точность диаграмм будет "плавать", и как следствие, будет снижаться точность принятых решений, ведь неточности и расплывчатости каждый "читатель" будет трактовать по-своему. И что-то мне подсказывает, что второй кейс будет встречаться существенно чаще.

🔹 Во-вторых, такие модели просто невозможно поддерживать в сколько-нибудь сложных проектах. Ну вот, нарисовали мы такую диаграммку, обсудили с коллегами и решили, что нужно сделать разбиение чуть-чуть иначе, функции сервисов чуть-чуть по другому разложить. Теперь нужно это решение отразить в модели. Хорошо, когда у нас одна, ну две диаграммы. А если их десятки, а то и сотни, причем один и тот же элемент системы в разных видах представлен на разных диаграммах? Конечно, можно на это забить, и поменять только ту пару диаграмм, которые обсуждали, но дальше это приводит к тому, что накапливается большое число диаграмм непонятного статуса: невозможно понять, отражают они реальность или нет?

По итогу, я для себя выбрал два подхода к моделям, и ни для одного из них Draw.io не подошел:
- Нестрогие диаграммы, картинки, схемки и прочие наброски, которые делаются "в моменте", для текущих обсуждений и не поддерживаются в дальнейшем.
Тут нужен инструментарий максимально простой, легковесный, доступный. Чаще всего я использую легковесные рисовалки типа Excalidraw или yEd. Попытки использовать в этом качестве Draw.io не увенчались успехом, чтобы сделать даже простенький набросок нужно очень много всего нажимать и корректировать.

- Строгое моделирование для документирования решений и отслеживания изменений. Делается в специализированных моделерах, которые контролируют нотацию, отслеживают представления, в которых используются элементы модели.
Вносить изменения в модель может быть трудоемко, поэтому все изменения вносятся после того, как ключевые моменты уже обсуждены и приняты на уровне набросков. В качестве моделера Draw.io использовать не получается, каждая диаграмма - сама по себе. Тут я использую что-то вроде Archi, Visual Paradigm, Sparx EA, для таких инструментов диаграмма - это лишь интерфейс для работы с моделью.
#инструменты

Всем привет!

Я сейчас повторяю одно исследование про диаграммы (в частности, UML), и прошу вас принять в нем участие. Что именно я воспроизвожу: в 2014 году исследователи из Трирского университета проводили опрос про использование диаграмм, эскизов и набросков при разработке и проектировании ПО в Германии и США. Я взял их опросник и перевел на русский: https://forms.gle/zU7PncWsWc9u3cXZ6

Я был бы вам очень признателен, если бы вы прошли его. Это займет буквально 5-7 минут. В опросе у германских исследователей приняло участие 390 респондентов, и я надеюсь, мы сможем собрать не меньшее по мощности исследование. В результате мы точно узнаем — кто и как использует диаграммы при разработке ПО.

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

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

Итоговые результаты опубликую у себя в канале и здесь тоже обязательно продублирую.

Пост согласован с @mxsmirnov

Промежуточные итоги по опросу:

164 ответа (надеюсь, наберем ещё)
47% — системные аналитики, 24.4% — архитекторы, 16.5% — бизнес- или фуллстеки.
Почти все из средних (37,2%) или крупных (48,8) компаний, почти все из России.
По отраслям: 38,4% — финтех(!), 11,6% — ритейл, 11% — госпроекты, 9,1% — автоматизация производства.
Проекты в основном крупные: от 11 человек и выше (суммарно 58,5%), и 33,5% — от 4 до 10 человек.

Теперь самое интересное:
🔹 67,1% составляли диаграммы буквально на днях или в этом месяце, 10,4% — прямо в течение дня, когда проходили опрос.
🔹 88,4% вносили несколько изменений в диаграмму после создания(!)
🔹 Суммарно потраченное время на диаграмму: несколько часов (43,3%) или даже дней! (11,6%). За час уложились 34,8%.
🔹 При этом в основном над диаграммой работает 1-3 человека (51,2% работают в одиночку).
🔹 Срок жизни диаграммы в основном около года (34,8%) или больше (25,6%), и здесь впервые значимая величина ответов "не знаю" (10,4%)

Диаграммы в основном скорее формальные, но не идеально формальные.
Чисто UML-ных диаграмм около трети, с некоторыми элементами — больше половины. Совсем без UML — 18,4%

Для чего рисуют (только ответы >50%):
➡️ Зафиксировать требование
➡️ Презентовать решение
➡️ Объяснить задачу
➡️ Спроектировать архитектуру
➡️ Проанализировать требования

Что чаще всего описывает диаграмма:
➡️ Архитектуру
➡️ API / интеграцию

Понятно, что с большим отрывом лидирует Sequence Diagram: более 70% ответов, следующие за ней — Use Case (45,7%) и State Machine (43,9%). Совсем не используют UML 6,7%.


Средний возраст респондентов — 35 лет, средний стаж — 5 (правда, есть выбросы на 20, 25 и 30 — видимо, на таких сроках уже пятилетками считают, детали смазываются 😂).

Корреляции показателей пока не считал, там должно быть интересно.

Ещё очень интересные комментарии — спасибо огромное всем, кто развернуто написал!


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

⭐️ Большинство аналитиков рисуют диаграммы, но многие не для того, чтобы разобраться или что-то спроектировать, а потому, что в документации есть такой раздел. Некоторые даже не знают, куда эта документация дальше пойдет. Такие дела.

⭐️ UML жив, тут даже сомнений нет. Но жив он частично. И используется совсем не так, как был придуман. От всего UML осталась диаграмма последовательности (и она ого-го как используется!), диаграмма вариантов использования (вот это меня удивило, думал, её мало кто использует) и диаграмма состояний. При этом сиквенс в основном фиксирует уже спроектированное решение — тут, конечно, нужен корреляционный анализ, но пока кажется это так.

⭐️ С другой стороны, почти 20% живут без всякого UML, и им норм.

⭐️ Лично меня удивила популярность диаграммы юскейсов — правда так много людей её используют? А зачем?

В чём результаты опроса сошлись с экспертами индустрии:
Sequence diagrams, the only good thing UML brought to software development. Это статья от создателя mermaid.js. Там и про смерть UML с разных позиций, и про пользу сиквенсов, и про то, как их использовать. С цитатами типа "The reward of the clarity of sequence diagrams is worth the pain and boredom of learning all the others at university" и "Sequence diagrams are the only type of diagrams I use anymore."

Статья классная, попробую перевести её, как будет время.

А итоговый вывод: UML — как латынь для некоторых наук. Мёртв-не мёртв, а лучше знать хотя бы основы и понимать, как его правильно применять сейчас. Lingua Franca для разработки.

Красивое пошаговое визуальное объяснение как работает алгоритм Raft для достижения согласованного состояния распределенных систем.
https://thesecretlivesofdata.com/raft/
#distributed #raft

Не удержался, вступил в холивар про хореографию и орекстрацию https://xn--r1a.website/c/1120099288/159035

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

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

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

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

ArchDays

1 ноября пройдет конференция ArchDays. Мы продолжаем отбор выступлений.

Темы выступлений:
- Процессы проектирования
- Практики проектирования
- Инструменты проектирования
- Обучение архитектуре
- Собственная разработка

Как и прежжде есть желание сделать упор на практическую деятельность: порешать архитектурные кейсы, провести архитектурную Ката, собрать архитектурное видение новых концепций архитектуры.

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

Ссылка: https://archdays.ru

Если кого-то хотите увидеть на конференции, пишите в тред, отправлю персональное приглашение.

Увидимся на ArchDays!

Репост приветствуется :)

📖 В последнее время меня что-то потянуло на шпионские романы 🕵️. Нет, не про Джеймса Бонда и всякие технические ухищрения. А про тайный сбор информации, секретные встречи, агентурные сети, поддельные паспорта и обмен сообщениями, при котором ни получатель, ни отправитель не знают друг друга, и все такое.

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

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

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

Значит ли это что всегда нужно проектировать системы как агентурные сети? Конечно же, нет. Все, как принято говорить у архитекторов, зависит от контекста 😆😆😆.

#метафоры

Чем круче джип - тем дальше бежать за трактором

У любой архитектуры есть пределы развития. Как бы хороша ни была архитектура, со временем она устареет и систему придется заменять полностью.🏗️

🚜Чем более продуманная и хорошо проработанная архитектура у вашей системы, тем дольше система остаётся в строю и продолжает приносить пользу, адаптируясь под изменения окружения, железа, требований и т.п.🚚

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

Вот так вот...

Про принятие архитектурных решений
#мысливслух

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

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

Если кажется, что если есть выбор, то, скорее всего, какие-то требования и ограничения просто еще не выявлены. И вот это, как по мне, самая сложная часть работы архитектора. Принять архитектурное решение таки нужно, но в условиях недостаточных знаний о реальных требованиях и ограничениях невозможно сделать это обоснованно, Приходится опираться на ненадежный фундамент - опыт, экспертное мнение и ощущения в особо чувствительных частях тела. Обосновать такое решение сложно иначе, чем "я художник, я так вижу". Некоторые прячут это за более красивыми формами "это отраслевой стандарт", "все так делают", "у меня 50 лет опыта", но сути это не меняет.

снова #мысливслух

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

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

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

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

Но та ли эта сила, которую мы ждем от архитектора?

А вот и запись доклада подъехала

Выложили запись доклада Романова Бориса на тему «Роль аналитика в процессе создания сложных информационных систем»

В докладе Бориса Романова, выступавший на конференции Systems Education, подчеркнул важность аналитика в балансировке между требованиями заказчика и возможностями разработки. Он также описал различные модели и инструменты, используемые аналитиком для моделирования, поведения системы и предметной области, что помогает в создании эффективных информационных систем.

Тайм-кол доклада:
00:00 О себе
02:34 Разработка сложных систем
08:17 При чём здесь аналитика?
09:53 Информационные системы — это способ изменить мир
13:17 Набор связанных моделей
16:15 Моделирование ожидаемых изменений в мире
20:59 Закон Голла
21:31 Моделирование полезных инструментов: Story Mapping
22:48 Моделирование поведения системы
27:42 Моделирование предметной области
30:18 Инструментарий
31:40 Моделирование в процессе: Создание MVP
33:38 Непрерывное развитие системы через моделирование
34:18 Экспресс оценка изменений на основе изменения моделей
35:39 Заключение
36:41 Ответы на вопросы

Посмотреть можно на нашем YouTube-канале

#вебинар

#мысливслух
продолжение. Начало тут

Если продолжить эти рассуждения, то становится понятно на чем базируется "сила компетенции архитектора".

Чтобы находить хорошие решения, у архитектора, во-первых, должен быть в голове широкий арсенал возможных технический решений, из которых он будет выбирать подходящее решение. Не помешает также навык комбинирования новых решений из готовых элементов или их синтеза на основе каких-то методов и принципов (тот же ТРИЗ). Большой арсенал позволяет надеяться, что при выборе решения, подходящего к конкретному случаю, будут рассмотрены действительно разнообразные варианты, а не притянуты за уши самые распространенные варианты.

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

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

Т.е. базис, фундамент архитектурной работы - это арсенал решений + знание интересов, которые нужно учитывать

И, соответственно, становится понятным трек развития компетенции ИТ-архитектора.

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

Во-вторых - накопление подходов, паттернов, приёмов для решения типовых задач. Уверяю вас, лучше тратить свою творческую энергию на создание действительно уникальных, нетипичных решений. А для решения задач, уже ставших типовыми, обычными, стандартными, банально для экономии времени нужно использовать обычные, типовые, стандартные решения. Брокеры сообщений для асинхронной коммуникации. Базы данных - для хранения данных. API для синхронной коммуникации. Какой именно брокер, какая именно СУБД - это уже вопрос из предыдущего пункта, как говорится "зависит от контекста" :-)

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

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

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

Upd. @GKruglov верно подметил, что есть нулевой уровень, без прохождения которого восхождение по треку будет крайне болезненным и травмоопасным.

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

Архитектура архитектуры (физика явления)

С точки зрения физика архитектура объясняется просто.)

— Система имеет некоторую энтропию (мера хаоса).
— Эта энтропия тем выше, чем сложнее система, то есть чем больше система содержит элементов.
— Высокая энтропия порождает высокую неопределённость. Мы не можем предсказать, как поведёт себя система в дальнейшем, и чего нам ждать от неё.
— Устранить риск можно, получив информацию об элементе системы. Чем больше информации мы имеем, тем меньше у системы шансов «взбрыкнуть».
— Однако для полного контроля над системой нужна вся информация об её элементах и об элементах, с которыми система взаимодействует. Это трудно достижимо.
— Решение: связываем элементы системы, подчиняем их нашим правилам. Чем меньше у элементов степеней свободы, тем предсказуемее их поведение.
Получившийся набор правил нарекаем архитектурой.
Если система реализует архитектуру, то её энтропия снижена и вместе с энтропией смягчены риски.

Ну а архитектор в этом случае — борец с энтропией.)

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

Мне же видится, что все подходы - это проявления встреченного когда-то в книге по объектно-ориентированному проектированию простого принципа "непрерывности" кода.

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

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

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

Выделение ограниченных контекстов в DDD и разбиение кодовой базы на части по контекстам тоже, в общем-то, базируется на этом принципе, но идет еще немного дальше. Грамотно построенные границы контекстов ограничивают распространение изменений не только кода, но и требований. Теоретически, изменения в одном контексте не должны бесконтрольно расползаться по соседним контекстам и, соответственно, не затрагивать соответствующую кодовую базу. Хотя, честно говоря, вблизи такого идеального разбиения я пока не встречал 😉.

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

Вот смотрите:

Всё начинается с логлайна. Это описание идеи фильма или сериала в 1-2 предложениях. По нему продюсеры принимают решение — брать сценарий или не брать. Структура логлайна: герой — проблема — цель героя — конфликт. А, каково? В принципе подходит для описания концепции ИТ-продукта — для него есть своя формула, похожая.

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

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

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

Дальше идёт поэпизодный план — он уже имеет размер 20-30 страниц, выстроен по сценам и актам, и в том порядке, в котором их увидит зритель. Диалогов в нём всё ещё нет! Ну может только ключевые реплики. Зато есть все сюжетные повороты. В поэпизодном плане проверяется структура истории, пересечение линий персонажей и их взаимовлияние, и продумываются решения отдельных сцен — мы в этой сцене хотим, чтобы зритель понял вот это, а как мы это покажем? Как эта сцена двигает сюжет или раскрывает персонажей? В большой ИТ-системе это соответствует схеме навигации с описанием экранов (но без дизайна!)

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

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

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

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

И сценарист начинает переделывать или уточнять сценарий после всех замечаний.

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

Годная статья про GIN индексы в #PostgreSQL
https://pganalyze.com/blog/gin-index

Давно хотел разобраться как оно работает, да все руки не доходили. Оказалось, что все не так уж сложно. Но интересно.
Прямо вспомнились 1990-2000-е годы, Cognitive Technologies, Электронный Архив (!) Евфрат, организация индекса в иерархической СУБД НИКА...