Бывает так, что сайт уже готов, а в нем отсутствует какая-нибудь важная функция: программа рассылки, онлайн-калькулятор, нет нужных полей в CMS и пр. Когда после этого заново просматривается техническое задание к этому проекту, то вдруг выясняется, что эти функции просто не были включены в техзадание. Чтобы этого не случилось, в данной статье подробно опишется, как грамотно составить ТЗ для программиста, чтобы в будущем не было никаких проблем.
Структура ТЗ
Для того, чтобы грамотно составить техническое задание программисту, необходимо правильно обозначить структуру. Выделим основные разделы, которые в любом случае должны присутствовать в ТЗ.
Определение цели проекта
Без четкого понимания конечной цели невозможно создать качественный продукт, который полностью устроил бы заказчика. Поэтому, чем лучше будет поставлена цель работы перед разработчиком, тем предпочтительней будет полученный конечный результат.
Для разработчика четко сформулированная цель всего проекта дает полное понимание всей сути поставленной задачи. Для заказчика цель работы дает осознание всех задач, которые решаются по мере продвижения работы.
Полный бюджет проекта
Для исполнителя бюджет проекта, написанный в техническом задании, на начальном этапе дает согласованный с работодателем учет всех его работ. В некоторых случаях, после обоюдного согласования трудовых затрат, происходит корректировка конечной стоимости проекта. Заказчику полный бюджет в ТЗ дает понимание, сколько всего денежных средств надо будет заплатить разработчику. И уже на этих данных он может планировать свой бюджет.
Нет времени разбираться?
Разработка сайта под ключ
От проектирования каким должен быть сайт для лучших продаж до запуска и интеграции с любыми сторонними системами. Все сайты имеют мобильную версию и готовы к SEO-продвижению и приему рекламного трафика. Специализируемся на 1С-Битрикс более 10 лет.
Ваш сайт:
Перечень необходимых работ
Без полного перечня планируемых работ невозможно представить ни одного грамотного техзадания. Он должен быть удобным в понимании и составлен в виде пунктов.
Для исполнителя список работ нужен для понимания, по какой технологии ему следует выполнять задание, какой программный код использовать. Также перечень пунктов в какой-то мере является его гарантом, если вдруг по окончании проекта заказчику что-то не понравилось. Всегда можно открыть техническое задание и увидеть, была ли включена данная работа в условный перечень.
Также у программистов по ходу проекта всегда имеется возможность отказаться от каких-либо заданий, которые не были предварительно включены в список. Или включить их все-таки в ТЗ, но за дополнительную плату. Работодателю перечисленный список работ дает подробное понимание выполняемых заданий на каждом конкретном этапе.
Тщательно описывается готовый продукт
В техническом задании программисту в обязательном порядке должен быть пункт, в котором было бы подробное описание конечного продукта. Для исполнителя данный раздел дает уверенность в правильном понимании итогового результата. Заказчику описание продукта также нужно для полного представления о готовом проекте.
Оценивание результата проекта
Оценка результата может быть предварительной, когда она производится после каждого этапа проделанных работ, или итоговой, уже после окончательного завершения проекта. Оценивание делается при помощи специализированных программ тестирования. Сравнивается полученный результат с требованиями задания для программиста.
Для исполнителя этот пункт ТЗ нужен для того, чтобы он на любом этапе работы имел возможность убедиться в том, что проект соответствует всем нужным требованиям технического задания. Заказчику оценка работ необходима для понимания того, что вложение денег в проект было сделано не зря.
Сроки выполнения работ
Не может быть ТЗ без срока выполнения заказа. Да, бывают ситуации, когда изначально очень тяжело определить весь фронт работ. Или по мере выполнения штатных задач над проектом появляются форс-мажорные обстоятельства, которые вынуждают сдвигать конечные сроки выполнения работы. Но, в любом случае, хотя бы предварительное время работы над проектом должно быть.
Привлекли 35.000.000 людей на 185 сайтов
Мы точно знаем, как увеличить онлайн–продажи
Применяем лучшие практики digital–продвижения как из вашей тематики, так и из смежных областей бизнеса. Именно это сделает вас на голову выше конкурентов и принесёт лиды и продажи.
Ваш сайт:
Исполнителям срок исполнения заказа позволяет уже на начальном этапе объективно оценить свои потребности в ресурсах и трудозатраты (часы работы). Для заказчика – полное ориентирование в сроках работы, что позволяет планировать все свои остальные проекты. Часто бывает, что работа для данного ТЗ является только составной частью какого-то большого проекта. И он не может дальше продвигаться, пока не будет выполнена эта конкретная работа.
Будущее обслуживание проекта
Всегда, даже после самого удачного проекта, по прошествии некоторого времени, могут обнаруживаться ошибки («баги»), которые следует незамедлительно исправлять. Поэтому, в любом техническом задании, все запланированные работы должны учитывать будущее обслуживание сайта в перспективе.
Исполнителю этот перечень работ дает представление о будущей нагрузке, которая будет присутствовать в связи с дальнейшим обслуживанием. Для заказчика данный пункт в ТЗ дает информацию, которая позволяет планировать затраты на будущую поддержку сайта.
Выявление проблем
В этот пункт техзадания входят работы, которые могут возникнуть при форс-мажорных обстоятельствах. Для того, чтобы грамотно составить данную часть ТЗ, нужно знать самые слабые места сайта, и уже на основе этих знаний заранее предугадать возникновение будущих неполадок.
Обычно, пункт по выявлению проблем составляется заказчиком совместно с программистом или группой программистов, которые пишут код. Они, как никто лучше знают все «узкие» места проекта.
Пример ТЗ для программиста
Приведем реальный пример технического задания для веб-разработчика на тему: «Доработка полей в CMS». Это ТЗ содержит следующие пункты с заданием:
- Цель проекта: доработать поля в CMS.
- Исходная информация. Произошла путаница с тем какое поле за что отвечает, в каком шаблоне, какой функционал. В итоге, слетела оптимизация этих элементов. Далее подробнее.
- Описание. Есть 2 типа страниц: записи и страницы.
Сриншот 1
Записи, пример — https://…
Страницы, пример — https://…
Пример того что у разных типов разные поля.
Для типа Записи, есть вот такое поле:
Скриншот 2
Для типа Страницы, такого поля нет:
Скриншот 3
Какие поля нужны / что нужно выводить:
- Тег title — заголовок окна браузера
- Тег meta description — описание страницы
- Тег h1 — заголовок (основной) на странице
- Название страницы в хлебных крошках
- Название в меню на сайте
- Название страницы в админке
- Способ реализации.
Для следующих элементов нужно сделать отдельные поля:
- Тег title.
- Тег meta description.
- Тег h1.
- Название страницы в хлебных крошках.
- Дать им понятные названия (чтобы однозначно понимать что должно делать это поле).
- Сгруппировать их на странице редактирования.
Названия для полей:
- Тег title — заголовок окна браузера.
- Тег meta description — описание страницы.
- Тег h1 — заголовок (основной) на странице.
- Название страницы в хлебных крошках.
- Название в меню на сайте — уточнить откуда берется.
- Название страницы в админке — уточнить откуда берется.
Группировка
Нужно, на странице редактирования, указанные выше поля:
- разместить рядом друг с другом;
- в указанной выше последовательности;
- присвоить им, указанные названия.
Область для размещения полей:
Скриншот 4
- Оценка задачи. Необходимо … рабочих дней работы одного разработчика.
- Бюджет … рублей.
Основные рекомендации и пояснения по написанию ТЗ
Каждое ТЗ для программиста является уникальным, но общие советы применимы ко всем заданиям. Вот главные рекомендации по написанию технического задания для программиста:
- Чем больше сам проект, тем больше людей задействуются в нем, техзадание соответственно увеличивается в объеме.
- Если нужно, то в техническом задании должны быть ссылки и скриншоты на необходимые элементы функций и интерфейса разработки с подробнейшими обоснованиями.
- Техническое задание должно быть понятным и удобным для восприятия. ТЗ нельзя присылать программисту в виде бесформенного «полотна», оно должно быть разбито на пункты. Все этапы проекта и подпункты по самым неважным на первый взгляд работам также должны быть внесены.
- Следует ставить реальные сроки работ. В них также необходимо включать время на согласование проектной документации между разработчиком и заказчиком.
- В ТЗ должна быть только четкая формулировка. Много проектов «заваливалось» или срывались его сроки выполнения только из-за того, что заказчик не смог нормально поставить конкретные технические условия.
- Заказчик должен писать в ТЗ, может ли программист применять прототипы, если в задании отсутствует дизайн для страниц.
Главные ошибки при составлении ТЗ
Каким бы грамотным специалистом не составлялось техническое задание для разработчика, все равно, фактически в каждом написанном ТЗ, имеются типовые ошибки. Рассмотрим самые основные из них:
- В техническом задании расплывчато проставлены задачи и цели проекта.
- Недостаточно технической информации. Конечно, программист в любое время может связаться с заказчиком, но на это тратится драгоценное дополнительное время.
- Нечеткие сроки выполнения задания.
- Несогласованность между заказчиком и исполнителем.
- В техзадании отсутствует единый регламент, который дополнительно помогает взаимодействовать между сторонами.
- В ТЗ не прописаны ответственные лица.
- Отсутствие в техническом задании составляющей, которая бы объективно оценивала полученный результат.
Итак, теперь можно приступать к написанию ТЗ, соблюдая все вышеперечисленные рекомендации, вы сможете составить действительно понятное и четкое техническое задание программисту.
Рекомендации геймдизайнеру от программиста (архитектора).
Вступление
Компьютерные игры — относительно молодая отрасль, которая в перспективе сменит киноиндустрию, так-же как кинофильмы заменили театр. Создание игры — это коллективное творчество, во многом напоминающее создание кинофильма. Кроме того, создание компьютерных игр — одна из самых сложных IT задач, поскольку она включает все себя практические все IT области.
Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.
Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.
Я намеренно оставил за кадром другие документы: концепцию, экономическое обоснование и ТЗ для других исполнителей. Это позволило сфокусироваться на одной теме и осветить ее и только ее достаточно подробно.
Самое важное:
- Четкое понимание конечного результата. (Контроль качества.)
- Сроки исполнения.
Зачем нужна документация:
- Экономия времени на коммуникациях. (Один раз написать, вместо того чтобы 100 раз пересказывать, путаясь в показаниях.)
- Способ увидеть, как будет выглядеть готовый проект.
- Анализ и выявление проблем еще на стадии планирования. (Чем раньше будет выявленна архитектурная ошибка — тем дешевле ее исправить)
- Фиксирование принятых решений. (Точные данные, вместо разрозненных слухов разной степени свежести.)
- Планирование работ.
Какие бывают документы:
- Концепция («Про че игра?»)
- Спецификация (Что мы хотим получить?)
- Техническое задание (Как это устроено — именно о нем будет идти речь.)
- План работ (Как мы это будем делать.)
Кто участвует в обсуждении ТЗ:
Чем раньше будет получена обратная связь от заинтересованных специалистов — тем меньше будет сделано лишней работы.
- Геймдизайнер (Написание документации)
- Архитектор (Отслеживание полноты и подробности описания, декомпозиция.)
- Программист (Оценка объемов работ.)
Требования к оформлению документации:
Чем более неряшливо будет оформление — тем меньше людей вообще начнет это читать. Читатели проявляют невероятную изобретательность, чтобы избежать неприятной для них работы. Поэтому так важно прилагать усилия к тому чтобы чтение документации было легким и приятным настолько, насколько это вообще возможно.
- Форматирование. (Легко напечатать и приятно читать/держать в руках)
- Выделение ключевых фраз. (Для чтения документа по диагонали)
- Составление списков. (Вместо сплошного текста)
- Разбиение длинных списков по группам. (По три пункта в группе)
- Многократные повторения. (Избегать ссылок по документу)
- Дата, номер страницы, количество страниц, нумерация пунктов. (Для точных ссылок при обсуждении прочитанного)
- Оглавление, список документов, история изменений. (Для поиска по документации/версиям)
Требования к содержанию ТЗ
Нет четкого списка требований, которому должна удовлетворять документация. Поэтому разработка ТЗ приостанавливается задолго до приближения к ее полноте. В итоге следующий этап разработки начинается без ТЗ, в надежде, что ТЗ будет дописана по ходу, или даже по итогам разработки.
- Русский язык. (Никаких мемов, искаженных аглийских терминов, албанского языка и прочего мусора. Даже внутреннюю документацию читают очень многие.)
- Никаких общих слов типа:
- все возможные варианты
- карта придумывается компьютером
- взаимодействие различных объектов
- после всех действий и т.д.
- Все названия видов сущностей(классов) должны иметь:
- русское название (для игрока)
- английское (для кода)
- краткое описание (расшифровка/подсказка/комментарий)
- Сущность должна иметь только одно название. (Чтобы “броня” не превращалась на другой странице в “армор” или “щит”).
- Предложения должны быть полными и понятными читателю без пристального изучения контекста. (Не надо подразумевать, что читатель сам догадается до того, что подразумевал автор)
- Все что можно измерить, должно быть измерено.
- размеры картинки в пикселях и байтах
- количество столбцов и клеток в таблице
- количество символов в текстовом поле
- количество оружия на уровень
- время сессии и т.д.
Главные требования к результату работы программиста:
Эти важные требования подразумеваются, но никогда никем не озвучиваются.
- Гибкость системы к изменениям. (Динамические требования.)
- Автоматический сбор данных об ошибках. (Обратная связь.)
- Простота запуска и настройки заказчиком. (Демонстрация результата.)
Первый этап написания ТЗ:
Описание предметной области, ее формализация в понятных программистам терминах.
- База данных (метаданные)
- список типов объектов
- характеристики объектов
- связь/зависимость между объектами
- Бизнес-процессы (полный игровой цикл)
- список процессов (сценарии работы)
- список функционала (что должен уметь)
- список ожидаемых изменений (что вообще может быть)
Второй этап написания ТЗ:
Как должен выглядеть/работать продукт для всех типов пользователей (игроки и администраторы).
- Интерфейс (визуальная часть)
- список экранов игры с названиями (или группы элементов)
- список элементов на каждом экране с названиями и текстом подсказок
- описание поведения элементов (подмигивание, подсказка, блокирование, всплывающие диалоги и т. д.)
- Админка (управление)
- сервер (жизненные/системные показатели )
- игровой контент(распродажи, квесты, монстры, вещи, магазины, дроп, локации и т.д.)
- игровые данные(контент генерируемый игроками)
- статистика и отчеты (какую статистику нужно собирать?)
Третий этап написания ТЗ:
Как мы собираемся это все делать.
- Исследование необходимых технологий
- Список требований к каждой технологии
- Описание тестов/демонстрации работы каждой технологии
- Список будущих требований/возможных проблем (что дальше?)
- Список требований к разным видам контента(ресурсов) для игры (размеры картинки мечей, длинна названий квестов, разновидности спецэффектов, размеры видеороликов и т.д.).
- Список небходимых инструментов для работы с контентом (редактор карт, админка квестов, ).
- Расстановка приоритетов по задачам.
- Требования к первой работающей сборке (что должен уметь первый прототип).
- Список остальных итераций разработки проекта с требованиями к их результатам. (Что нужно показать в конце каждого этапа, чтобы закончить его)
Сопровождение документации
- Большая часть того, что написано на первых этапах – устареет и будет нуждаться в переписке заново задолго до окончания планирования.
- Главный принцип первых этапов планирования: расставить список разделов и составить список вопросов по каждому разделу.
- Чем ниже детализация на начальных этапах – тем лучше. (количество типов оружия, вместо полного списка с названиями, количество квестов по уровням, вместо их подробного перечня и т.п.)
- Чем легче найти нужный пункт в документации и изменить его, не затрагивая остальное – тем лучше. Поэтому нужно избегать графических схем и сплошного текста из сложноподчиненных предложений. Оставьте графические презентации и эмоциональные описания для финальной отчетности.
- После каждого цикла планирования — проверять и тестировать полноту документации и равномерность уровня ее детализации. (Если в доме из 5 комнат описана только одна – нужно описать остальные четыре, или выкинуть подробное описание одной комнаты, чтобы все комнаты были описаны одинаково подробно.)
- Составить список неудобных вопросов. Темные пятна всегда есть, и их стараются обойти и замолчать, не осознавая этого.
- Предоставлять краткие инструкции конечным исполнителям. Конечные исполнители не должны сталкиваться с полной документацией, и мучительными поисками нужного упоминания по всему объему.
- Признак мастерства: каждый следующий уровень планирования уточняет, но не изменяет результаты описания более абстрактных уровней. Именно хороший навык перемещения по уровням абстрагирования/детализации позволяет перейти от припадочного описания деталей к планомерному перечислению сущностей.
Срезание углов
Любая технология будет упрощена до абсурда, чтобы уменьшить количество работы и расходов. Хлеб из химических дрожжей, вино из спирта, разработка без документации.
Многие считают что документация не нужна, если:
- Проект в 2-3 месяца.
- Команда из 2-3 человек.
- Ограниченный бюджет. (Он всегда ограничен)
- Нет требований к документации. (Никто не знает как надо делать)
- От нее нет никакой пользы. (Никогда не использовали документацию)
Однако следует помнить: разработка документации занимает 40% всех усилий. И определяет на 90% вероятность успешного завершения разработки проекта.
Первые шаги
Настоятельно рекомендуется новичкам выбирать в качестве первых проектов «клоны» классических игр. Пока нет успешного опыта такой игры — нет виденья всего цикла разработки продукта. А значит нет понимания того, как дойти до финиша.
Не стоит начинать разработку игры, не написав хотя бы двух полноценных ТЗ в качестве упражнения. Это может быть ТЗ по арканоиду. Но это обязательно должен быть ТЗ по которому разработчики смогут написать полноценный арканоид, даже если они никогда не видели этой игры прежде.
Составить техническое задание так, чтобы человек понял, что от него требуется и у него появилась внутренняя мотивация решить твою задачу, — это не особое искусство или магия, а конкретный скилл, который можно и нужно вырабатывать.
У меня 8-летний опыт в проектном менеджменте, работе с дизайнерами, программистами и в постановке задач для них. А последние 3 года я руковожу собственной digital-студией «Пекло». Поэтому с уверенностью говорю, что неважно, работаешь ты с придирчивым разработчиком-перфекционистом или супер-творческим десигнером, подход к формированию задачи одинаковый, за исключением нескольких мелочей.
В этой статье я поделюсь советами и приемами, которые я использую в работе сам: как составить ТЗ так, чтобы вашим коллегам, подрядчикам, партнерам было приятно и комфортно принимать и осуществлять ваши задачи. А это залог эффективной командной работы, выполненных планов, заработанных денег. Поехали!
Заголовок/название задачи должен отвечать на вопрос «Что Сделать?»
Хорошие примеры:
- Разработать дизайн анимированных баннеров для FB/Insta & Google для {CLIENTNAME}
- Исправить отображение страницы /pricing на мобильных устройствах
Плохие примеры:
- Баннеры для {CLIENTNAME}
- Верстка на странице цен
В чем соль:
- Ответ на вопрос «что сделать?» уже подразумевает действие и побуждает к нему
- В хорошо сформулированной задаче должен быть видимый/ощутимый результат
- Когда ты понимаешь желаемый результат — в итоге меньше прокрастинации и больше готовности приступить к задаче и сделать ее
Заголовок задачи должен давать понимание приблизительного объема работы
Хорошие примеры:
- Сделать ХХ ресайзов готового дизайна под площадки для {CLIENTNAME}
- Сделать адаптивную верстку личного кабинета для {CLIENTNAME}
Плохие примеры:
- Дизайн для {CLIENTNAME}
- Сайт для {CLIENTNAME}
В чем соль:
- Если задача слишком объемная и «необъятная», то в итоге непонятно, с какой стороны к ней приступить, с чего конкретно начать и поэтому возникает стресс и прокрастинация
- Надо постараться передать конкретный объем работы + если задача крупная, то обязательно должна содержать подзадачи, с которых нужно начать делать большую задачу
Рекомендации выше подходят как для мелких задач, не требующих дальнейших описаний, видения решения и так далее. Также я рекомендую использовать эти правила даже для ведения личных задач, а не только для постановки коллегам.
Сроки выполнения задачи
Задача, «подкрепленная» дедлайном более приоритетная и важная к исполнению. Задача без дедлайна получает статус «ну, когда-нибудь хорошо было бы ее сделать».
Если вы ставите задачу партнерам и вы не рулите приоритетами их задач, то обязательно уточняйте, когда ее смогут выполнить.
Описание задачи и его структура
Описание задачи необходимо для крупных и объемных задач, где нужно передать весь контекст проекта и понимание ситуации. Обычно описание задачи состоит из нескольких логичных последовательных блоков (это важно!):
- Краткое описание проблемы и ее масштаба
- Видение ее решения (или описание конкретных действий)
- Профит и польза проекту/команде/всем от выполненной задачи
Но помните, что не нужно писать летописи-лонгриды из ваших user story при описании багов. Краткость — сестра таланта. Плюс текст отформатированный, с расставленными акцентами, логично распределенный на абзацы.
IT-шный пример
Заголовок: Задать подготовленные мета-данные для страниц сайта
Мы обнаружили, что на сайте не сформулированы titles & meta descriptions. У части страниц они не заполнены, половина страниц — дубли, а оставшаяся часть сформулирована без использования ключевых слов и некликабельно. Это критическая ошибка, так как без корректных мета-данных сайт не может расти в поисковой выдаче.
Мы составили таблицу в Google Docs с прописанными мета-данными для каждой статической страницы сайта, а также с шаблонами для динамически генерируемых страниц. Ссылка на документ: {link}. Так как у проекта нет админки, где мы могли бы все настроить своими руками, просьба вставить метаданные из документа на страницы сайта:
- Для статических страниц данные вносятся копипастом
- Для динамических страниц используются переменные. Например:%НазваниеТовара% за %price% от интернет-магазина BRANDNAME.COM. То есть, для каждой конкретной страницы сайта должно подставляться ее содержимое. Весь список переменных также находится в таблице.
Просьба это сделать ASAP, так как от этого зависит вся дальнейшая работа по оптимизации. После реализации задачи, мы отправим сайт на переиндексацию и сразу получим увеличение показов и кликов в выдаче! Если в ходе работы возникнут вопросы — без проблем спрашивайте!
Пояснение: кратко описываем проблему, подготавливаем всю необходимую информацию для разработчика (таблица), далее описываем решение задачи, объясняем подводные камни с «переменными». В конце обозначаем важность задачи, желаемые сроки и профит, который будет от решенной задачи. Также мы добавляем, что мы если что рядом и готовы оперативно ответить и помочь (снижает стресс при получении незнакомой задачи).
Самое важное: если решенная задача имеет конкретный результат и пользу, то у исполнителя есть мотивация ее выполнить. Если важность задачи не раскрыта и понимание того, что она даст, то и желания сделать задачу, быть причастным к ее решению тоже особого нет.
Дизайнерский пример
Заголовок: Разработать landing page для {clientname}
К нам обратились ребята из ХХХ. Они организуют ивенты и тусовки для крупных компаний, и за два года стали лидерами. Текущий лендинг — унылое говно и не соответствует их компании.
Мы узнали собрали всю инфу и контент у клиента:
- {ссылка на гуглдок} — это ссылка на ТЗ с примерной последовательностью блоков и черновиками текстов. В случае, если появятся идеи и предложения — можно отойти от ТЗ и предложить свое решение.
- {ссылка на гуглдиск} — собрали в папку все необходимое для проекта: исходники лого, фотографии с тусовок и командные фото
- Вот подборка ссылок на хорошие сайты, которые можно изучить перед работой:
Помни: рисуем mobile-first, так как 90% трафика — мобильные устройства!
Предлагаю перед стартом работ встретиться и обсудить детали работ, я детальнее расскажу про компанию и структуру лендинга, которую мы продумали. По срокам — нужно показать макет до ХХХ, так что время на подумать есть. Контент дали хороший, заказчик адекватный — так что уверен, сможем сделать круто!
Пояснение: рассказываем о сильных сторонах клиента и о проблеме, даем всю необходимую информацию для старта работ и показываем важные технические нюансы. Из моего опыта, дезигнеры, как правило, не любят много букв, текст читают и копипастят невнимательно, поэтому с ними чаще всего нужно обсуждать задачу голосом. В конце, опять же, говорим о положительных нюансах и намерении сделать круто. Однако, жизнь, тяжелая и непредсказуемая штука: может прилететь говняный проект, и вы понимаете, что уже не отвертеться, его нужно сдать и забыть как страшный сон. В таком случае не обманывать коллегу и говорить честно: «Брат, мы должны сделать эту грязную работу!».
Контекст задачи
Некоторые из советов (вроде написания заголовков задач) вообще не требуют дополнительного времени на постановку, а вот насколько развернутые и детально описанные должны быть ТЗ — определяет контекст задачи. Перед постановкой задачи обязательно:
- Поймите, насколько исполнитель знаком с проектом, для которого делается задача?
- Учитывайте, делал ли он раньше аналогичные задачи с вами или вообще с кем-то
- И если есть сомнения, что вы хорошо друг друга поймете — созвонитесь и синхронизируйтесь
В результате вы сэкономите всем время, нервы, быстрее и круче решите задачу, получите каеф от гладкого процесса.
Взаимоотношения с ответственным за выполнение задачи
С каждым человеком у нас складываются определенные взаимоотношения и стиль общения. И чтобы задача лучше читалась и воспринималась исполнителем, можно этот нюанс учитывать и отходить от официоза, канцеляризмов и написать текст на «вашем» языке, что тоже будет комфортнее для восприятия информации
Cover-letter для оформленной задачи — задачу нужно ПРОДАТЬ
Еще небольшая фишка: когда задача уже сформулирована по феншую. Ее нужно ПРОДАТЬ исполнителю:
- Привлечь внимание
- Вызвать интерес
- Вызвать желание
- СДЕЛАТЬ ЕЕ
Прямо по канонам AIDA получается, да? 
Хороший пример:
Вася, привет! В процессе аудита сайта мы обнаружили серьезную ошибку — которая мешает росту сайта. Нужна твоя помощь. Посмотри, пожалуйста, ее сегодня — {ссылка на тикет}!
Плохой пример:
Всем привет! Завели новую задачу: {ссылка на тикет}
И еще мудрые советы в копилку:
- Я прочитал книгу Getting Things Done Дэвида Аллена, и внедрил (и продолжаю это делать) методологию GTD на N% в свою жизнь и стал работать эффективнее и с меньшим стрессом. Очень ее рекомендую.
- Используйте Главред для написания текста
- Не ставьте задачи голосовыми сообщениями! %)
Главное, сформировать у себя привычку писать задачи по феншую — это перестанет быть для вас стрессом, нагрузкой и перестанет занимать дополнительное время. Зато будет порядок в процессах и в эффективности работы!
- 1. Назначение, цели ТЗ
- 2. Общие рекомендации по написанию ТЗ
- 3. Общая структура ТЗ. От абстракции к конкретике
Назначение, цели ТЗ
Итак, техническое задание, сокращенно ТЗ, уже довольно давно служит для формального описания того, что мы собственно хотим видеть в конечном продукте. Не является исключением и ТЗ для разработки web-ресурса. По своей сути — это база для разработки сайта. В нем указываются все положения, прямо или косвенно касающиеся сайта.
ТЗ, как правило, прилагается к основному договору на работы по созданию web-ресурса, т. к. включает полный перечень всех работ для обязательного выполнения дабы исключить возможные споры между клиентом и исполнителем, которые как известно все-равно время от времени возникают.
Есть мнение некоторых “побитых” опытом людей, что техническое задание надо писать так, как будто с ним вы будете присутствовать на суде и использовать его в качестве защиты. Может это и крайность, но тем не менее — повод лишний раз задуматься о важности хорошо написанного и детализированного ТЗ.
По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.
Составление ТЗ как правило выполняют руководитель проекта или непосредственно программист при участии заказчика, который предоставляет основную информацию.
Чем детализированнее ТЗ (в разумных пределах конечно), тем лучше для обеих сторон — как для клиента, так и для исполнителя работы. В выигрыше так сказать оба:
— клиент будет уверен, что все задуманное им в проекте четко прописано и должно быть реализовано в соответствии с ТЗ.
— исполнитель – застрахован от множества мелких или крупных корректировок и доработок, опять же опираясь на то самое ТЗ.
Существует мнение, что без ТЗ можно обойтись. Например, один из доводов — задача слишком творческая, что бы уложить ее в рамки ТЗ. Такое мнение, скорее всего, скрывает нехватку опыта и профессионализма в данной области. Считаю такое мнение ошибочным, так как почти все в сайтостроении можно формализовать и представить в ТЗ и составить его – это скорее дело опыта.
Общие рекомендации по написанию ТЗ
- Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
- Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
- В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
- Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит? Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
- Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях ( благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
- Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.
Справка
Прототип — это графическая схема размещения элементов интерфейса. Грубо говоря, нарисованная в специальной программе страница со всеми элементами.
Существует много софта для прорисовки прототипов, включая как декстопные приложения, так и онлайн-сервисы, а также расширения для браузеров с более скромными возможностями. Софт как с бесплатной лицензией так и с платной.
Из популярных можно выделить:
— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;
— среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много — выбирай, осваивай, рисуй…
Общая структура ТЗ. От абстракции к конкретике
Одна из возможных структур сайта, подчеркну возможных, может выглядеть примерно так:
- Общая информация о сайте.
- Функциональное назначение сайта.
- Понятия и термины
- Описание модулей сайта
- Функциональные характеристики
- Описание страниц.
- Резервирование и надежность.
- Хостинг для сайта.
1. Общая информация о сайте
Здесь достаточно несколько предложений для того что бы ввести в курс дела, что за сайт или модуль будет разрабатываться и его цель в общем. Пишется вольным стилем.
2. Функциональное назначение сайта
Тут краткий перечень того, какими техническими средствами или инструментами должен обладать сайт, исходя из общей цели. Поясню на примере. Для сайта-визитки это может быть банально, форма обратной связи, перечень основных страниц, например с «о компании», «контакты» и прочие.
3. Понятия и термины
Этот раздел должен гарантировать понимание обеими сторонами специфических для данной предметной области понятий, которые важны для понимания и разработки сайта. Могут вводиться обеими сторонами.
4. Описание модулей сайта
Этот раздел включает список модулей, которые используются на сайте. Это вполне например может быть упоминаемая выше форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:
- Поле «Ваш имя»;
- Поле «Ваш е-mail»;
- Поле «Ваш вопрос»;
- Поле ввода капчи для защиты от спам-роботов.
И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса?» или что-то в этом роде.
5. Функциональные характеристики
Сюда можно отнести, например, список браузеров, где сайт должен корректно отображаться и работать. Например, некоторые заказчики могут требовать, что бы их сайт работал корректно и в небезызвестном Internet Explorer 6, что бы не терять хоть и небольшую, но долю возможных посетителей.
Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и по настройке сервера.
Также в функциональные характеристики входит наличие или отсутствие мобильной версии сайта, но это, как правило, либо уходит в отдельный раздел данного ТЗ либо вообще отдельно пишется.
6. Описание страниц сайта
Это довольно обширный пункт, где прорисовуются все страницы сайта и пишутся комментарии к их работе.
Также может приводиться общая структура страниц сайта. Так называемые «высокоуровневые» прототипы. Например, для простого сайта-каталога это может быть:
Для каждой конкретной страницы могут рисоваться прототипы с подробными комментариями по каждому из элементов интерфейса с их поведением.
Страницы, используемые для админ-панели обычно уазываются отдельно от спубличных страниц. Эти два раздела в свою очередь могут группироваться в свои отдельные подразделы. Здесь стоит следить, чтобы прототипы не конфликтовали с их описанием, и не возникало никаких противоречий. Примером прототипа определенной страницы сайта может быть:
Остальные страницы
Последние два раздела ТЗ мы не будет рассматривать детально, скажу вкратце, что одно из требований к надежности может включать настройку резервного копирования БД.
Требования к хостингу может включать доступную физическую память для сайта, пропускную способность канала, поддержку используемой базы данных и ряд других требований, предъявляемых для корректной работы сайта.
В конец ТЗ в обязательном порядке нужно внести информацию о том, что все работы, не описанные в настоящем ТЗ, выполняется по усмотрению программиста по очевидным причинам. Это наша «маленькая гарантия» от возможных доработок и переделок, выходящих за рамки ТЗ.
Выводы: Надо сказать, что такая структура разделов ТЗ не претендует на всю полноту (по крайней мере для больших стратегических проектов), но основные моменты все же охватывает.
Надо подчеркнуть, что всё вышеизложенное является только рекомендациями, основанными на опыте людей, работающих в сфере сайтостроения и никак не является жестким требованием, предъявляемым к написанию ТЗ.
Удачных Вам проектов и человеческого взаимопонимания!
Еще по теме:
- Что влияет на частоту индексации и как заставить поискового робота посещать ваш сайт чаще
- Зеркала сайта и объединение доменов
- Да будет SEO: 4 плагина для оптимизации сайта на WordPress
- Error 404 — что значит, как найти и исправить ошибку
- Что такое атрибут rel=“canonical”, когда и как его использовать?
От чего зависит скорость индексации сайта, как на нее можно повлиять и как сообщить роботу Яндекса и Google об изменениях на сайте. Читайте о том,…
Что такое зеркало сайта Зачем нужны зеркала Как определить зеркала сайта Как указать главное зеркало Как расклеить домены Мини-кейсы от Siteclinic 1. Как быстро восстановить…
Рассмотрим SEO-плагины для CMS WordPress, которые позволяют провести внутреннюю оптимизацию сайта. О некоторых плагинах я уже писала ранее. У плагинов, о которых расскажу в этой…
В этой статье мы разберём, что такое 404 ошибка, когда и каким образом она может навредить и как её отследить, а также приведём перечень рекомендаций…
В этой статье мы разберём, как и для чего нужно использовать атрибут rel=“canonical”, а также на конкретных примерах опишем, когда его лучше применять. Что такое…
Есть вопросы?
Задайте их прямо сейчас, и мы ответим в течение 8 рабочих часов.
Что такое техническое задание (ТЗ)?
Техническим заданием называется служебный документ с описанием правил выполнения работы и требований к исполнителю.
Почему важно зафиксировать весь процесс работы в виде технической документации?
- В ТЗ прописаны договоренности между исполнителем и заказчиком, которые сложно выразить в договоре из-за использования специфической IT-терминологии.
- Это сэкономит время на коммуникациях: зафиксированные технические решения избавят от многочисленных пересказов, подтверждений, путаницы в показаниях.
- Документ позволит четко разделить зоны ответственности между сторонами проекта.
- ТЗ дает возможность проанализировать будущий проект и выявить проблемы на стадии планирования.
- Правильно составленное задание сделает поведение всех участников работы предсказуемым и избавит от возникновения многочисленных недоразумений.
- С юридической точки зрения, наличие этого документа облегчит сторонам разрешение спорных моментов.
- Техзадание делает возможным финансовое планирование, что является залогом успешного бизнеса. Заказчику будет заранее видно, на что расходуются его средства.
У каждого проекта должны быть обозначены границы — по стоимости, объему выполняемых работ, срокам исполнения и качеству. Все это должно быть зафиксировано в ТЗ.
Если одна из сторон хочет сотрудничать без техзадания
Это может означать следующее:
-
Заказчик не устанавливает четких требований специально, чтобы затем получить часть работ бесплатно, либо он не уверен/не знает/не решил/не понимает, что ему надо.
-
Разработчик надеется на постоянное продолжение работ за счет заказчика, аргументируя это некой неопределенностью.
В такой ситуации противоположная сторона должна обязательно настоять на создании технического задания с четкими границами и определением задач. Без этого сторонам будет трудно доказать, что работы были сделаны, или, наоборот, не сделаны должным образом.
Участники проекта
| Заказчик | Менеджер проекта | Разработчики |
|---|---|---|
| Ставит задачу | Ставит задачу разработчикам | Выполняют задание в соответствии с ТЗ |
| Согласовывает ТЗ | Контролирует ход работы и расставляет приоритеты | |
| Принимает работу | Осуществляет взаимодействие с заказчиком и разработчиком | |
| Тестирует выполненную работу (если нет тестировщиков) |
Если проект большой, дополнительно могут добавиться участники:
- Product Manager
- Руководитель проекта
- Спонсор проекта
- Тестировщики
- Технические писатели
- Кураторы
- Пользователи/потребители (например, для финального тестирования)
- И др.
Если проект маленький, то заказчик и исполнитель, как правило, работают напрямую. В этом случае тестирование берёт на себя заказчик, а разработчик сам контролирует сроки и ставит приоритеты.
Что дает сторонам каждый раздел ТЗ:
|
Раздел ТЗ |
+ Для Заказчика |
+ Для Разработчика |
|---|---|---|
|
Определение цели |
Осознание задач, которые решает проект или его доработка |
Понимание сути задачи |
|
Описание продукта |
Представление о том, каким будет готовый продукт |
Уверенность в правильном понимании конечного результата |
|
Сроки выполнения |
Ориентирование в сроках работ и получения планируемых результатов |
Оценка трудозатрат и потребности в ресурсах |
|
Бюджет проекта |
Определение более-менее точной суммы затрат и планирование бюджета |
Согласованный учет всех работ проекта |
|
Перечень работ |
Подробное описание работ и каждого этапа реализации проекта |
Ведение работ по установленной технологии. Возможность отказаться от работ, не предусмотренных заданием, либо включить их в ТЗ за доплату |
|
Оценка результата работ |
Проверка работы проекта по программе тестирования на соответствие требованиям задания |
Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ |
|
Обслуживание проекта |
Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта |
Выполнение работ с учетом обслуживания проекта в перспективе |
|
Выявление проблем |
Планируемые доработки проекта |
Доработка в соответствии с новыми потребностями |
Последствия составления некачественного задания
-
Программист или команда разработчиков действуют «вслепую», несогласованно, не имея четкого представления о конечном результате проекта. Итогом будут зря потраченные время и деньги, испорченные отношения с заказчиком.
-
Результат проекта не соответствует ожиданиям заказчика. Потребуется дополнительный бюджет и время на доработки.
Обычно разработке качественного ТЗ мешают следующие моменты:
-
Заказчик не готов платить до 40% от стоимости проекта только за разработку задания. Например, можно еще до начала проектирования написать все тест-кейсы и заложить в ТЗ. Но в этом случае стоимость задания с тест-кейсами может превысить стоимость разработки, а его составление займет не один месяц. Зато это полностью снимает вопрос с ошибками в работе и упрощает приёмку.
-
Заказчик не знает всех деталей проекта до начала эксплуатации уже готового результата.
-
Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.
-
Исполнитель и заказчик не могут предвидеть заранее все возможные проблемы. Опытные участники проекта с обоих сторон могут заранее предусмотреть ряд типовых и уникальных проблем, но это не гарантирует, что вся работа над проектом пройдет гладко.
Например, забыли прописать в техзадании наличие одной кнопки, а после сдачи проекта оказалось, что без неё полноценно пользоваться системой нельзя. Для добавления же кнопки требуется переделать половину внутренней архитектуры базы данных, а значит и часть программного кода переписывать. Кто из сторон виноват в этой ситуации?
Большинство таких проблем решает Agile (гибкий подход к работе), но это не отменяет необходимость составления ТЗ. Используйте Agile при разработке любых проектов с высокой неопределённостью. Как правило, против этого выступают только заказчики, потому что они не видят точной границы цены и сроков. Зато финальный продукт гарантировано будет выполнять поставленные задачи — Agile в разы снижает число готовых проектов, которые были заброшены из-за того, что не выполняют своих функций.
Стороны должны понимать, что большинство проектов выполняется с большой долей неопределённости, и заранее договариваться, как будут взаимодействовать в случае возникновения проблем.
Техзадание должно отвечать на вопросы:
- Что? (какие работы, содержание элементов)
- Где? (расположение элементов)
- Когда? (последовательность выполнения и установленные сроки работ)
- Как? (технология реализации, оформление, принцип работы.) Как правило, у любого объекта должны быть функции: добавления, отображения, редактирования, удаления. А также описаны зависимости и взаимодействия с другими объектами. Иногда добавляются функции модерации, валидации, автообновления, архивации и т.п.
- Откуда? / Куда? (при переносе и т. п.)
- Зачем? (обоснование работ, если задание будет согласовываться с 3-м лицом)
- Особенности.
Основные рекомендации и пояснения по написанию ТЗ
- Чем больше масштаб проекта, тем более объемным должно быть техническое задание.
- Необходимо указывать реально осуществимые сроки выполнения работ с учетом времени на согласование проектной документации и приемо-сдаточных мероприятий. Стоит обратить внимание на ответственность заказчика за бездействие с его стороны или на форс-мажоры, тормозящие выполнение работ.
- Программисту нужны четкие условия. Формулировки “как вариант”, “примерно”, “около”, “где-то рядом”, “там, где лучше по вашему мнению”, — неприемлемы. Требования и характеристики, которые носят субъективный характер, бессмысленны с практической и ошибочны с юридической точек зрения.
- Чтобы сделать задачу по созданию какого-либо функционального модуля понятной для программиста, в техзадании размещают гиперссылки на те страницы, где есть нужные элементы интерфейса и функции, и дают к ним подробные пояснения. Также прилагают скриншоты с выделением интересующего фрагмента.
- Если дизайна для страниц нет или он не так важен для заказчика, программист может использовать прототипы, о чем после согласования указывается в задании.
- ТЗ должно быть удобным и понятным для всех сторон проекта, подробно описывать все этапы и подпункты даже по самым незначительным работам. Программист и менеджер не всегда имеют представление о том, что необходимо заказчику, поэтому важно своевременно обнаружить и согласовать все несогласованные детали.
7 типовых ошибок
- Нечеткие цели и задачи.
- Мало деталей в технической информации.
- Размытые или неустановленные сроки.
- Нет согласованности по всем вопросам между сторонами.
- Нет регламента взаимодействия.
- Нет ответственных лиц.
- Нет критериев оценки результата.
Пример правильного технического задания на доработку проекта
Задача:
Разместить на сайт www.site.name.ru новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.
Описание:
- ГДЕ? Добавить в главное верхнее меню сайта новый раздел «Ваш консультант» между разделами «Блог» и «Наши клиенты».
- КУДА? URL новой страницы сделать:
/vash_konsultant.htm - КАК? Макет новой страницы взять со страницы “Наши врачи”. Только вместо врачей будут консультанты.
- ЧТО? Структура страницы следующая:
- заголовок: Ваш консультант — по центру (в стиле других заголовков страниц сайта);
- 3 блока в ряд, имеющие поля:
- с фотографиями продавцов размером 400*600 (выравнивание по центру);
- Ф.И.О. продавцов под фотографиями (текстовый формат с возможностью правки);
- телефон общий у всех: 555-555-55 под Ф.И.О. (текстовый формат с возможностью правки);
- электронный адрес под телефоном (e-mail:
site2@mail.ru); - кнопка «Получить консультацию» ниже всех полей, размер кнопки, цвет и форма в стиле кнопок на сайте (см. кнопка «Сделать заказ» на url:
/katalog.ru).
- ОТКУДА? Данные консультантов должны правиться в редакторе сайта. Также должны редактироваться теги TITLE, DESCRIPTION, H1.
Если работы выполняются для целей SEO – не забывайте закладывать все необходимые элементы на странице.
Также внизу разместить форму заказа.
- ГДЕ? Под списком консультантов, над футером.
- ЧТО? Три поля:
- Имя
- Номер телефона
- Содержание заявки
- КАК? Обязательные для заполнения поля: Имя и Номер телефона. Оформление сделать по образцу формы обратной связи. Если обязательное поле не заполнено, то должно выводиться сообщение, как в форме обратной связи.
- КУДА? Заявку отправлять на email заказчика:
info@common.com - КАК? Оформление письма в свободной форме.
- ОСОБЕННОСТИ Защиту от ботов поставить, как на форме обратной связи.
При отправке заявки, если все заполнено правильно, в Яндекс-метрику должно отсылаться событие “Отправка заявки”. - НЕ ЗАБЫТЬ О ПРАВИЛАХ ПРИЁМКИ
Проверить:- На странице не должно быть незакрытых HTML-тегов.
- Проверить адаптив на мобильных устройствах Android с разрешением ***x**** и ****x****, и планшетах с разрешением 1280×1024.
- Проверить работу в браузерах Safari, Chrome, Mozilla.
PS. Стоимость и сроки исполнения, как правило, указываются отдельно в приложении к договору. Исполнитель выставит стоимость работ, исходя из прописанных в техзадании задач. Чем больше пожеланий – тем больше будет стоимость.
Online SEO-инструменты для продвижения сайтов
Проверьте свой сайт и сайты конкурентов на 205 факторов поисковых систем.
Как составить ТЗ для программиста?
Составление технического задания для программиста 1С
Многие сталкиваются с тем, что достаточно сложно объяснить коротко и ясно то, что мы хотим в повседневной жизни. А уж когда надо дать задание специалисту написать программу для организации или ИП с учетом особенностей и собственных пожеланий по функционалу, то можно вообще «зависнуть».
Позвоните или напишите в чат и мы совершенно бесплатно поможем Вам подготовить ТЗ по 1С!
Ссылка на шаблон технического задания.
Кто должен писать ТЗ?
Безусловно техзадание должен предоставить заказчик, т. к. он уж точно знает свои потребности и возможности. Но, как показывает практика, подавляющее большинство клиентов не компетентны в области 1С. Вот почему зачастую сам исполнитель вынужден вникнуть в потребности заказчика, понять какой конечный продукт ему нужен, и соответственно оформить все это в письменной форме для программиста.
Для чего необходимо техзадание?
При идеальном раскладе при той или иной доработке в программном продукте 1С необходимо техническое задание. Должны быть прописаны в первую очередь: задачи, сроки и способ исполнения.
Это важный документ, потому как при возникновении каких-либо спорных вопросов грамотная разработка техзадания станет отправной точкой в переговорах.
Составлять ТЗ или нет — решает каждый для себя, но это точно не будет лишним: упростит общение с клиентом и придаст работе деловой и конкретный характер.
Содержание ТЗ
Обозначим перечень наиболее важных пунктов, которые должны быть в техническом задании:
1. Цель/Задача. Сформулировать то, что должно быть реализовано в конечном итоге.
2. Описание. Вкратце изложить содержание планируемых доработок.
3. Способ реализации. Детально описать методы, с помощью которых должна быть достигнута цель. Следует прописать все особенности задачи на языке программиста: регистры, справочники (создать их или отредактировать); дизайн интерфейса и т.д. Для тех, кто не знаком и лишь что-то такое слышал про специфический язык программиста, советуем не делать ненужных попыток «заговорить» на техническом языке. Т.к. описание в идеале — это сухая констатация, исключающая неоднозначность и возможность возникновения лишних вопросов. Кроме этого этот пункт может включать в себя пример, как подобное программирование было уже исполнено где-то.
4. Оценка работы. Данный пункт очень важен — в нем нужно описать трудозатраты.
Еще два важных момента: есть утвержденные стандарты к написанию ТЗ — ГОСТы. Сейчас они редко используются, но некоторые клиенты могут по старинке просить использовать и их.
И второе, когда сдается работа может возникнуть и такое — «а мы же вроде как просили Вас сделать то-то и тогда-то…». Есть вероятность, что придется все начать делать с самого начала.
Поэтому, повторимся, что грамотно составленное ТЗ будет полезно как для заказчика, так и для исполнителя.
Пример ТЗ для программиста
Техническое задание 1С на доработку внешней обработки
Цель
Необходимо настроить выгрузку данных из 1С в АРМ банка.
Описание
В связи с переходом организации на конфигурацию 1С «Зарплата и кадры государственного учреждения» требуется разработка других обработок, которые осуществляли бы аналогичный функционал на новой конфигурации.
Выгрузка данных должна основываться на документах «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и «ВедомостьНаВыплатуЗарплатыВБанк».
Исходные данные
Имеющаяся обработка к конфигурации 1С «Зарплата бюджетного учреждения», осуществляющая выгрузку данных из документа «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и других справочников и регистров в файл DBF обмена данными с АРМ банка установленного образца.
Обработка выгружает данные в поля TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN соответствующую информацию из конфигурации 1С, предварительно занесённую в указанный документ и другие учётные таблицы. Выгружаются табельный номер, ФИО сотрудника, его паспортные и адресные данные, день рождения и гражданство.
Способ реализации
Это будут внешние отчёты и обработки с использованием механизма расширений, если текущие параметры совместимости базы и возможности платформы позволят это сделать. При изменении конфигурации базы следует создать: справочники, документы, регистры.
Оценка работы
Потребуется 5 рабочих дней работы программиста.
Отзывы о компании
-
Сивелькина С. В.
ПАО «НИКО-БАНК» выражает свою благодарность за оперативную и грамотную работу.
В условиях постоянно меняющегося законодательства Банк заинтересован иметь полную и актуальную номативную базу. Это обеспечивается использованием Банком справочно-нормативной системы «Гарант».
Безусловным плюсом в работе компании «МастерСофт» является быстрое реагирование сотрудников при предоставлении документов по запросу Банка, принятых до обновления справочно-правовой системы.
-
Мордвинцев С. П.
Коллектив компании «АЭРОПОРТ ОРЕНБУРГ» выражает благодарность за взаимовыгодное сотрудничество с МастерСофт-ИТ. Оперативная поставка антивирусных программ Dr. Web обеспечила надежную защиту нашей компьтерной сети.
Особая благодарность сотрудникам Департамента продаж СЦ ИТ за профессиональный подход в решении всех возникающих задач.
-
Ряховская Н. А.
ООО «Орский Вагонный Завод» выражает искреннюю благодраность за качество обслуживания вашими специалистами. Консультации и поставка антивирусов всегда проходят оперативно и на высоком профессиональном уровне.
Уверены, что и в дальнейшем наше сотрудничество на взаимовыгодных условиях продолжится.
-
Кетерер Т. М.
Главный бухгалтер муниципального бюджетного учреждения дополнительного образования «Дворец творчества детей и молодёжи» Кетерер Татьяна Михайловна выражает благодарность специалистам МастерСофт:
«Я хотела бы объявить благодарность вашим сотрудникам. Работает с нами по программе «1С: Бухгалтерия бюджетного учреждения 8» непосредственно Шевлягина Юлия.
Так же огромная благодарность за отзывчивость, терпение и квалифицированную, своевременную помощь Набокиной Олесе и Ерёменко Татьяне (они нас сопровождают по программе «Зарплата и Кадры»).
Им очень с нами тяжело, но они терпеливо продолжают сотрудничать. С вами очень надёжно. Конечно же наши ошибки есть и без вас мы бы вообще о них не знали и в суде, наверное, судились бы. А сейчас мы решаем вопросы…».
Вещи, которые по началу кажутся сложными, мы лучше понимаем на простых примерах.
Например, вы хотите, чтобы все данные с заявок на сайте автоматически попадали в список рассылки «Заказы с сайта». Давайте посмотрим, как ставить такие задачи программисту без необходимости хоть что-то понимать в программировании.
3 способа связать сайт с сервисом рассылок
Прежде всего, нужно решить, как связать сервис email-рассылок с вашим или CRM-системой.
Вы можете использовать:
- Готовые интеграции. Например, сервис UniSender интегрируется с популярными CRM-системами , CMS-системами и интернет-магазинами.
- Интеграции с помощью Zapier – специального сервиса, который позволяет связывать разные системы не привлекая программиста. Как связывать сервисы через Zapier.
- Интеграции по API.
Последний способ используется, когда готовых интеграций нет или нужно сделать что-то, что они не позволяют.
Поэтому советую изучить для начала, что можно сделать с помощью готовых интеграций. И только если нужную вам задачу невозможно решить, обращаемся к API.
Что за зверь такой – API?
По сути, это «язык», с помощью которого две системы (например, сайт и система рассылки) могут понимать друг друга и обмениваться данными.
API-документация — это развернутая инструкция для программиста, как организовать «общение» вашего сайта с системой рассылки, чтобы она совершала нужные действия в нужный момент.
Для того чтобы программист понял, что именно вы от него хотите, ему нужно это максимально детально объяснять.
Я в работе использую такую схему:
Пример работы этой схемы легко понять на известном меме:
А теперь разберём первую схему детальнее.
Что проработать в техническом задании. 5 элементов
1. Источник
Источник – это система, откуда мы берём данные.
Например, какой-либо сайт example.com или ваша CRM-система.
2. Триггер
Триггер – это событие, по которому данные должны передаваться.
Например, могут быть такие триггеры:
- посетитель на сайте заполнил и отправил форму «N»;
- пользователь зарегистрировался на сайте;
- авторизированный пользователь обновил данные о себе в личном кабинете, отписался от рассылки или изменил условия её получения;
- менеджер обновил статус клиента в CRM-системе на «N»;
- пользователь совершил заказ.
То есть, триггеры зависят от возможных действий пользователя на сайте или смены статусов в CRM-системе.
3. Данные
Какую именно информацию о пользователе мы передадим в систему рассылки, когда сработает триггер.
В большинстве случаев нужно передавать email-адрес и значения других полей, которые необходимо продумать заранее.
Например, на сайте есть форма заявки с такими полями:
- Ваше имя.
- Ваш email.
- Телефон.
- Город.
И мы хотим, чтобы данные автоматически попадали в группу «Заявки».
В системе рассылки поля «имя», «email» и «телефон» уже существуют по умолчанию. А вот поле «Город» нам некуда передавать, поэтому для начала его нужно создать в системе рассылки.
В сервисе UniSender это делается так: