В прошедшие выходные был на ЛАФ-2022 — Летнем аналитическом фестивале. Это тоже конференция аналитиков, но по формату и атмосфере она очень сильно отличается от AnalystDays. И сопоставима по количеству участников — было несколько меньше 500 человек. ЛАФ проводится с 2010 и первые годы был в Иваново: суббота была с докладами в офисе, вечером ехали на турбазу, шашлыки и общение, а в воскресенье продолжали работать — не взирая на открывающиеся возможности для отдыха. А несколько последних лет оба дня проходят на турбазе или доме отдыха в разных местах. Были Владимир, Тверская область, Кострома, а в этом году — Софрино в Подмосковье. И благодаря формату на фестивале царит атмосфера активных знакомств участников и общения. Тем более, что в пятницу вечером, после заезда, был командный квиз и дискотека, а в субботу — афтерпати с живой музыкой, танцами и шашлыками. Пати завершилось около полуночи, но общение продолжалось до полтретьего минимум, потом я ушел спать.

Что интересно, от AnalystDays отличается не только формат конференции, но и состав докладов, можете посмотреть сами программы: ЛАФ и AnalystDays. На ЛАФ гораздо больше докладов про профессиональную работу аналитика и кейсов конкретных проектов. При этом, конечно, получилось меньше докладов по softskill, хотя они тоже были. Но, как и на AnalystDays докладов, связанных с особенностями работы аналитика в микросервисной архитектуре — не было. Да, были доклады по интеграции, но в них обычная логика, свойственная enterprise-приложениям, а не ситуации, когда запрос пользователя обрабатывается несколькими сервисами и надо обеспечить надежный отклик за приемлемое время при их асинхронной работе. И доклад Дмитрия Морякова про распил монолита задача про минимизацию связей выделяемой части ставилась, но способ решения был в тщательном анализе этих связей, который выполняет аналитик по выделенной архитекторами части, известными методами.

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

Я сам делал доклад про способы описания бизнес-архитектуры. И участвовал в круглом столе «Почему индустрии нужны проектировщики, а не аналитики?» Это заняло полдня, а дальше я слушал доклады и вел репортаж в телеграме в ходе конференции. Рассказ об этом — дальше в отчете. Надо отметить, что рассказ заведомо не полон: на конференции было пять треков. Кроме того, параллельно с моими выступлениями шли выступления очень хороших спикеров, которые я тоже пропустил. Жаль.

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

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

Мой доклад Бизнес-архитектура: от цепочки создания ценности до автоматизации бизнес-процессов был про разные способы описывать бизнес-архитектуру. Обычно это принято делать через описание бизнес-процессов, но такой способ имеет множество проблем, особенно напрактике — думаю, все встречались с толстыми описаниями со множеством диаграмм, которые не соответствуют реальному положению дел, и плохо понимаются сотрудниками компании, которые вроде должны по этим процессам работать. Я говорил об альтернативных способах. Это task flow, поток задач, который широко применятеся в ИТ и знаком по доскам. И его можно применять для любых компаний, и это досотаточно легко — если рассматривать workflow документа как отражение выполнения задачи. От task flow есть переход к цепочкам создания ценности, value chain. И к ценности для потребителя, продуктам для него. В Archimate продукты проявлены, хотя предполагается их реализация через бизнес-сервисы, реализуемые бизнес-процессами. А есть другие способы — OMG Essence, канвас Остервальдера для описания встройки компании в рынок.

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

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

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

А то, что позиция называется «аналитик» связано с историческими причинами, и не стоит переживать по этому поводу. Впрочем, отмечены ситуации, когда требования обеспечиавают страховку при разборе результатов, либо нужны для формального соответствия ГОСТ, но это уже отдельные темы.

Конспектировать и активно участвовать — невозможно. Но после круглого стола Денис Бесков, который его организовывал, собрал тезисы участников.

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

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

Как обосновать важность наставничества заказчику? Ему нужны выполненные работы, а не идеальная команда. Но! Ему нужно уверенное планируемое выполнение задач. Наставничество — позволяет этого достичь.

Наставник — не мамочка, а старший брат или сестра: родительская забота, авторитет опытного, но при этом относительное равенство и приятельские отношения. Старший брат всегда на твоей стороне, это важно.

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

Активности

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

Про базу знаний: все знают, не буду рассказывать зачем. Сразу про опыт. Она с госами, и там очень много формальных требований к документации, и много всего. Сделали реальную базу знаний по всем проектам.

Регулярный фидбэк тет-а-тет. Особенно если работаете в open space. Как отдельная активность, отделенная от других. Еженедельно + по вехам проекта или испытательного срока.

Какие ставить задачи и как это делать.

• Не только полезные для проекта, но и служить интеграции человека, знакомить с проектом и предметными областями. Задача — элемент мозаики знаний. Каждая задача — расширяет его область.
• Надо объяснять не только что надо сделать, но и важность этой задачи для проекта.
• Учитывайте, что сроки у новичка будут больше.

Антипаттерны

• Человеку поручают рутинные работы. Там легко выявить ошибки, познакомить с процессами. И у новичка рутинная работа не будет вызывать отторжение. Но! нельзя только скидывать рутину на новичка. И не формулировать «вот тебе рутина пока мы заняты делом».
• Nice to have — не срочные и без рисков для проекта. Кажется хорошей идеей — рисков нет, технический долг разгребают, а в исследованиях новички проявляют себя. Но! Такие задачи не дают чувства значимости и интеграции с командой. Тот же эффект «вот тебе всякое разное, пока мы дело делаем».
• Бросить в воду — пусть сам выплывает, нет — нам слабаки не нужны. Сценарий очень часто применяют с обоснованием «у нас команда профессионалов, не нужны люди, с которыми надо нянчиться». Реально за этими словами стоит нежелание заниматься наставничеством. Новичок при этом испытывает сильный стресс, и там может быть точка невозврата, от которой человек уйдет. Часть по-факту превращается в стихийное наставничества со всеми минусами. И вам дальше искать следующего — большие накладные расходы впустую. Может, все-таки учить плавать, а не бросать в воду. А еще — вам надо передать ваши практики и способы решения задач, которые отличаются от тех, к которым он привык на предыдущем месте. И еще — что думает выплывший о бросивших в воду? Он не будет воспринимать остальных людей как команду. Так что только как педагогический прием под наблюдением, а не реально бросать вводу.
• Сразу расскажу тебе все. Обычно у тех, кто недавно выплывал сам — остался посттравматический синдром. И они рассказывают очень много в первый же день. И это превышает возможности восприятия. И человек реально забудет большую часть информации. В то время как наставник наоборот, будет стремиться рассказать все больше.
• Мелочная опека. В первый день прочитали лекцию. Во второй — дали задачу и плотно опекают, вплоть до того, что диктуют письма. Тоже антипаттерн. Новичок думает «что я, совсем тупой?» А цель наставничества — научить делать задачи — не достигается. И даже если новичок держится за мамину юбку и хочет делать пjд диктовку — надо с этим что-то делать.

Наставничество — не только способ научить, но и способ научиться.

• Самый эффективный способ разобраться — рассказать другому.
• Новый взгляд со стороны может показать неожиданные моменты

Профит

• Новичок стал членом команды
• Новичок приведет других, скажет что классная компания

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

Интересанты и их интересы

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

Проблемы в привязке к интересантам: долгое погружение аналитика (РП), сложность поиска специалистов (PM), недостаточная эффективность (CEO), нет замены на сложных работах (Senior), недостаток материалов для обучения (Junior), перегруз на типовых работ (Middle)

Демография: в 2017—2022 приход молодежи упала на 25 %, а потребность — возрастает.

User story: я хочу построить работу в отделе, чтобы удовлетворить интересы таких-то стейкхолдеров. Это — из ее опыта, переформулируйте для себя в соответствии с вашей ситуацией.

Первые шаги

• Ситуация: что критично, что подождет
• Ресурсы
• Выделить направление максимального эффекта
• Выявить показатели для оценки

А параллельно — стратегия

• Что руководство хочет от отдела
• Зачем отдел нужен — часто видение руководства разъезжается с собственным, и, более того, можно было сделать, как хотели, но об этом не знали
• Оценить ресурсы.
• Составить план

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

Оценка эффективности. Критерии различаются от ситуации

• Надо как-то оценить в начале: что есть
• А потом мониторить

У нее было: количество ошибок сохранилось, но при этом объем работ возрос, то есть на единицу работы уменьшилось. А еще — не сорвали процесс заказчика, и это — успех. Надо смотреть.

Сделали шаблоны проектирования — сократили работу аналитиков в несколько раз. И два аналитика были на 10 разработчиков. Правда, не успевали все равно одним разработчиком надо было усилить.

При поиске аналитиков важное

• К новичку — соображалка и проверка по hard skill, которым учился. Учили БД — что узнал?
• К среднему уровню — soft skill. B проверка, что адекватно рассказывает про опыт, не врет.

РП: Вы дали слабых аналитиков. Чтобы не было — подключаешь его на этапе заявки и совместный отбор. Поэтому даже при ошибках — они совместные.

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

К подразделениям

• Не допускать простоев на входе
• Памятки новичкам — снизить неопределенность
• И у кого спросить — даже для ведущего, потому что специфике проекта он не знает

ступени развития аналитика.

• Специалист — пишет по алгоритму, примерам и шаблонам
• Старший — на результат, то чего нет в шаблоне
• Эксперт — разработка шаблонов и нестандартные решения

Передача знаний сверху-вниз, люди повышают компетенции

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

Триада технологического развития: технологии, обучение, сохранение знаний. Надо делать все вместе. Разрабатываем технологию — добавляем базу знаний — готовим и проводим обучение. И в обратную сторону, подготовка обучения показывает провалы ы базе знаний, а ее наполнение — пропуски в технологиях.

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

Обучение: если обучали — запишите и положите, ведите список — для повторного использования.

Вовлеченность

• Внимание к потребностям человека
• Открытость
• Аналитиков надо учить. Опасность, что они уйдут — не так важна.

Новаторов 2-3 %, в ИТ — побольше, но не так много. Ранних последователей 13 %, всего 16 %. На них надо опираться. И к ним притягивать раннее большинство. Они осмотрительны, но если видят, что получилось — они хотят попробовать. Дальше позднее большинство.

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

Автоматизация где можно. Например, генерация описания АПИ (старая история) — потому что без этого обновление — адский труд, вплоть до увольнения тех, кто занимался.

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

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

Собирается в докладе

• Заставить задуматься — возможно, это сложно
• Будет говорить вещи, которые могут показаться странными. И, возможно, такими являются.
• Первая стадия столкновения с изменениями — отрицание

Если ты такой умный, то почему до сих пор не богатый? В 20 ржешь, в 30 заставляет задуматься, в 40 — хочется дать в рожу задающему. Реплика из зала: в 40 отвечаешь на него. Вот так: одни отвечают, а другим хочется дать в рожу.

Что хуже поломанного компаса? Ложные ориентиры.

Как только встречает двуличие — это не мой человек.

Мало людей идут сложными путями. Вместо простых, пусть ложным. Большинство не может быть не правым. Если все побежали — не надо бежать в другую сторону.

Ролик с эффектом домино, когда маленькая дощечка по цепочке валит все больших и больших.

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

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

В 1950 году британские ученые осознали опасность роста населения Индии.

• Первая версия: тупые индусы не знают, откуда дети. Развернули программу планирования семьи
• Наводнили дешевыми контрацептивами. Рождаемость сначала упала, потом поднялась.
• Главный секрет: папаша мог пойти на пенсию после рождения третьего сына. Поэтому — 4-6 детей. Закон принимали раджи, когда надо было набирать армии. До этой причины добирались 30 лет

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

Три подхода к решению

• Мышление собирателя — transportation thinking. Есть маленький генератор эндорфинов — собрал что-то. Эта яблоня там-то и есть единственный путь. Если не знаешь, как правильно решать задачу — не профессионал. 90 % госов и run-бизнеса.
• Мышление охотника. Олень — не там, где видели в тот же раз. Вероятностное мышление, надо построить гипотезу, где может быть объект. А еще если не увидел — не надо уйти в депрессию. Удовлетворение от процесса. А еще «где бы я был, если бы был оленем», и рыбу ловить на то, что любит она. Надо смоделировать ситуацию, держа в голове другой объект. Grow Change.
• Конвергентное и дивергентное мышление. Сначала создаем альтернативы, а потом делаем выбор. Но еще после выбора — надо заниматься реализацией, просто взял и сделал то, что придумал. То есть надо чередовать все три деятельности, и уметь переключаться.
• Великий строитель. Надо создать календарь, чтобы заставать мигрирующие стада. А еще организовать деятельность товарищей: загнать мамонта, а не убить, чтобы убить там, где можно переработать, и потом убить. Строители получают удовлетворение от таких проектов. Но их мало.

Мы все гибриды, у нас есть все варианты удовлетворения.

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

Контур результата. Мерило работы — не усталость. Лучше всех в колхозе работала лошадь, но председателем она не стала. Если вы в системе — лошадь, то вам будут все время накидывать задачи.

Клиентоориентированность важнее функциональности. Осознанность важнее клиентоориентированности.

Ресурсы — Действия — Результат — Выгода — Влияние. Output — Outcome — Impact (по-русски все — результат).

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

Как побеждать: Run — Grow — Transform.

Вы зачем получаете 80тр как аналитик, вместо того, чтобы получать 200тр как продукт? Вам это нравится? Реально вы сами для себя определяете, на какой площадке играть.

Принцип баланса инвестиций: Инвестиции, Варианты-Выбор, Операции — по трети.

Работать надо умнее, а не больше. И бежать из тех мест, где работа оценивается потением или демонстрацией потения (имитацией). После трех лет имитации деятельности люди не способны вести деятельность.

• Прежняя парадигма: 80 run + 20 grow — кризис — transform — снова run + change
• Новая парадигма: 50 transform + 30 grow + 20 run. При этом часть transform невидима.
• Джобс 4 года собирал права на музыкальные произведения, чтобы запустить iPod+iPhone. B это создание конкурентного преимущества

Контур контекста.

Гараедаги. Как управлять хаосом и сложными проектами.

Почему нет результатов

• Не понял (просто скопировал)
• Я не подумал (сделал как привычно)
• Подумал, но мало
• Отказался меняться
• Не смог понять новую парадигму

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

Сдвиг парадигмы от Анализа к Системе. Матрица: run-change-transform против complicated-complex. В complicated — аналитический подход, в complex — системный. В клеточках подходы, надо будет посмотреть.

Работайте с теми, кто умеет работать.

Куда денется серийное производство? Каждая новая тесла уникальна, при этом программирование роботов ведут 8 scrum команд? и каждая новая тесла — новый релиз продукта.

Контур глубинной причины. TOC. Часть системного мышления — про причины, а не симптомы. Ищем корневые причины. Но! В острой ситуации не всегда есть время искать корневые причины, надо устранять симптомы, а одновременно работать с причиной.

Контур осознанности. 2*2 Осознанность — Компетентность

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

Люди внедряют устаревшие модели.

Малый круг — рефлексия. Объясняешь другим. Раз, два — сам понял, они не понимают. Когда ты оцениваешь свою компетентность — можно избежать большого круга.

Большинство проджектов думают, что знают, что такое продукт — то, что делает команда. Продукты знают, что продукт — нечто другое, то, что наносит пользу. Одни других не понимают. То есть понимание зависит от контекста.

Теория U. Кусочек, хорошие схемы. Система — не один, а двое. Потому что синергетический эффект — только тогда возникает. Поэтому определить только одну сторону — провально. Если мы хотим изменить — то мы должны и измениться сами. Принцип сотворчества.

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

Механизмы слепой эволюции

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

600 экспериментов, 500 человек, выкатили 3.

История с разработкой продуктов больше похожа на кладбище великолепных идей.

В омут с головой — не надо.

Стратегия — не про героизм «мало ресурсов гарантированный результат».

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

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

По мотивам фреймворка Роджера Мартина.

• В чем смысл существования (миссия)
• Где мы можем достичь максимум (рынок)
• Что есть наша победа (vision) — мы сами это формулируем в меняющемся мире
• Как победим (стратегические ставки, вектора развития)
• Как мы изменимся: в чем будем лучшими (возможности), как изменимся наши поддерживающие процессы

Как создать

• Discovery
• Research
• Design: ставки, capability, системы и процессы
• Operate & Optimize

Контур целостности.

• Холархия и холоны.
• Самоопределение — это способ вхождения в объемлющую систему.
• Самоопределение — основа эволюции.

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

Не делайте херни, и не находитесь в организации, которая ее делает.

Понятный рассказ о переходе от устных уведомлений к чеклисту по изменениям для того, чтобы обеспечить устойчивость процесса. Большая компания, 15 команд занимаются аналитикой данных, а данные лежат на 20 серверах и поступают из многих CRM-систем. Структуры данных меняются. Раньше была устная информация об изменениях на летучке. Те, кто слушал вроде как прикидывали, что проблем нет. Но с голоса воспринимали не все, руководители не всегда знали про использование полей, и от изменений ложились процессы интеграции. И это было 1-2 раза в месяц, и это приводило к инкапсуляции команд внутри, взаимному недовольству.

Поэтому сделали протокол из 4 пунктов изменений. Потом постепенно это разрослось в большой чек-лист

• Использование изменяемых объектов — через инструменты, скрипты по базам, интеграционные пакеты, BI-отчеты, логи ClickHouse
• Предварительные уведомления: сделали структурную ленту новостей, с детальным описанием изменений. Плюс ping в slack инфраструктурных команд. Если с отработкой изменений есть проблемы — то новость комментируют или отвечают в slack, изменение может быть отложено.
• Изменения — задача на разработчиков по шаблону, изменения, тестирование. В задаче: проблема, мотивация, что сделать, сроки. Важно раскрыть смысл задачи, а не просто набор изменений. Разработчику это важно, чтобы ответственно отнестись, и не было рефакторинга.
• Уведомления по факту — новости в стафф, на каналах в слаке и на летучках.

Эффект

• Сократилось время на поиск объектов — собрали единые скрипты для поиска.
• Скорость подготовки к изменениям сократилась в два раза — задача стала типовой, идем по чеклисту
• Скорость реализации увеличилась в 1.5 раза
• Падения ушли
• Увеличилось доверие между командами

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

Монолит. Общая БД — ограничение масштабирования. А интеграция — через БД. Микросервисы: у каждого своя БД и взаимодействие через АПИ — для масшабируемости. Можно запустить много экземпляров.

Как менять? Варианты пилотного проекта.

• Делаем в микросервисах новое, ставим рядом. Оно хорошо, но не получается распилить.
• Поставить новую систему в параллельную работу, а потом переключить. Дорого, не всегда есть время.
• Вырезаем из монолита критичную часть и делаем микросервисами.

Рассматривали именно третий сценарий, когда монолит сильно не справляется, и критичную часть надо выделить для ее масштабирования.

Роль аналитика

• Реверс инжиниринг — анализ БД, сбор требований. С документацией обычно проблемы. Есть средства не только для БД, но и для кода и логов, но практически БД — не дорого и достаточно.
• Моделирование: предметная область, процессы AsIs
• Проектирование: бизнес-процессы ToBe на основании решений по архитектуре. Управление зависимостями.

И дальше в докладе было детальное описание по стадиям.

• Построить модель предметной области
• Описать бизнес-процессы AsIs — выдерживая модель
• Выделить микросервисы
• Спроектировать новые бизнес-процессы: монолит обеспечивал транзакционность работы по запросу пользователя, а в микросервисной архитектуре исполнение идет асинхронно по нескольким сервисам, и это требует перестройки процессов
• Детальное проектирование микросервисов.

Нотации.

• Процессы — BPMN. Процессы, и их ассоциация с хранилищами. Описание коллаборации: межпроцессный обмен, service task, очереди сообщений.
• Предметная область:

Domain-Subdomain - удобная, но слабая, только верхнего уровня. Работает на простых областях. 
UML диаграмма классов - хорошая, но с трудом понимается всей командой, особенно бизнесом. 

• • ER-диаграммы, с дополнением сущность-связь EA для отложения вложенности доменов

Инструментарий — EA (он использовал его), Visual Paradigm, iServer. На большой БД нужны отчеты по БД.

Диаграмма: два БП, в одном пишем хранилище, в другом — читаем. Направленная связь записи/чтения — по варианту использования use case. Вся модель — в репозитории, и это дает возможности проверять модель, группировать информацию.

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

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

Самый страшный монолит можно распилить. Вопрос — сколько сил вкладывать в детальное проектирование и моделирование.

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

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

Компания проверяет закупочную деятельность. Конфликт интересов:

• Инспекторы выписывают безопасные штрафы, которые не оспариваются
• Руководитель — обеспечивает выполнение своих показателей
• Главный босс — заинтересован в увеличении числа штрафов.

Анализ: мощность инспекторов — десятки контрактов, а их 10к+. Большие контракты идут мимо проверок. Заказчик сложный — идет конфликт интересов.

Была процедура вне системы. Инспектор заходил на портал по госзакупкам, находил контракт, вручную копировал в Excel и так же вручную, заходил в систему закупок города, оттуда копировал.

Она сделала выгрузку контрактов, наложила на них риск-мониторинг. 10k строк, 50 колонок: характеристики и риски. Она сама была инспектором и хотела помочь инспектору — облегчить работу. И помочь боссу — чтобы он видел мониторинг.

Надо было наглядно показать проблему, и далее — динамику работы. Смотрела инфографику. Нашла 3d-дерево, но по масштабу не подходило. А потом — увидела фрактальное дерево на питоне, оно уже подходило на объеме. А риск мониторинг — подсвечивать цветами, как пробки. Построение дерева — открытый код, довольно быстро, но дальше игрались с хорошей визуализацией.

Две инфографики

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

Логика дерева

• Справа — более дорогие контракты. И как раз было видно, какие контракты проверяют.
• Деление ветвей — по годам и финансовым критериям — по объему закупок.
• Более 15 фильтров, чтобы получить нужный срез контрактов — это часть дерева. Например, подозрительного поставщика, или по конкретному лекарству с особым учетом.
• Риск-мониторинг по цветовой гамме желтый-красный.
• Можно увидеть уже проведенные проверки и включение в текущие контракты. И эти контракты подсвечивались другим цветом — бирюзовым и синим. Красный пожар тушим синей водой.

Инфографика — не убирает работу с таблицами, под деревом есть таблица. Обоснование включения в проверку.

Результаты

• Инспекторы не делают 2/3 механической работы — все контракты в дереве.
• Руководитель получил инструмент, защищающий от высшего руководства — прозрачность и обоснованность проверок.
• Босс увидел картину и масштаб проблемы, получил управляемость.

Работает во многих проектах: контрольное управление РФ, города, ДИТ — анализ с поставщиками, Европейский банк. И не только нарушения, но и освоение бюджета.

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

Задача в интеграции — описание моделей данных. Вроде все просто — структуры данных. Но надо объяснить разницу разного уровня.

• Физический уровень данных. Коробка, и разнородный крепеж. Если накидать — будет ненормализованная БД. Нужны коробочки по видам изделий. И их подписать — индексация. При этом нормализация разумна, гайки и болты используют совместно — значит можно в одну коробку. Аналогия хорошо заходит людям.
• Логический уровень. В телекоме история: надо перекрутить перегородку, а мужик пришел, и говорит: фигня какая, надо открутить и прикрутить. Логический уровень — об объектах, свойствах и взаимосвязях.
• Концептуальный уровень. О терминологии, которую мы используем.

Телеком. Для них Договор - контейнер для услуг. А у заказчика договор - уникальный идентификатор клиента, по которому идет пополнение счета и так далее.
Агрегатор такси. Вы вызываете, оплачиваете со своей карты. Но есть функция "вызов для другого человека", при этом плательщик - другой, а не вы. 

Способ интеграции — разница между шиной, точка-точка и dblink на примерах бара.

• Шина. Заходите в бар, заказываете пиво, платите. Бармен — идентификация, авторизация (18 лет), параметры контракта (пиво) и т. д. Он выполняет роль шины
• Точка-точка. Это уже другой бар — из холодильников с бутылками пива, и каждый из них с собственной авторизацией и собственной оплатой. И если надо несколько сортов пива — то надо стоять много очередей и в каждом выполнять свою процедуру.
• dblink — бар с бочкой и ковшиком, из которой сам наливаешь пиво. Очень просто — скорость и простота. Вместе с рисками — грязный ковшик, неаккуратный посетитель, могут всю бочку опрокинуть.