Как грамотно составить техническое задание программисту

Если одна из сторон хочет сотрудничать без техзадания

Это может означать следующее:

  1. Заказчик не устанавливает четких требований специально, чтобы затем получить часть работ бесплатно, либо он не уверен/ не знает/ не решил/ не понимает, что ему надо.

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

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

Раздел ТЗ

Для Заказчика

Для Разработчика

Определение цели

Осознание задач, которые решает проект или его доработка

Понимание сути задачи

Описание продукта

Представление о том, каким будет готовый продукт

Уверенность в правильном понимании конечного результата

Сроки выполнения

Ориентирование в сроках работ и получения планируемых результатов

Оценка трудозатрат и потребности в ресурсах

Бюджет проекта

Определение более-менее точной суммы затрат и планирование бюджета

Согласованный учет всех работ проекта

Перечень работ

Подробное описание работ и каждого этапа реализации проекта

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

Оценка результата работ

Проверка работы проекта по программе тестирования на соответствие требованиям задания

Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ

Обслуживание проекта

Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта

Выполнение работ с учетом обслуживания проекта в перспективе

Выявление проблем

Планируемые доработки проекта

Доработка в соответствии с новыми потребностями

Что было раньше

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

На многих проектах это выливалось в следующие проблемы:

  1. Описан внешний вид, но не принцип работы. Простой пример с корзиной интернет-магазина. В ТЗ было написано “Кнопка “Оформить заказ”. Но что должно произойти, когда пользователь нажал на эту кнопку{q} По каким правилам формируется номер заказа{q} Какой статус ему присваивается{q} Куда идет переадресация{q} А если один из товаров раскупили, пока пользователь оформлял заказ{q} На эти и многие другие вопросы в ТЗ ответов не было, а ведь это лишь один небольшой элемент. Подобные неописанные моменты приводили к спорам с Заказчиком, сильному выходу из бюджета и прочим неприятным последствиям.
  2. Отсутствие переиспользуемых блоков. На многих сайтах есть одинаковые блоки, используемые в разных местах, например, превью товара. Но данный блок в результате описывался в каждой странице. Это очень плохо по нескольким причинам. Во-первых, при необходимости изменения надо вносить сразу в нескольких местах, можно что-то упустить и будет несоответствие. Во-вторых, даже при одинаковых элементах в превью, заказчик может потребовать сделать их по-разному, что влечет за собой дополнительные затраты.
  3. ТЗ не коррелирует с задачами для команды. Чем дальше постановка задачи от реальности, тем ниже будет качество на выходе. Это еще одна проблема, которую хотелось решить.

Участники проекта

Заказчик Менеджер проекта Разработчики
Ставит задачу Ставит задачу разработчикам Выполняют задание в соответствии с ТЗ
Согласовывает ТЗ Контролирует ход работы и расставляет приоритеты
Принимает работу Осуществляет взаимодействие с заказчиком и разработчиком
Тестирует выполненную работу (если нет тестировщиков)

Если проект большой, дополнительно могут добавиться участники:

  • Product Manager
  • Руководитель проекта
  • Спонсор проекта
  • Тестировщики
  • Технические писатели
  • Кураторы
  • Пользователи/потребители (например, для финального тестирования)
  • И др.

Если проект маленький, то заказчик и исполнитель, как правило, работают напрямую. В этом случае тестирование берёт на себя заказчик, а разработчик сам контролирует сроки и ставит приоритеты.

Новый подход

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

ТЗ состоит из следующих разделов:

  1. Введение
  2. Статика
  3. Динамика
  4. Задачи
  5. Административная панель
  6. Общие технические требования

От проекта к проекту состав этих разделов может меняться, но основная структура остается. Давайте разберем подробнее.

Как грамотно составить техническое задание программисту

Введение и подготовка к реализации

  • Кратко описываем проект, его цели, ЦА, оставляем ссылки на предпроектную аналитику.
  • Описываем процесс инициализации проекта: настройку окружения для разработчиков и подход к разработке концепции дизайна для дизайнеров.
  • Принципы адаптивности или разбиения на версии. Последнее время в своей работе мы придерживаемся следующего принципа — “адаптивь все, что адаптивится”. Иначе говоря, в начале работы над ТЗ мы понимаем, какой сложный функционал нам нужен (или может понадобиться в ближайшем будущем) и вместе с дизайнером и front-end разработчиком придумываем способы его заадаптивить. При новом подходе отрицательных результатов еще не было, поэтому отдельные версии описывать не приходилось.

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

Статика

Как мы все знаем, страницы могут содержать либо статическую информацию, либо динамическую, присылаемую с сервера. Подразделы статики — страницы проекта. Каждую страницу мы разбиваем на блоки. Если блок статический, то мы описываем его суть и вид контента. Например, описание одного из блоков страницы “О компании” может выглядеть так.

“Основные преимущества компании. 5-6 иконок с описаниями.” Это очень краткое, но достаточное для точной оценки описание блока. При описании статики главная цель — задать четкие рамки. Сделать адаптив иконок не составит труда, а с графиком или таблицей все не так просто и однозначно. Но при этом нам не важно какие именно будут иконки и подписи к ним.

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

Помимо страниц Статика включает в себя описание pop-up и письма. На мой взгляд их нет смысла выносить в отдельный большой раздел и раздувать структуру.

Динамика

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

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

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

Административная панель

Здесь описываем структуру, модели и поля. Разбиение идет по разделам, например, “Товары”, “Каталог”, “Заказы” и т.д. Описываем что разные роли пользователей могут просматривать, что редактировать.

Общие технические требования

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

  1. SEO-требования к тегам и микроразметке
  2. Правила транслитерации
  3. Ручное и автоматическое тестирование
  4. Поддерживаемые браузеры

При описании новых версий необходимо вносить изменения в существующие элементы. Мы рассматривали следующие способы описания доработок: в начале каждого из разделов (Статика, Динамика, АП) писать “Доработка функционала “NAME”, либо сделать отдельный раздел “Доработки”, в котором в кучу будут свалены сразу все изменяющиеся задачи. Пока остановились на втором варианте, но это связано скорее удобством на конкретных проектах. В других условиях лучше подойдет первый способ.

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

Участники проекта

Давайте для наглядности разберем структуру ТЗ на основе упрощенной страницы раздела каталога.

Статика

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

Интегрируется следующий функционал:

  1. “Хлебные крошки”
  2. “Дерево каталога”
  3. “Фильтрация. Общие положения”
  4. “Фильтрация. Текст”
  5. “Фильтрация. Текст и изображение”
  6. “Фильтрация. Диапазон”
  7. “Сортировка. По умолчанию”
  8. “Сортировка. По возрастанию цены“
  9. “Сортировка. По убыванию цены”
  10. “Превью товара. Плитка”
  11. “Пагинация. Постраничная”
  12. “Текстовый блок”. Интегрируется в виде блока для SEO-текста перед подвалом сайта

URL: /c/1745-name, где 1745- id текущей категории каталога, а name — транслитерированное название этой категории.

Динамика

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

Функционал “Фильтрация. Общие положения”

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

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

  • выпадающий список закрывается, а фильтр применяется. В текущем разделе остаются только товары, соответствующие текущим активным фильтрам
  • название кнопки фильтра приобретает вид: “Название фильтра: K”, где K — количество выбранных значений фильтра, если их 2 или больше, или “Название фильтра: значение”, если было выбрано одно значение.
  • цвет кнопки фильтра меняется на вид используемого фильтра
  • в значениях других фильтров остаются только варианты, удовлетворяющие текущим активным фильтрам. Если в одном из неактивных фильтров остается одно значение, его кнопка приобретает вид неактивной, а название выводится в формате “Название фильтра: значение”
  • у всех активных фильтров после названия добавляется крестик, при клике на который сбрасывается только этот фильтр
  • пагинация сбрасывается
Предлагаем ознакомиться:  Жалоба в прокуратуру на халатность врачей больницы образец

Как грамотно составить техническое задание программисту

Если хотя бы один фильтр активен, после всех кнопок с фильтрами появляется кнопка “сбросить фильтры”, при клике на которую значению всех фильтров сбрасываются.

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

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

Выбранные фильтры добавляются в URL посредством query-параметров.

Функционал “Превью товара. Плитка”

Представляет собой плитку (прямоугольник) с самой важной для пользователя информацией о товаре. В варианте плиткой ключевой информацией является изображение товара. Превью содержит:

  1. Цена (целое число в рублях РФ)
  2. Название товара
  3. Метка “В магазине” или “С витрины”
  4. Изображение
  5. Размер
  6. Кнопка “В корзину” (Интеграция функционала “Добавить в корзину”)
  7. Кнопка “В избранное” (Интеграция функционала “Добавить в избранное”)

При клике на любую область превью, кроме кнопки “В корзину” осуществляется переход на страницу товара.

На одной строке должно помещаться 3-4 плитки с превью товара.

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

Последствия составления некачественного задания

  • Заказчик не готов платить до 40% от стоимости проекта только за разработку задания. Например, можно еще до начала проектирования написать все тест-кейсы и заложить в ТЗ. Но в этом случае стоимость задания с тест-кейсами может превысить стоимость разработки, а его составление займет не один месяц. Зато это полностью снимает вопрос с ошибками в работе и упрощает приёмку.

  • Заказчик не знает всех деталей проекта до начала эксплуатации уже готового результата.

  • Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.

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

Большинство таких проблем решает Agile (гибкий подход к работе), но это не отменяет необходимость составления ТЗ. Используйте Agile при разработке любых проектов с высокой неопределённостью. Как правило, против этого выступают только заказчики, потому что они не видят точной границы цены и сроков. Зато финальный продукт гарантировано будет выполнять поставленные задачи — Agile в разы снижает число готовых проектов, которые были заброшены из-за того, что не выполняют своих функций.

Выводы

  1. Полнота. Данное ТЗ позволяет однозначно описывать требования, что является основным и необходимым параметром любого ТЗ.
  2. Понятность. Около половины наших клиентов не имеют на своей стороне технического специалиста и сталкиваются с разработкой впервые. Поэтому очень важно было сделать ТЗ максимально понятным и читаемым. И у нас получилось! Даже технически не подкованные клиенты понимают, как оно устроено, могут спокойно его читать и давать отличную обратную связь.
  3. Молекулярность. ТЗ полностью соответствует нашим требованиям к разбиению на отдельные элементы, что значительно упрощает и решает проблемы, описанные выше. Блоки ТЗ напрямую соответствуют задачам, которые выполняются разработчиками, что было встречено на ура. Также ТЗ отлично ложится на дизайн-систему (про нее статья выйдет уже на следующей неделе).
  4. Простота оценки и конфигурации сметы. Хорошо описанные и разбитые задачи стало просто и приятно оценивать. Если во время оценки мы понимаем, что требования неполные, то дописываем их. Под каждый проект (этап) делаем гугл таблицу, в которой заказчик может попробовать разные конфигурации проекта и определить наиболее подходящий для себя вариант по цене/функционалу.
  5. Взаимодействие с заказчиками поднялось на новый уровень. Внесенные изменения позволяют четко определить границы проекта. Если необходимо внести изменения относительно ТЗ, это оценивается как новая задача, хотя при старом подходе это вызывало много споров.
  6. Рентабельность. Т.к. это в первую очередь бизнес, данный показатель наравне с предыдущим является одним из самых важных. Детальная проработка позволила свести количество плохо оцененных задач к минимуму. Ни по одному из проектов, реализуемых по новому подходу, не было превышения бюджета.
  1. Внесение доработок. На одном из проектов было необходимо ввести статусы товаров. В итоге получилось огромное количество доработок по 2-3 строчки. Нельзя это назвать явным минусом, т.к. полното требований в приоритете, но и идеальным данных подход назвать нельзя.
  2. Сложность восприятия при автоматизации бизнес-процессов. Если взять бизнес-процессы некоторых компаний от момента продажи до получения товара покупателем, не всегда есть возможность (или необходимость на первых этапах) покрыть весь процесс за счет Статики, Динамики и АП, т.к. многие задачи выполняются вручную, обсуждаются с клиентами по телефону и т.д. Это немного усложняет восприятие ТЗ в чистом виде, и требует дополнительного описания процессов.
  3. Стоимость и время разработки. Продавать ТЗ, конечно, стало сложнее, ведь далеко не все при первом контакте с разработкой готовы платить за него 10-20% от проекта при том что многие наши конкуренты берут за него 10-20 тыс. Но подобная работа сполна окупается при реализации, снижая риски проекта и улучшая качество.

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

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

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

Чем отличается техзадание от описания объекта заказа

  1. Что{q} (какие работы, содержание элементов)
  2. Где{q} (расположение элементов)
  3. Когда{q} (последовательность выполнения и установленные сроки работ)
  4. Как{q} (технология реализации, оформление, принцип работы.) Как правило, у любого объекта должны быть функции: добавления, отображения, редактирования, удаления. А также описаны зависимости и взаимодействия с другими объектами. Иногда добавляются функции модерации, валидации, автообновления, архивации и т.п.
  5. Откуда{q} / Куда{q} (при переносе и т. п.)
  6. Зачем{q} (обоснование работ, если задание будет согласовываться с 3-м лицом)
  7. Особенности.

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

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

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

Формирование технической формы базируется и на государственных стандартах (ГОСТ) составления и ведения программной документации. Заказчик не обязан использовать образец технического задания по ГОСТу. Это вспомогательная мера, которая упрощает разработку корректных закупочных документов.

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

Грани взаимодействия

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

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

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

Возможности — если кратко, то это то, что реально может сделать вендор (исполнитель). Рассмотрим на примере нашей RegionSoft CRM. Клиент покупает систему и составляет техническое задание на доработку: нужно создать интеграцию с сайтом и привязку событий в CRM к номеру заказа интернет-магазина. Это реально исполнимое требование, у нас есть ресурс и возможность сделать это.

Как грамотно составить техническое задание программисту

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

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

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

Основные рекомендации и пояснения по написанию ТЗ

  1. Чем больше масштаб проекта, тем более объемным должно быть техническое задание.
  2. Необходимо указывать реально осуществимые сроки выполнения работ с учетом времени на согласование проектной документации и приемо-сдаточных мероприятий. Стоит обратить внимание на ответственность заказчика за бездействие с его стороны или на форс-мажоры, тормозящие выполнение работ.
  3. Программисту нужны четкие условия. Формулировки “как вариант”, “примерно”, “около”, “где-то рядом”, “там, где лучше по вашему мнению”, — неприемлемы. Требования и характеристики, которые носят субъективный характер, бессмысленны с практической и ошибочны с юридической точек зрения.
  4. Чтобы сделать задачу по созданию какого-либо функционального модуля понятной для программиста, в техзадании размещают гиперссылки на те страницы, где есть нужные элементы интерфейса и функции, и дают к ним подробные пояснения. Также прилагают скриншоты с выделением интересующего фрагмента.
  5. Если дизайна для страниц нет или он не так важен для заказчика, программист может использовать прототипы, о чем после согласования указывается в задании.
  6. ТЗ должно быть удобным и понятным для всех сторон проекта, подробно описывать все этапы и подпункты даже по самым незначительным работам. Программист и менеджер не всегда имеют представление о том, что необходимо заказчику, поэтому важно своевременно обнаружить и согласовать все несогласованные детали.
Предлагаем ознакомиться:  Гражданско правовой договор с работником: Образец и пустой бланк

Для удобства ниже представлена таблица пунктов ГОСТа 34 и ГОСТа 19 для написания Технического задания.

ГОСТ 19 ГОСТ 34
1. Введение 1. Общие сведения
2. Основания для разработки
3. Назначение разработки 2. Назначение и цели создания системы
3. Характеристика объекта автоматизации
4. Требования к программе или программному изделию 4. Требования к системе
4.1. Требования к функциональным характеристикам 4.2. Требования к функциям (задачам), выполняемым системой
  4.1. Требования к системе в целом
4.1.1. Требования к структуре и функционированию системы
4.1.3. Показатели назначения
4.2. Требования к надёжности 4.1.4. Требования к надёжности
  4. 1.5. Требования к безопасности
4.1.6. Требования к эргономике и технической эстетике
4.3. Условия эксплуатации 4.1.2. Требования к численности и квалификации персонала системы и режиму его работы
  4. 1.9. Требования к защите информации от несанкционированного доступа
4.1.10. Требования по сохранности информации при авариях
4.1.11. Требования к защите от влияния внешних воздействий
4. 1.12. Требования к патентной чистоте
4.1.13. Требования по стандартизации и унификации
4.4. Требования к составу и параметрам технических средств 4.1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.5. Требования к информационной и программной совместимости  
4.6. Требования к маркировке и упаковке
4.7. Требования к транспортированию и хранению 4.1.7. Требования к транспортабельности для подвижных систем
4.8. Специальные требования 4. 1.14. Дополнительные требования
4.3. Требования к видам обеспечения
5. Требования к программной документации 8. Требования к документированию
6. Технико-экономические показатели
7. Стадии и этапы разработки 5. Состав и содержание работ по созданию системы
8. Порядок контроля и приёмки 6. Порядок контроля и приёмки системы
  7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
9.Источники разработки

Ниже рассмотрим каждый ГОСТ и пункты ГОСТ по отдельности.

Сбор и анализ требований

Закон о Федеральной контрактной системе не предусматривает определенных требований к формату и содержанию ТЗ, нет также и унифицированной или единой формы документа.

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

В процессе формирования ТЗ специалисты могут воспользоваться всеми открытыми и доступными для пользователей сервисами. К ним относятся:

  • ГОСТ Р 7.0.97-2016, включающий требования к оформлению различной документации;
  • реестр госзакупок в Единой информационной системе;
  • иные источники общедоступных данных.

В техническом задании должны быть прописаны наименование объекта госзаказа, а также основные требования и условия к нему. По ч. 4 ст. 23 44-ФЗ, название предмета заказа приводится на основании действующего каталога товаров, работ, услуг (КТРУ) (утв. ПП РФ № 145 от 06.02.2017).

Изучив искомую позицию в КТРУ, специалист заказчика описывает объект госзаказа в строгом соответствии с конкретной строкой каталога. В случае несовпадения прописанных в КТРУ характеристик и описания заказчика ответственный специалист приводит письменное обоснование, указывая при этом требуемое наименование закупаемого объекта (Правила, закрепленные Постановлением Правительства № 555 от 05.06.2015).

В техническом задании описывается конечный результат закупки в части товаров, работ и услуг, учитывающий все потребности заказчика. Формирование описательной части нормируется статьей 33 44-ФЗ. Эти правила нужно также учесть и при разработке всего техзадания:

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

Это очень важный внутрикорпоративный процесс, в ходе которого выясняется, чего хотят от программы (здесь и далее возьмём CRM, но методы работают и с другими типами софта) потенциальные пользователи. Если вы обратитесь к крупному вендору типа SAP или системному интегратору, то с высокой долей вероятности вам предложат воспользоваться услугами бизнес-консультанта (он же персональный менеджер, он же аккаунт-менеджер, он же «теперь ваш представитель в нашей компании»).

Лучше, чем вы и ваши сотрудники, вашу компанию не знает никто. А значит, сбор и анализ требований — исключительно ваша задача, в которой вендор может помочь и направить, но ни в коем случае не вмешаться в процесс. Расспросите разработчика о подобных внедрениях, уточните, на что обратить внимание и приступайте.

Есть очень простая схема сбора требований.

  1. Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут пользоваться CRM. Расскажите о решении, которое предполагается выбрать, предоставьте доступ к демо-версии.
  2. Члены рабочей группы должны передать информацию сотрудникам и запросить у них пожелания к новой программе в абсолютно свободной форме. Если кто-то из сотрудников никогда не сталкивался с подобным софтом и не готов говорить в аспекте будущего использования, нужно попросить его описать свои периодические задачи, это универсальный подход.
  3. Затем каждое подразделение устанавливает, чего нет в CRM или чему она не соответствует, и агрегирует информацию.
  4. Рабочая группа анализирует собранные требования, проверяет и исключает пересечения. Например, нередко отдел продаж и отдел маркетинга заказывают один и тот же отчёт, но в требованиях могут по-разному называться поля и сущности, хотя данные за ними стоят одинаковые. Соответственно, нужно придти к единой форме.
  5. Рабочая группа формирует список требований и расставляет приоритеты. На этом этапе можно подключить вендора, поскольку он отвечает за ресурсы. Например, можно попросить создать пользовательский отчёт для RegionSoft CRM, а можно заказать интеграцию с сайтом. Это совершенно разные по срокам задачи, здесь очень важен приоритет.

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

Анатомия технического задания

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

  • Выявление — определение требований, поиск проблем, которые необходимо решить.
  • Анализ — разбор требований, выделение ключевых потребностей, обобщение.
  • Адаптация — оценка требований в контексте возможностей CRM и существующих бизнес-процессов.
  • Документирование — формальное и подробное описание требований, согласование ТЗ.
  • Общение с вендором (разработчиком) — итеративное взаимодействие с вендором по поводу доработок согласно составленному ТЗ.
  • Реализация — работа вендора над созданием необходимой функциональности. Лучше, если вендор будет постоянно на связи с заказчиком — так продукт на выходе будет наиболее точно соответствовать видению клиента.
  • Тестирование — проверка функциональности сотрудниками вендора, внутренними экспертами клиента и конечными пользователями с целью установления соответствия доработки и ТЗ, работоспособности системы с изменениями.

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

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

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

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

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

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

Предлагаем ознакомиться:  Договор на оперативное управление имуществом образец

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

Дело вот в чём: каждый вендор работает на рынке по несколько лет (мы сейчас не о CRM-однодневках), а то и десятков лет, а значит имеет набор кейсов практически по каждой отрасли. Соответственно, и инженеры, и программисты, и продажники знакомы со спецификой внедрения в каждом типе компании. Но опять-таки, важно ориентироваться именно на свой бизнес.

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

Как грамотно составить техническое задание программисту

Приведу пример. В одной компании внедряли CRM, предполагалась работа на довольно большом массиве данных (несколько десятков миллионов записей в месяц, несколько сотен тысяч записей в день). Начальник отдела продаж запросил отчёт по выгрузке этих записей с периодичностью «ежедневно». Естественно, что такой отчёт при одновременной работе сотни пользователей нагружал систему — были найдены решения по оптимизации процесса.

Зачем{q} Обоснование необходимости доработки и его место в бизнес-процессе. Этот пункт больше нужен самому заказчику, но и вендору нелишне знать, какие ещё процессы будут затронуты. Иногда это помогает найти альтернативное решение.

Что должно делать{q} Самый информативный блок — в нём описываются требования, ожидания от системы. И вот тут случаются тем самые перлы, чудеса и коллизии, которые впору отправлять на башорг, и которые ну очень усложняют жизнь. Причина одна — пользователь не знает, чего он хочет, что нужно сделать. Есть ещё маленькая подпричина — пользователь не может сформулировать требования.

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

10 правил, написанных слезами разработчика

, а не 300-страничным описанием CRM, которая необходима клиенту. Перед составлением требований следует внимательно ознакомиться с интерфейсом системы, её возможностями, документацией — скорее всего, большая часть «хотелок» уже есть в базовой поставке. Вторым шагом я бы рекомендовал обратить внимание на встроенные инструменты доработки (дизайнеры отчётов, конфигураторы и проч.) — возможно, нужные изменения сможет внести штатный программист (во многих компаниях они есть).

Техническое задание не должно быть жадным. Нередко бизнес переоценивает свои возможности или желает получить «всё и сразу». Такой подход не оправдан ни с точки зрения денег, ни с точки зрения бизнеса. Вендор, как правило, существует не пару недель (в случае RegionSoft — 15 лет), и к нему можно обратиться и через некоторое время, когда вы уже реально поймёте, чего в CRM не хватает.

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

Например, RegionSoft CRM — десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании. Нет, конечно, всё имеет свою цену, но опять же — в общем случае требование невыполнимое.

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

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

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

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

Техническое задание должно быть написано на человеческом языке. И это важно, нет, ВАЖНО. Выделю две ситуации, когда проблемы с языком приводят к затягиванию реализации проекта.

  1. Клиент пытается продемонстрировать свою техническую грамотность и городит конструкции типа: «имплементировать окно с хинтом в тело календаря с возможностью реакции на колл события…» вместо «в календаре должно всплывать окно, в котором можно отметить задачу как выполненную». Если у вас или вашего внутреннего эксперта нет навыков написания технических текстов, не гуглите — пишите обычными словами, мы их понимаем.
  2. ТЗ переполнено грамматическими ошибками. Нужно не только избавиться от расплывчатых описаний и метафор (из реального: «Чтобы компьютер не пищал, будто помирает в судорогах»), лишних слов, слов-паразитов. Проверяйте пунктуацию – зачастую ошибки в ней искажают смысл требования. Задание на проект – это документ и лексика в нём должна быть соответствующая, а грамотность — близкая к 100%.

И ещё — не используйте редакторы типа Microsoft Visio и UML-диаграммы, если вы в них не разбираетесь. То, что кажется красивым и деловым, на взгляд разработчика оказывается адской путаницей. Если хочется вставить схему или картинку — нарисуйте её человеческими методами, не утруждайте себя, это нам, разработчикам, ничем не поможет.

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

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

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

Как грамотно составить техническое задание программисту

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

Заповеди закончились, теперь отповедь

Кроме перечисленных правил, есть ещё несколько вещей, о которых стоит рассказать. Речь идёт о целях, планах и ожиданиях — всех тех оставляющих, которые делают проект успешным, а отношения вендора и клиента почти дружескими.

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

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

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

Исходите из объективной необходимости изменений и расширений — выше я писал, что разработчик не исчезает и готов внести изменения и дополнения по вашим требованиям в любой момент. Поэтому не пытайтесь создать CRM/ERP мечты сразу, не требуйте от вендора кнопку «Всё работает, пока я пью кофе» — поработайте в системе, определите критичные для вас замечания и приступайте к сбору требований и составлению ТЗ.

Весь декабрь мы

https://www.youtube.com/watch{q}v=UoKlKx-3FcA

на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря — 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.

Понравилась статья? Поделиться с друзьями:
Юридическая помощь
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:

Adblock detector