ITHumanWork | Карьера в IT и Бизнес анализ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Влияние аналитика — это не роль
Это функция

После поста про встречи хочу продолжить развивать тему влияния аналитика на конечный результат

Посмотрите комментарии, в них одна и та же мысль:
“Меня просто не зовут”
“Решения принимаются без меня”

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

- аналитика не исключают
➡️ его просто не видят как того, кто влияет

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

Влияние — это то, что происходит в момент обсуждения

🏋‍♂️Если аналитик:
— фиксирует уже принятые решения
— оформляет требования
— уточняет после
➡️ он не влияет ➡️ Он обслуживает процесс

😡Если аналитик:
— задаёт вопросы, которые меняют ход обсуждения
— вскрывает противоречия
— показывает последствия решений
— соединяет бизнес, процессы и систему
➡️ он начинает влиять ➡️И только в этом случае:

его начинают звать не потому что “надо”, а потому что без него хуже думается

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

влияние — это не право
это эффект мышления

И да, это неприятно признавать. Потому что легче сказать: “меня не включили”, чем спросить себя “а что я приношу в обсуждение?”

Пишите в комментариях:

☑️ Когда вы приходите на встречу — вы больше фиксируете или меняете ход разговора?

Почему аналитиков не приглашают на важные встречи и почему это бесит?

‼️ Это ситуация, знакомая многим:
➡️ происходит обсуждение продукта;
➡️ принимаются решения;
➡️ затем формулируется задача.

Аналитик узнаёт об этом уже постфактум.

Первая реакция часто бывает следующей: «меня не ценят», «меня исключили» или даже 😡 «как так вообще можно работать?»

Однако, взглянем правде в глаза, проблема не всегда заключается в команде.
Очень часто причина кроется в другом:
❗️ команда не понимает, зачем вам там быть

Если аналитик:
➡️ фиксирует то, что уже решено;
➡️ оформляет требования;
➡️ «дописывает документацию после встречи»,
➡️то его и будут приглашать только после факта формирования задачи

Потому, что его функция воспринимается исключительно как «записать».

Но если.

Аналитик:
➡️ помогает сформулировать проблему;
➡️ задаёт вопросы, которые меняют решение;
➡️ указывает на риски до того, как они материализуются,
➡️ то его начинают приглашать раньше.

Это происходит потому, что он оказывает влияние.

🧠 По сути:
на встречи приглашают не по роли,
а по влиянию.

Безусловно, бывают ситуации, когда:
— процессы нарушены;
— коммуникация выстроена некорректно;
— роли не определены.
Но даже в этом случае остаётся вопрос:
— что именно вы вносите в обсуждение?

Если вы несёте лишь фиксацию — вас пригласят в конце.
Если вы несёте мышление — вас пригласят в начале.

А как у вас?
Вас зовут на обсуждения или подключают «когда уже всё решено»?

Готова взять в работу 2-х лидов аналитики

Сейчас работаю с лидом, и мы разбираем не “как писать требования”

А вещи уровнем выше:
➡️ как понимать свою роль в структуре компании
➡️ где реально твоя зона влияния
➡️ как выруливать из сложных управленческих ситуаций
➡️ как управлять аналитиками, а не просто “раздавать задачи”

И вот что вижу:
чаще всего проблема не в знаниях
а в том, что:

— нет опоры
— нет понимания границ
— и нет безопасного пространства, где можно разобрать ситуацию

Если вы сейчас:

➡️ сталкиваетесь с конфликтами (в командах, с продактами, со скрам-мастерами и т.д.)
➡️ не до конца понимаете свою роль как лида
➡️ чувствуете, что “делаете много, а влияния мало”
➡️ устали разруливать всё в одиночку

🚀 возможно, вам сюда

Как проходит работа:

— сначала созвон, где формируем запрос, цели и разбираем текущую ситуацию
— дальше выбираем формат (обычно — раз в неделю)
— на встречах разбираем конкретные кейсы из вашей работы
— между встречами можно писать, приносить ситуации, фиксировать мысли

Это не разовая консультация
☑️ это сопровождение до результата или до ощущения уверенности в своей роли

Работа гибкая и персональная

И да, для первых двух мест условия будут мягче обычных

В общем, жду — напишите в сообщения канала
и мы определим требуется ли длительная поддержка 🪜

Сначала — ты, потом — рынок
И что остаётся за аналитиком в эпоху AI

Это третий пост из нашей серии с Настей
(первые были про мышление аналитика и профстандарты)
⸻

В разговоре мы довольно быстро пришли к простой, но неприятной мысли:
👉 если ориентироваться только на рынок — можно сильно промахнуться

Это я часто вижу на практике. Люди выбирают направление, потому что:
➡️ “сейчас востребовано”
➡️ “много вакансий”
➡️ “все туда идут”

И дальше начинается:
➡️ не подходит формат работы
➡️ не совпадает тип задач
➡️ быстрое выгорание

И здесь мы с Настей сошлись:
👉 сначала важно понять себя и только потом смотреть на рынок
Потому что рынок сейчас меняется быстрее, чем раньше. Быстрее, чем когда-либо.

И тут как раз появляется второй слой разговора — AI 😡
⸻

AI уже забирает на себя:

➡️ часть анализа данных
➡️ подготовку текстов
➡️ структурирование информации
➡️ базовые исследования

И это только начало 🧶

Здесь возникает логичный вопрос:
👉 а что тогда остаётся за аналитиком?
Мы довольно долго это обсуждали. И пришли к интересной связке

Настя со своей стороны подсветила:
👉 инструменты и навыки будут меняться постоянно
А я добавлю:
👉 остаётся уровень смыслов
⸻

То, что пока нельзя делегировать:

➡️ понять, в чём реальная проблема
➡️ связать бизнес, процессы и систему
➡️ проверить, где причина, а где симптом
➡️ принять решение в условиях неопределённости

Всё снова возвращается к началу:
👉 если ты не понимаешь, как ты думаешь никакой рынок и никакой AI не помогут
Поэтому:

сначала — ты
потом — рынок
и уже потом — инструменты

Это как раз та точка, где анализ перестаёт быть “набором навыков” и становится «профессией уровня мышления»

Как вам наш цикл постов?🙃

Кажется, я об этом ещё не писала (или давно не напоминала) — исправляюсь 👇

⸻

У ITHumanWork есть сайт

И там сейчас собрано всё, что важно:

— подробнее про меня и мой опыт
— какие форматы работы есть для аналитиков и компаний
— статьи и кейсы по оптимизации процессов
— и как со мной можно поработать

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

➡️ той самой, через которую мы работаем с реальными проектами
➡️ и которую я даю на воркшопах и в Клубе

⸻

Если вы давно читаете канал, но ещё не заходили — самое время.
И буду благодарна, если будете делиться хочется, чтобы нас — тех, кто за системный рост в профессии — становилось больше

⸻

И вторая новость:

на сайте появился новый раздел
➡️ записи воркшопов

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

Страничка будет постепенно пополняться 😉

Если откликается — загляните думаю, каждый найдёт что-то полезное для себя

Confluence выкатили Whiteboards
Что это меняет для аналитиков?

Долгое время у нас было разделение:

— требования и документация → Confluence
— обсуждения, схемы, воркшопы → Miro / FigmaJam

➡️ контекст постоянно рвался

Теперь доски появились прямо в Confluence

Что это даёт:

➡️ можно не просто фиксировать требования
А собирать их в процессе

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

➡️ уменьшается разрыв между “обсудили” и “задокументировали”

Раньше:
😡 сначала сделали доску → потом пошли описывать. Потом что-то потеряли при переносе или забыли смысл обсуждения, потому что уже потратили время на перенос и контекст в памяти уже размылся.

Теперь:
🧠 это один поток и всем проще держать контекст

Все артефакты рядом:
— требования
— обсуждения
— схемы
— заметки

По функциональности пока базово:

— стикеры
— шаблоны
— таймер
— простые mindmap

Но для аналитика этого уже достаточно, чтобы:
☑️ провести сессию
🏋‍♂️ собрать требования
🪫 зафиксировать решения

⸻
И да, забавно, что интерфейс подозрительно напоминает FigmaJam 😏
⸻

Но вопрос интереснее:

🧶 вы бы остались в Confluence или всё равно ушли бы в Miro для работы с командой?

Почему профстандарты перестают работать?

Это, кстати, одна из тем, на которой мы с Настей довольно долго зависли в разговоре.

И интересно, что мы пришли к этому с разных сторон, но в итоге — к одной точке.
⸻

С одной стороны — есть ощущение, что “всё размывается”

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

И это многих пугает или как минимум, путает.

Но Настя здесь дала важный контекст:

➡️ сама профессия бизнес-аналитика достаточно молодая

И те самые профстандарты, к которым мы привыкли, по сути — попытка зафиксировать то, что ещё формируется

А дальше начинается самое интересное😉

С моей стороны это выглядит так:

➡️ каждая команда начинает формировать роль под себя:

— под продукт
— под бизнес
— под структуру команды

И в итоге:

аналитик может называться одинаково,
но делать совершенно разное

И вот здесь профстандарты начинают “ломаться”

Потому что:

❌ нельзя описать одну роль для всех
❌ нельзя задать универсальный список задач, который везде будет работать одинаково

Настя очень точно это сформулировала:

➡️ роли начинают дробиться, потому что дробятся задачи бизнеса

А я бы добавила:

➡️ и наоборот — задачи начинают пересекаться сильнее, чем раньше

Вот мы и получаем парадокс:
— роли становятся уже
— а требования к мышлению — шире
Отсюда вывод:

➡️ профстандарты не исчезают
➡️ они просто перестают быть универсальными

И если раньше можно было сказать:
“вот что должен уметь аналитик”

То сейчас скорее:
➡️ “вот как он должен думать”

И, кажется, это как раз то место, где анализ начинает сильно отличаться от других профессий

В следующем посте как раз пойдём дальше. И нет, это не просто “рынок перегрелся” 😡😏

У нас завершился первый реальный консалтинговый проект внутри ITHumanWork🥳

И это не “учебный кейс”
Это работа с настоящим заказчиком

Формат был такой:
участники Клуба вместе со мной проходили полный этап
👉 диагностики бизнеса

Что сделали:

➡️разобрали бизнес-цели и стратегию (например, рост выручки и выход на рентабельность 40%)

➡️провели анализ процессов и выявили реальные проблемы (хаос коммуникаций, размытая ответственность, отсутствие регламентов)

➡️ собрали структуру ролей и зон ответственности (то, что обычно “где-то в голове”)

➡️ предложили изменения в процессах (AS IS → TO BE)

➡️провели Демо (презентацию результатов работы Заказчику)
⸻

И вот что важно:

👉 заказчик уже на этапе диагностики получил результат

— понятную структуру команды
— зафиксированные роли
— прозрачность процессов

И, по её словам, она уже

“в восторге, потому что появляются первые документы для сотрудников”

⸻

А для участников Клуба это было:

— не теория
— не учебный пример
— а реальная работа с бизнесом

Со всеми нюансами:
— неполные данные
— живые процессы
— реальные ограничения
⸻

И сейчас мы переходим к следующему этапу
👉 внедрение изменений
(а это уже совсем другой уровень сложности)
⸻

Для меня это, наверное, самый важный результат:

ITHumanWork — это не про “послушать и забыть”. А про делать, пробовать и видеть эффект
⸻

И да, такие проекты доступны для участников Клуба

Если хочется не просто изучать анализ, а реально в нем работать — вы знаете, куда идти 😉

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

Ситуация:

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

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

Странно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⸻

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

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

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

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

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

Аналитик — это не профессия?

🪫 Недавно записали разговор с Анастасией — бизнес-аналитиком с 15+ лет опыта и автором канала «Про_БА» (@pro_ba_it).

🧠 Поймали себя на мысли, что из этого получилась не просто беседа, а серия важных наблюдений про аналитику сегодня.
Начну с одного из них 👇
⸻

Аналитик — это не столько профессия, сколько способ мышления

Факт:
➡️у аналитика нет фиксированного набора задач

То есть нет единого, универсального списка, который одинаково работал бы в любой компании.
Набор задач всегда зависит:
— от отрасли
— от продукта
— от контекста команды

Аналитик может:
— писать требования
— разбирать процессы
— лезть в систему
— помогать продукту с приоритетами

➡️ в каждой команде роль выглядит по-разному
⸻

Отсюда второй вывод:

аналитик — “человек-оркестр”

Но не потому что “делает всё подряд”.
А потому что:
— работает на стыке ролей
— закрывает разрывы между ними
— держит целостную картину

Сам себе оркестр. Сам себе дирижёр🙃
И здесь есть нюанс:
роли, в которых приходится находиться, могут противоречить друг другу

Нужно:
— удерживать контекст
— переключаться между задачами
— и при этом не терять целостность

➡️ и всем этим управлять одновременно
⸻

И это объясняет, почему:
— сложно описать “идеального аналитика”
— не работают жёсткие профстандарты
— роли в анализе постоянно меняются

Ключевое:

🔍 меняется не набор задач
☑️ меняется способ мышления под задачи

⸻

Мы с Анастасией дальше как раз обсуждали,
почему вообще так произошло. У себя в канале «Про_БА» (@pro_ba_it) она поделится мыслями о возникновении и развитии бизнес-анализа, кому интересно, велком🚀
⸻

Это первый пост из серии. Дальше будет глубже 🙃

Ураа!
‼️ Радостная новость, наконец-то стал работать бот в ТГ(@ithumanworkbot)!

Через него тоже можно записаться на воркшоп, который пройдет завтра. Подробности в предыдущих постах.

Кто откладывал, успейте записаться. 🚀

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

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

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

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

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

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

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

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

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

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

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

Бэклог есть. Управления — нет. 😒

Очень частая ситуация, которую вижу у аналитиков:
— задач много
— бэклог “ведётся”
— что-то постоянно делается

Но если задать простой вопрос: почему сейчас делается именно это — ответить сложно

——

🔍 Кстати, вчера с ребятами из клуба смотрели на новую версию Jira и удивились, что по умолчанию в ней теперь нет Фичей — только Эпики и Стори.

И это хороший повод задуматься:
а вы по каким уровням вообще ведёте бэклог?

——

Бэклог часто воспринимается как:
➡️ список задач
➡️ очередь на разработку
➡️ “что надо сделать”

Но по факту бэклог — это инструмент управления работой команды и, что важнее, управления продуктом.

——

Если в нём:
— перемешаны уровни (эпики, фичи, задачи)
— есть задачи, которые никто не понимает
— половина не актуальна
— приоритеты не объясняются

😡 это не бэклог
🏋‍♂️ это список мыслей и идей

——

Что происходит дальше:

— команда берёт “что понятнее”
— бизнес не получает ожидаемый результат
— аналитик превращается в “оформителя задач”
— приоритеты определяются ситуативно

——
И важный момент:

аналитик не всегда принимает решение о приоритетах, но он напрямую влияет на то, можно ли вообще эти приоритеты определить

Потому что если:
— задачи не структурированы
— нет границ
— не понятна ценность

❗️ никакая приоритизация не сработает

——

Бэклог — это инструмент управления продуктом. И в этом процессе аналитик — первый помощник продакта.

А вы по каким уровням ведёте бэклог?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

hh.ru тихо продолжает менять правила игры

За последние месяцы платформа обновила интерфейс, начала добавлять новые стикеры преимуществ на вакансиях и усилила алгоритмы поиска.

Вакансии всё больше выглядят как карточки продукта, а резюме — как страницы, которые нужно «поддерживать в выдаче»:

➡️ обновлять
➡️ быть активным
➡️ получать отклики

Параллельно компании всё активнее используют ИИ для первичной оценки кандидатов.

Если собрать это вместе, получается интересный сдвиг.

Рынок найма всё больше напоминает маркетплейс:

компании упаковывают вакансии
кандидаты — себя, а алгоритмы решают, кто кого увидит

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

И, возможно, именно поэтому у многих сейчас продолжает укрепляться ощущение:
«я делаю всё как раньше, но это больше не работает»

⸻

Кстати, сегодня вечером в 19:00 мск проведу открытый воркшоп.

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

Приглашения участникам уже отправлены на почту, но ещё можно успеть присоединиться. 🔗Запись — вот тут