Написать тз – Как составить техническое задание 🚩 для чего нужно техническое задание 🚩 Офисная жизнь

• онлайн-калькулятор;
• программу рассылки;
• анализатор статистики;
• парсер и так далее.

Или вы хотите создать какой-то уникальный сервис для пользователей.

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

Составление вакансии и ТЗ для программиста

Чтобы оставить объявление о поиске программиста-фрилансера, нужно сузить круг поиска. Для этого пишется объявление такого вида:

Требуется программист, чтобы добавить функцию X на готовый сайт на WordPress.

Из объявления фрилансер понимает, что от него требуется и сможет ли он это сделать. Но из него не ясно, какие плагины или наработки уже используются, поэтому нельзя сразу выявить уязвимости.

Когда вы определитесь с выбором исполнителя и обговорите все важные моменты, можно отправлять ТЗ. В нем должно быть:

1. Сроки, обговоренные с исполнителем, и ситуации, когда дедлайн можно подвинуть.
2. Способ и вариант оплаты. Например, на банковскую карту после принятия заказа.
3. Штрафы и правки.
4. Подробное описание того, как вы видите результат работы.
5. Техническая информация.
6. Тестирование

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

Желаемый результат

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

Допустим, вам нужен сервис проверки орфографии. Опишите все ваши представления:

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

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

Техническая информация

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

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

Идентификация сетевых ресурсов является важным подготовительным этапом перед осуществлением взлома. Если хакер знает, что ваш корпоративный портал работает под управлением IIS 7 под управлением Windows Server 2008, то ему необходимо найти уязвимости, которым подвержены данные программные продукты. Для этого проще всего поискать в базах уязвимостей. В случае если найти ничего не удалось, то особо продвинутый взломщик может попытаться самостоятельно найти «лазейку», собрав у себя точную копию взламываемой системы и попытавшись самостоятельно проанализировать код. «Информационная безопасность: защита и нападение», Бирюков А. А.

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

Программа должна отображаться на странице page.php, а исполнительный файл в файле core.php. Взаимодействие между файлами с помощью ajax. Все обработанные данные нужно записывать в таблицу data_table (My_SQL) со столбцами id, name и url.

Нельзя создавать функции и переменные с названиями: generate, crop и analyze. Иначе возможен конфликт.

Стандарты оформления кода

Разные люди по-разному пишут. Хороший пример – наш блог. В нем несколько авторов, у каждого из которых свой стиль. То же самое и с программистами.

Я спросил Ольгу Безматерных, руководителя отдела продаж «Текстерры», что она думает по поводу работы с чужим кодом. Она ответила, что он замедляет выполнение задач, а один раз в ее практике был случай, когда работать с кодом было невозможно – пришлось вернуть деньги.

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

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

Переменные можно называть по-разному: $aB, $ab, $a_b, $A и так далее. Если это незначительно, добавлять комментарии критически важно. Без них в коде тяжело ориентироваться, даже если его писали вы, но отложили на неделю.

Поэтому, чтобы потом эту программу легко мог исправить любой другой программист, нужно чтобы у нее был какой-то стандартизированный вид. Доверить составление стандартов можно первому программисту, с которым вы работали.

Подключение и тестирование

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

Заключение

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

Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика

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

Ожидаемая длительность проекта, фактически, является одним из факторов дрейфа требований. За долгий срок даже в достаточно неповоротливой компании может многое измениться, например, появиться новое руководство с новым видением. Если же, напротив, проект небольшой и быстрый, то оптимальный вариант – разработать, согласовать и реализовать одно небольшое и достаточно детальное ТЗ.

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

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

Компании работают в реальной среде и часто им приходится иметь дело с новыми партнерами, с которыми ранее они не работали. Это же относится и к разработчикам ИТ-решений. Конечно, хорошо иметь исполнителя, который отлично знает все детали вашего бизнеса, понимает вас с полуслова и в котором вы уверены на все 100% (в этом случае от разработки ТЗ, вообще, можно отказаться), но в реальности это может оказаться совершенно неизвестная вам компания. В таком случае, конечно же, целесообразно начинать сотрудничество с небольших, по-возможности, проектов и с четких и детальных формулировок требований, указанных в ТЗ.

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

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

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

По своему опыту могу порекомендовать обратить внимание исполнителя на необходимость рассмотрения в ТЗ в числе прочих следующих вопросов:

Категории (роли) пользователей, работающих с системой – перечислить роли и кратко описать каким должностям из каких подразделений они соответствуют.
Функционал системы – составить иерархическую структуру, в которой на верхнем уровне перечислены крупные модули (подсистемы), далее детализируемые до более мелких функциональных блоков и даже отдельных функций.
Модель использования системы – сопоставить категории пользователей системы и используемые ими функциональные блоки, обозначенные выше.
Сценарии использования системы при выполнении основных бизнес-процессов – наложить видение решения на реальные процессы, описать на каких этапах и каким образом оно будет использоваться. Не пожалейте времени на то, чтобы совместно с исполнителем наглядно схематически разрисовать сценарии хотя бы по основным бизнес-процессам и согласовать их с заинтересованными лицами.
Прототипы пользовательского интерфейса – схематически изобразить, например, при помощи Microsoft Visio как будут выглядеть основные формы вашего будущего ПО.
Логическая модель данных – изобразить основные сущности предметной области и взаимосвязи между ними. Это позволит вам и исполнителю разговаривать на одном языке с использованием общей терминологии.
Источники данных и взаимодействие с другими системами – описать откуда будут загружаться первоначальные данные при внедрении системы и из каких внешних источников они будут поступать впоследствии.
К рассмотрению этих вопросов в ТЗ стоит подходить «без фанатизма» с учетом возможной неопределенности требований, описанной выше. Детальную их проработку можно оставить на более поздние этапы создания системы, но если вы хотя бы в общих чертах остановитесь на них при разработке ТЗ, то заставите исполнителя и себя лучше подумать над решением, которое пока еще существует только на бумаге и переделка которого пока еще не сопряжена с глобальными финансовыми и временными затратами.

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

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

С чего начать писать тех.задание? — Хабр Q&A

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

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

Дело ИТ-шника понять и перевести на технический язык. Но ни в коем случае не самому описывать бизнес-процессы. Бизнес процесс должен описать тот, кто этим занимается.

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

На самом деле ТЗ не всегда нужно.

Если заказчик согласен вечно платить почасовку — можно без ТЗ.
Это позволяет сэкономить кучу времени и быстро подстраиваться под изменения бизнеса.

Но это возможно только если заказчик может и согласен платить без ограничений.
Такое возможно, если сумма денег которые тратят на исполнителя — для заказчика копейки.
Или заказчик безоговорочно доверяет исполнителю (и исполнитель по карману заказчику)

Есть еще вариант —
делается примитивный прототип MVP
https://en.wikipedia.org/wiki/Minimum_viable_product
По нему оценивают и тех. задание составляют/уточняют.
Но делать такие вещи обычные заказчики отказываются,
только те, кто работает с большими и дорогими вещами — согласны.
Это серьезно уменьшает их риски.

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