Создание автоматизированной системы – процесс трудоемкий. Важно учесть все моменты. Это позволить избежать появления ошибок в процессе работы готовой системы после ее внедрения. Именно поэтому сначала нужно составить подробное техническое задание на создание.
Первым этапом разработки техзадания на внедрение информационной системы является сбор данных у заказчика. Все они должны быть подробно изложены в ТЗ. Именно этот документ становится основополагающим при итоговом приеме готового проекта.
Этапы создания
Разработка технического задания на внедрение информационной системы включает в себя 3 основных этапа:
- Постановка задач, сбор информации, определение критериев качества планируемой системы, факты необходимости проведения НИР (научно-исследовательской работы).
- Научно-исследовательская работа позволяет определить структуру, методы решения задач, целесообразность их применения. Основная задача НИР – определение целесообразности будущего использования информационной системы в конкретном случае.
- Разработка, утверждение техзадания. На этой стадии определяются основные требования к будущей ИС, этапы ее разработки, сроки выполнения, выбор языков программирования, согласование всех пунктов ТЗ и его утверждение.
Функции
ТЗ оформляется согласно ГОСТ 34.602-89. Правильно составленное техническое задание на разработку информационной системы характеризуется следующими функциями:
Этап проектирования и техническое задание (ТЗ) в проектах по автоматизации
- Организационная. В документе фиксируются все требования заказчика.
- Информационная. В ТЗ изложены все подробные данные для создания и внедрения будущей ИС.
- Коммуникационная. Обозначены взаимные договоренности заказчика и исполнителя.
- Юридическая. ТЗ, составленное в соответствии со всеми требованиями ГОСТ, имеет такую же юридическую силу, как и договор. В случае, если между заказчиком и исполнителем возникнут спорные моменты, документ может быть предоставлен в суде любой из сторон.
Оформление
Разработка технического задания на внедрение информационной системы включает в себя не только сбор и оформление информации касательно готового ПО. В нем также прописываются все этапы, начиная с оформления идеи заказчика и заканчивая нюансами ее дальнейшего обслуживания и модернизации.
Общие сведения
Прежде, чем приступить к изложению в ТЗ всех деталей будущей разработки, важно обозначить информацию о наименовании будущей системы, ее назначении и краткую характеристику. Кроме этого важно указать формат сдачи готовой работы, условия ее передачи-приема и другие важные организационные моменты.
К особо важным моментам следует отнести:
- цели разработки системы и ее практическое значение;
- структура ИС, ее основные функции;
- надежность и безопасность;
- виды обеспечения ИС, включая информационные технологии, которые могут потребоваться для корректной работы системы;
- характеристика объектов автоматизации;
- список сопровождающей документации и правила ее составления.
Разработка ИС
Создание автоматизированной системы включает 6 стадий разработки:
ТОП-9 советов как написать техническое задание? (ТЗ или техзадание за 9 шагов)
- составление ТЗ;
- составление проектной документации;
- создание эскиза;
- проектирование по ранее созданному эскизу (разработка системы и документации к ней);
- запуск ИС (передача готовой системы заказчику);
- сопровождение (модернизация внедренной ИС).
Моделирование бизнес-процессов и потоков данных в ИС
Под бизнес-процессом понимаются задачи и мероприятия, которые связаны между собой для осуществления услуг потребителям. Создание автоматизированной системы подразумевает обязательное наличие в ней всех заранее озвученных заказчиком бизнес-процессов.
Современные информационные технологии позволяют создать модель, которая будет полностью копировать будущую ИС. Моделирование бизнес-процессов осуществляется с помощью специальной методологии IDEF0. Выглядит модель, как группа логически связанных диаграмм, составленных в иерархическом порядке.
Выделяют 4 главных типа:
- Контекстная – диаграмма А-0. Для каждой модели создается только одна контекстная диаграмма. Она является вершиной всей структуры. Здесь указывается назначение ИС.
- Декомпозиция – разделение будущей системы на основные компоненты.
- Дерево узлов – дробление компонентов на более мелкие.
- Отдельная диаграмма FEO для экспозиции.
Моделирование потоков данных производится с помощью DFD. Эта методология показывает, как каждый из процессов преобразует входящие и исходящие данные потоков данных.
В отличие от IDEF0, DFD представляет не иерархическую взаимосвязь, а последовательную совокупность данных. Все смоделированные процессы отражают функции будущей системы. Все входящие и исходящие потоки обозначены стрелками, хранилища данных отображаются объектами в покое.
Системное проектирование ИС
Главные аспекты, учитываемые при проектировании архитектуры ИС:
- быстродействие;
- безопасность;
- надежность;
- масштабируемость.
Наиболее востребованные архитектуры:
- клиент-сервер;
- файл-сервер;
- многоуровневая архитектура.
Архитектура клиент-сервера обеспечивает доступ к общим данным и обрабатывает их. При этом обязательно учитывается согласованность и ценность данных. Это позволяет не нагружать сеть. Хранение и обработка данных проходит централизованно. За счет этого архитектура клиент-сервер считается наиболее надежной.
Архитектура файл-сервер предполагает только хранение данных. Дальнейшая обработка любой информации должна проводиться на клиентских машинах. Такая архитектура может излишне нагружать сеть, что может сказаться на производительности. Кроме этого, такую архитектуру нельзя назвать надежной.
Многоуровневая архитектура – наилучший вариант для ИС. Все бизнес-процессы здесь происходят на сервере приложений. Именно благодаря этому данный тип архитектуры считается более надежным и безопасным, менее затратным финансово и по ресурсам сети. Несмотря на это, многоуровневая архитектура не пользуется большим спросом.
Разработки ИС на таком типе архитектуры требует высоких показателей скорости канала и производительности серверов, где будет работать ИС. Кроме этого, администрирование такой системы требует более высоких навыков.
Структура ИС
Любая ИС включает основные функциональные подсистемы:
- информационную;
- программную;
- техническую;
- математическую;
- лингвистическую.
Каждая из перечисленных подсистем реализует отдельные цели всей системы. Например, информационная подсистема определяет виды и структуру документов, математическая запускает определенные вычислительные алгоритмы и т. д.
Техническое обеспечение ИС
Для обеспечения бесперебойной работы будущей ИС в техзадании важно определить, какие именно технические средства должны быть в наличии. Из физических техсредств это могут быть рабочие станции, серверы, принтеры, источники бесперебойного питания.
Кроме машин, аппаратуры и других физических средств важно прописать требования к серверу и рабочей станции, на которых будет работать ИС: информационные технологии, объем памяти, скорость передачи данных и т. д.
Все технические средства должны обеспечивать:
- круглосуточную работу всего комплекса оборудования и других техсредств;
- безупречное исполнение всех функций ИС, включая резервные источники;
- защиту от несанкционированного доступа;
- локальную сеть, в которой будут объединены все рабочие машины и серверы, связанные с ИС.
Физическое проектирование
Под физическим проектированием подразумевается формирование баз данных для конкретной системы управления. Требования к конкретным системам управления базами данных (СУБД) также прописываются в ТЗ.
Физическая модель проектируется на основании ранее созданной логической модели. Все данные описываются уже с учетом средств СУБД. Другими словами, физическая модель должна по всем параметрам соответствовать будущей реальной базе данных будущей ИС.
Порядок контроля и приема системы
Перед сдачей ИТ-проекта заказчику необходимо провести несколько контрольных операций, которые позволят испытать готовую систему. Проводятся испытания обычно путем введения данных большого диапазона. Это может быть как систематически повторяющаяся информация, так и данные разного характера и объема. Еще необходимо провести проверку на соответствие руководства к ИС с фактическими показателями.
Все программные изделия могут быть переданы на носителях в виде исходных кодов или же в виде готовых модулей. Процесс передачи готового проекта проходит в присутствии специальной комиссии, в которую входят как представители заказчика, так и исполнителя. Процесс передачи также включает в себя демонстрацию всех функций системы, которые были заранее смоделированы определенном образом. Вся необходимая документация также передается вместе с ПО.
По итогам передачи системы обязательно составляется и подписывается обеими сторонами акт приема-передачи.
Техническое задание на разработку информационной системы – главный документ, который определяет четкие требования будущей ИС, порядок ее создания и прочие важные условия. Именно на основании ТЗ есть возможность проверить весь функционал системы, ее соответствие требованиям заказчика. Документ может быть представлен в качестве доказательной базы в случае возникновения споров между заказчиком и исполнителем, в том числе в суде.
Кроме требований к функционалу системы в ТЗ прописываются условия эксплуатации, безопасности, надежности ИС и поэтапный порядок ее разработки.
Источник: dynamicsun.ru
Техническое задание 1С
Что такое техническое задание на доработки 1С? С точки зрения ГОСТов*, в которых регламентирована деятельность по разработке программного обеспечения и автоматизированных систем (АС) – это основной документ, определяющий требования и порядок развития или модернизации (далее – создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.
- *ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
- ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
Приглашаем на
бесплатный вебинар!
06 июня в 11:00 мск
К сожалению, в ГОСТе не дано более четкого определения, поэтому, учитывая интересы взаимодействующих сторон – интегратора и заказчика, правильнее будет дать более точное определение. Техническое задание, являясь основным документом на проектирование автоматизированной системы, устанавливает основные характеристики и назначение АС, определяет необходимые этапы создания документации и ее состав, а также является частичным обоснованием стоимости внедрения 1С.
Зачем нужно техническое задание
Основные проблемы в проекте возникают из-за некорректно сформулированных или незакрепленных требований проекта. Основные требования к результату должны быть описаны в техническом задании, которое формируется техническими специалистами исполнителя, а не заказчиком.
Таким образом, напрашиваются дополнения к уже сформулированному выше определению. Хочется добавить, что этот документ, содержащий требования, должен быть сформулирован на понятном для заказчика языке. Привязок к особенностям технической реализации АС не делается. Т.е. на этапе ТЗ в принципе неважно, на какой платформе будут реализовываться эти требования. Выяснением и формулированием требований, а также оформлением технического задания должен заниматься бизнес-аналитик, и никак не программист (хотя при совмещении ролей такой вариант возможен), потому что именно аналитик говорит с заказчиком на языке его бизнеса.
Корректное техническое задание, написанное и согласованное между всеми заинтересованными и ответственными лицами, является залогом успешной реализации любого проекта.
Бесплатная
консультация
эксперта
Анна Викулина
Руководитель Центра
сопровождения 1С
Спасибо за Ваше обращение!
Специалист 1С свяжется с вами в течение 15 минут.
Кто разрабатывает техническое задание
Заказчик, как правило, не является специалистом в области информационных технологий, поэтому основные требования к результату должны быть описаны в техническом задании, которое формируется техническими специалистами исполнителя, а не заказчиком.
Типовые ошибки при разработке технического задания
Документ базируется на ГОСТ 34.602-89, дающий формализованную структуру, но не имеющий четких требований к изложению разделов и пунктов. Эта особенность стандарта — его сила и его слабость. Свобода изложения может привести к тому, что требования разделов (особенно функциональные):
- Излагаются не системно, без привязки к какой-либо структуре (модули системы, бизнес-процессы);
- Дублируются;
- Относятся к различным уровням детализации.
Допущение ошибок при составлении технического задания приводит к увеличению стоимости и продолжительности проекта. Основная задача технического задания – оформить требования заказчика в понятном и возможном к реализации формате.
Реализация требований заказчика невозможна без правильно составленного технического задания. Даже при наличии высокой компетенции сотрудников, возможно возникновение ошибок. Чаще всего встречаются следующие:
- Излишняя детализация;
- Требования, противоречащие друг другу;
- Неточные формулировки.
Многие заказчики грешат требованием к излишне детализированному описанию процесса работы системы, однако основное внимание следует сфокусировать на результате, а не на том, как должна выглядеть система.
Требования не должны быть противоречивыми. Также желательно избегать расплывчатых, неконкретных формулировок. При разработке ТЗ определяются базовые требования и назначение проекта, его функционал.
Как избежать ошибок при составлении ТЗ
Главное правило: больше конкретики. При составлении требований необходимо использовать ссылки на ГОСТ, нормативные документы заказчика, что позволит избежать двойного толкования или недопонимания между заказчиком и исполнителем.
При разработке ТЗ необходимо применять сухой, научный стиль изложения, избегать применения сравнений. Использовать следует терминологию отрасли, сферы, в которой ведется разработка проекта.
Руководствоваться нужно следующими правилами:
- Формирование ТЗ – это совместная работа исполнителя и заказчика;
- Риски исполнителя должны быть минимизированы и не должны превышать аналогичные для заказчика (иначе это приведет к увеличению стоимости проекта);
- Требования формируются объективными, использование субъективного виденья заказчика не рекомендуется;
- Не допускается использование терминов, принятых в широком деловом общении, но противоречащих принятым в отрасли и стандарте;
- Основное внимание уделяется описанию результатов, требуемых заказчиком. Например, заказчику необходимо получать отчет о движении товара в соответствующих аналитических разрезах, тогда в ТЗ должны быть подробно описаны параметры отчета (строки, аналитика, период, за который составляется отчет) и источники данных для его формирования. Самое главное здесь – не допустить расширенного толкования технического задания, иначе, если вы не указали период или источник данных, конечный результат может сильно отличаться от требований заказчика, а доработка потребует дополнительных средств и времени.
Разработка, например, «правильного» ТЗ программисту 1С, подразумевает полное погружение в тему, знание всех ее аспектов и тонкостей. ТЗ должно давать ответ не только на вопрос «что должен сделать программист», но в первую очередь – «какие задачи должна решать система 1С:Предприятие после выполнения работ». Требования должны быть сформулированы подробно, но без лишней информации. Это уменьшит вероятность появления неточностей и ошибок. Именно поэтому привести универсальный пример технического задания 1С не представляется возможным – каждый случай ТЗ на разработку 1С уникален.
Источник: wiseadvice-it.ru
ТЗ на разработку IT-продукта: почему это важно и как правильно подойти к составлению технического задания
Вопрос разработки или не разработки технического задания порой становится точкой, в которой разгораются противоречия между заказчиком и исполнителем. Погружаясь в пучину непонимания друг друга, можно не только затормозить разработку проекта, ухудшить результат работы, но и вообще не найти общего языка друг с другом и разойтись, так ничего и не начав.
90 просмотров
Нередко предложение разработать сперва ТЗ воспринимается в штыки, и мы прекрасно понимаем нежелание клиента тратить дополнительные время и ресурсы на «ненужную» работу. Ну, например:
- Откладывается старт проекта, а сроки и без того горят. И на этом фоне потратить несколько недель, а то и месяц, на сбор, уточнение и фиксацию требований кажется ненужным расточительством. Да и зачем, ведь клиент всегда на связи, и можно просто написать / позвонить и уточнить!
- Не хочется разводить лишнюю бюрократию – в общем-то продолжение предыдущего аргумента. «Будут вопросы – пишите мне, я отвечу».
- Клиенту проект и так ясен и понятен полностью, поэтому расписывать что-то нет нужды. А если что-то непонятно – снова, всегда можно поговорить и разрешить возникшие вопросы.
- Итого: зачем же нам этот «ненужный» документ, если мы и так можем напрямую друг с другом обо всём договориться? Особенно если за него ещё и просят заплатить!
Даже я, пока пишу этот текст, в какой-то мере испытываю солидарность с заказчиком, ведь аргументы серьезные. Тогда почему же все-таки ТЗ нужно? Или, вернее, когда оно действительно нужно, а когда аргументация «против» более чем справедлива? Давайте попробуем разобраться.
Назначение технического задания
Чтобы понять, когда нам нужно ТЗ, давайте выясним, какие боли оно должно закрыть. Ведь если оно не решает никаких конкретных проблем, тогда и делать его действительно нет никакого смысла. Исходя из опыта нашей команды, можем сформировать вот такой список:
1. Детализация абстрактных идей. Часто, даже если в целом задача действительно понятна и поставлена довольно точно, в постановке могут найтись некоторые неопределённости. Более того, конкретные и понятные задачи могут оказаться расплывчатыми из-за разных способов реализации.
Возьмём пример: нужно разработать карточку товара в интернет-магазине. Вроде бы все мы видели, как выглядит интернет-магазин, и вопросов здесь возникать не должно. Но есть такие мелочи, как:
- Как должен выглядеть предпросмотр товара, должна ли картинка увеличиваться при клике, как должен выглядеть слайдер.
- Можно ли в блок показа картинки заливать видео? Должно ли это видео храниться на сервере с сайтом, или подойдёт встроенный плеер из YouTube?
- Что будет в блоке описания: просто свободный текст, или таблица с характеристиками? Должны ли характеристики браться из специальных полей карточки товара или же контент-менеджер должен просто сам вводить произвольный текст?
Вообще список уточняющих вопросов можно придумывать бесконечно, и всё равно в итоге что-то забудем. Но как минимум ключевые пункты нужно уточнить и зафиксировать.
Или другой вариант: задача проста и понятна, но имеет несколько способов реализации. Например, разработать модуль обратной связи: здесь можно действительно разработать какую-то систему работы с обращениями на стороне сайта, сделать личный кабинет менеджера, настроить рассылку уведомлений о новых сообщениях и т.п. А можно просто поставить какой-нибудь готовый модуль, типа JivoSite, и по стоимости и трудоёмкости разработки эти две задачи радикально отличаются!
2. Более обоснованный выбор технического стека на проекте. Экстраполировать предыдущий пример можно на гораздо более сложные задачи, чем форма обратной связи. В целом может оказаться, что часть функционала, который требуется клиенту, уже реализован каким-то сервисом или библиотекой, и здесь можно сэкономить на разработке с нуля. Либо же наоборот, появится понимание, что требуемый бизнес-процесс в готовых решениях работает совсем не так, как нужно клиенту, и придётся писать всё самим.
Чтобы провести такой анализ, нужно обладать необходимыми данными, детально понимать задачу клиента. К сожалению, на нашей практике были случаи, когда мы ошибались в прогнозах, изначально вместе с клиентом рассчитывая, что функционал в готовом виде уже реализован в стороннем модуле, «остаётся только немного допилить». Когда же дело дошло до реализации, выяснялось, что требуемое поведение реализовать сложно/дорого или даже практически невозможно с использованием предполагаемой технологии. Итог печален: сверхурочная работа, непопадание в сроки, повышенные затраты. Для обеих сторон лучше постараться избежать таких ситуаций «на берегу».
3. Лучшее понимание проекта и для клиента и для исполнителя. В ходе детализации требований не только разработчик, но клиент сам может лучше понять, как его проект должен работать, какой функционал первостепенный, а чем можно пренебречь.
Беда тут в том, что все проекты ограничены бюджетом и сроками. И часто в ходе уточнения требований оказывается, что реализовать полностью всё желаемое – либо долго, либо дорого, либо всё сразу. Конечно, опытная команда разработки может найти способы ускорить процесс, распараллелив разработку нескольких модулей, но и это не всегда возможно.
В итоге приходится становиться перед выбором, какой функционал делать в первую очередь, т.к. это основная идея всего проекта, а какой можно доделать дальнейшими итерациями или вовсе опустить.
4. Более точные прогнозы по бюджетам и срокам. Это достижимо, если ТЗ закрывает вышеописанные пункты. Как и любая хорошая аналитика, хорошо разработанное ТЗ значительно снижает возможные неопределённости в ходе реализации проекта.
5. ТЗ – как основа, на которой строятся договорные отношения по разработке проекта. Детальное описание того, как проект должен работать – это фактически фиксация обязанностей исполнителя разработать именно описанную систему, а не какую-либо другую. Наличие такого документа – хороший плюс как для исполнителя, так и заказчика, т.к. позволяет обеим сторонам предохранить себя от необоснованных требований или неисполнения обязательств.
Горький опыт
Очевидно, ТЗ, решающее указанные задачи, уже не может быть просто формальной бумажкой и не может быть выполнено «абы как». Более того, наибольший эффект от него можно получить при участии в разработке ТЗ той команды, которая в дальнейшем будет разрабатывать и сам продукт.
К сожалению, мы порой сталкиваемся с ситуациями, когда клиенту ТЗ написал уже какой-то «подрядчик по написанию ТЗ», который в целом и не собирался в дальнейшем по нему что-то делать. В таких замечательных документах мы встречаем очень много воды, крайне внимательно и дотошно прописанные разделы «термины и определения» и скудное, бедное описание самих бизнес-процессов, которые продукт должен реализовывать. Вишенкой на таком торте порой встречаем прописанные «технические требования» к проекту в виде случайного списка софта, на котором всё должно работать. А изюминка внутри этой вишенки – то, что версии софта либо устаревшие, либо не соответствуют тому, что на этом софте можно сделать и что реально нужно сделать для проекта.
Здесь можно было бы посмеяться, но на самом деле от такой ситуации становится больно, потому что, во-первых, клиент уже заплатил за проделанную работу, и порой немалые деньги. Как следствие, очень тяжело смириться с мыслью, что пользы от такого ТЗ нет, и нужно всё проделывать заново. А для исполнителя подписываться под таким ТЗ – довольно существенный риск, и порой приходится отказываться от вполне интересного и желанного проекта. Кроме того, такие ситуации в глазах клиента в целом дискредитируют команды, предлагающие начать с разработки ТЗ, автоматически вызывая к ним подозрение.
На что сделать акцент в ТЗ в зависимости от типа проекта
Тем не менее, не все проекты действительно требуют скурпулёзно составленного ТЗ и крайне глубокой аналитики. Мы в DigitalWand стараемся соблюсти в этом баланс и не делать больше, чем необходимо для успешности проекта.
Рассмотрим на примерах сайтов, от простого к сложному.
- Простые лендинги. В данном случае важно иметь прототип для разработки дизайна, понимать, нужен ли адаптив для мобильных устройств, а также какое-то описание требуемых «спецэффектов» на странице, если они есть. В остальном какая-то детальная документация по проекту не требуется, т.к. как правило визуальным рядом весь проект и заканчивается.
- Информационный портал, блог. Здесь тоже всё, как правило, довольно просто, и, имея визуальный дизайн или прототипы страниц сайта, в целом, можно понять, что и как должно быть сделано.
- Социальная сеть. Да, и такие проекты сегодня пишут! По сути, это тот же информационный портал, но есть более детальное разделение ролей и интерфейс публикации не только для редакторов, но и для других пользователей системы. Здесь уже требуется формализовать требования, т.к. у разных категорий пользователей есть разный «пользовательский путь», разные права доступа к функциям системы, и это всё необходимо зафиксировать как минимум чтобы просто не запутаться самим.
- Интернет-магазин. Довольно шаблонная задача на сегодняшний день, и если есть планы использовать для него какое-то готовое решение практически без модификаций, например магазин от Битрикса, тогда можно действительно обойтись без ТЗ. В остальных же случаях стоит проанализировать и прописать те моменты, которые отличают новый магазин от всех прочих – в плане интерфейса, бизнес-логики, структуры каталога и процесса покупки товара. К примеру, магазины, ориентированные на бизнес, могут не предоставлять вообще способов оплаты на сайте, но при этом в конце покупки должен генерироваться PDF файл счёта на оплату. Кроме того, для такого рода проектов обязательно стоит уделить внимание обмену данными с внешними системами, наверняка такие будут, как минимум с учётной программой типа 1С.
- Маркетплейс. Как социальная сеть отличается от простого блога возможностью разным категориям пользователя публиковать контент, так же и маркетплейс отличается от простого интернет-магазина возможностью разным продавцам продавать свой товар и управлять каталогом, а платформе получать комиссию с каждой сделки. Здесь техническое задание – вещь обязательная, т.к. для разных категорий пользователей будут разные бизнес-процессы, а также, скорее всего, понадобится биллинг и интеграции с банками.
- Автоматизация процессов организации: ERP, CRM системы. В проектах такого рода аналитика в целом – один из важнейших этапов работы, и, порой, наиболее трудоёмкая её часть. Совсем без ТЗ в этой сфере можно делать только какие-то мелкие «наколеночные» решения, чтобы малой кровью протестировать гипотезу.
Классификация, конечно, довольно грубая, но надо же как-то упорядочивать информацию. Наша команда имела опыт разработки всех этих типов проектов, но, что более важно, этот опыт не всегда был только успешным. Анализируя наши ошибки и сложности, с которыми мы сталкивались, мы часто замечали, что в проблемных проектах предварительная аналитика была на недостаточном уровне, что вело к изменению планов «на лету», внезапные поиски решения там, где всё раньше казалось понятным, реализацию не предусмотренного функционала… как снежный ком это накапливалось и приводило к выходу за рамки бюджета и сроков.
Цены и сроки на разработку ТЗ
Сложно писать о конкретных ценах в постоянно меняющемся рынке. Такая информация может стать не актуальной на следующий день после публикации. Поэтому постараюсь сориентировать через трудозатраты.
В самом простом случае, когда не требовалось полномасштабное описание проекта, а нужна была лишь фиксация основных моментов, мы поступали просто: делали небольшой документ на пару страниц, где тезисно или со скриншотами описывали, что необходимо, согласовывали с клиентом. Под этим документом и подписывались. Конечно, это не идеальный вариант, но точно лучше, чем совсем ничего. По трудозатратам это не сильно накладно: обычно достаточно менеджеру проекта потратить день-два на общение с клиентом и командой и фиксацию требований. Такая схема подходит для коротких проектов, продолжительностью до месяца, когда задача в основном простая и понятная для всех участников, и главные риски здесь — посыпаться на неточностях в мелочах.
Если же проект крупнее, то и работы больше. Например, для составления ТЗ на разработку интернет-магазина общая команда как со стороны клиента, так и со стороны разработчика, может выглядеть примерно так:
- Менеджер продукта со стороны Клиента.
- Менеджер проекта со стороны Исполнителя.
- Ведущий разработчик.
- Дизайнер, UI/UX.
- SEO-специалист.
- Специалисты со стороны внешних систем (например, 1С).
- Возможно участие дополнительных лиц, участвующих в согласовании или формировании списка бизнес-требований.
Даже просто организовать эффективное взаимодействие такой команды — уже не тривиальная задача, особенно учитывая то, что её участники могут работать в разных компаниях.
В таком случае разработка ТЗ может занять 1–2 месяца, в зависимости от эффективности взаимодействия и детальности проработки требований.
Впрочем, даже если в разработке участвуют всего несколько человек из внутренней команды разработчика, этот процесс может занять много времени. Например, для одного из наших проектов в рамках разработки ТЗ потребовалось не только спроектировать и описать архитектуру, но предварительно проверить несколько гипотез, отбросить неверные архитектурные решения, разработать детальные прототипы пользовательского интерфейса. И тщательно вычитать и причесать итоговый документ, т.к. он нужен был клиенту для регистрации продукта в реестре российского ПО. Над задачей работало всего 3 человека с нашей стороны: менеджер, ведущий разработчик, дизайнер. А на реализацию ушло 2 с лишним месяца.
В общем, сроки и стоимость разработки технического задания достаточно индивидуальны в зависимости от проекта и требуемого результата.
Заключение
Чтобы результат был качественным, нужно понимать: ТЗ — это не просто N страниц какого-то сложного текста, который нужен только для того, чтобы прикреплять его к договору. Техническое задание — это результат аналитической работы, проведённой специалистами из разных областей, задействованных в разработке. При этом важен не только итоговый документ, но и сам факт того, что аналитическая работа клиентом и командой разработки была проведена, и появилось более четкое понимание продукта, используемых технологий, приоритетов, сроков, подходов к разработке. Всё-таки даже в IT мы в первую очередь работаем с людьми, и человеческий фактор нельзя не учитывать.
Анализируя наши ошибки и сложности, мы часто замечали, что в проблемных проектах «страдала» предварительная аналитика. По итогу, мы выработали сбалансированный подход к разработке технического задания. Мы стараемся и сэкономить бюджет клиента и не застревать в «крючкотворстве».
Но многое зависит и от клиента: от его готовности предоставить необходимую информацию, обсудить бизнес-логику, подумать над бизнес-приоритетами и т.п. Здесь, без плотного взаимодействия заказчика и исполнителя – никуда. В общем, как всегда, залог успеха – в тесном сотрудничестве на благо общей цели. Ведь мы, как исполнитель, заинтересованы в качественной реализации крутых проектов не меньше, чем наши заказчики. Для нашей команды это не только заработок, но и действительно любимая работа.
Источник: vc.ru