#AnalystDays Татьяна Половинкина из НЕОФЛЕКС. В чем смысл цели? Офигенно крутой доклад про работу с целеполаганием по X-матрице Стратегия - Тактика - Задачи (гипотезы) - Результаты. Матрица - потому что у тебя не обычное дерево, ты на каждом шаге заполняешь взаимную зависимость и отсекаешь то, что оказывается малозначимым. По каждому такту - лайфхаки, и иллюстрация сквозным примером.

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

Цель - желаемый осознанный результат. Но желаниям человека свойственна нерациональность и субъективность, нельзя сделать, чтобы человек захотел сделать хранилище данных, он может захотеть лишь самостоятельно. Средство для этого - осознанность. X-матрица - способ осознанной работы с целями. Стратегия - тактика - задачи - результаты. Хотя я бы назвал его способом рационально работать с целями, потому что эмоциональную и мотивационную компоненты он не охватывает.

Лайфхаки стратегии.
* Надо максимально узнавать видение, стратегию компании, чтобы реализоваться, чтобы понимать зону возможностей в компании. А компания должна регулярно транслировать, что происходит. Например, компания живет за счет выполнения проектов, и сотрудникам надо показывать возможности текущих проектов. И это - не однонаправленный вектор: инициативный сотрудник может попробовать расширить стратегию, включив в нее работу с продуктами - если видит в этом счастье. Но это непросто.
* Вплетите личную мотивацию в стратегические намерения компании.
- Хочу работать в известной компании - хочу прокачать свой бренд, личный и компании
- Хочу работать в востребованной компании с возможностью обучаться - хочу работать с профи.
- Хочу работать с друзьями и расти - приводите друзей, компания будет расти
* Нет плохой и правильной цели. Есть ценность для вас.
- Что изменится, если достигнешь цели
- Что будет, если не достигнешь
- Ресурсы которые потратим и сохраним.
Если человек хочет машину, чтобы замечали - может, ему достаточно просто перестать скромничать и его начнут замечать?

Тактика - это вектор действия в направлении стратегической цели. Лайфхаки тактики.
* Проверка фокусировки. Хочу 1 млн прибыли - а что делать будешь сейчас? - буду путешествовать. Стоп. Или зарабатывать, или путешествовать. Ну или покажи связь.
* Тактика "от" и "к" - Чего хотите достигнуть и что сейчас мешает.
* Гибкость. Мелкие задачи, появляются новые возможности и ограничения. Нужен ли этот бой сейчас?

Лайфхаки задач.
* Цель - не средство. Не прочитать книгу, а стать книголюбом, или изучить и применять знания. Изучить курс - не цель.
* Помните, что задача - это гипотеза! Работайте по HADI циклу проверки гипотез
* Эффект Икеи или Брейнсторм. Когда хотите достичь цели - позвольте людям набросать гипотез, не давайте пути сами. Когда делаешь мебель своими руками - она чудесна. Так и с любыми путями.
* Людей, которые хотят знать алгоритмы, алгоритмы (ИИ) заменят в первую очередь.

Матрица: какие идеи на какие тактические вектора движения работают. Ставят баллы. И это отсекает гипотезы, которые в тактику не укладываются.

Лайфхаки результата.
* Проверка фокусировки. Метрики, которые мы будем измерять. Основанные на ценности, целе, результате, а не на исполнении задач. Но задачи тоже меряем - это оценивает затраченные ресурсы.
* Умение ошибаться. Это как отладка кода - мы же ошибаемся, и это не страшно. Так и со всем остальным. Надо извлекать выводы.

Матрица: какие задачи-гипотезы на какие метрики результата влияют. Там тоже индикатор - насколько гипотеза влияет, тут отсев гипотез.

Кейс, на котором дальше был разбор - ее стратегическая цель. Была 2 года назад - максимально расширить компетенцию SQL у сотрудников - они data-аналитики. У нее: изучение навыка, применение навыка, трансляция навыка (это обязательно, синхронизация с другими). Шаги задач и результатов - в презентации были матрицы идей с конкретными баллами. Картинка оценки часто удивляла, оказывалось, что гипотеза, которая кажется перспективной, набирала меньше всего.

Лайфхаки синхронизации
* Умение делегировать
* Поймай мяч. Кидаем проблему сотрудникам, они придумывают. И приходят за ресурсами - время, сервера - и это корректирует цель

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

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

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

Доклад очень хороший. Для тех, кто идет в жизни по плану. Есть альтернативная стратегия: ищем подходящие случаи. Там тоже нужна осознанность, нужно представить те варианты, которые ты видишь как перспективные, к которым внимателен в окружающем мире - это называется предпринимательская бдительность, об этом есть отдельные книги. А еще есть деление людей на дайверов и сканеров от Барбары Шер. Метод подходит для обоих, но наполнение будет сильно различаться, на мой взгляд.

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

Я тут не могу не прокомментировать. Про разделение информационного и человекоцентричного мира - интересная идея, но надо подумать про границы. На мой взгляд, есть одна граница между индустриальным миром и тем, что за ним. Я называю то, что за ним - цифровым миром, так как термин постиндустриальный уже приобрел иной смысл. Можно в индустриальном выделить отдельную фазу после фабрик (первая промышленная революция) и конвейера (вторая), открытую научно-технической револуцией 1960-х, и неточно назвать ее информационным. Или все-таки информационный мир - начало того, что будет после индустриального мира - и тогда именно он будет развиваться.

Теперь отдельно про человекоцентричность. С одной стороны, я впервые засек в 2019 смену социального контракта сотрудника от компетентной работы за зарплату к искренней работы на цели компании в обмен на условия для счастья на работе, у меня об этом есть статьи и доклады. Но, с другой стороны, тут важная часть - счастье на работе. Я решительно не согласен с японской концепцией, в которой человек приходит в корпорацию на всю жизнь и работает исключительно на благо этой корпорации. И не имеет иного смысла жизни, вплоть до того, что при увольнении кончает жизнь самоубийством - кейсы известны. И с вариантом, к которому пришли некоторые американские компании (и не только они): мы все сделаем, чтобы вы могли круглосуточно не выходить с места работы, я тоже не согласен. Потому что жизнь человека не ограничивается работой. И там есть не только досуг и работа в профессиональных сообществах, но и социальные связи, а также рождение и воспитание детей. Конечно, есть концепт, что людей на Земле и так слишком много, поэтому рожать новых не нужно, но, по-моему, он доказал свою несостоятельность. Так что тут важны акценты. А Харари, на которого Татьяна ссылалась в вопросах, на мой взгляд, мыслит в рамках этих концептов. Так что индивидуальное и субъективное счастье - правильно.

#AnalystDays Дмитрий Блинов, DBlinov.com. Декомпозируем истории и создаем User story map для фитнес-аппа. Хороший доклад о том, как декомпозировать и резать скоуп для MVP на примере кейса создания софта для фитнес-клуба. Agile и Scrum основаны на идее быстрой регулярной поставки инкремента ценности. Возможность поставки означает, что задача должна быть готова полностью, а не на 99%. В то время как практика ответа на вопрос - задача готова почти: сделал, но не смержил; протетсировал, но не везде. Мы работаем среди умных людей, и странно, если не найдет причину. Важно договориться: готова - это 100%.

Если наша задача - оставлять инкремент, то декомпозиция по слоям архитектуры или фазам разработки не подходит. Бэк без UI или требования без разработки никому не нужны. И был придуман иной способ - user story, рассказ о работе пользователя, который достигает какой-то цели. Придумал Кен Бек в XP. Основные книги: Майк Кон и Джеф Паттон. Главная фишка story - ценность, это и делает ее инкрементом. Появились шаблоны, в начале 2000-х. Потом ценность вперед переставили. История должна быть INVEST. Оцениваемая и ценная.

Рассказ - длинный, это эпик, а дальше мы его делим на кусочки и в user story map приоритизируем. Придумал Джеф Паттон: 2004 статья, 2007 термин, 2014 в книге. Кстати, в 2013 я был на тренинге Джефа Паттона, и он очень интересно рассказывал про user story map, у меня в блоге есть конспект.

В докладе - сквозной кейс: хочу открыть фитнес-клуб DomFit. QR-код на турникете, найти и записаться, оплатить на тренировку и многое другое. В списки появляются объекты - о клубе, о тренировке, о тренерах, профиль пользователя. Если так понятнее - делайте такие истории. Но помните, что хранение объектов не имеет ценности без их использования для других историй.

Расположили каркас в строку. Что делить? То, что не пролезает в спринт, и то, что включает несоклько приоритетов. Очень часто части истории имеют разную важность. Задача Product Owner - поделить истории, чобы можно было оставить наверху ценные части. Делим vertical valuable visible. Не всегда получается вертикально, они не будут ровными кусками - где-то UI больше, где-то - бэк. Но обязательно что-то в UI - история должна быть видима. В кейсе выделили: регистрация, пропуск по QR, записаться и оплатить.

Регистрация - куча вариантов как залогиниться. И для каждого - варианты, например через почту - много способов. Альтернативы по сценариям и данным. И надо найти 1-2 самого ценного вариант, а остальные - убрать. Опускаем вниз на user story map. Личный профиль. Делим: атрибуты объектов, типы, справочники, интеграция. В MVP берем малое: телефон, почта, QR.

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

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

Итого - что получилось из user story. суммарная визуализация, и в рассказе было 9 способов декомпозиции. Есть еще.
* Деление по глубине вывода данных - для банка увидеть остаток, операции недели, важные атрибуты и т.п.
* Админка и настройки - потом!
* Элементы управления: сложные - потом. Если нет разницы текст или календарь - сделайте календарь, если его сложнее - текст. А вообще с календарем - беда, когда надо скроллить до своего года рождения - сильно огорчаешься.
* UI. Внешний софт - простой функционал с красивым GUI, если внутренний - наоборот, просто бухгалтера хотят черные буквы на белом фоне, а не полутона.
* Производительность - можно позднее, если у вас не будет ее сразу. Но важно: когда поделили, то остаются обе истории, медленная и быстрая, а не забыли, что сделали медленно.

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

Размер декомпозиции. 5 историй в спринт. Ему такая цифра нравится. Реально идем итеративно от какого-то старта.

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

Все про MVP знают. Но не делат. Оправдания разные.
* Все равно релизить, зачем откладывать;
* Все на бэк, можем поставлять раз в месяц - про месяц правда, но можем или хотим
* Лень - когнитивная скупость.
* Еще ответ: наша ситуация уникальна.
Все это отмазки. И что будут слишком маленькая история, которая не приносит ценности - тоже, так получается редко.

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

#AnalystDays Ольга Кулапина из Red Collar. Куда приводит Discovery. Как работать с неопределенностью. Доклад был о том, как подружить продуктовые практики и заказную разработку. От аналитиков продуктового мышления ожидают в разных ситуациях, например когда компания делает pet-проект или когда средний оффлайн выходит в онлайн, или в других подобных случаях. Они обращаются к тем аналитикам, которые есть. Понятно, что на входе они под такую работу не подписывались, но на практике часто нет выбора. А еще это интересная задача. И, наконец, многое тут можно сделать, используя знакомые практики аналитика. Да, полностью задачи продукта ты не решишь, маркетринг, продвижение и unit-экономика останется за рамками, но провести discovery, подготовить первый шаг - вполне.

Что сделать то, что не делали, нужны две вещи: знакомые точки кристаллизации, от которых можно оттолкнуться и сегментация, разложение процесса по шагам. Что будет точкой кристаллизации? Можно представить discovery как работу аналитиком в ситуации, когда требования сводятся к идее нового продукта, изучение потребностей целевой аудитории представить как выявление пользовательских требований, а изучение рыночного ландшафта - как изучение предметной области. Вроде получается почти знакомый проект. Далее по шагам.

Шаг 1. Перепрошиваем мозг, меняем майндсет. Продукт думает: зачем это нужно бизнесу и пользователю, и спрашивает бизнес, почему пользователь будет покупать именно этот продукт. Ориентация на цели, сроки и бюджет вторичны. Гипотезы и проверка через даныне - не фантазии. Постоянные улучшения, гибкость, толерантность к неопределенности. На дискавери надо не все: спрашивать зачем, понимать потребности пользователя, связываем задачи бизнеса с пользователем (это умеем), строим гипотезы, не боимся неопределенности.

Шаг 2. Ищем знакомое в незнакомом, перешиваем и развиваем навыки. Cust Dev похож на бриф, исследуем конкурентов - как заказчика, на открытых данных, объемы рынка - по открытым данным конкурентов.

Cust Dev.
* Не знаете откуда взять аудиторию? Запросить у заказчика - нормально. Еще соцсети
* Не знаете сегментирование - JTBT. Поймите, какую работу выполняет продукт, напрмиер, йогурт с высоким содержанеим белка - когда его применяют. И это дает аудиторию и вопросу к ней - про
* Какую методику выбрать? Чем больше неопределенности - качественная, подробности - количественная.
* Интервью. Короткие - люди вам не должны. Но задавайте открытые вопросы. Не про ваши гипотезы, а про то, как они действуют. Узнаете новое. Но это - пользователям, а заказчику - гипотезы и сценарии, иначе он будет увеличивать MVP.

Исследование конкурентов.
Поле конкурентов и ответ - стоит ли лезть на это поле.
Фреймворков много. Ее любимый - магический квадрант Гартнера, Фичи и UX, кружок - объем рынка.

Объемы рынка. Зачем? Если пришли с идеей, а денег нет - люди не привыкли платить - то лучше не лезть, это трудно.
Фреймворков много, наиболее легкий - TAM-SAM-SOM.

Все эти фреймворки в пределе сводится к здравому смыслу и business view.

Неопределенности стало меньше, но появился хаос данных.

Шаг 3. Гипотезы - проводник через хаос данных. Научиться мыслить гипотезами. Верхнеуровневые рамочные - цифровые - улучшение продукта. Рамка - идея, например, всем будет полезен магазин готовых маршрутов. Цифровые про MVP, проверка продукта.

Шаг 4. MVP. Определились с составом продукта, теперь его надо обрезать. Все кивают на концепцию, но как только реально доходит до урезания - не режут. Не переживайте, что первый продукт бедный - будет возможность дополнить. HADI цикл. И есть лайфхак: у вас будет не бедный продукт, а сфокусированный или сконцентрированный, смена термина многое меняет в восприятии.

Здесь много трагедий и боли. Стартап хотел цивилизовать рынок щебня. Ребята 4 месяца разговаривали на прототипов. Самолет, к которому прилепили бассейн и спортзал. Срезать не удалось, потому что MVP срезать не удалось, заказчик полюбил. В результате MVP разрабатывали год, потратили все деньги ,на маркетинг и продвижение не осталось - а это дороже разработки. А сейчас конкуренты пришли с идеей выкупить идею - рынок созрел.

Для сокращения MVP - делайте быстро и малыми силами. Не 30 человек год, а три за месяц.

Шаг 5. Во-время останавливаемся. Discovery - продуктовая гипотеза. Весь продуктовый цикл не закрываете. Там маркетринг, юнит-экономика и много чего.

И в заключении. Иногда discovery - крик бизнеса о помощи, не игнорируйте. Бизнес-аналитик - может сделать.

Как обычно, слайды моего доклада - сразу на моем сайте https://mtsepkov.org/SoftSkills-AD-2024

#AnalystDays Вера Бонарева из Сбербанк. Преодоление сложностей в интеллектуальном распознавании документов: инновационные подходы и роль LLM. Это блиц-рассказ о том, как усложнялась по мере реализации задача распознования документов, появлялись все новые кейсы и способы распознавания.
* Первоначально задача выглядела просто: приходят сканы и документы разных типов (xml, excel, word, pdf) - и надо опознать тип. Полный автомат, документы передает внешний сервис. ему же оправляют ответ. Настроили распознавание текста с изображений, парсеры xml и excel, систему правил, которая применяется после распознавания скана или парсера.
* Быстро выяснилось, что приходят архивы с большим количеством файлов, надо распаковать и каждый обрабатывать отдельно.
* Затем - что в архиве может приходить потоковый скан на сотни страниц, который надо разбить на отдельные документы.
* Затем - добавили верификацию пользователями того, что распозналось плохо или неуверенно - у системы появился GUI, а с документом приходят данные - кто должен подтвердить. Верификаторы - дефицитный ресурс, в пике потока получается задержка до пары дней, поэтому если в архиве документы, которые распознаются хорошо и которые плохо - то статус надо вести не у архива в целом. а по отдельным документам в нем. И еще специальные меры, чтобы документ, ожидающий верификации, не был сброшен из очереди по сроку.
* Из паспортов и некоторых других документов надо вытаскивать атрибуты - ФИО, серия, номер и так далее, для этого подключили ML, с паспортами и другими документами фиксированных форматов она справляется.
* Из договоров ML атрибуты вытаскивает плохо, там большие тексты - про них спрашивают LLM, GigaQuery и ответ сравнивают с тем, что дала система правил.
* Поскольку верификация - избирательная, то ошибки проскакивают, и пользователь может отправить на повторное распознавание, которое всегда с верификацией, даже для простых документов.
Такое вот усложнение системы в ходе разработки и эксплуатации - типичная история.

#AnalystDays Наталья Семенова. Коллеги, мы тоже на одном языке говорим. Рассказ об известной всем аналитикам, и не только им, проблеме, что одни и те же слова в разных проектах могут означать совершенно разное. Потому что значение слов определяет контекст, к которому относится не только предметная область, но и способ ведения проекта, например, в заказной, продуктовой и inhouse-разработке работа с требованиями сильно отличается, хотя описывается одним и тем же выражением "собрать требования" или "выявить требования". Проблема как бы известна, но многие почему-то уверены, что это происходит потому, что люди неправильно употребляют слова. начинается холивар и апелляции к словарям. И это, в том числе, проявляется на собеседованиях: ответ отклоняют как неверный. А реально проблема в различии контекстов. Это даже в BABOK есть, правда очень кратко. И аналитик должен уметь распознавать контексты, и дальше вести коммуникацию с их учетом. А если подозревает, что контекст ему не знаком - то не стесняться спрашивать или иным образом уточнять значения слов. В докладе - много кейсов, а также подходы к прояснению контекста.

Этого доклада не было в программе - Наталья выступала на BarCamp, рассказывал доклад, который делала на Стачке, и то ли конференция вообще не вела запись докладов, то ли запись этого не получилась. А AnalystDays ведет запись и трансляцию не только основных треков, но и BarCamp, так что теперь запись есть.

Для начала были кейсы, касающиеся различных типов проектов. Потому что именно о них часто не подозревают, и на собеседованиях наступают на эти грабли.

Мини сценка, разговор двух аналитиков:
- Стейкхолдеры у нас никакие...
- А ты что, ты же тоже стейкхолдер?
- Как я стейкхолдер. это же заказчики?

Собрать требования.
* Уточнить у ЛПР, поискать в документации требования и выявить заинтересованных лиц.
* Изучить бизнес-требования, запросить описания процессов, собрать у стейкхолдеров
* Сформировать гипотезы, сделать тестирование на фокус-группе, оценить стоимость и ROI.
Это различия внутренней, заказной и продуктовой разработки - требования собираем по-разному. И это - за рамками разговора.

Взаимодействие с командой.
* А что общаться, написал ТЗ и отдал, дальше на вопросы...
* У других - плотное взаимодействие: истории, DoD, сделал сторителлинг и так далее.
Разные методы работы команды. И отличия надо понимать, выяснять. что тебя ждет в проекте и действовать сообразно, или предлагать изменения, тоже осознанно.

А что делать до разработки?
* discovery и presale
* product market fit, анализ конкурентов
Тоже заказная и продуктовая разработка.

Ретро, разное отношение
* Сначала было скучно, потом весело.
* Проводим по регламентам каждый квартал, хотя хочется чаще.
* Проводим каждый спринт и отдельно со смежниками по необходимости.
Зависит от зрелости бизнес-процессов: хаотичные, по регламентам, постоянные улушения - на слайде была шкала из 5 уровней. Я бы отнес это не к зрелости бизнес-процессов, а к культуре ведения проекта, но такое различие терминов - тоже часть культурной рамки.

Степень свободы аналитика
* RACI по процессам, с заданными инструментами
* задачи на синках, целесообразность обсуждается, oD и критерии качества тоже.
Начинающим интересно по регламентам, опытные - сами решают по ситуации.

Как выявлять диференцииаторы контекста? Рассматривают 4 квадранта: Знать - Узнавать; Все просто - Все серьезно.
Все просто.
* Знаем: быстрая память и интуиция из насмотренности.
* Узнаем: спросить в разговоре или погуглить. Очень часто пытаемся угадать - а это неправильно.

Все серьезно.
* Надо знать про стандарты, метрики, модели и техники, инструменты, регламенты и заглядывать туда. по необходимости. Быстрая проверка через стандарты помогает.
* Модель IGOE: inputs - guides (как будем делать) - ouputs - enablers (что поможет выполнить).
* Кастомные модель 6 перспектив: люди, процессы, время, ресурсы, инструменты, скоуп. Применялась в EPAM, она делала доклад, можно посмотреть.

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

По концептуализации у Натальи был доклад на прошлой AnalystDays.

В конце было еще обсуждение с кейсами от участников.

#AnaystDays Галина Кореневская из ГК Самолет. Как мы изобрели Business and Data Flow Diagram. В 2022 Самолет решил стать лидером рынка за счет покупки крупной компании. Перед Ит поставили задачу поддержать быстрый переход компаний в однородное состояние, для чего сделать описание бизнес-процессов, которое бы соответствовало действительности. И разобраться с более, чем 350 ИТ-системами. Для описания бизнес-процессов надо выбрать нотацию. Они собрали цели бизнеса и ИТ. Бизнесу достаточно BPMN, а ИТ, помимо описания бизнес-процессов, хотели видеть его поддержку ИТ-системами, сущности и интеграцию систем. И они доработали BPMN-нотацию для описания. Рассказ был о доработках и о требованиях к описаниям.

* Нейминг - краткое наименование отражает смысл процесса. BPMN storm - тип asis/tobe. рейтинг качества, ниже 8 - надо переделать
* Границы. Старт - триггер, он должен быть подписан! А это - важно. И именно событие. Не "необходим пересмотр лимитов", а почему он необходим, например, увеличился объем работ
* Действия: гранулярность, кто выполняет и в какой системе. должен быть результат, роль которая выполняет и входящие параметры - документ. Могут быть подпроцессы.
* Стрелки - явные шлюзы, понимать: от процесса к документу - результат, от документа в задачу - параметр.
* Сущности делятся цифровые и нецифровые. Сканы - тоже нецифровые. Цифровые - с жизненным циклом. Если жизненный цикл в одной системе - фиолетовый, а много систем - зеленый. Клиент - живет в нескольких, задача - только в jira.
* Описания интеграций. Автоматическая задача передачи данных (шестеренка) - стрелка потока нужного цвета, входит в задачу принимающей системы, на выходе - ее документ. Зеленые стрелки - передача сущностей, а фиолетовая = передача событий, меняющих состояния документов. Например, из СРМ в учетную систему идут клиент и договор - зеленая стрелка, в учетной системе к договору привязываются платежи, они в CRM не отправляются, но после оплаты идет нотификация для смены состояния договора фиолетовой стрелкой.

Результаты.
* схемы стали объемнее. Увы.
* 40 воркшопов с бизнесом и ИТ. 15 команд, 4 ИТ-блока.
* Архитектор не участвует во встречах си бизнесом - егму оказывается достаточно документов.
* Повысили информативность для команд разработки
* Бизнес вовлекли в описание процессов. Они не отказывались от участия.

#AnalystDays Григорий Печенкин. Пять граней мышления аналитика. Кто такое - хороший аналитик? Это человек с особым типом мышления, у которого есть 5 аспектов. Доклад был о них, на кейсе работы с обобщенным университетом по внедрению системы индивидуальных образовательных траекторий студентов. На первой встрече присутствуют трое: Проректор, который хочет модель, где студенты сами выбирают что изучать; руководитель учетно-методического отдела, который говорит, что для этого надо совсем немного: зафиксировать индивидуальные планы и сделать выбор нагрузки; и главный от ИТ, который поддерживает и говорит, что все данные есть - остались от предыдущего заказчика. Проректор слышит коллег и говорит: ОК, все поддерживают, договорились, работаем. Вопрос: о чем договорились, ко эти лица и что делать дальше? И тут нам как раз помогает способы мышления.

1. Системное мышление. Смотрим на мир как на систему систем. Книжек - много. Но! это не формальная теория, которая дает аппарат, а философская концепция с шаблонами мышления. У него было три подхода: в институте, (2) когда стал аналитиком - Системный анализ, почитал книгу, к жизни отношения не имеет (3) книга где описано как действует.

Сколько уровней требований? Три. Это - хорошее число. А еще теория систем: наш продукт - часть надсистемы, и оттуда верхний уровень. Внутри системы есть взаимодействие с внешним миром - это пользовательская и интеграция, окружение. И третий - требования к устройству (функциональные или системные). И это - причины классификации, а не формальная классификация.

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

2. Логическое мышление. Иногда логика дает сбои - когнитивные искажения и другие.
Искажения частное-общее: Чрезмерное обобщение, эффект знакомства, иллюзия кластеризации.
Решаем не задачу, которая стоит, а знакомую: фрейминг и другое.

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

Фраза - гипотезы, что за ней - отсечение гипотез. Дальше - уточняющие вопросы. И верификация. Потом - вывод. Разветвляющийся конус гипотез, потом - схловываем. Главное - не пренебрегайте верификацией. В 9 из 10 проговорите то, что всем понятно. Но в 1 из 10 оказывается, что все неправильно.

Главный по ИТ может быть
* ответственным за только ИТ-администрацию
* главный или проректор по цифровизации
* глава ИТ-факультета, профессор, который заодно отвечает за ИТ-ландшафт
И надо уточнять. И далее - уточнять его интересы

3. Мир интересов. Его надо видеть.

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

Луковичная диаграмма. Рисуем стейкхолдеров по слоям подсистема-надсистема, и рисуем интересы.

4. Критическое мышление. Во всех университетах говорят, что это надо ставить, но понимают по-разному. Его понимание - это Сомнения на пути к истине.

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

На вас можно повлиять.
* Изолировать от другой точки зрения: не ходите к этому, он не решает. Если не изолировать, то дискредитировать - он не решает, дурак, некомпетентен.
* Подмена свидетелей. Негатив вычеркиваем, позитив лайкаем и добавляем от себя
* Создание информационного фона. Много каналов - с анонсы, и иногда там крупицы золота. Никто не комментирует. А в два ночи - 70 комментариев. А потом - 50 к другому. И это - один человек, к нему идут. Он пришел из губернаторской команды и принес культуру с командой поддержки. И это - способ воздействия на убеждения.
Манипулируют все. родители детьми, супруги друг другом и так далее. И когда приходите со своей системой - она влияет на интересы и весь спектр может быть применен.

Был еще пятый аспект, но я не записал. Над будет посмотреть презентацию и запись...

В конце недели прошла осенняя #AnalystDays. На ней было очень сильных докладов, и я желаю организаторам и ПК сохранить этот уровень. Я публиковал заметки в ходе конференции и сейчас собрал их в отчет https://mtsepkov.org/AnalystDays-2024b, дополнив еще несколькими докладами, заметки с которых сразу опубликовать не успел. А уже завтра начинается #Teamlead, в котором я тоже участвую и выступаю.

#Teamlead Мария Щекочихина из CUSTIS. Делаем происходящее с персоналом предсказуемым. Это рассказ о том, что надо технически делать, чтобы происходящее на масштабе 10 команд и 100+ человек было предсказуемым. Если кратко - то надо сценировать будущее, траектории развития сотрудников и других изменений - и ты оказываешься готов к различным вариантам развития ситуации. Для этого есть два инструмента: карта команд и работа с рисками, и еще - фидбэчница, фиксация истории взаимодействия. Но рассказ был построен не от инструментов, а от кейсов, инструменты проявлялись как средство, помогающее с этими кейсами разбираться. Потому что инструмент - универсален, как база знаний, применять его можно по-разному. Дальше - краткий конспект.
* Кейс-1. Ваня приходит с офером x2. Столько платить не можем, а он нужен. Но не можем. И человек ушел. Что делать? Надо планировать рост ключевых сотрудников заранее. На замену ведущим готовить людей из middle.
* Кейс-2. Есть люди, которые мониторят рынок. И спрашивают "а почему моя зарплата не соответствует". Надо следить самим за рынком зарплат. При этом вилки и медианы надо адаптировать на ситуацию в компании - у всех разные возможности. А дальше держим в зеленой зоне в районе медианы. Если границы - сложно работать: сотрудник на низкой границе придет с офером с большим повышением, и удержать будет сложно, а для сотрудника на верхней границы нет возможностей роста и это - риск, он уйдет в другую команду и компанию на другую позицию.
* Кейс-3. Растим мидла Васю на позицию ведущего. Индивидуальный план развития: что мы ожидаем для роста, и сроки выхода на позицию, это не пара месяцев. А вам как руководителю - надо обеспечить позицию ведущего и бюджет для нее. И встречи. Раз в пару недель - прогресс роста.
* Кейс-4. Сотрудник не соответствует позиции, но не признает. Такого не был, это всего один раз, это не говорили. Важно - фиксировать все, что было на ревью. Что вы говорили и вам отвечали. Не хочу быть лидом, а проводить собеседования - хочу. Дальше мы можем поднимать историю во взаимодействии.
* Кейс-5. Аналитик переросла позицию. И внутри команды не решается. Нужен вышестоящий руководитель или HR. Есть ли подходящая позиция в соседнй команде? Если есть - идет туда. Но надо еще подготовить замену у себя - из соседней команды. Это надо делать заранее, но сотрудники в случае понятных перспектив обычно лояльно относятся к ситуации. Чтобы все это видеть - нужны карты персонала. Несколько команд, траектории и проблемы. Ведут в Miro, в презентации был пример.
* Кейс-6. В команде только один с конкретной специализацией. А второго нанять нельзя - нет денег и задач для него. Есть два варианта: (а) аналогичный специалист в другой команде и страховка друг друга и (б) рост кого-то во вторую специализацию. Помогают увидеть карты персонала. Они показывают дизайн команды: грейды внутри специализации и соотношение разных специализаций - балансировка мощности. Из карты видно, где проблемы - провалы и отсутствие возможности роста.
* Кейс-7. Два разработчика мидл активно развиваются. И у вас цепочка middle - senior - техлид. Все хорошо. Но приходит второй - а у вас нет третьей позиции senior, у вас она вообще одна. Надо заранее понимать - кого двигать. Карта рисков. Сотрудники: ценность и возможность развития. И Риски: как избегать и что делать в случае риска. Excel с раскраской.
* Кейс-8. 2022: 2 техлида и один ведущий ведущий уезжают, при чем ведущий страховал одного техлида. Смотрим на карту. Ищем других ведущих - не нашли. И открыла вакансию с перспективой роста, которую проговаривала на входе. За 2-3 месяца получилось подготовиться.
* Кейс-9. Тимлид Аня просит срочно согласовать вакансию аналитика в команду. Тут надо остановиться и подумать: много работы навсегда или это завал на 3 месяца? Должен быть фронт на год. А еще: есть ограничения. И нет ли кого-то, кто может получить новую компетенцию.

Кейсы 10-14.
* Больничные на 2-3 месяца. Редко, но внезапно. Надо заранее планировать замены ключевых. А если вышестоящий? Она в том году выпала, тимлиды справились за счет инструментов на горизонтальной связи..
* Многодетный мать/отец вышел из декрета и к работе есть вопросы. Надо восстанавливать - давать автономные задачи, чтобы он мог организовывать работу
* Тяжелые проблемы в семье - тоже нужно дать возможность восстановиться, на обособленных задачах. Но надо договориться про срок.
* Декрет ключевой сотрудницы. Он прост - потому что известно заранее. Инструменты помогут.
* Кланы: привел друга, хантит из соседнего подразделения, пришла команда, друзья тимлида. (а) группирующий риск - как привел - так и уведет. (б) увод между командами ухудшает отношения тимлидов.

Рисков - много, список будет дополняться. В презе - список. Работа с рисками. Вероятность наступления и тяжесть последствий. низкий-средний-тяжелый.
* Тяжелый-вероятный: архитектор, которого год искали - не проходит испытательный срок
* Легкий-вероятный: джун не проходит - не так страшно.
* маловероятный-тяжелый: Недовольный сотрудник и пишет гневное прощальное письмо

Кейс 15-17. Те же инструменты могут использоваться для других целей.
* Оценка встройки на собеседованиях. Классный человек, но через полгода станет скучно - сразу делаем сценарий.
* Проект завершился - перераспределяем людей. Карта персонала.
* Сборка новой команды - тоже карта персонала. Людей надо как-то вытащить, в карте - есть замены и риски.

Основа работы Performance review: есть цикличность и сроки. Раз в полгода - зависит от динамики команды.
* ИПР стыкованы с performance review.
* Обратная связь после performance. И обязательно слушаем его ответ.
* Регулярные 1:1 - по ИПР.
* Планирование. годовое: зарплаты, должности, соотносим с рынком. И дальше по мере изменений - актуализируем.
* И не забываем все записывать. Это не только вам, но и тому, кто придет на смену. Преемственность в руководстве.

Что это дает? Для сотрудника: понятные правила, ИПР, нестандартная траектория - не замкнут в команде. Для тимлида - картинка сверху, проблемные места и планы по ним.

Набор инструментов - для 50+ Для 5-10 можно использовать отдельные инструменты. Важно - работа с рисками, сценарии "а что если". Могут помочь: руководитель и HR (они неплохо сценируют). И обязательно все записывать!

#Teamlead Альберт Степанцев из Спринт-Ф. Законы Мерфи в повседневной работе руководителя. Это был рассказ о разнообразных рисках и способах работы с ними. В нем была очень интересная техника: три дня выхода на работу, чтобы проверить что сотрудник сработается с командой. Оплачиваемых, по договору.

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

Альберт - CTO напрокат, партнер по выстраиванию ИТ и его опыт работы включает много компаний. Доклад структурирован на три части: Люди, инструменты и система.

Люди. Мы нанимаем, работаем, увольняем.

Риски найма: найм неподходящего, завышенные ожидания; риск несовместимости; риск долгого (дорогого) найма.

Как парировать риски найма.
* Нанимаем первого подходящего, время - дорого
* Сократите плечо найма - сколько собеседований. Чем выше этапов - тем выше вероятность ошибки. У него 15 минут HR на общую адекватность. А потом - сразу на себя, и вместо идеального собеседования, где тесты, lifecoding и прочее - показывает экран с реальными задачами готов или нет. Затем - код проекта - совместно почитать. И тоже достаточно 15 минут.
* Если кажется - значит не кажется: если на каком-то этапе беседы показалось, что что-то не так - оно не так. Не игнорируйте подсказки подсознания.

После найма - онбординг, есть семь ступенек.
* Придти на работу
* Начать что-то делать - не все доходят до этого
* Делать хорошо, не вредить
* Хорошо и быстро - в темпе команды
* Хорошо, быстро и то, что нужно. А не сделать CRM чтобы MongoDB изучить.
* Хорошо и быстро то что нужно, и не только в своих интересах. Бывают эксцессы.

Как парировать риски лестницы?
* Главное - создать условия, потом требовать результата. Офис, рабочее место
* Дублировать и резервировать. Можно с аутстаффом договориться.
* Прозрачность - не пустое слово.

На найме - показать экран с правилами, разными: как ветки делать, что ответ должен быть дан, если задан вопрос.

Второй закон Чизхолма: если дела идут хорошо - что-то случится в ближайщем будущем.
Закон Падлера: Все, что хорошо начинается - кончается плохо, а что начинается плохо - кончается еще хуже.

Рано или поздно все увольняются. Крепостное право отменено. Риски: неожиданное увольнение, отказ увольняться, негатив и так далее.

Увольнение начинается с найма - проактивная позиция
* вы должны быть готовы
* озвучьте при найме правила увольнения, с вариантами (одним днем, две недели и так далее)
* ведите сценарии на возможные риски увольнений
* если сценария нет - вы полдня думаете, а ситуация может измениться, негатив.

Техника три дня: приходи на три дня, возьми больничный в прежнем месте, а мы договор подпишем
1. Доступ получил, проект поднял
2. Учебная задача
3. Реальная задача, но короткая
Позволяет 90% рисков найма и увольнения снимает. И можно в любой момент разорвать.

2. Инструменты. Техника, офис, софт для работы. Людям надо дать инструменты. Инструменты выбирают люди - а люди ошибаются.

Проблемы с инструментами.
* Инструмент выглядит хорошо, но не решает задачи. gitlab вместо CI/CD или NetBeans вместо IDE
* Решает задачи, но никто его не знает. Как ExtJS
* Решает задачи, но крадет время. Кто-то вручную проталкивает задачи по gitflow вместо скриптов
* Известен но никому не нужен
* Неудобен до неприятия. Как Кибана для тестировщиков

Инструменты - экономят время. А время - деньги. Работа, которая делается зря - muda из Канбан. Инструменты должны время сокращать, а не красть.

Про инструменты.
* Запрещайте физически (merge в мастер)
* Автоматизация, которая экономит время
* Известное - лучше неизвестного
* Нужное - лучше известного

3. Работайте с надежностью системы. Люди - связи - процессы - изменение процессов во времени.

Проблема - степенная функция ненадежности. Надежность - что элемент работает. Например, что сотрудник приходит на работу. Если n элементов, то общая надежность - степенная функция от надежности.

Ракета М1 - 30 двигателей с надежностью 95% на первой ступени. Для неотработанной техники - прекрасно. Но общая надежность - 21%, только один из 5 - успешен. Запускали 4 раза и она 4 раза взорвалась.

10 человек, каждый из 20 рабочих дней приходит 19. Какова вероятность, что будет день, когда придут все - не высокая.

Связи. Ненадежность передачи информации, испорченный телефон.

Надо сокращать число элементов системы. Инструмент - выделение инкапсулированных элементов.
* Один специалист по React - он подчиняется тимлиду
* Их двое - одного ведущим, но кого? Он вводит дежурства, кто за старшего. Старший работает по ответственным задачам.
* Когда трое - он знает, кого назначить старшим. Когда четвера - заместитель, бас-фактор. Мини-группы по 3-6 человек. И они кристаллизуются естественно. А дальше делим пополам.

Почему 5? Потому что в зоне произвольного внимания 7 элементов: ты, руководитель и 5 подчиненных.

Из ответов на вопросы.
* Проверка совместимости - еще до техскилов. Если он не на одной волне - не поработаешь. Способ - разговор, вживую, голосом, можно онлайн. Последний фильмы, книга, были ли американцы на Луне.
* Тимлиды и техлиды - там 3 дня не работает, испытательный срок. И там нужна обратная связь от команды, вплоть до ежедневной.
* Многоступенчатые системы найма - ломать. Даже в крупной компании. Это дисфункция. У него был опыт. Пришел в компанию - Кадровое агентство, Свои, Тхлид, Руководитель. Сказал "давайте рискнем, выводите на меня" - получилось.
* Техника три дня - это для тех, кого готовы взять. И это НЕ дороже, проверка совместимости эффективна, а затраты на РК и другие проверки - сложнее. 3 дня дешевле 20% дохода, который хочет кадровое агентство.
* Про увольнение - показываешь в 20 пунктах, среди которых как уйти в отпуск, получить больничный, уволится. Это нормально.
* Вопрос. ПСБ, служба безопасности - нельзя показывать код и применять 3 дня. Что делать? Ответ. Случаи есть, работает с банками.
Право зеркального NDA - может распространить на кандидата. И он на три дня подписывает договор. Код - несекретный, он в любом проекте есть. Еще внутренние проекты - там часто те же технологии.

#Teamlead Александра Брызгалова (bryzgalova.ru) Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас). Основной тезис доклада: если ваше замечательное решение отвергается, то причина обычно не в том, что люди глупы или ленивы, или преследуют какие-то личные цели. Обычно есть какие-то аспекты, которые в своем решении вы не учли: оно не решает проблемы, или решает не актуальную проблему, или создает дополнительный урон или риски, которые вы не видите. И надо расширить рамку рассуждения, понять логику тех, кого вы считаете противниками, найти общую цель - и тогда ситуация изменится. Инструмент, которым иллюстрированы кейсы - грозовая туча из TOC (Theory of Constraints) Голдратта. Но это - лишь один элемент теории. и, по сути, он дал понятную схематизацию, визуальный ряд.

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

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

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

2. Я хочу. чтобы начинали большие тикеты с важными задачами, а они - берут малые. Кричать надо. А он - ленивый. Пошли разбираться. Оказалось, что большие проекты плохо описаны, клиент не понимает что хотел, тянет. Если тянем время - все сговорчивые, и все проще, и меньше лишней работы. Общая цель - есть, меньше работы. Решения: пересмотреть способ описания, менять описания.

3. Жадный собственник. Было двое, один вышел. Виктор Петрович, надо больше денег нанять больше людей. А он - не дает, потому что жадный и не думает про завтра. Конфликт: мы хотим бюджет. а он не дает потому что жадный. А дело было не в жадности. Если вдруг у компании есть деньги - мы можем в теории нанять людей. Но, скорее всего, есть проблемы со старым. Норма прибыли - малая, и нет впечатление, что оно возрастет. Больше фич - не значит больше денег. И надо с этим разбираться - что ждут, и почему не работает.

4. Глупый начальник. Надо автоматизировать тестирование, а начальник не дает. Я хочу - потому что хочу повысить качество. А он - просто не хочет напрягаться. А реально: компания получала деньги за время, которая потратила. Автоматизация - уменьшение выручки. А затраты - меньше. Повышение качества тестирование - не факт, что повысит выручку. И надо менять модель.

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

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

Мысль: люди - хорошие. Голдратт настолько верил, что написал это на надгробном камне. Хотя жил в Израиле в реальной ситуации. Это не романтизм, это прагматизм. У людей нет цели сделать плохо. Брак получается, его не делают сознательно.

Реальные причины: (а) не договорились про критерии качества; (б) я не могу не делать брак - технология, компетентность, он случается; (в) я специально делаю браком - бывает, но очень редко. Штрафы - не эффективно, в последнем случае надо увольнять, а в двух первых - исправлять систему. Обвинить кого-то не значит найти решение.

Но увольнять можно. Даже хороших людей - они могут не соответствовать тому, что нужно.