6903
правки
Изменения
Новая страница: «В конце мая прошла очередная, четырнадцатая [https://analystdays.ru/ru/program/93575 '''#AnalystDays''']. Я участвую…»
В конце мая прошла очередная, четырнадцатая [https://analystdays.ru/ru/program/93575 '''#AnalystDays''']. Я участвую в них с самой первой конференции в 2012 году, пропустив только одну в 2019 году. Это профильная для меня конференция, а среди участников много старых друзей и хорошее общение. И эта конференция не стала исключением. А еще по докладам можно посмотреть, что происходит в сообществе и как реально выполняются проекты. По способам работы аналитика и формату написания постановок это очень хорошо видно.
И тут стоит отметить несколько факторов. Докладов про то, как писать постановки, в программе практически не было - а это значит пользуются известными способами, никаких принципиальных новшеств тут нет. То есть изменения архитектуры приложений, переход на микросервисы слабо сказались на работе аналитика. А значит аналитик по-прежнему описывает преимущественно внешний формат работы приложения - через формы, user story, use case, функциональные требования и другими известными способами, а дизайн отдан разработчикам и в него аналитики не погружаются, максимум описывают структуры данных. Были доклады о том, как вести анализ данных и о том, как продавать бизнес-идеи. А еще - много докладов про софт-скилл, ведение проектов и обучение аналитиков. И вот здесь я вижу контраст между тем, что рассказывают на AnalystDays и тем, что я слышу на других конференциях, на котором много докладов по той же тематике - AgileDays, TeamLeadConf. Аналитики, которые были на конференции - мыслят в более традиционных процессах.
Характерный пример с первым докладом - он был посвящен делегированию, которое понималось как поручение конкретных задач. А вовсе не как передачу ответственности за определенную область, что характерно для выступлний на других конференциях. При этом доклад занял первое место по голосованию участников - а значит именно такой навык наиболее востребован. Может быть потому, что для передачи ответственности за определенную область, сначала надо научиться поручать конкретные задачи, чтобы они выполнялись. А этому - не учат, приходится осваивать самому. И в докладе это подробно было разобрано.
Так что в целом уровень докладов соответствует основной аудитории конференции. На этом я закончу о конференции в целом, и перехожу к конкретным докладам. Начну со своего, а дальше будут конспекты других докладов. Отмечу только, что уже в конце следующей недели будет ЛАФ, другая конференция аналитиков. Интересно будет сравнить впечатления.
= Мой доклад =
Мой доклад был про самоопределение: [[Как строить образ будущего и идти к нему - схемы самоопределения (AnalystDays-2022)|'''Как строить образ будущего и идти к нему''']]. Идея возникла после разговоров в кулуарах осенней AnalystDays. Доклад по самоопределению у меня уже был, я его [[Как строить свой профессиональный путь - схемы самоопределения (TeamLeadConf-2018)|'''рассказывал на Teamleadconf-2018''']], и еще на паре конференций. Но там фокус был на том, как идти к образу будущего, а фокуса на его построении - не было. Я предполагал, что люди понимают, что образ будущего должен вдохновлять на движение к нему, а не быть социально-одобренным "надо". И что люди умеют разбираться в своих желаниях и находить баланс между ними. Но, оказалось, что это - тоже актуальные вопросы, включая самоопределение при внутреннем конфликте ценностей. Со времени предыдущего доклада у меня появились схемы, посвященные этому, доклад был расширен и доработан.
Весенние события сильно подняли актуальность вопросов самоопределения, включая решение внутренних конфликтов ценности: геополитика начала гораздо активнее влиять на профессиональное самоопределение. Поэтому до конференции я успел рассказать доклад по этим слайдам еще пару раз, в том числе [[Как строить образ будущего и идти к нему - схемы самоопределения (Школа Системного менеджмента 2022)|'''на конференции Школы Системного менеджмента Анатолия Левенчука''']], где фокус, однако, был не на содержании слайдов, а на логике построения самого доклада как примера обучения самоопределению.
= Дискуссия с Димой Безуглым =
После доклада Дима Безуглый сказал, что не согласен с 95% (согласен с 1 из 20) и позвал на дуэль, которая состоялась на второй день после его доклада. В общем, народ пришел, но яростной схватки не получилось, оказалось, что при последовательном изложении мыслей большинство различий - в акцентах и терминах, а не в содержании. Мы развивали мысли друг друга, а не спорили.
Это было содержательно - два слота в зале баркемпов, потом еще слот в коридоре и на обеде, а потом продолжение обсуждений в кулуарах. Поэтому во второй день я был лишь на двух слотах докладов - но не жалею об этом. К сожалению, вести и обсуждение и конспектировать невозможно, а записи не было - это был баркемп. Но есть конспект от [http://t.me/Naaastyaaa @Naaastyaaa]
Писала для себя тезисный конспект батла по профессиональному развитию, может ещё кому-то будет интересно
Переход от личностного развития к лидерству, объединению людей и заданию направления
# Откуда брать цель? Самоопределение - выбор, кого усиливать
# Для реализации нужна команда. Развитие компетенций возможно только в команде
KOD knowledge of demand
Двухслойная эволюция
# ты развивается и толкаешь команду
# команда развивает тебя
Можно войти в команду с минимальным опытом, чтобы обучиться
Чтобы выиграть в будущем, надо понимать, как изменится среда, в которой мы будем играть. Есть "я такой уникальный, попробую все" и разумная эволюция, где навыки сегодня готовятся на будущее
# Дискавери - карта (в команде)
# Ресерч (в команде)
# Постановка цели
# Дизайн (использовать профили)
# Действия
Вышеописанный процесс упускает пользу для себя и самоопределение. На этапе постановки цели нужно включать процесс самоопределения
К любому AsIs и ToBe должен быть приписан вектор изменений. Когда измеряешь движущийся объект, нужно учитывать вектор.
Ресурсы не надо готовить, надо понимать, какие есть.
"Глупо плыть на корабле и думать, что можешь выбрать свою траекторию". Нужно определить субъект, относительно которого строится траектория.
Рост - от границ эго к границам личности, к границам семьи, к границам общества
Think big act small. Нужны короткие шаги и периодическая переоценка цели
Если соглашаться на все возможности, вас растащат, не сможешь сконцентрироваться на цели
Контур самоопределения должен включать
* себя
* команду
* страну
* человечество
Управлять ценностями = управление нашим кругом
: 10% мыслят самостоятельно, могут быть против всех
: 80% флюгер, сумма мыслей окружения
: 10% социопаты против всего
Самоопределением надо заниматься в коллективе
Нас научили оценивать себя через других. Учиться оценивать себя самостоятельно (есть техники).
Независимое мнение - обязательное качество лидера
В каждой группе должен быть человек, который против, чтобы провоцировать обсуждение
База:
* Эмоциональный интеллект
* Командный интеллект
После этого:
* Хард скиллы (kod)
Команда - нейросеть, каждый узел (член команды) должен развиваться своим путём (кто-то развивает лидерство, софт скиллы, кто-то хард)
= Наталья Семенова. Делегирование как инструмент лидерства, эффективности, мотивации и профессионального развития =
У меня сложное отношение к докладу, а отзыве я буду писать о тех моментах, которые считаю проблемными.
# Неясно, чем различается делегирование от простого назначения задачи для выполнения, я бы сказал, что любое назначение задачи называется делегированием, хотя различается передача выполнения и передача ответственности за результат. Впрочем, у Натальи тут есть основания, потому что она посмотрела определения, и там делегирование понимается как назначение задачи. И тут есть вопрос про источник такого определения и понимание тех, кто писал определение, потому что беглый поиск говорит преимущественно о делегировании полномочий, а не о передачи выполнения задачи.
# На входе Наталья, взяв определение делегирования как передачу от руководителя подчиненному, оговорила, что в современном Agile-мире все происходит не так, нет руководителей и подчиненных. Однако, дальше рассказ идет о передаче от старшего аналитику младшему, о должностных инструкциях и других атрибутах классической компании.
# Нет трассировки делегирования до его целей. Хотя про цели говорили, периодически они в рассказе всплывали, но трассировка всегда была в залоге, что передача таких-то задач достигает таких целей, в то время, как ход мыслей, скорее, должен быть другим: мы хотим достичь таких-то целей и потому передаем такие-то задачи.
# Любопытное разделение между лидером и менеджером. Менеджер - про работу, организует стабильный процесс и нацелен на качество результата. А Лидер - про людей, увлекает за собой и не слишком интересуется результатом. Но при этом конкретный человек может быть в обоих позициях и переключаться между ними. А может быть разделение, в ответах на вопросы прозвучало разделение функционального руководителя и руководителя проекта.
При этом в докладе довольно много моделей - разделение задач важный-срочный; ситуационное лидерство; кривая обучения она же эффект Даннинга-Крюгера, разбирается их влияние на выполнение задачи. А эффект передачи всегда рассматривается многопланово, по критериям Компетенция-Качество-Производительность-Авторитет-Мотивация.
В целом в докладе получается преломление современных концептов делегирования, менеджмента, лидерства, agile-организации работы через призму традиционных способов организации, которые как-то интерпретировали все эти концепты по-своему, в частности сведя делегирование к назначению задачи. И это интересно как проявление различных типов корпоративных культур.
Как я уже отмечал, доклад занял первое место на конференции по голосованию участников, а значит именно такое содержание востребовано аудиторией.
= Георгий Мысливец из Sportmaster Lab. PRO менторство в системном анализе =
Понятный рассказ про менторство, которое используется для погружения новичков в проект. У них мобильная разработка, 100+человек в департаменте, распределенная команда - Москва с удаленкой, регионы, подрядчики. Георгий как ментор работал с 5 аналитиками, 4 успешно прошли испытательный срок.
Когда выходит новый человек, то из команды выделяется наставник, обычно системный аналитик, который на испытательном сроке погружает в команду. Когда просят обучить новичка возникает вопрос "он умный или как я?". Ментор - входная точка контакта по всем вопросам. Не только производственный инструктаж, но и передача софт и хард скиллов.
Есть курс менторства: цели и процесс, модель HBDI доминант мышления (Herrmann Brain Dominance Instrument) и ситуационная модель лидерства.
Для новичка - есть документ Quick start. Его надо обновлять, review - часто подготовки к менторству. Там сообщая орг.информация, информация о команде и продукте, командные процессы, артефакты аналитика. Документ не надо перегружать. В разных командах Quick start разный, так как разные проекты и технологии.
А еще надо запланировать задачу для новичка, это реальная бизнесовая, а не учебная задача. И тут особенность: эти задачи обычно нужны еще вчера. И есть нетривиальная задача ментора сделать баланс между обучением новичка и скоростью решения задачи.
Работа начинается в первый день. Там не так много успевают, но там важно - встреча offline, если он в Москве. Личная встреча - чтобы познакомиться, узнать характер, понять взаимодействие - через созвон это сложно. А еще - проверка всех доступов, есть чеклист.
Первая неделя.
* Готовят план на весь испытательный срок, совместно с новичком - это удобно.
* Передать первую задачу в работу. Не более трех задач в неделю. Задача должна быть измеримой, то есть в результате должен быть конечный артефакт, который можно оценить. Задача должна погружать в продукт, в их случае основное - модель данных, интеграция со смежными системами, это не задача типа "перекрасить кнопку". И нести практическую пользу.
* Основной результат работы над задачей обычно диаграмма последовательности, отражающая вызовы между системами и работу с базой данных. Из нее следует, что нужно реализовать и что нужно проверить после реализации.
Испытательный срок
* План работ в confluence и еженедельный статус
* Канал коммуникации вопрос-ответ. Его надо наладить и в первые дни активно использовать, чтобы заработало. Нравился slack, но сейчас с ним проблемы, можно в confluence. Когда отвечает на вопросы, то старается следовать "не дай рыбу, но дай удочку" - чтобы он новичок научился разбираться в похожих задачах сам.
* Оформление постановки на изменение - есть шаблон.
* Регулярная обратная связь.
Помимо ментора есть куратор, с которым встреча раз в 2 недели, есть HR, ментора можно менять, если есть проблемы.
Менторство дает плюшки не только обучаемому, но и самому ментору.
* Чтобы погрузить новичка в продукт, ментор должен объяснить функционал продукта простыми словами, человеку, который вне контекста - и при этом ментор сам лучше осознает продукт и контекст работы.
* Обмен опытом - обучаемый новичок в компании, но у него часто есть собственный опыт работы, ценный для ментора.
* Поиск дыр в документации, ее актуализация
* Повышение собственного опыта коммуникации - помогает для взаимодействия с заказчиками, коллегами
= Татьяна Половинкина. Debugging мозга или гон тараканов =
Основной инструмент аналитика - мозги. Мозги содержат баги, и неплохо их бы знать. Ошибки, о которых Татьяна рассказывала - известны, но в докладе были их примеры проявления в работе аналитика из реальных проектов и техники их избегания именно в работе аналитика. И хотя я бы поспорил в привязке примеров к конкретным когнитивным искажениям, это не столь важно, потому что ошибки, примеры которых приведены, реально встречаются и их надо избегать.
Когнитивные ошибки стало популярной темой, современные исследования выделяют их до 2000, в докладе было 8.
# 2013 - Эффект Манделы. Он умер в 2013 году у себя дома, в 2015 решили сделать фильм и обнаружили, что многие люди верят что Мандела умер в 1975 году в тюрьме. Не единичные случаи. Эффект массовой ложной памяти начали исследовать, обнаружили массовый эффект. В презентации - многие примеры. Проявление в работе аналитика: вы проводите встречу, пишите протокол, и выясняете, что другие поняли договоренности совершенно по-другому. Способ борьбы - фиксация онлайн прямо на экране.
# Ошибка выжившего. Про самолеты во второй мировой. И про спасение дельфинами - они вовсе не обязательно толкают к берегу. В Бостоне было приложение, которое фиксировало ямы на дороге, и отправляло статистику дорожным службам. Обнаружилось, что самые плохие дороги в дорогих районах - просто потому что смартфоны преимущественно были у обеспеченных людей. Решение - проверяйте полноту исходных данных.
# Ошибка согласованности. Идея: дает пример трех чисел 2-4-6, говорит, что они удовлетворяют правилу, и предлагает назвать "аналогичные". Большинство порождает гипотезу, что речь идет о увеличивающихся числах, быть может по какому-то закону. Реально правило "любые три числа" - это не выясняют. Решение - примеры "от противного", мозговой штурм. Придумайте самую ужасную поликлинику - и проигрывайте на ней.
# Ошибка планирования. Недооценка времени и прочих затрат, требуемых для выполнения задачи. Сиднейский театр: срок строительства +10 лет и 102 млрд вместо 7! Оценка студентам "когда сделаете диплом". 50% оценили "в апреле", реально большинство сделали в мае, но 45% не сделали даже в июне к окончательному сроку диплома. Но это не только с дипломами: примерно столько же людей оказываются не готовыми к Рождеству, при чем регулярно и даже из тех, кто знает про эту ошибку.
# Фундаментальная ошибка атрибуции. Свои достижения объясняешь тем, что ты герой, чужие - случайностью, и наоборот, свои неудачи обстоятельствами, а чужие - их недостатками. Приходим к клиенту, говорим, что готовы мигрировать данные. Клиент говорит "у нас Excel"? думаем "попали в прошлый век", а реально там нормальная автоматизация, макросы. Решение - не торопитесь с выводами, переспрашивайте.
# Дилемма заключенного. Двух поймали, предлагают наябедничать, если оба молчат - каждому по году, если один ябедничает, то го отпустят, второму 10, а если оба - то каждому по 5. Поскольку люди другим не доверяют, то начинают ябедничать, и оба проигрывают. Но! при повторяющейся игре люди подчиняются.
# Эксперимент Милгрэма. Показывает предрасположенность подчиняться авторитету. Если ответственность на другом, или вам объяснили. что так положено, то вы можете творить ужасные вещи. Способ интеграции, у клиента была общая схема, которая в конкретном случае могла быть реализована только криво из-за технологических ограничений, предлагали альтернативные пути - он настаивал на кривом решении.
# Эффект Даннинга-Крюгера. Новичкам неизвестно, то что известно всем, это нормально, объясняйте и не ворчите.
= Илья Отькало. Управление конфликтами при внедрении и сопровождении информационной системы =
В рассказе было около 20 типовых конфликтных ситуаций и советы по каждой из них одного из двух типов: как решать ситуацию. когда она возникла, и как работать, чтобы подобных ситуаций не возникало. Жаль, что при таком количестве ситуаций не было каких-то обобщений, классификаций, общих подходов. При работе с конфликтами они есть, и даже на материале доклада можно сформулировать общие принципы, обобщая несколько ситуаций. А так получается ощущение мозаики.
# Ситуация: "Перенесите все данные за 3 года из SAP R3 в новую отечественную систему". При сильном различии структур данных. Что делать? Совет: Без паники, объясняем разницу структур данных и другие проблемы. Клиенту чаще всего надо смотреть отчеты, и можно договориться, чтобы это делали в старой системе.
# Ситуация. Перенесите из программы Ф1. Что такое Ф1 - никто не знает. Совет: Часто это какая-то специфическая система заказчика. В ней придется разобраться, но это - рабочая ситуация. И определять список переносимых данных, чаще всего целесообразен перенос больших справочников.
# Ситуация. Вот стопка первички, надо занести в новую программу при внедрении. Тяжело. Совет. Часто бывает достаточно занести итоги или что-то подобное.
# Ситуация. Почему я должен снова платить. если вы исправляете ошибку разработчика? Совет. Тут надо разграничить ответственность.
# Ситуация: "Совсем по-другому предлагала интерфейс, надо все переделать". Совет. Обсуждать и согласовывать эскизы.
# Ситуация: "Во многих ситуациях программа ведет не так, как я ожидала, исправляйте". Совет. Фиксация алгоритмов и передача заказчику с тестированием в разных ситуациях.
# Ситуация: "Предыдущий специалист работал быстрее". Совет. Тут надо вскрывать причины. Может быть, действительно, вам не хватает квалификации и надо подтянуть. Но может сложность самой программы выросла или вы начали работать с более сложным сегментом и так далее. Вам надо разбираться.
# Ситуация: Почему я должна столько ждать такую несложную задачу? Совет. Объяснять на что реально тратят время. Даже если не поймет технические детали - у него будет ощущение, что вы не бездельничаете.
# Ситуация: "Вы не понимаете задачу, не буду к вам обращаться". Совет. Тоже бывает, что не хватает квалификации, ее надо повышать - но в моменте надо обращаться к коллегам и к другим
# Ситуация: Не привыкла работать по типовому решению, переделайте. Совет. Говорите, что что любой каприз за ваши деньги, но при этом объясняете, чем чреват отход от типового решения и объем изменений в связанном функционале, который рассчитан на типовое решение.
# Ситуация Программа противоречит законодательству - про пользовательское соглашение, про закон о персональных данных. Совет. Для начала надо разобраться в проблеме конкретно. Если делали не вы - обратиться к разработчикам решения, у них часто есть ответ. Тут надо быть на стороне заказчика.
# Ситуация: БД рухнула, надо восстановить.сколько будет стоить. Совет. Тут главное - не давать невыполнимых обещаний, надо понимать, что будет затрачено время, гарантий нет - как оплачивать.
# Ситуация: Почему факт вырос вдвое после оценки. Совет: называйте осторожно и оговаривайте условия. При этом "не менее 20 часов" - плохо, воспринимается как "за 20 сделаю", надо называть "не меньше 20, думаю, за 40 точно получится".
# Ситуация: кто-то (менеджер) пообещал быстрее. Совет: тут надо разбираться.
# Ситуация: Я не понимают эти технические детали, этот термин. Или я на разбираюсь в этой бухгалтерии. Совет. Говорите на языке заказчика. Заранее узнайте, кто будет на встрече и подготовьтесь.
# Ситуация: "меня в принципе устраивает, но финдиректор не доволен". Совет: выявляется всех стейкхолдеров. и когда идет постановка - заранее выясняйте их мнение о предлагаемых решениях, прогнозируйте ситуацию.
# Ситуация: "Отдел кадров решил переходить на новую программу". Совет. Это саботаж. По разным причинам. С ним надо уметь разбираться. В том числе - помогать в переходе на новую систему, разбираться со страхах сокращения персонала, которые обычно не обоснованы.
# Ситуация: вас резко переводят на другой проект, как объяснить заказчику. Совет: надо найти достойного преемника, познакомиться, представить заказчику, обещать помощь новому сотруднику (и оговорить это внутри).
# Ситуация "К сожалению, пользователи не смоги разобраться в новом модуле". Совет: надо обучать, писать инструкции, и прогнозировать по модулю или фиче, потребуется ли это и в каком объеме.
= Татьяна Комиссарова. Как растить и развивать команду аналитиков в матричной организации =
В современном мире наиболее распространена проектная или продуктовая организация. Она очень эффективна, но у нее есть свои минусы, которые компенсируются добавлением матричной структуры, объединением аналитиков разного уровня формальности.
Истории из жизни.
* Ушел ведущий аналитик, который вел проект с глубокой кастомизацией. Выгребали больно, потому что аналитики соседних проектов не в курсе, хотя они внедряют то же базовое решение - нет общения.
* Проектная организация: в двух проектах сделали модель управления задачами, и третий - начал писать ТЗ
С этих историй начали делать матричную структуру, когда наряду с проектной или продуктовой организацией есть функциональные объединения.
Проблемы с проектной или продуктовой структурой.
* Аналитиков на проекте 1-3, они там замкнуты.
* Неясно как нанимать аналитиков - в команде часто нет профессиональных компетенций.
Способы реализации матричной структурой отличаются уровнем формализации: можно делать альтернативную организационную структуру, а можно слабее формализованные центры компетенций или сообщества. Способ зависит от ситуации в компании, даже при неформальной структуре ее надо организовывать и выделять время аналитиков для работы в ней
Разделение ответственности между лидом команды и лидом аналитиков может быть разным, главное - зафиксировать принципы разделения и сделать это понятным всем аналитикам. Темы следующие.
* Обмен практиками
* Снижение бас-фактора
* системы горизонтального и вертикального роста
* Мотивация
* Система найма и погружения сотрудников
* Погружение в предметную область
* Встраивание в работу конкретной команды
* Обеспечение задачами и информацией
Практики
* Регулярные встречи аналитиков по ходе проектов. К ним еще архитекторы подтянулись.
* Ретро-встречи. И задачи из них.
* Каналы коммуникации, для вопросов по опыту и помощи.
* База знаний и практик. Это не так просто, но есть прием - начинать с каталогов тех артефактов, которые так или иначе есть. это еще и стимулирует людей делать отторгаемое, общезначимое. Вместо каталогов можно тэгировать в общей системе тэгов. Еще каталог модулей.
* Ротация людей по проектам и практика в соседнем проекте.
* Единые процессы и практики в разных проектах. Только тут не надо навязывать, и не надо стандартизировать все. Должна быть польза и принятие самими аналитиками. Полезны единые шаблоны документов.
* Единые подходы к найму: процедура, этапы собеседований, типовые описания вакансий, типовые вопросы
* Единые подходы к погружению аналитика
* HR-бренд для аналитиков - внешние события, подкасты, статьи
* Рост и развитие. Учитывайте, что развитие нужно не всем.
* Матрица компетенций, карьерные треки
* План развития. Не делайте только из книжек и тренингов, должны быть практические задачи
* Мотивация - совместная зона ответственности лида аналитиков и лида проекта.
= Валерий Разномазов. Аналитика микросервисов. Практический опыт аналитика в enterprise =
Работают с банками, используют DDD и онтологию. В докладе рассказывали о тех новых компетенциях которые требует от аналитиков микросервисная архитектура. Все это - инженерные компетенции, и в ответах на вопросы Валера сказал, что аналитик, который ими не владеет, в современных enterprise-проектах не нужен.
Докладе начался интересной моделью от MS, в котором ИТ-система сравнивается с городом времен начала промышленной революции. Транспорт - протоколы, Склады - базы данных, Лавки - АПИ и так далее.
Что позволяют микросервисы
* Можно быстро заменить функционал - и угроза санкций резко повысила значимость такой замены.
* Масштабируемость, во всяком случае есть такой миф.
* Изменение технологий: с Java на php, на go, в масштабах монолита нельзя.
* Микросервис может сопровождаться одним человеком.
Последствия того, что микросервис делает один человек - семантическое безумие, разнородность названий для одного и того же. Сложности технологизации. Тяжело прогнозировать нагрузку, highload, который не масштабируется железом, возрастает риск утечки данных, проблемы релизов и многое другое.
Пандемия - карточные сервисы начали ложится, нагрузка возросла. Есть время отклика обработки карточного платежа, и если там конвейер микросервисов - то накладные расходы по обмену между ними его сильно кушают.
Способы взаимодействия: файл, БЛ, сообщения, http API. В этом аналитику надо разбираться.
Каждый сервис со своей моделью данных - отдельного администратора БД нет, надо разбираться аналитику, идемпотентность данных, безопасность данных, NoSQL базы данных. Еще вопрос дизайна. Дизайнер что-то согласовал с бизнесом. И там интерфейс намерения - вопрос данных, Дизайнер, Архитектор и Аналитик работают вместе. Соответствие между бизнес-сущностями и ИТ-реализацией. Однозначное соответствие с DTO и базой данных - а для этого надо разбираться в технической части.
Как распилить монолит на микросервисы? Куски кода не рождают семантику. Было удачное решение для кредитного конвейера, при механическом переносе та же архитектура для скоринга - не взлетает, нужно учитывать структуру бизнеса.
Оркестрация или хореография? Если стабильная понятная система, то лучше хореография, сами договорятся. А вот если там неясно или будет изменяться - то оркестрация лучше. И стартуем от бизнес-процесса.
Цитадель - архитектурный паттерн, при котором в микросервисы выносится лишь часть функционала, ядро остается в монолите. Монолит обеспечивает централизованное защищенное хранилище данных.
* В микросервисы выносим лишь изменчивые части.
* Жизненный цикл требований. Регуляторы пишут про будущие изменения.
* Выносим то, где нагрузка, внешние АПИ и так далее
* Никто в бизнесе не даст сломать старое - надо обеспечить непрерывность работы.
* Окружаем старый монолит аванпостами нового. И потихоньку заменяем - обращения в базу данных, интерфейс и так далее.
Оценка эффективности - ROI. Две базовых метрики: UpTime - время бесперебойной работы и Yield - время необработанных запросов. По ним оценивается стоимость, и дальше можно оценивать стоимость простоев.
Важнейшим артефактом становится тикет в Jira. Согласованные по стандартам (ГОСТ34, ITIL) не получается.
К тикету - дизайн в Figma, описание фичи в confluence, содель данных, обычно xsd. Коммиты в git - ссылаются на тикет.
= Антон Семенченко. Работа Аналитика при реализации zero code, low code, no code и DSL в примерах =
Антон сыплет афоризмами. Большинство проектов проваливаются, потому, что мы, следуя методологии, точно и в срок делаем то, о чем нас не просят.
То есть из-за плохой коммуникации. Нужен инструмент - ограничивал выразительность, давал гарантии, что наш проект из-за сложности не начал разваливаться.
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 лет до того, как заказчик к ним пришел.
= Ольга Бершель. Вредные советы по составлению CJM =
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 чтобы вовлечь женщин в его потребление.
Псевдоэлита с прозрачностью мира и ИТ-технологиями теряют свои позиции, и они это понимают - и им надо напугать сообщество, создать образ врага и так далее. И они это сейчас делают - именно в этом суть текущей геополитики. Наша страна выпиливается из матрицы. Через провокацию, чтобы матрица тебя выпихнула. Построить мир не ценности потребления, а ценности развития и создания. Кто-то еще хочет релоцироваться в добрый мир? Лично у него нет никакого желания платить своими желаниями за общую машину оболванивания.
Что делать с рептилоидами? Не работайте на них. Захватывайте власть своей компании. Если власть в ИТ компании станут нормальными людьми - все будет хорошо. Рептилоиды пойдут в тренеры, коучи и психологи - это прекрасно. Кто хочет управлять цифровой компанией, которая помогает достойно жить и поджимает гадких рептилоидов?
{{wl-publish: 2022-06-08 17:56:03 +0300 | MaksTsepkov }}
И тут стоит отметить несколько факторов. Докладов про то, как писать постановки, в программе практически не было - а это значит пользуются известными способами, никаких принципиальных новшеств тут нет. То есть изменения архитектуры приложений, переход на микросервисы слабо сказались на работе аналитика. А значит аналитик по-прежнему описывает преимущественно внешний формат работы приложения - через формы, user story, use case, функциональные требования и другими известными способами, а дизайн отдан разработчикам и в него аналитики не погружаются, максимум описывают структуры данных. Были доклады о том, как вести анализ данных и о том, как продавать бизнес-идеи. А еще - много докладов про софт-скилл, ведение проектов и обучение аналитиков. И вот здесь я вижу контраст между тем, что рассказывают на AnalystDays и тем, что я слышу на других конференциях, на котором много докладов по той же тематике - AgileDays, TeamLeadConf. Аналитики, которые были на конференции - мыслят в более традиционных процессах.
Характерный пример с первым докладом - он был посвящен делегированию, которое понималось как поручение конкретных задач. А вовсе не как передачу ответственности за определенную область, что характерно для выступлний на других конференциях. При этом доклад занял первое место по голосованию участников - а значит именно такой навык наиболее востребован. Может быть потому, что для передачи ответственности за определенную область, сначала надо научиться поручать конкретные задачи, чтобы они выполнялись. А этому - не учат, приходится осваивать самому. И в докладе это подробно было разобрано.
Так что в целом уровень докладов соответствует основной аудитории конференции. На этом я закончу о конференции в целом, и перехожу к конкретным докладам. Начну со своего, а дальше будут конспекты других докладов. Отмечу только, что уже в конце следующей недели будет ЛАФ, другая конференция аналитиков. Интересно будет сравнить впечатления.
= Мой доклад =
Мой доклад был про самоопределение: [[Как строить образ будущего и идти к нему - схемы самоопределения (AnalystDays-2022)|'''Как строить образ будущего и идти к нему''']]. Идея возникла после разговоров в кулуарах осенней AnalystDays. Доклад по самоопределению у меня уже был, я его [[Как строить свой профессиональный путь - схемы самоопределения (TeamLeadConf-2018)|'''рассказывал на Teamleadconf-2018''']], и еще на паре конференций. Но там фокус был на том, как идти к образу будущего, а фокуса на его построении - не было. Я предполагал, что люди понимают, что образ будущего должен вдохновлять на движение к нему, а не быть социально-одобренным "надо". И что люди умеют разбираться в своих желаниях и находить баланс между ними. Но, оказалось, что это - тоже актуальные вопросы, включая самоопределение при внутреннем конфликте ценностей. Со времени предыдущего доклада у меня появились схемы, посвященные этому, доклад был расширен и доработан.
Весенние события сильно подняли актуальность вопросов самоопределения, включая решение внутренних конфликтов ценности: геополитика начала гораздо активнее влиять на профессиональное самоопределение. Поэтому до конференции я успел рассказать доклад по этим слайдам еще пару раз, в том числе [[Как строить образ будущего и идти к нему - схемы самоопределения (Школа Системного менеджмента 2022)|'''на конференции Школы Системного менеджмента Анатолия Левенчука''']], где фокус, однако, был не на содержании слайдов, а на логике построения самого доклада как примера обучения самоопределению.
= Дискуссия с Димой Безуглым =
После доклада Дима Безуглый сказал, что не согласен с 95% (согласен с 1 из 20) и позвал на дуэль, которая состоялась на второй день после его доклада. В общем, народ пришел, но яростной схватки не получилось, оказалось, что при последовательном изложении мыслей большинство различий - в акцентах и терминах, а не в содержании. Мы развивали мысли друг друга, а не спорили.
Это было содержательно - два слота в зале баркемпов, потом еще слот в коридоре и на обеде, а потом продолжение обсуждений в кулуарах. Поэтому во второй день я был лишь на двух слотах докладов - но не жалею об этом. К сожалению, вести и обсуждение и конспектировать невозможно, а записи не было - это был баркемп. Но есть конспект от [http://t.me/Naaastyaaa @Naaastyaaa]
Писала для себя тезисный конспект батла по профессиональному развитию, может ещё кому-то будет интересно
Переход от личностного развития к лидерству, объединению людей и заданию направления
# Откуда брать цель? Самоопределение - выбор, кого усиливать
# Для реализации нужна команда. Развитие компетенций возможно только в команде
KOD knowledge of demand
Двухслойная эволюция
# ты развивается и толкаешь команду
# команда развивает тебя
Можно войти в команду с минимальным опытом, чтобы обучиться
Чтобы выиграть в будущем, надо понимать, как изменится среда, в которой мы будем играть. Есть "я такой уникальный, попробую все" и разумная эволюция, где навыки сегодня готовятся на будущее
# Дискавери - карта (в команде)
# Ресерч (в команде)
# Постановка цели
# Дизайн (использовать профили)
# Действия
Вышеописанный процесс упускает пользу для себя и самоопределение. На этапе постановки цели нужно включать процесс самоопределения
К любому AsIs и ToBe должен быть приписан вектор изменений. Когда измеряешь движущийся объект, нужно учитывать вектор.
Ресурсы не надо готовить, надо понимать, какие есть.
"Глупо плыть на корабле и думать, что можешь выбрать свою траекторию". Нужно определить субъект, относительно которого строится траектория.
Рост - от границ эго к границам личности, к границам семьи, к границам общества
Think big act small. Нужны короткие шаги и периодическая переоценка цели
Если соглашаться на все возможности, вас растащат, не сможешь сконцентрироваться на цели
Контур самоопределения должен включать
* себя
* команду
* страну
* человечество
Управлять ценностями = управление нашим кругом
: 10% мыслят самостоятельно, могут быть против всех
: 80% флюгер, сумма мыслей окружения
: 10% социопаты против всего
Самоопределением надо заниматься в коллективе
Нас научили оценивать себя через других. Учиться оценивать себя самостоятельно (есть техники).
Независимое мнение - обязательное качество лидера
В каждой группе должен быть человек, который против, чтобы провоцировать обсуждение
База:
* Эмоциональный интеллект
* Командный интеллект
После этого:
* Хард скиллы (kod)
Команда - нейросеть, каждый узел (член команды) должен развиваться своим путём (кто-то развивает лидерство, софт скиллы, кто-то хард)
= Наталья Семенова. Делегирование как инструмент лидерства, эффективности, мотивации и профессионального развития =
У меня сложное отношение к докладу, а отзыве я буду писать о тех моментах, которые считаю проблемными.
# Неясно, чем различается делегирование от простого назначения задачи для выполнения, я бы сказал, что любое назначение задачи называется делегированием, хотя различается передача выполнения и передача ответственности за результат. Впрочем, у Натальи тут есть основания, потому что она посмотрела определения, и там делегирование понимается как назначение задачи. И тут есть вопрос про источник такого определения и понимание тех, кто писал определение, потому что беглый поиск говорит преимущественно о делегировании полномочий, а не о передачи выполнения задачи.
# На входе Наталья, взяв определение делегирования как передачу от руководителя подчиненному, оговорила, что в современном Agile-мире все происходит не так, нет руководителей и подчиненных. Однако, дальше рассказ идет о передаче от старшего аналитику младшему, о должностных инструкциях и других атрибутах классической компании.
# Нет трассировки делегирования до его целей. Хотя про цели говорили, периодически они в рассказе всплывали, но трассировка всегда была в залоге, что передача таких-то задач достигает таких целей, в то время, как ход мыслей, скорее, должен быть другим: мы хотим достичь таких-то целей и потому передаем такие-то задачи.
# Любопытное разделение между лидером и менеджером. Менеджер - про работу, организует стабильный процесс и нацелен на качество результата. А Лидер - про людей, увлекает за собой и не слишком интересуется результатом. Но при этом конкретный человек может быть в обоих позициях и переключаться между ними. А может быть разделение, в ответах на вопросы прозвучало разделение функционального руководителя и руководителя проекта.
При этом в докладе довольно много моделей - разделение задач важный-срочный; ситуационное лидерство; кривая обучения она же эффект Даннинга-Крюгера, разбирается их влияние на выполнение задачи. А эффект передачи всегда рассматривается многопланово, по критериям Компетенция-Качество-Производительность-Авторитет-Мотивация.
В целом в докладе получается преломление современных концептов делегирования, менеджмента, лидерства, agile-организации работы через призму традиционных способов организации, которые как-то интерпретировали все эти концепты по-своему, в частности сведя делегирование к назначению задачи. И это интересно как проявление различных типов корпоративных культур.
Как я уже отмечал, доклад занял первое место на конференции по голосованию участников, а значит именно такое содержание востребовано аудиторией.
= Георгий Мысливец из Sportmaster Lab. PRO менторство в системном анализе =
Понятный рассказ про менторство, которое используется для погружения новичков в проект. У них мобильная разработка, 100+человек в департаменте, распределенная команда - Москва с удаленкой, регионы, подрядчики. Георгий как ментор работал с 5 аналитиками, 4 успешно прошли испытательный срок.
Когда выходит новый человек, то из команды выделяется наставник, обычно системный аналитик, который на испытательном сроке погружает в команду. Когда просят обучить новичка возникает вопрос "он умный или как я?". Ментор - входная точка контакта по всем вопросам. Не только производственный инструктаж, но и передача софт и хард скиллов.
Есть курс менторства: цели и процесс, модель HBDI доминант мышления (Herrmann Brain Dominance Instrument) и ситуационная модель лидерства.
Для новичка - есть документ Quick start. Его надо обновлять, review - часто подготовки к менторству. Там сообщая орг.информация, информация о команде и продукте, командные процессы, артефакты аналитика. Документ не надо перегружать. В разных командах Quick start разный, так как разные проекты и технологии.
А еще надо запланировать задачу для новичка, это реальная бизнесовая, а не учебная задача. И тут особенность: эти задачи обычно нужны еще вчера. И есть нетривиальная задача ментора сделать баланс между обучением новичка и скоростью решения задачи.
Работа начинается в первый день. Там не так много успевают, но там важно - встреча offline, если он в Москве. Личная встреча - чтобы познакомиться, узнать характер, понять взаимодействие - через созвон это сложно. А еще - проверка всех доступов, есть чеклист.
Первая неделя.
* Готовят план на весь испытательный срок, совместно с новичком - это удобно.
* Передать первую задачу в работу. Не более трех задач в неделю. Задача должна быть измеримой, то есть в результате должен быть конечный артефакт, который можно оценить. Задача должна погружать в продукт, в их случае основное - модель данных, интеграция со смежными системами, это не задача типа "перекрасить кнопку". И нести практическую пользу.
* Основной результат работы над задачей обычно диаграмма последовательности, отражающая вызовы между системами и работу с базой данных. Из нее следует, что нужно реализовать и что нужно проверить после реализации.
Испытательный срок
* План работ в confluence и еженедельный статус
* Канал коммуникации вопрос-ответ. Его надо наладить и в первые дни активно использовать, чтобы заработало. Нравился slack, но сейчас с ним проблемы, можно в confluence. Когда отвечает на вопросы, то старается следовать "не дай рыбу, но дай удочку" - чтобы он новичок научился разбираться в похожих задачах сам.
* Оформление постановки на изменение - есть шаблон.
* Регулярная обратная связь.
Помимо ментора есть куратор, с которым встреча раз в 2 недели, есть HR, ментора можно менять, если есть проблемы.
Менторство дает плюшки не только обучаемому, но и самому ментору.
* Чтобы погрузить новичка в продукт, ментор должен объяснить функционал продукта простыми словами, человеку, который вне контекста - и при этом ментор сам лучше осознает продукт и контекст работы.
* Обмен опытом - обучаемый новичок в компании, но у него часто есть собственный опыт работы, ценный для ментора.
* Поиск дыр в документации, ее актуализация
* Повышение собственного опыта коммуникации - помогает для взаимодействия с заказчиками, коллегами
= Татьяна Половинкина. Debugging мозга или гон тараканов =
Основной инструмент аналитика - мозги. Мозги содержат баги, и неплохо их бы знать. Ошибки, о которых Татьяна рассказывала - известны, но в докладе были их примеры проявления в работе аналитика из реальных проектов и техники их избегания именно в работе аналитика. И хотя я бы поспорил в привязке примеров к конкретным когнитивным искажениям, это не столь важно, потому что ошибки, примеры которых приведены, реально встречаются и их надо избегать.
Когнитивные ошибки стало популярной темой, современные исследования выделяют их до 2000, в докладе было 8.
# 2013 - Эффект Манделы. Он умер в 2013 году у себя дома, в 2015 решили сделать фильм и обнаружили, что многие люди верят что Мандела умер в 1975 году в тюрьме. Не единичные случаи. Эффект массовой ложной памяти начали исследовать, обнаружили массовый эффект. В презентации - многие примеры. Проявление в работе аналитика: вы проводите встречу, пишите протокол, и выясняете, что другие поняли договоренности совершенно по-другому. Способ борьбы - фиксация онлайн прямо на экране.
# Ошибка выжившего. Про самолеты во второй мировой. И про спасение дельфинами - они вовсе не обязательно толкают к берегу. В Бостоне было приложение, которое фиксировало ямы на дороге, и отправляло статистику дорожным службам. Обнаружилось, что самые плохие дороги в дорогих районах - просто потому что смартфоны преимущественно были у обеспеченных людей. Решение - проверяйте полноту исходных данных.
# Ошибка согласованности. Идея: дает пример трех чисел 2-4-6, говорит, что они удовлетворяют правилу, и предлагает назвать "аналогичные". Большинство порождает гипотезу, что речь идет о увеличивающихся числах, быть может по какому-то закону. Реально правило "любые три числа" - это не выясняют. Решение - примеры "от противного", мозговой штурм. Придумайте самую ужасную поликлинику - и проигрывайте на ней.
# Ошибка планирования. Недооценка времени и прочих затрат, требуемых для выполнения задачи. Сиднейский театр: срок строительства +10 лет и 102 млрд вместо 7! Оценка студентам "когда сделаете диплом". 50% оценили "в апреле", реально большинство сделали в мае, но 45% не сделали даже в июне к окончательному сроку диплома. Но это не только с дипломами: примерно столько же людей оказываются не готовыми к Рождеству, при чем регулярно и даже из тех, кто знает про эту ошибку.
# Фундаментальная ошибка атрибуции. Свои достижения объясняешь тем, что ты герой, чужие - случайностью, и наоборот, свои неудачи обстоятельствами, а чужие - их недостатками. Приходим к клиенту, говорим, что готовы мигрировать данные. Клиент говорит "у нас Excel"? думаем "попали в прошлый век", а реально там нормальная автоматизация, макросы. Решение - не торопитесь с выводами, переспрашивайте.
# Дилемма заключенного. Двух поймали, предлагают наябедничать, если оба молчат - каждому по году, если один ябедничает, то го отпустят, второму 10, а если оба - то каждому по 5. Поскольку люди другим не доверяют, то начинают ябедничать, и оба проигрывают. Но! при повторяющейся игре люди подчиняются.
# Эксперимент Милгрэма. Показывает предрасположенность подчиняться авторитету. Если ответственность на другом, или вам объяснили. что так положено, то вы можете творить ужасные вещи. Способ интеграции, у клиента была общая схема, которая в конкретном случае могла быть реализована только криво из-за технологических ограничений, предлагали альтернативные пути - он настаивал на кривом решении.
# Эффект Даннинга-Крюгера. Новичкам неизвестно, то что известно всем, это нормально, объясняйте и не ворчите.
= Илья Отькало. Управление конфликтами при внедрении и сопровождении информационной системы =
В рассказе было около 20 типовых конфликтных ситуаций и советы по каждой из них одного из двух типов: как решать ситуацию. когда она возникла, и как работать, чтобы подобных ситуаций не возникало. Жаль, что при таком количестве ситуаций не было каких-то обобщений, классификаций, общих подходов. При работе с конфликтами они есть, и даже на материале доклада можно сформулировать общие принципы, обобщая несколько ситуаций. А так получается ощущение мозаики.
# Ситуация: "Перенесите все данные за 3 года из SAP R3 в новую отечественную систему". При сильном различии структур данных. Что делать? Совет: Без паники, объясняем разницу структур данных и другие проблемы. Клиенту чаще всего надо смотреть отчеты, и можно договориться, чтобы это делали в старой системе.
# Ситуация. Перенесите из программы Ф1. Что такое Ф1 - никто не знает. Совет: Часто это какая-то специфическая система заказчика. В ней придется разобраться, но это - рабочая ситуация. И определять список переносимых данных, чаще всего целесообразен перенос больших справочников.
# Ситуация. Вот стопка первички, надо занести в новую программу при внедрении. Тяжело. Совет. Часто бывает достаточно занести итоги или что-то подобное.
# Ситуация. Почему я должен снова платить. если вы исправляете ошибку разработчика? Совет. Тут надо разграничить ответственность.
# Ситуация: "Совсем по-другому предлагала интерфейс, надо все переделать". Совет. Обсуждать и согласовывать эскизы.
# Ситуация: "Во многих ситуациях программа ведет не так, как я ожидала, исправляйте". Совет. Фиксация алгоритмов и передача заказчику с тестированием в разных ситуациях.
# Ситуация: "Предыдущий специалист работал быстрее". Совет. Тут надо вскрывать причины. Может быть, действительно, вам не хватает квалификации и надо подтянуть. Но может сложность самой программы выросла или вы начали работать с более сложным сегментом и так далее. Вам надо разбираться.
# Ситуация: Почему я должна столько ждать такую несложную задачу? Совет. Объяснять на что реально тратят время. Даже если не поймет технические детали - у него будет ощущение, что вы не бездельничаете.
# Ситуация: "Вы не понимаете задачу, не буду к вам обращаться". Совет. Тоже бывает, что не хватает квалификации, ее надо повышать - но в моменте надо обращаться к коллегам и к другим
# Ситуация: Не привыкла работать по типовому решению, переделайте. Совет. Говорите, что что любой каприз за ваши деньги, но при этом объясняете, чем чреват отход от типового решения и объем изменений в связанном функционале, который рассчитан на типовое решение.
# Ситуация Программа противоречит законодательству - про пользовательское соглашение, про закон о персональных данных. Совет. Для начала надо разобраться в проблеме конкретно. Если делали не вы - обратиться к разработчикам решения, у них часто есть ответ. Тут надо быть на стороне заказчика.
# Ситуация: БД рухнула, надо восстановить.сколько будет стоить. Совет. Тут главное - не давать невыполнимых обещаний, надо понимать, что будет затрачено время, гарантий нет - как оплачивать.
# Ситуация: Почему факт вырос вдвое после оценки. Совет: называйте осторожно и оговаривайте условия. При этом "не менее 20 часов" - плохо, воспринимается как "за 20 сделаю", надо называть "не меньше 20, думаю, за 40 точно получится".
# Ситуация: кто-то (менеджер) пообещал быстрее. Совет: тут надо разбираться.
# Ситуация: Я не понимают эти технические детали, этот термин. Или я на разбираюсь в этой бухгалтерии. Совет. Говорите на языке заказчика. Заранее узнайте, кто будет на встрече и подготовьтесь.
# Ситуация: "меня в принципе устраивает, но финдиректор не доволен". Совет: выявляется всех стейкхолдеров. и когда идет постановка - заранее выясняйте их мнение о предлагаемых решениях, прогнозируйте ситуацию.
# Ситуация: "Отдел кадров решил переходить на новую программу". Совет. Это саботаж. По разным причинам. С ним надо уметь разбираться. В том числе - помогать в переходе на новую систему, разбираться со страхах сокращения персонала, которые обычно не обоснованы.
# Ситуация: вас резко переводят на другой проект, как объяснить заказчику. Совет: надо найти достойного преемника, познакомиться, представить заказчику, обещать помощь новому сотруднику (и оговорить это внутри).
# Ситуация "К сожалению, пользователи не смоги разобраться в новом модуле". Совет: надо обучать, писать инструкции, и прогнозировать по модулю или фиче, потребуется ли это и в каком объеме.
= Татьяна Комиссарова. Как растить и развивать команду аналитиков в матричной организации =
В современном мире наиболее распространена проектная или продуктовая организация. Она очень эффективна, но у нее есть свои минусы, которые компенсируются добавлением матричной структуры, объединением аналитиков разного уровня формальности.
Истории из жизни.
* Ушел ведущий аналитик, который вел проект с глубокой кастомизацией. Выгребали больно, потому что аналитики соседних проектов не в курсе, хотя они внедряют то же базовое решение - нет общения.
* Проектная организация: в двух проектах сделали модель управления задачами, и третий - начал писать ТЗ
С этих историй начали делать матричную структуру, когда наряду с проектной или продуктовой организацией есть функциональные объединения.
Проблемы с проектной или продуктовой структурой.
* Аналитиков на проекте 1-3, они там замкнуты.
* Неясно как нанимать аналитиков - в команде часто нет профессиональных компетенций.
Способы реализации матричной структурой отличаются уровнем формализации: можно делать альтернативную организационную структуру, а можно слабее формализованные центры компетенций или сообщества. Способ зависит от ситуации в компании, даже при неформальной структуре ее надо организовывать и выделять время аналитиков для работы в ней
Разделение ответственности между лидом команды и лидом аналитиков может быть разным, главное - зафиксировать принципы разделения и сделать это понятным всем аналитикам. Темы следующие.
* Обмен практиками
* Снижение бас-фактора
* системы горизонтального и вертикального роста
* Мотивация
* Система найма и погружения сотрудников
* Погружение в предметную область
* Встраивание в работу конкретной команды
* Обеспечение задачами и информацией
Практики
* Регулярные встречи аналитиков по ходе проектов. К ним еще архитекторы подтянулись.
* Ретро-встречи. И задачи из них.
* Каналы коммуникации, для вопросов по опыту и помощи.
* База знаний и практик. Это не так просто, но есть прием - начинать с каталогов тех артефактов, которые так или иначе есть. это еще и стимулирует людей делать отторгаемое, общезначимое. Вместо каталогов можно тэгировать в общей системе тэгов. Еще каталог модулей.
* Ротация людей по проектам и практика в соседнем проекте.
* Единые процессы и практики в разных проектах. Только тут не надо навязывать, и не надо стандартизировать все. Должна быть польза и принятие самими аналитиками. Полезны единые шаблоны документов.
* Единые подходы к найму: процедура, этапы собеседований, типовые описания вакансий, типовые вопросы
* Единые подходы к погружению аналитика
* HR-бренд для аналитиков - внешние события, подкасты, статьи
* Рост и развитие. Учитывайте, что развитие нужно не всем.
* Матрица компетенций, карьерные треки
* План развития. Не делайте только из книжек и тренингов, должны быть практические задачи
* Мотивация - совместная зона ответственности лида аналитиков и лида проекта.
= Валерий Разномазов. Аналитика микросервисов. Практический опыт аналитика в enterprise =
Работают с банками, используют DDD и онтологию. В докладе рассказывали о тех новых компетенциях которые требует от аналитиков микросервисная архитектура. Все это - инженерные компетенции, и в ответах на вопросы Валера сказал, что аналитик, который ими не владеет, в современных enterprise-проектах не нужен.
Докладе начался интересной моделью от MS, в котором ИТ-система сравнивается с городом времен начала промышленной революции. Транспорт - протоколы, Склады - базы данных, Лавки - АПИ и так далее.
Что позволяют микросервисы
* Можно быстро заменить функционал - и угроза санкций резко повысила значимость такой замены.
* Масштабируемость, во всяком случае есть такой миф.
* Изменение технологий: с Java на php, на go, в масштабах монолита нельзя.
* Микросервис может сопровождаться одним человеком.
Последствия того, что микросервис делает один человек - семантическое безумие, разнородность названий для одного и того же. Сложности технологизации. Тяжело прогнозировать нагрузку, highload, который не масштабируется железом, возрастает риск утечки данных, проблемы релизов и многое другое.
Пандемия - карточные сервисы начали ложится, нагрузка возросла. Есть время отклика обработки карточного платежа, и если там конвейер микросервисов - то накладные расходы по обмену между ними его сильно кушают.
Способы взаимодействия: файл, БЛ, сообщения, http API. В этом аналитику надо разбираться.
Каждый сервис со своей моделью данных - отдельного администратора БД нет, надо разбираться аналитику, идемпотентность данных, безопасность данных, NoSQL базы данных. Еще вопрос дизайна. Дизайнер что-то согласовал с бизнесом. И там интерфейс намерения - вопрос данных, Дизайнер, Архитектор и Аналитик работают вместе. Соответствие между бизнес-сущностями и ИТ-реализацией. Однозначное соответствие с DTO и базой данных - а для этого надо разбираться в технической части.
Как распилить монолит на микросервисы? Куски кода не рождают семантику. Было удачное решение для кредитного конвейера, при механическом переносе та же архитектура для скоринга - не взлетает, нужно учитывать структуру бизнеса.
Оркестрация или хореография? Если стабильная понятная система, то лучше хореография, сами договорятся. А вот если там неясно или будет изменяться - то оркестрация лучше. И стартуем от бизнес-процесса.
Цитадель - архитектурный паттерн, при котором в микросервисы выносится лишь часть функционала, ядро остается в монолите. Монолит обеспечивает централизованное защищенное хранилище данных.
* В микросервисы выносим лишь изменчивые части.
* Жизненный цикл требований. Регуляторы пишут про будущие изменения.
* Выносим то, где нагрузка, внешние АПИ и так далее
* Никто в бизнесе не даст сломать старое - надо обеспечить непрерывность работы.
* Окружаем старый монолит аванпостами нового. И потихоньку заменяем - обращения в базу данных, интерфейс и так далее.
Оценка эффективности - ROI. Две базовых метрики: UpTime - время бесперебойной работы и Yield - время необработанных запросов. По ним оценивается стоимость, и дальше можно оценивать стоимость простоев.
Важнейшим артефактом становится тикет в Jira. Согласованные по стандартам (ГОСТ34, ITIL) не получается.
К тикету - дизайн в Figma, описание фичи в confluence, содель данных, обычно xsd. Коммиты в git - ссылаются на тикет.
= Антон Семенченко. Работа Аналитика при реализации zero code, low code, no code и DSL в примерах =
Антон сыплет афоризмами. Большинство проектов проваливаются, потому, что мы, следуя методологии, точно и в срок делаем то, о чем нас не просят.
То есть из-за плохой коммуникации. Нужен инструмент - ограничивал выразительность, давал гарантии, что наш проект из-за сложности не начал разваливаться.
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 лет до того, как заказчик к ним пришел.
= Ольга Бершель. Вредные советы по составлению CJM =
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 чтобы вовлечь женщин в его потребление.
Псевдоэлита с прозрачностью мира и ИТ-технологиями теряют свои позиции, и они это понимают - и им надо напугать сообщество, создать образ врага и так далее. И они это сейчас делают - именно в этом суть текущей геополитики. Наша страна выпиливается из матрицы. Через провокацию, чтобы матрица тебя выпихнула. Построить мир не ценности потребления, а ценности развития и создания. Кто-то еще хочет релоцироваться в добрый мир? Лично у него нет никакого желания платить своими желаниями за общую машину оболванивания.
Что делать с рептилоидами? Не работайте на них. Захватывайте власть своей компании. Если власть в ИТ компании станут нормальными людьми - все будет хорошо. Рептилоиды пойдут в тренеры, коучи и психологи - это прекрасно. Кто хочет управлять цифровой компанией, которая помогает достойно жить и поджимает гадких рептилоидов?
{{wl-publish: 2022-06-08 17:56:03 +0300 | MaksTsepkov }}
