Бизнес-аналитика = Деньги: карьера, зарплата, как войти в IT

Всем привет! Сегодня поговорим о самом начальном и самом важном этапе любого проекта — сборе требований. ⏳ Почему клиенты часто не знают, чего хотят, и как им помочь это сформулировать? Давайте разберем 5 шагов, которые превращают хаос в четкое техническое задание. 👇 Шаг 1. Готовь вопросы до встречи 🛒 Приходить к заказчику без подготовки — ошибка. Что делаем: 🔍 Изучаем контекст (чем живет его бизнес) 📝 Пишем список вопросов (цели, задачи, боли) 💰 Делим вопросы на бизнес-вопросы и функционал Это как поход в магазин со списком: и деньги целы, и купили то, что надо. Шаг 2. Магия интервью 🎩 Заказчик говорит: «Нужно красиво, быстро и удобно»...

Привет! Сегодня я хочу поговорить с вами о самом начале любого IT-проекта. ⏳ О моменте, когда всё только зарождается и когда совершается больше всего фатальных ошибок. Речь пойдет о сборе требований. Почему эта тема? Да потому что фраза «клиент сам не знает, чего хочет» уже стала мемом. 🤷‍♂️ Но наша задача — не посмеяться над заказчиком, а помочь ему сформулировать свои хотелки так, чтобы программисты написали именно то, что нужно, а не «чтобы работало, но я не знаю как». Давайте разберем 5 шагов, которые превращают хаос в техническое задание...

Привет, коллега! 👋 Ты хочешь написать Техническое задание (ТЗ), от которого не сбежит ни один исполнитель, а заказчик не будет спрашивать «А где это мы так договорились?». Тогда тебе точно нужен ГОСТ 34.602.2020 — свежая версия старого-доброго стандарта на ТЗ для автоматизированных систем. Не пугайся слова «ГОСТ»! 🤯 Это не бюрократический монстр, а твой лучший друг. Я разобрал его по косточкам и расскажу только самое важное. Проще говоря, этот ГОСТ — чек-лист мечты. Он гарантирует, что: ✅ Все цели и задачи понятны и измеримы...

Привет, друзья! 😊 Если вы работаете с разработчиками или заказчиками программного обеспечения, то рано или поздно столкнетесь с ТЗ по ГОСТ 19.201‑78 — это официальный стандарт технических заданий для программ и информационных систем. Звучит страшно, но на самом деле ГОСТ — это просто удобный чек‑лист, который помогает не завалить проект. Представьте, что вы строите дом без проекта: каждая задача понимается по-своему — результат выгоден. 🏚️ ГОСТ 19.201‑78 определяет структуру и требования к содержанию ТЗ: какие разделы должны быть, что в них писать и как оформлять...

Если ваш документ с требованиями к разработке не содержит этих 6 разделов — он неполный. Разбираем иерархическую структуру, которая закроет 95% спорных ситуаций. Создание ТЗ часто похоже на сборку Ikea без инструкции: вроде все детали есть, но результат шатается, а лишние винтики остаются. Проблема в отсутствии единого, логичного каркаса. Представленную ниже структуру можно считать эталонной — это исчерпывающий план, превращающий ТЗ из формальности в рабочий инструмент. Здесь вы отвечаете на вопрос «Что, для кого и зачем?» еще до начала разработки...

Вопрос: «📊 КАКИМ ОБРАЗОМ система должна это делать?» (Качество!) Это требования к свойствам системы: скорость 🚀, безопасность 🛡, удобство. 📌 Пример: «Страница оплаты должна загружаться менее чем за 2 секунды ⏱️». «Данные карт должны быть зашифрованы по стандарту PCI DSS 🔒». 💡 ГЛАВНАЯ МЫСЛЬ: Цепочка «Бизнес ➡️ Пользователь ➡️ Функциональные требования» должна быть ПРОСЛЕЖИВАЕМОЙ 🔗. Каждая «фича» ведет к цели пользователя, а та — к цели бизнеса. Если связь рвется — вы делаете ненужную фичу 🚫! 📌 Практический совет-чеклист: 1️⃣ Какой бизнес-цели это служит? 🎯 (Чтобы не делать бессмысленные...

🎯 1. Бизнес-требования (Business Requirements) Вопрос: «➡️ ЗАЧЕМ мы это делаем? Какая ЦЕЛЬ?» Это высокоуровневые цели организации. Они про выгоду и результат 📈 📌 Пример: «Увеличить долю рынка на 15% за год за счет запуска мобильного приложения для заказов». 👥 2. Пользовательские требования (User Requirements) Вопрос: «👤 КТО и ЧТО должен уметь делать?» Они описывают задачи и цели пользователя. Часто пишутся как User Stories 📖 🎭 Формат: «Как [тип пользователя], я хочу [возможность], чтобы [получить пользу]»...

Представьте, что вы приходите к архитектору и говорите: «Хочу дом». Он, конечно, построит. Но будет ли это тот дом, о котором вы мечтали? Без подробного обсуждения количества комнат, материалов, расположения розеток и вида из окна результат, скорее всего, разочарует. В IT-мире история та же. Слово **«требование»** (requirement) — это не просто список пожеланий заказчика. Это структурированная, проверяемая и четкая инструкция, которая отвечает на три главных вопроса: **ЗАЧЕМ, ДЛЯ КОГО** и **КАК**...

Фасилитатор процесса, который помогает команде следовать принципам Scrum и убирает препятствия. Определяет стратегию продукта, «что» делать и «зачем». Бизнес-аналитик часто помогает ему с «как». Упрощённая визуальная модель будущего интерфейса (от скетча на салфетке до интерактивного макета в Figma)...

Подход к разработке через короткие итерации (спринты), быстрые выпуски и обратную связь. Scrum и Kanban — его частные случаи. Последовательный подход: сбор требований → дизайн → разработка → тестирование → запуск. Часто используется в госпроектах. Визуальное описание процессов или данных с помощью диаграмм (BPMN, UML)...

Детальное описание требований к системе. Часто включается в BRD. Документ бизнес-требований. «Что» должно быть сделано и «почему». Документ функциональных требований. «Как» система должна работать. Свод знаний по бизнес-анализу...

Все, кто влияет на проект или заинтересован в нём: заказчик, пользователь, разработчик, тестировщик. Твоя главная аудитория. Что система или процесс должны делать. Бывают бизнес-требования (цели), пользовательские (сценарии) и функциональные (как работает). Описание функции с точки зрения пользователя: «Как роль, я хочу возможность, чтобы выгода»...