2022-06-22: ЛАФ - море общения и содержательные доклады
В прошедшие выходные был на ЛАФ-2022 — Летнем аналитическом фестивале. Это тоже конференция аналитиков, но по формату и атмосфере она очень сильно отличается от AnalystDays. И сопоставима по количеству участников — было несколько меньше 500 человек. ЛАФ проводится с 2010 и первые годы был в Иваново: суббота была с докладами в офисе, вечером ехали на турбазу, шашлыки и общение, а в воскресенье продолжали работать — не взирая на открывающиеся возможности для отдыха. А несколько последних лет оба дня проходят на турбазе или доме отдыха в разных местах. Были Владимир, Тверская область, Кострома, а в этом году — Софрино в Подмосковье. И благодаря формату на фестивале царит атмосфера активных знакомств участников и общения. Тем более, что в пятницу вечером, после заезда, был командный квиз и дискотека, а в субботу — афтерпати с живой музыкой, танцами и шашлыками. Пати завершилось около полуночи, но общение продолжалось до полтретьего минимум, потом я ушел спать.
Что интересно, от AnalystDays отличается не только формат конференции, но и состав докладов, можете посмотреть сами программы: ЛАФ и AnalystDays. На ЛАФ гораздо больше докладов про профессиональную работу аналитика и кейсов конкретных проектов. При этом, конечно, получилось меньше докладов по softskill, хотя они тоже были. Но, как и на AnalystDays докладов, связанных с особенностями работы аналитика в микросервисной архитектуре — не было. Да, были доклады по интеграции, но в них обычная логика, свойственная enterprise-приложениям, а не ситуации, когда запрос пользователя обрабатывается несколькими сервисами и надо обеспечить надежный отклик за приемлемое время при их асинхронной работе. И доклад Дмитрия Морякова про распил монолита задача про минимизацию связей выделяемой части ставилась, но способ решения был в тщательном анализе этих связей, который выполняет аналитик по выделенной архитекторами части, известными методами.
Из докладов я хочу отметить Екатерины Подолиной про визуализацию, пригодную чтобы показать 20к элементов в комплексной картине. Очень интересный способ.
Я сам делал доклад про способы описания бизнес-архитектуры. И участвовал в круглом столе «Почему индустрии нужны проектировщики, а не аналитики?» Это заняло полдня, а дальше я слушал доклады и вел репортаж в телеграме в ходе конференции. Рассказ об этом — дальше в отчете. Надо отметить, что рассказ заведомо не полон: на конференции было пять треков. Кроме того, параллельно с моими выступлениями шли выступления очень хороших спикеров, которые я тоже пропустил. Жаль.
До описания докладов — пара слов о площадке. В целом площадка Софрино — хорошая. Мне лично по атмосфере прошлогодняя под Костромой на берегу Волги в лесу понравилась больше, чем парк Софрино, но это уже вопросы личного вкуса. Я знаю, что участникам понравились бассейн и рыбалка. Но у Софрино есть несколько системных недостатков, один — критичный. Во многих номерах — ровно одна розетка в комнате, высоко на стене рядом с телевизором, так что без удлинителя при подключении зарядки телефон просто висит в воздухе, да и у ноутов не всегда хватает длины провода, в результате он может лежать на полу на проходе с рисками наступить. Проблема лечится удлинителем, я совершенно случайно с собой взял, можно было сильно поругавшись получить на ресепшн, но количество ограничено. Если в следующем году будет там же, то в письмо участникам стоит написать об этом недостатке, чтобы они взяли удлинители. А еще — большие полотенца, потому что отельные очень малы, и ножницы, чтобы открывать шампуни и гели для душа, пакеты руками не разрываются (один из пяти поддался). А если будут искать другую площадку, то, может, стоит завести чеклист проверки для номеров так же как для конференционных залов — чтобы такие предупреждения формировать.
Но, несмотря на отдельные недостатки, конференция прошла великолепно. Громадное спасибо организаторам и программному комитету за прекрасную, вдохновляющую конференцию и качественную программу! И всем участникам - за море общения!
Содержание
[убрать]- 1 Мой доклад — о бизнес-архитектуре
- 2 Круглый стол
- 3 Александр Скоробутов, Татьяна Тимофеева. Введение нового человека в проект. Антипаттерны и подводные камни для наставника — как найти верный путь
- 4 Ирина Гертовская. Отдел системного анализа: создать, развить, расширить. Дорожная карта и путевые заметки
- 5 Дмитрий Безуглый. Не слепая эволюция. Системный подход в работе и жизни
- 6 Анжелика Арсланова. Работа с источниками данных и изменениями. Чек-лист для изменений
- 7 Дмитрий Моряков. Изоляция микросервисов по данным при миграции с монолита
- 8 Екатерина Подолина. Растим деревья на данных и тушим пожар риск-мониторинга
- 9 Владимир Баймаков. Просто о сложном: о моделях данных, интеграциях и баре
Мой доклад — о бизнес-архитектуре
Мой доклад Бизнес-архитектура: от цепочки создания ценности до автоматизации бизнес-процессов был про разные способы описывать бизнес-архитектуру. Обычно это принято делать через описание бизнес-процессов, но такой способ имеет множество проблем, особенно напрактике — думаю, все встречались с толстыми описаниями со множеством диаграмм, которые не соответствуют реальному положению дел, и плохо понимаются сотрудниками компании, которые вроде должны по этим процессам работать. Я говорил об альтернативных способах. Это 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 — бар с бочкой и ковшиком, из которой сам наливаешь пиво. Очень просто — скорость и простота. Вместе с рисками — грязный ковшик, неаккуратный посетитель, могут всю бочку опрокинуть.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.