Технические задания и IT-системы: разбираемся, как ожидания мэтчить с реальностью
Больше половины IT-систем разрабатываются на основе некорректных или неполных требований. Такие проекты редко становятся успешными. Однако проблему можно решить, если выстроить правильное взаимодействие заказчика с разработчиками системы. В статье разбираемся, как это можно сделать, заменив текстовую документацию на другой способ фиксации требований — графическое техническое задание.
Что такое графическое техническое задание?
Вспомните схему по сборке мебели из ИКЕА: простые рисунки и понятный порядок действий. А теперь представьте, что весь процесс сборки описывается исключительно текстом. Как быстро вы соберёте свой книжный стеллаж «Билли» по такой инструкции?
С ТЗ похожая история, чем оно понятнее, тем проще его согласовать, а также представить, как будущая IT-система впишется в бизнес-процессы заказчика.
Чтобы создать работающий продукт, важно уже на этапе ТЗ убедиться, что разработчик и менеджер со стороны заказчика одинаково полно понимают, что в этом ТЗ написано.
В текстовых ТЗ сложно заметить все детали.
На одном из наших самых длительных проектов, мы начинали с того, что описывали полноценные ТЗ текстом. Затем был этап согласования, который мог затягиваться на неделю. Далее команда приступала к разработке, после которой очень часто заказчик возвращался с фразой «ой, а у нас тут правочки».
За три года совместной работы мы пришли к тому, что стали сразу рисовать скетчи и описывать процесс взаимодействия пользователей с системой. Это значительно ускорило процесс согласования и сократило количество правок.
Хороший системный или бизнес-аналитик может вытянуть из заказчика все необходимые требования и функциональность, но зачастую это занимает много времени с обеих сторон.
Методом проб и ошибок, мы в Аспирити пришли к новому способу фиксации требований, назвали его «графическое техническое задание».
Графическое ТЗ — это подход к разработке требований. При составлении графического ТЗ мы тесно взаимодействуем с бизнесом заказчика для строительства фундамента будущего продукта. Это позволяет не ломать привычные паттерны, а наоборот упростить работу.
Графическое техническое задание полностью описывает функциональность будущей системы и даёт чёткую последовательность действий пользователя.
Графическое ТЗ — это способ фиксации требований заказчика, который помогает визуализировать функциональность проекта и учесть все пользовательские кейсы, чтобы будущая система точно решала поставленные задачи.
Мы используем этот способ, чтобы отобразить смысл всех компонентов, а не их вид. Оно расширяет юзкейсы до подробного скетча с последовательностью действий пользователя и результатом этих действий. Чтобы с первого взгляда было понятно, что на экране вообще происходит.
При использовании графического ТЗ кипы текста превращаются в блок-схемы. Они наглядные и понятные.
Пример из нашего недавнего проекта, где мы разработали приложения для водителей машин-погрузчиков на производстве:
После изучения предоставленного заказчиком ТЗ выяснилось, что в нём отсутствуют важные моменты. Мы погрузились в процессы заказчика и составили новое ТЗ в графическом виде.
На графическом ТЗ понятно, что и в какой момент происходит, какие и откуда данные подтягиваются.
При составлении мы выяснили важные подробности:
- бывает несколько сценариев использования и взаимодействия с тарой;
- на маршрутах могут возникать пересечения водителей, и проектируемое решение должно отрабатывать такой риск.
Чем графическое техзадание отличается от варфрейма и прототипа?
Вайрфрейм показывает, что где и как будет расположено в интерфейсе. Это скелет дизайна, который позже будет заполнен UI элементами.
Графическое техзадание же раскрывает функциональность и кейсы использования, а не представляет детально проработанную структуру и лучшие UX решения.
Главная идея графического ТЗ — понять, всю ли функциональность учли на этапе сбора требований до того, как приступать к разработке.
Мы в Аспирити, тщательно прорабатываем техническое задание и создаём UX-прототип, чтобы иметь возможность протестировать удобство системы до разработки. Так что графическое ТЗ в нашем случае является основой для UX-прототипа.
Смысл у них идентичен, однако способ взаимодействия с интерфейсом разный. Графическое ТЗ просто отображает весь список необходимой нам функциональности. Оно описывает его, как это делало бы обычное текстовое техзадание. А в UX-прототипе вся функциональность становится более удобной для пользователя, так как учитывает паттерны поведения и прошлый опыт.
Зачем нужно графическое ТЗ?
Графическое ТЗ помогает всем специалистам одинаково верно понять логику работы IT-системы и проверить, насколько она вписывается в существующий бизнес-процесс.
Благодаря графическому ТЗ первые этапы разработки можно сделать более понятными для обеих сторон. Это значительно снижает риск ошибочного проектирования и позволяет избежать появления множества правок и доработок в процессе разработки.
Когда действия пользователя отображены визуально, гораздо легче понять, весь ли функционал учли на этапе составления ТЗ. А заказчику становится проще проконтролировать цепочку взаимодействия пользователя с интерфейсом и убедиться, что она отвечает всем бизнес-процессам.
При проектировании и разработке корпоративных решений, мы предпочитаем составлять графическое ТЗ вместе с будущими пользователями системы — сотрудниками компании. Это позволяет лучше погрузиться в бизнес-процессы заказчика и провести интервью с будущими пользователями, а не просто отработать задачи представителя заказчика, которому делегировали проект по разработке нового ПО.
Никаких волшебных способов записать все требования, чтобы потом ничего недоделывать, не существует. Но если вы будете использовать максимально понятные и графические способы для фиксации функциональности системы, то шанс разработать качественный продукт, который не сломает процессы клиента, а улучшит его, увеличится.
С подробными примерами и другим способом создать понятное ТЗ можно ознакомиться в статье:
А обсудить, как написать ТЗ так, чтобы ожидания не расходились с реальностью, можно в комментариях 🙂