DataBatt

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

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

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

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

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

Если данные — это новая нефть, то SQL — это насос, который качает её из недр. Но бензин, пластик и удобрения из сырой нефти сами собой не появляются. Для этого нужен завод. В мире данных таким заводом стал Python. Excel — это швейцарский нож. Отличный инструмент, чтобы нарезать колбаску: посчитать суммы, построить диаграмму, показать боссу табличку с «итогами за месяц». Но попробуйте этим ножом пилить дерево (например, 10 миллионов строк логов) — и сразу понимаете, что инструмент не про это. SQL мощнее, но это язык запросов, а не аналитики...

Если вы хоть раз получали в Jira задачу с комментарием вроде «нужно срочно подключить пиксель Facebook» или «давайте попробуем A/B тест новой формы регистрации», то поздравляю: где-то рядом с вами работает маркетинговый аналитик. И хотя кажется, что это «ещё один человек, который любит отчётики», на деле это важный игрок, от решений которого зависит, в каком направлении бежит вся команда: стоит ли вкладываться в новый лендинг, менять флоу регистрации или заливать больше бюджета в рекламу. Если упростить до айтишных аналогий, маркетинговый аналитик — это SRE для рекламных кампаний...

Все мы, айтишники, знаем, что данные — это новая нефть. Но вот проблема: нефть сама по себе машину не заведёт. Её нужно переработать, очистить и превратить в бензин. Точно так же и с данными: собрали терабайты логов, накачали базу событиями, сделали ETL — и что дальше? В этот момент на сцену выходит BI-аналитик. Его роль часто остаётся в тени: про дата-сайентистов пишут книги и снимают фильмы, про разработчиков — мемы, а про BI-аналитиков знают только коллеги из соседнего отдела. Давайте разберёмся, кто это вообще такой и почему без него бизнесу трудно принимать решения...

Представьте, что команда строит новый сервис: разработчики кодят, тестировщики ловят баги, менеджеры двигают таски по Kanban-доске. Всё вроде идёт по плану, но в какой-то момент появляется вопрос: «А пользуются ли люди нашим продуктом так, как мы задумывали?». И вот тут на сцену выходит продуктовый аналитик — не маг и не гадалка, но именно тот человек, который умеет разговаривать с цифрами и превращать их в осмысленные решения для бизнеса. Если упростить до максимума, продуктовый аналитик — это GPS-навигатор для продукта...

Представьте: вы сделали красивое приложение. Кнопки сияют, анимации плавные, интерфейс будто сошёл со страниц артбука Миядзаки. Люди скачивают его десятками, но... через день оно пустеет, как заброшенный храм в лесу. Пользователи приходят — и исчезают. Где же та магия, что заставит их остаться? Чтобы найти ответ, в продуктовой аналитике есть карта сокровищ — Pirate Metrics (AARRR). Нет, это не про пиратов с ромом и попугаями, а про настоящий «пиратский клад» — рост продукта. Фреймворк помогает увидеть путь пользователя как приключение с пятью ключевыми этапами...

Представьте, что вы ведёте машину, а приборная панель заклеена скотчем. Вы не знаете, с какой скоростью едете, сколько осталось топлива и не перегревается ли двигатель. Можно ли так добраться до цели? Теоретически да, но риск велик: либо заглохнете, либо попадёте в аварию. С продуктами та же история. Если вы делаете сервис или приложение, но не смотрите на метрики, вы едете вслепую. Код может быть идеальным, дизайн — стильным, а пользователи… уже уходят. Метрики — это приборная панель вашего продукта...

Все мы знаем про калории. Все говорят, что надо их считать, но по факту максимум, что мы делаем — смотрим на упаковке и думаем: «Ну, норм». С метриками в IT всё примерно так же: все признают их важность, но считают единицы. А зря. Умение говорить про метрики — это суперсила. Она превращает разработчика, тимлида или проджект-менеджера из «того, кто что-то просит» в человека, который диктует бизнесу свои правила. И внезапно оказывается, что «починить техдолг» или «сделать фичу» — это не просто хотелка, а обоснованное вложение...