Как написать тз для программиста приложений
190 оценок средняя 4,90 из 5
Составление и обсуждение ТЗ с программистом до принятия его в работу является важным этапом разработки и жалеть свое время на это стоит. Неправильно написанное техническое задание может в будущем стоить вам лишних денег и времени.
Занимаясь SEO-продвижением сайта, очень часто приходится сталкиваться с необходимостью доработки сайта, добавлением на него отсутствующего функционала. Например, с необходимостью написать программу рассылки, разработки виртуального калькулятора, или же попросту добавления страницы «Спасибо!», выводящейся после оформления клиентом заказа.
Чтобы программист правильно понял задачу и корректно выполнил ее, необходимо составление технического задания (ТЗ). Технического задание представляет собой документ, где подробно описывается перечень главных требований, которые должны быть грамотно выполнены.
Перед тем, как начинать писать техническое задание, рекомендуем для начала поискать готовые решения вашей задачи, которые можно использовать уже сейчас. Возможно, покупка такого решения будет стоить вам дешевле, чем разработка его с нуля.
Если все же нужно продумать и написать нужный функционал самостоятельно, тогда потребуется обращение к программисту. Именно в таком случае и нужно составление ТЗ для программиста, которое позволит дополнить процесс проектирования.
Если будете знать, как составить ТЗ, и оно будет составлено корректно, то программисту тоже будет значительно легче понять и выполнить требования заказчика. В процессе разработки и создания ТЗ необходимо максимально подробно описывать каждый пункт, чтобы у исполнителя не возникало лишних вопросов. Одни не верно истолкованный пункт техзадания может повлиять на окончательный результат. Составление и обсуждение ТЗ с программистом до принятия его в работу является важным этапом разработки и жалеть свое время на это стоит. Неправильно написанное техническое задание может в будущем стоить вам лишних денег и времени.
Для чего вообще должно быть составлено ТЗ
Многие владельцы сайтов или ответственные лица за его поддержку проекта не понимают почему разработчики требуют с них письменного составления технического задания, ведь все можно обсудить на словах. Считается, что составление такого задания, лишь пустая трата времени. Однако, не все так просто, и действительно лучше писать техзадание, предоставляя документ, согласно которому в дальнейшем будет приниматься работа.
Давайте на примере рассмотрим, почему стоит ответственно отнестись к созданию и разработке технического задания, которое четко расскажет исполнителю о задаче и функционале нужной разработки. Опишите подробнее цель задачи и с большей вероятностью она будет достигнута.
- Далеко не всем задачам можно дать простое объяснение. Исполнителям становится непонятно, что от них желают получить в конечном итоге. В этом случае, лучше будет расписать все по пунктам. Опишите подробно, и тогда исполнителям станет значительно легче;
- Также бывает ситуациям, когда исполнителям приходится совершать задания, они думают, что делают все верно. Но для заказчика все неверно, он хотел другого, и работа оказывается потрачена впустую, не выполняя основных требований. И тогда, не только не достигнута нужная цель, но и следует невыполнение необходимых и важных требований. Именно поэтому так и важно создание задания, которое поможет исполнителям все делать верно, исходя из требований заказчика;
- В итоге возникает спор, где правой оказывается каждая из сторон. Для заказчика важно получить то, что он хочет, но он этого не получил. Исполнитель сделал все, исходя из требований, но остальное в стоимость не входило. В итоге, поскольку не смогли поделиться информацией, появились пострадавшие. А если бы был необходимый документ, то таких бы ошибок можно было бы избежать.
Именно поэтому, и нужно позаботиться о том, чтобы составление ТЗ произошло вовремя, следовательно, не нужно лениться его писать для программиста.
Что собой представляет составление ТЗ для программиста
Если посвятить достаточно времени разработке ТЗ, можно будет получить следующие преимущества:
- Можно сэкономить больше времени на переделывание, доработку.
Чем большей информацией будет располагать исполнитель, тем лучше он поймет требования заказчика. Даже если вам кажется, что задача предельно проста, все равно описывайте ее максимально подробно, по пунктам. Ведь даже красная кнопка может оказаться не такого оттенка, какого вы ожидали.
- Вы получите результат максимально приближенный вашим ожиданиям.
Потратьте время на поиски и предоставления примеров реализации вашей задачи на других сайтах. Наличие таких примеров техническом задании значительно повышают шансы получить в конечном итоге решение, соответствующее вашим требованиям.
- У программиста не будет возможности уйти от требований, описанных в ТЗ.
Техническое задание фиксирует все ваши требования к конечному результату, и исполнитель будет обязан выполнить все по пунктам. Если программист начнет говорить, что предъявляемых вами требований не было, можно будет просто сослаться на документ, где есть общее описание задачи.
Так что если вы представите ТЗ, то правда, однозначно, окажется на вашей стороне. И если в создании сайта, будут упущения программиста, тогда он обязан будет внести доработки бесплатно и без лишних разговоров. Главное, чтобы такой документ действительно был, отвечал поставленным задачам, описание следовало по пунктам. Таким образом, проекты, направленные на создания сайта, будут делаться лучшим образом.
Кто именно обязан создать подходящее ТЗ
Собственно, не имеет значения, кто именно будет заниматься разработкой технического ТЗ. Такая работа может выполняться как клиентом, так и исполнителем. Если вы новичок и у вас нет опыта составления такого документа – не страшно.
Давайте рассмотрим по пунктам, каким именно должно быть ТЗ. Описание задания не должно быть создано как попало, иначе это не принесет ничего кроме проблем для будущего сайта.
- Описание технического задания должно быть максимально удобным и понятным. Нельзя говорить, что на сайте должна быть удобная навигация, это слишком расплывчато. Ведь у каждого имеется свое представление о том, что должно быть удобным. Тоже самое, можно сказать и про красивый и современный дизайн сайта. Здесь тоже свое видение, которое может на совпадать с видением клиента;
- Важно оформлять структуру ТЗ. Оформление технического задания, лучше делать в виде списка, а не использовать сплошной текст. Хорошо, если работа будет еще содержать важные подпункты, что позволят понять, что для сайта самое важное. Структура технического задания позволит легче понять задачу, что стоит перед обеими сторонами;
- Конечно же, наличие технического задания должно быть полноценным и подробным. Такие проекты не вызывают лишних вопросов, как единые системы. И чем лучше продумана работа, тем полноценней будут системы сайта.
Так что, если готовите ТЗ для сайта, нужно заранее позаботиться о том, чтобы все было сделано именно так, как нужно. Благодаря этому, проекты, в результате будут именно такими, как это нужно.
от прототипа до настройки аналитики
Рассматривает проекты по ТЗ, не забывайте системы сайта, которые они должны выполнять.
- Обязательно укажите, чего желаете достигнуть, то есть, цель, задачи, которые нужно решать. Они могут быть первостепенные и второстепенные, уже в зависимости от пожеланий;
- Как уже говорилось выше, нужно подробное описание, что нужно сделать и каким образом. Излагайте расширено, даже деталей не упускайте;
- Какие есть способы реализации. Если не знаете нужные термины, тогда можно пояснить все что нужно, обычными словами. Термины можно применять только тогда, когда без них невозможно обойтись.
Как видите, не так много нужно знать, чтобы составить качественное ТЗ. Но все равно, никак без ответственного подхода не обойтись, так что внимание тут обязательно.
Что можно сказать в заключение
Конечно же, даже если правильно и подробно составить техническое задание, это все равно может не до конца избавить от проблем, когда выполняются задачи. Но зато это предоставит отличную возможность изначально рассмотреть все детали, не повторять обсуждения, фиксируя те решения, что уже приняты. Именно благодаря ТЗ можно избавиться от определенного ряда проблем, вопросов, что не нужны и неуместны. Но есть главное условия: составляя ТЗ, необходимо знать и понимать ту задачу, которую ставят и расписывают.
Компьютерные игры — относительно молодая отрасль, которая в перспективе сменит киноиндустрию, так-же как кинофильмы заменили театр. Создание игры — это коллективное творчество, во многом напоминающее создание кинофильма. Кроме того, создание компьютерных игр — одна из самых сложных IT задач, поскольку она включает все себя практические все IT области.
Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.
Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.
Я намеренно оставил за кадром другие документы: концепцию, экономическое обоснование и ТЗ для других исполнителей. Это позволило сфокусироваться на одной теме и осветить ее и только ее достаточно подробно.
Самое важное:
- Четкое понимание конечного результата. (Контроль качества.)
- Сроки исполнения.
Зачем нужна документация:
Какие бывают документы:
- Концепция («Про че игра?»)
- Спецификация (Что мы хотим получить?)
- Техническое задание (Как это устроено — именно о нем будет идти речь.)
- План работ (Как мы это будем делать.)
Кто участвует в обсуждении ТЗ:
- Геймдизайнер (Написание документации)
- Архитектор (Отслеживание полноты и подробности описания, декомпозиция.)
- Программист (Оценка объемов работ.)
Требования к оформлению документации:
- Форматирование. (Легко напечатать и приятно читать/держать в руках)
- Выделение ключевых фраз. (Для чтения документа по диагонали)
- Составление списков. (Вместо сплошного текста)
- Разбиение длинных списков по группам. (По три пункта в группе)
- Многократные повторения. (Избегать ссылок по документу)
- Дата, номер страницы, количество страниц, нумерация пунктов. (Для точных ссылок при обсуждении прочитанного)
- Оглавление, список документов, история изменений. (Для поиска по документации/версиям)
Требования к содержанию ТЗ
- Русский язык. (Никаких мемов, искаженных аглийских терминов, албанского языка и прочего мусора. Даже внутреннюю документацию читают очень многие.)
- Никаких общих слов типа:
- все возможные варианты
- карта придумывается компьютером
- взаимодействие различных объектов
- после всех действий и т.д.
- Все названия видов сущностей(классов) должны иметь:
- русское название (для игрока)
- английское (для кода)
- краткое описание (расшифровка/подсказка/комментарий)
- Сущность должна иметь только одно название. (Чтобы “броня” не превращалась на другой странице в “армор” или “щит”).
- Предложения должны быть полными и понятными читателю без пристального изучения контекста. (Не надо подразумевать, что читатель сам догадается до того, что подразумевал автор)
- Все что можно измерить, должно быть измерено.
- размеры картинки в пикселях и байтах
- количество столбцов и клеток в таблице
- количество символов в текстовом поле
- количество оружия на уровень
- время сессии и т.д.
Главные требования к результату работы программиста:
- Гибкость системы к изменениям. (Динамические требования.)
- Автоматический сбор данных об ошибках. (Обратная связь.)
- Простота запуска и настройки заказчиком. (Демонстрация результата.)
Первый этап написания ТЗ:
Описание предметной области, ее формализация в понятных программистам терминах.
Бывает так, что сайт уже готов, а в нем отсутствует какая-нибудь важная функция: программа рассылки, онлайн-калькулятор, нет нужных полей в CMS и пр. Когда после этого заново просматривается техническое задание к этому проекту, то вдруг выясняется, что эти функции просто не были включены в техзадание. Чтобы этого не случилось, в данной статье подробно опишется, как грамотно составить ТЗ для программиста, чтобы в будущем не было никаких проблем.
ТОП-10лучших компаний интернет-продвижения России 2020
Структура ТЗ
Для того, чтобы грамотно составить техническое задание программисту, необходимо правильно обозначить структуру. Выделим основные разделы, которые в любом случае должны присутствовать в ТЗ.
Определение цели проекта
Без четкого понимания конечной цели невозможно создать качественный продукт, который полностью устроил бы заказчика. Поэтому, чем лучше будет поставлена цель работы перед разработчиком, тем предпочтительней будет полученный конечный результат.
Для разработчика четко сформулированная цель всего проекта дает полное понимание всей сути поставленной задачи. Для заказчика цель работы дает осознание всех задач, которые решаются по мере продвижения работы.
Полный бюджет проекта
Для исполнителя бюджет проекта, написанный в техническом задании, на начальном этапе дает согласованный с работодателем учет всех его работ. В некоторых случаях, после обоюдного согласования трудовых затрат, происходит корректировка конечной стоимости проекта. Заказчику полный бюджет в ТЗ дает понимание, сколько всего денежных средств надо будет заплатить разработчику. И уже на этих данных он может планировать свой бюджет.
Перечень необходимых работ
Без полного перечня планируемых работ невозможно представить ни одного грамотного техзадания. Он должен быть удобным в понимании и составлен в виде пунктов.
Для исполнителя список работ нужен для понимания, по какой технологии ему следует выполнять задание, какой программный код использовать. Также перечень пунктов в какой-то мере является его гарантом, если вдруг по окончании проекта заказчику что-то не понравилось. Всегда можно открыть техническое задание и увидеть, была ли включена данная работа в условный перечень.
Также у программистов по ходу проекта всегда имеется возможность отказаться от каких-либо заданий, которые не были предварительно включены в список. Или включить их все-таки в ТЗ, но за дополнительную плату. Работодателю перечисленный список работ дает подробное понимание выполняемых заданий на каждом конкретном этапе.
Тщательно описывается готовый продукт
В техническом задании программисту в обязательном порядке должен быть пункт, в котором было бы подробное описание конечного продукта. Для исполнителя данный раздел дает уверенность в правильном понимании итогового результата. Заказчику описание продукта также нужно для полного представления о готовом проекте.
Оценивание результата проекта
Оценка результата может быть предварительной, когда она производится после каждого этапа проделанных работ, или итоговой, уже после окончательного завершения проекта. Оценивание делается при помощи специализированных программ тестирования. Сравнивается полученный результат с требованиями задания для программиста.
Для исполнителя этот пункт ТЗ нужен для того, чтобы он на любом этапе работы имел возможность убедиться в том, что проект соответствует всем нужным требованиям технического задания. Заказчику оценка работ необходима для понимания того, что вложение денег в проект было сделано не зря.
Сроки выполнения работ
Не может быть ТЗ без срока выполнения заказа. Да, бывают ситуации, когда изначально очень тяжело определить весь фронт работ. Или по мере выполнения штатных задач над проектом появляются форс-мажорные обстоятельства, которые вынуждают сдвигать конечные сроки выполнения работы. Но, в любом случае, хотя бы предварительное время работы над проектом должно быть.
Исполнителям срок исполнения заказа позволяет уже на начальном этапе объективно оценить свои потребности в ресурсах и трудозатраты (часы работы). Для заказчика – полное ориентирование в сроках работы, что позволяет планировать все свои остальные проекты. Часто бывает, что работа для данного ТЗ является только составной частью какого-то большого проекта. И он не может дальше продвигаться, пока не будет выполнена эта конкретная работа.
Будущее обслуживание проекта
Всегда, даже после самого удачного проекта, по прошествии некоторого времени, могут обнаруживаться ошибки («баги»), которые следует незамедлительно исправлять. Поэтому, в любом техническом задании, все запланированные работы должны учитывать будущее обслуживание сайта в перспективе.
Исполнителю этот перечень работ дает представление о будущей нагрузке, которая будет присутствовать в связи с дальнейшим обслуживанием. Для заказчика данный пункт в ТЗ дает информацию, которая позволяет планировать затраты на будущую поддержку сайта.
Выявление проблем
В этот пункт техзадания входят работы, которые могут возникнуть при форс-мажорных обстоятельствах. Для того, чтобы грамотно составить данную часть ТЗ, нужно знать самые слабые места сайта, и уже на основе этих знаний заранее предугадать возникновение будущих неполадок.
Обычно, пункт по выявлению проблем составляется заказчиком совместно с программистом или группой программистов, которые пишут код. Они, как никто лучше знают все «узкие» места проекта.
Пример ТЗ для программиста
Приведем реальный пример технического задания для веб-разработчика на тему: «Доработка полей в CMS». Это ТЗ содержит следующие пункты с заданием:
- Цель проекта: доработать поля в CMS.
- Исходная информация. Произошла путаница с тем какое поле за что отвечает, в каком шаблоне, какой функционал. В итоге, слетела оптимизация этих элементов. Далее подробнее.
- Описание. Есть 2 типа страниц: записи и страницы.
Сриншот 1
Скриншот 2
Скриншот 3
Какие поля нужны / что нужно выводить:
- Тег title - заголовок окна браузера
- Тег meta description - описание страницы
- Тег h1 - заголовок (основной) на странице
- Название страницы в хлебных крошках
- Название в меню на сайте
- Название страницы в админке
- Тег title.
- Тег meta description.
- Тег h1.
- Название страницы в хлебных крошках.
- Дать им понятные названия (чтобы однозначно понимать что должно делать это поле).
- Сгруппировать их на странице редактирования.
Названия для полей:
- Тег title - заголовок окна браузера.
- Тег meta description - описание страницы.
- Тег h1 - заголовок (основной) на странице.
- Название страницы в хлебных крошках.
- Название в меню на сайте - уточнить откуда берется.
- Название страницы в админке - уточнить откуда берется.
Нужно, на странице редактирования, указанные выше поля:
- разместить рядом друг с другом;
- в указанной выше последовательности;
- присвоить им, указанные названия.
Область для размещения полей:
Скриншот 4
- Оценка задачи. Необходимо . рабочих дней работы одного разработчика.
- Бюджет . рублей.
Основные рекомендации и пояснения по написанию ТЗ
Каждое ТЗ для программиста является уникальным, но общие советы применимы ко всем заданиям. Вот главные рекомендации по написанию технического задания для программиста:
- Чем больше сам проект, тем больше людей задействуются в нем, техзадание соответственно увеличивается в объеме.
- Если нужно, то в техническом задании должны быть ссылки и скриншоты на необходимые элементы функций и интерфейса разработки с подробнейшими обоснованиями.
- Техническое задание должно быть понятным и удобным для восприятия. ТЗ нельзя присылать программисту в виде бесформенного «полотна», оно должно быть разбито на пункты. Все этапы проекта и подпункты по самым неважным на первый взгляд работам также должны быть внесены.
- Следует ставить реальные сроки работ. В них также необходимо включать время на согласование проектной документации между разработчиком и заказчиком.
- В ТЗ должна быть только четкая формулировка. Много проектов «заваливалось» или срывались его сроки выполнения только из-за того, что заказчик не смог нормально поставить конкретные технические условия.
- Заказчик должен писать в ТЗ, может ли программист применять прототипы, если в задании отсутствует дизайн для страниц.
Главные ошибки при составлении ТЗ
Каким бы грамотным специалистом не составлялось техническое задание для разработчика, все равно, фактически в каждом написанном ТЗ, имеются типовые ошибки. Рассмотрим самые основные из них:
Техническим заданием называется служебный документ с описанием правил выполнения работы и требований к исполнителю.
Почему важно зафиксировать весь процесс работы в виде технической документации?
- В ТЗ прописаны договоренности между исполнителем и заказчиком, которые сложно выразить в договоре из-за использования специфической IT-терминологии.
- Это сэкономит время на коммуникациях: зафиксированные технические решения избавят от многочисленных пересказов, подтверждений, путаницы в показаниях.
- Документ позволит четко разделить зоны ответственности между сторонами проекта.
- ТЗ дает возможность проанализировать будущий проект и выявить проблемы на стадии планирования.
- Правильно составленное задание сделает поведение всех участников работы предсказуемым и избавит от возникновения многочисленных недоразумений.
- С юридической точки зрения, наличие этого документа облегчит сторонам разрешение спорных моментов.
- Техзадание делает возможным финансовое планирование, что является залогом успешного бизнеса. Заказчику будет заранее видно, на что расходуются его средства.
У каждого проекта должны быть обозначены границы - по стоимости, объему выполняемых работ, срокам исполнения и качеству. Все это должно быть зафиксировано в ТЗ.
Если одна из сторон хочет сотрудничать без техзадания
Это может означать следующее:
Заказчик не устанавливает четких требований специально, чтобы затем получить часть работ бесплатно, либо он не уверен/не знает/не решил/не понимает, что ему надо.
Разработчик надеется на постоянное продолжение работ за счет заказчика, аргументируя это некой неопределенностью.
В такой ситуации противоположная сторона должна обязательно настоять на создании технического задания с четкими границами и определением задач. Без этого сторонам будет трудно доказать, что работы были сделаны, или, наоборот, не сделаны должным образом.
Участники проекта
| Заказчик | Менеджер проекта | Разработчики |
|---|---|---|
| Ставит задачу | Ставит задачу разработчикам | Выполняют задание в соответствии с ТЗ |
| Согласовывает ТЗ | Контролирует ход работы и расставляет приоритеты | |
| Принимает работу | Осуществляет взаимодействие с заказчиком и разработчиком | |
| Тестирует выполненную работу (если нет тестировщиков) |
Если проект большой, дополнительно могут добавиться участники:
- Product Manager
- Руководитель проекта
- Спонсор проекта
- Тестировщики
- Технические писатели
- Кураторы
- Пользователи/потребители (например, для финального тестирования)
- И др.
Если проект маленький, то заказчик и исполнитель, как правило, работают напрямую. В этом случае тестирование берёт на себя заказчик, а разработчик сам контролирует сроки и ставит приоритеты.
Что дает сторонам каждый раздел ТЗ:
Раздел ТЗ
+ Для Заказчика
+ Для Разработчика
Осознание задач, которые решает проект или его доработка
Понимание сути задачи
Представление о том, каким будет готовый продукт
Уверенность в правильном понимании конечного результата
Ориентирование в сроках работ и получения планируемых результатов
Оценка трудозатрат и потребности в ресурсах
Определение более-менее точной суммы затрат и планирование бюджета
Согласованный учет всех работ проекта
Подробное описание работ и каждого этапа реализации проекта
Ведение работ по установленной технологии. Возможность отказаться от работ, не предусмотренных заданием, либо включить их в ТЗ за доплату
Оценка результата работ
Проверка работы проекта по программе тестирования на соответствие требованиям задания
Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ
Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта
Выполнение работ с учетом обслуживания проекта в перспективе
Планируемые доработки проекта
Доработка в соответствии с новыми потребностями
Последствия составления некачественного задания
Программист или команда разработчиков действуют «вслепую», несогласованно, не имея четкого представления о конечном результате проекта. Итогом будут зря потраченные время и деньги, испорченные отношения с заказчиком.
Результат проекта не соответствует ожиданиям заказчика. Потребуется дополнительный бюджет и время на доработки.
Обычно разработке качественного ТЗ мешают следующие моменты:
Заказчик не готов платить до 40% от стоимости проекта только за разработку задания. Например, можно еще до начала проектирования написать все тест-кейсы и заложить в ТЗ. Но в этом случае стоимость задания с тест-кейсами может превысить стоимость разработки, а его составление займет не один месяц. Зато это полностью снимает вопрос с ошибками в работе и упрощает приёмку.
Заказчик не знает всех деталей проекта до начала эксплуатации уже готового результата.
Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.
Исполнитель и заказчик не могут предвидеть заранее все возможные проблемы. Опытные участники проекта с обоих сторон могут заранее предусмотреть ряд типовых и уникальных проблем, но это не гарантирует, что вся работа над проектом пройдет гладко.
Например, забыли прописать в техзадании наличие одной кнопки, а после сдачи проекта оказалось, что без неё полноценно пользоваться системой нельзя. Для добавления же кнопки требуется переделать половину внутренней архитектуры базы данных, а значит и часть программного кода переписывать. Кто из сторон виноват в этой ситуации?
Большинство таких проблем решает Agile (гибкий подход к работе), но это не отменяет необходимость составления ТЗ. Используйте Agile при разработке любых проектов с высокой неопределённостью. Как правило, против этого выступают только заказчики, потому что они не видят точной границы цены и сроков. Зато финальный продукт гарантировано будет выполнять поставленные задачи - Agile в разы снижает число готовых проектов, которые были заброшены из-за того, что не выполняют своих функций.
Стороны должны понимать, что большинство проектов выполняется с большой долей неопределённости, и заранее договариваться, как будут взаимодействовать в случае возникновения проблем.
Техзадание должно отвечать на вопросы:
- Что? (какие работы, содержание элементов)
- Где? (расположение элементов)
- Когда? (последовательность выполнения и установленные сроки работ)
- Как? (технология реализации, оформление, принцип работы.) Как правило, у любого объекта должны быть функции: добавления, отображения, редактирования, удаления. А также описаны зависимости и взаимодействия с другими объектами. Иногда добавляются функции модерации, валидации, автообновления, архивации и т.п.
- Откуда? / Куда? (при переносе и т. п.)
- Зачем? (обоснование работ, если задание будет согласовываться с 3-м лицом)
- Особенности.
Основные рекомендации и пояснения по написанию ТЗ
- Чем больше масштаб проекта, тем более объемным должно быть техническое задание.
- Необходимо указывать реально осуществимые сроки выполнения работ с учетом времени на согласование проектной документации и приемо-сдаточных мероприятий. Стоит обратить внимание на ответственность заказчика за бездействие с его стороны или на форс-мажоры, тормозящие выполнение работ.
- Программисту нужны четкие условия. Формулировки “как вариант”, “примерно”, “около”, “где-то рядом”, “там, где лучше по вашему мнению”, - неприемлемы. Требования и характеристики, которые носят субъективный характер, бессмысленны с практической и ошибочны с юридической точек зрения.
- Чтобы сделать задачу по созданию какого-либо функционального модуля понятной для программиста, в техзадании размещают гиперссылки на те страницы, где есть нужные элементы интерфейса и функции, и дают к ним подробные пояснения. Также прилагают скриншоты с выделением интересующего фрагмента.
- Если дизайна для страниц нет или он не так важен для заказчика, программист может использовать прототипы, о чем после согласования указывается в задании.
- ТЗ должно быть удобным и понятным для всех сторон проекта, подробно описывать все этапы и подпункты даже по самым незначительным работам. Программист и менеджер не всегда имеют представление о том, что необходимо заказчику, поэтому важно своевременно обнаружить и согласовать все несогласованные детали.
7 типовых ошибок
- Нечеткие цели и задачи.
- Мало деталей в технической информации.
- Размытые или неустановленные сроки.
- Нет согласованности по всем вопросам между сторонами.
- Нет регламента взаимодействия.
- Нет ответственных лиц.
- Нет критериев оценки результата.
Пример правильного технического задания на доработку проекта
Описание:
Если работы выполняются для целей SEO – не забывайте закладывать все необходимые элементы на странице.
Также внизу разместить форму заказа.
PS. Стоимость и сроки исполнения, как правило, указываются отдельно в приложении к договору. Исполнитель выставит стоимость работ, исходя из прописанных в техзадании задач. Чем больше пожеланий – тем больше будет стоимость.
Бывает, что сайт уже готов, но нужно добавить на него какую-нибудь программу:
- онлайн-калькулятор;
- программу рассылки;
- анализатор статистики;
- парсер и так далее.
Или вы хотите создать какой-то уникальный сервис для пользователей.
В таких случая не всегда получается воспользоваться готовыми решениями и приходится нанимать программиста.
Составление вакансии и ТЗ для программиста
Чтобы оставить объявление о поиске программиста-фрилансера, нужно сузить круг поиска. Для этого пишется объявление такого вида:
Требуется программист, чтобы добавить функцию X на готовый сайт на WordPress.
Из объявления фрилансер понимает, что от него требуется и сможет ли он это сделать. Но из него не ясно, какие плагины или наработки уже используются, поэтому нельзя сразу выявить уязвимости.
Когда вы определитесь с выбором исполнителя и обговорите все важные моменты, можно отправлять ТЗ. В нем должно быть:
- Сроки, обговоренные с исполнителем, и ситуации, когда дедлайн можно подвинуть.
- Способ и вариант оплаты. Например, на банковскую карту после принятия заказа.
- Штрафы и правки.
- Подробное описание того, как вы видите результат работы.
- Техническая информация.
- Тестирование
Первые три пункта стандартны для любого договора подряда, а вот последние три можно разобрать подробно.
Желаемый результат
Чтобы при принятии готовой программы не было разногласий, лучше подробно описать, что вы хотите получить.
Допустим, вам нужен сервис проверки орфографии. Опишите все ваши представления:
- в какое поле пользователь может вставлять текст;
- должен ли он проверяться в режиме реального времени;
- как будут выделяться ошибки;
- будут ли комментарии к ошибкам;
- будет ли ограничение на объем или количество попыток.
- какой объем текста можно проверить за один раз или за один день;
- как пользователи будут оплачивать дополнительные попытки или объем;
- какие бонусы будут получать пользователи;
- нужно ли измерять грамотность текста в баллах;
- нужно ли сохранять текст в базу данных и так далее.
Такая скрупулезность может показаться муторной или даже излишней, но она обезопасит и вас и программиста.
Техническая информация
Вы должны предоставить техническую информацию, которая необходима для выполнения этой конкретной программы, но не более. Это легко, если ваш сайт создан на каком-нибудь распространенном движке – вы просто указываете название движка и плагины, с которыми должна взаимодействовать новая программа.
С самописными сайтами или движками сложнее. Тут вы можете либо не давать вообще никакой информации, кроме языка, чтобы программист составил только саму программу. А вы потом самостоятельно добавите ее на сайт, если разбираетесь в вопросе, но это чревато тем, что результат будет криво работать.
Идентификация сетевых ресурсов является важным подготовительным этапом перед осуществлением взлома. Если хакер знает, что ваш корпоративный портал работает под управлением IIS 7 под управлением Windows Server 2008, то ему необходимо найти уязвимости, которым подвержены данные программные продукты. Для этого проще всего поискать в базах уязвимостей. В случае если найти ничего не удалось, то особо продвинутый взломщик может попытаться самостоятельно найти «лазейку», собрав у себя точную копию взламываемой системы и попытавшись самостоятельно проанализировать код. «Информационная безопасность: защита и нападение», Бирюков А. А.
Если хотите, чтобы новый сервис сразу был добавлен на сайт, можете указать данные об используемых файлах, базе данных, языке, библиотеках и названиях функций. Вот пример:
Программа должна отображаться на странице page.php, а исполнительный файл в файле core.php. Взаимодействие между файлами с помощью ajax. Все обработанные данные нужно записывать в таблицу data_table (My_SQL) со столбцами id, name и url.
Нельзя создавать функции и переменные с названиями: generate, crop и analyze. Иначе возможен конфликт.
Стандарты оформления кода
Разные люди по-разному пишут. Хороший пример – наш блог. В нем несколько авторов, у каждого из которых свой стиль. То же самое и с программистами.
Я спросил Ольгу Безматерных, руководителя отдела продаж «Текстерры», что она думает по поводу работы с чужим кодом. Она ответила, что он замедляет выполнение задач, а один раз в ее практике был случай, когда работать с кодом было невозможно – пришлось вернуть деньги.
Поэтому если над проектом работает несколько человек, нужно составить стандарты оформления кода – что-то вроде редполитики для программистов.
Переменные можно называть по-разному: $aB, $ab, $a_b, $A и так далее. Если это незначительно, добавлять комментарии критически важно. Без них в коде тяжело ориентироваться, даже если его писали вы, но отложили на неделю.
Подключение и тестирование
Перед подключением программы лучше проверить код на наличие лазеек – предумышленных или нет. Если их нет, можно подключать. Дальше идет тестирование и открытие доступа для всех пользователей.
Заключение
Составление технического задания для программистов должно быть предельно точным. Это не тот случай, когда можно надеяться на взаимопонимание. Также лучше продумать все с самого начала, потому что постоянные изменения вектора не только не ускоряют путь к цели, но и делают его дороже.
В Google и «Яндексе», соцсетях, рассылках, на видеоплатформах, у блогеров
Читайте также: