Без ТЗ результат… ну, вы поняли.

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

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

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

Вы рассказываете это IT-команде напрямую, и они приступают к работе. Ведь, вроде, все понятно, ничего сложного. Разработка длится несколько месяцев, но в итоге вы получаете приложение с длинными таблицами, где всё нужно вносить вручную и долго разбираться. Часы разработки оплачены, деньги потрачены, но цель не достигнута. Кто виноват? В сущности, никто: в начале проекта вы не обсудили детали достаточно подробно, не договорились, что именно значит «удобство пользователя» в этом конкретном приложении.

Как это может исправить аналитик? Он выступает в роли дотошного переводчика с «заказческого» на «разработческий» и обратно. Уточняет, что именно вы имеете в виду, как представляете готовый продукт, и описывает его так, чтобы было понятно не только вам, но и команде. После такой подготовки вы получите то, что заказывали, а не неприятный сюрприз.
 

У каждого проекта есть своя специфика, но работа аналитика может включать в себя:

• Совместную проработку идеи с заказчиком, формулирование проблем и целей. Аналитик выясняет у клиента текущие бизнес-задачи, желаемые изменения и ожидаемые результаты. Цель этого этапа — понять «боль» клиента и наметить пути ее решения.
• Исследование конкурентной среды. Некоторые аналитики также включают в свою работу изучение рынка, продукты-аналоги. На основе этого он формирует перечень преимуществ, недостатков и особенностей различных существующих решений, представляет его заказчику. Так при создании клиентского приложения для сети АЗС мы выяснили, что раздражает пользователей в аналогичных сервисах, и постарались избежать таких проблем. Например, пользователь не столкнется с принудительным обновлением приложения в момент оплаты и списания бонусов, а нажимать на основные кнопки удобно одной рукой, если вторая занята заправочным пистолетом.
• Определение ключевого функционала. На основе первых двух этапов формируется первоначальное представление о будущем продукте. Проектируется MVP (Minimum Viable Product) — минимальная жизнеспособная версия сервиса.
• Проработка пользовательского опыта (UX). Аналитик создает возможные сценарии взаимодействия пользователя с продуктом, продумывает, как он будет достигать своих целей. Например, при разработке приложения для заказа блюд в сети кафе «Нетипичная пельменная», мы сделали максимально простую логику, чтобы клиент мог оформить заказ за считанные минуты.
• Детальное описание сервиса. Это может быть визуализация архитектуры сайта, таблицы, диаграммы, иллюстрации — наглядное представление для клиента и разработчиков.
• Формирование технического задания. После завершения обсуждений и достижения понимания между заказчиком и разработчиками, аналитик составляет ТЗ. Этот документ служит основой для разработки. Чем более детальным и точным он будет, тем меньше проблем возникнет в процессе реализации.

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

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

Аналитики в нашей и любой другой IT-команды — незаменимые сотрудники, и у каждого из них свои задачи и проекты. Новому клиенту может казаться, что их работа не нужна, ведь он сам уже всё написал в ТЗ, но часто обсуждение таких понятий, как удобство, красота показывает, что заказчик и разработчики могут понимать их совершенно по-разному. Поэтому человек, который установит значения этих понятий, «переведет» требования бизнеса на язык разработки — это буквально герой, который спасает всех от конфликтов, переделок и переплат.