Analyst IT

описание

Авторский канал для аналитиков в индустрии ИТ. Все, что надо знать аналитику в одном месте. Сотрудничество: @the_real_bird BA/SA: @ba_and_sa Регистрация РКН: https://knd.gov.ru/license?id=673c6a15b7aeb106ce045ee5&registryType=bloggersPermission #J6THB

← к каналу @analysis_it

12 520

подписчиков

Охват к подписчикам

13,5%

ERR

Реакции к просмотрам

0,47%

209 на 25 постов

Пересылки к просмотрам

1,03%

463

Постов в день

0,3

всего 25

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

доля реакций к просмотрам

27 июл.Как аналитик выживает между бизнесом и разработкой Салют! Есть шутка в профессии: аналитика не любят ни бизнес ни разработка. Бизнес считает что ты на стороне IT и тормозишь. Разработка считает, что ты на стороне бизнеса и генеришь бесконечные хотелки. А ты стоишь посередине и пытаешься сделать так чтобы все были живы. Я провела в этой позиции двенадцать лет. И да, первые несколько лет это реально выматывало. Потом поняла несколько вещей которые изменили отношение к этой роли. Ты не переводчик. Ты модератор конфликта интересов Долгое время я думала, что моя задача — переводить с языка бизнеса на язык разработки и обратно. Технически это так. Но если смотреть глубже — аналитик работает в точке где сталкиваются два мира с разными целями. Бизнес хочет всё, быстро и желательно вчера. Разработка хочет чёткие требования, стабильный скоуп и время сделать нормально. Эти желания почти никогда не совпадают полностью. Главная ловушка — пытаться угодить всем. Это невозможно. И попытка усидеть на двух стульях приводит к тому что не доверяют ни те ни другие. Баланс который я нашла: моя лояльность не людям, а результату. Я на стороне проекта — не бизнеса и не разработки. Звучит просто, но внутри перестроиться непросто. Что реально помогает Не передавай требования — объясняй контекст Худшее что может сделать аналитик — принести разработчику список требований без контекста. “Бизнес сказал сделать вот так.” Всё, ты стала почтальоном. Разработчик должен понимать зачем это нужно, какую проблему решает, что будет если сделать иначе. Когда человек понимает зачем — он предлагает решения лучше тех что придумал бизнес. И это победа для всех. Не ходи к разработке с сырыми требованиями Прежде чем идти к команде я сама прохожусь по требованиям и задаю себе неудобные вопросы. Что будет если пользователь сделает вот так? А если данных нет? А если два пользователя одновременно? Какой сценарий если что-то пошло не так? Лучше найти дыры самой, чем услышать их на разборе задач с командой. Разработка это запомнит — в хорошем смысле. Когда бизнес и разработка конфликтуют — не исчезай Самый плохой сценарий: бизнес и разработка начинают выяснять отношения, а аналитик тихонько выходит из чата. Я так делала. Казалось что конфликт не мой. Мой. Потому что в основе почти любого конфликта между бизнесом и разработкой — неточные или противоречивые требования. Разруливать это всё равно придётся, только потом и с большими потерями. Сейчас я захожу в такие конфликты первой. Не чтобы встать на чью-то сторону, а чтобы вытащить на поверхность в чём реальное расхождение. Часто оказывается что люди спорят об одном и том же просто разными словами. Фиксируй решения принятые не тобой Бизнес принял решение которое технически сомнительное. Разработка приняла архитектурное решение которое ограничивает функциональность. Ты была на встрече, слышала, высказала мнение — но решение не твоё. Фиксируй письменно. Не чтобы потом сказать “я же говорила”. А чтобы когда через три месяца это аукнется — был контекст почему так получилось и кто был в курсе. Это защищает всех, не только тебя. Не бери на себя ответственность за чужие решения Это отдельный пункт потому что он про границы. Аналитик отвечает за качество требований и за то что все стороны правильно поняли друг друга. Аналитик не отвечает за бизнес-решения заказчика и за технические решения разработки. Граница тонкая, но важная. Когда её нет — выгораешь быстро. Про эмоциональную сторону — это тоже важно Позиция между двумя огнями эмоционально затратная. Тебя могут обвинять с обеих сторон, иногда несправедливо. Бизнес говорит что не понимаешь их боль. Разработка говорит что приносишь нереализуемые хотелки. Я долго принимала это на свой счёт. Потом поняла: большая часть этих претензий — не ко мне лично, а к позиции. Аналитик по определению находится в точке напряжения. Это не баг профессии, это фича. Именно там где интересы сталкиваются — нужен человек который удерживает общую картину и не теряет голову. Не бизнес, не разработка. Аналитик. Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA2,52%
09:03Как ИИ изменил собеседования для аналитиков — и что теперь с этим делать Недавно разговаривала с коллегой которая проводит технические интервью в крупной компании. Говорит: “Мы перестали задавать вопросы на знание инструментов — бессмысленно. Все приходят подготовленные одинаково хорошо и одинаково поверхностно.” Я поняла о чём она. ИИ изменил собеседования — причём с обеих сторон стола. Что изменилось со стороны кандидата Раньше подготовка к собеседованию занимала недели. Нужно было вспомнить методологии, освежить термины, прогнать в голове кейсы. Сейчас ChatGPT выдаёт список типичных вопросов для аналитика за тридцать секунд и тут же даёт развёрнутые ответы на каждый. Результат: кандидаты приходят технически подготовленными лучше чем раньше. Но эта подготовка часто поверхностная — заученные формулировки без реального понимания за ними. Я видела это на собеседованиях, когда сама выступала в роли интервьюера. Человек красиво рассказывает про Event Storming — но когда спрашиваешь “а как вы справились когда ключевой эксперт отказывался участвовать?” — пауза. Потому что ИИ даёт теорию, а живого опыта за ней нет. Что изменилось со стороны интервьюера Умные компании это поняли и перестроили формат. Вот что я вижу сейчас: 1. Меньше вопросов на знание — больше на мышление “Что такое Use Case?” уже никто не спрашивает. Спрашивают: “Вот размытое требование от заказчика — что будете делать?” Или дают реальный противоречивый документ и смотрят как человек с ним работает. Знание можно нагуглить. Мышление — нет. 2. Кейсы вместо теории Всё больше компаний дают домашнее задание: реальная или приближённая к реальной ситуация, которую нужно разобрать. Не “расскажите про BPMN” а “вот процесс — опишите его, найдите проблемы, предложите решение”. ИИ может помочь с оформлением — но думать за кандидата всё равно не будет. Точнее будет, но интервьюер это увидит. 3. Глубокие вопросы про опыт “Расскажите про сложный проект” стало стандартом. Но теперь идут вглубь: “А что конкретно вы сделали когда заказчик отверг ваше решение?”, “Как вы убедили разработчиков что требование важное?”, “Что бы вы сделали иначе?” На такие вопросы ИИ не даст готового ответа — потому что ответ должен быть про вас, а не про аналитика вообще. 🤔 Что это значит для тех кто готовится к собеседованию ИИ как инструмент подготовки — отлично. Освежить теорию, прогнать термины, подготовить список вопросов которые стоит задать самому — всё это работает. Но есть вещи которые ИИ не заменит: 1. Реальные кейсы из практики. Если опыта мало — берите учебные проекты, pet-проекты, волонтёрские задачи. Что угодно реальное где были настоящие решения и настоящие проблемы. 2. Умение думать вслух. На современных собеседованиях важен не только ответ но и то как вы к нему пришли. Тренируйтесь проговаривать ход мыслей — это навык который нужно качать отдельно. 3. Честность про пробелы. “Я с этим не работала, но вот как бы я подошла к задаче” — это сильный ответ. Гораздо сильнее заученной формулировки которая рассыпается при первом уточняющем вопросе. ‼️ И про другую сторону — как ИИ меняет требования к аналитику Это отдельный разговор — но скажу коротко. Рутинные части нашей работы автоматизируются. Генерация шаблонов, базовые описания процессов, первичная структура документов — всё это ИИ делает уже сейчас. Это не страшно. Это значит что ценность аналитика смещается туда куда ИИ не дотянется: живая работа с людьми, понимание контекста, умение вытащить неочевидное требование, управление конфликтами интересов. Источник: @analysis_it 💙 Analyst IT | 💬 Analyst IT2,40%
5 авг.Синдром самозванца в профессии аналитика — как я с этим жила Салют! Расскажу про то, о чём в профессиональных каналах обычно не пишут. Не про инструменты, не про методологии. Про внутреннее состояние которое преследовало меня несколько лет и которое, как выяснилось, знакомо большинству аналитиков. Синдром самозванца. Ощущение что ты недостаточно компетентна, что тебя вот-вот разоблачат, что остальные знают что-то важное чего не знаешь ты. Как это выглядело у меня Я работала аналитиком уже третий год когда это накрыло особенно сильно. Пришла на новый проект, команда опытная, разработчики с серьёзным бэкграундом. На первой встрече они начали обсуждать архитектуру — термины летели один за другим, я кивала и делала вид что всё понимаю. Потом долго сидела и думала: может я не на своём месте? Может настоящий аналитик должен всё это знать? Спойлер: не должен. Но тогда я этого не понимала. Характерные симптомы которые я у себя замечала: — Боялась задавать “глупые” вопросы на встречах — Переписывала письма по десять раз прежде чем отправить — Когда что-то получалось хорошо - думала что просто повезло — Когда что-то шло не так - была уверена что это только моя вина — Сравнивала себя с коллегами и всегда была не в свою пользу Откуда это берётся в нашей профессии Аналитик работает на стыке всего. Нужно понимать бизнес, технологии, процессы, людей. Область знаний бесконечная — всегда найдётся что-то чего ты не знаешь. Плюс наша работа во многом невидима. Разработчик написал код — вот результат. Дизайнер сделал макет — вот результат. Аналитик провёл десять встреч, вытащил требования, предотвратил три конфликта — и что? Требования это не код, их не потрогаешь. Когда результат работы сложно измерить — мозг начинает сомневаться: а была ли вообще ценность? Что реально помогло 1️⃣ Разрешила себе не знать всего Звучит банально. Но мне реально пришлось внутренне договориться с собой: я не обязана знать всё про архитектуру, про DevOps, про финансовую модель заказчика. Я обязана знать своё дело хорошо и уметь задавать правильные вопросы нужным людям. “Не знаю, давайте разберёмся вместе” — это не слабость. Это профессиональная честность. 2️⃣ Начала вести список того что сделала хорошо Не для резюме. Для себя. Буквально блокнот где я записывала: вот здесь я нашла противоречие в требованиях до того как оно стало проблемой. Вот здесь помогла разрулить конфликт между командами. Вот здесь заказчик сказал что это лучшая документация которую он видел. Когда накрывало сомнениями — открывала и перечитывала. Работало. 3️⃣ Поговорила с коллегами Оказалось что опытные аналитики которым я завидовала — чувствовали то же самое. Просто не говорили об этом вслух. Один разговор по душам с коллегой которая была в профессии семь лет снял с меня какое-то внутреннее напряжение которое я носила месяцами. Мы все притворяемся что знаем больше чем знаем. Это нормально. Ненормально думать что ты одна такая. 4️⃣ Перестала сравнивать себя с чужими достижениями Соцсети и профессиональные каналы показывают лучшее. Никто не пишет “сегодня я провалила встречу и не смогла ответить на половину вопросов”. Все пишут про успехи, про крутые проекты, про сертификаты. Я сравнивала свою внутреннюю кухню с чужим парадным фасадом. Это заведомо проигрышная игра. Что поняла спустя двенадцать лет Синдром самозванца не исчезает полностью. Он просто меняет форму. Сейчас я могу провести сложнейшее интервью с производственниками, написать архитектурное описание интеграции, выступить перед советом директоров — и всё равно иногда поймаю себя на мысли “а вдруг я что-то важное упустила”. Разница в том что раньше эта мысль меня парализовала. Теперь я её замечаю, киваю ей и иду делать своё дело. ❗️Если вы аналитик и узнали себя в этом тексте — вы не одни. И то что вы сомневаетесь в себе скорее всего означает что вы достаточно вдумчивы чтобы видеть собственные пробелы. Это не слабость. Это качество хорошего специалиста. Если было полезно, ставьте реакции 😉 Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA2,12%
2 авг.без подписи1,15%
6 июл.Как читать чужую документацию на API, чтобы не наступить на грабли Салют! Решила еще написать пару постов на тему API и рассказать случай из практики: Получаю как-то документацию на внешнее API — для интеграции с платёжным сервисом. Открываю Swagger, всё красиво, эндпоинты на месте. Согласовываю интеграцию, передаю в разработку. Через две недели разработчик приходит с вопросом: “А что возвращает API если платёж завис в статусе pending дольше часа?” И тут выясняется — в документации этого нет вообще. Ни слова. Хорошая документация — редкость. Поэтому аналитик должен уметь читать её критически, а не просто принимать как есть. Вот на что я теперь смотрю в первую очередь: 1. Есть ли вообще схема ошибок Если описаны только успешные ответы — это красный флаг. Спрашиваю прямо: “пришлите список всех кодов ошибок и их тела ответов”. Если в ответ тишина или “ну, обычно 400 и 500” — закладываю время на уточнения в процессе разработки. Они будут точно. 2. Что значит “опциональное” поле на самом деле Поле помечено как optional. Окей, а что если его не передать? — Подставится дефолт? — Просто проигнорируется? — Или вернётся ошибка, потому что поле опциональное только формально, а по факту обязательное при определённых условиях? Третий вариант встречается чаще, чем хотелось бы. Проверяю на реальном запросе, документации на слово не верю. 3. Идемпотентность — спрашиваю прямо Если интеграция создаёт сущности — платёж, заказ, бронирование — обязательно уточняю: что при повторном запросе с теми же данными? Дубль? Та же сущность вернётся? Для платежей это критично — повторный запрос из-за обрыва сети не должен списать деньги дважды. Если в документации об этом ни слова, это не значит что идемпотентности нет. Значит, про неё просто забыли написать. Спрашиваю у владельцев API напрямую, не додумываю сама. 4. Лимиты и троттлинг Сколько запросов в секунду разрешено? Что происходит при превышении — 429 Too Many Requests, как и положено по спецификации? Или, как бывает на практике, сервис просто молча обрывает соединение либо отдаёт 503? Это нужно знать заранее, а не выяснять на проде в пятницу вечером. 5. Версионирование — какая версия актуальна на самом деле Иногда документация описывает v2, а в реальности эндпоинт всё ещё на v1, потому что миграция не завершена. Смотрю дату последнего обновления документации. Если её нет — тоже звоночек. 6. Тестовая среда — её поведение реально совпадает с продом? Самое неприятное открытие — когда на тестовом стенде всё работает идеально, а на проде логика чуть другая. Уточняю у поставщика API: гарантируется ли идентичность тестовой и боевой среды, или есть нюансы, о которых стоит знать заранее. Документация — это обещание. Но обещания не всегда выполняют полностью. Задача аналитика — найти дыры до того, как их найдёт разработчик в проде, а не после. 🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией)) ___________ Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA1,12%
16 июл.Как работать с требованиями которые меняются — без нервов и переработок Салют! Помню проект, где требования менялись так часто, что я перестала распечатывать документацию — смысла не было. Разработчики смотрели на меня с немым вопросом, я смотрела на бизнес с тем же вопросом. ❗️Тогда поняла: проблема не в том что требования меняются. Они всегда будут меняться. Проблема в том как ты выстраиваешь работу с ними. Сразу честно: ни один инструмент не спасёт если в компании хаос на уровне управления. Но даже в таких условиях правильный подход помогает выжить с меньшими потерями для себя и команды. И это тоже результат. Почему требования меняются — без прикрас — Бизнес не знал чего хочет до конца. Это нормально — люди часто понимают что им нужно только увидев первый результат — Изменился контекст: рынок, конкурент, законодательство, новый руководитель с другим видением — Требования были размыты с самого начала — вот это уже наша зона ответственности Злиться на второй пункт бессмысленно. Над третьим работать — полностью в наших силах. Что реально помогает (или помогало в моем случае): 1️⃣Фиксируйте договорённости сразу Любое решение с встречи — в письмо в тот же день. Люди искренне забывают что говорили три недели назад, это не злой умысел. Иногда такая фиксация воспринимается в штыки: “ты мне не доверяешь?” Я на это отвечала спокойно: “Доверяю, просто у меня плохая память” — обычно разряжало обстановку. Договорились: ... Следующий шаг: ... Жду подтверждения до [дата]. 2️⃣Спрашивайте “зачем”, а не “как” Это работает всегда и везде — просто здравый смысл. Приходит менеджер: “Хочу менять цвет строк в таблице”. Спрашиваю зачем. Оказывается — хочет видеть просроченные заказы. Реальное требование: автоматически подсвечивать просрочку. Другая задача, проще и полезнее. Половина изменений при правильном вопросе превращается в уточнение исходного требования, а не в новую задачу. 3️⃣ Показывайте стоимость изменения Когда бизнес приходит с правкой, говорю прямо: “Эта правка затрагивает три модуля, сдвигает сроки на неделю. Готовы?” Важна подача. Не “это дорого и мы не будем делать”, а “давайте я покажу что затронет эта правка — и вы примете решение”. Некоторые заказчики всё равно воспримут это как отказ помочь — но большинство после такого разговора спокойно отправляют правку в следующий релиз. 4️⃣ Приоритизируйте, не складывайте в кучу Приоритет / Критерий Срочно и важно / Блокирует работу прямо сейчас Важно, не срочно / В следующий спринт Хотелка / В бэклог Честно: в компаниях где всё “срочно и важно” по умолчанию — эта таблица работает плохо. Но даже там она помогает хотя бы начать разговор о приоритетах. 5️⃣ Договоритесь о правилах на берегу В начале проекта проговариваю с заказчиком: как обрабатываем изменения, когда правка идёт в текущий релиз, а когда в следующий, кто финальный ЛПР. Сложность в наших реалиях: ЛПР часто недоступен, меняется или принимает решения в коридоре после планёрки. В таком случае фиксирую хотя бы того кто есть — пусть не идеально, но лучше чем ничего. ❗️И про внутреннее состояние — это важно Я долго воспринимала каждое изменение как личную неудачу. Значит плохо собрала, не так спросила, недоработала. Потом поняла: идеальных требований не бывает. Иногда проблема вообще не в аналитике — а в том что решения принимаются спонтанно на самом верху, и никакой инструмент это не исправит. Наша ценность не в том чтобы зафиксировать всё раз и навсегда. А в том чтобы управлять изменениями так, чтобы команда не сходила с ума и бизнес получал то что реально нужно. 🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией)) ___________ Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA1,09%
28 авг. 2024 г.Всем привет! Продолжаем рубрику «Задачи и тестовые задания» #задачки #тестовыезадания | @analysis_it Задача 8: Вот интересная и необычная задачка на логику, которая поможет проверить аналитическое мышление и креативность кандидата: 💐Секретные цветы В одном закрытом саду растут четыре вида цветов: 🌹Розы 🌷Тюльпаны ⚜️Лилии 🪷Орхидеи У каждого из четырёх садоводов есть по одному виду цветов, и вы должны определить, у кого какие цветы, исходя из следующих условий: 1. Садовод Виктор не ухаживает за Розами. 2. У садовода Алёны есть только Тюльпаны или Орхидеи. 3. Садовод Пётр ухаживает за цветами, которые имеют больше пяти лепестков (это Лилии или Орхидеи). 4. Садовод Анна не может иметь цветы, которые начинаются на букву "О". Вопрос: Какой садовод с каким видом цветов? Решение: Решение этой задачи требует пошагового анализа условий: 1. Из условия 1 мы знаем, что Виктор не ухаживает за Розами. 2. Из условия 2 получается, что у Алёны могут быть только Тюльпаны или Орхидеи. 3. Из условия 3, Пётр ухаживает за Лилиями или Орхидеями. 4. Из условия 4, поскольку Анна не может иметь цветы, начинающиеся на "О", она не может ухаживать за Орхидеями. Опираясь на эти условия, можно сделать следующие выводы: - Если Анна не может иметь Орхидеи, а также Виктор не может иметь Розы, то у Алёны, которая может только за Тюльпанами или Орхидеями, скорее всего, должны быть Тюльпаны. - Это означает, что у Петра должны быть Лилии (так как он ухаживает за цветами с более чем 5 лепестками). - Таким образом, Виктору остаются Орхидеи, а у Анны будут Розы. В итоге: - Виктор — Орхидеи - Алёна — Тюльпаны - Пётр — Лилии - Анна — Розы Эта задачка не только проверяет логическое мышление, но и требует немного креативности для работы с условиями! Источник: @analysis_it0,73%
6 авг.Мы забыли, что такое кодить, и тебе советуем Потому что рост грейда и зп зависит НЕ от этого уж точно! Попытка превратиться в программиста в 2026 - самый долгий и мучительный путь к офферу на 350k+ Чтобы вывозить реалии рынка, нужно знать архитектуру. Вакансий с этим требованием всё больше, на собесах спрашивают постоянно, а сами архитекторы - никакие не сверхлюди. Это просто те, кто решил забрать контроль в свои руки. Они влияют на продукт и бизнес, принимают решения и берут ответственность. А взамен получают уверенность в завтрашнем дне и чек, который часто в два раза выше тех самых 350+к. 13 августа в 19:00 (МСК) проведем бесплатный веб «Архитектура без кода: как стать аналитиком, которого слушают разработчики и бизнес» На вебе на примере заказов, REST, Kafka и баз данных разберем влияние аналитика на архитектуру без единой строчки кода: покажем грамотную связку сервисов, разберем частые ошибки новичков и ответим на ваши вопросы в прямом эфире Регистрируйся по ссылке Erid: 2SDnjepKPPR Название: ООО "СТЕП БАЙ СТЕП" ИНН: 08000132170,59%
17 авг. 2024 г.Алоха! Сегодня решила затронуть тему ролей Бизнес-аналитика и Product manager - PM. Я работала на проектах как с PM, так и без него, где совмещала свою роль еще и его 🤯 И в чем же было различие и с какими трудностями можно столкнуться, давайте разбираться #роли #БА #PM #управлениепроектами Опишу два кейса: Каждая проектная ситуация уникальна, и взаимодействие между бизнес-аналитиками и продакт-менеджерами (PM) может варьироваться в зависимости от специфики проекта. Давайте рассмотрим два кейса: один с таким взаимодействием, а другой без него 1️⃣ Кейс 1: Бизнес-аналитик и PM на проекте 🧑‍💻Ситуация: Разработка нового мобильного приложения для управления финансами)) 🧑‍🏫Роли и обязанности (основные или одни из основных): Продакт-менеджер (PM): - Определение целей продукта: PM проводит исследование и определяет ключевые функции, которые сделают приложение конкурентоспособным - Приоритизация задач: Взаимодействует с командой, формируя бэклог и расставляя приоритеты для разработки функций, исходя из бизнес-ценности. - Координация: Обеспечивает взаимодействие между командой разработки, дизайнерами, маркетингом и тд. Бизнес-аналитик (BA): - Сбор требований: Ведет интервью с заказчиками и пользователями для выявления потребностей. - Документация: Создает требования к функционалу и документацию для дальнейшей разработки. - Анализ процессов: Оценивает болевые точки текущих финансовых решений пользователей и предлагает улучшения. ✅ Результаты сотрудничества: BA с PM смогли оперативно реагировать на изменения приоритетов, отражая новую информацию в бэклоге. Совместная работа позволила избежать недопонимания требований, что ускорило процесс разработки. ———————————— 2️⃣ Кейс 2: Бизнес-аналитик без PM 🧑‍💻Ситуация: Оптимизация внутренней системы управления проектами в крупной компании финансов 🧑‍🏫 Роли и обязанности: Бизнес-аналитик (BA): - Выявление проблем: BA самостоятельно собирает данные о текущих процессах и проводит встречи с командой для понимания их потребностей. - Документация: Создает требования к функционалу и документацию для дальнейшей разработки. - Анализ требований и процессов: Отвечает за формулирование требований и подготовку предложений по улучшению. Оценивает узкие места в процессах и предлагает улучшение. - Коммуникация: Взаимодействует с технической командой, но часто сталкивается с недостатком контекста по бизнес-целям. Грубо говоря, весь проект тянет на себе ‼️Проблемы, с которыми столкнулся BA: - Неясные приоритеты: Без PM сложно было понимать, какие задачи являются наиболее важными с точки зрения бизнеса. - Отсутствие стратегического видения: BA не имел четкого направления, что приводило к потенциальным упущениям в анализируемых данных. - Меньше поддержки: Нехватка координации привела к тому, что некоторые идеи не были правильно донесены до технической команды, вызывая недопонимание. - Трудозатраты: было много ответсвенности возложено на ВА, много времени уходило на работу с бизнесом, а не на реализацию, что смещало сроки сдачи проекта. ———————————— ➕ Преимущества работы в паре с моей точки зрения Бизнес-аналитику проще работать в паре с продакт-менеджером по следующим причинам: 1. Совместное понимание целей: myБизнес-аналитик получает четкое понимание бизнес-целей и приоритетов от PM, что позволяет работать более эффективно. 2. Упрощенная коммуникация: PM служит связующим звеном между командой и заинтересованными сторонами, что помогает BA сосредоточиться на технических вопросах и требованиях. 3. Быстрая адаптация: Когда возникают изменения, PM может быстро адаптировать стратегию, а вместе с BA переработать требования без значительных задержек в проекте. 🏁Подведем итог: Взаимодействие между бизнес-аналитиками и продакт-менеджерами важно для успеха проектов. В первом кейсе сотрудничество способствовало достижению более высоких и быстрых результатов, тогда как во втором случае отсутствие PM создало трудности в определении приоритетов и целей. Это подтверждает, что эффективная командная работа может значительно повысить шансы на успех проекта @ba_and_sa Источник 👇0,44%
21 июл.Можно ли аналитику в 2026 году положиться на ИИ и агентов или ещё нет? ⏳ 15 мин | 🟤🟤⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA0,44%
10 авг.Самый ценный специалист в ИТ и бизнесе Если разработчик пишет код, а тимлид управляет задачами, то кто решает, как вообще должна быть устроена компания и её ИТ-инфраструктура, чтобы бизнес достигал своих целей? Корпоративный архитектор. Он создаёт единый механизм, в котором ИТ, стратегия, процессы и данные не противоречат друг другу и приносят компании реальную прибыль. Отсюда — прямой выход на собственника и доход от 500 000 ₽ в месяц. Вырастите из технаря в стратега за 4 месяца на курсе «Корпоративный архитектор» от Академии Эдюсон. Это комплексная программа для смены роли — с упором на практику, работу с метриками и новыми инструментами. После курса вы сможете реально влиять на бизнес: • Спроектировать единую ИТ-архитектуру по международным стандартам (включая TOGAF и ArchiMate). • Интегрировать нейросети в процессы и автоматизировать работу компании. • Защищать ИТ-решения перед топами на языке денег — с упором на метрики, финансы, оргдизайн и стратегию. Также получите шаблоны и инструкции для решения задач + удостоверение о повышении квалификации в финале. Оставьте заявку с промокодом АРХИТЕКТОР — заберите курс с персональной скидкой. Реклама. ООО «ЭДЮСОН» ИНН 7729779476. erid: 2W5zFJ5e73F0,39%
14 авг.Имитационное моделирование: что это такое и с чем его едят ⏳ 5 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT0,34%