Договор на техническое обслуживание и поддержку сайта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЛАЙФХАКИ ПО СОСТАВЛЕНИЮ ТЗ

Кстати. Хотите увеличить продажи вдвое и повысить эффективность бизнеса? Тогда интегрируйте сайт с CRM! Рекомендую Битрикс 24 и Мегаплан (“Megastart” скидка 10% на все 14 дней бесплатно). Потом спасибо скажете.

Хорошим помощником могут стать широко представленные в сети рейтинги и ТОПы Интернет-ресурсов.

1. Большой опыт. Он заключается не только в составлении технических заданий, но и в разработке сайтов — благодаря этому наши ТЗ удобно использовать.
2. Удобное сотрудничество. Мы выполняем заказы оперативно, ценим время наших клиентов и ответственно относимся к своей работе.
3. Надежность. Если после получения ТЗ у вас возникают какие-либо вопросы, вы всегда можете обращаться с ними к нашим специалистам — нам важно, чтобы с нашей помощью вы смогли создать по-настоящему эффективный сайт.

Техническое задание на сайт от «Студии В» — это набор четких, детальных инструкций, удобных в применении и полностью описывающих требования к созданию сайта. Чтобы заказать разработку ТЗ для сайта в Москве, просто свяжитесь с нами или заполните форму на сайте!

Для того, чтобы заказать сайт в веб агентстве «Студия В» достаточно заполнить бриф

Стоимость создания ТЗ начинается от 30 000 рублей.

ОШИБКИ ПРИ НАПИСАНИИ ТЗ

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

Поэтому выделяю самые основные из списка, те, что у Вас с вероятностью в 80% будут, если это Ваша первая разработка тз.

1. Нет ограничений во времени

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

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

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

2. Утрата данных доступа

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

А дальше в 9 из 10 случаев эти данные просто теряются: разработчику они больше не нужны, а заказчик про них благополучно забывает.

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

Поэтому запомните, что данные доступа к хостингу и доменному имени – это Ваши личные данные.

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

3. Отсутствие наглядности

Принцип “лучше 1 раз увидеть, чем 100 раз услышать” работает здесь на полную. В одни и те же слова заказчик и исполнитель могут вкладывать разный смысл.

И наверное эта ошибка вообще должна стоять на первом месте нашего хит-парада, так как такая картина происходит постоянно: “Хочу абстракцию”, – пишет заказчик, подразумевая нечто подобное (пример на картинке ниже)

“Ок, держите”, – говорит разработчик. И предлагает заказчику абстракцию следующего вида.

И попробуй потом докажи, что Ваша абстракция абстрактнее его. Каждый прав, никто не виноват.

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

4. Качественные прилагательные

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

Например, красивый (кто-то может быть ещё красивее или страшнее), умный, современный и т.п. Это слова-табу. Их нельзя однозначно понять. У каждого субъективное представление о красоте и современности.

Только конкретика. Например, “На два тона светлее”, “Смещаем на 5 сантиметров” или “Острые углы у кнопки”.

5. “На усмотрение разработчика”

Об этот коварный пункт спотыкаются многие. Заполняя бриф или составляя тз на дизайн сайта, не оставляйте в нём пробелов.

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

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

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

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

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

Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

КОРОТКО О ГЛАВНОМ

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

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

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

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

Лайфхак. Если Вы решили делать лендинг самостоятельно, то я рекомендую  конструкторы –  PlatformaLP, Tilda, Bloxy.

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

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

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

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

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

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

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

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