В конце мая прошла очередная, четырнадцатая #AnalystDays. Я участвую в них с самой первой конференции в 2012 году, пропустив только одну в 2019 году. Это профильная для меня конференция, а среди участников много старых друзей и хорошее общение. И эта конференция не стала исключением. А еще по докладам можно посмотреть, что происходит в сообществе и как реально выполняются проекты. По способам работы аналитика и формату написания постановок это очень хорошо видно.

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

Дополнение по обсуждению предыдущего тезиса. Народа на докладах про микросервисную архитектуру - много, на AnalystDays минимум одby такой доклад был. То есть интерес к теме - есть. Но потребности работать по-другому - нет. Потребность - это когда по-старому нельзя и ты как-то экспериментируешь, что-то делаешь по-другому - и тогда об этом можно рассказать. Как-то, как получается делать, не ожидая, пока кто-то напишет книжку с методами. Микросервисы - давно есть, не супер новая тема, на highload и других конференциях - много разработческих докладов. А аналитики в этом движении не участвуют. Моя гипотеза - что дизайн и архитектуру окончательно отдали разработчикам. Работа через userstory и макеты интерфейсов не требует понимать как работает приложение. От не понимания не комфортно - отсюда интерес. Но не более. Позиция системного аналитика, который проектировал устройство - окончательно исчезла, проектирование интерфейсов добавилось к бизнес-аналитику, который стал просто аналитиком, а остальное - разработчикам или стало не актуально. У системного аналитика было проектирование базы данных. С переходом на объектные языки это стало служебной по сравнению с диаграммами классов, которую аналитики не освоили, хотя общая БД осталась - но разработчики уже могли делать в реализации по-своему, исходя из диаграммы классов и ограничений ОРМ. А переход на микросервисы, у каждого из которых своя БД, проектирование БД без знаний об устройстве приложения окончательно утратило актуальность. Эта гипотеза подтверждается тем, что в командах сервисов без GUI аналитики встречаются очень редко. Ниша упущена.

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

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

Так что в целом уровень докладов соответствует основной аудитории конференции. На этом я закончу о конференции в целом, и перехожу к конкретным докладам. Начну со своего, а дальше будут конспекты других докладов. Отмечу только, что уже в конце следующей недели будет ЛАФ, другая конференция аналитиков. Интересно будет сравнить впечатления. А осенью у организаторов в планах провести две AnalystDays: в Ереване 02.10 и в Петербурге 4-5.11. Выбирайте и участвуйте!

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

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

После доклада Дима Безуглый сказал, что не согласен с 95% (согласен с 1 из 20) и позвал на дуэль, которая состоялась на второй день после его доклада. В общем, народ пришел, но яростной схватки не получилось, оказалось, что при последовательном изложении мыслей большинство различий - в акцентах и терминах, а не в содержании. Мы развивали мысли друг друга, а не спорили.

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

Писала для себя тезисный конспект батла по профессиональному развитию, может ещё кому-то будет интересно

Переход от личностного развития к лидерству, объединению людей и заданию направления

1. Откуда брать цель? Самоопределение - выбор, кого усиливать
2. Для реализации нужна команда. Развитие компетенций возможно только в команде

KOD knowledge of demand

Двухслойная эволюция

1. ты развивается и толкаешь команду
2. команда развивает тебя

Можно войти в команду с минимальным опытом, чтобы обучиться

Чтобы выиграть в будущем, надо понимать, как изменится среда, в которой мы будем играть. Есть "я такой уникальный, попробую все" и разумная эволюция, где навыки сегодня готовятся на будущее

1. Дискавери - карта (в команде)
2. Ресерч (в команде)
3. Постановка цели
4. Дизайн (использовать профили)
5. Действия

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

К любому AsIs и ToBe должен быть приписан вектор изменений. Когда измеряешь движущийся объект, нужно учитывать вектор.

Ресурсы не надо готовить, надо понимать, какие есть.

"Глупо плыть на корабле и думать, что можешь выбрать свою траекторию". Нужно определить субъект, относительно которого строится траектория.

Рост - от границ эго к границам личности, к границам семьи, к границам общества

Think big act small. Нужны короткие шаги и периодическая переоценка цели

Если соглашаться на все возможности, вас растащат, не сможешь сконцентрироваться на цели

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

• себя
• команду
• страну
• человечество

Управлять ценностями = управление нашим кругом

10% мыслят самостоятельно, могут быть против всех

80% флюгер, сумма мыслей окружения

10% социопаты против всего

Самоопределением надо заниматься в коллективе

Нас научили оценивать себя через других. Учиться оценивать себя самостоятельно (есть техники).

Независимое мнение - обязательное качество лидера

В каждой группе должен быть человек, который против, чтобы провоцировать обсуждение

База:

• Эмоциональный интеллект
• Командный интеллект

После этого:

• Хард скиллы (kod)

Команда - нейросеть, каждый узел (член команды) должен развиваться своим путём (кто-то развивает лидерство, софт скиллы, кто-то хард)

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

1. Неясно, чем различается делегирование от простого назначения задачи для выполнения, я бы сказал, что любое назначение задачи называется делегированием, хотя различается передача выполнения и передача ответственности за результат. Впрочем, у Натальи тут есть основания, потому что она посмотрела определения, и там делегирование понимается как назначение задачи. И тут есть вопрос про источник такого определения и понимание тех, кто писал определение, потому что беглый поиск говорит преимущественно о делегировании полномочий, а не о передачи выполнения задачи.
2. На входе Наталья, взяв определение делегирования как передачу от руководителя подчиненному, оговорила, что в современном Agile-мире все происходит не так, нет руководителей и подчиненных. Однако, дальше рассказ идет о передаче от старшего аналитику младшему, о должностных инструкциях и других атрибутах классической компании.
3. Нет трассировки делегирования до его целей. Хотя про цели говорили, периодически они в рассказе всплывали, но трассировка всегда была в залоге, что передача таких-то задач достигает таких целей, в то время, как ход мыслей, скорее, должен быть другим: мы хотим достичь таких-то целей и потому передаем такие-то задачи.
4. Любопытное разделение между лидером и менеджером. Менеджер - про работу, организует стабильный процесс и нацелен на качество результата. А Лидер - про людей, увлекает за собой и не слишком интересуется результатом. Но при этом конкретный человек может быть в обоих позициях и переключаться между ними. А может быть разделение, в ответах на вопросы прозвучало разделение функционального руководителя и руководителя проекта.

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

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

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

Понятный рассказ про менторство, которое используется для погружения новичков в проект. У них мобильная разработка, 100+человек в департаменте, распределенная команда - Москва с удаленкой, регионы, подрядчики. Георгий как ментор работал с 5 аналитиками, 4 успешно прошли испытательный срок.

Когда выходит новый человек, то из команды выделяется наставник, обычно системный аналитик, который на испытательном сроке погружает в команду. Когда просят обучить новичка возникает вопрос "он умный или как я?". Ментор - входная точка контакта по всем вопросам. Не только производственный инструктаж, но и передача софт и хард скиллов.

Есть курс менторства: цели и процесс, модель HBDI доминант мышления (Herrmann Brain Dominance Instrument) и ситуационная модель лидерства.

Для новичка - есть документ Quick start. Его надо обновлять, review - часто подготовки к менторству. Там сообщая орг.информация, информация о команде и продукте, командные процессы, артефакты аналитика. Документ не надо перегружать. В разных командах Quick start разный, так как разные проекты и технологии.

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

Работа начинается в первый день. Там не так много успевают, но там важно - встреча offline, если он в Москве. Личная встреча - чтобы познакомиться, узнать характер, понять взаимодействие - через созвон это сложно. А еще - проверка всех доступов, есть чеклист.

Первая неделя.

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

Испытательный срок

• План работ в confluence и еженедельный статус
• Канал коммуникации вопрос-ответ. Его надо наладить и в первые дни активно использовать, чтобы заработало. Нравился slack, но сейчас с ним проблемы, можно в confluence. Когда отвечает на вопросы, то старается следовать "не дай рыбу, но дай удочку" - чтобы он новичок научился разбираться в похожих задачах сам.
• Оформление постановки на изменение - есть шаблон.
• Регулярная обратная связь.

Помимо ментора есть куратор, с которым встреча раз в 2 недели, есть HR, ментора можно менять, если есть проблемы.

Менторство дает плюшки не только обучаемому, но и самому ментору.

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

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

Когнитивные ошибки стало популярной темой, современные исследования выделяют их до 2000, в докладе было 8.

1. 2013 - Эффект Манделы. Он умер в 2013 году у себя дома, в 2015 решили сделать фильм и обнаружили, что многие люди верят что Мандела умер в 1975 году в тюрьме. Не единичные случаи. Эффект массовой ложной памяти начали исследовать, обнаружили массовый эффект. В презентации - многие примеры. Проявление в работе аналитика: вы проводите встречу, пишите протокол, и выясняете, что другие поняли договоренности совершенно по-другому. Способ борьбы - фиксация онлайн прямо на экране.
2. Ошибка выжившего. Про самолеты во второй мировой. И про спасение дельфинами - они вовсе не обязательно толкают к берегу. В Бостоне было приложение, которое фиксировало ямы на дороге, и отправляло статистику дорожным службам. Обнаружилось, что самые плохие дороги в дорогих районах - просто потому что смартфоны преимущественно были у обеспеченных людей. Решение - проверяйте полноту исходных данных.
3. Ошибка согласованности. Идея: дает пример трех чисел 2-4-6, говорит, что они удовлетворяют правилу, и предлагает назвать "аналогичные". Большинство порождает гипотезу, что речь идет о увеличивающихся числах, быть может по какому-то закону. Реально правило "любые три числа" - это не выясняют. Решение - примеры "от противного", мозговой штурм. Придумайте самую ужасную поликлинику - и проигрывайте на ней.
4. Ошибка планирования. Недооценка времени и прочих затрат, требуемых для выполнения задачи. Сиднейский театр: срок строительства +10 лет и 102 млрд вместо 7! Оценка студентам "когда сделаете диплом". 50% оценили "в апреле", реально большинство сделали в мае, но 45% не сделали даже в июне к окончательному сроку диплома. Но это не только с дипломами: примерно столько же людей оказываются не готовыми к Рождеству, при чем регулярно и даже из тех, кто знает про эту ошибку.
5. Фундаментальная ошибка атрибуции. Свои достижения объясняешь тем, что ты герой, чужие - случайностью, и наоборот, свои неудачи обстоятельствами, а чужие - их недостатками. Приходим к клиенту, говорим, что готовы мигрировать данные. Клиент говорит "у нас Excel"? думаем "попали в прошлый век", а реально там нормальная автоматизация, макросы. Решение - не торопитесь с выводами, переспрашивайте.
6. Дилемма заключенного. Двух поймали, предлагают наябедничать, если оба молчат - каждому по году, если один ябедничает, то го отпустят, второму 10, а если оба - то каждому по 5. Поскольку люди другим не доверяют, то начинают ябедничать, и оба проигрывают. Но! при повторяющейся игре люди подчиняются.
7. Эксперимент Милгрэма. Показывает предрасположенность подчиняться авторитету. Если ответственность на другом, или вам объяснили. что так положено, то вы можете творить ужасные вещи. Способ интеграции, у клиента была общая схема, которая в конкретном случае могла быть реализована только криво из-за технологических ограничений, предлагали альтернативные пути - он настаивал на кривом решении.
8. Эффект Даннинга-Крюгера. Новичкам неизвестно, то что известно всем, это нормально, объясняйте и не ворчите.

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

1. Ситуация: "Перенесите все данные за 3 года из SAP R3 в новую отечественную систему". При сильном различии структур данных. Что делать? Совет: Без паники, объясняем разницу структур данных и другие проблемы. Клиенту чаще всего надо смотреть отчеты, и можно договориться, чтобы это делали в старой системе.
2. Ситуация. Перенесите из программы Ф1. Что такое Ф1 - никто не знает. Совет: Часто это какая-то специфическая система заказчика. В ней придется разобраться, но это - рабочая ситуация. И определять список переносимых данных, чаще всего целесообразен перенос больших справочников.
3. Ситуация. Вот стопка первички, надо занести в новую программу при внедрении. Тяжело. Совет. Часто бывает достаточно занести итоги или что-то подобное.
4. Ситуация. Почему я должен снова платить. если вы исправляете ошибку разработчика? Совет. Тут надо разграничить ответственность.
5. Ситуация: "Совсем по-другому предлагала интерфейс, надо все переделать". Совет. Обсуждать и согласовывать эскизы.
6. Ситуация: "Во многих ситуациях программа ведет не так, как я ожидала, исправляйте". Совет. Фиксация алгоритмов и передача заказчику с тестированием в разных ситуациях.
7. Ситуация: "Предыдущий специалист работал быстрее". Совет. Тут надо вскрывать причины. Может быть, действительно, вам не хватает квалификации и надо подтянуть. Но может сложность самой программы выросла или вы начали работать с более сложным сегментом и так далее. Вам надо разбираться.
8. Ситуация: Почему я должна столько ждать такую несложную задачу? Совет. Объяснять на что реально тратят время. Даже если не поймет технические детали - у него будет ощущение, что вы не бездельничаете.
9. Ситуация: "Вы не понимаете задачу, не буду к вам обращаться". Совет. Тоже бывает, что не хватает квалификации, ее надо повышать - но в моменте надо обращаться к коллегам и к другим
10. Ситуация: Не привыкла работать по типовому решению, переделайте. Совет. Говорите, что что любой каприз за ваши деньги, но при этом объясняете, чем чреват отход от типового решения и объем изменений в связанном функционале, который рассчитан на типовое решение.
11. Ситуация Программа противоречит законодательству - про пользовательское соглашение, про закон о персональных данных. Совет. Для начала надо разобраться в проблеме конкретно. Если делали не вы - обратиться к разработчикам решения, у них часто есть ответ. Тут надо быть на стороне заказчика.
12. Ситуация: БД рухнула, надо восстановить.сколько будет стоить. Совет. Тут главное - не давать невыполнимых обещаний, надо понимать, что будет затрачено время, гарантий нет - как оплачивать.
13. Ситуация: Почему факт вырос вдвое после оценки. Совет: называйте осторожно и оговаривайте условия. При этом "не менее 20 часов" - плохо, воспринимается как "за 20 сделаю", надо называть "не меньше 20, думаю, за 40 точно получится".
14. Ситуация: кто-то (менеджер) пообещал быстрее. Совет: тут надо разбираться.
15. Ситуация: Я не понимают эти технические детали, этот термин. Или я на разбираюсь в этой бухгалтерии. Совет. Говорите на языке заказчика. Заранее узнайте, кто будет на встрече и подготовьтесь.
16. Ситуация: "меня в принципе устраивает, но финдиректор не доволен". Совет: выявляется всех стейкхолдеров. и когда идет постановка - заранее выясняйте их мнение о предлагаемых решениях, прогнозируйте ситуацию.
17. Ситуация: "Отдел кадров решил переходить на новую программу". Совет. Это саботаж. По разным причинам. С ним надо уметь разбираться. В том числе - помогать в переходе на новую систему, разбираться со страхах сокращения персонала, которые обычно не обоснованы.
18. Ситуация: вас резко переводят на другой проект, как объяснить заказчику. Совет: надо найти достойного преемника, познакомиться, представить заказчику, обещать помощь новому сотруднику (и оговорить это внутри).
19. Ситуация "К сожалению, пользователи не смоги разобраться в новом модуле". Совет: надо обучать, писать инструкции, и прогнозировать по модулю или фиче, потребуется ли это и в каком объеме.

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

Истории из жизни.

• Ушел ведущий аналитик, который вел проект с глубокой кастомизацией. Выгребали больно, потому что аналитики соседних проектов не в курсе, хотя они внедряют то же базовое решение - нет общения.
• Проектная организация: в двух проектах сделали модель управления задачами, и третий - начал писать ТЗ

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

Проблемы с проектной или продуктовой структурой.

• Аналитиков на проекте 1-3, они там замкнуты.
• Неясно как нанимать аналитиков - в команде часто нет профессиональных компетенций.

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

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

• Обмен практиками
• Снижение бас-фактора
• системы горизонтального и вертикального роста
• Мотивация
• Система найма и погружения сотрудников
• Погружение в предметную область
• Встраивание в работу конкретной команды
• Обеспечение задачами и информацией

Практики

• Регулярные встречи аналитиков по ходе проектов. К ним еще архитекторы подтянулись.
• Ретро-встречи. И задачи из них.
• Каналы коммуникации, для вопросов по опыту и помощи.
• База знаний и практик. Это не так просто, но есть прием - начинать с каталогов тех артефактов, которые так или иначе есть. это еще и стимулирует людей делать отторгаемое, общезначимое. Вместо каталогов можно тэгировать в общей системе тэгов. Еще каталог модулей.
• Ротация людей по проектам и практика в соседнем проекте.
• Единые процессы и практики в разных проектах. Только тут не надо навязывать, и не надо стандартизировать все. Должна быть польза и принятие самими аналитиками. Полезны единые шаблоны документов.
• Единые подходы к найму: процедура, этапы собеседований, типовые описания вакансий, типовые вопросы
• Единые подходы к погружению аналитика
• HR-бренд для аналитиков - внешние события, подкасты, статьи
• Рост и развитие. Учитывайте, что развитие нужно не всем.
• Матрица компетенций, карьерные треки
• План развития. Не делайте только из книжек и тренингов, должны быть практические задачи
• Мотивация - совместная зона ответственности лида аналитиков и лида проекта.

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

Докладе начался интересной моделью от MS, в котором ИТ-система сравнивается с городом времен начала промышленной революции. Транспорт - протоколы, Склады - базы данных, Лавки - АПИ и так далее.

Что позволяют микросервисы

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

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

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

Способы взаимодействия: файл, БЛ, сообщения, http API. В этом аналитику надо разбираться. Каждый сервис со своей моделью данных - отдельного администратора БД нет, надо разбираться аналитику, идемпотентность данных, безопасность данных, NoSQL базы данных. Еще вопрос дизайна. Дизайнер что-то согласовал с бизнесом. И там интерфейс намерения - вопрос данных, Дизайнер, Архитектор и Аналитик работают вместе. Соответствие между бизнес-сущностями и ИТ-реализацией. Однозначное соответствие с DTO и базой данных - а для этого надо разбираться в технической части.

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

Оркестрация или хореография? Если стабильная понятная система, то лучше хореография, сами договорятся. А вот если там неясно или будет изменяться - то оркестрация лучше. И стартуем от бизнес-процесса.

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

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

Оценка эффективности - ROI. Две базовых метрики: UpTime - время бесперебойной работы и Yield - время необработанных запросов. По ним оценивается стоимость, и дальше можно оценивать стоимость простоев.

Важнейшим артефактом становится тикет в Jira. Согласованные по стандартам (ГОСТ34, ITIL) не получается. К тикету - дизайн в Figma, описание фичи в confluence, содель данных, обычно xsd. Коммиты в git - ссылаются на тикет.

Антон сыплет афоризмами. Большинство проектов проваливаются, потому, что мы, следуя методологии, точно и в срок делаем то, о чем нас не просят.

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

zero-code. Визуальное моделирование drag-drop. Первые шаги, MVP - просто и эффективно, пока не уперлись в сложность. Но сложная отладка, вопросы масштабирования и часто привязка к платной платформе. Как правило, узкая оптимизация. Micro-flows - не ориентирован на разработчика.

Plain Text vs Visual? На первый взгляд, визуально лучше. "Ты не умничай, ты просто рукой покажи". Но вспомним любой фильм про хакеров: почему-то они через drag-drop банк не взламывают - они работают через консоль - plain text.

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

DSL. Их много. SQL тоже рождался как DSL, уже потом оброс всяким. html и css - тоже, а xml создавали как способ делать DSL.

• Внутренние (которые на том же языке программирования, например, черех fluen interface for api),
• Внешние, которые интерпретируются или компилируются или конфигурируют, через них? например, реализуют BDD
• Визуальные

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

• Например, формулируем требования на DSL для BDD, а из них генерация чек-листов для ручных тестировщиков и автотестов.
• Или диаграмма состояний документа - State Machine, где переходы тоже снабжены ручными и автоматизированными проверками. А может быть еще генерация кода для реализации workflow документа.

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

Customer Journey Map: по столбцам - воронка взаимодействия с пользователем, по строкам - характеристики, которые нам интересно наблюдать и получать.

Они сделали CJM, извлечь из него пользу получилось не сразу и пока шли собрали много граблей. В докладе - анализ в виде вредных советов.

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

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

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

Доклад - плохой. У него много плохих докладов и плохих курсов. Потому что новое качественным не бывает. А он рассказывает новое. Идеи доклада - не политкорректные и не щадят нежные души. Он далек от Пелевина по вставке гадостей, но гадостей будет много. Надо что-нибудь гадкое сказать. Ладно: гуманитарии - одно из главных зол этого мира. Что, никто не уходит? Люксофт. За первый год не нанял ни одного из project-менеджеров со словами "он глуп и не понимает". Откуда ж я знал, что в аутсорсинговой компании именно глупые проджект-менеджеры нужны... С тех пор занимался разным - тренингами, стратегией.

Если ты такой умный, то почему не такой богатый? Кем вы будете через 10 лет? Кто сказал, что через 10 лет будет управлять цифровой компанией? А кто хочет? Три человека. Ответ почему вы не будете богатыми - потому что этого не хотите.

Будущее (Ваше, Компании, Страны) определяется тем, что вы делаете со своими ресурсами. Колесо: Развитие - Рост - Работа. Как делится ваш бюджет между этими направлениями?

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

Дальше был PEST-анализ (Politics, Economics, Social, Technology) современного общества и мифов о нем. Миф про устройство. Разумные осознанные граждане хорошо живут и выбирают лучших. Среди них есть средний класс, которые не оскорбляют верующих и так далее. Нас коробит, что наша элита, которую мы видим - вообще не элита. Они - иноагенты. К этой штуке прилагается социальный лифт.

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

Реально, за кулисами устроено так, если смотреть снизу-вверх.

• Хвостовики. низкоквалифицированная рабочая сила, соцработники, латиносы. Социальный лифт тяжелый, надо получить образование и много работать. Поскольку лифт тяжелый, их выбор не получить образования, а быть таксистами, водителями автобуса и так далее. В том числе - идти в нянечки - и получается, что они учат наших детей
• 70% 3 класс, низкоквалифицированная рабочая сила и соц.работники, бедные по воспитанию и убеждению. Без них - по прежнему не бывает. И педагоги школ - они там, и они передают свое представление о мире детям.
• 20% 2 класс, высококвалифицированная рабочая сила. Верят, что если много работать, то будет счастье. Нет, это обман: став PM ты получишь много работы и стрессов, и не получишь счастья.
• 5-6% псевдоэлита, первый класс, прислуга элиты: политики, адвокаты, звезды и прочие. Создают ложные идеалы для всех остальных - куда стремиться в жизни.
• элита 3-4% - номинальная вершина
• менее 1% - серые кардиналы, реальные бенефициары, далее называемые рептилоидами.

Около 100 лет в России социальной элиты не было - попадали не самые достойные и умные.

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

Ресурсы - у 1% серых кардиналов. И они за счет новых технологий хотят получить новыми технологиями и управлять, не нуждаясь в остальных. Серые кардиналы хотят обеспечить гарантированное доминирование. Отмечу, что тут противоречие: с одной стороны серым кардиналам не нужны шудры, а с другой стороны они гонятся за тем, чтобы обеспечить доминирование среди шудров.

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

Чтобы поменять правительство, которое лучшее для третьего класса, нужно чтобы третьего класса не было. Правительство удерживает стабильность третьего класса. И мы не сможем его поменять.

Айн Рэнд. Атлант расправляет плечи. В книге описаны архетипы общества.

• Политик, псевдоэлита. Единственным способом существования достойного видит эксплуатацию других, таскать каштаны чужими руками.
• Либерально-чувственный архетип - 1й класс. Паразитирует на тех, кто зарабатывает кто-то другой и эти ресурсы раздает.
• Хипстер прожектер - 1й класс. Чуваки, я заработаю много денег, для этого вы мне сейчас денег отвалите. Они только тратят деньги.
• Кто такой Джон Голд? Философия рационального эгоизма.

Что не написала Рэнд? Что вся элита нужна для того чтобы у работающих была цель.

Экономика. Бреттон-Вудская система. Эмиссия денег ФРС. За эти деньги можно купить только бижутерию - товары глубокой переработки. Все заработанные деньги элита России тратит в Лондоне. Мировые инфляции и кризисы. Как только мы скупили так много, что мир не тянет - надо кого-то выпотрошить. Чтобы последствия чрезмерного потребления надо устранить.

Мифы

• Развитая экономическая система должна быть сервисная. Меня постригут, я за это расскажу доклад +200$ к национальному доходу.
• Драйверы экономического роста являются технологические изменения. только вот бенефициары не меняются.
• Массовый рынок генерирует основную прибыль. Как бы элита ублажает массовый спрос - а это 3 класс, массовый потребитель, который не хочет думать. Приложение чтобы помочь женщинам прожить менструальный цикл, и около 500 data science чтобы вовлечь женщин в его потребление.

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

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