#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
Кейсы 10-14.
* Больничные на 2-3 месяца. Редко, но внезапно. Надо заранее планировать замены ключевых. А если вышестоящий? Она в том году выпала, тимлиды справились за счет инструментов на горизонтальной связи..
* Многодетный мать/отец вышел из декрета и к работе есть вопросы. Надо восстанавливать - давать автономные задачи, чтобы он мог организовывать работу
* Тяжелые проблемы в семье - тоже нужно дать возможность восстановиться, на обособленных задачах. Но надо договориться про срок.
* Декрет ключевой сотрудницы. Он прост - потому что известно заранее. Инструменты помогут.
* Кланы: привел друга, хантит из соседнего подразделения, пришла команда, друзья тимлида. (а) группирующий риск - как привел - так и уведет. (б) увод между командами ухудшает отношения тимлидов.
Рисков - много, список будет дополняться. В презе - список. Работа с рисками. Вероятность наступления и тяжесть последствий. низкий-средний-тяжелый.
* Тяжелый-вероятный: архитектор, которого год искали - не проходит испытательный срок
* Легкий-вероятный: джун не проходит - не так страшно.
* маловероятный-тяжелый: Недовольный сотрудник и пишет гневное прощальное письмо
Кейс 15-17. Те же инструменты могут использоваться для других целей.
* Оценка встройки на собеседованиях. Классный человек, но через полгода станет скучно - сразу делаем сценарий.
* Проект завершился - перераспределяем людей. Карта персонала.
* Сборка новой команды - тоже карта персонала. Людей надо как-то вытащить, в карте - есть замены и риски.
Основа работы Performance review: есть цикличность и сроки. Раз в полгода - зависит от динамики команды.
* ИПР стыкованы с performance review.
* Обратная связь после performance. И обязательно слушаем его ответ.
* Регулярные 1:1 - по ИПР.
* Планирование. годовое: зарплаты, должности, соотносим с рынком. И дальше по мере изменений - актуализируем.
* И не забываем все записывать. Это не только вам, но и тому, кто придет на смену. Преемственность в руководстве.
Что это дает? Для сотрудника: понятные правила, ИПР, нестандартная траектория - не замкнут в команде. Для тимлида - картинка сверху, проблемные места и планы по ним.
Набор инструментов - для 50+ Для 5-10 можно использовать отдельные инструменты. Важно - работа с рисками, сценарии "а что если". Могут помочь: руководитель и HR (они неплохо сценируют). И обязательно все записывать!
* Больничные на 2-3 месяца. Редко, но внезапно. Надо заранее планировать замены ключевых. А если вышестоящий? Она в том году выпала, тимлиды справились за счет инструментов на горизонтальной связи..
* Многодетный мать/отец вышел из декрета и к работе есть вопросы. Надо восстанавливать - давать автономные задачи, чтобы он мог организовывать работу
* Тяжелые проблемы в семье - тоже нужно дать возможность восстановиться, на обособленных задачах. Но надо договориться про срок.
* Декрет ключевой сотрудницы. Он прост - потому что известно заранее. Инструменты помогут.
* Кланы: привел друга, хантит из соседнего подразделения, пришла команда, друзья тимлида. (а) группирующий риск - как привел - так и уведет. (б) увод между командами ухудшает отношения тимлидов.
Рисков - много, список будет дополняться. В презе - список. Работа с рисками. Вероятность наступления и тяжесть последствий. низкий-средний-тяжелый.
* Тяжелый-вероятный: архитектор, которого год искали - не проходит испытательный срок
* Легкий-вероятный: джун не проходит - не так страшно.
* маловероятный-тяжелый: Недовольный сотрудник и пишет гневное прощальное письмо
Кейс 15-17. Те же инструменты могут использоваться для других целей.
* Оценка встройки на собеседованиях. Классный человек, но через полгода станет скучно - сразу делаем сценарий.
* Проект завершился - перераспределяем людей. Карта персонала.
* Сборка новой команды - тоже карта персонала. Людей надо как-то вытащить, в карте - есть замены и риски.
Основа работы Performance review: есть цикличность и сроки. Раз в полгода - зависит от динамики команды.
* ИПР стыкованы с performance review.
* Обратная связь после performance. И обязательно слушаем его ответ.
* Регулярные 1:1 - по ИПР.
* Планирование. годовое: зарплаты, должности, соотносим с рынком. И дальше по мере изменений - актуализируем.
* И не забываем все записывать. Это не только вам, но и тому, кто придет на смену. Преемственность в руководстве.
Что это дает? Для сотрудника: понятные правила, ИПР, нестандартная траектория - не замкнут в команде. Для тимлида - картинка сверху, проблемные места и планы по ним.
Набор инструментов - для 50+ Для 5-10 можно использовать отдельные инструменты. Важно - работа с рисками, сценарии "а что если". Могут помочь: руководитель и HR (они неплохо сценируют). И обязательно все записывать!
👍1
#Teamlead Альберт Степанцев из Спринт-Ф. Законы Мерфи в повседневной работе руководителя. Это был рассказ о разнообразных рисках и способах работы с ними. В нем была очень интересная техника: три дня выхода на работу, чтобы проверить что сотрудник сработается с командой. Оплачиваемых, по договору.
Рассказ сопровождала большая куча историй и законов, начиная с закона Мерфи: все, что можно сделать не так - сделают, который родился, когда на эксперименте команда техников прикрутила половину датчиков неверно. Расширенный вариант таков:
все, о чем можно подумать - вероятно, все вероятное - неизбежно, а когда есть варианты - случится худшее. Но Альберт - не пессимист, а реалист: если у нас половина стакана воды - надо дырку искать. То есть готовимся к рискам.
Альберт - CTO напрокат, партнер по выстраиванию ИТ и его опыт работы включает много компаний. Доклад структурирован на три части: Люди, инструменты и система.
Люди. Мы нанимаем, работаем, увольняем.
Риски найма: найм неподходящего, завышенные ожидания; риск несовместимости; риск долгого (дорогого) найма.
Как парировать риски найма.
* Нанимаем первого подходящего, время - дорого
* Сократите плечо найма - сколько собеседований. Чем выше этапов - тем выше вероятность ошибки. У него 15 минут HR на общую адекватность. А потом - сразу на себя, и вместо идеального собеседования, где тесты, lifecoding и прочее - показывает экран с реальными задачами готов или нет. Затем - код проекта - совместно почитать. И тоже достаточно 15 минут.
* Если кажется - значит не кажется: если на каком-то этапе беседы показалось, что что-то не так - оно не так. Не игнорируйте подсказки подсознания.
После найма - онбординг, есть семь ступенек.
* Придти на работу
* Начать что-то делать - не все доходят до этого
* Делать хорошо, не вредить
* Хорошо и быстро - в темпе команды
* Хорошо, быстро и то, что нужно. А не сделать CRM чтобы MongoDB изучить.
* Хорошо и быстро то что нужно, и не только в своих интересах. Бывают эксцессы.
Как парировать риски лестницы?
* Главное - создать условия, потом требовать результата. Офис, рабочее место
* Дублировать и резервировать. Можно с аутстаффом договориться.
* Прозрачность - не пустое слово.
На найме - показать экран с правилами, разными: как ветки делать, что ответ должен быть дан, если задан вопрос.
Второй закон Чизхолма: если дела идут хорошо - что-то случится в ближайщем будущем.
Закон Падлера: Все, что хорошо начинается - кончается плохо, а что начинается плохо - кончается еще хуже.
Рано или поздно все увольняются. Крепостное право отменено. Риски: неожиданное увольнение, отказ увольняться, негатив и так далее.
Увольнение начинается с найма - проактивная позиция
* вы должны быть готовы
* озвучьте при найме правила увольнения, с вариантами (одним днем, две недели и так далее)
* ведите сценарии на возможные риски увольнений
* если сценария нет - вы полдня думаете, а ситуация может измениться, негатив.
Техника три дня: приходи на три дня, возьми больничный в прежнем месте, а мы договор подпишем
1. Доступ получил, проект поднял
2. Учебная задача
3. Реальная задача, но короткая
Позволяет 90% рисков найма и увольнения снимает. И можно в любой момент разорвать.
2. Инструменты. Техника, офис, софт для работы. Людям надо дать инструменты. Инструменты выбирают люди - а люди ошибаются.
Проблемы с инструментами.
* Инструмент выглядит хорошо, но не решает задачи. gitlab вместо CI/CD или NetBeans вместо IDE
* Решает задачи, но никто его не знает. Как ExtJS
* Решает задачи, но крадет время. Кто-то вручную проталкивает задачи по gitflow вместо скриптов
* Известен но никому не нужен
* Неудобен до неприятия. Как Кибана для тестировщиков
Инструменты - экономят время. А время - деньги. Работа, которая делается зря - muda из Канбан. Инструменты должны время сокращать, а не красть.
Про инструменты.
* Запрещайте физически (merge в мастер)
* Автоматизация, которая экономит время
* Известное - лучше неизвестного
* Нужное - лучше известного
3. Работайте с надежностью системы. Люди - связи - процессы - изменение процессов во времени.
Рассказ сопровождала большая куча историй и законов, начиная с закона Мерфи: все, что можно сделать не так - сделают, который родился, когда на эксперименте команда техников прикрутила половину датчиков неверно. Расширенный вариант таков:
все, о чем можно подумать - вероятно, все вероятное - неизбежно, а когда есть варианты - случится худшее. Но Альберт - не пессимист, а реалист: если у нас половина стакана воды - надо дырку искать. То есть готовимся к рискам.
Альберт - CTO напрокат, партнер по выстраиванию ИТ и его опыт работы включает много компаний. Доклад структурирован на три части: Люди, инструменты и система.
Люди. Мы нанимаем, работаем, увольняем.
Риски найма: найм неподходящего, завышенные ожидания; риск несовместимости; риск долгого (дорогого) найма.
Как парировать риски найма.
* Нанимаем первого подходящего, время - дорого
* Сократите плечо найма - сколько собеседований. Чем выше этапов - тем выше вероятность ошибки. У него 15 минут HR на общую адекватность. А потом - сразу на себя, и вместо идеального собеседования, где тесты, lifecoding и прочее - показывает экран с реальными задачами готов или нет. Затем - код проекта - совместно почитать. И тоже достаточно 15 минут.
* Если кажется - значит не кажется: если на каком-то этапе беседы показалось, что что-то не так - оно не так. Не игнорируйте подсказки подсознания.
После найма - онбординг, есть семь ступенек.
* Придти на работу
* Начать что-то делать - не все доходят до этого
* Делать хорошо, не вредить
* Хорошо и быстро - в темпе команды
* Хорошо, быстро и то, что нужно. А не сделать CRM чтобы MongoDB изучить.
* Хорошо и быстро то что нужно, и не только в своих интересах. Бывают эксцессы.
Как парировать риски лестницы?
* Главное - создать условия, потом требовать результата. Офис, рабочее место
* Дублировать и резервировать. Можно с аутстаффом договориться.
* Прозрачность - не пустое слово.
На найме - показать экран с правилами, разными: как ветки делать, что ответ должен быть дан, если задан вопрос.
Второй закон Чизхолма: если дела идут хорошо - что-то случится в ближайщем будущем.
Закон Падлера: Все, что хорошо начинается - кончается плохо, а что начинается плохо - кончается еще хуже.
Рано или поздно все увольняются. Крепостное право отменено. Риски: неожиданное увольнение, отказ увольняться, негатив и так далее.
Увольнение начинается с найма - проактивная позиция
* вы должны быть готовы
* озвучьте при найме правила увольнения, с вариантами (одним днем, две недели и так далее)
* ведите сценарии на возможные риски увольнений
* если сценария нет - вы полдня думаете, а ситуация может измениться, негатив.
Техника три дня: приходи на три дня, возьми больничный в прежнем месте, а мы договор подпишем
1. Доступ получил, проект поднял
2. Учебная задача
3. Реальная задача, но короткая
Позволяет 90% рисков найма и увольнения снимает. И можно в любой момент разорвать.
2. Инструменты. Техника, офис, софт для работы. Людям надо дать инструменты. Инструменты выбирают люди - а люди ошибаются.
Проблемы с инструментами.
* Инструмент выглядит хорошо, но не решает задачи. gitlab вместо CI/CD или NetBeans вместо IDE
* Решает задачи, но никто его не знает. Как ExtJS
* Решает задачи, но крадет время. Кто-то вручную проталкивает задачи по gitflow вместо скриптов
* Известен но никому не нужен
* Неудобен до неприятия. Как Кибана для тестировщиков
Инструменты - экономят время. А время - деньги. Работа, которая делается зря - muda из Канбан. Инструменты должны время сокращать, а не красть.
Про инструменты.
* Запрещайте физически (merge в мастер)
* Автоматизация, которая экономит время
* Известное - лучше неизвестного
* Нужное - лучше известного
3. Работайте с надежностью системы. Люди - связи - процессы - изменение процессов во времени.
🔥3
Проблема - степенная функция ненадежности. Надежность - что элемент работает. Например, что сотрудник приходит на работу. Если n элементов, то общая надежность - степенная функция от надежности.
Ракета М1 - 30 двигателей с надежностью 95% на первой ступени. Для неотработанной техники - прекрасно. Но общая надежность - 21%, только один из 5 - успешен. Запускали 4 раза и она 4 раза взорвалась.
10 человек, каждый из 20 рабочих дней приходит 19. Какова вероятность, что будет день, когда придут все - не высокая.
Связи. Ненадежность передачи информации, испорченный телефон.
Надо сокращать число элементов системы. Инструмент - выделение инкапсулированных элементов.
* Один специалист по React - он подчиняется тимлиду
* Их двое - одного ведущим, но кого? Он вводит дежурства, кто за старшего. Старший работает по ответственным задачам.
* Когда трое - он знает, кого назначить старшим. Когда четвера - заместитель, бас-фактор. Мини-группы по 3-6 человек. И они кристаллизуются естественно. А дальше делим пополам.
Почему 5? Потому что в зоне произвольного внимания 7 элементов: ты, руководитель и 5 подчиненных.
Из ответов на вопросы.
* Проверка совместимости - еще до техскилов. Если он не на одной волне - не поработаешь. Способ - разговор, вживую, голосом, можно онлайн. Последний фильмы, книга, были ли американцы на Луне.
* Тимлиды и техлиды - там 3 дня не работает, испытательный срок. И там нужна обратная связь от команды, вплоть до ежедневной.
* Многоступенчатые системы найма - ломать. Даже в крупной компании. Это дисфункция. У него был опыт. Пришел в компанию - Кадровое агентство, Свои, Тхлид, Руководитель. Сказал "давайте рискнем, выводите на меня" - получилось.
* Техника три дня - это для тех, кого готовы взять. И это НЕ дороже, проверка совместимости эффективна, а затраты на РК и другие проверки - сложнее. 3 дня дешевле 20% дохода, который хочет кадровое агентство.
* Про увольнение - показываешь в 20 пунктах, среди которых как уйти в отпуск, получить больничный, уволится. Это нормально.
* Вопрос. ПСБ, служба безопасности - нельзя показывать код и применять 3 дня. Что делать? Ответ. Случаи есть, работает с банками.
Право зеркального NDA - может распространить на кандидата. И он на три дня подписывает договор. Код - несекретный, он в любом проекте есть. Еще внутренние проекты - там часто те же технологии.
Ракета М1 - 30 двигателей с надежностью 95% на первой ступени. Для неотработанной техники - прекрасно. Но общая надежность - 21%, только один из 5 - успешен. Запускали 4 раза и она 4 раза взорвалась.
10 человек, каждый из 20 рабочих дней приходит 19. Какова вероятность, что будет день, когда придут все - не высокая.
Связи. Ненадежность передачи информации, испорченный телефон.
Надо сокращать число элементов системы. Инструмент - выделение инкапсулированных элементов.
* Один специалист по React - он подчиняется тимлиду
* Их двое - одного ведущим, но кого? Он вводит дежурства, кто за старшего. Старший работает по ответственным задачам.
* Когда трое - он знает, кого назначить старшим. Когда четвера - заместитель, бас-фактор. Мини-группы по 3-6 человек. И они кристаллизуются естественно. А дальше делим пополам.
Почему 5? Потому что в зоне произвольного внимания 7 элементов: ты, руководитель и 5 подчиненных.
Из ответов на вопросы.
* Проверка совместимости - еще до техскилов. Если он не на одной волне - не поработаешь. Способ - разговор, вживую, голосом, можно онлайн. Последний фильмы, книга, были ли американцы на Луне.
* Тимлиды и техлиды - там 3 дня не работает, испытательный срок. И там нужна обратная связь от команды, вплоть до ежедневной.
* Многоступенчатые системы найма - ломать. Даже в крупной компании. Это дисфункция. У него был опыт. Пришел в компанию - Кадровое агентство, Свои, Тхлид, Руководитель. Сказал "давайте рискнем, выводите на меня" - получилось.
* Техника три дня - это для тех, кого готовы взять. И это НЕ дороже, проверка совместимости эффективна, а затраты на РК и другие проверки - сложнее. 3 дня дешевле 20% дохода, который хочет кадровое агентство.
* Про увольнение - показываешь в 20 пунктах, среди которых как уйти в отпуск, получить больничный, уволится. Это нормально.
* Вопрос. ПСБ, служба безопасности - нельзя показывать код и применять 3 дня. Что делать? Ответ. Случаи есть, работает с банками.
Право зеркального NDA - может распространить на кандидата. И он на три дня подписывает договор. Код - несекретный, он в любом проекте есть. Еще внутренние проекты - там часто те же технологии.
🔥5👍1
#Teamlead Александра Брызгалова (bryzgalova.ru) Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас). Основной тезис доклада: если ваше замечательное решение отвергается, то причина обычно не в том, что люди глупы или ленивы, или преследуют какие-то личные цели. Обычно есть какие-то аспекты, которые в своем решении вы не учли: оно не решает проблемы, или решает не актуальную проблему, или создает дополнительный урон или риски, которые вы не видите. И надо расширить рамку рассуждения, понять логику тех, кого вы считаете противниками, найти общую цель - и тогда ситуация изменится. Инструмент, которым иллюстрированы кейсы - грозовая туча из TOC (Theory of Constraints) Голдратта. Но это - лишь один элемент теории. и, по сути, он дал понятную схематизацию, визуальный ряд.
Я хочу отметить, что доклад по сути борется с основной ошибкой атрибуции, в просторечии "все уроды, а я д'Артаньян". Корень этой ошибки в том, что модель самого себя и модели других людей в мозгу разделены и слабо связаны.
А теперь - кейсы из доклада. Они - про ситуации, когда конфликт - это не отвлеченный спор, а когда в результате спора вам нужно что-то вместе сделать. И тут метафора деления пирога: все, что досталось ему - отнято от меня. Но часто есть возможность не делить маленький пирог, а найти пирог побольше. Всегда есть win-win. Выгодно в это верить. Потому что если верим - пойдем договариваться. А если не верим - то вообще не пойдем. А могут быть варианты.
1. Самый умный разработчик. Который, как казалось руководству не тщательно тестирует код, выкатывает с багами, пользователи жалуются. Итого, мы хотим, чтобы тестировал, а он - нет. А не хочет он потому что хочет быть самым умным. Но решили разобраться. И, оказывается, ему когда-то сказали, что самое важное - скорость выкатки фичи. Я проверяю основное, пользователи быстро ищут ошибки, мы исправляем. Скорость - важная. Но жалобы - тоже. И выяснили, что жалуются одни и те же - и из них сделали команду ранних последователей - и они перестали жаловаться, их замечаниям был другой статус.
2. Я хочу. чтобы начинали большие тикеты с важными задачами, а они - берут малые. Кричать надо. А он - ленивый. Пошли разбираться. Оказалось, что большие проекты плохо описаны, клиент не понимает что хотел, тянет. Если тянем время - все сговорчивые, и все проще, и меньше лишней работы. Общая цель - есть, меньше работы. Решения: пересмотреть способ описания, менять описания.
3. Жадный собственник. Было двое, один вышел. Виктор Петрович, надо больше денег нанять больше людей. А он - не дает, потому что жадный и не думает про завтра. Конфликт: мы хотим бюджет. а он не дает потому что жадный. А дело было не в жадности. Если вдруг у компании есть деньги - мы можем в теории нанять людей. Но, скорее всего, есть проблемы со старым. Норма прибыли - малая, и нет впечатление, что оно возрастет. Больше фич - не значит больше денег. И надо с этим разбираться - что ждут, и почему не работает.
4. Глупый начальник. Надо автоматизировать тестирование, а начальник не дает. Я хочу - потому что хочу повысить качество. А он - просто не хочет напрягаться. А реально: компания получала деньги за время, которая потратила. Автоматизация - уменьшение выручки. А затраты - меньше. Повышение качества тестирование - не факт, что повысит выручку. И надо менять модель.
С внедрением идей. Чаще всего не заходит не потому, что там - дураки, а потому что такое внедрение ставит под угрозу какую-то другую потребность системы. И с этим надо разобраться: нужно ли это изменение для системы и не не ухудшит ли оно что-либо.
Внедрение наполовину - какой-то компромисс, мы улучшили на половину, а риск не убрали. А еще хуже - заметание под ковер, просто редко здороваемся и забываем.
Мысль: люди - хорошие. Голдратт настолько верил, что написал это на надгробном камне. Хотя жил в Израиле в реальной ситуации. Это не романтизм, это прагматизм. У людей нет цели сделать плохо. Брак получается, его не делают сознательно.
Я хочу отметить, что доклад по сути борется с основной ошибкой атрибуции, в просторечии "все уроды, а я д'Артаньян". Корень этой ошибки в том, что модель самого себя и модели других людей в мозгу разделены и слабо связаны.
А теперь - кейсы из доклада. Они - про ситуации, когда конфликт - это не отвлеченный спор, а когда в результате спора вам нужно что-то вместе сделать. И тут метафора деления пирога: все, что досталось ему - отнято от меня. Но часто есть возможность не делить маленький пирог, а найти пирог побольше. Всегда есть win-win. Выгодно в это верить. Потому что если верим - пойдем договариваться. А если не верим - то вообще не пойдем. А могут быть варианты.
1. Самый умный разработчик. Который, как казалось руководству не тщательно тестирует код, выкатывает с багами, пользователи жалуются. Итого, мы хотим, чтобы тестировал, а он - нет. А не хочет он потому что хочет быть самым умным. Но решили разобраться. И, оказывается, ему когда-то сказали, что самое важное - скорость выкатки фичи. Я проверяю основное, пользователи быстро ищут ошибки, мы исправляем. Скорость - важная. Но жалобы - тоже. И выяснили, что жалуются одни и те же - и из них сделали команду ранних последователей - и они перестали жаловаться, их замечаниям был другой статус.
2. Я хочу. чтобы начинали большие тикеты с важными задачами, а они - берут малые. Кричать надо. А он - ленивый. Пошли разбираться. Оказалось, что большие проекты плохо описаны, клиент не понимает что хотел, тянет. Если тянем время - все сговорчивые, и все проще, и меньше лишней работы. Общая цель - есть, меньше работы. Решения: пересмотреть способ описания, менять описания.
3. Жадный собственник. Было двое, один вышел. Виктор Петрович, надо больше денег нанять больше людей. А он - не дает, потому что жадный и не думает про завтра. Конфликт: мы хотим бюджет. а он не дает потому что жадный. А дело было не в жадности. Если вдруг у компании есть деньги - мы можем в теории нанять людей. Но, скорее всего, есть проблемы со старым. Норма прибыли - малая, и нет впечатление, что оно возрастет. Больше фич - не значит больше денег. И надо с этим разбираться - что ждут, и почему не работает.
4. Глупый начальник. Надо автоматизировать тестирование, а начальник не дает. Я хочу - потому что хочу повысить качество. А он - просто не хочет напрягаться. А реально: компания получала деньги за время, которая потратила. Автоматизация - уменьшение выручки. А затраты - меньше. Повышение качества тестирование - не факт, что повысит выручку. И надо менять модель.
С внедрением идей. Чаще всего не заходит не потому, что там - дураки, а потому что такое внедрение ставит под угрозу какую-то другую потребность системы. И с этим надо разобраться: нужно ли это изменение для системы и не не ухудшит ли оно что-либо.
Внедрение наполовину - какой-то компромисс, мы улучшили на половину, а риск не убрали. А еще хуже - заметание под ковер, просто редко здороваемся и забываем.
Мысль: люди - хорошие. Голдратт настолько верил, что написал это на надгробном камне. Хотя жил в Израиле в реальной ситуации. Это не романтизм, это прагматизм. У людей нет цели сделать плохо. Брак получается, его не делают сознательно.
🔥3
Реальные причины: (а) не договорились про критерии качества; (б) я не могу не делать брак - технология, компетентность, он случается; (в) я специально делаю браком - бывает, но очень редко. Штрафы - не эффективно, в последнем случае надо увольнять, а в двух первых - исправлять систему. Обвинить кого-то не значит найти решение.
Но увольнять можно. Даже хороших людей - они могут не соответствовать тому, что нужно.
Но увольнять можно. Даже хороших людей - они могут не соответствовать тому, что нужно.
👍4💯1
Слайды моего доклада про системное мышление опубликованы на моем сайте https://mtsepkov.org/SysThinkTeamlead Там же ссылки на предыдущие доклады по теме, для которых есть записи.
🔥2👍1
#Teamlead Алена Рыжкова из ИТ-холдинг Т1. Как эффективно скоординировать работу 10 разношерстных команд для успешного закрытия проекта на примере реальных кейсов. Мой личный фреймворк организации проектной работы. Это доклад о конкретном фреймворке, который сложился у Алены для управления проектами, выполняемые сборными командами сотрудников, работающих по совмещению. На мой взгляд, получился хороший легкий фреймворк, которым можно пользоваться. Тем более, что Алена хорошо расскрыла внутреннюю логику. А если представлять его место в других методологиях, то можно и обогощать другими элементами при необходимости - ведь фреймворк должен соответствовать тем проектам, а проекты у всех разные. Об этом я напишу в конце.
Типовая задача у Алены: вывести зи эксплуатации сервис X и заменить на другой сервис Y. Обычно высоконагруженный. Под задачу создается команда из разных специалистов, но ее участники работают не только над этим проектом, а основное подчинение - другое.
В фреймворке три основных элемента: инфополе, процессы и ценности, в каждом - свои составляющие.
1) Инфополе. У разных участников - разный контекст и понимание проекта. Был проект, где выводили вендорскую, и внедряли свою. Рядом с вендорской был доп.модуль, костылями и интеграцией. И они обрадовались, что он будет в новой системе. А оказалось, что команда разработки воспроизводила систему вендора как есть, без расширения. Обнаружили не сразу, договаривались долго.
Из чего состоит инфополе?
1а) 1-страничное описание. Цель, задачи - скоуп, заказчик, карта с вехами, зависимости и риски. Важно: задачи должны быть поняты всей командой. Для этого надо рассказать подробнее. Карта бизнес-процесса с системами и потоками. Формулировка - кратко, просто и понятно. И если спец.термины - нужно толкование, в команде разные участники. В сложных способах - еще и проверять понимание.
Заказчика надо знать в лицо и это тот, кому будем сдавать проект. Форма карты - зависит от проекта - масштаб, насколько проект знакомый, она показывала свой.
1б) Зоны ответственности. Тут могут быть всякие взгляды. Можно начать и пусть само сложится - но проявятся серые зоны, когда никто не ведет. Разработка и девопсы спорили, кто заполнит инвентори параметры, там 20 минут но каждый раз - а спорили 2 дня.
DevOps и сопровождение подключается сразу! А то они могут не принять готовую систему.
По зонам надо предложить свое, собрать предложения, зафиксировать договоренности.
1в) Дорожная карта. Основной вектор развития, связи. Гант: дорожки с вехами. Важно не забыть работы по заказу оборудования и инфраструктурные работы - может быть долго. Не забыть не функциональные блоки - безопасность, надежность.
Получается общее информационное поле. Но просто сказать после этого "поехали" - не достаточно, надо реально стартовать работы. А то приходишь - а оказывается, что все заняты другими делами. Почему? Потому что делают те проекты, по которыем создается информационное давление - на статусах, от менеджеров и так далее.
2) Процессы, которые позволят синхронизироваться, выявлять проблемы и решать. Точка коммуникации.
2а) Основное - статус проекта. 30 минут 2-4 раза в неделю. Прогресс движения к ближайшей контрольной точки.
И открытый микрофон после основной повестки. И надо явно драйвить: какие вопросы, замечания, проблемы.
2б) Рабочие группы по выявленным проблемам. На статусе это не эффективно. Сбор вариантов, проработка и итог. 30-60 минут 2-3 раза в день. Но недолго. Пример. Вендор задержал поставку, которая влияла на старт пилота. И нужен был план-Б, чтобы запустить функционал пилота.
2в) Чат в мессенджере. 20-30 сообщений в дел. Модерация, во-время предложить обсудить на встрече и написать результат.
Статус, рабочие группы и чаты нужны в любых проектах, даже маленьких. Причины факапов чаще не технические, а организационные. Серые зоны ответственности и прочее.
Типовая задача у Алены: вывести зи эксплуатации сервис X и заменить на другой сервис Y. Обычно высоконагруженный. Под задачу создается команда из разных специалистов, но ее участники работают не только над этим проектом, а основное подчинение - другое.
В фреймворке три основных элемента: инфополе, процессы и ценности, в каждом - свои составляющие.
1) Инфополе. У разных участников - разный контекст и понимание проекта. Был проект, где выводили вендорскую, и внедряли свою. Рядом с вендорской был доп.модуль, костылями и интеграцией. И они обрадовались, что он будет в новой системе. А оказалось, что команда разработки воспроизводила систему вендора как есть, без расширения. Обнаружили не сразу, договаривались долго.
Из чего состоит инфополе?
1а) 1-страничное описание. Цель, задачи - скоуп, заказчик, карта с вехами, зависимости и риски. Важно: задачи должны быть поняты всей командой. Для этого надо рассказать подробнее. Карта бизнес-процесса с системами и потоками. Формулировка - кратко, просто и понятно. И если спец.термины - нужно толкование, в команде разные участники. В сложных способах - еще и проверять понимание.
Заказчика надо знать в лицо и это тот, кому будем сдавать проект. Форма карты - зависит от проекта - масштаб, насколько проект знакомый, она показывала свой.
1б) Зоны ответственности. Тут могут быть всякие взгляды. Можно начать и пусть само сложится - но проявятся серые зоны, когда никто не ведет. Разработка и девопсы спорили, кто заполнит инвентори параметры, там 20 минут но каждый раз - а спорили 2 дня.
DevOps и сопровождение подключается сразу! А то они могут не принять готовую систему.
По зонам надо предложить свое, собрать предложения, зафиксировать договоренности.
1в) Дорожная карта. Основной вектор развития, связи. Гант: дорожки с вехами. Важно не забыть работы по заказу оборудования и инфраструктурные работы - может быть долго. Не забыть не функциональные блоки - безопасность, надежность.
Получается общее информационное поле. Но просто сказать после этого "поехали" - не достаточно, надо реально стартовать работы. А то приходишь - а оказывается, что все заняты другими делами. Почему? Потому что делают те проекты, по которыем создается информационное давление - на статусах, от менеджеров и так далее.
2) Процессы, которые позволят синхронизироваться, выявлять проблемы и решать. Точка коммуникации.
2а) Основное - статус проекта. 30 минут 2-4 раза в неделю. Прогресс движения к ближайшей контрольной точки.
И открытый микрофон после основной повестки. И надо явно драйвить: какие вопросы, замечания, проблемы.
2б) Рабочие группы по выявленным проблемам. На статусе это не эффективно. Сбор вариантов, проработка и итог. 30-60 минут 2-3 раза в день. Но недолго. Пример. Вендор задержал поставку, которая влияла на старт пилота. И нужен был план-Б, чтобы запустить функционал пилота.
2в) Чат в мессенджере. 20-30 сообщений в дел. Модерация, во-время предложить обсудить на встрече и написать результат.
Статус, рабочие группы и чаты нужны в любых проектах, даже маленьких. Причины факапов чаще не технические, а организационные. Серые зоны ответственности и прочее.
👍2🔥1
3. Ценности и принципы. Нужна мотивация и понимание, в чем смысл - это отдельные блоки. Они зависят от проекта. Но еще есть принципы - верхнеуровневые праивла, которыми мы руководствуемся. Они определяют как поступать правилами, что держать в фокусе внимания. И не просто записать, а реально применять. Для этого надо приземлять принципы через паттерны и антипаттерны.
Ее принципы: Открытость, Поддержка и Лидерство. И были слайды, где для каждого были паттерны и антипаттерны.
Открытость - предоставление всей информации всей команде проекта. Нет отдельного чата разработки, приглашение на статусы всех заинтересованных. Она первой пригасила на статусы ИБ, сначала напряглись - потом пошло сотрудничество.
Открытость с руководством. Если пошли задержки - надо сразу говорить. Во-первых, они компетентны и заинтересованы и помогут. Во-вторых открытость рождает доверие, а оно критично при факапах.
Поддержка. Атмосфера, к которой не чувствует брошенным с проблеми, не боится быть осмеянным или обруганным. Это не значит, что он решит за команду - но он поддержит, поможет и направит.
Лидерство. Это не про то, как кто-то на белом коне ведет проект к успеху, это за ответственное отношение к результату, его должна показывать вся команда. Надо выдвигать аргументы и защищать. Не все умеют и считают уместным, но надо этому учить.
В целом получился легкий фреймворк. На мой взгляд, очень напоминающий то адаптивное управление проектами, которое продвигает Павел Алферов из своего опыта, сократив классику до необходимого минимума. Кстати, как источники, где можно посмотреть, Алена указывала PMBOK - там есть все, можно брать элементы. И фреймворк p3.express/ru. А я бы дополнил этот список практиками Kanban и социократии. Вопреки распространенному мифу, Канбан - это не упрощенный скрам для потока задач, это способ работы и совершенствования методов организации работы. И там много различных практик, а также технология определения узких мест в ходе проекта. А социократия - еще один подход, который можно использовать как источник для полезных практик. И организация рабочих групп для решения вопросов, которую Алена описала - одна из них. Ее, кстати, можно применять для решения проблем, которые выявили ретро, только там время работы больше, был интересный доклад Ростелекома об этом.
Ее принципы: Открытость, Поддержка и Лидерство. И были слайды, где для каждого были паттерны и антипаттерны.
Открытость - предоставление всей информации всей команде проекта. Нет отдельного чата разработки, приглашение на статусы всех заинтересованных. Она первой пригасила на статусы ИБ, сначала напряглись - потом пошло сотрудничество.
Открытость с руководством. Если пошли задержки - надо сразу говорить. Во-первых, они компетентны и заинтересованы и помогут. Во-вторых открытость рождает доверие, а оно критично при факапах.
Поддержка. Атмосфера, к которой не чувствует брошенным с проблеми, не боится быть осмеянным или обруганным. Это не значит, что он решит за команду - но он поддержит, поможет и направит.
Лидерство. Это не про то, как кто-то на белом коне ведет проект к успеху, это за ответственное отношение к результату, его должна показывать вся команда. Надо выдвигать аргументы и защищать. Не все умеют и считают уместным, но надо этому учить.
В целом получился легкий фреймворк. На мой взгляд, очень напоминающий то адаптивное управление проектами, которое продвигает Павел Алферов из своего опыта, сократив классику до необходимого минимума. Кстати, как источники, где можно посмотреть, Алена указывала PMBOK - там есть все, можно брать элементы. И фреймворк p3.express/ru. А я бы дополнил этот список практиками Kanban и социократии. Вопреки распространенному мифу, Канбан - это не упрощенный скрам для потока задач, это способ работы и совершенствования методов организации работы. И там много различных практик, а также технология определения узких мест в ходе проекта. А социократия - еще один подход, который можно использовать как источник для полезных практик. И организация рабочих групп для решения вопросов, которую Алена описала - одна из них. Ее, кстати, можно применять для решения проблем, которые выявили ретро, только там время работы больше, был интересный доклад Ростелекома об этом.
p3.express
Минималистичная система управления проектами
❤2
По горячим следам сделал отчет с #Teamlead https://mtsepkov.org/TeamLead-2024-Msk, пока Highload не стер контекст докладов. Часть заметок я выкладывал в ходе конференции, но доклады Александра Зизы и Анны Обуховой требуют осмысления, их выложить сразу не получилось. Всего в отчете 12 докладов. А еще общее наблюдение, в основном по TechTalks: крупные компании переходят от функциональных подразделений к кроссфункциональным командам, называя это продуктовым подходом, чтобы быть в тренде. Это прогресс, а вот зачем они строили функциональную организацию по учебникам 30-летней давности - неясно. Хотя психологически это понятно.
Вот список докладов в моем отчете.
* Максим Цепков. Системное мышление — нужно ли оно в IТ и зачем?
* Мария Щекочихина. Делаем происходящее с персоналом предсказуемым
* Альберт Степанцев. Законы Мерфи в повседневной работе руководителя
* Александра Брызгалова. Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас)
* Александр Зиза. 4 стратегии развития управленческого мастерства
* Анна Обухова. Как сделать так, чтобы команда наконец признала тебя лидом
* Рита Канис. Как убить всех зайцев: про управление знаниями исподтишка
* Алена Рыжкова. Как эффективно скоординировать работу 10 разношерстных команд.
* Алексей Макаров. Команда разработки за свой счет
* Евгений Идзиковский. Legacy-код в психике — как расплатиться со своим техдолгом
* Екатерина Шашкова. Как мы перестали говорить «у нас так принято» и стали описывать процесс разработки
* Руслан Карманов. Китайские методологии IT-управления
Вот список докладов в моем отчете.
* Максим Цепков. Системное мышление — нужно ли оно в IТ и зачем?
* Мария Щекочихина. Делаем происходящее с персоналом предсказуемым
* Альберт Степанцев. Законы Мерфи в повседневной работе руководителя
* Александра Брызгалова. Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас)
* Александр Зиза. 4 стратегии развития управленческого мастерства
* Анна Обухова. Как сделать так, чтобы команда наконец признала тебя лидом
* Рита Канис. Как убить всех зайцев: про управление знаниями исподтишка
* Алена Рыжкова. Как эффективно скоординировать работу 10 разношерстных команд.
* Алексей Макаров. Команда разработки за свой счет
* Евгений Идзиковский. Legacy-код в психике — как расплатиться со своим техдолгом
* Екатерина Шашкова. Как мы перестали говорить «у нас так принято» и стали описывать процесс разработки
* Руслан Карманов. Китайские методологии IT-управления
🔥9
Вслед за #Teamlead прошел #Highload. 3500 offline участников, 15+ треков интересных выступлений и много общения, так что публиковать заметки в ходе конференции не получалось. Собрал и публикую отчет https://mtsepkov.org/Highload-2024. Отмечу, что презентации всех докладов уже доступны на сайте конференции, надо зайти в конкретный доклад, так что подробности можно смотреть.
Самым интересным для меня докладом было выступление Наиль Миннахметов из МТС про архитектуру: это очень редкий случай, когда большая компания отдает решения по архитектуре на уровень команд, выстраивая федеративную конструкцию. А в целом в отчет попали следующие доклады.
* Наиль Миннахметов из МТС. Артефакты архитектуры. Какие, зачем и как их организовать
* Владимир Кочетков. Программировать как хакер, защищать — как программист
* Алексей Мерсон (Т-Банк). Надежность на масштабе в 45 млн клиентов — инструменты и практики цифрового банка
* Алексей Николаевский. Транзакционная работа с топиками. Архитектура и сравнение решений в Apache Kafka и YDB
* Григорий Петров. Красота кода глазами нейрофизиолога-программиста
* Эмир Вильданов. Движок распределенного SQL в СУБД Picodata: принцип его работы, принятые архитектурные решения и сравнение с аналогами
* Евгений Харченко из Райффайзен Банк. Инженерная культура на масштабе: как развивать и оценивать практики
* Виталий Исаев. Как объединять данные из разных СУБД и делать это эффективно
* Павел Велихов. Стоимостный оптимизатор в YDB — как, зачем и почему?
* Ольга Лукьянова. Моментальная навигация по коду для любого коммита. А так можно было?
* Екатерина Лысенко. Финтех: причины моей ненависти
* Виталий Левченко. Грейды Go-разработчика, или Что отличает сеньора-гофера от остальных
* Алексей Обыскалов. Как работать с легаси, чтобы ни вы, ни проект не сгорели
* Максим Мирошниченко. Оптимизация конкурентных приложений: паттерны, сравнение и микроархитектура
Самым интересным для меня докладом было выступление Наиль Миннахметов из МТС про архитектуру: это очень редкий случай, когда большая компания отдает решения по архитектуре на уровень команд, выстраивая федеративную конструкцию. А в целом в отчет попали следующие доклады.
* Наиль Миннахметов из МТС. Артефакты архитектуры. Какие, зачем и как их организовать
* Владимир Кочетков. Программировать как хакер, защищать — как программист
* Алексей Мерсон (Т-Банк). Надежность на масштабе в 45 млн клиентов — инструменты и практики цифрового банка
* Алексей Николаевский. Транзакционная работа с топиками. Архитектура и сравнение решений в Apache Kafka и YDB
* Григорий Петров. Красота кода глазами нейрофизиолога-программиста
* Эмир Вильданов. Движок распределенного SQL в СУБД Picodata: принцип его работы, принятые архитектурные решения и сравнение с аналогами
* Евгений Харченко из Райффайзен Банк. Инженерная культура на масштабе: как развивать и оценивать практики
* Виталий Исаев. Как объединять данные из разных СУБД и делать это эффективно
* Павел Велихов. Стоимостный оптимизатор в YDB — как, зачем и почему?
* Ольга Лукьянова. Моментальная навигация по коду для любого коммита. А так можно было?
* Екатерина Лысенко. Финтех: причины моей ненависти
* Виталий Левченко. Грейды Go-разработчика, или Что отличает сеньора-гофера от остальных
* Алексей Обыскалов. Как работать с легаси, чтобы ни вы, ни проект не сгорели
* Максим Мирошниченко. Оптимизация конкурентных приложений: паттерны, сравнение и микроархитектура
👍8❤1