tgindex

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

описание

ITHumanWork — как рынок и найм смотрят на бизнес-аналитиков. Без иллюзий: резюме, рост, потолок, реальная работа в командах. Клуб ITHumanWork — профессиональная среда, где аналитики взрослеют и начинают звучать выгодно для рынка.

792
подписчиков
Охват к подписчикам
22,5%
ERR
Реакции к просмотрам
1,92%
293 на 49 постов
Пересылки к просмотрам
0,64%
97
Постов в день
0,0
всего 91

Где отзываются чаще

доля реакций к просмотрам
  • 3 июл. 2025 г.без подписи5,77%
  • 8 февр.без подписи4,46%
  • 21 окт. 2025 г.без подписи4,44%
  • 6 июл.🔎 Что делает бизнес-аналитик весь день? Типичные задачи BA в российских реалиях Стейкхолдеры считают, что бизнес-аналитик целый день проводит встречи и задает вопросы, разработчики думают - BA все время пишет ТЗ, продакты уверены - этот специалист постоянно анализирует данные. Что говорить, иногда даже сами начинающие BA не всегда понимают, какими именно задачами им предстоит заниматься. Давайте заглянем «под капот» профессии и разложим работу BA по полочкам, от утреннего кофе до вечернего отчета. 🕘 09:00 Аналитик приходит в офис, проверяет почту, участвует в ежедневном стендапе (Daily Stand-up) - встреча с продакт-менеджером и разработчиками, на которой сообщает о статусе задач. 🕤 09:30 Готовится к интервью со стейкхолдерами. Это не просто “пообщаться с коллегами”, а выявить скрытые потребности и боли бизнеса. Для этого аналитик готовит сценарий и вопросы ко встрече. 🕙 10:00 Анализирует существующие бизнес-процессы (AS-IS). Изучает, как процесс работает сейчас и фиксирует в виде моделей в нотации BPMN 2.0 — это стандарт де-факто в РФ. 🕚 11:00 Изучает конкурентов компании. Анализирует, как похожие проблемы решают другие компании на рынке. Это помогает предложить лучшее решение. 🕛 12:00 Встреча со стейкхолдерами. Аналитик - это главный «коммуникационный хаб» проекта. Он должен уметь проводить эффективные встречи и извлекать из них результат. 🕐 13:00 Встреча прошла успешно, задача понятна, ключевые показатели эффективности (KPI) определены, можно и пообедать 🙂 🕑 14:00 Начинает проектировать решение поставленной на встрече задачи. Разрабатывает модели будущих процессов (TO-BE) - визуализация идеального процесса работы после внедрения решения. 🕒 15:00 Структурирует и документирует требования по проекту. Это ядро работы. В зависимости от проекта это могут быть технические задания, пользовательские истории или сценарии взаимодействия с системой. 🕓 16:00 Встреча с дизайнером для обсуждения макетов будущих экранов, чтобы все участники процесса одинаково понимали, что должно получиться. 🕠 17:00 Делает отчет по предыдущему проекту. Пишет SQL-запрос, чтобы получить данные для отчета без помощи разработчика. Далее визуализирует полученные результаты в виде дашбордов. 🕕 18:00 Все задачи на день выполнены, можно идти домой👋 Если, пока вы читали, вам показалось, что это нереально, то вам не показалось😁 Так выглядел бы идеальный день бизнес-аналитика - мне же хотелось показать многообразие наших задач. Пишите, что из вышеперечисленного делаете чаще всего, а я в следующем посте опишу реальный день бизнес-аналитика.4,02%
  • 5 нояб.без подписи4,00%
  • 29 окт.без подписи3,60%
  • 14 мая🎁 Разыгрываю место на ближайшую QA-сессию клуба ITHumanWork И хочу сделать это чуть интереснее, чем просто “поставьте реакцию” 🙂 На QA-сессиях мы обычно разбираем: — сложные рабочие ситуации — конфликты ролей — проблемы в командах — предпроектное обследование — работу с неопределённостью — реальные кейсы аналитиков, лидов и продактов Поэтому условие участия будет таким: 👇 Напишите в комментариях: — сложный кейс из вашей практики или — рабочую ситуацию, которую вы до сих пор не понимаете как правильно решать или — вопрос, который давно хочется обсудить с другими специалистами 💣 Победителя выберу не рандомно А по самому интересному / неоднозначному / жизненному кейсу И да, вполне возможно, что часть кейсов потом разберём ещё и отдельными постами в канале 👀 Если у вас есть коллеги: — аналитики — лиды — продакты которым это тоже может быть полезно — можете переслать им этот пост 🙌 Посмотрим, какие реальные боли и ситуации сейчас происходят внутри профессии3,51%
  • 23 июн.Почему в IT так плохо слышат друг друга? Или, точнее, не умеют. За годы работы я всё больше убеждаюсь: большая часть проблем в IT возникает не из-за технологий, сложных терминов, разных грейдов или специализаций. А из-за коммуникации. Посмотрите на типичную цепочку. 1️⃣-е звено. Топ-менеджер говорит: 👉 “Нам нужно ускорить запуск продукта” Но не всегда может объяснить: - зачем; - для кого; - какие ограничения существуют; - что именно считается успехом. 2️⃣-е звено. Мидл-менеджер получает эту задачу и добавляет свою интерпретацию. Потому что ему тоже нужно как-то превратить стратегию в конкретные действия. 3️⃣-е звено. Аналитик пытается собрать из всего услышанного что-то непротиворечивое. Иногда успешно. Иногда играет в тот самый “сломанный телефон”. 4️⃣-е звено. Потом приходит разработчик и говорит: 👉 “Так сделать нельзя” Или: 👉 “Это будет стоить в 10 раз дороже” И внезапно оказывается, что половину договорённостей нужно пересматривать. Все, цепочка замкнулась, начинай сначала. Почему это происходит? По моим наблюдениям, причин несколько: 1️⃣ Людей редко учат формулировать свои ожидания. Мы ожидаем, что руководитель автоматически умеет ставить задачи, а аналитик - писать безупречные ТЗ. Но это отдельные нарабатываемые навыки, а не безусловные рефлексы. 2️⃣ Не всегда понятно, какую проблему должен решить новый человек. Очень часто вакансия появляется раньше, чем сформулирована потребность. 3️⃣ Цели и приоритеты постоянно меняются. Сегодня проекту нужен один специалист. Через месяц уже другой. 4️⃣ Руководители далеко не всегда понимают текущее состояние рынка. Какие специалисты существуют. Что умеют, с каким рабочим запросом можно к ним прийти. И чем они отличаются друг от друга. 💣 Поэтому одна из самых недооценённых компетенций в IT — это не знание BPMN, UML или SQL. А умение формулировать мысли так, чтобы другой человек понял ваш посыл однозначно, без лишних догадок. И чем выше позиция человека в компании, тем дороже обходятся ошибки коммуникации. А как вам кажется, где чаще всего ломается передача смысла: a) между бизнесом и IT b) между руководителями и командами c) между самими специалистами?3,50%
  • 11 июн.Не вверх, а вглубь Что почитать Senior-аналитику и аналитику-управленцу Заметила интересную вещь. Когда аналитик растёт от Junior к Middle, список книг обычно выглядит так: — BPMN — UML — User Story — требования — Agile То есть мы учимся профессии. Но потом наступает момент, когда новые знания по нотациям и шаблонам уже почти не меняют качество работы. Потому что основные сложности становятся другими. Теперь нужно понимать: — почему люди сопротивляются изменениям — почему компании принимают странные решения — почему хорошие процессы не внедряются — почему руководители конфликтуют между собой — как вообще устроены организации И в этот момент аналитик начинает читать уже не про анализ. А про управление, системы, людей и бизнес. Из книг, которые в своё время сильно повлияли на меня: 📚 Ицхак Адизес Практически весь цикл его книг. Особенно полезны работы про жизненные циклы компаний, управленческие роли и знаменитая классификация PAEI. Очень помогает понять, почему компании ведут себя по-разному и почему одни управленческие решения работают, а другие нет. 📚 Мир Эяль — «На крючке» Про механики формирования привычек и поведения пользователей. Полезно не только продактам, но и аналитикам, которые работают с пользовательскими сценариями и цифровыми продуктами. 📚 Патрик Ленсиони — «Пять пороков команды» Про то, как на самом деле возникают проблемы внутри команд и почему даже сильные специалисты не всегда способны показывать сильный результат вместе. 📚 BPM CBOK На мой взгляд, одна из лучших книг для тех, кто хочет выйти за пределы моделирования процессов и начать понимать процессное управление как систему. 💣 В какой-то момент рост аналитика происходит уже не вверх по профессии. А вглубь понимания того, как работают люди, компании и системы. Именно там обычно начинается переход от: 👉 «аналитик умеет делать задачи» к 👉 «аналитик влияет на результат» ⸻ А какие книги сильнее всего повлияли на ваше профессиональное мышление?3,48%
  • 3 нояб.без подписи2,94%
  • 12 маяПочему функции Product Manager всё чаще пересекаются с анализом? 🤷‍♀️ Ранее разграничение ролей казалось более чётким. Product Manager: 👉 отвечает за продукт, его ценность и стратегию. Аналитик: 👉 собирает требования и содействует реализации. Однако по мере развития индустрии эти роли начинают всё активнее пересекаться. В чём причина такого развития событий? Современный Product Manager уже не может ограничиваться исключительно уровнем: — идей; — гипотез; — дорожных карт (roadmap). Сегодня специалисты по продукту всё чаще вынуждены: — разбираться в бизнес-процессах; — понимать ограничения систем; — проводить анализ данных; — работать в условиях неопределённости; — выявлять реальные проблемы пользователей; — управлять требованиями и ожиданиями стейкхолдеров. Это уже сфера аналитического мышления. Одновременно с этим аналитики также начинают двигаться в сторону Product-подхода. Поскольку хороший аналитик давно не просто: 👉 «описывает требования». Он: — фокусируется на ценности; — влияет на принятие решений; — содействует приоритизации задач; — сохраняет понимание бизнес-контекста; — оценивает влияние изменений на продукт. 😡 В итоге границы между ролями начинают размываться. Всё чаще вопрос звучит не так: 👉 «какова ваша формальная роль?» А так: 👉 «какую функцию вы выполняете в команде?» При этом роли остаются различными. Product Manager отвечает: — за направление развития; — за ценность; — за бизнес-результат. Аналитик: — за исследование; — за структурирование информации; — за выявление и удержание контекста. Однако без развитого аналитического мышления Product Manager сегодня очень быстро начинает принимать решения, основанные исключительно на интуиции. А без глубокого понимания продукта аналитик рискует превратиться в специалиста по оформлению документации. И, честно говоря, представляется, что в будущем пересечений станет ещё больше. Особенно в командах, где приоритетом является не процесс ради процесса, а реальный результат. ❤️ Как вы считаете: границы между Product и аналитикой действительно становятся тоньше или это результат смешивания ролей со стороны компаний? 🪫2,92%
  • 20 окт. 2025 г.без подписи2,65%