В конце мая прошла очередная, четырнадцатая #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
Писала для себя тезисный конспект батла по профессиональному развитию, может ещё кому-то будет интересно
Переход от личностного развития к лидерству, объединению людей и заданию направления
KOD knowledge of demand
Двухслойная эволюция
Можно войти в команду с минимальным опытом, чтобы обучиться
Чтобы выиграть в будущем, надо понимать, как изменится среда, в которой мы будем играть. Есть "я такой уникальный, попробую все" и разумная эволюция, где навыки сегодня готовятся на будущее
Вышеописанный процесс упускает пользу для себя и самоопределение. На этапе постановки цели нужно включать процесс самоопределения
К любому AsIs и ToBe должен быть приписан вектор изменений. Когда измеряешь движущийся объект, нужно учитывать вектор.
Ресурсы не надо готовить, надо понимать, какие есть.
"Глупо плыть на корабле и думать, что можешь выбрать свою траекторию". Нужно определить субъект, относительно которого строится траектория.
Рост - от границ эго к границам личности, к границам семьи, к границам общества
Think big act small. Нужны короткие шаги и периодическая переоценка цели
Если соглашаться на все возможности, вас растащат, не сможешь сконцентрироваться на цели
Контур самоопределения должен включать
Управлять ценностями = управление нашим кругом
Самоопределением надо заниматься в коллективе
Нас научили оценивать себя через других. Учиться оценивать себя самостоятельно (есть техники).
Независимое мнение - обязательное качество лидера
В каждой группе должен быть человек, который против, чтобы провоцировать обсуждение
База:
После этого:
Команда - нейросеть, каждый узел (член команды) должен развиваться своим путём (кто-то развивает лидерство, софт скиллы, кто-то хард)
У меня сложное отношение к докладу, а отзыве я буду писать о тех моментах, которые считаю проблемными.
При этом в докладе довольно много моделей - разделение задач важный-срочный; ситуационное лидерство; кривая обучения она же эффект Даннинга-Крюгера, разбирается их влияние на выполнение задачи. А эффект передачи всегда рассматривается многопланово, по критериям Компетенция-Качество-Производительность-Авторитет-Мотивация.
В целом в докладе получается преломление современных концептов делегирования, менеджмента, лидерства, agile-организации работы через призму традиционных способов организации, которые как-то интерпретировали все эти концепты по-своему, в частности сведя делегирование к назначению задачи. И это интересно как проявление различных типов корпоративных культур.
Как я уже отмечал, доклад занял первое место на конференции по голосованию участников, а значит именно такое содержание востребовано аудиторией.
Понятный рассказ про менторство, которое используется для погружения новичков в проект. У них мобильная разработка, 100+человек в департаменте, распределенная команда - Москва с удаленкой, регионы, подрядчики. Георгий как ментор работал с 5 аналитиками, 4 успешно прошли испытательный срок.
Когда выходит новый человек, то из команды выделяется наставник, обычно системный аналитик, который на испытательном сроке погружает в команду. Когда просят обучить новичка возникает вопрос "он умный или как я?". Ментор - входная точка контакта по всем вопросам. Не только производственный инструктаж, но и передача софт и хард скиллов.
Есть курс менторства: цели и процесс, модель HBDI доминант мышления (Herrmann Brain Dominance Instrument) и ситуационная модель лидерства.
Для новичка - есть документ Quick start. Его надо обновлять, review - часто подготовки к менторству. Там сообщая орг.информация, информация о команде и продукте, командные процессы, артефакты аналитика. Документ не надо перегружать. В разных командах Quick start разный, так как разные проекты и технологии.
А еще надо запланировать задачу для новичка, это реальная бизнесовая, а не учебная задача. И тут особенность: эти задачи обычно нужны еще вчера. И есть нетривиальная задача ментора сделать баланс между обучением новичка и скоростью решения задачи.
Работа начинается в первый день. Там не так много успевают, но там важно - встреча offline, если он в Москве. Личная встреча - чтобы познакомиться, узнать характер, понять взаимодействие - через созвон это сложно. А еще - проверка всех доступов, есть чеклист.
Первая неделя.
Испытательный срок
Помимо ментора есть куратор, с которым встреча раз в 2 недели, есть HR, ментора можно менять, если есть проблемы.
Менторство дает плюшки не только обучаемому, но и самому ментору.
Основной инструмент аналитика - мозги. Мозги содержат баги, и неплохо их бы знать. Ошибки, о которых Татьяна рассказывала - известны, но в докладе были их примеры проявления в работе аналитика из реальных проектов и техники их избегания именно в работе аналитика. И хотя я бы поспорил в привязке примеров к конкретным когнитивным искажениям, это не столь важно, потому что ошибки, примеры которых приведены, реально встречаются и их надо избегать.
Когнитивные ошибки стало популярной темой, современные исследования выделяют их до 2000, в докладе было 8.
В рассказе было около 20 типовых конфликтных ситуаций и советы по каждой из них одного из двух типов: как решать ситуацию. когда она возникла, и как работать, чтобы подобных ситуаций не возникало. Жаль, что при таком количестве ситуаций не было каких-то обобщений, классификаций, общих подходов. При работе с конфликтами они есть, и даже на материале доклада можно сформулировать общие принципы, обобщая несколько ситуаций. А так получается ощущение мозаики.
В современном мире наиболее распространена проектная или продуктовая организация. Она очень эффективна, но у нее есть свои минусы, которые компенсируются добавлением матричной структуры, объединением аналитиков разного уровня формальности.
Истории из жизни.
С этих историй начали делать матричную структуру, когда наряду с проектной или продуктовой организацией есть функциональные объединения.
Проблемы с проектной или продуктовой структурой.
Способы реализации матричной структурой отличаются уровнем формализации: можно делать альтернативную организационную структуру, а можно слабее формализованные центры компетенций или сообщества. Способ зависит от ситуации в компании, даже при неформальной структуре ее надо организовывать и выделять время аналитиков для работы в ней
Разделение ответственности между лидом команды и лидом аналитиков может быть разным, главное - зафиксировать принципы разделения и сделать это понятным всем аналитикам. Темы следующие.
Практики
Работают с банками, используют DDD и онтологию. В докладе рассказывали о тех новых компетенциях которые требует от аналитиков микросервисная архитектура. Все это - инженерные компетенции, и в ответах на вопросы Валера сказал, что аналитик, который ими не владеет, в современных enterprise-проектах не нужен.
Докладе начался интересной моделью от MS, в котором ИТ-система сравнивается с городом времен начала промышленной революции. Транспорт - протоколы, Склады - базы данных, Лавки - АПИ и так далее.
Что позволяют микросервисы
Последствия того, что микросервис делает один человек - семантическое безумие, разнородность названий для одного и того же. Сложности технологизации. Тяжело прогнозировать нагрузку, 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.
DSL дает единую точку правды, из которой идет генерация всего остального.
Пример - система для промоакций и скидок, а за ней по факту 11 систем, которые надо согласованно сконфигурировать, а при нестандартных акциях еще написать согласованный код - сделали DSL, который описывал эти акции, и из него для начала просто были проверки для всех систем, а потом - и генерацию для них всяких файлов. Ну и постепенно системы переписывали - они исторически наслоились за 20 лет до того, как заказчик к ним пришел.
Customer Journey Map: по столбцам - воронка взаимодействия с пользователем, по строкам - характеристики, которые нам интересно наблюдать и получать.
Они сделали CJM, извлечь из него пользу получилось не сразу и пока шли собрали много граблей. В докладе - анализ в виде вредных советов.
Почитать: Даниэль Канеман "Думай медленно, решай быстро", Джим Калбах "Путь клиента", Ариели "Умные решения". CJM о том, как люди принимают решения, и механизмы, как реально люди его принимают на смеси рациональных и эмоционального, и надо это учитывать.
В докладе Дима делился своей картиной нынешних геополитических изменений и устройства мира в целом. А также потенциалом аналитиков и вообще ИТ-шников в изменении мира. Дальше - конспект.
Доклад - плохой. У него много плохих докладов и плохих курсов. Потому что новое качественным не бывает. А он рассказывает новое. Идеи доклада - не политкорректные и не щадят нежные души. Он далек от Пелевина по вставке гадостей, но гадостей будет много. Надо что-нибудь гадкое сказать. Ладно: гуманитарии - одно из главных зол этого мира. Что, никто не уходит? Люксофт. За первый год не нанял ни одного из project-менеджеров со словами "он глуп и не понимает". Откуда ж я знал, что в аутсорсинговой компании именно глупые проджект-менеджеры нужны... С тех пор занимался разным - тренингами, стратегией.
Если ты такой умный, то почему не такой богатый? Кем вы будете через 10 лет? Кто сказал, что через 10 лет будет управлять цифровой компанией? А кто хочет? Три человека. Ответ почему вы не будете богатыми - потому что этого не хотите.
Будущее (Ваше, Компании, Страны) определяется тем, что вы делаете со своими ресурсами. Колесо: Развитие - Рост - Работа. Как делится ваш бюджет между этими направлениями?
Ложные ориентиры. Спиральная динамика. Какие-то гуманитарии решили, что наблюдение за одноэтажной Америкой 60-х может служить ориентиром. Я тут не могу не прокомментировать, что эти гуманитарии просто сняли из общественного сознания те мировоззренческие картины, которые формировала общественно-политическая мысль за последние 200 лет, что хорошо видно, если сопоставлять описание уровней с описанием эволюции общественно-политическая мысли Валлерстайном, об этом у меня есть статья. Впрочем, это не сильно важно.
Дальше был PEST-анализ (Politics, Economics, Social, Technology) современного общества и мифов о нем. Миф про устройство. Разумные осознанные граждане хорошо живут и выбирают лучших. Среди них есть средний класс, которые не оскорбляют верующих и так далее. Нас коробит, что наша элита, которую мы видим - вообще не элита. Они - иноагенты. К этой штуке прилагается социальный лифт.
Реально у нас продолжает жить индийская кастовая структура. Внизу - Неприкасаемые, над ними Шудры, они работают. Поэтому им нужны лэндлорды, которые направляют шудров куда надо. Шудры норовят бунт, поэтому нужны воины, кшатрии, которые борются с бунтами, и именно поэтому Индия проигрывала все войны - ее воины не для этого. Но дальше поняли, что удерживать через брахманов, и дальше там устроили пути развития. Система всеобщего счастья - сказка для шудров.
Реально, за кулисами устроено так, если смотреть снизу-вверх.
Около 100 лет в России социальной элиты не было - попадали не самые достойные и умные.
Развитие технологий приводит к тому, что больше шудры не нужны. И голубые воротнички тоже. Вместо 10к продавцов нужна команда тильды и те, кто настраивают страницы маркетинга.
Ресурсы - у 1% серых кардиналов. И они за счет новых технологий хотят получить новыми технологиями и управлять, не нуждаясь в остальных. Серые кардиналы хотят обеспечить гарантированное доминирование. Отмечу, что тут противоречие: с одной стороны серым кардиналам не нужны шудры, а с другой стороны они гонятся за тем, чтобы обеспечить доминирование среди шудров.
Дилемма среднего класса в этих условиях: либо учиться и подняться во второй, либо опуститься в дно, и тогда будет достаточно спички для бунта. Что делать? Надо тащить средний класс вверх. Все специальности будут ИТ плюс что-то еще. Врачи, механики и так далее должны владеть ИТ.
Чтобы поменять правительство, которое лучшее для третьего класса, нужно чтобы третьего класса не было. Правительство удерживает стабильность третьего класса. И мы не сможем его поменять.
Айн Рэнд. Атлант расправляет плечи. В книге описаны архетипы общества.
Что не написала Рэнд? Что вся элита нужна для того чтобы у работающих была цель.
Экономика. Бреттон-Вудская система. Эмиссия денег ФРС. За эти деньги можно купить только бижутерию - товары глубокой переработки. Все заработанные деньги элита России тратит в Лондоне. Мировые инфляции и кризисы. Как только мы скупили так много, что мир не тянет - надо кого-то выпотрошить. Чтобы последствия чрезмерного потребления надо устранить.
Мифы
Псевдоэлита с прозрачностью мира и ИТ-технологиями теряют свои позиции, и они это понимают - и им надо напугать сообщество, создать образ врага и так далее. И они это сейчас делают - именно в этом суть текущей геополитики. Наша страна выпиливается из матрицы. Через провокацию, чтобы матрица тебя выпихнула. Построить мир не ценности потребления, а ценности развития и создания. Кто-то еще хочет релоцироваться в добрый мир? Лично у него нет никакого желания платить своими желаниями за общую машину оболванивания.
Что делать с рептилоидами? Не работайте на них. Захватывайте власть своей компании. Если власть в ИТ компании станут нормальными людьми - все будет хорошо. Рептилоиды пойдут в тренеры, коучи и психологи - это прекрасно. Кто хочет управлять цифровой компанией, которая помогает достойно жить и поджимает гадких рептилоидов?