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

Пишем техническое задание программисту: инструкция для новичков

Вещи, которые по началу кажутся сложными, мы лучше понимаем на простых примерах.

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

3 способа связать сайт с сервисом рассылок

Прежде всего, нужно решить, как связать сервис email-рассылок с вашим или CRM-системой.

Вы можете использовать:

  1. Готовые интеграции. Например, сервис UniSender интегрируется с популярными CRM-системами ,  CMS-системами и интернет-магазинами.
  2. Интеграции с помощью Zapier – специального сервиса, который позволяет связывать разные системы не привлекая программиста. Как связывать сервисы через Zapier.
  3. Интеграции по API.

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

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

Что за зверь такой – API?

По сути, это «язык», с помощью которого две системы (например, сайт и система рассылки) могут понимать друг друга и обмениваться данными.

API-документация — это развернутая инструкция для программиста, как организовать «общение» вашего сайта с системой рассылки, чтобы она совершала нужные действия в нужный момент.

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

Я в работе использую такую схему:

схема

Пример работы этой схемы легко понять на известном меме:

объяснение схемы

А теперь разберём первую схему детальнее.

Что проработать в техническом задании. 5 элементов

1. Источник

Источник – это система, откуда мы берём данные.

Например, какой-либо сайт example.com или ваша CRM-система.

2. Триггер

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

Например, могут быть такие триггеры:

  • посетитель на сайте заполнил и отправил форму «N»;
  • пользователь зарегистрировался на сайте;
  • авторизированный пользователь обновил данные о себе в личном кабинете, отписался от рассылки или изменил условия её получения;
  • менеджер обновил статус клиента в CRM-системе на «N»;
  • пользователь совершил заказ.

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

3. Данные

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

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

Например, на сайте есть форма заявки с такими полями:

  • Ваше имя.
  • Ваш email.
  • Телефон.
  • Город.

И мы хотим, чтобы данные автоматически попадали в группу «Заявки».

В системе рассылки поля «имя», «email» и «телефон» уже существуют по умолчанию. А вот поле «Город» нам некуда передавать, поэтому для начала его нужно создать в системе рассылки.

В сервисе UniSender это делается так:

Как составить ТЗ для программиста

Бывает, что сайт уже готов, но нужно добавить на него какую-нибудь программу:

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

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

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

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

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

Требуется программист, чтобы добавить функцию 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. Иначе возможен конфликт.

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

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

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

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

Чек-лист по юзабилити: 200+ пунктов на проверку

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

И это даже не половина способов

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

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

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

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

Заключение

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

kak-sostavit-tz-dlya-programmista

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *