Правильное техническое задание на разработку программного обеспечения – секрет успешного проекта. Техническое задание: законодательные требования и сложившаяся практика

Не хотите получить полное разочарование принимая сайт от разработчика? Тогда внимательно прочитайте эту статью!

Но возможно, всё же вины его нет? Ведь за результат любого делегирования отвечает не только исполнитель, но и заказчик.

Чтобы получить максимально желаемый результат нужно знать как правильно составить техническое задание для создания сайта.

ЗАЧЕМ НУЖНО ТЕХ ЗАДАНИЕ?

Исполнителю грамотное ТЗ на разработку сайта поможет заранее оценить объём работы, её сложность и стоимость. Понять, справится ли он с такой задачей самостоятельно, или стоит взять помощников. А затем сделать именно то, чего от него ждёт заказчик.
Заказчику техзадание даёт уверенность в том, что он задокументировал свои пожелания к будущему сайту, чётко обозначил сроки, в которые должен уложится исполнитель, прописал требования к работе сайта. И если результат окажется неудовлетворительным, можно предъявить обоснованную претензию: «Не соответствует ТЗ!»

О ЧЁМ ПИШУТ В ТЕХЗАДАНИИ?

В тех задании рассматриваются следующие вопросы:

Для чего и для кого создаётся сайт?
Чем он будет наполнен?
Как это всё будет функционировать?
Кто и как будет работать над проектом, кто за что отвечает?
Что будет приниматься на выходе?

ОСНОВНЫЕ РАЗДЕЛЫ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА РАЗРАБОТКУ САЙТА

1. Информация о заказчике, то есть о вас

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

2. Информация о проекте

Что это будет: сайт-визитка, блог, интернет-магазин, корпоративный портал, электронная библиотека?

3. Целевая аудитория сайта

Опишите вашу целевую аудиторию, расскажите что им нужно и как их можно заинтересовать.

4. Цели и задачи, которые должен решать сайт для заказчика и для аудитории

Вы должны чётко понимать, для чего вам нужен web сайт. Для повышения имиджа? Для прямых продаж? Для новостей? Вы хотите конвертировать посетителей в подписчиков с помощью сайта? Вы хотите сделать ресурс для привлечения потенциальных партнёров?

Указывайте прямое назначение вашего сайта.

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

5. Рамки проекта (основной функционал)

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

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

6. Структура (карта) сайта

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

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

7. Отдельные страницы

Пока вы рисуете карту сайта, каждая страница - это просто квадратик. Но исполнителю нужно понимать, что и в каком порядке на этом квадратике будет расположено (вспоминаем примеры таблиц в начале статьи). Какие там будут информационные блоки? На каждой ли странице будут меню, сайдбар (отдельный блок с навигацией) , футер (нижний блок) ? Хотите ли вы видеть на странице баннеры, картинки? Будут ли они статичные или движущиеся?

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

8. Требования к дизайну сайта

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

9. Рабочий функционал сайта

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

Какая форма? Для чего? Какие пункты в ней должны быть? Как она выглядит? Этих нюансов исполнитель может не угадать, в итоге вы получите совсем не то, что хотели. Деньги заплачены, проект соответствует ТЗ (вы же написали «календарь» - вот он), а вам придётся довольствоваться тем, что получилось, хотя это вовсе не то, чего хотелось, или переплачивать за изменения.

10. Описание контента

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

11. Технические требования

Сложный пункт для тех, кто мало понимает в сайтостроении.

Если не разбираетесь, включайте логику.

Например, ваш сайт должен:

одинаково хорошо смотреться на мониторах разной ширины (адаптивный дизайн);
быть СЕО оптимизирован для продвижения;
уметь противостоять вирусам;
иметь встроенный seo-функционал и так далее.

Пишите только о том, в чём вы уверены, или посоветуйтесь со специалистом. Лучше проконсультироваться заранее, чем потом переплачивать за доработки.

Если вы решили обратиться к нам и у вас нет своего техзадания, вы можете скачать и заполнить наш .

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

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

Если даже после прочтения ТЗ исполнитель делает что-то не так, значит, вам нужно пересмотреть свой подход к постановке задач. Даже самый крутой исполнитель, которого вы нанимаете на проект, сделает не то что вам нужно, если вы составили для него плохое техническое задание.

Чтобы написать хорошее ТЗ, вам необходимо представить себя на месте человека, которому оно адресовано. Проиллюстрируем эту мысль.

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

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

Что было плохо:

Мы писали список требований к иллюстрациям для анимации, не сопроводив эти требования примерами с картинками и видео. Это был просто текст вроде: “старайтесь рисовать гнущиеся элементы таким образом, чтобы энкор поинты суставов совпадали друг с другом”. Из-за того что мы поленились это проиллюстрировать, наш иллюстратор сделал то что нужно только с третьего раза.
Мы насыщали ТЗ слишком большим количеством примеров. Иллюстратор буквально тонул в изобилии работ, которые нам нравятся. Не было четкого стилистического ориентира.
Много текста. Мы писали лишнюю информацию о проекте. Эта информация никак не могла помочь иллюстратору сделать его работу.
Раскадровка с недостаточными пояснениями о том что будет происходить в слайде.
Доступность ТЗ только онлайн, на Гугл Диске.
Мы не имели четкого представления для кого пишем это ТЗ. Мы не вошли в роль этого человека для нашего проекта.

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

Проанализировав свои ошибки, мы поменяли подход к написанию технического задания. Наш последний проект получился очень легким на подъем, во многом это благодаря тому, что мы стали четче и обдуманнее ставить задачи. Мы значительно меньше времени стали тратить на дополнительные объяснения. ТЗ состояло из 43 страниц. Возможно, мы немного перестарались, но первые слова иллюстратора, после прочтения нового ТЗ, были такими:

Суть нашего нового подхода к написанию ТЗ свелась к следующему:

1. Очень кратко и емко нужно описать для кого этот проект, какие задачи нужно решить по окончанию проекта, и какую конкретную задачу решает человек, которого вы нанимаете на проект. Таким образом, он не будет работать вслепую, понимание “что” и “зачем” позволит ему предложить вам лучшие решения.

2. Сопроводить исполнителя всеми необходимыми материалами, которые нужны для работы: референсы, картинки и видео с объяснениями. Наш последний проект был посвящен работе кухонного прибора. В сети без проблем можно найти тысячи статей, картинок и видео о его работе. Мы сэкономили время иллюстратору и собрали самые очевидные и понятные картинки и видео. Это заняло у нас 15 минут. Но мы уверены что сэкономили гораздо больше времени на работу.

3. По пунктам четко и кратко написать все что требуется сделать, чтобы считать работу завершенной.

4. Любые технические требования теперь мы иллюстрируем и записываем видео . Тут важно побольше задавать вопросов себе: что в нашем пайплайне может быть непонятно? Что может породить дополнительные вопросы?

5. Теперь мы скидываем не только текст в формате Гугл Докс, но еще ссылку на скачивание PDF версии ТЗ, чтобы в случае неполадок с интернетом, ТЗ было под рукой.

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

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

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

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

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

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

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

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

7. Передать задание в работу за разумный срок до окончательной реализации, чтобы была возможность протестировать результат и исправить возможные ошибки.

8. Если ваши подчиненные также будут пользоваться созданным приложением, постарайтесь им самостоятельно объяснить особенности работы с приложением – это избавит IT-специалиста от необходимости сто раз объяснять одно и то же.

9. Помните, что ваше задание будет служить справочником для вас - в нем всегда можно посмотреть описание информации, вспомнить забытое требование.

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

При разработке любого проекта. Как оформляется этот документ? Об этом будет рассказано в статье.

Техническое задание - что это такое?

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

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

Зачем техническое задание заказчику?

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

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

Зачем техническое задание исполнителю?

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

Исполнитель должен уточнить все необходимые моменты и насчет суммы оплаты. Так, стоит убедиться, что денежные выплаты касаются только тех моментов, что оговорены в документе. В противном же случае невнимательные исполнители могут поработать бесплатно.

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

Начало составления документа

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

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

Требования и сроки

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

А что можно рассказать о требованиях? Заказчик должен помнить, что все требования делятся на два основных типа: специальные и функциональные. Функциональные требования являются в некоторой степени наглядными, образными. Это определенные изображения, элементы, зарисовки того, что заказчик хотел бы увидеть. Специальные же требования - жестко регламентированные, с указанием определенных задач и способов исполнения. Естественно, специальные должны значительно преобладать. В противном случае исполнитель может попросту не до конца понять, что же именно от него хотят.

Ответственность и отчетность

Еще о двух важнейших элементах, которые должны содержать абсолютно любые образцы технических заданий, стоит рассказать чуть подробнее. Речь идет об ответственности сторон и об отчетности. Что представляет собой каждый из этих элементов?

Отчетность желательно формировать поэтапно, в особенности если техническое задание большое. Как только был завершен определенный этап работы, можно подавать (требовать) отчетность. К тому же подобная система позволяет держать исполнителя в тонусе. В противном же случае он может сделать все в последний момент, а стало быть, крайне некачественно.

Что можно сказать об ответственности сторон? Сразу стоит отметить, что подобный пункт не является обязательным. Однако многие заказчики все же находят нужным регламентировать основные виды штрафов, наказаний и санкций за различные нарушения. Желательно указывать основные элементы ответственности в таких документах, как техническое задание на закупку, на транспортировку и т. д.

Составление технического задания

Любое техническое задание (на поставку, строительство, транспортировку и т. д.) необходимо очень грамотно и качественно оформлять. Это нужно, во-первых, для того, чтобы в дальнейшем не возникало судебных разбирательств, споров и конфликтов из-за недопонимания сторон. А во-вторых, для простого удобства. Грамотно оформить техническое задание способен далеко не каждый заказчик. Зачастую для этого дела нанимаются юристы, хотя в этом и нет особого смысла.

Просто стоит запомнить несколько простых правил:

договор должен быть детальным и подробным (однако преувеличивать не стоит; многотомные комментарии к требованиям вряд ли захочет читать хоть один исполнитель);
договор должен быть четким, без воды и лишних сведений;
задание не должно быть неким догматом; стоит помнить, что это лишь указание, хоть и строго регламентированное - будь то техническое задание на техническое обслуживание или на посадку деревьев.

Все те советы, что были даны выше - лишь малая часть из того, о чем можно было бы рассказать. Однако все еще можно дать заказчикам пару указаний. Так, техническое задание (на техническое обслуживание или на строительство) может быть построено по шаблону. При этом необязательно брать этот шаблон откуда-то; так, если написание договора на оказание услуг - довольно частая обязанность, то выстроить для себя пару клише будет не так уж и сложно.

Стоит напомнить и о том, насколько важно сверяться с нормами: будь то ГОСТ, нормативные или правовые акты, локальные акты и т. д.