Техническим заданием называется служебный документ с описанием правил выполнения работы и требований к исполнителю.
Почему важно зафиксировать весь процесс работы в виде технической документации?
У каждого проекта должны быть обозначены границы - по стоимости, объему выполняемых работ, срокам исполнения и качеству. Все это должно быть зафиксировано в ТЗ.
Это может означать следующее:
Заказчик не устанавливает четких требований специально, чтобы затем получить часть работ бесплатно, либо он не уверен/не знает/не решил/не понимает, что ему надо.
Разработчик надеется на постоянное продолжение работ за счет заказчика, аргументируя это некой неопределенностью.
В такой ситуации противоположная сторона должна обязательно настоять на создании технического задания с четкими границами и определением задач. Без этого сторонам будет трудно доказать, что работы были сделаны, или, наоборот, не сделаны должным образом.
Заказчик | Менеджер проекта | Разработчики |
---|---|---|
Ставит задачу | Ставит задачу разработчикам | Выполняют задание в соответствии с ТЗ |
Согласовывает ТЗ | Контролирует ход работы и расставляет приоритеты | |
Принимает работу | Осуществляет взаимодействие с заказчиком и разработчиком | |
Тестирует выполненную работу (если нет тестировщиков) |
Если проект большой, дополнительно могут добавиться участники:
Если проект маленький, то заказчик и исполнитель, как правило, работают напрямую. В этом случае тестирование берёт на себя заказчик, а разработчик сам контролирует сроки и ставит приоритеты.
Раздел ТЗ |
+ Для Заказчика |
+ Для Разработчика |
---|---|---|
Определение цели |
Осознание задач, которые решает проект или его доработка |
Понимание сути задачи |
Описание продукта |
Представление о том, каким будет готовый продукт |
Уверенность в правильном понимании конечного результата |
Сроки выполнения |
Ориентирование в сроках работ и получения планируемых результатов |
Оценка трудозатрат и потребности в ресурсах |
Бюджет проекта |
Определение более-менее точной суммы затрат и планирование бюджета |
Согласованный учет всех работ проекта |
Перечень работ |
Подробное описание работ и каждого этапа реализации проекта |
Ведение работ по установленной технологии. Возможность отказаться от работ, не предусмотренных заданием, либо включить их в ТЗ за доплату |
Оценка результата работ |
Проверка работы проекта по программе тестирования на соответствие требованиям задания |
Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ |
Обслуживание проекта |
Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта |
Выполнение работ с учетом обслуживания проекта в перспективе |
Выявление проблем |
Планируемые доработки проекта |
Доработка в соответствии с новыми потребностями |
Программист или команда разработчиков действуют «вслепую», несогласованно, не имея четкого представления о конечном результате проекта. Итогом будут зря потраченные время и деньги, испорченные отношения с заказчиком.
Результат проекта не соответствует ожиданиям заказчика. Потребуется дополнительный бюджет и время на доработки.
Заказчик не готов платить до 40% от стоимости проекта только за разработку задания. Например, можно еще до начала проектирования написать все тест-кейсы и заложить в ТЗ. Но в этом случае стоимость задания с тест-кейсами может превысить стоимость разработки, а его составление займет не один месяц. Зато это полностью снимает вопрос с ошибками в работе и упрощает приёмку.
Заказчик не знает всех деталей проекта до начала эксплуатации уже готового результата.
Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.
Исполнитель и заказчик не могут предвидеть заранее все возможные проблемы. Опытные участники проекта с обоих сторон могут заранее предусмотреть ряд типовых и уникальных проблем, но это не гарантирует, что вся работа над проектом пройдет гладко.
Например, забыли прописать в техзадании наличие одной кнопки, а после сдачи проекта оказалось, что без неё полноценно пользоваться системой нельзя. Для добавления же кнопки требуется переделать половину внутренней архитектуры базы данных, а значит и часть программного кода переписывать. Кто из сторон виноват в этой ситуации?
Большинство таких проблем решает Agile (гибкий подход к работе), но это не отменяет необходимость составления ТЗ. Используйте Agile при разработке любых проектов с высокой неопределённостью. Как правило, против этого выступают только заказчики, потому что они не видят точной границы цены и сроков. Зато финальный продукт гарантировано будет выполнять поставленные задачи - Agile в разы снижает число готовых проектов, которые были заброшены из-за того, что не выполняют своих функций.
Стороны должны понимать, что большинство проектов выполняется с большой долей неопределённости, и заранее договариваться, как будут взаимодействовать в случае возникновения проблем.
Задача:
Разместить на сайт www.site.name.ru
новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.
Описание:
/vash_konsultant.htm
site2@mail.ru
);/katalog.ru
).Если работы выполняются для целей SEO – не забывайте закладывать все необходимые элементы на странице.
Также внизу разместить форму заказа.
info@common.com
PS. Стоимость и сроки исполнения, как правило, указываются отдельно в приложении к договору. Исполнитель выставит стоимость работ, исходя из прописанных в техзадании задач. Чем больше пожеланий – тем больше будет стоимость.