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

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

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

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

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

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

Содержание

Мой доклад

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

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

Дискуссия с Димой Безуглым

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

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

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

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

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

KOD knowledge of demand

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10% мыслят самостоятельно, могут быть против всех
80% флюгер, сумма мыслей окружения
10% социопаты против всего

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

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

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

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

База:

После этого:

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

Наталья Семенова. Делегирование как инструмент лидерства, эффективности, мотивации и профессионального развития

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

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

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

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

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

Георгий Мысливец из Sportmaster Lab. PRO менторство в системном анализе

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

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

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

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

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

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

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

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

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

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

Татьяна Половинкина. Debugging мозга или гон тараканов

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

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

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

Илья Отькало. Управление конфликтами при внедрении и сопровождении информационной системы

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

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

Татьяна Комиссарова. Как растить и развивать команду аналитиков в матричной организации

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

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

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

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

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

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

Практики

Валерий Разномазов. Аналитика микросервисов. Практический опыт аналитика в enterprise

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

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

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

Последствия того, что микросервис делает один человек - семантическое безумие, разнородность названий для одного и того же. Сложности технологизации. Тяжело прогнозировать нагрузку, 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.

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

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

Ольга Бершель. Вредные советы по составлению CJM

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

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

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

Дмитрий Безуглый. Новый мир, его вызовы. И аналитики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мифы

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

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