Евгений Кучерявый

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

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

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

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

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

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

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

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

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

«Нужен программист, который добавит функцию Х на готовый сайт на Битрикс»

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

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

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

2. Способ и вариант оплаты.

3. Правки и штрафы.

4. Подробное описание вашего видения того, что должно получиться.

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

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

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

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

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

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

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

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

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

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

Главное, при составлении ТЗ для фрилансера-программиста быть предельно скрупулезным, также как во время составления ТЗ для разработки сайта. Лучше все заранее продумать, чтобы потом не спотыкаться во ходе работы и не терять время с деньгами. Часто люди сталкиваются с проблемой, когда фрилансеры предоставляют услуги крайне низкого качества, не укладываются в поставленные сроки или попросту перестают отвечать на сообщения и звонки. Мы не рекомендуем работать без подписания договора, в котором будут обозначены обязанности обоих сторон. А такие сложные и масштабные проекты как: разработка крупного интернет магазина, портала, сайта для гос.учреждения - точно лучше заказывать у профессионалов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вступление

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

Все слышали про pre poduction , но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания - еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования . А вот как были достигнуты эти результаты? - загадка во тьме .

Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.

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

Самое важное:

1. Четкое понимание конечного результата. (Контроль качества.)
2. Сроки исполнения.

Зачем нужна документация:

1. Экономия времени на коммуникациях. (Один раз написать, вместо того чтобы 100 раз пересказывать, путаясь в показаниях.)
2. Способ увидеть, как будет выглядеть готовый проект.
3. Анализ и выявление проблем еще на стадии планирования. (Чем раньше будет выявленна архитектурная ошибка - тем дешевле ее исправить)
4. Фиксирование принятых решений. (Точные данные, вместо разрозненных слухов разной степени свежести.)
5. Планирование работ.

Какие бывают документы:

1. Концепция («Про че игра?»)
2. Спецификация (Что мы хотим получить?)
3. Техническое задание (Как это устроено - именно о нем будет идти речь.)
4. План работ (Как мы это будем делать.)

Кто участвует в обсуждении ТЗ:

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

1. Геймдизайнер (Написание документации)
2. Архитектор (Отслеживание полноты и подробности описания, декомпозиция.)
3. Программист (Оценка объемов работ.)

Требования к оформлению документации:

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

1. Форматирование. (Легко напечатать и приятно читать/держать в руках)
2. Выделение ключевых фраз. (Для чтения документа по диагонали)
3. Составление списков. (Вместо сплошного текста)
4. Разбиение длинных списков по группам. (По три пункта в группе)
5. Многократные повторения. (Избегать ссылок по документу)
6. Дата, номер страницы, количество страниц, нумерация пунктов. (Для точных ссылок при обсуждении прочитанного)
7. Оглавление, список документов, история изменений. (Для поиска по документации/версиям)

Требования к содержанию ТЗ

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

1. Русский язык. (Никаких мемов, искаженных аглийских терминов, албанского языка и прочего мусора. Даже внутреннюю документацию читают очень многие.)
2. Никаких общих слов типа:
   • все возможные варианты
   • карта придумывается компьютером
   • взаимодействие различных объектов
   • после всех действий и т.д.
3. Все названия видов сущностей(классов) должны иметь:
   • русское название (для игрока)
   • английское (для кода)
   • краткое описание (расшифровка/подсказка/комментарий)
4. Сущность должна иметь только одно название. (Чтобы “броня” не превращалась на другой странице в “армор” или “щит”).
5. Предложения должны быть полными и понятными читателю без пристального изучения контекста. (Не надо подразумевать, что читатель сам догадается до того, что подразумевал автор)
6. Все что можно измерить, должно быть измерено.
   • размеры картинки в пикселях и байтах
   • количество столбцов и клеток в таблице
   • количество символов в текстовом поле
   • количество оружия на уровень
   • время сессии и т.д.

Главные требования к результату работы программиста:

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

1. Гибкость системы к изменениям. (Динамические требования.)
2. Автоматический сбор данных об ошибках. (Обратная связь.)
3. Простота запуска и настройки заказчиком. (Демонстрация результата.)

Первый этап написания ТЗ:

Описание предметной области, ее формализация в понятных программистам терминах.

1. База данных (метаданные)
   • список типов объектов
   • характеристики объектов
   • связь/зависимость между объектами
2. Бизнес-процессы (полный игровой цикл)
   • список процессов (сценарии работы)
   • список функционала (что должен уметь)
   • список ожидаемых изменений (что вообще может быть)

Второй этап написания ТЗ:

Как должен выглядеть/работать продукт для всех типов пользователей (игроки и администраторы).

1. Интерфейс (визуальная часть)
   • список экранов игры с названиями (или группы элементов)
   • список элементов на каждом экране с названиями и текстом подсказок
   • описание поведения элементов (подмигивание, подсказка, блокирование, всплывающие диалоги и т. д.)
2. Админка (управление)
   • сервер (жизненные/системные показатели)
   • игровой контент(распродажи, квесты, монстры, вещи, магазины, дроп, локации и т.д.)
   • игровые данные(контент генерируемый игроками)
   • статистика и отчеты (какую статистику нужно собирать?)

Третий этап написания ТЗ:

Как мы собираемся это все делать.

1. Исследование необходимых технологий
   • Список требований к каждой технологии
   • Описание тестов/демонстрации работы каждой технологии
   • Список будущих требований/возможных проблем (что дальше?)
2. Список требований к разным видам контента(ресурсов) для игры (размеры картинки мечей, длинна названий квестов, разновидности спецэффектов, размеры видеороликов и т.д.).
3. Список небходимых инструментов для работы с контентом (редактор карт, админка квестов,).
4. Расстановка приоритетов по задачам.
5. Требования к первой работающей сборке (что должен уметь первый прототип).
6. Список остальных итераций разработки проекта с требованиями к их результатам. (Что нужно показать в конце каждого этапа, чтобы закончить его)

Сопровождение документации

1. Большая часть того, что написано на первых этапах – устареет и будет нуждаться в переписке заново задолго до окончания планирования.
2. Главный принцип первых этапов планирования: расставить список разделов и составить список вопросов по каждому разделу.
3. Чем ниже детализация на начальных этапах – тем лучше. (количество типов оружия, вместо полного списка с названиями, количество квестов по уровням, вместо их подробного перечня и т.п.)
4. Чем легче найти нужный пункт в документации и изменить его, не затрагивая остальное – тем лучше. Поэтому нужно избегать графических схем и сплошного текста из сложноподчиненных предложений. Оставьте графические презентации и эмоциональные описания для финальной отчетности.
5. После каждого цикла планирования - проверять и тестировать полноту документации и равномерность уровня ее детализации. (Если в доме из 5 комнат описана только одна – нужно описать остальные четыре, или выкинуть подробное описание одной комнаты, чтобы все комнаты были описаны одинаково подробно .)
6. Составить список неудобных вопросов . Темные пятна всегда есть, и их стараются обойти и замолчать, не осознавая этого.
7. Предоставлять краткие инструкции конечным исполнителям . Конечные исполнители не должны сталкиваться с полной документацией, и мучительными поисками нужного упоминания по всему объему.
8. Признак мастерства : каждый следующий уровень планирования уточняет, но не изменяет результаты описания более абстрактных уровней. Именно хороший навык перемещения по уровням абстрагирования/детализации позволяет перейти от припадочного описания деталей к планомерному перечислению сущностей.

Срезание углов

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

1. Проект в 2-3 месяца.
2. Команда из 2-3 человек.
3. Ограниченный бюджет. (Он всегда ограничен)
4. Нет требований к документации. (Никто не знает как надо делать)
5. От нее нет никакой пользы. (Никогда не использовали документацию)

Однако следует помнить: разработка документации занимает 40% всех усилий. И определяет на 90% вероятность успешного завершения разработки проекта.

Первые шаги

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

Итак, техническое задание, сокращенно ТЗ, уже довольно давно служит для формального описания того, что мы собственно хотим видеть в конечном продукте. Не является исключением и ТЗ для разработки 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. Описание страниц сайта
Это довольно обширный пункт, где прорисовуются все страницы сайта и пишутся комментарии к их работе.
Также может приводиться общая структура страниц сайта. Так называемые «высокоуровневые» прототипы. Например, для простого сайта-каталога это может быть:

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

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

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

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

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

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

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

Удачных Вам проектов и человеческого взаимопонимания!

Подписаться на рассылку