Записки аналитика: что спасает проект, когда бизнес говорит «сделайте красиво»
Почему я решила написать эту серию статей…
…и кто все это время был рядом
Бывало у вас такое – заходите на сайт, кладете что-то в корзину… и все зависает. Или начинаете заполнять форму, а она вдруг требует ввести одно и то же дважды. И вроде бы вот он, шаг до цели – а что-то мешает его сделать.
Меня зовут Юля. Я – бизнес- и системный аналитик. И в такие моменты я обычно подключаюсь. Чтобы разобраться, что пошло не так. Чтобы превратить смутное "кажется, что-то не то" в ясное "вот здесь сломано"– и починить.
Я веду аналитический цикл от начала до конца: от первых слов заказчика до сопровождения релиза. Каждый день я работаю с самыми разными документами: BRD, пользовательскими сценариями, SRS, UML-диаграммами. Проектирую интерфейсы в Figma, делаю точные прототипы в Axure, рисую BPMN и собираю «самописные» таблицы. В Jira координирую задачи, обеспечивая трассировку требований и прозрачность релизов. А еще владею визуальной фасилитацией: помогаю команде найти общий язык через глоссарии, схемы и презентации, чтобы каждый понимал, за чем мы идем и к чему стремимся.
Но все это – не просто набор навыков. Это способ смотреть на мир: находить связи там, где кажется лишь шум. Задавать вопросы вместо догадок. Не бояться услышать: «я не знаю».
💡 Зачем это веб-студиям и разработке
Вы и сами знаете, как часто заказчик приходит с фразой «нам нужен сайт» – без понимания, что именно не работает в бизнесе. Аналитик встраивается в работу до стадии дизайна и ТЗ – чтобы проект был про решение реальной проблемы, а не про очередной шаблон. Мы в «ЛК» привлекаем аналитиков к работе над проектом сразу. Именно поэтому нам не важно, есть ТЗ или нет. Наша команда сама может разобраться и гибко встроиться в процессы, не теряя времени. Обращайтесь.
Когда я начинала, аналитика казалась мне разбросанными фрагментами: диаграммы, UX, SQL–запросы, API–интеграции, встречи с заказчиком… Меня немного пугала эта разношерстность. Однако со временем я поняла: между этими элементами есть маршрут. И по нему можно пройти шаг за шагом, собирая целостную и работающую систему.
В этой серии статей я не собираюсь выдавать сухой чек-лист или заумные определения. Я хочу предложить живой, понятный путеводитель – карту, по которой сможет пройти каждый: будь то начинающий аналитик, тестировщик, проджект-менеджер или просто человек, столкнувшийся с навязчивым ощущением «что-то идет не так».
Вместе мы разберем, как превратить бессвязные фразы вроде: «Пользователи кладут в корзину и уходят»– в конкретные вопросы:
- Где именно они замирают?
- Почему форма или кнопка не работают?
- Какое ощущение испытывает человек?
Помимо меня, в этом путешествии будет и еще один попутчик – герой, который постепенно будет обретать черты и голос. Пока вы не узнаете его имени, но заметите, как с каждой темой он раскрывает новую грань общего движения – от неуверенной тени до уверенного спутника.
Если вы сейчас думаете: «С чего начать? Где найти ту самую ниточку?»– добро пожаловать в первую часть.
В ней мы остановимся на «Станции Сбор требований»: научимся слушать и не додумывать за заказчика, превратим "кажется" в данные и зададим тот самый первый вопрос, который запустит цепочку изменений.
А дальше– будут процессы, сценарии, интерфейсы, роли, API… но все по порядку.
Готовы? Тогда поехали.
Проект, с которым мы будем идти
Я вообще-то джем варю. Не просто в банке с этикеткой, а авторский. Уникальные вкусы: лаванда с лимоном, груша с чили… Клубника с кокосом – мой личный фаворит. Люди говорят – вкусно.
Но вот захожу в статистику, если можно так назвать – и ничего не понимаю. Кто-то что-то кладет в корзину, а потом исчезает. Заказ не оформляет. Почему? Без понятия. Может, форма длинная. Может, кнопка “Купить” слишком невнятная. Может, людей пугает слово “муква”, хотя это просто плод баобаба, из которого, кстати, получается отличный джем.
Так начался наш проект. Передо мной был человек – умный, с юмором, немного уставший. Но главное – искренне заинтересованный. Он не просил чудес. Он хотел понять.
– Хочу, чтобы покупали. Понимать, что работает, а что нет. Чтобы все было просто, по-человечески. Ну и чтобы вкус клубника-кокос наконец кто-нибудь оценил.
На этом этапе у него не было формального ТЗ. Ни аналитики, ни гипотез, ни отчетов. Только догадки, наблюдения, ощущения – и надежда на то, что аналитики помогут в этом разобраться.
Так начинаются не просто проекты. Так начинаются настоящие истории взаимодействия между бизнесом и аналитикой. Не с задач. А с вопроса. Не с таблиц. А с желания понять, почему продукт, в который вложено столько души, не работает так, как хотелось бы.
В этой точке аналитик не приходит с готовым ответом. Он приходит с вниманием. С умением слушать, задавать вопросы, вычленять суть. Он – тот, кто превращает "непонятно" в структуру. "Кажется" – в уточненные цели. А "что–то не так" – в путь к решению.
И в этом месте может начать путь кто угодно: начинающий аналитик, тестировщик, который чувствует, что за пределами багов есть нечто большее, проджект, которому важно понимать, что именно нужно построить, и даже опытный специалист, готовый на миг отложить экспертность – чтобы снова почувствовать: все начинается с простого, но честного «не понимаю».
В этом проекте не было понятных вводных. Но было главное – искреннее желание разобраться. А значит, было с чего начать.
🛠 Как встраиваются бизнес- и системные аналитики
Мы не требуем от клиента подробное ТЗ – подключаем аналитика на раннем этапе, распаковываем цели, говорим с бизнесом на одном языке. Это помогает и компании-разработчику: команда не тратит часы на переделки и угадайки.
Станция «Сбор требований»: важные вопросы и первые навыки
«Прежде чем придумывать или описывать решение, нужно точно понять проблему, которую оно должно решать.» – Wiegers, K., & Beatty, J. (2013). Software Requirements, Microsoft Press
Сбор требований – это вроде бы база. Классика. Но именно на этом этапе чаще всего происходят ключевые и незаметные сбои. Незаметные – потому что выглядит так, будто все хорошо: заказчик что-то говорит, аналитик что-то записывает, задача идет в backlog, работа кипит. А потом – «не то сделали».
Почему? Потому что аналитик начал с ответа, а не с проблемы. Потому что заказчик говорил об одном, а думал о другом. Потому что слушали, но не слышали.
Сигналы вместо задач
Почти ни один проект не начинается со строки «Нужно сделать…». Он начинается с сигналов – разрозненных, тревожных, эмоциональных.
- Люди что–то кладут в корзину и исчезают.
- Может, форма слишком длинная.
- Или кнопка «Купить» слишком невнятная.
- Или слово «муква» пугает – хотя это всего лишь плод баобаба!
- Как вообще понять, что у меня на сайте происходит?
Это не постановка задачи. Это человеческая попытка описать неопределенность. И вот здесь, в этом хаосе, появляется аналитик. Он не принесет сразу план работ. Он принесет ясность – если умеет.
Когда неясность – главный артефакт
Здесь легко ошибиться. Особенно если ты уже опытный специалист и быстро «узнаешь» типовую ситуацию.
– Ага, классика: не видят кнопку, редизайн страницы нужен.
– О, я уже делал такое, там воронка всегда в форме рвется.
– Ну ясно, надо ускорить оформление и добавить прогресс-бар.
Стоп. Эти быстрые реакции – не анализ. Это не анализ, а аналитическая инерция – опасная тем, что маскируется под уверенность, но уводит от сути. Заказчик не дал гипотезу. Он проговорил свою тревогу. И твоя задача – не схватиться за первое «кажется», а понять, на чем оно стоит.
Что делает профессионал?
Он не давит. Он рассматривает. Он задает вопросы – не чтобы получить ответ, а чтобы достроить картину. Примеры:
🔹 А в какой именно момент пользователь чаще всего уходит?
🔹 Есть ли аналитика, тепловая карта, запись сессии?
🔹 Что показывает воронка? Где обрыв?
🔹 А вы сами пробовали пройти путь как пользователь?
Чем больше ты уточняешь, тем яснее становится, где начинается проблема. И часто ответ – «не знаем».
– Нет, тепловую карту не подключали.
– Да, путь не проходили.
– А какие у нас данные… возможно, где–то в кабинете хостинга.
Это не провал. Это нормальный старт. Большинство команд живут в догадках, пока кто–то не начнет задавать нужные вопросы.
Но вот что важно: вопросы – это тоже методология
Ты не просто говоришь «а покажите путь». Ты понимаешь, какие типы слепых зон могут быть:
- Бизнес–процесс как черный ящик: «у нас все руками, но нормально работает».
- Пользовательский путь как догадка: «ну они обычно делают вот так».
- Цифры как миф: «у нас вроде бы 20% конверсии».
- Данные как хаос: «аналитика где–то была, сейчас не скажу».
Это называется ракурсный просмотр требований: ты смотришь не только на то, “что хотят”, но и откуда это взялось, чем подтверждено, какими ограничениями окружено, кем сформулировано – и кем оставлено за кадром.
Уровень выше: чувствительность к контексту
Топ-аналитик (и хороший проджект, и зрелый тестировщик и многие другие) чувствует, как говорят разные роли.
🔹 Руководитель говорит стратегией – но часто не знает, как устроен процесс.
🔹 Пользователь говорит болью – но не знает, как устроена система.
🔹 Технарь говорит реалиями – но не всегда слышит бизнес–смысл.
Аналитик собирает эти голоса, проверяет взаимосвязи и фиксирует не то, что «сказали», а то, что действительно должно лечь в основу проектирования.
📌 Аналитик – не роскошь, а норма в разработке
Вы экономите время, деньги и нервы, когда аналитик заранее отсекает лишние гипотезы. Мы не просто “пишем документацию”, а встраиваемся в процесс – гибко, поэтапно, без бюрократии. Так проект доходит до релиза с нужной фичей, а не “тем, что придумали по пути”.
Наш герой впервые замер
Он услышал тревогу – и не стал бежать с ответом. Он сделал паузу. Настроился. Прислушался. Он впервые услышал тишину между словами и понял: там, где кажется пусто – на самом деле смысл.
Это было начало. Он еще не знал, как формулировать вопросы, не умел отличать гипотезу от страха и боль от запроса. Но в этот момент он выбрал – не торопиться.
У него появились уши – большие, внимательные. С их помощью он начал не просто слушать, а понимать суть сказанного и несказанного.
Совет героя
Не додумывай за заказчика. Даже если кажется, что все ясно. Думай вширь: кто говорит, почему именно сейчас, что замалчивается, кто не пришел на встречу, какие данные лежат под ковром.
У каждого проекта – свои «невыявленные» требования. И часто именно они подрывают сроки, бюджеты, а вместе с тем и доверие.
Хочешь убедиться, что ничего не упустил? Смотри на проект не с одной, а с десяти точек – процесс, данные, состояния, исключения, интерфейс, роли, отчеты, жизненный цикл, мониторинг, администрирование. Эта техника изменила мой подход в моей работе – и, возможно, пригодится и тебе.
Продолжение – в следующий вторник в этом же блоге. Расскажу про техники фасилитации, SMART и многое другое. А пока вы можете проконсультироваться у специалистов нашей компании в приоритетном порядке, заполнив форму по кнопке ниже и указав код «Статья аналитика»:
