Как перестать выполнять задачи клиента — и начать делать то, что ему реально нужно

Привет! Я Лев Гречко, системный аналитик диджитал-продакшна Далее. Хочу поделиться с вами своим подходом к задачам. В статье расскажу, как оптимизирую решения и прихожу к результатам, которые экономят ресурсы обеих сторон стейкхолдеров — заказчиков и команды разработки.

Поинты будут полезны аналитикам, проджектам и заказчикам, которые хотят работать только над действительно полезными фичами.

В моем представлении основная польза аналитика — это не способность красиво описывать требования, методы и писать километровые SQL-запросы. Это умение задавать вопросы и понимать истинную проблему клиента. Для этого нужно копнуть чуть глубже поставленной задачи и учитывать особенности команды: как бизнес-составляющей, так и составляющей разработки.

Я, как аналитик, никогда не имел дело с «диким» интернетом, а работал только с enterprise-проектами бизнеса. Это внутренние системы, где заказчик и пользователь — фактически одно лицо. В Далее успел побывать в двух командах, в каждой из которых были свои особенности общения с клиентами.

С одним заказчиком мы общались на «ты» — порой в неформальной обстановке — лично, в мессенджерах, по телефону, с другим — любой диалог проходил через тонны бюрократии по почте. Бывало и так, что я буквально ни-че-го не знал о клиенте — все шло через тимлида и без моего прямого участия. Но в любом кейсе мне приходилось докапываться до сути, чтобы не тратить время специалистов на неверные решения.

Возьмем пример из обычной жизни, когда начальник говорит: «Хочу отдохнуть». Кажется, все понятно — надо брать отпуск. Но если начать уточнять, появятся варианты:

На каждом ответе сценарий и решения меняются. И в конце оказывается, что отдых — это вообще не отпуск, а делегирование части работы, перенос сроков или найм помощника.

С задачами аналитика то же самое. Стоит насторожиться, когда заказчик приходит сразу с готовым решением.

Пример из моей практики — бизнес запросил новый отчет с 30+ атрибутами. Казалось, без него нельзя — нужно срочно разрабатывать. Но я посмотрел внимательнее: почти все нужные данные уже были в другом разделе системы, о котором клиент забыл. Мы добавили пару новых полей, настроили фильтры и визуализацию — и получили тот же результат. Без дублирования, в 10 раз быстрее и с меньшими трудозатратами.

Чтобы аналитику выполнять запрос осмысленно, нужно услышать заказчика и помочь сформулировать настоящую потребность. Привести его к этому через ряд вопросов или разобраться самому, когда действовать приходится вслепую.

Самое важное, что может сделать аналитик в начале работы, — это начать спрашивать. Не писать требования, не рисовать схемы, а разговаривать. И не о том, как должно работать решение, а о том, зачем оно вообще нужно. Правда, перед этим стоит понять сам формат общения:

Из вышеперечисленных тонкостей мы понимаем: возможно ли выйти на прямой диалог, какие есть другие пути для сбора информации и стоит ли вообще их искать.

Если с клиентом можно говорить напрямую и он активно участвует в процессе, то мы переходим к уточняющим вопросам. Главное — не спрашивать все подряд, как на допросе. Хорошее интервью — это диалог, где аналитик помогает заказчику самому обозначить проблему. Иногда человек впервые задумывается над смыслом задачи, когда слышит:

— А если эту функцию убрать, что изменится?

Именно в такие моменты рождается понимание, что делать нужно не все, что просят, а только то, что даст реальную пользу.

Например, заказчик говорит: «Добавьте кнопку для выгрузки данных». Если спросить «Зачем?» и «Кому она поможет?», то может выясниться, что пользователю просто нужно быстро переслать отчет коллеге. Тогда более удобным решением будет не новая кнопка, а автоматическая отправка или общий доступ к отчету.

Если в системе много ролей, то даже общение с заказчиком не даст полной картины. Он описывает бизнес-цель, пользуется частью функционала, но может не знать, как ведут себя все пользователи продукта. В таких случаях помогает опрос. Пусть даже короткий и неформальный.

Чтобы опрос был полезным, не перегружайте его: 5-10 вопросов. Чем длиннее анкета, тем больше шансов получить поверхностные да/нет. Лучше меньше, но так, чтобы каждый ответ раскрывал поведение и мотивацию человека.

1. Начните с контекста. Пусть пользователь расскажет, как часто он работает в системе и что делает. Это даст понимание, какой у него сценарий: ежедневный, периодический или разовый.

2. Узнайте про опыт. Что для него удобно, что раздражает и какие действия занимают больше времени, чем хотелось бы. Не спрашивайте «что вам нравится/не нравится» — спрашивайте «когда вы в последний раз столкнулись с неудобством» и «что вы сделали тогда».

3. Изучите альтернативы. Если человек вместо системы использует Excel, Telegram или блокнот, значит, ему чего-то не хватает. Это ценный сигнал, а не повод спорить.

4. Спросите про ценность. Что для него главное: скорость, точность, визуализация, простота? Ответы часто расходятся с тем, что думает бизнес.

Не стану делать вид, что это простой и доступный инструмент. За все время мне удалось провести полноценный опрос пользователей лишь однажды. Но тот опыт стал очень показателен.

Мы развивали внутреннюю систему расчетов, которая должна была заменить Excel-таблицы. Раньше сотрудники вручную заносили данные, сверяли формулы и тратили на это часы. В новой системе все сводилось к трем кликам: выбрать услугу, указать дату, и нужные показатели автоматически подтягивались из базы.

Но после релиза выяснилось, что часть сотрудников по-прежнему делает расчеты в Excel. Я подготовил опрос на несколько минут. Ответы показали, что людям не хватало уверенности: интерфейс казался непривычным, а в Excel «все видно и под контролем». При этом никто не отрицал, что новая система объективно быстрее.

После демо-сессий, добавления подсказок и улучшения навигации метрики начали расти. Пользователи поняли, в чем их личная польза — меньше рутины и снижение риска ошибок.

Цель: понять, как пользователи реально работают с системой и где возникают сложности.Формат: Google-форма или короткое интервью за 5–10 минут.

Блок 3. Альтернативы и привычки

Блок 2. Оценка опыта

Блок 3. Альтернативы и привычки

Блок 4. Понимание ценности

Даже если такой опрос пройдут десять человек, этого уже достаточно, чтобы увидеть закономерности:

Через ответы мы находим тот самый контекст, который редко отражен в ТЗ, и можем предложить решения на основе реальных данных.

В идеальном мире у аналитиков должен быть прямой доступ к пользователям продукта: с возможностью посмотреть, как они работают, опросить или поговорить с ними. Однако мы живем в далеко неидеальном мире.

И, как я писал выше, не всегда получается выйти на связь и с самим заказчиком: задать вопросы или предложить альтернативы — иногда приказы не обсуждаются.

В таких случаях приходится реализовывать функционал в точности по предоставленным бизнес-требованиям. Но даже без анкет и интервью можно собрать информацию, чтобы провести анализ решения.

Метрики — это честная обратная связь. Пользователи могут сказать, что все удобно, но если цифры показывают обратное — значит, они пошли другим путем. Они же показывают, какие действия сотрудники выполняют чаще всего, а какие — почти никогда. Становится понятно, что реально работает, а что только перегружает систему.

Самый простой и часто недооцененный способ — взять задачу и пройти путь пользователя самому. Когда я начинаю работать с модулем, то закрываю глаза и представляю, что впервые его вижу. Стараюсь выполнить в нем реальную задачу: создать объект, провести расчет, сделать отчет.

Так я вижу то, что не заметить на диаграмме: лишние клики, путаницу в названиях, неочевидные поля. Эта практика помогает смотреть на удобство системы глазами человека, который не знает внутренней кухни.

Можно предложить коллеге не из проекта опробовать функцию — с минимальным объяснением ее работы. Дать ему короткое задание и просто наблюдать, что он делает. Когда человек впервые видит интерфейс, он часто задает те же вопросы, что и будущие пользователи.

Все эти методы можно использовать вместе. Но, чтобы они сработали, важно сохранять любопытство и не зацикливаться на исходной постановке задачи.

Работа аналитика часто напоминает медицинскую диагностику: человек приходит с жалобой, но объяснить причину сам не может. С бизнесом выглядит похоже. За фразой «нам нужно новое решение» может стоять проблема данных, логики процессов или просто усталость от старого интерфейса. Поэтому аналитик должен уметь отделить симптомы от диагноза.

По сути, это и есть аналитика — не в документации и схемах, а в умении разговаривать с людьми. И делать это так, чтобы в конце у всех было одинаковое понимание, зачем мы делаем задачу.

Приходилось ли вам подвергать сомнению требования клиента? К чему удалось прийти?