#EnterpriseAgile Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка. Одна из существенных черт Agile-методов - прозрачность. И рассказ был о том, как обеспечивают прозрачность работы ИТ для топов банка через запуск value stream. На входе была ситуация, когда руководство неплохо представляет, что происходит в проектах, такая культура в банке есть, но там задействована примерна 1/3 ИТ. А 2/3 были через пулы распределены по подразделениям бизнеса и чем именно они занимаются, руководству не понятно. Более того, как выяснилось в ходе проекта, бизнесу тоже было не понятно, бизнес с ИТ не общался, и обе стороны имели не высокое мнение о другом, как это часто бывает. А еще бизнес с удивлением выяснял суммы, в которые ему обходится ИТ-пул - бухгалтерия это распределяла на общие расходы, а в управленческой отчетности это не светили.
Средство решения - реорганизация работы ИТ в value stream? как это описано в SAFe, в которых идет квартальное планирование от задач бизнеса. Каждый стрим - 10-15 команд. За 2024 запустили 13 value stream, на следующий год - еще столько же. Запуск - это определение границ, целей и задачи value stream, затем структурирование внутри. После этого идут циклы квартального планирования и реализации, и по результатам - актуализация целей и задач на следующий год.
Получили:
* Структурирование работ, и людей по направлением
* У всех - единая мотивация
* Управление достижением цели
* value stream - продуктовые, операционные, процессные.
* Связь между целями и результатами деятельности. Воронка продаж, экономика
* Метрики - cycle time, ttm, радар agile-здоровья и оценка зрелости
Средство решения - реорганизация работы ИТ в value stream? как это описано в SAFe, в которых идет квартальное планирование от задач бизнеса. Каждый стрим - 10-15 команд. За 2024 запустили 13 value stream, на следующий год - еще столько же. Запуск - это определение границ, целей и задачи value stream, затем структурирование внутри. После этого идут циклы квартального планирования и реализации, и по результатам - актуализация целей и задач на следующий год.
Получили:
* Структурирование работ, и людей по направлением
* У всех - единая мотивация
* Управление достижением цели
* value stream - продуктовые, операционные, процессные.
* Связь между целями и результатами деятельности. Воронка продаж, экономика
* Метрики - cycle time, ttm, радар agile-здоровья и оценка зрелости
#EnterpriseAgile Анастасия Заруднева из Райффайзен Банк. Continuous Big Systems Replacement. Банк меняет основную систему, которая обрабатывает 15м операций в день, над ней работает 250 команд. Проект идет три года, они в середине пути. При этом существенная часть нового в параллельной эксплуатации, а часть уже ведут в новых системах, так что есть уверенность в успехе. Важно: новую систему пишут те же команды, что и развивают старые, потому что надолго вырвать команды из создания реально работающего продукта противоречит agile-подходу. Дополнительно за счет этого команды понимают продукт, знают алгоритмику.
Как декомпозировать?
* Если есть продукты - их можно выделять. привлечение, размещение
* По процессам. Вокруг таких систем есть системы-сателлиты, можно брать из них.
* По потребителям данных. Самый молодой и массовый стрим, там сложно.
В направлении 3 стрима, 40 продуктов, примерно 15 в стриме. Пример продукта - депозиты ФЛ. На стрим - менеджер стрима, бизнес-аналитик и команды, которые пишут микросервисы. Переводят 4 продукта одновременно. Продукт-менеджеры сами решают, насоклько они проводят реинжиниринг при переносе в новую систему, будут ли они переписывать логику при переходе. Может быть выделена фича-команда или задачи помещены в общий бэклог. С бизнесом ежеквартально согласуется список продуктов, которые переносятся.
На слайде была архитектура: каналы -> продуктовая логика -> core -> главная книга -> распространение данных -> потребители (риски, отчетность и др.) Фича-команда - продуктовая умеет детать доработки для всех командах. Может параллельно работать старая и новая продуктовая логика. Новая главная книга работает параллельно со старой, но мастер пока старая.
Как управлять таким переносом?
* Делать на маленькие шаги
* Исследовать через поставку
* Ставить целью спринта приближение к target-архитектуре
* Находить возможность parallel run
* Работать с потребителем данных
Как декомпозировать?
* Если есть продукты - их можно выделять. привлечение, размещение
* По процессам. Вокруг таких систем есть системы-сателлиты, можно брать из них.
* По потребителям данных. Самый молодой и массовый стрим, там сложно.
В направлении 3 стрима, 40 продуктов, примерно 15 в стриме. Пример продукта - депозиты ФЛ. На стрим - менеджер стрима, бизнес-аналитик и команды, которые пишут микросервисы. Переводят 4 продукта одновременно. Продукт-менеджеры сами решают, насоклько они проводят реинжиниринг при переносе в новую систему, будут ли они переписывать логику при переходе. Может быть выделена фича-команда или задачи помещены в общий бэклог. С бизнесом ежеквартально согласуется список продуктов, которые переносятся.
На слайде была архитектура: каналы -> продуктовая логика -> core -> главная книга -> распространение данных -> потребители (риски, отчетность и др.) Фича-команда - продуктовая умеет детать доработки для всех командах. Может параллельно работать старая и новая продуктовая логика. Новая главная книга работает параллельно со старой, но мастер пока старая.
Как управлять таким переносом?
* Делать на маленькие шаги
* Исследовать через поставку
* Ставить целью спринта приближение к target-архитектуре
* Находить возможность parallel run
* Работать с потребителем данных
#EnterpriseAgile Сергей Паршиков. Оценка производительности команды в корпоративной среде. Доклад - summary личного опыта в разных компаниях. Основная идея: волюнтаризм руководителя - зло, потому что рождает обиды. Нужна прозрачная система, о которой договорились. На мой взгляд, основная ценность в другом, автоматические системы есть у многих, и волюнтаризм руководителя - средство исправить их перекосы. А фишка этой системы - dashboard, где показатели можно смотреть оперативно и корректировать свое поведение, а если система дает странные результаты - то можно вести анализ и корректировать систему не дожидаясь, пока она сработает с обидами. Плюс - команда же сама договорилась о такой системе. Сергей говорил в докладе, но без акцентов.
Теперь подробнее. Для начала - каждый руководитель должен обеспечить базу, без которой мотивация будет работать плохо. Вот они:
* Интересные задачи. Всех заставляют заниматься рутиной. Ему везло - предлагали много свободы.
* Клевый коллектив
* Достойная оплата труда
* Комфортные условия работы
Если условия обеспечили - можно начинать требовать. Заряженные сотрудники - это как бегущие быки. Хорошо бегут, только сносят все вокруг. Важно поставить заборчики, чтобы направить энергию в нужное русло. Именно эту роль выполняет KPI как инструмент оценки.
С KPI есть две популярные системы: (1) волюнтаризм руководителя, который субъективно ставит продуктивность и соответствие культуре; (2) бездушная оценка системы, к которой добавляется личный фонд руководителя. В обоих волюнтаризм приводит к обидам. Реально, на мой взгляд, проблема в том, что руководители норовят не просто поставить оценки, они еще часто не хотят внятно объяснять причины, и вообще делать результаты прозрачными. Их можно понять - объяснить без обид психологически сложно и требует времени, но обиды дает это. Впрочем, идея Сергея это тоже лечит.
Когда он придумывал систему, то держал две метафоры.
* Самомотивация - игра в теннис об стенку, когда ты должен каждый раз корректировать по своим действиям
* Бежать за чемпионами - смотреть на метрики коллег и сравнивать себя. Нужна честная, прозрачная, а не субъективная оценка.
Что входит в квартальную оценку?
* Продуктовые и бизнес-метрики - это всем понятно
* Голос клиента - это тоже продуктовая, но это не предвзятый взгляд клиента. Клиенты ставят звездочки за функционал, и это транслируются.
* Эффективность производство - на прошлой конференции был отдельный доклад и в презентации есть QR код со ссылками.
* eNPS: Критика - нейтральное - промоутеры. Формула: Промоутеры - Критика.
* Visibility - публичные выступления. Когда ты подталкиваешь выступать - ты подталкиваешь к выбору интересных задач. А еще - писать в корпоративный час о запуске фич - внутренняя видимость. Это реально поменяло словарь - когда пишешь новости сам осознаешь что сделал, позиционируешь в других терминах.
Дальше эти оценки взвешиваются для общей оценки. И есть dashboard мониторинга: снежинка, тренды, сравнительные характеристики. Dashboard видят все.
Важно, что систему придумал не он сам, они о ней договорились, ее ведет Excel. Не нравится - систему можно менять. Открытые оценки и сравнение - команды начали сравнивать, задавать вопросы - и выяснили, что методики оценки разные, начали разбираться. А вот его самого топы оценивают субъективно.
Теперь подробнее. Для начала - каждый руководитель должен обеспечить базу, без которой мотивация будет работать плохо. Вот они:
* Интересные задачи. Всех заставляют заниматься рутиной. Ему везло - предлагали много свободы.
* Клевый коллектив
* Достойная оплата труда
* Комфортные условия работы
Если условия обеспечили - можно начинать требовать. Заряженные сотрудники - это как бегущие быки. Хорошо бегут, только сносят все вокруг. Важно поставить заборчики, чтобы направить энергию в нужное русло. Именно эту роль выполняет KPI как инструмент оценки.
С KPI есть две популярные системы: (1) волюнтаризм руководителя, который субъективно ставит продуктивность и соответствие культуре; (2) бездушная оценка системы, к которой добавляется личный фонд руководителя. В обоих волюнтаризм приводит к обидам. Реально, на мой взгляд, проблема в том, что руководители норовят не просто поставить оценки, они еще часто не хотят внятно объяснять причины, и вообще делать результаты прозрачными. Их можно понять - объяснить без обид психологически сложно и требует времени, но обиды дает это. Впрочем, идея Сергея это тоже лечит.
Когда он придумывал систему, то держал две метафоры.
* Самомотивация - игра в теннис об стенку, когда ты должен каждый раз корректировать по своим действиям
* Бежать за чемпионами - смотреть на метрики коллег и сравнивать себя. Нужна честная, прозрачная, а не субъективная оценка.
Что входит в квартальную оценку?
* Продуктовые и бизнес-метрики - это всем понятно
* Голос клиента - это тоже продуктовая, но это не предвзятый взгляд клиента. Клиенты ставят звездочки за функционал, и это транслируются.
* Эффективность производство - на прошлой конференции был отдельный доклад и в презентации есть QR код со ссылками.
* eNPS: Критика - нейтральное - промоутеры. Формула: Промоутеры - Критика.
* Visibility - публичные выступления. Когда ты подталкиваешь выступать - ты подталкиваешь к выбору интересных задач. А еще - писать в корпоративный час о запуске фич - внутренняя видимость. Это реально поменяло словарь - когда пишешь новости сам осознаешь что сделал, позиционируешь в других терминах.
Дальше эти оценки взвешиваются для общей оценки. И есть dashboard мониторинга: снежинка, тренды, сравнительные характеристики. Dashboard видят все.
Важно, что систему придумал не он сам, они о ней договорились, ее ведет Excel. Не нравится - систему можно менять. Открытые оценки и сравнение - команды начали сравнивать, задавать вопросы - и выяснили, что методики оценки разные, начали разбираться. А вот его самого топы оценивают субъективно.
👍7❤2
Публикую отчет по #EnterpriseAgile - https://mtsepkov.org/AgileEnterprise-2024 Общее впечатление от конференции таково: у крупных компаний, которые хотят использовать Agile-методы всерьез на масштабах компании - получается это делать, технологии набрали зрелость. Используется OKR для координации по целям и фокусировки на развитии, а из SAFe выделилось ядро полезное ядро: PI Planing для синхронизации и получения реалистичных планов на большом масштабе, до 10 тысяч человек и более, и value stream train - средство управление потоками создания ценности с трассировкой до стратегических целей вместо обычного управления потоками задач, где выполнение задачи еще не гарантирует получения ценности для компании и потребителя. И в целом получается, что компания - не механистичный исполнительный механизм, а конструкция со свободными элементами, обладающими собственной волей, но действующими скоординировано.
Отчет включает опубликованное в ходе конференции и три доклада, конспекты которых я опубликовать не успел. Это - меньше половины докладов конференции, так как параллельно шло два потока, а на части слотов нетворкинг я предпочел докладам. Вот список.
* Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только).
* Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка.
* Анна Аверьянова из Робофинанс. Как OKR помог закрыть бизнес!
* Марина Кубанина. Технологии Доверия (ex-PwC). Про лоскутные одеяла, развод и Agile.
* Сергей Паршиков. Оценка производительности команды в корпоративной среде
* Сергей Лебедев и Максим Матвеев из YADRO. Тернистый путь к звездам: как мышление меняет компанию
* Евгений Михин из Яндекса. Continuous budgeting в портфельном управлении Яндекса
* Алексей Грабарник из Газпромбанка. Lean-управление портфелем стримов в Газпромбанке
Отчет включает опубликованное в ходе конференции и три доклада, конспекты которых я опубликовать не успел. Это - меньше половины докладов конференции, так как параллельно шло два потока, а на части слотов нетворкинг я предпочел докладам. Вот список.
* Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только).
* Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка.
* Анна Аверьянова из Робофинанс. Как OKR помог закрыть бизнес!
* Марина Кубанина. Технологии Доверия (ex-PwC). Про лоскутные одеяла, развод и Agile.
* Сергей Паршиков. Оценка производительности команды в корпоративной среде
* Сергей Лебедев и Максим Матвеев из YADRO. Тернистый путь к звездам: как мышление меняет компанию
* Евгений Михин из Яндекса. Continuous budgeting в портфельном управлении Яндекса
* Алексей Грабарник из Газпромбанка. Lean-управление портфелем стримов в Газпромбанке
❤2🔥1
Собрал и опубликовал на сайте отчет по #MergoConf https://mtsepkov.org/MergeConf-2024-Msk Конференция впервые прошла в Москве. Два дня, 8 потоков, и среди докладов доклады были очень содержательные, конспект которых не поместился один комментарий. Я сам тоже выступал. А записей конференции не будет, так что пропущенные доклады пропали безвозвратно. Так что читайте мой конспект, хотя докладов в нем мало. А организаторам хочу пожелать успехов.
🔥6
#AnalystDays Татьяна Половинкина из НЕОФЛЕКС. В чем смысл цели? Офигенно крутой доклад про работу с целеполаганием по X-матрице Стратегия - Тактика - Задачи (гипотезы) - Результаты. Матрица - потому что у тебя не обычное дерево, ты на каждом шаге заполняешь взаимную зависимость и отсекаешь то, что оказывается малозначимым. По каждому такту - лайфхаки, и иллюстрация сквозным примером.
К докладу была интересная подводка про смену эпох и про приход человекоцентричного мира, которые не про счастье людей, а про счастливых людей, которые лучше работают в компаниях. Ее я прокомменитирую в конце. А сейчас - основное содержание.
Цель - желаемый осознанный результат. Но желаниям человека свойственна нерациональность и субъективность, нельзя сделать, чтобы человек захотел сделать хранилище данных, он может захотеть лишь самостоятельно. Средство для этого - осознанность. X-матрица - способ осознанной работы с целями. Стратегия - тактика - задачи - результаты. Хотя я бы назвал его способом рационально работать с целями, потому что эмоциональную и мотивационную компоненты он не охватывает.
Лайфхаки стратегии.
* Надо максимально узнавать видение, стратегию компании, чтобы реализоваться, чтобы понимать зону возможностей в компании. А компания должна регулярно транслировать, что происходит. Например, компания живет за счет выполнения проектов, и сотрудникам надо показывать возможности текущих проектов. И это - не однонаправленный вектор: инициативный сотрудник может попробовать расширить стратегию, включив в нее работу с продуктами - если видит в этом счастье. Но это непросто.
* Вплетите личную мотивацию в стратегические намерения компании.
- Хочу работать в известной компании - хочу прокачать свой бренд, личный и компании
- Хочу работать в востребованной компании с возможностью обучаться - хочу работать с профи.
- Хочу работать с друзьями и расти - приводите друзей, компания будет расти
* Нет плохой и правильной цели. Есть ценность для вас.
- Что изменится, если достигнешь цели
- Что будет, если не достигнешь
- Ресурсы которые потратим и сохраним.
Если человек хочет машину, чтобы замечали - может, ему достаточно просто перестать скромничать и его начнут замечать?
Тактика - это вектор действия в направлении стратегической цели. Лайфхаки тактики.
* Проверка фокусировки. Хочу 1 млн прибыли - а что делать будешь сейчас? - буду путешествовать. Стоп. Или зарабатывать, или путешествовать. Ну или покажи связь.
* Тактика "от" и "к" - Чего хотите достигнуть и что сейчас мешает.
* Гибкость. Мелкие задачи, появляются новые возможности и ограничения. Нужен ли этот бой сейчас?
Лайфхаки задач.
* Цель - не средство. Не прочитать книгу, а стать книголюбом, или изучить и применять знания. Изучить курс - не цель.
* Помните, что задача - это гипотеза! Работайте по HADI циклу проверки гипотез
* Эффект Икеи или Брейнсторм. Когда хотите достичь цели - позвольте людям набросать гипотез, не давайте пути сами. Когда делаешь мебель своими руками - она чудесна. Так и с любыми путями.
* Людей, которые хотят знать алгоритмы, алгоритмы (ИИ) заменят в первую очередь.
Матрица: какие идеи на какие тактические вектора движения работают. Ставят баллы. И это отсекает гипотезы, которые в тактику не укладываются.
Лайфхаки результата.
* Проверка фокусировки. Метрики, которые мы будем измерять. Основанные на ценности, целе, результате, а не на исполнении задач. Но задачи тоже меряем - это оценивает затраченные ресурсы.
* Умение ошибаться. Это как отладка кода - мы же ошибаемся, и это не страшно. Так и со всем остальным. Надо извлекать выводы.
Матрица: какие задачи-гипотезы на какие метрики результата влияют. Там тоже индикатор - насколько гипотеза влияет, тут отсев гипотез.
К докладу была интересная подводка про смену эпох и про приход человекоцентричного мира, которые не про счастье людей, а про счастливых людей, которые лучше работают в компаниях. Ее я прокомменитирую в конце. А сейчас - основное содержание.
Цель - желаемый осознанный результат. Но желаниям человека свойственна нерациональность и субъективность, нельзя сделать, чтобы человек захотел сделать хранилище данных, он может захотеть лишь самостоятельно. Средство для этого - осознанность. X-матрица - способ осознанной работы с целями. Стратегия - тактика - задачи - результаты. Хотя я бы назвал его способом рационально работать с целями, потому что эмоциональную и мотивационную компоненты он не охватывает.
Лайфхаки стратегии.
* Надо максимально узнавать видение, стратегию компании, чтобы реализоваться, чтобы понимать зону возможностей в компании. А компания должна регулярно транслировать, что происходит. Например, компания живет за счет выполнения проектов, и сотрудникам надо показывать возможности текущих проектов. И это - не однонаправленный вектор: инициативный сотрудник может попробовать расширить стратегию, включив в нее работу с продуктами - если видит в этом счастье. Но это непросто.
* Вплетите личную мотивацию в стратегические намерения компании.
- Хочу работать в известной компании - хочу прокачать свой бренд, личный и компании
- Хочу работать в востребованной компании с возможностью обучаться - хочу работать с профи.
- Хочу работать с друзьями и расти - приводите друзей, компания будет расти
* Нет плохой и правильной цели. Есть ценность для вас.
- Что изменится, если достигнешь цели
- Что будет, если не достигнешь
- Ресурсы которые потратим и сохраним.
Если человек хочет машину, чтобы замечали - может, ему достаточно просто перестать скромничать и его начнут замечать?
Тактика - это вектор действия в направлении стратегической цели. Лайфхаки тактики.
* Проверка фокусировки. Хочу 1 млн прибыли - а что делать будешь сейчас? - буду путешествовать. Стоп. Или зарабатывать, или путешествовать. Ну или покажи связь.
* Тактика "от" и "к" - Чего хотите достигнуть и что сейчас мешает.
* Гибкость. Мелкие задачи, появляются новые возможности и ограничения. Нужен ли этот бой сейчас?
Лайфхаки задач.
* Цель - не средство. Не прочитать книгу, а стать книголюбом, или изучить и применять знания. Изучить курс - не цель.
* Помните, что задача - это гипотеза! Работайте по HADI циклу проверки гипотез
* Эффект Икеи или Брейнсторм. Когда хотите достичь цели - позвольте людям набросать гипотез, не давайте пути сами. Когда делаешь мебель своими руками - она чудесна. Так и с любыми путями.
* Людей, которые хотят знать алгоритмы, алгоритмы (ИИ) заменят в первую очередь.
Матрица: какие идеи на какие тактические вектора движения работают. Ставят баллы. И это отсекает гипотезы, которые в тактику не укладываются.
Лайфхаки результата.
* Проверка фокусировки. Метрики, которые мы будем измерять. Основанные на ценности, целе, результате, а не на исполнении задач. Но задачи тоже меряем - это оценивает затраченные ресурсы.
* Умение ошибаться. Это как отладка кода - мы же ошибаемся, и это не страшно. Так и со всем остальным. Надо извлекать выводы.
Матрица: какие задачи-гипотезы на какие метрики результата влияют. Там тоже индикатор - насколько гипотеза влияет, тут отсев гипотез.
👍3🔥2
Кейс, на котором дальше был разбор - ее стратегическая цель. Была 2 года назад - максимально расширить компетенцию SQL у сотрудников - они data-аналитики. У нее: изучение навыка, применение навыка, трансляция навыка (это обязательно, синхронизация с другими). Шаги задач и результатов - в презентации были матрицы идей с конкретными баллами. Картинка оценки часто удивляла, оказывалось, что гипотеза, которая кажется перспективной, набирала меньше всего.
Лайфхаки синхронизации
* Умение делегировать
* Поймай мяч. Кидаем проблему сотрудникам, они придумывают. И приходят за ресурсами - время, сервера - и это корректирует цель
Выводы.
* Вплетите личную мотивацию в стратегию компании. Человек не может работать над задачами без смысла
* Фокусировка
* Работа с гипотезами
* Синхронизация
Результат - человек: вовлеченный, осознанный и гибкий.
Есть ли трудности при применении подхода? Есть люди, которым трудно тратить время на осознание, легче попробовать. И им надо объяснить, в чем польза подумать над смыслом - меньше переделывать.
Выгорание - накопление конфликтов, его не бывает, если приносит удовольствие. ИТ-компания зарабатывает на проектах. И либо ты встраиваешься, либо переделываешь систему, например, перефокусируешься с проектов на продукты, и это расширяет область возможностей - но это очень зависит от твоих ресурсов.
Доклад очень хороший. Для тех, кто идет в жизни по плану. Есть альтернативная стратегия: ищем подходящие случаи. Там тоже нужна осознанность, нужно представить те варианты, которые ты видишь как перспективные, к которым внимателен в окружающем мире - это называется предпринимательская бдительность, об этом есть отдельные книги. А еще есть деление людей на дайверов и сканеров от Барбары Шер. Метод подходит для обоих, но наполнение будет сильно различаться, на мой взгляд.
А теперь - к началу доклада. Подводка была через идею эволюции миров: аграрный - индустриальный - информационный - человекоцентричный. Человекоцентриный - потому что ИИ пока лишь воспроизводит то, что придумано человеком. Важно, что человекоцентричность - не про любовь к людям, это то, что счастливые люди работают лучше. И если бы человек был счастлив в компании - он бы не искал счастья за стороне. Зарплата - способ купить счастье за счет денег.
Я тут не могу не прокомментировать. Про разделение информационного и человекоцентричного мира - интересная идея, но надо подумать про границы. На мой взгляд, есть одна граница между индустриальным миром и тем, что за ним. Я называю то, что за ним - цифровым миром, так как термин постиндустриальный уже приобрел иной смысл. Можно в индустриальном выделить отдельную фазу после фабрик (первая промышленная революция) и конвейера (вторая), открытую научно-технической револуцией 1960-х, и неточно назвать ее информационным. Или все-таки информационный мир - начало того, что будет после индустриального мира - и тогда именно он будет развиваться.
Лайфхаки синхронизации
* Умение делегировать
* Поймай мяч. Кидаем проблему сотрудникам, они придумывают. И приходят за ресурсами - время, сервера - и это корректирует цель
Выводы.
* Вплетите личную мотивацию в стратегию компании. Человек не может работать над задачами без смысла
* Фокусировка
* Работа с гипотезами
* Синхронизация
Результат - человек: вовлеченный, осознанный и гибкий.
Есть ли трудности при применении подхода? Есть люди, которым трудно тратить время на осознание, легче попробовать. И им надо объяснить, в чем польза подумать над смыслом - меньше переделывать.
Выгорание - накопление конфликтов, его не бывает, если приносит удовольствие. ИТ-компания зарабатывает на проектах. И либо ты встраиваешься, либо переделываешь систему, например, перефокусируешься с проектов на продукты, и это расширяет область возможностей - но это очень зависит от твоих ресурсов.
Доклад очень хороший. Для тех, кто идет в жизни по плану. Есть альтернативная стратегия: ищем подходящие случаи. Там тоже нужна осознанность, нужно представить те варианты, которые ты видишь как перспективные, к которым внимателен в окружающем мире - это называется предпринимательская бдительность, об этом есть отдельные книги. А еще есть деление людей на дайверов и сканеров от Барбары Шер. Метод подходит для обоих, но наполнение будет сильно различаться, на мой взгляд.
А теперь - к началу доклада. Подводка была через идею эволюции миров: аграрный - индустриальный - информационный - человекоцентричный. Человекоцентриный - потому что ИИ пока лишь воспроизводит то, что придумано человеком. Важно, что человекоцентричность - не про любовь к людям, это то, что счастливые люди работают лучше. И если бы человек был счастлив в компании - он бы не искал счастья за стороне. Зарплата - способ купить счастье за счет денег.
Я тут не могу не прокомментировать. Про разделение информационного и человекоцентричного мира - интересная идея, но надо подумать про границы. На мой взгляд, есть одна граница между индустриальным миром и тем, что за ним. Я называю то, что за ним - цифровым миром, так как термин постиндустриальный уже приобрел иной смысл. Можно в индустриальном выделить отдельную фазу после фабрик (первая промышленная революция) и конвейера (вторая), открытую научно-технической револуцией 1960-х, и неточно назвать ее информационным. Или все-таки информационный мир - начало того, что будет после индустриального мира - и тогда именно он будет развиваться.
👍3🔥1
Теперь отдельно про человекоцентричность. С одной стороны, я впервые засек в 2019 смену социального контракта сотрудника от компетентной работы за зарплату к искренней работы на цели компании в обмен на условия для счастья на работе, у меня об этом есть статьи и доклады. Но, с другой стороны, тут важная часть - счастье на работе. Я решительно не согласен с японской концепцией, в которой человек приходит в корпорацию на всю жизнь и работает исключительно на благо этой корпорации. И не имеет иного смысла жизни, вплоть до того, что при увольнении кончает жизнь самоубийством - кейсы известны. И с вариантом, к которому пришли некоторые американские компании (и не только они): мы все сделаем, чтобы вы могли круглосуточно не выходить с места работы, я тоже не согласен. Потому что жизнь человека не ограничивается работой. И там есть не только досуг и работа в профессиональных сообществах, но и социальные связи, а также рождение и воспитание детей. Конечно, есть концепт, что людей на Земле и так слишком много, поэтому рожать новых не нужно, но, по-моему, он доказал свою несостоятельность. Так что тут важны акценты. А Харари, на которого Татьяна ссылалась в вопросах, на мой взгляд, мыслит в рамках этих концептов. Так что индивидуальное и субъективное счастье - правильно.
👍6❤3🔥3
#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, если внутренний - наоборот, просто бухгалтера хотят черные буквы на белом фоне, а не полутона.
* Производительность - можно позднее, если у вас не будет ее сразу. Но важно: когда поделили, то остаются обе истории, медленная и быстрая, а не забыли, что сделали медленно.
Если наша задача - оставлять инкремент, то декомпозиция по слоям архитектуры или фазам разработки не подходит. Бэк без 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 - микропроект, который можно сдать заказчику.
Размер декомпозиции. 5 историй в спринт. Ему такая цифра нравится. Реально идем итеративно от какого-то старта.
Выгоды маленьких история - мы можем многое опустить вниз, и на это место положить ценное. B снижает риски: если история одна и что-то заблокировала - стоп. А если три - нормально.
Все про MVP знают. Но не делат. Оправдания разные.
* Все равно релизить, зачем откладывать;
* Все на бэк, можем поставлять раз в месяц - про месяц правда, но можем или хотим
* Лень - когнитивная скупость.
* Еще ответ: наша ситуация уникальна.
Все это отмазки. И что будут слишком маленькая история, которая не приносит ценности - тоже, так получается редко.
Так что делите истории, чтобы они были ценными и маленькими. User story - микропроект, который можно сдать заказчику.
👍2
#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 цикл. И есть лайфхак: у вас будет не бедный продукт, а сфокусированный или сконцентрированный, смена термина многое меняет в восприятии.
Что сделать то, что не делали, нужны две вещи: знакомые точки кристаллизации, от которых можно оттолкнуться и сегментация, разложение процесса по шагам. Что будет точкой кристаллизации? Можно представить discovery как работу аналитиком в ситуации, когда требования сводятся к идее нового продукта, изучение потребностей целевой аудитории представить как выявление пользовательских требований, а изучение рыночного ландшафта - как изучение предметной области. Вроде получается почти знакомый проект. Далее по шагам.
Шаг 1. Перепрошиваем мозг, меняем майндсет. Продукт думает: зачем это нужно бизнесу и пользователю, и спрашивает бизнес, почему пользователь будет покупать именно этот продукт. Ориентация на цели, сроки и бюджет вторичны. Гипотезы и проверка через даныне - не фантазии. Постоянные улучшения, гибкость, толерантность к неопределенности. На дискавери надо не все: спрашивать зачем, понимать потребности пользователя, связываем задачи бизнеса с пользователем (это умеем), строим гипотезы, не боимся неопределенности.
Шаг 2. Ищем знакомое в незнакомом, перешиваем и развиваем навыки. Cust Dev похож на бриф, исследуем конкурентов - как заказчика, на открытых данных, объемы рынка - по открытым данным конкурентов.
Cust Dev.
* Не знаете откуда взять аудиторию? Запросить у заказчика - нормально. Еще соцсети
* Не знаете сегментирование - JTBT. Поймите, какую работу выполняет продукт, напрмиер, йогурт с высоким содержанеим белка - когда его применяют. И это дает аудиторию и вопросу к ней - про
* Какую методику выбрать? Чем больше неопределенности - качественная, подробности - количественная.
* Интервью. Короткие - люди вам не должны. Но задавайте открытые вопросы. Не про ваши гипотезы, а про то, как они действуют. Узнаете новое. Но это - пользователям, а заказчику - гипотезы и сценарии, иначе он будет увеличивать MVP.
Исследование конкурентов.
Поле конкурентов и ответ - стоит ли лезть на это поле.
Фреймворков много. Ее любимый - магический квадрант Гартнера, Фичи и UX, кружок - объем рынка.
Объемы рынка. Зачем? Если пришли с идеей, а денег нет - люди не привыкли платить - то лучше не лезть, это трудно.
Фреймворков много, наиболее легкий - TAM-SAM-SOM.
Все эти фреймворки в пределе сводится к здравому смыслу и business view.
Неопределенности стало меньше, но появился хаос данных.
Шаг 3. Гипотезы - проводник через хаос данных. Научиться мыслить гипотезами. Верхнеуровневые рамочные - цифровые - улучшение продукта. Рамка - идея, например, всем будет полезен магазин готовых маршрутов. Цифровые про MVP, проверка продукта.
Шаг 4. MVP. Определились с составом продукта, теперь его надо обрезать. Все кивают на концепцию, но как только реально доходит до урезания - не режут. Не переживайте, что первый продукт бедный - будет возможность дополнить. HADI цикл. И есть лайфхак: у вас будет не бедный продукт, а сфокусированный или сконцентрированный, смена термина многое меняет в восприятии.
❤2
Здесь много трагедий и боли. Стартап хотел цивилизовать рынок щебня. Ребята 4 месяца разговаривали на прототипов. Самолет, к которому прилепили бассейн и спортзал. Срезать не удалось, потому что MVP срезать не удалось, заказчик полюбил. В результате MVP разрабатывали год, потратили все деньги ,на маркетинг и продвижение не осталось - а это дороже разработки. А сейчас конкуренты пришли с идеей выкупить идею - рынок созрел.
Для сокращения MVP - делайте быстро и малыми силами. Не 30 человек год, а три за месяц.
Шаг 5. Во-время останавливаемся. Discovery - продуктовая гипотеза. Весь продуктовый цикл не закрываете. Там маркетринг, юнит-экономика и много чего.
И в заключении. Иногда discovery - крик бизнеса о помощи, не игнорируйте. Бизнес-аналитик - может сделать.
Для сокращения MVP - делайте быстро и малыми силами. Не 30 человек год, а три за месяц.
Шаг 5. Во-время останавливаемся. Discovery - продуктовая гипотеза. Весь продуктовый цикл не закрываете. Там маркетринг, юнит-экономика и много чего.
И в заключении. Иногда discovery - крик бизнеса о помощи, не игнорируйте. Бизнес-аналитик - может сделать.
👍2
Как обычно, слайды моего доклада - сразу на моем сайте https://mtsepkov.org/SoftSkills-AD-2024
🔥1
#AnalystDays Вера Бонарева из Сбербанк. Преодоление сложностей в интеллектуальном распознавании документов: инновационные подходы и роль LLM. Это блиц-рассказ о том, как усложнялась по мере реализации задача распознования документов, появлялись все новые кейсы и способы распознавания.
* Первоначально задача выглядела просто: приходят сканы и документы разных типов (xml, excel, word, pdf) - и надо опознать тип. Полный автомат, документы передает внешний сервис. ему же оправляют ответ. Настроили распознавание текста с изображений, парсеры xml и excel, систему правил, которая применяется после распознавания скана или парсера.
* Быстро выяснилось, что приходят архивы с большим количеством файлов, надо распаковать и каждый обрабатывать отдельно.
* Затем - что в архиве может приходить потоковый скан на сотни страниц, который надо разбить на отдельные документы.
* Затем - добавили верификацию пользователями того, что распозналось плохо или неуверенно - у системы появился GUI, а с документом приходят данные - кто должен подтвердить. Верификаторы - дефицитный ресурс, в пике потока получается задержка до пары дней, поэтому если в архиве документы, которые распознаются хорошо и которые плохо - то статус надо вести не у архива в целом. а по отдельным документам в нем. И еще специальные меры, чтобы документ, ожидающий верификации, не был сброшен из очереди по сроку.
* Из паспортов и некоторых других документов надо вытаскивать атрибуты - ФИО, серия, номер и так далее, для этого подключили ML, с паспортами и другими документами фиксированных форматов она справляется.
* Из договоров ML атрибуты вытаскивает плохо, там большие тексты - про них спрашивают LLM, GigaQuery и ответ сравнивают с тем, что дала система правил.
* Поскольку верификация - избирательная, то ошибки проскакивают, и пользователь может отправить на повторное распознавание, которое всегда с верификацией, даже для простых документов.
Такое вот усложнение системы в ходе разработки и эксплуатации - типичная история.
* Первоначально задача выглядела просто: приходят сканы и документы разных типов (xml, excel, word, pdf) - и надо опознать тип. Полный автомат, документы передает внешний сервис. ему же оправляют ответ. Настроили распознавание текста с изображений, парсеры xml и excel, систему правил, которая применяется после распознавания скана или парсера.
* Быстро выяснилось, что приходят архивы с большим количеством файлов, надо распаковать и каждый обрабатывать отдельно.
* Затем - что в архиве может приходить потоковый скан на сотни страниц, который надо разбить на отдельные документы.
* Затем - добавили верификацию пользователями того, что распозналось плохо или неуверенно - у системы появился GUI, а с документом приходят данные - кто должен подтвердить. Верификаторы - дефицитный ресурс, в пике потока получается задержка до пары дней, поэтому если в архиве документы, которые распознаются хорошо и которые плохо - то статус надо вести не у архива в целом. а по отдельным документам в нем. И еще специальные меры, чтобы документ, ожидающий верификации, не был сброшен из очереди по сроку.
* Из паспортов и некоторых других документов надо вытаскивать атрибуты - ФИО, серия, номер и так далее, для этого подключили ML, с паспортами и другими документами фиксированных форматов она справляется.
* Из договоров ML атрибуты вытаскивает плохо, там большие тексты - про них спрашивают LLM, GigaQuery и ответ сравнивают с тем, что дала система правил.
* Поскольку верификация - избирательная, то ошибки проскакивают, и пользователь может отправить на повторное распознавание, которое всегда с верификацией, даже для простых документов.
Такое вот усложнение системы в ходе разработки и эксплуатации - типичная история.
👍1
#AnalystDays Наталья Семенова. Коллеги, мы тоже на одном языке говорим. Рассказ об известной всем аналитикам, и не только им, проблеме, что одни и те же слова в разных проектах могут означать совершенно разное. Потому что значение слов определяет контекст, к которому относится не только предметная область, но и способ ведения проекта, например, в заказной, продуктовой и inhouse-разработке работа с требованиями сильно отличается, хотя описывается одним и тем же выражением "собрать требования" или "выявить требования". Проблема как бы известна, но многие почему-то уверены, что это происходит потому, что люди неправильно употребляют слова. начинается холивар и апелляции к словарям. И это, в том числе, проявляется на собеседованиях: ответ отклоняют как неверный. А реально проблема в различии контекстов. Это даже в BABOK есть, правда очень кратко. И аналитик должен уметь распознавать контексты, и дальше вести коммуникацию с их учетом. А если подозревает, что контекст ему не знаком - то не стесняться спрашивать или иным образом уточнять значения слов. В докладе - много кейсов, а также подходы к прояснению контекста.
Этого доклада не было в программе - Наталья выступала на BarCamp, рассказывал доклад, который делала на Стачке, и то ли конференция вообще не вела запись докладов, то ли запись этого не получилась. А AnalystDays ведет запись и трансляцию не только основных треков, но и BarCamp, так что теперь запись есть.
Для начала были кейсы, касающиеся различных типов проектов. Потому что именно о них часто не подозревают, и на собеседованиях наступают на эти грабли.
Мини сценка, разговор двух аналитиков:
- Стейкхолдеры у нас никакие...
- А ты что, ты же тоже стейкхолдер?
- Как я стейкхолдер. это же заказчики?
Собрать требования.
* Уточнить у ЛПР, поискать в документации требования и выявить заинтересованных лиц.
* Изучить бизнес-требования, запросить описания процессов, собрать у стейкхолдеров
* Сформировать гипотезы, сделать тестирование на фокус-группе, оценить стоимость и ROI.
Это различия внутренней, заказной и продуктовой разработки - требования собираем по-разному. И это - за рамками разговора.
Взаимодействие с командой.
* А что общаться, написал ТЗ и отдал, дальше на вопросы...
* У других - плотное взаимодействие: истории, DoD, сделал сторителлинг и так далее.
Разные методы работы команды. И отличия надо понимать, выяснять. что тебя ждет в проекте и действовать сообразно, или предлагать изменения, тоже осознанно.
А что делать до разработки?
* discovery и presale
* product market fit, анализ конкурентов
Тоже заказная и продуктовая разработка.
Ретро, разное отношение
* Сначала было скучно, потом весело.
* Проводим по регламентам каждый квартал, хотя хочется чаще.
* Проводим каждый спринт и отдельно со смежниками по необходимости.
Зависит от зрелости бизнес-процессов: хаотичные, по регламентам, постоянные улушения - на слайде была шкала из 5 уровней. Я бы отнес это не к зрелости бизнес-процессов, а к культуре ведения проекта, но такое различие терминов - тоже часть культурной рамки.
Степень свободы аналитика
* RACI по процессам, с заданными инструментами
* задачи на синках, целесообразность обсуждается, oD и критерии качества тоже.
Начинающим интересно по регламентам, опытные - сами решают по ситуации.
Как выявлять диференцииаторы контекста? Рассматривают 4 квадранта: Знать - Узнавать; Все просто - Все серьезно.
Все просто.
* Знаем: быстрая память и интуиция из насмотренности.
* Узнаем: спросить в разговоре или погуглить. Очень часто пытаемся угадать - а это неправильно.
Все серьезно.
* Надо знать про стандарты, метрики, модели и техники, инструменты, регламенты и заглядывать туда. по необходимости. Быстрая проверка через стандарты помогает.
* Модель IGOE: inputs - guides (как будем делать) - ouputs - enablers (что поможет выполнить).
* Кастомные модель 6 перспектив: люди, процессы, время, ресурсы, инструменты, скоуп. Применялась в EPAM, она делала доклад, можно посмотреть.
Этого доклада не было в программе - Наталья выступала на BarCamp, рассказывал доклад, который делала на Стачке, и то ли конференция вообще не вела запись докладов, то ли запись этого не получилась. А AnalystDays ведет запись и трансляцию не только основных треков, но и BarCamp, так что теперь запись есть.
Для начала были кейсы, касающиеся различных типов проектов. Потому что именно о них часто не подозревают, и на собеседованиях наступают на эти грабли.
Мини сценка, разговор двух аналитиков:
- Стейкхолдеры у нас никакие...
- А ты что, ты же тоже стейкхолдер?
- Как я стейкхолдер. это же заказчики?
Собрать требования.
* Уточнить у ЛПР, поискать в документации требования и выявить заинтересованных лиц.
* Изучить бизнес-требования, запросить описания процессов, собрать у стейкхолдеров
* Сформировать гипотезы, сделать тестирование на фокус-группе, оценить стоимость и ROI.
Это различия внутренней, заказной и продуктовой разработки - требования собираем по-разному. И это - за рамками разговора.
Взаимодействие с командой.
* А что общаться, написал ТЗ и отдал, дальше на вопросы...
* У других - плотное взаимодействие: истории, DoD, сделал сторителлинг и так далее.
Разные методы работы команды. И отличия надо понимать, выяснять. что тебя ждет в проекте и действовать сообразно, или предлагать изменения, тоже осознанно.
А что делать до разработки?
* discovery и presale
* product market fit, анализ конкурентов
Тоже заказная и продуктовая разработка.
Ретро, разное отношение
* Сначала было скучно, потом весело.
* Проводим по регламентам каждый квартал, хотя хочется чаще.
* Проводим каждый спринт и отдельно со смежниками по необходимости.
Зависит от зрелости бизнес-процессов: хаотичные, по регламентам, постоянные улушения - на слайде была шкала из 5 уровней. Я бы отнес это не к зрелости бизнес-процессов, а к культуре ведения проекта, но такое различие терминов - тоже часть культурной рамки.
Степень свободы аналитика
* RACI по процессам, с заданными инструментами
* задачи на синках, целесообразность обсуждается, oD и критерии качества тоже.
Начинающим интересно по регламентам, опытные - сами решают по ситуации.
Как выявлять диференцииаторы контекста? Рассматривают 4 квадранта: Знать - Узнавать; Все просто - Все серьезно.
Все просто.
* Знаем: быстрая память и интуиция из насмотренности.
* Узнаем: спросить в разговоре или погуглить. Очень часто пытаемся угадать - а это неправильно.
Все серьезно.
* Надо знать про стандарты, метрики, модели и техники, инструменты, регламенты и заглядывать туда. по необходимости. Быстрая проверка через стандарты помогает.
* Модель IGOE: inputs - guides (как будем делать) - ouputs - enablers (что поможет выполнить).
* Кастомные модель 6 перспектив: люди, процессы, время, ресурсы, инструменты, скоуп. Применялась в EPAM, она делала доклад, можно посмотреть.
Как узнавать дифференциалы в серьезных случаях?
* курсы, конференции - загружать теорию
* Опыт
* Моделирование и концептуализация - для тех, кто может сам из непонятных ситуаций создавать модели.
По концептуализации у Натальи был доклад на прошлой AnalystDays.
В конце было еще обсуждение с кейсами от участников.
* курсы, конференции - загружать теорию
* Опыт
* Моделирование и концептуализация - для тех, кто может сам из непонятных ситуаций создавать модели.
По концептуализации у Натальи был доклад на прошлой AnalystDays.
В конце было еще обсуждение с кейсами от участников.
#AnaystDays Галина Кореневская из ГК Самолет. Как мы изобрели Business and Data Flow Diagram. В 2022 Самолет решил стать лидером рынка за счет покупки крупной компании. Перед Ит поставили задачу поддержать быстрый переход компаний в однородное состояние, для чего сделать описание бизнес-процессов, которое бы соответствовало действительности. И разобраться с более, чем 350 ИТ-системами. Для описания бизнес-процессов надо выбрать нотацию. Они собрали цели бизнеса и ИТ. Бизнесу достаточно BPMN, а ИТ, помимо описания бизнес-процессов, хотели видеть его поддержку ИТ-системами, сущности и интеграцию систем. И они доработали BPMN-нотацию для описания. Рассказ был о доработках и о требованиях к описаниям.
* Нейминг - краткое наименование отражает смысл процесса. BPMN storm - тип asis/tobe. рейтинг качества, ниже 8 - надо переделать
* Границы. Старт - триггер, он должен быть подписан! А это - важно. И именно событие. Не "необходим пересмотр лимитов", а почему он необходим, например, увеличился объем работ
* Действия: гранулярность, кто выполняет и в какой системе. должен быть результат, роль которая выполняет и входящие параметры - документ. Могут быть подпроцессы.
* Стрелки - явные шлюзы, понимать: от процесса к документу - результат, от документа в задачу - параметр.
* Сущности делятся цифровые и нецифровые. Сканы - тоже нецифровые. Цифровые - с жизненным циклом. Если жизненный цикл в одной системе - фиолетовый, а много систем - зеленый. Клиент - живет в нескольких, задача - только в jira.
* Описания интеграций. Автоматическая задача передачи данных (шестеренка) - стрелка потока нужного цвета, входит в задачу принимающей системы, на выходе - ее документ. Зеленые стрелки - передача сущностей, а фиолетовая = передача событий, меняющих состояния документов. Например, из СРМ в учетную систему идут клиент и договор - зеленая стрелка, в учетной системе к договору привязываются платежи, они в CRM не отправляются, но после оплаты идет нотификация для смены состояния договора фиолетовой стрелкой.
Результаты.
* схемы стали объемнее. Увы.
* 40 воркшопов с бизнесом и ИТ. 15 команд, 4 ИТ-блока.
* Архитектор не участвует во встречах си бизнесом - егму оказывается достаточно документов.
* Повысили информативность для команд разработки
* Бизнес вовлекли в описание процессов. Они не отказывались от участия.
* Нейминг - краткое наименование отражает смысл процесса. BPMN storm - тип asis/tobe. рейтинг качества, ниже 8 - надо переделать
* Границы. Старт - триггер, он должен быть подписан! А это - важно. И именно событие. Не "необходим пересмотр лимитов", а почему он необходим, например, увеличился объем работ
* Действия: гранулярность, кто выполняет и в какой системе. должен быть результат, роль которая выполняет и входящие параметры - документ. Могут быть подпроцессы.
* Стрелки - явные шлюзы, понимать: от процесса к документу - результат, от документа в задачу - параметр.
* Сущности делятся цифровые и нецифровые. Сканы - тоже нецифровые. Цифровые - с жизненным циклом. Если жизненный цикл в одной системе - фиолетовый, а много систем - зеленый. Клиент - живет в нескольких, задача - только в jira.
* Описания интеграций. Автоматическая задача передачи данных (шестеренка) - стрелка потока нужного цвета, входит в задачу принимающей системы, на выходе - ее документ. Зеленые стрелки - передача сущностей, а фиолетовая = передача событий, меняющих состояния документов. Например, из СРМ в учетную систему идут клиент и договор - зеленая стрелка, в учетной системе к договору привязываются платежи, они в CRM не отправляются, но после оплаты идет нотификация для смены состояния договора фиолетовой стрелкой.
Результаты.
* схемы стали объемнее. Увы.
* 40 воркшопов с бизнесом и ИТ. 15 команд, 4 ИТ-блока.
* Архитектор не участвует во встречах си бизнесом - егму оказывается достаточно документов.
* Повысили информативность для команд разработки
* Бизнес вовлекли в описание процессов. Они не отказывались от участия.
❤3🔥1
#AnalystDays Григорий Печенкин. Пять граней мышления аналитика. Кто такое - хороший аналитик? Это человек с особым типом мышления, у которого есть 5 аспектов. Доклад был о них, на кейсе работы с обобщенным университетом по внедрению системы индивидуальных образовательных траекторий студентов. На первой встрече присутствуют трое: Проректор, который хочет модель, где студенты сами выбирают что изучать; руководитель учетно-методического отдела, который говорит, что для этого надо совсем немного: зафиксировать индивидуальные планы и сделать выбор нагрузки; и главный от ИТ, который поддерживает и говорит, что все данные есть - остались от предыдущего заказчика. Проректор слышит коллег и говорит: ОК, все поддерживают, договорились, работаем. Вопрос: о чем договорились, ко эти лица и что делать дальше? И тут нам как раз помогает способы мышления.
1. Системное мышление. Смотрим на мир как на систему систем. Книжек - много. Но! это не формальная теория, которая дает аппарат, а философская концепция с шаблонами мышления. У него было три подхода: в институте, (2) когда стал аналитиком - Системный анализ, почитал книгу, к жизни отношения не имеет (3) книга где описано как действует.
Сколько уровней требований? Три. Это - хорошее число. А еще теория систем: наш продукт - часть надсистемы, и оттуда верхний уровень. Внутри системы есть взаимодействие с внешним миром - это пользовательская и интеграция, окружение. И третий - требования к устройству (функциональные или системные). И это - причины классификации, а не формальная классификация.
Три стейкхолдера, они на разных уровнях.
* Проректор - университет в целом.
* УМУ - смежная система внутри университета. При этом она говорит из своей позиции закладывает две бомбы. Потому как индивидуальные учебные планы - сложная бюрократия, а планирование нагрузки означает, что вы предсказали, что студенты выберут.
* Главный по ИТ - а тут зависит от ситуации в университете.
2. Логическое мышление. Иногда логика дает сбои - когнитивные искажения и другие.
Искажения частное-общее: Чрезмерное обобщение, эффект знакомства, иллюзия кластеризации.
Решаем не задачу, которая стоит, а знакомую: фрейминг и другое.
Трехцветных котов не бывают, только кошки, так говорит генетика и вы это знаете. Приходит заказчик, говорит: у меня трехцветный кот. Как к этому относиться? Может быть, это исключение - хотя генетика теоретически не позволяет, реально на 3000 котов один такй есть. Либо у кота просто три оттенка серого цвета, и еще голубые глоза. Или модный постер с многоцветным котом. Наши ограничения, что трехцветных не бывает - эффект фрейминга.
Фраза - гипотезы, что за ней - отсечение гипотез. Дальше - уточняющие вопросы. И верификация. Потом - вывод. Разветвляющийся конус гипотез, потом - схловываем. Главное - не пренебрегайте верификацией. В 9 из 10 проговорите то, что всем понятно. Но в 1 из 10 оказывается, что все неправильно.
Главный по ИТ может быть
* ответственным за только ИТ-администрацию
* главный или проректор по цифровизации
* глава ИТ-факультета, профессор, который заодно отвечает за ИТ-ландшафт
И надо уточнять. И далее - уточнять его интересы
3. Мир интересов. Его надо видеть.
У Главного по ИТ могут быть такие интересы:
* снизить количество ручной работы
* навести порядок в процессах
* поддержать новую модель
* защитить свою команду
* не загружать себя работой
* потопить конкурента
У других - тоже свои интересы, и получается диаграмма интересов.
Луковичная диаграмма. Рисуем стейкхолдеров по слоям подсистема-надсистема, и рисуем интересы.
4. Критическое мышление. Во всех университетах говорят, что это надо ставить, но понимают по-разному. Его понимание - это Сомнения на пути к истине.
Профессия, где необходимо - судья. Состязательный сопсоб ведения процесса, две стороны. И судья должен смотреть обе точки зрения, полагаться на независимые свидетельства. В жизни тоже: что выбрать айфон или андроид. И убеждения - основание.
1. Системное мышление. Смотрим на мир как на систему систем. Книжек - много. Но! это не формальная теория, которая дает аппарат, а философская концепция с шаблонами мышления. У него было три подхода: в институте, (2) когда стал аналитиком - Системный анализ, почитал книгу, к жизни отношения не имеет (3) книга где описано как действует.
Сколько уровней требований? Три. Это - хорошее число. А еще теория систем: наш продукт - часть надсистемы, и оттуда верхний уровень. Внутри системы есть взаимодействие с внешним миром - это пользовательская и интеграция, окружение. И третий - требования к устройству (функциональные или системные). И это - причины классификации, а не формальная классификация.
Три стейкхолдера, они на разных уровнях.
* Проректор - университет в целом.
* УМУ - смежная система внутри университета. При этом она говорит из своей позиции закладывает две бомбы. Потому как индивидуальные учебные планы - сложная бюрократия, а планирование нагрузки означает, что вы предсказали, что студенты выберут.
* Главный по ИТ - а тут зависит от ситуации в университете.
2. Логическое мышление. Иногда логика дает сбои - когнитивные искажения и другие.
Искажения частное-общее: Чрезмерное обобщение, эффект знакомства, иллюзия кластеризации.
Решаем не задачу, которая стоит, а знакомую: фрейминг и другое.
Трехцветных котов не бывают, только кошки, так говорит генетика и вы это знаете. Приходит заказчик, говорит: у меня трехцветный кот. Как к этому относиться? Может быть, это исключение - хотя генетика теоретически не позволяет, реально на 3000 котов один такй есть. Либо у кота просто три оттенка серого цвета, и еще голубые глоза. Или модный постер с многоцветным котом. Наши ограничения, что трехцветных не бывает - эффект фрейминга.
Фраза - гипотезы, что за ней - отсечение гипотез. Дальше - уточняющие вопросы. И верификация. Потом - вывод. Разветвляющийся конус гипотез, потом - схловываем. Главное - не пренебрегайте верификацией. В 9 из 10 проговорите то, что всем понятно. Но в 1 из 10 оказывается, что все неправильно.
Главный по ИТ может быть
* ответственным за только ИТ-администрацию
* главный или проректор по цифровизации
* глава ИТ-факультета, профессор, который заодно отвечает за ИТ-ландшафт
И надо уточнять. И далее - уточнять его интересы
3. Мир интересов. Его надо видеть.
У Главного по ИТ могут быть такие интересы:
* снизить количество ручной работы
* навести порядок в процессах
* поддержать новую модель
* защитить свою команду
* не загружать себя работой
* потопить конкурента
У других - тоже свои интересы, и получается диаграмма интересов.
Луковичная диаграмма. Рисуем стейкхолдеров по слоям подсистема-надсистема, и рисуем интересы.
4. Критическое мышление. Во всех университетах говорят, что это надо ставить, но понимают по-разному. Его понимание - это Сомнения на пути к истине.
Профессия, где необходимо - судья. Состязательный сопсоб ведения процесса, две стороны. И судья должен смотреть обе точки зрения, полагаться на независимые свидетельства. В жизни тоже: что выбрать айфон или андроид. И убеждения - основание.
❤3
На вас можно повлиять.
* Изолировать от другой точки зрения: не ходите к этому, он не решает. Если не изолировать, то дискредитировать - он не решает, дурак, некомпетентен.
* Подмена свидетелей. Негатив вычеркиваем, позитив лайкаем и добавляем от себя
* Создание информационного фона. Много каналов - с анонсы, и иногда там крупицы золота. Никто не комментирует. А в два ночи - 70 комментариев. А потом - 50 к другому. И это - один человек, к нему идут. Он пришел из губернаторской команды и принес культуру с командой поддержки. И это - способ воздействия на убеждения.
Манипулируют все. родители детьми, супруги друг другом и так далее. И когда приходите со своей системой - она влияет на интересы и весь спектр может быть применен.
Был еще пятый аспект, но я не записал. Над будет посмотреть презентацию и запись...
* Изолировать от другой точки зрения: не ходите к этому, он не решает. Если не изолировать, то дискредитировать - он не решает, дурак, некомпетентен.
* Подмена свидетелей. Негатив вычеркиваем, позитив лайкаем и добавляем от себя
* Создание информационного фона. Много каналов - с анонсы, и иногда там крупицы золота. Никто не комментирует. А в два ночи - 70 комментариев. А потом - 50 к другому. И это - один человек, к нему идут. Он пришел из губернаторской команды и принес культуру с командой поддержки. И это - способ воздействия на убеждения.
Манипулируют все. родители детьми, супруги друг другом и так далее. И когда приходите со своей системой - она влияет на интересы и весь спектр может быть применен.
Был еще пятый аспект, но я не записал. Над будет посмотреть презентацию и запись...
В конце недели прошла осенняя #AnalystDays. На ней было очень сильных докладов, и я желаю организаторам и ПК сохранить этот уровень. Я публиковал заметки в ходе конференции и сейчас собрал их в отчет https://mtsepkov.org/AnalystDays-2024b, дополнив еще несколькими докладами, заметки с которых сразу опубликовать не успел. А уже завтра начинается #Teamlead, в котором я тоже участвую и выступаю.
👍10
#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 месяца? Должен быть фронт на год. А еще: есть ограничения. И нет ли кого-то, кто может получить новую компетенцию.
* Кейс-1. Ваня приходит с офером x2. Столько платить не можем, а он нужен. Но не можем. И человек ушел. Что делать? Надо планировать рост ключевых сотрудников заранее. На замену ведущим готовить людей из middle.
* Кейс-2. Есть люди, которые мониторят рынок. И спрашивают "а почему моя зарплата не соответствует". Надо следить самим за рынком зарплат. При этом вилки и медианы надо адаптировать на ситуацию в компании - у всех разные возможности. А дальше держим в зеленой зоне в районе медианы. Если границы - сложно работать: сотрудник на низкой границе придет с офером с большим повышением, и удержать будет сложно, а для сотрудника на верхней границы нет возможностей роста и это - риск, он уйдет в другую команду и компанию на другую позицию.
* Кейс-3. Растим мидла Васю на позицию ведущего. Индивидуальный план развития: что мы ожидаем для роста, и сроки выхода на позицию, это не пара месяцев. А вам как руководителю - надо обеспечить позицию ведущего и бюджет для нее. И встречи. Раз в пару недель - прогресс роста.
* Кейс-4. Сотрудник не соответствует позиции, но не признает. Такого не был, это всего один раз, это не говорили. Важно - фиксировать все, что было на ревью. Что вы говорили и вам отвечали. Не хочу быть лидом, а проводить собеседования - хочу. Дальше мы можем поднимать историю во взаимодействии.
* Кейс-5. Аналитик переросла позицию. И внутри команды не решается. Нужен вышестоящий руководитель или HR. Есть ли подходящая позиция в соседнй команде? Если есть - идет туда. Но надо еще подготовить замену у себя - из соседней команды. Это надо делать заранее, но сотрудники в случае понятных перспектив обычно лояльно относятся к ситуации. Чтобы все это видеть - нужны карты персонала. Несколько команд, траектории и проблемы. Ведут в Miro, в презентации был пример.
* Кейс-6. В команде только один с конкретной специализацией. А второго нанять нельзя - нет денег и задач для него. Есть два варианта: (а) аналогичный специалист в другой команде и страховка друг друга и (б) рост кого-то во вторую специализацию. Помогают увидеть карты персонала. Они показывают дизайн команды: грейды внутри специализации и соотношение разных специализаций - балансировка мощности. Из карты видно, где проблемы - провалы и отсутствие возможности роста.
* Кейс-7. Два разработчика мидл активно развиваются. И у вас цепочка middle - senior - техлид. Все хорошо. Но приходит второй - а у вас нет третьей позиции senior, у вас она вообще одна. Надо заранее понимать - кого двигать. Карта рисков. Сотрудники: ценность и возможность развития. И Риски: как избегать и что делать в случае риска. Excel с раскраской.
* Кейс-8. 2022: 2 техлида и один ведущий ведущий уезжают, при чем ведущий страховал одного техлида. Смотрим на карту. Ищем других ведущих - не нашли. И открыла вакансию с перспективой роста, которую проговаривала на входе. За 2-3 месяца получилось подготовиться.
* Кейс-9. Тимлид Аня просит срочно согласовать вакансию аналитика в команду. Тут надо остановиться и подумать: много работы навсегда или это завал на 3 месяца? Должен быть фронт на год. А еще: есть ограничения. И нет ли кого-то, кто может получить новую компетенцию.
❤1