Рассказываем главные требования для создания технического задания и описываем пользу, которую оно принесет.
В этой статье мы рассказываем о базовых пунктах, по которым исполнители или клиенты создают техзадание: требования к работе проекта, инструменты для исполнения, выбор хостинга, структура и другая информация, которая нужна для написания сайта. Написать универсальный образец ТЗ для создания сайта невозможно — у каждого бизнеса есть уникальные задачи и требования к ним. Поэтому некоторые этапы из статьи могут вам не подойти.
07.02.2022 · 15 минут
Прежде чем приступать к разработке, нужно составить техзадание для правильной работы.
Что такое техзадание и для чего оно нужно
Техническое задание — документ или несколько документов, которые дают информацию о том, каким будет проект.
Исполнитель или клиент пишет техзадание для всего проекта. Далее оно будет делиться на другие техзадания для разных видов работ и соисполнителей.
В техзадании фиксируют все требования, по которым создаётся проект. Важно, чтобы все условия были расписаны подробно, чтобы все стороны лучше понимали, что должно получиться в результате.
Как системному аналитику ставить задачи на разработку
Кто составляет техзадание
Бизнес-аналитики получают заказ от клиента, выслушивают требования, пожелания и составляют ТЗ. После они несут его на согласование с разработчиками, дизайнерами, контентщиками и другими участниками процесса, которые будут исполнять заказ. После их правок, аналитики создают окончательный вариант технического задания, которое согласовывает и подписывает инвестор, а после аналитики передают документы в работу. В некоторых компаниях техническое задание на разработку сайта составляют менеджеры проекта, разработчики или менеджеры по работе с клиентами. Бывают случаи, когда сам работодатель составляет документацию.
Человек, который составляет техзадание, если это не заказчик, может принадлежать к разным отделам: проджект-менеджер, бизнес-аналитик. Все зависит от специфики задачи. Если нужно сделать сайт-визитку, то в данном случае бизнес-аналитик не обязателен, так как у клиента уже есть четкое представление, что он хочет.
Однако, если это просто идея, то в таких случаях для составления тз может потребоваться аналитик. Например, нужно создать платформу по продаже автомобилей. Разработчик не может сделать хороший продукт, так как просто не разбирается в предметной области. Для этого аналитик проводит исследование: что удобно пользователю, какие нужны фильтры, что есть у конкурентов. После сообщает клиенту и разработчикам, что должно быть на сайте, чтобы закрыть потребности пользователя.
Борис Качанов. Frontend-разработчик
Польза техзадания для исполнителя
• Понятно чего хочет инвестор.
• Исполнитель сразу понимает сможет ли он написать задуманное.
• Защищает разработчика от внезапных изменений в пожеланиях инвестора, то есть он делает только то, что есть в документах, даже если клиент внезапно захочет поменять все на половине пути, то согласованное ТЗ не даст ему это сделать.
Как написать понятное ТЗ, разделы. Советы от экспертной группы Бизнес-аналитика SDC
• Правильный пример ТЗ на создание сайта облегчает процесс выполнение задач.
• Техзадание помогает выбрать правильные инструменты для разработки.
• Исполнитель сможет рассчитать приблизительное время работ и стоимость.
Польза техзадания для клиента
• Клиент понимает, что он получит в результате, сколько процесс создания займет времени, а также за что он заплатит деньги.
• Если задача выполнена, то можно пройти по пунктам и удостовериться, что другая сторона сделала все по ТЗ.
• Есть возможность заменить рабочего с минимальными потерями для дела.
• ТЗ отсеивает некомпетентных людей. То есть можно собрать команду, которая справится с поставленными задачами.
Работать по техзаданию проще, так как исполнитель сразу понимает, что от него требуется, а заказчик видит, что он получит в результате. Кроме того, клиент и разработчик уверены в том, что они общаются на одном языке. Техническое задание на создание сайта дает гарантии для обеих сторон: во время сдачи проекта происходит сверка по техзаданию и устанавливается завершенность или незавершенность работы.
Бывают примеры, когда уже в согласованном техническом задании могут произойти изменения, так как предусмотреть все возникающие в процессе работы проблемы невозможно. В таких случаях, пути их решений обсуждаются с заказчиком.
Борис Качанов. Frontend-разработчик
Что должно быть в техзадании
Составлением техзадания занимается специалист. Однако, если техническое задание было отдано в руки бизнес-аналитика, то клиент все равно остается непосредственным участником.
Чаще всего типовое ТЗ на разработку сайта содержит данные об общей информации по задаче и всем страницам, требованиях к дизайну и прототипированию, о требованиях к сайту, описание основных инструментов и информацию о структуре. Разберем каждый пункт.
Общая информация
Все работники должны понимать в чем состоит предназначение будущего проекта: личный блог, интернет-магазин, информационный портал. А также, что будет на сайте: каталог товаров, корзина, блог, форма заказа, доставка, о нас, обратная связь, чтобы не получилось следующей ситуации:
Разработчик представляет, что нужно сделать такую страницу:
А после приходит пример страницы от работодателя. Здесь становится понятно, что заказчик видит задачу иначе:
То есть первоначальная оценка сроков и финансовых трат, которые озвучил исполнитель на основании своих умозаключений, отличается от того, что хочет заказчик.
Основополагающие вещи, которые зависят от специфики проекта, должны быть в техзадании. Однако незначительные вопросы, которые возникают по ходу разработки, например, размер шрифта внутри кнопки «вход», можно решить в личной переписке с клиентом без составления дополнительного ТЗ.
Борис Качанов. Frontend-разработчик.
Глоссарий
Техзадание разрабатывают для разработчиков, дизайнеров, контентщиков и для заказчика, поэтому стоит расшифровать сложные термины, которые присутствуют на всех страницах и написать их понятным для работодателя языком.
Дизайн и прототипирование
Пример дизайна в ТЗ на сайт должен обладать хотя бы базовыми вещами: цветовая гамма, шрифт, брендбук. Важно расшифровать все свои желания, преобразовать их в понятные задачи для исполнителя. То есть, если клиент хочет сделать акцент в дизайне за счет зеленого цвета, то нужно указывать имя цвета, например, «MediumSeaGreen – #3cb371».
Четко формулируйте свои требования. Например, «красивый, современный дизайн» — это не техзадание, так как такая формулировка не содержит конкретики. Инвестор должен пояснить, что он понимает под словами «красивый» или «современный», а еще лучше — показать что он понимает под словами «некрасивый» и «не современный».
Клиент сам или вместе с аналитиками и дизайнерами готовит разработчикам прототип. Макет делают для главной страницы, так как это первая страница, на которую попадает посетитель. Делать прототипы для всех разделов не нужно, но нужно создать отдельные примеры для уникальных страниц, а также один общий для типовых.
Если исполнитель просто говорит, что ваша идея неудачная, то это ничего не значит, так как здесь нет конкретики. Попросите объяснить на примере, как лучше сделать. Например, заказчик хочет создать сайт-визитку из нескольких страниц, но такой формат — не самое удачное решение. Поэтому мы, как разработчики, показываем существующие одностраничные сайты-визитки и предлагаем написать что-то подобное. Однако, если клиент настаивает на своей версии, то исполнитель сделает то, что он хочет.
Борис Качанов. Frontend-разработчик.
Требования к работе сайта
Требования нужны для разработчика, чтобы он понимал масштабы проекта, какая целевая аудитория у сайта, под какие нужды надо адаптировать сайт и для того, чтобы разработчик мог запланировать модернизации в будущем.
• Поддерживаемые браузеры и их минимальные версии.
• Количество возможных пользователей единовременно.
• Адаптируемость сайта под разные размеры экрана. Например, если нужно сделать интернет-магазин, то адаптируемость под экраны телефонов поможет клиенту в будущем сэкономить на создании отдельного приложения для мобильных устройств, так как в интернет-магазинах часто делают заказы через смартфон.
• Локализация. Здесь перечисляют все языки, которые будет поддерживать сайт. Если целевая аудитория — пользователи из-за рубежа, то добавление других языков поможет улучшить их пользовательский опыт и приведет к последующей коммерческой выгоде. Например, интернет-магазины, которые продают свою продукцию по всему миру (Aliexpress, iHerb, eBay, ASOS) или сайты-визитки, должны быть на тех языках, с какими странами вы работаете.
Описать инструменты и требования к хостингу
Указать, на каком хостинге находится сайт. На этом этапе разработчик объясняет клиенту, что размещение на хостинге — это либо аренда места, либо его покупка.
Среди хостингов используют: TIMEWEB — функциональность платформы можно опробовать в течение 10 дней, базовый пакет стоит 169 рублей в месяц; BEGET — платная платформа с пробным бесплатным доступом на 1 месяц; REG —цена от 98 рублей в месяц с пробным периодов в 14 дней, здесь есть конструктор сайтов; SPRINTHOST — бесплатный период составляет 30 дней, цена стартового пакета составляет 118 рублей в месяц.
Структура сайта
Если уделить структуре портала недостаточно внимания, то навигация по сайту будет непонятной. Пользователь не разберется и просто уйдет.
Для правильно структуры нужно указать следующие данные:
• Маршрутизация: перелинковка, переадресация.
• Пояснение к каждой странице сайта. Исполнитель и клиент должны знать, какие элементы на странице будут и какие функции они несут.
• Расписать сценарии работы пользователя на сайте. Расписывать алгоритмы действий пользователя нужно, чтобы стало понятно, какие функции будут выполнять элементы сайта. Например, пользователь заходит на сайт магазина → регистрирует или входит в свой аккаунт → выбирает фильтр по телефонам → добавляет тот, что понравился в корзину → оформляет заказ.
Количество действий зависит от сценария. Важно понимать, что чем подробнее он описан, тем проще разработчику учесть и понять все аспекты, а клиенту проверить их.
Вид контента
Сайт будет выглядеть пустым, если на страницах нет никакой информации. Кто будет создавать контент, а после его размещать обсуждается с заказчиком. Критерии оценки текста нужны, но они не должны быть двусмысленными или пустыми. Например, такие критерии, как «уникальный», «достоверный» и «без ошибок» подходят для требований к материалу, но «красивый» или «интересный» — нет. Все это нужно отразить в ТЗ на разработку сайта и написать пример текста для одной или нескольких страниц.
Прежде чем подписать техзадание, работодатель должен донести свои ожидания и идеи, а исполнитель должен быть уверен в том, что клиент полностью озвучил свои пожелания и не будет их видоизменять в процессе, так как на создание одного вида проекта рассчитывается время и закладывается бюджет. Однако, если в ходе разработки работодатель решил добавить новую функциональность, например, в личный блог про овощи добавить страницу с возможностью их продажи, то он должен понимать, что на удовлетворение этих требование уйдет больше времени и денег, чем запланировано изначально, так как к одному виду сайта нужно будет добавить другой.
Источник: lpmotor.ru
Техзадание на салфетке: как упростить реализацию дашборда
Наличие грамотно составленного технического задания – обязательно условие для успешной реализации проекта автоматизации корпоративной отчетности. Оно поможет и исполнителю избежать бесконечного процесса доработок, и заказчику получить эффективный инструмент работы с нужными данными.
Однако далеко не всегда руководство компании понимает, что именно должно быть включено в ТЗ. А следовательно, на создание и согласование самого ТЗ, в котором задача будет прописана максимально точно, можно потратить несколько месяцев. Это, разумеется, будет серьезным ударом по эффективности работы.
Понятно, что нужна схема работы, которая позволит одновременно и избежать бюрократии, и избежать взаимного недовольства исполнителя и заказчика. Я уверен, что необходимо итерационно заниматься созданием конечного визуального продукта. И для этого за годы работы мною найден простой, но действенный инструмент.
Техзадание на салфетке
Давайте признаем: требовать от клиента четко и детального ТЗ с алгоритмами всех показателей бесполезно. В лучшем случае ответ на такой запрос мы получим требование 100 метрик на одном дашборде в режиме реального времени. В худшем – предложение сделать несколько рабочих вариантов, из которых и будут выбирать нужный для доработки.
Чтобы работу можно было начать без проволочек, я использую короткую форму брифа из 6 пунктов, разделенных на две колонки. В правой содержится творческая составляющая, ассоциации: это пункты «заказчик», «выводы», «решения».
А в левой – логика построения и факты по существу: например, в каком формате будет представлен отчет, с какой периодичностью должны обновляться данные, какие ключевые количественные показатели и в каких разрезах (фильтрах, категориях) будут отображены.
Здесь также три пункта: «формат и период», «ключевые показатели» и «категории и фильтры» Именно левая часть служит основой для визуализации, поэтому поговорим о ней подробнее.
Формат и период
Формат – это первое, с чем стоит определиться. Речь идет про реальный сценарий использования аналитики, про то, как именно планируется работать с данными – смотреть на экране проектора, в BI-приложении на планшете, в Excel на ноутбуке или только на бумажных распечатках. Если это не обговорить в начале пути, вероятность того, что проект придется переделывать полностью, будет очень высока.
Период должен фиксировать, как часто отчетом будут пользоваться: раз в день, в неделю, в месяц, в квартал или в год. Понятно, что если показатель анализируется два раза в год, то тратить ресурсы даже на еженедельное его обновление смысла нет.
Ключевые показатели
Нужно уже на первом этапе выделить самые важные количественные показатели, которые должны быть отражены. Это может быть прибыль, выручка, продажи, численность работников, ФОТ и любой другой в соответствии с целью отчета. Будет ли этот показатель включать множество составляющих, можно будет определить и потом.
Категории и фильтры
В данном пункте необходимо прописать, как необходимо детализировать ключевые показатели. К примеру, топ-менеджер может потребовать фильтровать сделки по типу клиента, но в базе исходных данных такого атрибута нет. Чтобы реализовать подобный фильтр, надо будет либо заполнить это поле в источнике данных, либо сделать агрегированный промежуточный расчет.
Теперь посмотрим более детально на правую колонку. Если с параметрами, включенными в левую часть брифа, у аналитиков обычно нет сложностей, то с описанием правой части они могут возникнуть. Однако пренебрегать этим не стоит: именно в правой колонке находятся вопросы, больше всего влияющие на успех проекта.
Заказчик
Необходимо точно определить, кто будет основным пользователем, ведь универсальных дашбордов не существует. Директору по продажам и финдиректору интересны разные наборы показателей, а следовательно, и отчеты должны быть персонализированы. Особенно важно учитывать реального пользователя: мы можем готовить отчет для гендиректора, а в действительности им будет пользоваться заместитель, тогда как гендиректор будет только подписывать документы. Даже это может влиять на желаемый результат проекта.
Выводы
В этом пункте нужно прописать, какие выводы можно будет сделать, глядя в отчет: где отклонения, проблемы, задержки сроков или другие параметры. Это преобразование данных в информацию, но еще не принятие решения. Вывод логически исходит из показателей и категорий в отчете, правильно представленных на диаграммах. Например, помесячный график выручки растет вверх, а рентабельность падает. А рядом мы видим список убыточных проектов.
Решения
Понятно, что ни один дашборд в явном виде не предложит решение проблемы и не даст инструкции по дальнейшим бизнес-действиям. Его придется принимать заказчику, в том числе учитывая дополнительную внешнюю информацию или собственный опыта. И все же нужно понимать, что решения должны соотноситься с выводами.
Например, логическим решением при низкой конверсии агентских продаж будет увеличение комиссионных ставок, а при падении продаж в отдельном сегменте – увеличение рекламного бюджета.
И если такой логической связи между выводом и решением нет, то что-то в брифе пошло не так. Не нужно бояться, что заказчик подумает, что мы лезем не в свое дело. Хороший руководитель поймет, что это необходимо для того, чтобы сделать отчет полезнее. Также важно помнить, что все варианты решений просчитать нельзя, но выделить пару вариантов, чтобы связать части брифа между собой, вполне возможно.
КЕЙС: Структура себестоимости
Давайте рассмотрим применение ТЗ на салфетке на реальном примере.
В одном из крупных агрохолдингов назревал конфликт между экономистами, ежемесячно предоставляющими финдиректору огромный отчет по структуре себестоимости, факторам отклонений от норматива, детализации по каждой статье, и финдиректором, который все равно вынужден был требовать дополнительных разъяснений.
Получалось, что при наличии всех необходимых данных, сделать их основой для принятия управленческих решений было крайне трудно, если не невозможно. В процессе беседы с заказчиком мне удалось сформировать следующее техзадание на салфетке.
Заполнение первой строки таблицы прошло легко. Заказчик – финансовый директор. Формат и период – ежемесячный дашборд в Excel.
Заполняем левую часть дальше. Ключевой показатель – себестоимость 1 кг продукции, план-факт и отклонение. Этот KPI директору важно видеть по фабрикам, статьям затрат и в помесячной динамике – это вносим в ячейку «категории, фильтры».
Переходим к пункту «выводы»: заказчику необходимо понять, кто виноват в превышении норматива себестоимости. Статей затрат много, но они сводятся к двум группам: те, за которые отвечает сама фабрика, и те, которые формируют конечную себестоимость (маркетинг, логистика и прочие вспомогательные службы).
Что вносим в ячейку «решения»? На основе полученных данных финдиректор принимает решение, платить или нет премию директору фабрики. Если норматив себестоимости превышен, это плохо. Но если при этом фабрика уложилась в свои лимиты, то она получает свой бонус.
Результатом ТЗ на салфетке стало то, что мы получили возможность сфокусироваться на самом важном и не утонуть в согласовании второстепенных деталей. Уже можно нарисовать эскизы для будущей визуализации – как бы на «обороте салфетки» – и сразу показать их заказчику.
- горизонтальная водопадная диаграмма, на которой мы видим промежуточную производственную себестоимость и итоговую с учетом всех сопутствующих расходов;
- рейтинг фабрик по себестоимости;
- помесячная динамика плана и факта.
Источник: alexkolokolov.com
Техническое задание на внедрение Google Analytics
Сегодня предлагаю рассмотреть справочный материал, который должен помочь клиенту и подрядчику общаться на одном языке.
При обсуждении работ по внедрению (установке) Google Analytics или любой другой системы веб-аналитики на сайт между заказчиком (клиентом) и подрядчиком возможно возникновение ситуаций, когда обе стороны не понимают того, что хочет от них услышать/получить оппонент.
Я постараюсь дать некоторые пояснения для стороны клиента, чтобы информация получаемая подрядчиком для оценки объема работы и планирования сроков получалась объективной.
Итак, общий вопрос — мне нужно настроить Google Analytics, сколько это стоит, я не считаю верным изначально. Для решения подобной задачи нужно как минимум предоставить информацию:
- что уже настроено в Google Analytics (если он уже используется);
- какой способ настройки планируется использовать (через код отслеживания или с помощью Google Tag Manager);
- есть ли необходимость в настройки электронной торговли (если да, то классический или расширенный вариант будет использован);
- какие цели преследует установка на сайте Google Analytics.
В зависимости от ответов на эти вопросы будет формироваться стоимость и планироваться сроки выполнения работ. Прежде чем обращаться с вопросом о настройке Google Analytics, я бы рекомендовал владельцу сайта (клиенту) подумать над ответами на эти вопросы. Их все равно придется решать, даже если вам сразу назовут примерную или начальную стоимость выполнения работ.
Разумеется, что эти вопросы зачастую требуют пояснения со стороны подрядчика, по причине неосведомленности во всех тонкостях вопроса клиента, но ответы на них помогут выстроить более продуктивный диалог и подрядчику и клиенту.
Следующий момент, это предварительное определение элементов подлежащих отслеживанию на сайте. Желательно клиенту иметь свое видение этой проблемы, но и подрядчик со своей стороны также должен предложить свой вариант, чтобы помочь клиенту выбрать действительно важные для него объекты на сайте.
Посмотрите на интерактивные элементы используемые на сайте, определите те из них, отслеживание которых поможет вам принять решения по оптимизации сайта или бизнес процессов связанных с ним.
Какой вариант выбрать для внедрения — через код отслеживания или с помощью Google Tag Manager?
Я сторонник настройки Google Analytics с помощью Google Tag Manager, этим вы минимизируете общение с вашими разработчиками. Тем более, если у вас есть проблемы с ними, например, вам приходится долго ждать изменений на сайте, которые вы предлагает внести.
Стоимость внедрения через код отслеживания ниже (в части оплаты подрядчику), но если разработчики у вас оплачиваются отдельно, то за внедрение кода с их помощью, также придется заплатить.
Отслеживание электронной торговли. Выбор между классическим вариантом и расширенной электронной торговлей. Выбирая между двумя вариантами необходимо учесть, что работа по внедрению расширенной торговли на порядок трудозатратнее и более длительна нежели ее классический вариант.
Расширенная торговля Google Analytics
Также расширенная торговля потребует значительного участия разработчиков в процессе ее внедрения, учтите это при принятии решения. Возможно настройка классической электронной торговли Google Analytics и данные, которые будут доступны после ее внедрения полностью решат ваши задачи.
Что я имею ввиду под целями настройки Google Analytics. Собственно это то, ради чего вы хотите выполнить его настройку у себя на сайте. Тут тоже могут быть варианты:
- для самостоятельной работы с отчетами;
- для работы различных подразделений организации;
- по результатам вы хотите получать отчеты на почту с определенной периодичностью и не работать с отчетами в панели управления;
- «нужно на отдельной странице вывести такие-то метрики и показатели, чтобы я зашел на страницу сайта и он мне все показал в одном месте»;
- «про него много говорят он стоит у конкурентов и мне нужен», или «у меня много времени и я буду смотреть отчеты в реальном времени», а также другие варианты.
Это тоже важно знать для настройки Google Analytics, т.к. настройкой на сайте работы не ограничиваются, есть масса возможностей по гибкой настройке этого инструмента под ваши нужды, а также создание различных персонализированных отчетов, сводок и т.п. с помощью API Google Analytics.
Как же оформить свои пожелания по настройке?
- создайте документ в текстовом редакторе (например в Word-е);
- сделайте скриншот страницы с элементом, который вы хотите отслеживать;
- выделите его цветом;
- вставьте скриншот в документ;
- укажите урл страницы, на которой сделан скриншот и описание элемента;
- повторите для каждого интерактивного элемента, которые хотите отслеживать.
Небольшие замечания к описанному алгоритму.
Если один элемент встречается на разных страницах, достаточно одного скриншота и одного урл, где этот элемент имеется на странице.
Пример описания элемента: «Красная кнопка в форме подписки на рассылку, расположена на всех страницах сайта в правой части страницы. Нужно фиксировать клики по кнопке в случае если пользователь ввел в поле Email корректный адрес электронной почты».
Если к моменту начала общения с подрядчиком у вас будет такой документ, думаю, что вопрос определения стоимости, согласования сроков и объема работ займет меньше времени, чем их решение без такого технического задания на внедрение Google Analytics.
Источник: prometriki.ru