Если пройтись по зарубежным сайтам с запросом «документ о требованиях к продукции», то можно найти креативные и убедительные статьи о том, что технические условия (ТЗ, ПРД) мертвы.
С этим приходится отчасти согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома заметок для клиентов, которые порой очень непрофессиональны.
Однако если речь идет о доработке базовой системы, то тут дело принимает совершенно иной оборот. Нам приходится сталкиваться как с модификациями, так и с заказной разработкой, поэтому техническое задание – это жесть, если повар нам не врет. В общем, сегодня мы говорим о тех классических технических задачах, которые пишутся для улучшения купленного и установленного программного обеспечения.
Короче, о наболевшем.
Аспекты взаимодействия
Прежде чем мы начнем разбирать процесс создания технического задания, поговорим о четырехугольнике, в котором оказываются подрядчик и заказчик при запуске проекта.
Требования - желаемое поведение системы, описанное потребителем или владельцем процесса, которое должно быть реализовано.
Как правило, требования формируются на основе опыта работы и понимания корректного поведения программы.
Это ключевая информация для разработчика (вендора), однако именно на этапе сбора требований возникает наибольшее количество коллизий, ошибок, ненужных запросов и т.п.
Ресурсы — люди, машины, инвентарь, среда разработки, время и деньги, которые необходимо использовать в процессе реализации требований.
Ресурсы требуют четкого планирования и оценки на этапе утверждения технического задания.
Грамотная расстановка приоритетов со стороны заказчика и распределение трудовых ресурсов со стороны поставщика позволяет избежать срыва сроков и минимизировать другие риски.
Возможности — короче, это то, что реально может сделать вендор (исполнитель).
Давайте посмотрим на наш пример РегионСофт CRM .
Клиент покупает систему и составляет техническое задание на доработку: необходимо создать интеграцию с сайтом и привязать события в CRM к номеру заказа интернет-магазина.
Это реалистичное требование, у нас есть ресурс и возможность это сделать.
Также необходимо разработать и подключить к CRM CMS — систему управления контентом сайта.
Теоретически мы можем это сделать, но у нас нет возможности сделать это дешево, а у клиента нет возможности заплатить нам столько, чтобы мы выделили человеческие и временные ресурсы на задачу.
В итоге заказчик отказывается от этого требования — и CMS ему особо не нужна, всё и так хорошо.
Но о «жадности» ТЗ позже.
Ограничения — совокупность препятствий, которые затрудняют или делают невозможным выполнение задач из технического задания: бюджет, технологический стек, проблемы с лицензированием, законодательные запреты, конфигурации оборудования и т. д. Таким образом, все четыре сущности тесно переплетаются между собой и определяют успех проекта в целом.
Давайте рассмотрим каждый элемент и попробуем выделить важные моменты, которые необходимо учитывать при работе над техническими характеристиками.
Сбор и анализ требований
Это очень важный внутрикорпоративный процесс, в ходе которого становится понятно, чего хотят от программы потенциальные пользователи (здесь и далее речь пойдет о CRM, но методы работают и с другими типами ПО).Если вы обратитесь к крупному вендору типа SAP или системному интегратору, то с большой долей вероятности вам предложат воспользоваться услугами бизнес-консультанта (он же персональный менеджер, он же аккаунт-менеджер, он же «теперь ваш представитель в нашем компания").
По сути, в большинстве случаев это обычный хорошо обученный продавец, у которого две задачи: увеличить стоимость проекта и не упустить вас с крючка.
Он здесь уже час и даже не прикоснулся к доске.
Он не настоящий системный аналитик Никто не знает вашу компанию лучше, чем вы и ваши сотрудники.
Это значит, что сбор и анализ требований — исключительно ваша задача, в которой вендор может помогать и направлять, но ни в коем случае не вмешиваться в процесс.
Спросите разработчика о таких реализациях, узнайте, на что обратить внимание, и приступайте.
Кстати, хорошим помощником может стать ваш сотрудник, хорошо разбирающийся в профильной теме, имеющий примерное представление об архитектуре ПО и знакомый с процессом разработки – он может выступать в роли аналитика и внутреннего эксперта, курирующего процесс разработки.
процесс создания технических спецификаций и общения с поставщиком.
Существует очень простая схема сбора требований.
- Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут использовать CRM. Расскажите о решении, которое вы намерены выбрать, предоставьте доступ к демо-версии.
- Члены рабочей группы должны донести информацию до сотрудников и в совершенно свободной форме запросить у них пожелания по новой программе.
Если кто-то из сотрудников никогда не сталкивался с таким программным обеспечением и не готов говорить о дальнейшем использовании, нужно попросить его описать его периодические задачи; это универсальный подход.
- Затем каждый отдел определяет, чего нет в CRM или чего он не соответствует, и агрегирует информацию.
- Рабочая группа анализирует собранные требования, проверяет и устраняет пересечения.
Например, часто отдел продаж и отдел маркетинга заказывают один и тот же отчет, но требования могут иметь разные названия полей и сущностей, хотя данные за ними одни и те же.
Соответственно, нам необходимо прийти к единой форме.
- Рабочая группа составляет список требований и устанавливает приоритеты.
На этом этапе можно привлечь продавца, так как он отвечает за ресурсы.
Например, вы можете попросить создать собственный отчет для RegionSoft CRM или заказать интеграцию с сайтом.
Это задачи с совершенно разными сроками выполнения; приоритет здесь очень важен.
Вы можете попросить форму у поставщика или создать ее самостоятельно — в любом случае есть несколько железных правил, соблюдение которых избавит вас и вашего поставщика CRM от головной боли.
Анатомия технической спецификации
Если говорить о процессе создания технического задания, то он состоит из нескольких этапов.Их последовательное прохождение приводит заказчика к желаемому улучшению.
Вот они.
- Выявление – выявление требований, поиск проблем, которые необходимо решить.
- Анализ – анализ требований, выявление ключевых потребностей, обобщение.
- Адаптация – оценка требований в разрезе возможностей CRM и существующих бизнес-процессов.
- Документация – формальное и подробное описание требований, утверждение технических условий.
- Общение с вендором (разработчиком) – итеративное взаимодействие с вендором по вопросам доработок в соответствии с составленным техническим заданием.
- Внедрение — это работа вендора по созданию необходимого функционала.
Лучше, если вендор будет постоянно на связи с заказчиком — так конечный продукт будет максимально соответствовать видению клиента.
- Тестирование – проверка функциональности сотрудниками вендора, внутренними экспертами клиента и конечными пользователями с целью установления соответствия модификации и техническим характеристикам, а также работоспособности системы с изменениями.
Бизнес-уровень — самый глобальный уровень, на котором решаются сложные и приоритетные задачи.
Этот уровень включает в себя интеграцию, усовершенствование и моделирование бизнес-процессов, разработку новых функциональных модулей.
Как правило, это ресурсоемкая разработка, требующая серьезных консультаций и тесного сотрудничества с заказчиком.
Например, одно время в РегионСофт CRM Такие заказные модификации включали складской учет, кассовый аппарат и производство.
Постепенно изменения вошли в релиз и в дальнейшем позволили создать новый продукт для оптовых, розничных магазинов и гипермаркетов - РегионСофт Ритейл .
Уровень пользователя или группы пользователей.
На этом уровне реализуются задачи по доработке существующего интерфейса.
Например, пользователь может захотеть, чтобы при наведении курсора на покупателя появлялось окно с номером и статусом последнего заказа или пользовательский отчет со специальной группировкой данных.
Доработки на этом уровне занимают меньше времени, но их может быть много — например, несколько требований со стороны отделов маркетинга, логистики и технической поддержки.
Уровень функциональности.
Зачастую его трудно отделить от предыдущего; Здесь работает формальный критерий — улучшение идет не на уровне отображения чего-то в интерфейсе, а на уровне доработки логики системы.
Сюда могут входить требования к различным видам сортировки, интеграции чата и возможностям телефонии.
Уровень обслуживания - по сути, требования этого уровня должны первыми включаться в новые сборки с исправлениями.
Это задачи, связанные со скоростью отклика системы, работой в условиях высокой нагрузки и безопасностью.
В идеале таких модификаций у вендора быть не должно — корпоративное ПО не должно тормозить, терять данные, сворачивать формы и распределять права доступа одного уровня.
Но если появляется требование, и оно не связано с личной паранойей заказчика или проблемами на аппаратной стороне, стоит обратить на него повышенное внимание.
Уровень технологии — последний в списке, но впереди остальных по важности и сложности.
Это могут быть требования клиента, связанные с платформой, операционной системой или устройствами.
Например, запрос на сборку для MacOS. Будет здорово, если такие требования постепенно перерастут в релизы, но обязательно иметь к ним исправления.
Именно по просьбам клиентов на этом уровне мы сделали сборку РегионСофт CRM для MacOS и добавили удаленный доступ с использованием технологии TRM в качестве временного решения редкого, но существующего запроса на мобильную версию.
Анатомия технической спецификации проста, по крайней мере, в скелетной форме.
Обязательные части технического задания помогают заказчику сосредоточиться на проблеме и правильно сформулировать задачу, а подрядчику понять, чего от него хотят. Кстати, о понимании.
Конечно, в начале поста мы немного солгали, отрицая бизнес-консультантов как класс.
Дело вот в чем: каждый вендор работает на рынке несколько лет (мы не говорим об однодневных CRM), а то и десятилетий, а значит, у них есть набор кейсов практически в каждой отрасли.
Соответственно, инженеры, программисты и продавцы знакомы со спецификой внедрения в каждом типе компаний.
Но опять же, важно сосредоточиться конкретно на своем бизнесе.
Для кого? В этом разделе необходимо описать, кто будет конечным пользователем улучшения, какие задачи планируется решать и с какой периодичностью.
Позволь мне привести пример.
Одна компания внедряла CRM и должна была работать с достаточно большим массивом данных (несколько десятков миллионов записей в месяц, несколько сотен тысяч записей в день).
Руководитель отдела продаж запросил отчет о выгрузке этих записей с частотой «ежедневно».
Естественно, такой отчет при одновременной работе сотен пользователей нагружал систему — были найдены решения по оптимизации процесса.
Уже в ходе работы выяснилось, что продавец перестраховался и отчет нужен только в конце месяца, и тогда его можно будет запускать по расписанию в ночное время.
Излишне говорить, что время и деньги были потрачены впустую.
За что? Обоснование необходимости улучшения и его места в бизнес-процессе.
Этот пункт больше необходим самому заказчику, но и вендору полезно знать, какие еще процессы будут затронуты.
Иногда это помогает найти альтернативное решение.
Что ему делать? Самый информативный блок – в нем описаны требования и ожидания от системы.
И тут случаются те самые перлы, чудеса и столкновения, которые впору отправить в башорг, и которые ну очень осложняют жизнь.
Причина только одна – пользователь не знает, чего он хочет, что нужно сделать.
Есть еще одна маленькая подпричина — пользователь не может сформулировать требования.
И здесь задача разработчика (рабочей группы, аналитика, если он есть) – помочь правильно сформулировать потребность, выбрать подходящее требование и вписать задачу в контекст работы системы.
В этом же блоке нужно упомянуть ожидаемый результат. Параметры спецификации — сроки, этапы реализации, ответственность всех сторон, необходимые контакты и т. д. По сути, это набор важных формальных вещей, которые и делают документ техническим заданием.
Техническое задание должно быть согласовано и подписано сторонами во избежание многочисленных изменений в ходе разработки (они все равно будут, но в меньшем объеме).
В идеале техническое задание составляется при активном участии вендора, а его результат имеет примерно следующую структуру:
- Описание требований каждого механизма и каждой функции.
- Описание реализации данного функционала
- Стоимость работ по каждому этапу отдельно
- Общая стоимость работ по данному техническому заданию
- Сроки выполнения работ с разбивкой по этапам и указанием приоритетности
- Описание условий установки и тестирования модификаций
- Оговорки относительно исчерпывающего характера технического задания и других условий
10 правил, написанных слезами разработчика
Техническое задание на доработку должно быть техническим заданием на доработку.
, а не 300-страничное описание CRM, которое нужно клиенту.
Прежде чем составлять требования, следует внимательно ознакомиться с интерфейсом системы, ее возможностями и документацией – скорее всего, большинство «хотелок» уже включено в базовую комплектацию.
Вторым шагом я бы рекомендовал обратить внимание на встроенные инструменты модификации (конструкторы отчетов, конфигураторы и т.п.
) — возможно, штатный программист сможет внести необходимые изменения (они есть у многих компаний).
Техническое задание не должно быть жадным.
Зачастую бизнес переоценивает свои возможности или хочет получить «все и сразу».
Такой подход не оправдан ни с финансовой, ни с деловой точки зрения.
Вендора, как правило, нет пару недель (в случае с «РегионСофт» — 15 лет), и обратиться к нему можно через некоторое время, когда вы действительно поймете, чего не хватает в CRM. Яркий пример избыточности буквально со вчерашнего дня: клиент купил ERP известной российской компании, думая, что раз бухгалтерия работает, то и ERP от этого вендора будет хорошей.
ERP оказалась не только не очень хорошей сама по себе, но и очень непригодной для бизнеса.
И здесь РегионСофт CRM Подходит для складского учета и производства.
Выход есть: забудьте про ERP, плачьте, интегрируйте бухгалтерию 1С с новой CRM и наслаждайтесь удобным внедрением.
Но жаль потраченных денег! А клиент требует интеграции CRM с ERP. Мы этого не сделали, но зачем такая трата, почему две относительно похожие системы?
Техническое задание должно быть реалистичным и достижимым.
- как по требованиям, так и по срокам.
Здесь важно прислушаться к мнению вендора, так как он точно знает, сколько времени будет потрачено на ту или иную задачу.
Поверьте, разработчику невыгодно тратить время и увеличивать сроки — ему выгодно завершить как можно больше проектов и сделать их хорошо, чтобы не понести удар по своей репутации.
Что касается реалистичности, то избежать запросов на апгрейд CRM до уровня системы управления коллайдерами просто: следует включить в требования то, что действительно необходимо в данный момент и в обозримом будущем.
Например, RegionSoft CRM — настольная программа; у нас нет браузерного клиента.
Просить нас создать веб-приложение для одной компании бессмысленно, это серьезная разработка, она находится в стадии реализации и не является возможной разработкой для одной компании.
Нет, конечно, все имеет свою цену, но опять же – в общем случае требование невозможно выполнить.
Это не следует путать с ситуацией, когда речь идет о заказной разработке и радикально меняется идея и логика приложения; по сути, спонсируется создание нового ПО «под себя».
Но это другая история.
Техническое задание должно быть подробно описано.
Необходимо указать все существенные детали будущего проекта: от частоты использования программы до пожеланий к интерфейсу.
Чем подробнее будут требования, тем проще и быстрее будет реализация и тестирование.
Особенно стоит обратить внимание на детали, если вы работаете в конкретной отрасли (медицина, страхование, банки) — подробное изложение нюансов взаимодействия бизнеса и программы позволит вендору понять задачу и быстро адаптировать систему под Ваша компания.
Обязательно обратите внимание на форматы чисел, названия полей, наличие или отсутствие выпадающих списков, поведение кнопок и подсказок, типы данных.
Если заказчик использует свои формулы, которые необходимо включить в логику работы CRM ( например, расчет дилерских бонусов ), эти формулы необходимо записывать с полным пояснением их обозначений и логики расчета.
Да, корпоративное программное обеспечение выглядит примерно так, и в нем много важных деталей.
Техническое задание должно быть однозначным и точным.
Расплывчатые формулировки, варианты реализации, неясные требования – все это путь в тупик.
Бывает, что клиент из добрых побуждений записывает в техническое задание несколько вариантов поведения системы, близких, но не равноценных.
В этом случае он уверен, что помогает, подсказывает программисту, но на самом деле благими намерениями выложена дорога в ад, разработчик должен понять, что именно нужно, и он сам выберет, как это сделать, исходя из от характеристик системы и стека используемых технологий.
В этом году вы снова сможете загадать одно желание.
Только, пожалуйста, не тратьте их на то, что даже я не могу выполнить, например, на четкие бизнес-требования!
Техническое задание должно быть написано человеческим языком.
И это важно, нет, ВАЖНО.
Выделю две ситуации, когда языковые проблемы приводят к задержкам реализации проекта.
- Клиент пытается продемонстрировать свою техническую грамотность и делает конструкции типа: «внедрить в тело календаря окно с подсказкой с возможностью реагировать на события вызова.
» вместо «в календаре должно всплывать окно».
в котором вы можете отметить задачу как выполненную».
Если вы или ваш внутренний эксперт не обладаете навыками технического письма, не гуглите — пишите обычными словами, мы их понимаем.
- Техническое описание полно грамматических ошибок.
Необходимо не только избавиться от расплывчатых описаний и метафор( из настоящего: «Чтобы компьютер не пищал так, будто умирает в конвульсиях» ), лишние слова, слова-паразиты.
Проверьте пунктуацию – часто ошибки в ней искажают смысл требования.
Проектное задание – это документ и словарный запас в нем должен быть соответствующим, а грамотность – близкой к 100%.
То, что кажется красивым и деловым, в глазах разработчика оказывается адским бардаком.
Если вы хотите вставить схему или картинку, нарисовать ее человеческими методами, не утруждайте себя, нам, разработчикам, это не поможет.
Техническое задание не должно быть книгой жалоб.
Вам нужно решить проблему, а не описать ее, обращая внимание на шрифты и забывая об описании требований.
Техническое задание должно содержать не только саму проблему, но и ее решение на уровне понимания — тогда разработчик будет решать ее на уровне кода.
Сравнивать «Отдел продаж плохо планирует, теряет цифры, уже год бьемся» И «необходимо создать отчет, который будет сохранять значения плановых и фактических продаж ежемесячно с разбивкой по группам товаров» .
Техническая спецификация должна быть способна заглянуть в будущее.
Ну, не совсем это, а люди, стоящие за этим.
Если известно, что в ближайшее время произойдут изменения в бизнес-процессах, это необходимо учитывать, чтобы не платить за модификации дважды.
Круг ведения не должен быть бюрократическим.
Если вы когда-либо составляли этот документ, то наверняка чувствовали, как сложно избежать соблазна скатиться в бюрократию, добавить вводные слова, строгие фразы и охарактеризовать каждый пункт как статью УК (желательно с наказанием каждому за нарушение).
).
Бюрократические формулировки маскируют неполное понимание целей создания технических условий.
Ответственность поставщика указана в договоре, там же прописан бюджет. Не следует переносить эти моменты в технические характеристики.
Техническое задание должно представлять собой техническое задание.
Звучит парадоксально, но зачастую вместо технических условий мы читаем письма, жалобы, договоры, только что написанные инструкции по CRM или протоколы совещаний.
Конечно, работать по такому документу невозможно.
Чтобы оставаться в курсе формы и содержания, используйте старый добрый трюк: просматривайте термин слово за словом.
Технические средства диктуют модификацию, технологию и направлены на решение проблемы путем изменения программного обеспечения.
Это то, о чем нам нужно говорить в контексте программного обеспечения.
Задание – это постановка вопроса, проблемы без советов, подсказок и предварительных оценок.
Просто констатация проблемы.
Заповеди закончились, теперь упрек
Помимо перечисленных правил, есть еще несколько вещей, о которых стоит поговорить.Речь идет о целях, планах и ожиданиях — обо всех тех элементах, которые делают проект успешным, а отношения между вендором и клиентом почти дружескими.
Техническое задание нужно писать быстро.
, даже если перед вами стоит задача по автоматизации процессов мобильного оператора или крупного гипермаркета.
Это связано с тем, что технологии развиваются с огромной скоростью и даже система, которую вы внедряете, может пережить мажорный релиз (а иногда и два) за полгода-год и получить новый функционал.
Возможно, вам придется пересмотреть необходимость внесения изменений и начать процесс заново.
Наконец он нашел время выполнить техническое задание.
Но, увы, разработчиков, которые могли бы это реализовать, не осталось.
Клиент не знает о стеке и технических ограничениях.
И он не должен знать — это задача вендора, именно он оценивает работу после составления технического задания.
Заказчик не должен углубляться в технологии и через каждую запятую спрашивать, сможет ли вендор сделать то или иное.
Составьте подробное техническое задание, и разработчик подберет подходящую архитектуру – зачастую даже лучшую, чем вы думаете.
Оцените свой бюджет и избежите неприятных сюрпризов — это чуть ли не совместная задача номер один.
Не стоит давить на продавца и требовать от него примерной оценки работы (ну хотя бы примерно, навскидку, на глазок, но как и у других, ну в проектах такого типа, но по опыту, ну в рамках погрешность).
Полная оценка бюджета возможна только после прочтения, анализа и окончательного утверждения технического задания.
Если ваш разработчик поступит иначе, готовьтесь к тому, что доработки обойдутся как минимум в два раза дороже.
Исходя из объективной необходимости изменений и расширений — Я выше писал, что разработчик не пропадает и готов в любой момент внести изменения и дополнения по вашим требованиям.
Поэтому не пытайтесь сразу создать CRM/ERP своей мечты, не требуйте от вендора кнопки «Все работает, пока я пью кофе» — поработайте в системе, выявите критические для вас замечания и начните собирать требования и чертить до технических характеристик.
О технических заданиях можно писать бесконечно; это настоящий генератор не только мемов и сказок, но и головной боли.
Можно говорить о приоритетах и правилах проектирования, о ГОСТе 1989 года, который делает технические спецификации негуманными, о стандартах IEEE, которые немного лучше, о прототипах и дополняющих их технических условиях.
Но в итоге хотелось бы ограничиться одним, самым главным правилом: техническое задание – это не норма закона, не ГОСТ и не догма, поэтому, если можно его улучшить, улучшите, если можете упростить.
это, упростите, если можете сделать это изящно и так, чтобы всем понравилось, сделайте это.
Уверен, после этого никто не будет тыкать носом в технические характеристики и говорить, что там этого не написано.
Или почти никто.
Весь декабрь мы мы даем скидки на RegionSoft CRM и все фирменное программное обеспечение.
С 1 по 15 декабря - 15% и крутые условия рассрочки и аренды.
-70% и -90% у нас нет, потому что мы держим цену на лицензии экономически обоснованной, а не берём её на ровном месте.
Ну, если вам нужно CRM-система (с модификацией или без), затем перейдите к наш сайт , там много про CRM, ее преимущества и другой корпоративный софт. И да, мы всегда ищем партнеров, готовых продавать CRM и другие продукты, модифицировать и продавать CRM, продавать программное обеспечение и обучать пользователей.Тэги: #Управление разработкой #Управление проектами #ERP-системы #CRM-системы #спецификации #техническое задание #crm-система #техническое задание на программирование #техническое задание на crmРазделение доходов справедливо и выгодно партнеру.
Мы вам покажем, расскажем, научим.
Напишите на адрес [email protected]. Слайды, слайды.
Комиксы взяты из http://www.modernanalyst.com/ и из Pinterest. Если есть лучший перевод, мы будем рады включить его в публикацию.
-
Объяснение Обучения Сетевой Поддержке
19 Oct, 24 -
Ати Радеон Hd 4870 X2
19 Oct, 24 -
Несколько Слов В Защиту Костной Проводимости
19 Oct, 24 -
Linux На Usb-Накопителе + Tft
19 Oct, 24 -
Настольные Ролевые Игры
19 Oct, 24 -
Еженедельный Подкаст №58
19 Oct, 24
