Бывает так, что сайт уже готов, а в нем отсутствует какая-нибудь важная функция: программа рассылки, онлайн-калькулятор, нет нужных полей в 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
- Оценка задачи. Необходимо … рабочих дней работы одного разработчика.
- Бюджет … рублей.
Основные рекомендации и пояснения по написанию ТЗ
Каждое ТЗ для программиста является уникальным, но общие советы применимы ко всем заданиям. Вот главные рекомендации по написанию технического задания для программиста:
- Чем больше сам проект, тем больше людей задействуются в нем, техзадание соответственно увеличивается в объеме.
- Если нужно, то в техническом задании должны быть ссылки и скриншоты на необходимые элементы функций и интерфейса разработки с подробнейшими обоснованиями.
- Техническое задание должно быть понятным и удобным для восприятия. ТЗ нельзя присылать программисту в виде бесформенного «полотна», оно должно быть разбито на пункты. Все этапы проекта и подпункты по самым неважным на первый взгляд работам также должны быть внесены.
- Следует ставить реальные сроки работ. В них также необходимо включать время на согласование проектной документации между разработчиком и заказчиком.
- В ТЗ должна быть только четкая формулировка. Много проектов «заваливалось» или срывались его сроки выполнения только из-за того, что заказчик не смог нормально поставить конкретные технические условия.
- Заказчик должен писать в ТЗ, может ли программист применять прототипы, если в задании отсутствует дизайн для страниц.
Главные ошибки при составлении ТЗ
Каким бы грамотным специалистом не составлялось техническое задание для разработчика, все равно, фактически в каждом написанном ТЗ, имеются типовые ошибки. Рассмотрим самые основные из них:
- В техническом задании расплывчато проставлены задачи и цели проекта.
- Недостаточно технической информации. Конечно, программист в любое время может связаться с заказчиком, но на это тратится драгоценное дополнительное время.
- Нечеткие сроки выполнения задания.
- Несогласованность между заказчиком и исполнителем.
- В техзадании отсутствует единый регламент, который дополнительно помогает взаимодействовать между сторонами.
- В ТЗ не прописаны ответственные лица.
- Отсутствие в техническом задании составляющей, которая бы объективно оценивала полученный результат.
Итак, теперь можно приступать к написанию ТЗ, соблюдая все вышеперечисленные рекомендации, вы сможете составить действительно понятное и четкое техническое задание программисту.
Как создать ТЗ для программиста
Время на прочтение
6 мин
Количество просмотров 100K
Рекомендации геймдизайнеру от программиста (архитектора).
Вступление
Компьютерные игры — относительно молодая отрасль, которая в перспективе сменит киноиндустрию, так-же как кинофильмы заменили театр. Создание игры — это коллективное творчество, во многом напоминающее создание кинофильма. Кроме того, создание компьютерных игр — одна из самых сложных 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. Описание страниц сайта
Это довольно обширный пункт, где прорисовуются все страницы сайта и пишутся комментарии к их работе.
Также может приводиться общая структура страниц сайта. Так называемые «высокоуровневые» прототипы. Например, для простого сайта-каталога это может быть:
Для каждой конкретной страницы могут рисоваться прототипы с подробными комментариями по каждому из элементов интерфейса с их поведением.
Страницы, используемые для админ-панели обычно уазываются отдельно от спубличных страниц. Эти два раздела в свою очередь могут группироваться в свои отдельные подразделы. Здесь стоит следить, чтобы прототипы не конфликтовали с их описанием, и не возникало никаких противоречий. Примером прототипа определенной страницы сайта может быть:
Остальные страницы
Последние два раздела ТЗ мы не будет рассматривать детально, скажу вкратце, что одно из требований к надежности может включать настройку резервного копирования БД.
Требования к хостингу может включать доступную физическую память для сайта, пропускную способность канала, поддержку используемой базы данных и ряд других требований, предъявляемых для корректной работы сайта.
В конец ТЗ в обязательном порядке нужно внести информацию о том, что все работы, не описанные в настоящем ТЗ, выполняется по усмотрению программиста по очевидным причинам. Это наша «маленькая гарантия» от возможных доработок и переделок, выходящих за рамки ТЗ.
Выводы: Надо сказать, что такая структура разделов ТЗ не претендует на всю полноту (по крайней мере для больших стратегических проектов), но основные моменты все же охватывает.
Надо подчеркнуть, что всё вышеизложенное является только рекомендациями, основанными на опыте людей, работающих в сфере сайтостроения и никак не является жестким требованием, предъявляемым к написанию ТЗ.
Удачных Вам проектов и человеческого взаимопонимания!
Еще по теме:
- 6 плагинов для ускорения сайта на WordPress
- Гайд по robots.txt: создаём, настраиваем, проверяем
- Как оптимизировать страницы пагинации на сайте
- Обновление PageSpeed Insights: что изменилось, на какие метрики обращать внимание?
- Структура коммерческого сайта и SEO
Плагины, которые мы рассмотрим в этой статье, необходимо использовать для того, чтобы ускорить работу сайта и, как следствие, сделать его более удобным /привлекательным для пользователей….
В этой статье мы рассмотрим: Что такое robots.txt? Все директивы файла: Disallow и Allow Sitemap Host Crawl-delay Clean-param Использование спецсимволов Как проверить корректную работу файла…
Настройка SEO пагинации Рекомендации поисковиков Актуальные способы настройки пагинации Настройка каноникала на первую страницу Настройка каноникала каждой из страниц на себя Оптимизация каждой страницы пагинации…
1. Обновленный PageSpeed Insights Оценка скорости загрузки Данные наблюдений Имитация загрузки страницы Оптимизация Диагностика и успешные аудиты 2. Итоги Ни для кого не секрет, что…
Структура сайта и её влияние на SEO Этапы построения структуры сайта мозговой штурм анализ лидеров ниши сбор и кластеризация семантики прорисовка структуры и навигации Распространённые…
Есть вопросы?
Задайте их прямо сейчас, и мы ответим в течение 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. Структурированность информации
Важный принцип, соблюдение которого позволит и автору документа и его читателям быстро найти в нужную информацию.
Структуру ТЗ на можно разделить на 2 части:
- организационную;
- основную (тело ТЗ).
Когда вы приступаете к написанию документа, лучше сразу создать расширенную структуру ТЗ, которую в процессе работы уже можно будет дополнять. Уточните, есть ли в компании шаблоны документов, которые можно использовать для оформления организационной части ТЗ, если есть используйте их. Если нет — то шаблон, расписанный ниже.
В организационную часть входят:
- Титульный лист — наименование компании, кем утверждается документ (опционально), наименование документа, год создания документа.
- Оглавление — маршрутизация по документу. В Word есть удобный функционал для вставки и обновления Оглавления, используйте его.
- История изменений — нужный раздел ТЗ, который покажет разработчику и заказчику историю внесения изменений в документ. Например:
или
- Глоссарий — список сокращений и профессиональных терминов, которые используются в компании и документе — с пояснениями или ссылками на определения.
К основной части обычно относят:
- блок общей информации о ИС;
- детальное описание функциональных требований;
- нефункциональные требования.
Принцип 2. От общего к частному
Читая тот или иной документ, мы в первую очередь используем своего внутреннего визуала. Визуальное восприятие человека идёт «сверху вниз», то есть от общего к частному, и от крупных деталей к более мелким элементам.
Поэтому ещё один принцип, соблюдение которого сделает ваш документ более понятным и простым для восприятия — излагать информацию от общего к частному, от крупного к мелкому.
Помните, Техническое задание не художественный роман, и начинать документ с описания маленькой экранной формы (ЭФ) — плохая попытка заинтриговать читателей.
Как работает принцип «от общего к частному» покажу на примере расширенной структуры ТЗ.
В Блоке общей информации о ИС описывается:
- общая информация (цель создания ИС, её основное назначение и процессы какой предметной области должны быть реализованы в ИС);
- предполагаемый технологический стек, на котором будет реализована система или ссылка на архитектурное решение, где это определяется;
- перечисление выполняемых в ИС процессов/крупных функций;
- перечисление функциональных модулей ИС;
- интеграция — принципы интеграции; дополнительно опционально можно перечислить ИС, с которыми требуется интеграция.
Информация в данном блоке излагается крупно, ёмко, без деталей. Разделите Блок на подразделы. Как правило, Блок общей информации занимает в ТЗ не более 1,5–2 страниц.
Детальное описание функциональных требований
Это самый объёмный раздел ТЗ. По сути, его структура уже заложена списками бизнес-процессов/крупных функций и функциональных модулей, но теперь она расширяется и детализируется:
- Справочники — здесь описываются принципы использования справочников и списков, даётся список, справочников используемых в ИС. На этом уровне их можно разделить на группы: например, внутренние (ведётся в ИС, импортируется) и внешние. Описание каждого справочника, кроме наименования включает в себя: наименования атрибутов, коды атрибутов, их связь с другими справочниками.
- Роли — описываются ролевая модель: роли, функционал, кем и как администрируется.
- Функциональные модули — описываются принципы функционирования по каждому модулю из перечисленных в разделе «Блок общей информации —> Функциональные модули».
- Принципы построения интерфейсов ИС — описываются главное меню, если оно используется в системе. Также можно описать стандартные элементы экранных форм ввода и поиска.
- Список электронных сообщений, которыми система обменивается с другими системами. Раздел опциональный, информацию удобно оформлять в таблице — с явным указанием признака «входящее сообщение/исходящее сообщение».
- Реализуемые процессы — описываются алгоритмы выполнения каждого процесса в ИС из перечисленных в разделе «Блок общей информации —> Процессы». Описание процессов лучше всего располагать в логической последовательности.
При описании алгоритмов выполнения процессов нужно обязательно указать ролевую модель, справочники и тип процесса: ручной/полуручной/автоматический. И указать позитивный и негативный пути.
Для ручных процессов нужно прописать алгоритм выполнения от действий пользователя в системе — с указанием наименований экранных форм и используемых функциональных кнопок. Для автоматизированных — указать событие, инициирующее процесс, точки контроля выполнения процессов, результат выполнения. То есть артефакты, которые готовит система в процессе выполнения и по результатам конкретного процесса.
Если в рамках процесса ИС получает или формирует электронные сообщения, разработчику важно написать парсинг, который покажет, как разбирать и обрабатывать приходящие данные, как формировать сообщения и куда их отправлять. Этот раздел лучше оформлять в таблице.
Минимальное описание ЭФ включает
- Наименование поля на ЭФ.
- Тип и длина данных (на ЭФ и в базе данных, если отличаются).
- Обязательность (используют три варианта: О — обязательное, Н — необязательное, УО — условно/обязательное). Для УО в обязательном порядке прописать условие, при котором поле становится обязательным.
- Способ заполнения поля:
- ручное, автоматическое;
- выбор из выпадающего списка — перечисляем значения списка или даём гиперссылку на описание;
- выбор из справочника — даём гиперссылку на описание;
- чекбокс — описываем значения чекбокса;
- Проверки — описываются бизнес- и автоматические проверки поля.
- Маппинг на физическую модель данных (при необходимости).
Описание экранных форм (ЭФ) удобно давать в табличной форме.
Требования к печатным формам должны содержать
- шаблон печатной формы (со статической частью и динамической частью с маппингом на данные);
- алгоритм и режим формирования отчёта.
Требования к реализации ЭФ и ПФ можно оставить по тексту описания процессов. Но если таких описаний много и/или они объёмные, то лучше их вынести в отдельный раздел или приложение. А при описании давать гиперссылки на описание конкретных форм приложения.
Нефункциональные требования
Они могут относиться к системе в целом и к реализуемым процессам и функционалу в частности. Например: скорость отклика, режим доступности, пиковые нагрузки в периоде и тому подобное.
Принцип 3. Убрать информационный шум
Информационный шум — это элементы, усложняющие понимание текста, искажающие его смысл — или вовсе препятствующие адекватному пониманию содержания.
Если в документе сильный информационный шум, работать с ним сложно и автору, и уж тем более потребителям.
- В ТЗ не должно быть несогласованных предложений, бесконечных причастных и деепричастных оборотов, лексических и орфографических ошибок. Перечитывайте написанное перед отправкой документа на согласование. Хорошо, если дополнительно это будут делать коллеги, у которых не замылен глаз.
- Единое форматирование текста в документе и его приложениях обязательно. Разные шрифты, внезапный капслок или курсив, разные отступы и выравнивание абзацев, необоснованное цветовое выделение текста, отсутствие единого оформления заголовков и таблиц — всё это создаёт сильный информационный шум.
- Технические правки в документе, визуализируемые редактором в режиме рецензирования (например, форматирование, обновление ссылок или нумерации), нужно принимать перед отправкой на согласование документа.
- Описания однотипных объектов (например, справочников, ЭФ и ПФ) должны быть одинаковыми по форме и по составу данных. Массивные описания ЭФ и ПФ могут стать информационным шумом для описания реализуемого процесса. Решение одно — группируем и выносим в отдельный раздел или приложение.
Дополнительные артефакты ТЗ
Если разрабатываемая система будет обеспечивать выполнение STP-процессов с использованием электронного документооборота с внешними контрагентами удобно приложить DocFlow обмена электронными сообщениями:
Разработчик отсюда поймёт, как выполняется процесс, какие сообщения приходят на вход и выход, что нужно реализовать. А тестировщик сможет лучше протестировать сквозной процесс.
В некоторых ТЗ рисуют user story. Это помогает описать клиентский путь, адекватно спроектировать действия пользователя в системе и сделать user friendly интерфейс. С user story проще согласовывать ТЗ с заказчиком и делать тест-кейсы.
Полезно будет привести для разработчика в ТЗ диаграммы статусов пользователя и/или объекта учёта:
Что ещё важно
- ТЗ должно быть полным, нельзя пропустить раздел, потому что «тут и так всё понятно».
- Язык должен быть простым — насколько это возможно. «Хардовой» профессиональной лексики — немного, а все термины — объясняться в глоссарии. Помним, что уровень экспертизы потребителей документа может быть разным.
- В предложениях не должно быть двусмысленности, иначе появятся избыточные вопросы и замечания на этапе согласования. И велик риск, что разработчик реализует по ТЗ «как понял», а тестировщик «протестирует не то и не так».
В завершение хочу напомнить, что техническая документация, которую вы разрабатываете, — ваше лицо. Именно по документам, в первую очередь, судят о вас, как о профессионале. Поэтому ваша задача — сделать всё, чтобы подготовить идеальное ТЗ для разработчика и заказчика и по сути, и по форме.
Мы в Интерлогике постоянно пишем ТЗ для программистов 1С! Поэтому решили с вами поделиться информацией, как сделать это правильно.
Я редко взаимодействую с программистами. За это у нас отвечает Анатолий. Если вам понадобится помощь с поиском разработчика или написанием техзадания — то на консультации встретитесь с ним.
Ключевое, что нужно запомнить: идеального техздания — нет! Поэтому не заморачивайтесь особо над «правильностью»
👋 Привет! Меня зовут Алексей! Я руковожу Интерлогикой, и мы занимаемся автоматизацией управленческого учёта и бизнес-процессов. А ещё я провожу консультации, иногда пишу статьи, в которых отвечаю вопросы читателей, вы, кстати, тоже можете задать вопрос в форме, которая в низу страницы, ну или +7 (495) 764 83 81 , или через телеграм @Interlogik
Кто должен составлять ТЗ для программиста 1С
Считается, что техническое задание составляет заказчик и передаёт его программисту! С одной стороны — это так, с другой — точно нет!
В пользу «заказчик составляет ТЗ» — только конечный заказчик, пользователь 1С в полной мере понимает, что он хочет получить и что ему надо.
Но при этом заказчик не обязан вникать и разбираться в технических нюансах. Да и редко разбирается! В итоге у заказчика почти никогда нет возможности написать внятное ТЗ.
В этом случае, самый лучший ход — разработчик должен сам взять необходимую информацию и пожелания у заказчика. Написать техническое задание под себя. И согласовать его!
В Интерлогике Анатолий берёт необходимую информацию у заказчика, переводит её на язык программистов и нанимает нужных людей. С точки зрения разработчика — мы заказчики.
Как выглядят технические задания
Мы встречали самые разные форматы техзаданий! Были глупые и бесполезные, были и такие, что составлялись лишь для «отъёма денег», были и из одной строчки: «Сделайте, пожалуйста, чтобы финрезультат считался». Помню задания на пятьдесят страниц, оформленных по ГОСТу. Но объём — не определяет качество ТЗ!
Задача техзадания — упростить коммуникацию между заказчиком и исполнителем, ускорив разработку и не потеряв информацию. ТЗ хоть и документ, но он не должен плодить бюрократию! Поэтому маленькие задачи могут выглядеть, как короткое сообщение в Телеграме!
Структура ТЗ
Предлагаю использовать следующую структуру ТЗ:
- Дано (что имеется у клиента, обычно речь про программы и версии);
- Что изменить (цели разработки);
- Что Сделать (конкретные шаги изменения, лучше описывать через юзер-стори);
- Сдача (при каких условиях задача считается принятой).
Такая структура удобная для описания задач на 1-50 часов работы. Разберём элементы структуры подробнее.
Цель. Пункт подсказываем программисту 1С, что и как следует думать пользователю, чтобы выполнить бизнес-процесс.
Дано. Объясняем разработчику, с чем ему работать: программы, техническое окружение и так далее.
Что нужно сделать. Лучше объяснять с точки зрения пользователя, используя юзер-сторис из эджайла.
Как принимается работа. Важный пункт, который объяснит как принимается работа, при каких условиях он получит деньги. Это поможет заточить работу на работающий модуль и учёт, вместо следования букве ТЗ.
А что насчёт бюджета, разве в правильно составленном ТЗ он не должен быть?
Хороший вопрос! Нет, не должен быть! =) Бюджет — важен, но когда ТЗ пишет благополучатель, то он, вероятно, не понимает тонкости разработки. Может недооценить сложности и спугнуть разработчика или наоборот, заплатить больше. Будет выглядеть или как «Хочу из Сыктывкара долететь до Чикаго! За 5000 рублей!» или перебор «Вот вам 10 тысяч рублей, дайте мне чашку кофе». Лучше взять консультацию и выяснить «сколько это должно стоить.
Дедлайны. Ко срокам относитесь так же как и к бюджеты — они должны быть реалистичными, для этого лучше консультироваться со специалистами.
Рекомендации и пояснения по правильному составлению ТЗ для программиста 1С
Вот главное:
- Чем больше проект, тем больше людей, следовательно, и ТЗ раздувается. Таким образом, ТЗ придётся переписывать. Сроки удлиняются. Постарайтесь разбить проект на мелкие подпроекты и каждый закрывать отдельно: свой ТЗ, свой счёт и акт выполненных работ.
- Не стесняйтесь референсов. Если есть возможность, дайте больше скриншотов, примеров, описаний, юзер-историй.
- Структура. Позаботьтесь о редактуре ТЗ: главы, пункты, последовательность от А до Я. Структуру я вам дал. Не присылайте полотно текста.
- «Торгуйтесь». Проконсультируйтесь со специалистами о реальном сроке и стоимости работ. Мы в этом с радостью поможем!
Избегайте этих ошибок при составлении ТЗ для программиста 1С
Рассмотрим основные:
- Абстракции. Проговорите голосом ТЗ, убедитесь, что исполнитель будет делать ровно то, что нужно вам, а не то, что соответствует букве ТЗ. Впрочем, если ваши ожидания расходятся с записями — скорректируйте записи.
- Больше данных. В теории разработчик может написать заказчику и задать вопросы о программах, техническом окружении и прочие вещи. В реальности такое происходит редко. Часто разработчик садится «в последний день», когда выясняет, что ему нужна какая-то деталь. И начинается запоздалое «дёрганье». Сразу всё распишите и дайте пароли-явки, для самостоятельного выяснения.
- Условия приёмки и «штрафы». Обязательно чётко пропишите, при каких условиях разработка будет принята и оплачена. Больше внимания на «способность решить задачу», чем на «срыв дедлайна». Когда разработчик понимает, что запороть программу страшнее, чем просрать сроки — разработка делается от души и правильно.
- Ответственные. Укажите контакты ответственных лиц. Позаботьтесь о запасных, в случае недоступности или внезапных увольнений. Иногда мы нанимаем «школьников-фрилансеров» и не стесняемся, в этом случае, брать телефоны родителей-бабушек. Чтобы в случае чего успешно связаться с разработчиком. Интересно, что нам ни разу не приходилось звонить бабушке, разработчику достаточно просто знать, что у нас есть такой рычаг влияния.
- Вместо описания формы ввода опишите состав информации, которая есть у пользователя на начала бизнес-процесса и состав команд, которые ему доступны.
- Не описывайте алгоритмы! Лучше смысл этапов бизнес-процесса и ограничения.
👉 Нужна помощь в написании ТЗ? Мы готовы помочь, для этого оставьте заявку на странице консультацией, или сразу свяжитесь с нами по телефону +7 (495) 764 83 81#nbspили через телеграм @Interlogik
Эти ссылки для дополнительного чтения, мы отобрали вручную!
— Как составить идеальное ТЗ
— Как и где найти программиста 1С
— Консультации по автоматизации управленческого учёта