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

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

Всё начинается с логлайна. Это описание идеи фильма или сериала в 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, Электронный Архив (!) Евфрат, организация индекса в иерархической СУБД НИКА...

Имеем: Система А обращается к системе B, которая состоит из N экземпляров с отдельными урлами (B1, B2, B3 и т.п.)
Если мы точно знаем, на каком экземпляре обрабатывается запрос, то можем обращаться напрямую к нужному экземпляру, например A -> B3.
Но если точно не знаем, то есть система M, которая по параметрам запроса умеет определить правильный экземпляр B и адресовать запросу туда, куда нужно. Т.е. запрос идет так:
A —[запрос]—> M —> {B1 | B2 | B3 .... }. И, соответственно, есть накладные расходы на вычисление правильного экземпляра, т.е. такой запрос, по идее, должен выполняться дольше, чем прямой.

Однако, если верить замерам времени выполнения на стороне системы А, то для одного (!!WTF??) из экземпляров B ситуация ровно обратная - прямые запросы выполняются примерно на 100 мс дольше чем через промежуточный маршрутизатор. Для остальных экземпляров ситуация обратная (т.е. ожидаемая).

Почему может быть такой эффект?
Накидайте гипотез, будем проверять.

Вдруг вы еще не слышали - с 14 по 18 октября пройдет онлайн-конференция Podlodka Techlead Crew, посвященная вопросам проектирования надёжных систем.

Мне лично показались потенциально интересными:
- стартовый доклад про ключевые архитектурные принципы обеспечения надёжности (Александр Поломодов (Т-Банк) и Олег Бондарь (Яндекс) )
- доклад про фичетоглы от Николая Тимонина. Тема вроде бы уже не новая, но интересно послушать прикладной опыт.
- Подкупает название доклада Александра Агейченко «Надежный как кирпич» и цифры 99.9999% в описании.
- Интересно послушать рассуждения Филиппа Дельгядо про надежность взаимодействия сервисов, на которую заметно влияет кафка между ними.

Да, честно говоря, всё бы послушал, если удастся выбрать время :)

Если тоже соберетесь - то организаторы подвезли промокод на скидку в 500р : techlead_crew_7_SeusjW

— — — — — —
https://podlodka.io/techcrew

Что такое Eventual Consistency и как с ней бороться.

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

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

Хотел коротко, не получилось, пришлось освоить telegraph.
Продолжение тут https://telegra.ph/CHto-takoe-Eventual-Sonsistency-i-kak-s-nej-borotsya-11-09

Случайно занесло на #softweekend. Спасибо родной компании за билет.Глоток свежего воздуха социализации после заточения удаленки ;) Доклады, правда, послушать почти не получается пока, зато получается много потрепаться 😉. Если кто-то ещё из подписчиков тоже тут - заходите пообщаться.

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

Больше всего голосов набрал вопрос "как из разработчика стать архитектором", так что начнем с него.

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

Я старался покороче, но все равно получилось длинновато. Я не верю, что кто-то будет читать лонгрид, поэтому будет несколько постов.

Поехали!

Итак, "я разработчик, хочу расти в архитектора, куда смотреть, что изучать?"

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

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

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

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

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

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

Или другая, не менее частая история.

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

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

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

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

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

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

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

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

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

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

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

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

Подытоживая, я бы рекомендовал начинать путь к архитектурной работе со следующих шагов:
1. Прочитать несколько книг, расширяющих мышление за границы технических вопросов.
Мой список must read:
- Цель. Э.Голдратта.
Если зайдет первая - то прочитайте 2 и 3 части, они тоже интересные. Но 1 - обязательно.
- Искусство системного мышления. О'Коннор Дж., Макдермотт И.
- Антихрупкость, Н.Талеб

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

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

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

А параллельно накапливать технические скиллы и опыт. Старайтесь, изучая или читая про очередной фреймворк или СУБД, обращать внимание не только какой он сам по себе быстрый, надежный, удобный и т.п. а насколько он полезный для решения тех или иных задач. В чем сильные или слабые стороны, по сравнению с аналогами. Пригодится, когда нужно будет обосновывать то или иное архитектурное решение.

P.S. Вспомнил еще книжки про устройство бизнеса. Мне прямо очень хорошо зашли романы Артура Хейли, который живописно описывал работу отеля, аэропорта, завода, клиники. Очень впечатляюще описывается сложный механизм работы большой и сложной системы, состоящей из множества элементов.

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

Геннадий Круглов в своем канале рекомендует начинать с другой книжки про системное мышление - «Азбука системного мышления», Донелла Медоуз. Тоже хорошо, кстати, можно и с неё начать.

Еще одно огромное спасибо коллегам из @Systems.Education, которые помогли по материалам доклада подготовить статью.
Так что для тех, кто не любит смотреть видео, теперь есть лонгрид на хабре про аналитические модели.
Для текстового изложения получилось, наверное, немного скомкано. Не уверен, что для начинающих будет понятно назначение каждого типа моделей... Но тем, кто уже походил по граблям, надеюсь, будет полезно. Так, в свое время для меня просто открытием стали доски Story Mapping... Если будут вопросы - не стесняйтесь задавать в комментариях. Можно тут, можно и непосредственно на хабре.

А давайте знакомиться.
Я тут подумал, каналу скоро два года, а я так и не собрался представиться и рассказать о себе.
Исправляюсь.

#знакомство

Здравствуйте.
Меня зовут Борис Романов и сейчас я алкоголик архитектор.

Когда-то давно, еще в 90-х, я был программистом, сочинял программы на тему управления документами, всякие архивы, документообороты, формочки, поиски т.п. Писал на С++, мне очень нравилась выразительность этого языка. Но, надо признать, временами получалось достаточно громоздко.
Позднее, в 2000-х появился .NET и C#, код стал лаконичнее и выразительнее. Особенно, когда появились лямбды, LINQ и прочие функциональные приблуды.
Вообще, мне очень нравиться программировать. это прикольно и интересно. Я когда-то (надо же, уже 12 лет назад!) даже писал про это пост на хабре.

Процессы разработки были тогда еще дикие, неформализованные. Роли аналитиков, продактов просто не существовали. В команде был руководитель проекта, разработчики и (иногда) тестировщики. Про скрамы и водопады никто не слышал. Люди просто собирались и работали. Помню, когда появился трекер багов - bugzilla - так это было просто откровение :).

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

Так что к началу второй декады 21 века я постепенно переквалифицировался из программиста в странный гибрид архитектора и менеджера. Читал книжки про UML и управление проектами, пытался осмыслить вероятностную природу рисков. Даже статью тогда написал про использование MS Project для управления проектами по разработке ПО.

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

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

—————————————————————————
😉если вам интересно, то продолжение последует...

#знакомство Продолжение

Следующий виток расширения мировоззрения пришёлся на 2010-е.

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

Первым краеугольным камнем в фундаменте изменений стали книги по теории ограничений систем, начиная с почти развлекательных трех "Целей" и "Критической цепи" Голдратта, продолжая более серьезными книгами Уильяма Детмера и Лоуренса Лича. Теория ограничений произвела на меня глубокое впечатление, сильно изменила мой способ восприятия и понимания мира, научила обращать внимание на причинно-следственные связи, задавать вопросы "почему?" и "зачем?".

Вторым камнем для меня стали взгляды Насима Талеба. "Черный лебедь" и "Антихрупкость" хорошо легли на удобренную теорией ограничений почву. Пришло понимание, что просто делать свою работу хорошо и правильно - недостаточно для успеха, что ничего не существует само по себе, в отрыве от окружения. Миром правят случайности и вероятности, а наши возможности по прогнозированию сильно ограничены. Мало вкладываться в работу над понятными вещами, важно также, по "принципу штанги", защищаться от потенциально неизвестных событий. Теперь я всегда повторяю своим детям мысль, что если не хочешь ПОТОМ разгребать последствия неожиданных СЛУЧАЙНОСТЕЙ, лучше СПЕЦИАЛЬНО СЕЙЧАС что-то делать, чтобы снизить их вероятность или меньше от них зависеть. Банальный пример для детей - если ты специально всегда готов к уроку, то тебе неважно, когда учителю придет в голову дать контрольную. Более прикладной пример из программирования - если СНАЧАЛА реализовать простую обработку ошибок/исключений "вообще", которая для любой непонятной ошибки будет выдавать какое-то осмысленное, но главное - детерминированное поведение (запись в лог, сообщение об ошибке пользователю и т.п.), то тебе неважно, какие ошибки случатся ПОТОМ. Когда все неизвестные варианты "прикрыты", можно спокойно делать частные, улучшенные, специализированный обработчики конкретных ситуаций.

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

————————-
продолжение следует...