DataBatt

Спринт закрыт, код выкатили, тесты зелёные. Команда празднует победу, пока заказчик не открывает прод и не произносит сакраментальное: “А где сортировка по регионам? Я же просил!” Разработчик открывает Jira — чисто. Аналитик листает Confluence — другая версия ТЗ. Тестировщик поднимает тест-кейсы — вообще не про то. Проект вроде жив, но кто-то явно потерял нить. Знакомо? Добро пожаловать в мир, где нет трассировки требований. Если совсем просто, трассировка требований — это способ не потерять связь между тем, что хочет бизнес, что делает команда и что проверяют тестировщики...

Почему разработчики и тестировщики так часто получают размытые ТЗ и страдают от бесконечных переделок? Потому что мы слишком редко “дебажим” не код, а коммуникацию. В статье — четыре простых метода, которые помогут быстро понять, что на самом деле нужно заказчику: “Пять почему”, вопросы о бизнес-цели, интервью “от будущего к настоящему” и техника уточнения гипотез. Если ты хочешь перестать быть “исполнителем задач” и стать инженером смысла — добро пожаловать. Знакомо? Заказчик приходит и говорит: 1...

Что делает аналитик, если проект — это не CRM, а виртуальная электростанция? Разбираемся, как он соединяет технологии, психологию и сторителлинг, чтобы обучать людей в мире, которого не существует. Если ты когда-либо сталкивался с аналитиками, то, скорее всего, представляешь себе человека с таблицами, BPMN-диаграммами и ТЗ толщиной с «Войну и мир». Он знает всё про бизнес-процессы, требования и API. Но вот приходит VR-проект — и привычная логика ломается. Здесь пользователь не просто нажимает кнопку — он живет внутри сценария...

Представьте: вы разработчик, и вам в Jira прилетает задача — «Сделать кнопку красивой». Ну ок. Вы берёте UI-kit, добавляете градиент, скругления, анимацию при наведении. Всё по красоте. Сдаёте задачу — и слышите: «Нет, мы хотели строго и минималистично. Уберите лишнее, сделайте серой и без скруглений». В этот момент хочется открыть git и сделать git reset --hard reality. И дело не в том, что вы плохо написали код. Просто где-то потерялась самая важная часть проекта — смысл, который заказчик вкладывал в своё пожелание...

Когда я только начинал в аналитике, у нас был один разработчик Дима, который знал базу как свои пять пальцев. Каждый раз, когда мне нужны были данные, я чувствовал себя школьником с тетрадкой: — «Дим, можешь выгрузить, сколько пользователей нажали на кнопку „Купить“ за прошлую неделю?» — «Ага, ща… ну, через пару дней». И вот сидишь, ждёшь. Идея для анализа уже остыла, гипотеза потеряла актуальность, а отчёт приходит, когда бизнесу он уже «не горит». Именно тогда я понял: аналитик без SQL — как сапожник без сапог...