Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.
В этом гайде я расскажу, что и зачем нужно писать в техзадании. Заодно покажу, как писать не надо, чтобы создание ТЗ не обернулось потраченным впустую временем.
Статья будет полезна:
- Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
- Менеджерам проектов.
- Руководителям диджитал-студий.
- Предпринимателям, которые планируют заказать разработку сайта.
Чтобы материал получился дельный, я собрал комментарии нескольких разработчиков, дизайнеров, проект-менеджеров и владельцев диджитал-студий. Самые ценные добавил в конец статьи. Поехали разбираться.
Что такое техзадание и зачем оно нужно
Техническое задание - это документ, в котором зафиксированы требования к сайту. Чем четче и подробнее расписаны эти требования, тем лучше все участники процесса понимают, каким он должен быть. А значит, растет шанс того, что все останутся довольны результатом.
Главная цель технического задания: убедиться, что клиент и исполнитель правильно поняли друг друга.
Пользы от технического задания много. Для каждой стороны она своя.
Польза для клиента:
- Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет - без проблем поменять еще до начала разработки.
- Увидеть компетентность исполнителя. Если техзадание понятное и четкое - доверие к разработчику повышается. Если там написана каша - возможно, стоит бежать и не оглядываться.
- Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
- Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
- Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.
Польза для исполнителя:
- Понять, что хочет заказчик. Клиенту задают десятки вопросов, показывают примеры, предлагают решения. Затем записывают все в единый документ и согласовывают. Если все окей - ура, вы поняли правильно.
- Застраховаться от внезапных хотелок клиента. Иногда попадаются заказчики, которые хотят поменять задачу на полпути. Если вы согласовали и подписали ТЗ, вам не страшно подобное. В случае чего, даже суд будет на вашей стороне.
- Показать свою компетентность. Классно подготовленное техзадание покажет клиенту экспертность разработчиков. Если компания сомневалась, доверять ли вам разработку сайта, сомнения с большой вероятностью развеются.
- Заработать деньги. Некоторые студии и разработчики предлагают составление ТЗ как отдельную услугу.
- Облегчить и ускорить процесс разработки . В хорошем ТЗ указаны структура сайта, необходимые функции и элементы на каждой странице. Когда все требования уже перед глазами - остается только задизайнить и написать код.
Теперь давайте разберемся, как составить хорошее техзадание, которое выполняет все эти функции.
Техзадание составляет исполнитель
Вообще техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» - это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.
Хорошее ТЗ всегда составляет исполнитель: проект-менеджер или разработчик. Очевидно, что веб-разработчик понимает в создании сайтов больше, чем владелец кафе или стоматологической клиники. Поэтому описывать проект придется ему.
Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:
Конечно, заказчик может набросать свой вариант ТЗ. Возможно, это ускорит процесс создания конечного техзадания. А возможно, получится мусор, который втихаря выкинут на помойку.
Пишите однозначно и точно
Этот совет вытекает из главной цели техзадания - «Убедиться, что клиент и исполнитель правильно поняли друг друга».
В техническом задании не должно быть качественных прилагательных: красивый, надежный, современный. Их нельзя однозначно понять. У каждого свои понятия красоты и современности.
Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:
То же самое - с невнятными формулировками, которые ничего сами по себе не значат:
- Сайт должен понравиться заказчику. А если у него будет плохое настроение?
- Сайт должен быть удобным. Что это значит? Удобным для чего?
- Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
- Качественный экспертный контент. Ну, вы поняли.
Проверяйте, нет ли в тексте неоднозначностей. Если есть - перепишите. Ваши формулировки должны быть четкими и точными:
- Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
- Большие нагрузки → 50 тысяч посетителей одновременно.
- На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
- Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.
С формулировками разобрались, давайте пробежимся по структуре.
Укажите общую информацию
Все члены команды должны правильно понимать, чем занимается компания и кто ее целевая аудитория. Чтобы никто не запутался, это лучше прописать в самом начале техзадания.
А еще стоит указать цель сайта и описать его функционал в двух словах - чтобы не получить интернет-магазин вместо блога.
Поясните сложные термины
Первое правило техзадания - оно должно быть понятно всем, для кого предназначено. Если вы собираетесь использовать термины, которые может не понять ваша клиентка - владелица магазина детских игрушек - обязательно поясните их. Понятным языком, а не копипастой из «Википедии».
Опишите инструменты и требования к хостингу
Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом - он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»
Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.
Перечислите требования к работе сайта
Сайт должен работать во всех браузерах актуальных версий и на всех типах устройств. Да, это очевидно для любого разработчика и любого заказчика. Но лучше написать, чтобы защитить клиента от недобросовестно выполненной работы.
Сюда же напишите требования к скорости загрузки сайта , устойчивости к нагрузкам, защите от хакерских атак и подобным вещам.
Укажите структуру сайта
До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.
Пообщайтесь с заказчиком, выясните, что ему надо. Соберите разработчиков, сеошников, маркетологов, главреда - и решите, какие страницы нужны на сайте. Подумайте, как они будут связаны между собой, с какой на какую можно перейти.
Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.
Это один из важнейших этапов работы на сайтом. Структура - это фундамент. Если она неудачная - сайт получится кривой.
Объясните, что будет на каждой странице
Клиент должен понять, зачем нужна каждая страница и какие элементы на ней будут. Есть два способа это показать.
Прототип - более наглядный и однозначный способ. Исполнитель рисует эскизы каждой страницы и прилагает их к техзаданию. Клиент видит, как будет выглядеть интерфейс его будущего сайта и говорит, что ему нравится, а что стоит изменить.
Перечисление элементов - ленивая альтернатива прототипу. Просто напишите, какие блоки должны быть на странице, и что они делают.
Распишите сценарии использования сайта
Если вы делаете какой-то нестандартный интерфейс, просто показать структуру и эскизы страниц недостаточно. Важно, чтобы вся команда исполнителей и клиент поняли, как посетители будут пользоваться сайтом. Для этого отлично подходят сценарии. Схема сценария очень простая:
- Действие пользователя.
- Ответное действие сайта.
- Результат.
Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут какие-то интерактивные сервисы - очень желательно.
Подробнее о сценариях использования читайте в «Википедии ».
Определите, кто отвечает за контент
Одни разработчики делают сайт сразу с контентом. Другие ставят рыбу. Третьи могут написать тексты, но за дополнительную плату. Договоритесь об этом на берегу и зафиксируйте в техзадании, какой контент вы должны подготовить.
Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.
Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.
Опишите дизайн (если сможете)
Как и в с случае с текстом, объективные критерии оценки дизайна сайта придумать сложно. Если вы с клиентом договорились о цветовой гамме - напишите ее. Если у него есть брендбук, в котором прописаны шрифты, - укажите и их.
Писать про красивый и современный дизайн не надо. Это ничего не значит, не имеет силы и вообще фу.
Вместо вывода: структура техзадания
Для разных задач структура ТЗ будет своя. Глупо делать одинаковые технические задания для новой социальной сети и лендинга по оптовой продаже моркови. Но в целом вам нужны такие разделы:
- Информация о компании и целевой аудитории, цели и задачи сайта.
- Глоссарий терминов, которые могут быть непонятны клиенту.
- Технические требования к верстке и работе сайта.
- Описание используемых технологий и список требований к хостингу.
- Подробная структура сайта.
- Прототипы страниц или описания элементов, которые должны на них быть.
- Сценарии использования нестандартного интерфейса (опционально).
- Список контента, который делает разработчик.
- Требования к дизайну (опционально).
- Правила составления Software Requirements Specification. SRS - следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
- Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.
Это конец той части, которую писал я. Но есть и другая - комментарии специалистов, которые помогали делать гайд. Почитайте, это тоже интересно.
Комментарии разработчиков
Я пообщался с несколькими разработчиками, чтобы узнать, как они составляют техзадания. Передаю микрофон им.
В первую очередь ТЗ нужно клиенту - чтобы он понял, каким будет его сайт, и на что уходят деньги. Если что-то сделано не так - он может сослаться на ТЗ и попросить переделать.
ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.
Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.
Мы указываем:
- Информацию о компании и цель сайта.
- Требования к дизайну, цветовую гамму.
- Используемые технологии и CMS.
- Кто занимается контентом - мы или клиент.
- Структуру сайта вплоть до каждой страницы.
- Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.
Последние 2 раздела - самые важные. Именно они обеспечивают понимание, какие будет сайт и как он будет работать.
Очень важный момент - нельзя просто отдать техзадание разработчикам и надеяться, что они все сделают хорошо. ТЗ - это список требований к сайту, оно не может заменить общение. Важно убедиться, что каждый член команды понимает общую цель, а не просто выполняет задачи на потоке. Если что-то непонятно - надо объяснить, обсудить, дать подробные комментарии.
Наши специалисты помогли заказчику составить ТЗ техническое задание на модернизацию системы вентиляции .
Подробнее под катом..
Техническое задание
на модернизацию технологического оборудования вентиляционных систем корпуса лабораторий №451,452 корпуса 17 по адресу: г. Москва
1. Общие положения
1.1. Настоящее техническое задание предусматривает выполнение работ по модернизации технологического оборудования, систем управления и автоматики вентиляционных установок корпуса, лабораторий №451,452 корпуса 17.
1.2. Для выполнения работ разработать рабочую документацию разделов марок АОВ, ЭМ, ХС, АХС, АК, которую согласовать установленным порядком.
1.3. Работы выполнять с соблюдением требований нормативно-технической документации.
1.4. По окончании работ предъявить исполнительную документацию, выполненную в соответствии с требованиями ГОСТ и СНиП.
1.5. Сдать выполненную работу Заказчику.
1.6. Отдельные положения настоящего Технического Задания могут уточняться в процессе проведения работ по согласованию с Заказчиком.
2. Технические требования
2.1. Модернизация узлов регулирования тепло, холодоснабжения вентиляционных установок.
2.1.1. Узлы регулирования теплоснабжения.
Модернизации подлежат:
· узлы регулирования теплоснабжения первого подогрева вентиляционных установок К1, К2, К2а, К4 корпуса МИК-В, П2, П6 лаборатории №452, П1 лаборатории.
· узлы регулирования теплоснабжения второго подогрева вентиляционных установок К1, К2, К2а корпуса МИК-В.
Существующие узлы регулирования теплоснабжения подлежат демонтажу, при этом, часть оборудования узлов регулирования (циркуляционные насосы, запорная арматура), соответствующие по состоянию и техническим характеристикам, подлежит использованию в монтируемых узлах регулирования.
Состав оборудования монтируемых узлов регулирования, а также.используемое оборудование указано в приложении №1.
Провести гидравлические испытания контуров подогрева и калориферов вентиляционных установок с оформлением акта гидравлических испытаний.
Выполнить покраску трубопроводов и теплоизоляционные работы.
2.1.2.Узлы регулирования холодоснабжения вентиляционных установок.
Модернизации подлежат узлы холодоснабжения вентиляционных установок К1, К2, К2а, К4 корпуса МИК-В, П2, П6 лаборатории «452, П1 лаборатории №451.
Состав работ:
· замена терморегулирующих вентилей узлов регулирования холодоснабжения;
· демонтаж/монтаж вентилятора компрессорно-конденсаторного блока К1;
· демонтаж/монтаж фильтров-осушителей компрессорно-конденсаторных блоков К1, К2;
· демонтаж/монтаж испарителя вентиляционной установки К4;
· опрессовка в среде инертных газов, ваккумирование, заправка фреоном контуров холодоснабжения;
· восстановление теплоизоляции трубопроводов.
2.1.3. Узлы подпитки контуров увлажнения.
На узлах подпитки камер орошения кондиционеров К1, К2, К2а установить фильтры очистки холодной воды.
2.2. Шкафы управления и автоматики вентиляционных установок.
Подлежат демонтажу шкафы управления вентиляционными установками К1, К2, К2а, К4, РУ3, В1, В2, В3, В6, В7, В8 корпуса МИК-В, П2, П6, В1, В2, В3 лаборатории №451, П1, В1 лаборатории № 452.
Компоновка вновь устанавливаемых щитов управления:
ШУА К1 – шкаф управления и автоматики вентиляционной установкой и компрессорно-конденсаторным блоком (ККБ) кондиционера К1 (МИК-В);
ШУА К2 – шкаф управления и автоматики вентиляционной установкой и ККБ кондиционера К2 (МИК-В);
ШУА К2 – шкаф управления и автоматики вентиляционной установкой и ККБ кондиционера К2а (МИК-В);
ШУА К4 – шкаф управления и автоматики вентиляционной установкой и ККБ кондиционера К4 (МИК-В);
ШУВ– шкаф управления вытяжными установками РУ3, В1, В2, В3, В6, В7, В8 (МИК-В);
ШУА П2,П6 – шкаф управления и автоматики вентиляционными установками и компрессорно-конденсаторными блоками П2, П6 (лаборатория №452);
ШУВ– шкаф управления вытяжными установками В1, В2, В3 (лаборатория №452);
ШУА П1,В1 – шкаф управления и автоматики вентиляционными установками П1, В1 (лаборатория №451).
Модернизированные шкафы управления должны обеспечивать:
· выбор, с лицевой панели шкафа, режима управления вентиляционными установками (ручной/автоматический);
· световую сигнализацию штатных и аварийных режимов работы технологического оборудования вентиляционных установок (работа/авария);
· отключения вентиляционных установок при возникновении пожара;
· автоматическое срабатывание защит и блокировку работы оборудования при возникновении аварийных ситуаций.
Преобразователи частоты для управления электродвигателями вентиляторов и насосов подлежат дальнейшему использованию.
2.3. Система автоматизации и диспетчеризации
Система автоматизации и диспетчеризации предназначена для управления и контроля работы вентиляционных установок, а также для сбора, обработки, представления и хранения поступающей информации.
2.3.1. Система автоматики.
Система автоматики должна обеспечивать, в основном, автономное функционирование вентиляционных установок, не требующее вмешательства обслуживающего персонала и переход, при необходимости, на ручной режим управления. При любых вариантах управления и независимо от состояния локального контроллера, должно сохраняться условие автоматического отключения системы общеобменной вентиляции при пожаре. Отключение следует производить индивидуально для каждой системы с сохранением электропитания цепей защиты от замораживания.
Локальная автоматика вентиляционных систем должна предусматривать:
· регулирование температуры приточного воздуха на выходе вентиляционной установки или, при необходимости, температуры вытяжного воздуха из обслуживаемого помещения;
· регулирование влажности приточного воздуха;
· остановку вентиляторов и закрытие воздушных клапанов при срабатывании пожарной сигнализации;
· отключение увлажнения воздуха кондиционера при остановке его вентилятора;
· открытие и закрытие воздушного клапана соответственно при пуске и остановке вентилятора;
· автоматический прогрев калориферов перед запуском систем в зимнем режиме;
· защита от замораживания калориферов по воздуху и по воде (отключение вентилятора, закрытие воздушной заслонки, открытие на 100% клапана подогрева);
· отключение вентилятора при отсутствии перепада давления;
· контроль загрязненности фильтров установок.
Дистанционное воздействие на локальную автоматику с АРМ определяется в следующем объеме:
· изменение уставок регуляторов температуры и влажности;
· включение/отключение установок.
Существующее периферийное оборудование системы автоматики подлежит поверке, очистке и дальнейшему использованию в следующем порядке:
· датчики температуры и влажности вентиляционных установок подлежат поверке;
· датчики реле перепада давления подлежат проверке, очистке;
· термостаты защиты калориферов вентиляционных установок от замораживания подлежат замене.
· приводы регулирующих клапанов узлов регулирования подлежат замене в соответствие с п.2.1.1.
· приводы воздушных клапанов подлежат проверке и дальнейшему использованию;
Для управления рециркуляцией кондиционера К1 заменить двухпозиционные приводы воздушных клапанов на клапана с управляющим сигналом 0..10В.
2.3.2. Система диспетчеризации.
В состав системы диспетчеризации включить следующие компоненты:
· комплекс измерительных устройств, исполнительных механизмов и средств автоматизации на базе программно-технических средств «Honeywell »;
· многофункциональная кабельная система;
· комплекс программно-технических средств диспетчерского пункта.
Для диспетчеризации вентиляционных систем предусмотреть отображение, архивирование и протоколирование следующей информации:
· графическое изображение установок с датчиками температуры и влажности, термостатами от замораживания, реле дифференциального давления, регулирующими клапанами, увлажнителями воздуха, воздушными клапанами;
· номера установок;
· показания датчиков температуры, влажности;
· показания датчиков реле дифференциального давления;
· показания положения регулирующих клапанов 0..100%;
· режим «работа/останов» вентиляторов;
· режим «работа/ останов» насосов;
· положение воздушных клапанов «открыт/закрыт»;
· остановка систем при срабатывании пожарной сигнализации;
· остановка систем при возникновении угрозы замораживания калорифера;
· остановка установки при отсутствии перепада давления на вентиляторе;
· отключение увлажнителя воздуха при остановке вентилятора кондиционера;
· работа систем по заданному временному графику или без него;
· сигнализация аварий и нештатных ситуаций в случае возникновения неисправности оборудования, а также - выхода значений технологических параметров за пределы заданных диапазонов;
· регистрация аварий и нештатных ситуаций в журнале сообщений;
· журнал регистрации параметров на текущее время с указанием наименования контролируемых параметров, единиц измерения, номера контроллера и канала ввода/вывода.
2.3.3. Электропитание системы автоматизации и диспетчеризации должно осуществляться от сети переменного тока напряжением 380/220 В, частотой 50 Гц с использованием источников бесперебойного питания на аккумуляторных батареях и обеспечиваться как питание электроприемников первой категории
Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться - при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня - о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.
Грани взаимодействия
Прежде, чем приступить к препарации процесса создания технического задания, поговорим о четырёхугольнике, в который попадают исполнитель и заказчик, приступая к проекту.
Требования - желаемое поведение системы, описанное заказчиком или холдером процесса, подлежащее реализации. Как правило, требования формируются на основании опыта работы, представления правильного поведения программы. Это ключевая информация для разработчика (вендора), однако именно на этапе сбора требований возникает самое большое число коллизий, ошибок, излишних запросов и проч.
Ресурсы - люди, машины, инвентарь, среда разработки, время и деньги, которые должны использоваться в процессе реализации требований. Ресурсы требуют чёткого планирования и оценки на этапе согласования технического задания. Грамотная расстановка приоритетов со стороны заказчика и распределение трудовых ресурсов со стороны вендора позволяют избежать срыва сроков и минимизировать иные риски.
Возможности - если кратко, то это то, что реально может сделать вендор (исполнитель). Рассмотрим на примере нашей RegionSoft CRM . Клиент покупает систему и составляет техническое задание на доработку: нужно создать интеграцию с сайтом и привязку событий в CRM к номеру заказа интернет-магазина. Это реально исполнимое требование, у нас есть ресурс и возможность сделать это. А ещё нужно разработать и прикрутить к CRM CMS, систему управления контентом сайта. Теоретически мы это можем, но у нас нет возможности это сделать дёшево, а у клиента нет возможности заплатить нам столько, чтобы мы перекинули на задачу человеческие и временные ресурсы. В итоге от этого требования заказчик отказывается - да и CMS ему не особо нужна, всё и так хорошо. Но о «жадности» ТЗ- позже.
Ограничения - набор препятствий, которые делают выполнение задач из ТЗ затруднительным или невозможным: бюджет, стек технологий, лицензионные проблемы, законодательные запреты, аппаратные конфигурации и проч.
Таким образом, все четыре сущности тесно переплетаются между собой и определяют успех проекта в целом. Рассмотрим каждый элемент и попробуем выделить критические моменты, которые нужно иметь ввиду, работая над техническим заданием.
Сбор и анализ требований
Это очень важный внутрикорпоративный процесс, в ходе которого выясняется, чего хотят от программы (здесь и далее возьмём CRM, но методы работают и с другими типами софта) потенциальные пользователи. Если вы обратитесь к крупному вендору типа SAP или системному интегратору, то с высокой долей вероятности вам предложат воспользоваться услугами бизнес-консультанта (он же персональный менеджер, он же аккаунт-менеджер, он же «теперь ваш представитель в нашей компании»). На самом деле, в большинстве случаев это обычный вышколенный продажник, у которого две задачи: накрутить стоимость проекта и не дать вам сорваться с крючка.
Он находится здесь уже целый час и даже не притронулся к белой маркерной доске. Он не настоящий системный аналитик
Лучше, чем вы и ваши сотрудники, вашу компанию не знает никто. А значит, сбор и анализ требований - исключительно ваша задача, в которой вендор может помочь и направить, но ни в коем случае не вмешаться в процесс. Расспросите разработчика о подобных внедрениях, уточните, на что обратить внимание и приступайте. Кстати, неплохим помощником может быть ваш сотрудник, который хорошо разбирается в профильной теме и примерно представляет архитектуру ПО и знаком с процессом разработки - он может выступить в роли аналитика и внутреннего эксперта, замкнуть на себе процесс создания ТЗ и общения с вендором.
Есть очень простая схема сбора требований.
- Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут пользоваться CRM. Расскажите о решении, которое предполагается выбрать, предоставьте доступ к демо-версии.
- Члены рабочей группы должны передать информацию сотрудникам и запросить у них пожелания к новой программе в абсолютно свободной форме. Если кто-то из сотрудников никогда не сталкивался с подобным софтом и не готов говорить в аспекте будущего использования, нужно попросить его описать свои периодические задачи, это универсальный подход.
- Затем каждое подразделение устанавливает, чего нет в CRM или чему она не соответствует, и агрегирует информацию.
- Рабочая группа анализирует собранные требования, проверяет и исключает пересечения. Например, нередко отдел продаж и отдел маркетинга заказывают один и тот же отчёт, но в требованиях могут по-разному называться поля и сущности, хотя данные за ними стоят одинаковые. Соответственно, нужно придти к единой форме.
- Рабочая группа формирует список требований и расставляет приоритеты. На этом этапе можно подключить вендора, поскольку он отвечает за ресурсы. Например, можно попросить создать пользовательский отчёт для RegionSoft CRM, а можно заказать интеграцию с сайтом. Это совершенно разные по срокам задачи, здесь очень важен приоритет.
Анатомия технического задания
Если говорить о процессе создания технического задания, то существует несколько этапов. Их последовательное прохождение и приводит заказчика к желаемой доработке. Вот они.
- Выявление - определение требований, поиск проблем, которые необходимо решить.
- Анализ - разбор требований, выделение ключевых потребностей, обобщение.
- Адаптация - оценка требований в контексте возможностей CRM и существующих бизнес-процессов.
- Документирование - формальное и подробное описание требований, согласование ТЗ.
- Общение с вендором (разработчиком) - итеративное взаимодействие с вендором по поводу доработок согласно составленному ТЗ.
- Реализация - работа вендора над созданием необходимой функциональности. Лучше, если вендор будет постоянно на связи с заказчиком - так продукт на выходе будет наиболее точно соответствовать видению клиента.
- Тестирование - проверка функциональности сотрудниками вендора, внутренними экспертами клиента и конечными пользователями с целью установления соответствия доработки и ТЗ, работоспособности системы с изменениями.
Уровень бизнеса - самый глобальный уровень, на котором решаются сложные и приоритетные задачи. К этому уровню можно отнести интеграции, доработки и моделирование бизнес-процессов, разработку новых функциональных модулей. Как правило, это ресурсоёмкая разработка, с серьёзными консультациями и тесной совместной работой с заказчиком. Например, в своё время в RegionSoft CRM такой заказной доработкой были складской учёт, касса и производство. Постепенно изменения вошли в релиз, а позже позволили создать новый продукт для оптовых, розничных магазинов и гипермаркетов - RegionSoft Retail .
Уровень пользователя или группы пользователей. На этом уровне реализуются задачи по доработке существующего интерфейса. Например, пользователь может захотеть, чтобы при наведении курсора на клиента появлялось окошко со номером и статусом последнего заказа или существовал кастомный отчёт с особой группировкой данных. Доработки на этом уровне занимают меньше времени, но их может быть много - например, несколько требований от отдела маркетинга, логистики и технической поддержки.
Уровень функциональности. Зачастую его трудно отделить от предыдущего, здесь работает формальный критерий - доработка не на уровне отображения чего-либо в интерфейсе, а на уровне доработки логики системы. Сюда можно отнести требования к различного рода сортировкам, интеграциям с чатом, возможностям телефонии.
Уровень сервиса - на самом деле, требования этого уровня должны первыми попадать в новые сборки с фиксами. Это задачи по скорости отклика системы, работе под высокой нагрузкой, безопасности. В идеальном варианте у вендора не должно быть таких доработок - корпоративный софт не должен тормозить, терять данные, схлопывать формы и раздавать права доступа одного уровня. Но если требование появилось, и оно не связано с персональной паранойей заказчика или проблемами на стороне аппаратного обеспечения, стоит уделить ему повышенное внимание.
Уровень технологии - последний в списке, но по важности и сложности опережающий остальные. Это могут быть требования клиента, связанные с платформой, операционной системой или устройствами. Например, запрос сборки под MacOS. Очень здорово, если такие требования постепенно перерастут в релизы, но иметь их фиксы обязательно. Именно из запросов клиентов на этом уровне мы сделали сборку RegionSoft CRM под MacOS и добавили удалённый доступ по технологии TRM как временное решение редкого, но существующего запроса мобильной версии.
Анатомия технического задания проста, во всяком случае в виде скелета. Обязательные части технического задания помогают заказчику сосредоточиться на проблеме и сформулировать задачу правильно, а исполнителю - понять, что же от него хотят. Кстати, о понимании. Конечно, в начале поста мы немного слукавили, отрицая бизнес-консультантов как класс. Дело вот в чём: каждый вендор работает на рынке по несколько лет (мы сейчас не о CRM-однодневках), а то и десятков лет, а значит имеет набор кейсов практически по каждой отрасли. Соответственно, и инженеры, и программисты, и продажники знакомы со спецификой внедрения в каждом типе компании. Но опять-таки, важно ориентироваться именно на свой бизнес.
Для кого? В этом разделе нужно описать, кто будет конечным пользователем доработки, какие задачи и с какой периодичность планируется решать.
Приведу пример. В одной компании внедряли CRM, предполагалась работа на довольно большом массиве данных (несколько десятков миллионов записей в месяц, несколько сотен тысяч записей в день). Начальник отдела продаж запросил отчёт по выгрузке этих записей с периодичностью «ежедневно». Естественно, что такой отчёт при одновременной работе сотни пользователей нагружал систему - были найдены решения по оптимизации процесса. Уже в ходе работы выяснилось, что продажник перестраховался и отчёт нужен ему только по итогам месяца, и то его можно запускать по расписанию ночью. Стоит ли говорить, что время и деньги были потрачены зря.
Зачем? Обоснование необходимости доработки и его место в бизнес-процессе. Этот пункт больше нужен самому заказчику, но и вендору нелишне знать, какие ещё процессы будут затронуты. Иногда это помогает найти альтернативное решение.
Что должно делать? Самый информативный блок - в нём описываются требования, ожидания от системы. И вот тут случаются тем самые перлы, чудеса и коллизии, которые впору отправлять на башорг, и которые ну очень усложняют жизнь. Причина одна - пользователь не знает, чего он хочет, что нужно сделать. Есть ещё маленькая подпричина - пользователь не может сформулировать требования. И тут задача разработчика (рабочей группы, аналитика, если он есть) помочь сформулировать потребность верно, выбрать целесообразное требование, вписать задачу в контекст работы системы. В этом же блоке нужно упомянуть ожидаемый результат.
Параметры технического задания - сроки, этапы реализации, ответственные от всех сторон, необходимые контакты и проч. Фактически это совокупность важных формальных вещей, делающих документ техническим заданием. Техническое задание обязательно должно быть согласовано и подписано сторонами во избежание многочисленных изменений по ходу разработки (они всё равно будут, но в меньшем объёме).
В идеальном варианте техническое задание составляется при активном участии вендора, и его итог представляет собой примерно такую структуру:
- Описание требования каждого механизма и каждой функциональности
- Описание реализации данной функциональности
- Стоимость работ по каждому из этапов в отдельности
- Общая стоимость работ по данному техническому заданию
- Сроки исполнения работ с разбивкой по этапам и указанием очерёдности
- Описание условий установки и тестирования доработки
- Оговорки об исчерпывающем характере технического задания и иные условия
10 правил, написанных слезами разработчика
Техническое задание на доработку должно быть ТЗ на доработку , а не 300-страничным описанием CRM, которая необходима клиенту. Перед составлением требований следует внимательно ознакомиться с интерфейсом системы, её возможностями, документацией - скорее всего, большая часть «хотелок» уже есть в базовой поставке. Вторым шагом я бы рекомендовал обратить внимание на встроенные инструменты доработки (дизайнеры отчётов, конфигураторы и проч.) - возможно, нужные изменения сможет внести штатный программист (во многих компаниях они есть).Техническое задание не должно быть жадным. Нередко бизнес переоценивает свои возможности или желает получить «всё и сразу». Такой подход не оправдан ни с точки зрения денег, ни с точки зрения бизнеса. Вендор, как правило, существует не пару недель (в случае RegionSoft - 15 лет), и к нему можно обратиться и через некоторое время, когда вы уже реально поймёте, чего в CRM не хватает.
Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение: забыть про ERP, поплакать, интегрировать учёт 1С с новой CRM и радоваться удобной реализации. Но вбуханных денег жалко! И клиент требует интегрировать CRM с ERP. Мы и не такое делали, но зачем такая трата, зачем две относительно схожих системы?
Техническое задание должно быть реалистичным и выполнимым - как по требованиям, так и по срокам. Здесь важно прислушиваться к мнению вендора, поскольку он точно знает, какое время уйдёт на ту или иную задачу. Поверьте, разработчику не выгодно тянуть время и накручивать срок - ему выгодно завершить как можно больше проектов и сделать это хорошо, чтобы не получить удар по репутации. Что касается реалистичности, то избежать просьб допилить CRM до уровня системы управления коллайдером просто: следует включать в требования то, что действительно нужно на данный момент и в обозримом будущем.
Например, RegionSoft CRM - десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании. Нет, конечно, всё имеет свою цену, но опять же - в общем случае требование невыполнимое.
Не нужно путать с ситуацией, когда речь идёт о заказной разработке и в корне меняется идея и логика работы приложения, фактически спонсируется создание нового программного обеспечения «под себя». Но это другая история.
Техническое задание должно быть подробным. Нужно указать все значимые детали будущего проекта: от периодичности использования программы до пожеланий по интерфейсу. Чем подробнее будут изложен требования, тем проще и быстрее пройдут реализация и тестирование. Особо стоит уделить внимание деталям, если вы работаете в специфичной отрасли (медицина, страхование, банки) - подробное изложение нюансов взаимодействия бизнеса и программы обеспечит понимание задачи вендором и быструю адаптацию системы к вашей компании.
Обязательно обратите внимание на форматы чисел, названия полей, наличие или отсутствие выпадающих списков, поведение кнопок и хинтов, типы данных. Если заказчик использует собственные формулы, которые необходимо заложить в логику работы CRM (например, расчёт дилерских бонусов ), эти формулы должны быть прописаны с полной расшифровкой их обозначений и логики расчёта.
Да, корпоративный софт выглядит примерно так, и в нём много важных мелочей
Техническое задание должно быть однозначным и точным. Расплывчатые формулировки, варианты реализации, нечёткие требования - всё это путь в тупик. Бывает, что клиент из благих намерений пишет в ТЗ несколько вариантов поведения системы, близких, но не равнозначных. В этом случае он уверен, что помогает, подсказывает программисту, но на самом деле благими намерениями устлана дорога в ад разработчик должен понимать, что именно нужно, а как это сделать он выберет сам, исходя из особенностей системы и стека используемых технологий.
В этом году ты можешь снова загадать одно желание. Только, прошу, не трать его на то, что даже я не смогу выполнить, типа понятных бизнес-требований!
Техническое задание должно быть написано на человеческом языке. И это важно, нет, ВАЖНО. Выделю две ситуации, когда проблемы с языком приводят к затягиванию реализации проекта.
- Клиент пытается продемонстрировать свою техническую грамотность и городит конструкции типа: «имплементировать окно с хинтом в тело календаря с возможностью реакции на колл события…» вместо «в календаре должно всплывать окно, в котором можно отметить задачу как выполненную». Если у вас или вашего внутреннего эксперта нет навыков написания технических текстов, не гуглите - пишите обычными словами, мы их понимаем.
Техническое задание не должно быть жалобной книгой. Нужно решать проблему, а не описывать её, уделяя внимание шрифтам и забывая об описании требований. ТЗ должно содержать не только саму проблему, но и её решение на уровне осмысления - далее разработчик уже решит её на уровне кода. Сравните «отдел продаж плохо планирует, теряет цифры, уже год боремся» и «необходимо создать отчёт, который будет сохранять значения плана и факта продаж ежемесячно, в разрезе групп номенклатуры» .
Техническое задание должно уметь смотреть в будущее. Ну не совсем оно, а люди, стоящие за ним. Если известно, что в скором времени будут происходить изменения в бизнес-процессах, это нужно обязательно учитывать, чтобы не платить за доработку дважды.
Техническое задание не должно быть бюрократичным. Если вы хоть раз составляли этот документ, то наверняка ощущали, как тяжело избежать соблазна скатиться в бюрократию, наворотить вводных слов, строгих оборотов и описать каждый пункт как статью Уголовного кодекса (желательно с наказанием всем за нарушение). Бюрократические формулировки маскируют неполное понимание целей создания ТЗ. Ответственность вендора прописана в договоре, там же написан бюджет. Не стоит переносить эти моменты в техническое задание.
Техническое задание должно быть техническим заданием. Звучит парадоксально, но часто вместо ТЗ мы читаем письма, жалобы, договоры, заново написанную инструкцию к CRM или протокол совещания. Конечно, работать по такому документу невозможно. Для того, чтобы не уйти от формы и содержания, воспользуйтесь старой школьной уловкой: рассмотрите термин по словам. Техническое - значит, диктует доработку, технику, направлено на решение задачи посредством изменения ПО. Вот о задаче в контексте ПО и нужно говорить. Задание - значит, постановка вопроса, проблемы, без советов, подсказок и предварительных оценок. Просто формулировка задачи.
Заповеди закончились, теперь отповедь
Кроме перечисленных правил, есть ещё несколько вещей, о которых стоит рассказать. Речь идёт о целях, планах и ожиданиях - всех тех оставляющих, которые делают проект успешным, а отношения вендора и клиента почти дружескими.Техническое задание нужно писать быстро , даже если перед вами стоит задача автоматизации процессов сотового оператора или крупного гипермаркета. Это связано с тем, что технологии развиваются с огромной скоростью и даже та система, которую вы внедряете, за полгода-год может пережить мажорный релиз (а иногда и два), получить новую функциональность. Возможно, придётся пересмотреть необходимость доработок и начать процесс заново.
Наконец он нашёл время закончить ТЗ. Но, увы, вокруг не осталось разработчиков, чтобы его реализовать.Клиент не знает о стеке и технических ограничениях. И знать не должен - это задача вендора, именно он оценивает работы после составления технического задания. Заказчику не стоит углубляться в технологии и на каждой запятой спрашивать, сможет ли вендор сделать ту или иную вещь. Составьте комплексное ТЗ и разработчик выберет подходящую архитектуру - нередко даже лучшую, чем вы могли подумать.
Оценить бюджет и избежать неприятных сюрпризов - едва ли не совместная задача номер один. Не стоит дёргать вендора и требовать от него примерной оценки работ (ну хоть приблизительно, навскидку, на глазок, а как у других, ну в проектах такого типа, а по опыту, ну так, в пределах погрешности). Полная оценка бюджета возможна только после прочтения, анализа и окончательного утверждения технического задания. Если ваш разработчик поступает иначе - готовьтесь к тому, что доработка обойдётся минимум в два раза дороже.
Исходите из объективной необходимости изменений и расширений - выше я писал, что разработчик не исчезает и готов внести изменения и дополнения по вашим требованиям в любой момент. Поэтому не пытайтесь создать CRM/ERP мечты сразу, не требуйте от вендора кнопку «Всё работает, пока я пью кофе» - поработайте в системе, определите критичные для вас замечания и приступайте к сбору требований и составлению ТЗ.
О технических заданиях можно писать бесконечно, это настоящий генератор не только мемов и баек, но и головной боли. Можно рассказать о приоритетах и правилах оформления, о ГОСТе 1989 года, который делает ТЗ бесчеловечным, о стандартах IEEE, которые немного лучше, о прототипах и дополняющих их ТЗ. Но в конце хотелось бы ограничиться одним, самым главным правилом: техническое задание - не норма права, не ГОСТ и не догма, поэтому, если можно улучшить - улучшайте, можно упростить - упрощайте, можно сделать изящно и чтобы всем нравилось - делайте. Уверен, никто после такого не ткнёт носом в ТЗ и не скажет, что там такого не написано. Или почти никто.
Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря - 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.
Ну а если вам нужна CRM-система (с доработкой или без), то заходите на наш сайт , там много о CRM, её преимуществах и прочем корпоративном софте.
И да, мы всегда ищем партнёров, которые готовы продавать CRM и другие продукты, дорабатывать и продавать CRM, продавать софт и обучать пользователей. Разделение доходов честное и выгодное партнёру. Покажем, расскажем, научим. Пишите на [email protected]
Слайды, слайды. Комиксы взяты с http://www.modernanalyst.com/ и из Pinterest. Если есть лучший перевод - будем рады его внести в пост.
Ввиду того, что часто просят привести примеры ТЗ, делюсь с сообществом частью своих наработок. Коммерческой ценности (за давностью лет и конфигурации) данные документы не имеют, но надеюсь, могут пригодиться в качестве образцов.
Техническое задание:
Автоматизированная
система «СБЫТ».
Техническое задание
На листах
" _" ______________ 2010 г.
1. Общие сведения
Наименование автоматизированной системы
«АС СБЫТ»
Заказчик
Исполнитель
Основание для выполнения работ
Плановые сроки начала и окончания работ по созданию системы
Начало работ: 01.09.2010
Окончание работ: 31.12.2010
Назначение и цели создания системы
Назначение системы
Разрабатываемая автоматизированная система предназначена для автоматизации процессов сбыта предприятия..
Цели создания системы
Цели создания автоматизированной системы
Целями разработки «АС СБЫТ»являются:
- 3. Характеристика объекта автоматизации
3.1 Бизнес процессы предприятия
3.1. 1 Бизнес процесс «Заключение договора»
3.1.2. Бизнес процесс «Начисление оплаты»
- 4. Требования к системе.
4.1. Требования к системе в целом.
4.1.1. Разрабатываемые в АС методы и программные модули должны содержать возможности дальнейшего развития системы.
5.1.1. Разрабатываемая система должна состоять из автоматизированных систем, подсистем и учетных модулей, выделяемых по функциональному назначению в соответствии со сложившейся методикой построения автоматизированных систем финансово-экономического класса.
5.1.2. Разрабатываемая АС должна обеспечивать простоту настройки автоматизированного рабочего места (АРМ) каждого конкретного исполнителя в соответствии со сложившейся системой учета.
5.1.3. Разрабатываемая АС должна обеспечивать разграничение прав доступа пользователей и предоставлять возможность доступа к информации в объеме, необходимом и достаточном для осуществления должностных обязанностей каждого исполнителя.
5.1.4. Защита информации от несанкционированного доступа должна быть реализована с использованием следующих механизмов:
1. Ограничениями прав доступа на уровне платформы 1С:Предприятие 8.1.
2. Дополнительными ограничениями прав доступа на уровне среды исполнения.
5.1.4.1.Приоритетными должны являться ограничения прав доступа на уровне платформы. Снятие дополнительных ограничений на уровне среды исполнения не дает прав доступа к объектам или функциям системы, если на них наложено системное ограничение.
5.1.4.2.Защита информации на уровне платформы
· Защита информации на уровне платформы обеспечивается системными средствами. При этом регулируются права на чтение и редактирование объектов системы, использование интерфейсов, системных функций и выполнение регламентных операций с данными информационной системы.
· Все права доступа должны быть систематизированы в соответствующие наборы - Роли информационной системы.
· Список пользователей информационной системы должен определяться администратором системы.
· Права доступа каждого пользователя должны определяться набором Ролей информационной системы, доступных для него.
· Наборы Ролей информационной системы, доступных для каждого пользователя должен определять администратор системы.
· При начале работы в системе пользователь должен пройти процедуру авторизации, указав свое имя в системе и пароль.
5.1.4.3. Защита информации на уровне среды исполнения
Для ряда справочников в системе должны быть обеспечены дополнительные ограничения прав редактирования.
Справочники, для которых необходимо установить запрет на редактирование в системе:
- Адресные сокращения
- Валюты
- Виды взаиморасчетов
- Виды деятельности контрагентов
- Группы пользователей
- Документы удостоверяющие личность
- Должности организаций
- Подразделения
- Пользователи
- Статьи движения денежных средств
- Статьи затрат
- Тарифы
5.1.5. Для обеспечения сохранности информации при авариях, должно быть предусмотрено ежедневное автоматическое архивирование данных.
5.1.6. Требования к эргономике и технической эстетике
5.1.6.1.Для обеспечения унификации оформления пользовательских интерфейсов по умолчанию должны использоваться панели инструментов и контекстные меню, автоматически генерируемые платформой 1С.
5.1.6.2.Терминология, используемая для обозначения объектов и действий пользователей в системе должна соответствовать стандартной терминологии предметной области.
5.2. Требования к структуре и функционированию АС "СБЫТ".
5.2.1. АС "СБЫТ" должна состоять из следующих автоматизированных подсистем:
Подсистема ввода первичной информации об абоненте (заключения договора);
Подсистема формирования документов на оплату;
Подсистема связи с системой АСКУЭ;
Подсистема связи с платежными терминалами.
5.2.2. Состав Подсистемы ввода первичной информации об абоненте (заключения договора) должен быть следующим:
Документ «Договор с абонентом»;
5.2.3. Состав Подсистемы формирования документов на оплату должен быть следующим:
Документ « Квитанция»»
Документ «Начисление штрафных санкций»
Документ «Потребленная энергия»
Модуль проверки состояния взаиморасчетов
5.2.4. Состав Подсистемы связи с системой АСКУЭ должен быть следующим:
Модуль Связь с системой АСКУЭ.
5.2.5. Состав Подсистемы связи с платежными терминалами должен быть следующим:
Модуль Связь с с платежными терминалами.
5.3. Требования к функциям модуля Подсистемы ввода первичной информации об абоненте (заключения договора)
5.3.1. Подсистемы ввода первичной информации об абоненте (заключения договора) должна выполнять следующие функции:
Ввод и хранение информации об установленной мощности контрагента (в дальнейшем абонента);
Ввод и хранение информации об установленных счетчиках абонента;
Ввод и хранение информации о тарифах абонента;
Ввод и хранение информации о условиях начисления штрафных санкций абонента;
Ввод и хранение информации о сроках действия договора;
5.4. Требования к функциям Подсистемы формирования документов на оплату
5.4.1. Подсистема формирования платежных документов должна выполнять следующие функции:
Определение состояния взаиморасчетов с абонентом и определение условий возникновения штрафных санкций.
Формирование документов на оплату (квитанций или счетов на оплату).
5.5. Требования к функциям Подсистемы связи с системой АСКУЭ
5.5.1. Подсистемы связи с системой АСКУЭ должна выполнять следующие функции:
Передачу данных о вновь заключенных договорах с абонентами. Ключом связи должно быть уникальность пары «ID абонента» - «Код договора абонента».
Получение данных о потребленной электроэнергии абонентом. Ключом связи должно быть уникальность пары «ID счетчика» - «Код счетчика».
5.6. Требования к функциям Подсистемы связи с платежными терминалами
5.6.1. Подсистемы связи с системой АСКУЭ должна выполнять следующие функции:
Получение данных о произведенных платежах абонентами за электроэнергию через платежные терминалы.
- 6. Порядок контроля и приемки АИС "СБЫТ".
6.1.Устанавливается следующий порядок предъявления и сдачи Заказчику результатов работ:
6.1.1. Исполнитель демонстрирует работоспособность ПО на контрольном примере.
6.1.2. Данные для контрольного примера готовят представители Заказчика.
6.1.3. Исполнитель передает программное обеспечение в информационный отдел Заказчика и выполняет обучение администратора Заказчика.
6.1.4. По результатам решения контрольного примера должен быть подготовлен Акт о передаче ПО в опытную эксплуатацию.
6.1.5. В случае несоответствия функциональных возможностей ПО требованиям ТЗ Исполнитель выполняет устранение замечаний в рамках общей стоимости разработки АС.
6.1.6. При возникновении дополнительных к ТЗ требований Заказчика, составляется дополнительное ТЗ на доработку.
6.1.7. Наличие дополнительных требований Заказчика не должно являться основанием отказа от подписания Акта о передаче ПО в опытную эксплуатацию.
6.1.8. После передачи ПО в опытную эксплуатацию, по согласованному с Заказчиком Графику внедрения, Исполнитель производит краткое обучение персонала Заказчика работе с ПО и передает Инструкцию по работе с ПО на каждую подситему.
6.1.9. При внедрении ПО (опытной эксплуатации) Заказчик осуществляет:
Ввод необходимой НСИ;
Ввод фактических данных;
Формирование отчетности и проверку результатов работы.
6.1.10. В процессе внедрения Исполнитель должен оказывать помощь Заказчику в рамках Графика внедрения.
6.1.11. В случае слабой подготовки персонала Заказчика к внедрению и необходимости оказания дополнительной помощи Исполнителем для успешного внедрения ПО, должен быть составлен дополнительный протокол согласования договорных цен на оказание информационно-консультационных работ.
6.2.Порядок дальнейшего сопровождения задач АС "СБЫТ".
6.2.1. После сдачи ПО в эксплуатацию, дополнительные доработки и пожелания Заказчика могут быть реализованы по согласованному с Заказчиком ТЗ.
В ТЗ должна быть указана трудоемкость и стоимость работ по реализации дополнительных требований.
6.2.2. Исполнитель обязуется поддерживать телефонную "горячую линию" по сопровождению программного обеспечения.
6.2.3. По желанию Заказчика, Исполнитель может осуществлять сопровождение программного обеспечения непосредственно у Заказчика, которое должно производиться на основании дополнительного договора по сопровождению ПО.
6.2.4. Ошибки, выявленные Заказчиком в течение полугода с момента передачи ПО в эксплуатацию, должны устраняться Исполнителем оперативно и бесплатно.
В случае, если Исполнитель обнаружит, что ошибка возникла в результате неправильных действий Заказчика, время, затраченное Исполнителем на ее поиск и устранение, должно быть оплачено дополнительно.
6.2.5. Заказчик, в течении года после покупки 1С: Предприятие, имеет право на бесплатное получение всех обновлений от фирмы 1С, связанное с развитием программ 1С и изменением законодательства. Установка изменений должна производиться силами АСУ Заказчика.
6.2.6. Исполнитель гарантирует сохранение конфиденциальности содержания баз данных Заказчика и любой другой информации, полученной от Заказчика в процессе разработки, внедрения или сопровождения АС.
Технический проект:
УТВЕРЖДАЮ ПРЕДСТАВЛЯЮ НА УТВЕРЖДЕНИЕ
" "______________ 2010 г. " "_______________ 2010 г.
Приложение к техническому заданию от «____» ________ 2010
Автоматизированная
система «СБЫТ».
Технический проект
На листах
Действует с «__» ____________ 2010 г.
Справочники. 3
Счетчики. 3
Тарифы.. 3
Подстанции. 3
Варианты штрафных санкций. 3
Перечисления. 4
Виды начислений. 4
Регистры сведений. 4
Значение Тарифов. 4
Тарифы абонентов. 4
ПоказанияСчетчиков. 5
Регистры накопления. 5
Потребление энергии. 5
Документы.. 6
Договор с абонентом.. 6
Потребленная Энергия. 6
Квитанция. 7
Начисление штрафных санкций. 9
Обработки. 10
Получение данных из системы АСКУЭ. 10
Получение данных из платежной системы.. 11
Справочники
Счетчики
Реквизиты:
Тарифы
Реквизиты: нет
Варианты штрафных санкций
Реквизиты: нет
Перечисления
Виды начислений
Значения:
Регистры сведений
Сроки действия договоров
Периодичность: Непериодический
Назначение: Предназначен для хранения сроков действия договоров с абонентами
Измерения
Значение Тарифов
Периодичность: День
Назначение: Предназначен для хранения тарифов и дат, с которых тарифы начинают действовать их действия
Измерения
|
Реквизит |
Назначение |
|
|
Стоимость дневного тарифа |
||
|
Стоимость ночного тарифа (может быть не задан) |
Тарифы абонентов
Периодичность: День
Назначение: Предназначен для хранения тарифов назначенных абоненту согласно договорам
Измерения
|
Реквизит |
Назначение |
|
|
Справочник Тарифы |
Тариф абонента |
ПоказанияСчетчиков
Периодичность: День
Назначение: Предназначен для хранения показаний счетчиков для последующего начисления оплаты
Измерения
|
Реквизит |
Назначение |
|
|
ПоказанияДень |
Показание счетчика |
|
|
ПоказанияНочь |
Показание счетчика |
Регистры накопления
Потребление энергии
Назначение: Предназначен для хранения информации о потреблении энергии для последующего начисления оплаты
Тип регистра: оборотный
Измерения
Документы
Договор с абонентом
Назначение: Предназначен для отражения факта заключения договора с абонентом
|
Реквизит |
Назначение |
|
|
Контрагент |
Справочник Контрагенты |
|
|
ДоговорКонтрагента |
||
|
Справочник Тарифы |
||
|
УстановленнаяМощность |
Хранение установленной мощности абонента в КВТ |
|
|
ДатаНачалаДействия |
Дата с которой действует договор |
|
|
ДатаОкончанияДействия |
Дата окончания действия договора |
|
|
Организация |
Справочник Организации |
|
|
ВариантНачисленияШтрафов |
||
|
Номенклатура |
Справочник Номенклатура |
|
|
Ручная Корректировка |
Признак ручной корректировки проводок документа |
Табличная часть: Счетчики и Тарифы
Проведение документа
Документ проводится:
По регистру сведений «Показания счетчиков» куда прописывает счетчики абонента и начальные показания счетчиков;
По регистру сведений «Тарифы абонентов» куда прописывает тариф установленный абоненту с даты начала действия договора
По регистру сведений «Сроки действия договоров» куда прописывает договор, дата начала действия и дату окончания действия договора
Потребленная Энергия
Назначение: Предназначен для отражения показаний счетчиков на определенную дату
Заполнение документа
Документ может заполнятся двумя способами: ручным вводом и путем вызова обработки «Получение данных из системы АСКУЭ»
Проведение документа
Документ проводится:
По регистру сведений «Показания счетчиков» куда прописывает показания счетчиков на дату документа;
По регистру накоплений «Потребленная энергия по следующему алгоритму:
1. Берутся показания счетчиков из регистра сведений «Показания счетчиков» на дату документа и предыдущее значения показания счетчиков.
2. Разницы значений показаний заносятся в соответствующие ресурсы регистра накопления.
Печатные формы
Реестр показаний счетчиков
Квитанция
Назначение: Предназначен для отражения начислений абонентам
Заполнение документа
Документ может заполнятся двумя способами: ручным вводом и путем вызова обработки «начисление оплаты»
Табличная часть: Показания счетчиков
|
Реквизит |
Назначение |
|
|
Контрагент |
Справочник Контрагенты |
|
|
ДоговорКонтрагента |
Справочник Договоры контрагентов |
|
|
Номенклатура |
Справочник Номенклатура |
|
|
Справочник Тарифы |
Тариф абонента согласно договора |
|
|
Справочник Счетчики |
||
|
ВидНачисления |
Перечисление ВидыНачислений |
|
|
ПотребленнаяЭнергия |
Потребленнаяэненргия |
|
|
Значение тарифа |
Значение тарифа на дату документа |
|
|
Начисленно |
Сумма начисленная абоненту |
Проведение документа
Документ проводится:
По плану счетов налоговый:
Печатные формы
Реестр начислений
Алгоритм заполнения
Документ заполняется на основании справочника «Договора контрагентов» .
- Из справочника выбираются договоры, у которых, согласно регистра сведений «Сроки действия договоров» ДатаНачала меньше даты документа и ДатаОкончания больше даты документа;
- Выбираются счетчики соответствующие этим договорам;
- Для счетчиков определяется потребление энергии как оборот по регистру накопления «Потребление энергии» за период между датой документа и датой предыдущего документа, если дата предыдущего документа неизвестна, то берется весь оборот по регистру. Полученное значение записывается в поле «ПотребленнаяЭнергия»
- Устанавливается тариф согласно договора и значение тарифа на дату документа;
- Устанавливается вид начисления «По показаниям счетчика»;
- Рассчитывается Поле Начислено как произведение ПотребленнаяЭнергия на ЗначениеТарифа.
Алгоритм проведения
Кт. 90.01 с аналитикой СубконтоКт1 - Номенклатура.НоменклатурнаяГруппа, СубконтоКт2 - Номенклатура.СтавкаНДС.
Если есть Кредитовое сальдо По счету 62.02, то проводится зачет аванса с проводкой
Дт. 62.02 с аналитикой СубконтоДт1 - Контрагент, СубконтоДт2 - Договор контрагента
Сумма проводки - минимальное значение из кредитового сальдо по счету 62.02 и значения реквизита «начислено»)
Дт. 90.03 с аналитикой СубконтоДт1 - Номенклатура.НоменклатурнаяГруппа, СубконтоДт2 - Номенклатура.СтавкаНДС
Кт. 62.01 с аналитикой СубконтоКт1 - Контрагент, СубконтоКт2 - Договор контрагента
Сумма проводки = «Начисленно»* СтавкаНДС/(100+ставкаНДС), где СтавкаНДС - «Номенклатура.СтавкаНДС»
Начисление штрафных санкций
Назначение: Предназначен для отражения начислений штрафов абонентам
Заполнение документа
Документ может заполнятся двумя способами: ручным вводом и путем вызова обработки «начисление штрафов »
Табличная часть: Показания счетчиков
|
Реквизит |
Назначение |
|
|
Контрагент |
Справочник Контрагенты |
|
|
ДоговорКонтрагента |
Справочник Договоры контрагентов |
|
|
ВариантНачисленияШтрафов |
Справочник Варианты Начисления штрафных санкций |
|
|
Начисленно |
Сумма начисленная абоненту |
Проведение документа
Документ проводится:
По плану счетов хозрасчетный:
По плану счетов налоговый:
Печатные формы
Реестр начислений
Квитанция на оплату со штрих кодом
Штрих-код формируется при помощи шрифта «Infograftbarcode»
Алгоритм формирования Строка «0000»+Код договора абонента+Начислено
Макет квитанции прилагается в файле КВ_1.mxl
Алгоритм проведения
Для каждой строки табличной части «Показания счетчиков» должны быть сделаны следующие проводки:
Дт. 62.01 с аналитикой СубконтоДт1 - Контрагент, СубконтоДт2 - Договор контрагента
Кт. 91.01 с аналитикой СубконтоКт1 - Прочие доходы.
Сумма проводки - значение реквизита «Начислено»;
Обработки
Получение данных из системы АСКУЭ
|
Точность |
Назначение |
|||
|
Код счетчика в системе «Сбыт», совадает с ID_счетчика в системе АСКУЭ |
||||
|
Показания счетчика по дневному тарифу |
||||
|
Показания счетчика по ночному тарифу |
Реквизиты обработки
Алгоритм обработки:
- Получить из строки файла передачи данных код счетчика
- Найти по коду соответствующий элемент в справочнике «счетчики», если элемент не найден, то выдать сообщение « Не найден счетчик с кодом …»
- Если элемент найден, то добавить строку в таблицу значений, где: «счетчик» - найденный элемент, «ПоказанияДень» - «Day», «ПоказанияНочь» - «Night»
- Если обработка вызвана из документа «Потребленная Энергия» и число строк
в таблице значений больше 0 то записать содержимое таблицы значений в табличную часть документа и провести документ.
- Если в таблице значений есть строки и обработка не вызвана из документа «Потребленная Энергия», то создать документ «Потребленная Энергия» с датой равной текущей дате и затем провести документ.
Получение данных из платежной системы
Формат файла передачи данных - DBF;
Структура файла передачи данных:
Реквизиты обработки
Алгоритм обработки:
- Создать таблицу значений со структурой:
- Выбрать строки файла передачи данных
- Начать цикл по строкам файла передачи данных
- Прочитать строку файла передачи данных
- Получить из строки файла передачи данных код договора
- Найти по коду соответствующий элемент в справочнике «Договоры контрагентов», если элемент не найден, то выдать сообщение « Не найден договор с кодом …»
- Если элемент найден, то добавить строку в таблицу значений, где: «Договор» - найденный элемент, «Дата» - «Data_plat», «НомерПлатежа» - «Nomer_plat», «Сумма» - «Summa_plat»
- После получения последний строки файла передачи данных окончить цикл
- Для каждой строки таблицы значения создать документ «Платежное ордер поступление денежных средств». При создании документа сделать проверку наличия в системе документа с такой датой и таким номером входящего документа. Если документ присутствует в системе, то документ не создается.
- Правила заполнения реквизитов документа:
|
Реквизит |
Значение заполненя |
|
Вид операции |
|
|
СтрокаТаблицыЗначний.Дата |
|
|
Номер входящего документа |
СтрокаТаблицыЗначний.НомерПлатежа |
|
Дата входящего документа |
СтрокаТаблицыЗначний.Дата |
|
Договор контрагента |
СтрокаТаблицыЗначний.Договор |