Бриф? Техническое задание? Как? Зачем?

Время прочтения: 4 мин
Сложность: норм Просмотров:
Денис Сапожников 27.05.2019

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

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

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

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

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

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

Что делать в этой ситуации, когда одна сторона не способна составить ТЗ, а другая не заинтересована в этом?

Выходов из этой ситуации несколько:

1) Если проект большой или/и технически сложный, то однозначно стоит привлечь внешнего специалиста для разработки технического задания, не связанного с исполнителем. Это позволит сэкономить время и деньги при реализации проекта.
Сколько может стоить разработка подобной документации? Обычно это 3-10% от стоимости проекта.

2) Если проект небольшой, то стоит заинтересовать вашего контрагента в помощи при создании ТЗ.

3) Если время реализации проекта ощутимо меньше, чем время разработки — можно просто условно обсудить задачу, без составления проектной документации.

4) Научиться базовым принципам оформления технической документации

Базовые принципы оформления технической документации:

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

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

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

г. При написании ТЗ на разработку сайта не забывайте о мобильных версиях, кроссбраузерности, кроссплатформенности, адаптивности, требованиям к скорости загрузки, анимации (переходах)

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

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

ж. Не нужно стараться писать большое ТЗ— излагайте свои мысли кратко и по сути.

Для параноиков-идеалистов рекомендую обратить внимание на
ГОСТ 19.201-78 Единая система программной документации
Раздел «Техническое задание. Требования к содержанию и оформлению»

Клиентов, которые приходят с документами под разработку веб-проекта, оформленными по советскому ГОСТу 1978 года встречал крайне редко (только в крупных проектах с государственных торгов).

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

Успешных Вам проектов.

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

А пока этого не произошло, я буду писать этот блог и стараться давать Вам самую суть разработки, продвижения и управления в IT‑проектах.


P.s. нравится проект?
Ну так помоги развить его - репосты, донат и интересная работа приветствуются

Рекомендую посмотреть

Случайный вопрос

Сколько стоит разработать мобильное приложение на iOS?

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

Показать больше ответов

Привет, дружок‑пирожок