Как написать техническое задание для программиста образец

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

Как написать техническое задание для программиста образец

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

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

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

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

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

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

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

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

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

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

Заключение

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

kak-sostavit-tz-dlya-programmista

Источник: https://TexTerra.ru/blog/kak-sostavit-tz-dlya-programmista.html

Составление тз для сайта – техническое задание для программиста образец

Как написать техническое задание для программиста образец

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

Техническое задание должно быть четким, понятным и конкретным.

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

В правильное ТЗ должны входить следующие пункты:

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

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

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

Технические подробности

Немаловажен момент с описанием того, на чём будет работать новый модуль, который вы заказываете у программиста. В настоящее время предпочтение отдается готовым решениям, поэтому проблем интеграции в Битрикс, OpenCart, WordPress или любую другую систему, обычно не возникает, так как исполнителю сообщают все данные конфигурации сборки.

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

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

Поэтому рекомендуется в ТЗ писать разработчику, чтобы тот комментировал строки кода. Максимум комментариев в коде, и больше стандартных выражений, чтобы в дальнейшем можно было избежать пресловутых «костылей».

Тестирование

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

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

В общем, готовый проект любого масштаба, требует проверки и перепроверки.

Подводя итог

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

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

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

Техническое задание на разработку сайта.

Сайт разрабатывается  как  корпоративный  сайт компании ___________.

Этапы Работ.

Работы по настоящему Договору № _______ состоят из следующих этапов. По окончании всех этапов, Стороны подписывают Акт сдачи-приемки работ:

  1. Разработка дизайн-макета и концепции новой версии сайта www.______.ru
  2. Верстка Сайта.
  3. Графическое представление страниц Сайта.
  4. Наполнение Сайта информацией
  5. Установка и настройка функционала сайта
  6. Установка Сайта на хостинг Заказчика (перенос файлов, создание базы данных)
  7. Финальное тестирование Сайта.

Разработка дизайн-макета

Разработка дизайн-макета сайта с сохранением корпоративного стиля для организации включает в себя:

  • Концепция подачи материалов на главной странице (с графическими элементами),
  • Концепция подачи главной страницы раздела
  • Навигация между разделами и страницами сайта
  • Отображение материалов и новостей на главной странице
  • Отображение материалов и новостей страницах разделов

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

Верстка сайта.

1. Сайт разрабатывается на системе администрирования Joomla 3.3.6 (или последней актуальной версии на момент сдачи сайта).

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

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

2. Сайт разрабатывается под популярные браузеры Google Chrome- ‎Mozilla Firefox —  ‎Opera – IE (версия 9 и новее), а так же будет читаться на широко — экранных мобильных устройствах (планшетах и смартфонах).

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

  • Кодировка: UTF-8
  • Язык скриптования: php версии 5.3.10

Графика.Отрисовка графических элементов по макету, графика для разделов сайта и т.д.

  • Сайт двух-колоночный (левая колонка 250px + поле для текста 950px)
  • При разработке сайта должны быть использованы преимущественно светлые стили.
  • Сайт шириной (1200px), размер шрифта текстов 14 px.
  • Основные разделы сайта должны быть доступны с первой страницы.
  • На первой странице не должно быть большого объема текстовой информации, но представлено все самое основное.
  • Навигация сайта должна быть понятной и к любой странице сайта организован доступ максимум в 2 клика.

В дизайне сайта не должны присутствовать:

— мелькающие баннеры;
— сливающийся или плохо читаемый текст.

Графическое представление страниц сайта:

  • графическая шапка с логотипом, форма заказать звонок (всплывающее окно)
  • горизонтальное навигационное меню сайта (навигационная панель обеспечивает переход к основным пунктам меню сайта: , О нас, Услуги, Тарифы, Абонентам, Арендодателям, Контакты);
  • навигационная панель (меню) по подразделам выбранного раздела сайта (левая колонка);
  • форма быстрого заказа услуг (левая колонка);
  • ссылка на главную страницу при клике на логотип;
  • слайдер на главной странице (с созданием баннеров 3 шт.)
  • поле для отображения контента выбранной страницы сайта (заголовки, шрифт 16px);
  • внизу страницы — краткая контактная информация — телефон и e-mail компании

Наполнение сайта.

  • Разработка правильной (для поисковиков и человеко-понятной) структуры сайта и организация контента в соответствии со структурой
  • На сайте будет 4 основных раздела: Интернет, Телефония, Хостинг, Цифровое телевидение
  • Перенос информации с сайта прототипа.
  • Редакция материалов (форматирование кода, очистка), добавление фотографий
  • Компановка страниц: главная, страница разделов, страница материала.
  • Создание меню сайта, всех пунктов и подпунктов

Функционал сайта (компоненты, плагины и модули)

  • Слайдер баннеров на главной странице
  • Всплывающее окно «»
  • Форма быстрого заказа услуги (с выбором услуги и контактной информацией о клиенте)
  • Фотогалерея со всплывающими фото (подгрузка фото из кэша для облегчения сайта)
  • Организация разделов наши Клиенты и Наши партнёры, Сертификаты и грамоты
  • Плагин для возможности вставки на сайт кодов iframe (видео, интерактивных карт и т.д.)
  • Отзывы клиентов (компонент)
  • Счётчики посещений

Сроки работ.

  • Разработка дизайн макета – 7 дней
  • Верстка сайта и стилей графического представления страниц сайта – 30 дней
  • Наполнение сайта –7 дней
  • Тестирование сайта – 1 день

Сроки работ по настоящему техническому заданию 45 (сорок пять) дней.

Разработка, просмотр и доводка сайта производится на тестовой площадке Исполнителя, после чего утверждается Заказчиком (письмо по электронной почте). Перенос сайта на постоянное место производится в ночное время в течение 1 дня.

Подписи.

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

Как научиться писать технические задания для разработчиков?

Современные технологии позволяют полностью автоматизировать любую торговую стратегию и освободить трейдера от утомительных:

  • Наблюдений за графиком
  • Сложных вычислений
  • Психологических нагрузок
  • Эмоциональных переживаний
  • Ошибочных действий

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

Найти программиста это пол «беды», основная сложность заключается в том как объяснить программисту что вы хотите. Казалось бы ничего сложного нет, индикатор показывает BUY советник покупает, индикатор показывает SELL советник продает, но на самом деле для этих простых действий, программа должна выполнить массу предварительных шагов.

Вот только несколько простых:

  1. Проверить есть ли уже ордера. (Может на прошлом тике мы уже открыли ордер по сигналу)
  2. Проверить разрешено ли торговать. (Разрешена ли торговля по выбранной валюте)
  3. Проверить доступность интернет соединения.
  4. Проверить и рассчитать объём для торговли. (Хватит ли денег)
  5. Проверить и произвести вычисления из индикатора.

    (Получить сигнал)

  6. ……

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

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

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

Техническое задание обязательно должно содержать три блока:

Блок открытия позиции — условия при которых программа открывает или устанавливает ордера в рынке. Сигналы индикатора с учетом по времени, номеру бара, состоянию бара, размеру бара и другие условия…

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

Блок закрытия позиции — условия при которых позиция должна быть полностью или частично закрытой.

По мимо основных блоков могут быть еще дополнительные блоки:

  • Блок настроек программы.
  • Блок ММ (Мани менеджмента) в котором рассчитываются объемы для торговли (Лоты).
  • Информационный блок, задача которого выводить на экран текущую информацию.
  • Блок отправки сообщений на смартфон, почту или фтп сервер.
  • И другие ….

Важно четкие условия в техническом задании!!!

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

Рассмотрим пример правильного технического задания:

Торговая стратегия на двух скользящих средних.

Открытие ордеров:

Быстрая скользящая средняя пересекает медленную и при появлении нового бара открывается ордер не зависимо от того есть уже ордера в рынке или нет. Открытому ордеру устанавливается Тейк Профит согласно настройкам и Стоп Лосс. Период бара зависит от графика на который установлен советник.

Модификация ордеров:

Стоп Лосс савиться ниже локального минимума для баев и выше локального максимума для селов за последние 24 бара. Для всех ордеров применяется трейлинг стоп согласно настройкам советника.

Закрытие ордеров:

По тейк профиту, по стоп лоссу, по обратному сигналу.

Блок расчета лота:

Если последний ордер закрылся с убытком то для нового ордера лот будет увеличен в два раза.

Если последний ордер закрылся с прибылью то для нового ордера лот будет сброшен до начального из настроек

Блок настроек советника:

  • По индикаторам — Период мувинга, Тип мувинга, Цены расчетов мувинга.
  • Тейк профит
  • Стоп лосс
  • Лоты
  • Меджик номер
  • Проскальзывание

Источник: https://steptosleep.ru/%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-%D1%82%D0%B7-%D0%B4%D0%BB%D1%8F-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%81%D1%82%D0%BE%D0%B2/

Письмо программисту (ТЗ или тех задание)!

Как написать техническое задание для программиста образец

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

  • Наблюдений за графиком
  • Сложных вычислений
  • Психологических нагрузок
  • Эмоциональных переживаний
  • Ошибочных действий

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

Найти программиста это пол “беды”, основная сложность заключается в том как объяснить программисту что вы хотите. Казалось бы ничего сложного нет, индикатор показывает BUY советник покупает, индикатор показывает SELL советник продает, но на самом деле для этих простых действий, программа должна выполнить массу предварительных шагов.

По мимо основных блоков могут быть еще дополнительные блоки:

  • Блок настроек программы.
  • Блок ММ (Мани менеджмента) в котором рассчитываются объемы для торговли (Лоты).
  • Информационный блок, задача которого выводить на экран текущую информацию.
  • Блок отправки сообщений на смартфон, почту или фтп сервер.
  • И другие ….

Важно четкие условия в техническом задании!!!

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

Торговая стратегия на двух скользящих средних.

Открытие ордеров:

Быстрая скользящая средняя пересекает медленную и при появлении нового бара открывается ордер не зависимо от того есть уже ордера в рынке или нет. Открытому ордеру устанавливается Тейк Профит согласно настройкам и Стоп Лосс. Период бара зависит от графика на который установлен советник.

Модификация ордеров:

Стоп Лосс савиться ниже локального минимума для баев и выше локального максимума для селов за последние 24 бара. Для всех ордеров применяется трейлинг стоп согласно настройкам советника.

Закрытие ордеров:

По тейк профиту, по стоп лоссу, по обратному сигналу.

Блок расчета лота:

Если последний ордер закрылся с убытком то для нового ордера лот будет увеличен в два раза.

Если последний ордер закрылся с прибылью то для нового ордера лот будет сброшен до начального из настроек

Блок настроек советника:

  • По индикаторам – Период мувинга, Тип мувинга, Цены расчетов мувинга.
  • Тейк профит
  • Стоп лосс
  • Лоты
  • Меджик номер
  • Проскальзывание

Источник: https://trading-go.ru/articles/pismo-programmistu-tz-ili-tekh-zadanie/

Как грамотно составить ТЗ для программиста. Основы взаимопонимания

Как написать техническое задание для программиста образец

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

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

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

По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.

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

Чем детализированнее ТЗ (в разумных пределах конечно), тем лучше для обеих сторон — как для клиента, так и для исполнителя работы.

В выигрыше так сказать оба:— клиент будет уверен, что все задуманное им в проекте четко прописано и должно быть реализовано в соответствии с ТЗ.

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

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

Общие рекомендации по написанию ТЗ

  • Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
  • Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
  • В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
  • Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит?  Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно  и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
  • Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести  анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях ( благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
  • Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.

Справка

 Прототип — это графическая схема размещения элементов интерфейса. Грубо говоря, нарисованная в специальной программе страница со всеми элементами.

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

Из популярных можно выделить:— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;

—  среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много — выбирай, осваивай, рисуй…

Общая структура ТЗ. От абстракции к конкретике

Одна из возможных структур сайта, подчеркну возможных, может выглядеть примерно так:

  1. Общая информация о сайте.
  2. Функциональное назначение сайта.
  3. Понятия и термины
  4. Описание модулей сайта
  5. Функциональные характеристики
  6. Описание страниц.
  7. Резервирование и надежность.
  8. Хостинг для сайта.

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

2. Функциональное назначение сайта
Тут краткий перечень того, какими техническими средствами или инструментами должен обладать сайт, исходя из общей цели. Поясню на примере. Для сайта-визитки это может быть банально, форма обратной связи, перечень основных страниц, например с «о компании», «контакты» и прочие.

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

4. Описание модулей сайта
Этот раздел включает список модулей, которые используются на сайте. Это вполне например может быть упоминаемая выше форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:

  • Поле «Ваш имя»;
  • Поле «Ваш е-mail»;
  • Поле «Ваш вопрос»;
  • Поле ввода капчи для защиты от спам-роботов.

И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса?» или что-то в этом роде.

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

Например, некоторые заказчики могут требовать, что бы их сайт работал корректно и в  небезызвестном  Internet Explorer 6, что бы не терять хоть и небольшую, но долю возможных посетителей.

Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и  по настройке сервера.

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

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

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

Источник: https://siteclinic.ru/blog/technical-aspects/tz-dlya-programmista/

Как писать техзадание для интеграции с сервисом email-рассылок

Как написать техническое задание для программиста образец

Советы Как интегрировать сайт и сервис email-рассылок

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Источник

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

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

2. Триггер

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

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

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

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

3. Данные

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

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

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

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

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

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

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

Новое поле мы создаем, перейдя в меню «Контакты — Дополнительные поля».

Обратите внимание на выбор типа поля: если вы выберете неправильный тип, то данные не будут передаваться. Тип поля «Строка» позволяет передавать в поле любые текстовые или цифровые значения.

4. Приёмник

В нашем случае это система рассылок UniSender.

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

Этот ключ вы должны сами посмотреть в личном кабинете системы и прислать программисту:

Посмотреть API-ключ можно в меню «Настройка аккаунта» (раздел «Интеграция и API»)

Копируем цифры и буквы с вкладки «Интеграция и API» личного кабинета и передаём их программисту.

5. Реакция

Что система рассылки должна сделать, получив данные.

Примеры реакции системы рассылки:

  • отправить письмо с названием «N»
  • отправить письмо с подтверждением подписки
  • добавить контакт в группу с названием «N»
  • отправить SMS с текстом «N» контакту
  • отписать пользователя от всех рассылок

Рекомендую просмотреть список методов API перед отправкой задачи программисту.В этом документе описано всё, что может сделать система рассылок, получив по API команду от вашего сайта или CRM-системы.

Например, вам нужно отправить письмо с благодарностью за регистрацию на мероприятие. При этом double opt-in (двойное подтверждение подписки) мы не хотим использовать.

Такую задачу можно выполнить двумя способами:

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

Способ 2. Использовать метод Subscribe, то есть просто добавить пользователя в группу. А саму отправку письма настроить непосредственно в системе рассылки за три шага:

  • Создаем письмо, которое будет отправлено в момент попадания email-адреса в список «Заявки».
  • Переходим в меню «Рассылки — Письма и черновики — Создать email», заполняем все нужные поля и создаем письмо для нового подписчика.
  • На этапе «Отправка» нажимаем кнопку «Запланировать письмо по событию». Выбираем условие «При попадании в список подписчиков».

То есть, в первом случае мы «просим» систему рассылки отправить конкретное письмо, а во втором «просим» добавить контакт в группу. А система рассылки уже сама «знает», что при добавлении контакта в группу нужно отправить пользователю приветственное письмо.

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

Итог

Написать техническое задание программисту для интеграции по API с сервисом рассылки вовсе не сложно. Разложите задачу максимально детально по схеме «Триггер – Данные – Реакция» и не бойтесь консультироваться со службой поддержки.

“>

Источник: https://www.unisender.com/ru/blog/sovety/pishem-tehnicheskoe-zadanie-programmistu-podhod-devochki-blondinki

Техническое задание на разработку приложения

Как написать техническое задание для программиста образец

ТЗ на разработку — а оно нам надо?

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

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

Он тоже заинтересован в успехе вашего сотрудничества.

1 шаг. Идея разработки мобильного приложения

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

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

И если вам удастся найти эту прореху в нише, заполняйте ее смело и не теряйте драгоценных секунд — конкуренты не дремлют.

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

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

2 шаг. Вопросы, с которых начинается ТЗ

Чтобы составить ТЗ, для начала нужно ответить на несколько вопросов:1. Для кого это приложение? Для ваших клиентов, будущих или потенциальных, или для всех сразу? Или для ваших сотрудников?2.

Какие задачи решает приложение? Если оно для клиентов, то что клиенты смогут делать с помощью вашего приложения – заказывать товары, услуги, бронировать, записываться онлайн, узнавать об акциях и т.д.? Если оно для сотрудников, то какие функции в приложении помогут им работать эффективнее?3. На каком устройстве вы хотите видеть ваше приложение? Смартфон, планшет или десктоп?4.

В устройствах каких марок вы планируете поселить ваше приложение? От этого зависит, какую платформу для приложения вы выберите — iOS, Android, Windows.5. Когда вы хотите получить готовое приложение? То есть сроки.6.

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

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

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

3 шаг. Настало время ТЗ!

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

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

1. Терминология.

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

2. Цель создания системы, то есть приложения. Здесь вы подробно описываете, что пользователь сможет делать в приложении, какие действия и какой результат он получает. В общем, для чего ваше приложение будут скачивать люди в свои смартфоны. Если у вас приложение для магазина, то вы должны решить, к примеру —пользователь будет просто просматривать каталоги, узнавать о наличии товаров в магазинах или сразу покупать и заказывать доставку?
3. Требования к приложению. Самая сложная часть техзадания, где технические термины льются как из рога изобилия. Написать это самому нереально. Но важно понимать, что каждый шаг будущего пользователя должен быть продуман до технических мелочей. К примеру, из тз должно быть четко ясно, что случится, если нажать на вот эту красную кнопочку.
4. Сценарии использования. Что происходит, когда человек впервые заходит в приложение? Нужно ли регистрироваться? А что произойдет, когда он зайдет повторно? Все эти пути важно описать в тз, ведь это поможет выявить, какие функции нужны приложению и что именно должно в нем происходить.
5. Описание экранов. Некоторые тз содержат прототипы экранов, если они уже готовы. В некоторых есть даже первичный дизайн. В любом случае описать экраны хотя бы словами просто необходимо. Ведь для многих пользователей приложение – это и есть экран. Именно с ним он имеет дело, и что толку от функции регистрации, к примеру, если ни на одном экране нет такой кнопки?
6. Требования к платформе, CMS, архитектура системы… и еще много страшных слов, если вы не разработчик или технический писатель.
Ваше ТЗ может не содержать тех или иных разделов только в том случае, если это не существенно именно для вашего проекта. Но узнать, что именно существенно, а что нет, вы сможете только от разработчика.

Начните прямо сейчас!

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

А значит, в составлении ТЗ должны принимать участие обе стороны и… та-дам! Основные технические трудности мы берем на себя!
Как говорится, глаза боятся — а руки-то вот они. Тут важно начать. Часто, это главная заминка в начале успешного проекта.

Поэтому начинайте прямо сейчас — заполните бриф. Этого хватит, чтоб увидеть проект в общих чертах, а значит, дело останется за деталями!

Источник: https://punicapp.com/blog/pages/332/tehnicheskoe-zadanie-na-razrabotku-prilozheniya/

Юридическая ситуация
Добавить комментарий