Технические задания и IT-системы: разбираемся, как ожидания мэтчить с реальностью

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

Вспомните схему по сборке мебели из ИКЕА: простые рисунки и понятный порядок действий. А теперь представьте, что весь процесс сборки описывается исключительно текстом. Как быстро вы соберёте свой книжный стеллаж «Билли» по такой инструкции?

С ТЗ похожая история, чем оно понятнее, тем проще его согласовать, а также представить, как будущая IT-система впишется в бизнес-процессы заказчика.

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

В текстовых ТЗ сложно заметить все детали.

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

Методом проб и ошибок, мы в Аспирити пришли к новому способу фиксации требований, назвали его «графическое техническое задание».

Графическое техническое задание полностью описывает функциональность будущей системы и даёт чёткую последовательность действий пользователя.

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

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

При использовании графического ТЗ кипы текста превращаются в блок-схемы. Они наглядные и понятные.

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

После изучения предоставленного заказчиком ТЗ выяснилось, что в нём отсутствуют важные моменты. Мы погрузились в процессы заказчика и составили новое ТЗ в графическом виде.

На графическом ТЗ понятно, что и в какой момент происходит, какие и откуда данные подтягиваются.

При составлении мы выяснили важные подробности:

Вайрфрейм показывает, что где и как будет расположено в интерфейсе. Это скелет дизайна, который позже будет заполнен UI элементами.

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

Главная идея графического ТЗ — понять, всю ли функциональность учли на этапе сбора требований до того, как приступать к разработке.

Мы в Аспирити, тщательно прорабатываем техническое задание и создаём UX-прототип, чтобы иметь возможность протестировать удобство системы до разработки. Так что графическое ТЗ в нашем случае является основой для UX-прототипа.

Смысл у них идентичен, однако способ взаимодействия с интерфейсом разный. Графическое ТЗ просто отображает весь список необходимой нам функциональности. Оно описывает его, как это делало бы обычное текстовое техзадание. А в UX-прототипе вся функциональность становится более удобной для пользователя, так как учитывает паттерны поведения и прошлый опыт.

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

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

Когда действия пользователя отображены визуально, гораздо легче понять, весь ли функционал учли на этапе составления ТЗ. А заказчику становится проще проконтролировать цепочку взаимодействия пользователя с интерфейсом и убедиться, что она отвечает всем бизнес-процессам.

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

С подробными примерами и другим способом создать понятное ТЗ можно ознакомиться в статье:

А обсудить, как написать ТЗ так, чтобы ожидания не расходились с реальностью, можно в комментариях 🙂