Не так давно я выплеснул пакет эмоций после очередной встречи с разработчиком вэб-проекта (Серый аутсорсинг). В том посте я пообещал начать освещать темные углы аутсорсинга. Но как-то не срослось. И вот вчера, разбирая чтиво "отложенное на потом" наткнулся на такую вот статью 7 причин потребовать еще один документ. В целом статья правильная и ее цель заставить людей в процессе договорных отношений при разработке программного обеспечения нормализовать этот самый процесс. Но есть по ней одно замечание. На мой взгляд в статье произошла подмена понятий. Алексей описывает документ, именуемый Техническое задание (ТЗ), хотя по тексту статьи подразумевается два документа. Это Технические требования (ТТ) и собственно ТЗ.
Эти тезисы, которые раскрывает Алексей, больше относятся к ТТ:
- Вы хотите точно знать, какой результат вы получите
- Вы хотите знать, сколько на проект потребуется времени
- Вы хотите знать, сколько потребуется денег
Конечно же ТЗ содержит требования к разрабатываемому продукту, но оно также содержит описание реализации данных требований. Кроме того этап разработки ТЗ может быть включен в общий перечень этапов работ по договору в целом. Кроме того на момент заключения договора (на основании которого производятся выплаты за проделанный объем работ) ТЗ может не существовать.
Итак
ТЗ и ТТ - это два абсолютно разных документа. И разрабатывают их разные стороны договорных отношений. ТТ разрабатывает заказчик, а ТЗ разрабатывает исполнитель при содействии заказчика. "Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований' (заявки; тактико-технического задания и т. п.)." п. 1 Приложение 1 ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы".
ТЗ содержит следующие разделы:
1) общие сведения;
2) назначение и цели создания (развития) системы;
3) характеристика объектов автоматизации;
4) требования к системе;
5) состав и содержание работ по созданию системы;
6) порядок контроля и приемки системы;
7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8) требования к документированию;
9) источники разработки.
Начнем сначала
Попробуем смоделировать процесс разработки и внедрения новой информационной системы. Например сайта.
Вызывает большой босс к себе представителя служб ИТ (если фирма небольшая, то повезти может кому угодно) и говорит, что того постигло великое счастье и этот счастливчик теперь будет заниматься внедрением в конторе новой информационной системы.
И вот с чего же начать? Спросить у Гугля "кто на свете всех милее?" Кто нам сделает такой сайт, чтобы у босса эго разорвало? Разработчиков (или тех кто себя таковыми считает) на рынке предостаточно. Но при первом контакте сразу же задается вопрос "а чего ж тебе голубь надобно?".
И что, поняв суть вопроса сразу начинается процесс написания ТЗ? Ан нет. Фигушки. Не выйдет. Сначала необходимо самому понять что нужно строить. Вот тут и возникает замечательный документ Технические требования. Его можно назвать просто Требования. Он должен содержать общие описания будущей информационной системы так, как ее видит заказчик. Содержать описание ее функционала. Ее предназначения. Например:
- цель создания сайта - создание позитивного образа компании
- сайт должен быть двуязычным
- сайт состоит из двух частей: фронт-офис и бэк-офис, которые стоят на разном железе в разных зонах ватчгуарда
- администратор сайта сам может создавать разделы бесконечной глубины вложения
- сервер баз данных сайта = MS SQL 2005
- бэк-офис должен быть проинтегрирован со службой каталогов ActiveDirectory
- для авторизации внешних пользователей должен использовать OpenID
Да мало ли что там можно написать. После этого документ отдается на согласования во все подразделения, которые будут работать с этой системой. Продажники например могут потребовать возможность заполнения анкет. Или наличия калькулятора погашения кредита. Маркетологи могут (должны) потребовать модуль анализа статистики посещаемости и модуль проведения опросов.
Тоесть проект системы обрастает бизнес-требованиями.
После чего этот документ утверждается у руководства компании. И именно этот документ передается претендентам на рассмотрение. И именно по этому документу определяется стоимость и сроки проведения работ. Разработчики уже имеют опыт создания подобных систем (вряд ли вы затеяли что-то из ряда революционное) и кроме того они закладывают буфер. Как по срокам так и по стоимости.
Замечу, что после заключения договора, в процессе работ по разработке сайта ряд представителей подразделений начнут говорить, что многое не так и многое не учтено. Эти же монологи обязательно начнутся по прошествии времени, особенно если часть людей, которые были задействованы в процессе уже поменяли работу. И начнутся обвинения в халатном отношении к работе при разработке и внедрении системы. И опять таки, чтобы монологи не переросли в диалоги и служит этот манускрипт (ТТ).
Дальше, после выбора исполнителя с ним заключается договор, в котором на основании требований фиксируются работы, сроки их выполнения и стоимости. И одним из этапов работ может быть прописана разработка ТЗ (если оно не разрабатывалось ранее и естественно за деньги и с указанием сроков разработки). При этом указывается, что ТЗ является неотъемлемой частью договора. В этом случае данный документ (Техническое задание) набирает юридическую силу и тогда по нему и можно выяснять взаимоотношения. Иначе никак.
Почему ТЗ разрабатывает исполнитель? Да по тому, что заказчик в 98% случаев это не сможет сделать. Как сказано выше: ТЗ содержит состав и содержание работ по созданию системы. Если заказчик сам не занимается разработкой, он никогда не сможет описать все детали реализации проекта. Особенно в свете способов реализации, которыми владеет исполнитель.
Может ли исполнитель при написании ТЗ "кинуть" заказчика? Если у заказчика нет опыта - то запросто. Но этот вопрос решаемый. На рынке сейчас достаточно организаций, которые предоставят услуги по проверке ТЗ на корректность (вот и идея для создания он-лайнового сервиса). И в случае "кидка" вступают в силу части договора, в которых закреплены сроки и санкции...
В процессе разработки ТЗ исполнитель плотно "работает" с представителями заказчика. Кстати это именно тот этап, на который хорошо ложатся методы экстремального программирования со стороны исполнителя (дальше я их стараюсь пресекать).
Далее в подразделения передается ТЗ вместе с ТТ и эти службы должны проверить, что все что они указали в ТТ присутствует в ТЗ (на данном этапе в виду лояльности разработчика еще могут быть внесены небольшие "мы забыли..."). Все. После подписания ТЗ работы начинаются (и принимаются) строго по этому документу.
А что ТЗ дает разработчику? Фактически это инструкция к действию. А кроме того это гарантия, что процесс разработки закончится именно на заявленных в ТЗ пунктах. Иначе он не закончится никогда.
Умный исполнитель в процессе разработки продукта запустит в производство документ "планы развития информационной системы..." который по сути будет коммерческим предложением к дальнейшему сотрудничеству.
Схема конечно несколько утрированная, но абсолютно рабочая.
Вы скажете "какой геморой"! Согласен. Но "какой геморой" столкнуться с разработчиком, который начитался книжек по экстремальному программированию. Но об этом потом. А сейчас мне было бы очень интересно узнать ваше мнение о данном посте.