Этот день и это время настало!

Начинаем наш воркшоп, все кто записывался, ожидаем вас)

Вот почему нельзя из Задачи делать несколько потоков без шлюза😁

В экземпляр процесса пустила только 1 токен, а дальше … все вышло из под контроля😂😂😂

Провела воркшоп по MSPC — и пропала…

На самом деле, очень много всего, с чем надо было разобраться. Однако, в прошлый раз все прошло как нельзя круто! Позже опубликую отзывы участников😉

На прошлой встрече мы разбирали:
— как анализировать процессы и находить реальные причины проблем
— почему “долго”, “неудобно” - это не проблемы

Формат был максимально практический:
работали с кейсами, обсуждали подходы, разбирали логику анализа

По итогам стало видно главное —
когда начинаешь работать не с симптомами, а с причинами, по-другому начинаешь смотреть на задачи и процессы.

После воркшопа получила несколько запросов повторить встречу, поэтому запускаю второй поток 👇

📅 14 апреля 2026
🕖 вечер 19:00 мск
📍 онлайн

Формат:
— практический разбор кейсов
— работа с процессами
— обсуждение и ответы на вопросы

Участие платное. Как и в прошлый раз 2100 руб.

Тем, кто с нами - запишитесь через бота в MAX (адаптируемся как можем🙃)

После прошлого воркшопа по MSPC получила такие отзывы:

«Отличный воркшоп! С методологией MSPC столкнулась впервые. Вместо привычного поверхностного анализа и интуитивных решений — чёткий алгоритм: классифицируешь проблему и идёшь прямо к коренной причине. Особенно ценно, что разбирали реальный кейс и получили план улучшений, а не просто теорию»

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

И здесь, кажется, важно чуть подробнее рассказать, что такое MSPC.

MSPC — это не “ещё одна методология”, которую нужно выучить.
Это способ мыслить о проблемах в процессах.

Не через:
— «давайте автоматизируем»
— «давайте добавим людей»
— «давайте упростим шаг»

А через:
👉 понимание, к какому типу относится проблема
👉 где именно она возникает в процессе
👉 и почему она вообще появляется

По сути, это переход:
от симптомов → к причинам → к обоснованным решениям

И на практике это даёт очень заметный эффект:
ты перестаёшь “угадывать” решения
и начинаешь их обосновывать

На воркшопе мы как раз это и делаем:
— разбираем реальный кейс
— проходим по шагам алгоритма
— и выходим на причины и варианты улучшений

Без перегруза теорией, но с фокусом на мышление.
Подробности вот тут

Лид анализа vs Скрам-мастер
Что делать, если начинается конфликт?

Ситуация:

Вы — лид анализа в компании, где активно внедряют Agile. Перезапускаются команды, идут PI-планирования, матричная структура.

Появляется новая команда. Новый аналитик. Вы понимаете: нужно сопровождение на старте. Команду зовут на PI-планирование.
Вам говорят: “тебе нельзя участвовать”

Странно.

Вы объясняете:
— команда новая
— аналитик новый
— нужен контроль старта

Ответ: нет. 😒
⸻

Через пару дней — эскалационное письмо вашему руководителю. Вы в копии.😳

И вот здесь важно не “что вы чувствуете”(хотя да, это тоже понятно)
А как вы интерпретируете ситуацию
⸻

❌ Ошибка №1
Воспринимать это как личный конфликт

👉 это не про “наезд”
👉 это про конфликт ролей и границ

Да, формулировки могут быть резкими. Но мы всё-таки про профессиональное взаимодействие.
⸻

Что здесь на самом деле происходит:

Скрам-мастер:
— защищает команду (по гайду)
— выстраивает автономию (по гайду)
— ограничивает внешнее влияние (по гайду)

Лид анализа:
— отвечает за качество работы аналитиков (по функции)
— за их развитие (по функции)
— за результат через подопечных (по функции)

👉 оба действуют в рамках своих зон влияния
👉 но в разных системах координат
⸻

❌ Ошибка №2
Пытаться “продавить” участие

В Agile это почти всегда считывается как:
👉 недоверие к команде
👉 микроменеджмент
⸻

✔ Что стоит сделать:

1. Разделить роли
Вы не участник команды. Вы — владелец функции.

2. Перевести разговор в плоскость цели
Не:
❌ “я хочу присутствовать”
А:
✔ “моя задача — обеспечить качество работы аналитика на старте”

3. Найти формат, а не выбивать доступ
Вместо: “пустите на PI”
👉 предложить:
— синк после планирования
— разбор принятых решений
— точечное подключение

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

⸻

💣 Ключевой момент:

В матричной структуре конфликты — это норма

Вопрос не в том, чтобы их избежать,
а в том, кто управляет границами

И да, иногда это выглядит как “наезд”. Но чаще — это просто отсутствие договорённостей. Ну и неумение говорить о своих сложностях и работать в команде отдельных личностей, тоже никто не отменял.😉 Но мы то, профессионалы высокого класса🙂
⸻

А вы или ваш Лид сталкивались с таким? Как решали?

Думаю над новым направлением в ITHumanWork и хочу спросить вас 👇

Сейчас у нас фокус на аналитиках
Но по ходу работы и проектов всё чаще вижу:

👉 много пересечений с продуктовой ролью
👉 и растущий спрос в сторону Product Manager

У меня появился интересный вариант

Запустить отдельное направление по Product Management с наставником, который:

— работает в международной (Сингапур) компании
— ведёт продуктовую разработку
— и его приложение в 2025 попало в финалисты App Store 🙌

Формат примерно тот же, что и сейчас:

👉 не теория
👉 а работа с реальными задачами
👉 разбор решений
👉 развитие мышления

И если знаете тех, кому это может быть актуально — можете переслать им этот пост

Хочу собрать максимально честную картину перед запуском 👌

На очередной QA-сессии с ребятами из клуба разбирали кейс одного из участников

Перед аналитиком поставили крупную задачу:
👉 подготовить ТЗ для новой части системы

И это тот тип задач, который очень хорошо показывает разницу между уровнями аналитиков.

Потому что задача “написать ТЗ” только звучит просто. На деле — она комплексная.
И Джуна, а часто и Миддла, такая задача довольно быстро ставит в тупик.

Почему так происходит?

Прежде чем читать дальше — напишите своё мнение в комментарии 👇
Будем больше интерактировать с вами

Так вот.
Ключевое различие здесь не в “знании UML” или количестве техник анализа.
Разница в подходе.

Джун и Миддл:
👉 используют известные инструменты и методы анализа

Но Senior и Lead:
👉 начинают управлять самим процессом анализа

А это уже совсем другой уровень работы.
Потому что теперь аналитик:

— не просто собирает требования
— не просто пишет ТЗ
— не просто проводит встречи

Теперь он управляет:

— выявлением скрытых требований
— ожиданиями стейкхолдеров
— коммуникацией между участниками
— корпоративным контекстом
— ограничениями бизнеса
— бюджетом и оценками
— концепцией системы
— зоной ответственности разных участников

И только после этого:
👉 агрегирует всё изученное в целостное решение и документацию

💣 В какой-то момент аналитик перестаёт “пользоваться анализом”

И начинает:
👉 управлять неопределённостью

И именно поэтому предпроектное обследование — одна из самых сложных и самых недооценённых частей работы аналитика.

А вы когда-нибудь проводили предпроектное обследование?
Как это было у вас?