Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика из песочницы

Управление проектами*, Анализ и проектирование систем

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

Для начала определимся с тем, какие факторы влияют на разработку ТЗ. Прежде всего, это степень понимания заказчиком требований. Как уже говорилось выше, в момент начала работы над ТЗ вы можете слабо себе представлять, какую именно систему вы хотите создать. В качестве исходных данных у вас могут быть разрозненные, часто противоречащие друг другу запросы от подразделений, заинтересованных в создании новой системы. Хорошо, если вашей ИТ-службе удалось структурировать их, разрешить противоречия и, тем самым, подготовиться к общению с подрядчиком. Если же нет, то лучший вариант – это сначала разработать очень общее ТЗ, крупными мазками описывающее видение системы, перечислить необходимые модули (подсистемы), не углубляясь в подробности их функционирования, и далее совместно с исполнителем работать над детализацией требований к ним. Последующие версии ТЗ можно оформлять в виде дополнений к первоначальному ТЗ или в виде т.н. «частных технических заданий» (ЧТЗ) на модули решения. Это даст вам время лучше понять что же вы хотите получить в итоге, мобилизовать на работу над проектом подразделения компании, собрать необходимую информацию, освоить основные понятия, если тематика создаваемого решения для вас нова. Также исполнитель сможет лучше познакомиться с деятельностью вашей компании.
Немаловажным моментом является вероятность дрейфа требований. Компании меняются, подстраиваясь под внешние вызовы, причем, часто это происходит достаточно быстро. То, что разработано сегодня может отслужить свое и стать совершенно ненужным завтра в его первоначальном виде. Во избежании ненужных проблем в будущем это сразу надо проговорить с исполнителем и настраиваться на долгосрочное сотрудничество. Грамотный исполнитель в этих условиях может выбрать т.н. спиральную модель разработки ПО, в рамках которой ТЗ, фактически, разрабатывается на каждом новом витке спирали и описывает те изменения, которые должны произойти в следующей версии программного продукта. От написания громоздкого первоначального ТЗ в этом случае можно отказаться, ограничившись ТЗ на первую версию (итерацию).
Ожидаемая длительность проекта, фактически, является одним из факторов дрейфа требований. За долгий срок даже в достаточно неповоротливой компании может многое измениться, например, появиться новое руководство с новым видением. Если же, напротив, проект небольшой и быстрый, то оптимальный вариант – разработать, согласовать и реализовать одно небольшое и достаточно детальное ТЗ.
Значительное число участников проекта, создающих отдельные компоненты решения, требует большей детальности технических заданий, разрабатываемых ими, а также учета еще на этапе ТЗ спецификаций и особенностей реализации соседних модулей. Это поможет в дальнейшем минимизировать риски несостыковки модулей и, соответственно, избежать ненужных психологических и материальных затрат на переделку.
Сложность задачи также оказывает влияние на подход к написанию ТЗ. Увы, задача может быть слишком сложной не только для заказчика, но и для исполнителя, который, казалось бы, имеет опыт в создании решений данного класса. Сложность обычно заключается в том, что создаваемое решение не является типовым и никто из участников проекта не может заранее предсказать результат его внедрения и использования в бизнесе. В этом случае очень важно грамотно разбить проект на этапы (шаги), подразумевая то, что каждый следующий шаг будет корректироваться по результатам, достигнутым на предыдущих. Соответственно и техническое задание будет разрабатываться в начале каждого этапа, опираясь на опыт предыдущего.
Компании работают в реальной среде и часто им приходится иметь дело с новыми партнерами, с которыми ранее они не работали. Это же относится и к разработчикам ИТ-решений. Конечно, хорошо иметь исполнителя, который отлично знает все детали вашего бизнеса, понимает вас с полуслова и в котором вы уверены на все 100% (в этом случае от разработки ТЗ, вообще, можно отказаться), но в реальности это может оказаться совершенно неизвестная вам компания. В таком случае, конечно же, целесообразно начинать сотрудничество с небольших, по-возможности, проектов и с четких и детальных формулировок требований, указанных в ТЗ.
Степень детальности ТЗ и разнесенность во времени его разработки, конечно же, не являются единственными моментами, важными для заказчика. Перед началом разработки ТЗ очень рекомендую определиться с его структурой, фактически, составить страницы с его содержанием, перечнем пунктов и подпунктов до начала работ по ТЗ, а не в процессе или после. При этом и вы и исполнитель договоритесь о том какие вопросы должны быть рассмотрены на данном этапе. Вы будете хорошо понимать, что получите в итоге, а исполнитель будет понимать, что вы от него ждете. Не смотря на кажущуюся простоту, это делается не всегда, даже для крупных и сложных проектов. В итоге ТЗ может получиться совершенно непотребным для дальнейшей работы.
Как известно, существует множество методологий разработки программного обеспечения, отличающихся в числе прочего разной степенью формальности проектной документации. Тем не менее, ТЗ в явном или неявном виде присутствует в любой из них. При этом шаблоны этого документа могут существенно различаться для различных компаний и процессов разработки ПО. Будущий разработчик вашей системы может навязывать вам принятые у него шаблоны ТЗ, но в данном случае важно понимать, что, во-первых, ТЗ является важнейшим инструментом не только для исполнителя, но и для заказчика, который также имеет полное право определять его структуру. И, во-вторых, здравый смысл и основное назначение ТЗ, состоящее в формировании общего видения программного продукта заказчиком и исполнителем, не отменяет ни одна из методологий разработки.
В настоящее время в РФ действует ГОСТ 34.602-89 «Техническое задание на создание автоматизируемой системы», который, не смотря на 89-й год своего создания, неплохо отражает общую структуру ТЗ. Тем не менее, для многих случаев, он является недостаточно детальным и хорошо описывающим специфику разработки современных программных продуктов.
По своему опыту могу порекомендовать обратить внимание исполнителя на необходимость рассмотрения в ТЗ в числе прочих следующих вопросов:
Категории (роли) пользователей, работающих с системой – перечислить роли и кратко описать каким должностям из каких подразделений они соответствуют.
Функционал системы – составить иерархическую структуру, в которой на верхнем уровне перечислены крупные модули (подсистемы), далее детализируемые до более мелких функциональных блоков и даже отдельных функций.
Модель использования системы – сопоставить категории пользователей системы и используемые ими функциональные блоки, обозначенные выше.
Сценарии использования системы при выполнении основных бизнес-процессов – наложить видение решения на реальные процессы, описать на каких этапах и каким образом оно будет использоваться. Не пожалейте времени на то, чтобы совместно с исполнителем наглядно схематически разрисовать сценарии хотя бы по основным бизнес-процессам и согласовать их с заинтересованными лицами.
Прототипы пользовательского интерфейса – схематически изобразить, например, при помощи Microsoft Visio как будут выглядеть основные формы вашего будущего ПО.
Логическая модель данных – изобразить основные сущности предметной области и взаимосвязи между ними. Это позволит вам и исполнителю разговаривать на одном языке с использованием общей терминологии.
Источники данных и взаимодействие с другими системами – описать откуда будут загружаться первоначальные данные при внедрении системы и из каких внешних источников они будут поступать впоследствии.
К рассмотрению этих вопросов в ТЗ стоит подходить «без фанатизма» с учетом возможной неопределенности требований, описанной выше. Детальную их проработку можно оставить на более поздние этапы создания системы, но если вы хотя бы в общих чертах остановитесь на них при разработке ТЗ, то заставите исполнителя и себя лучше подумать над решением, которое пока еще существует только на бумаге и переделка которого пока еще не сопряжена с глобальными финансовыми и временными затратами.
В заключении хотелось бы отметить, что по моему опыту самое лучшее ТЗ – это ТЗ написанное самим заказчиком или при самом активном участии заказчика, т.к. никто лучше сотрудников вашей компании не знает ваших потребностей, деталей работы и далеко не всегда это удается выяснить на интервью. Конечно, для этого необходимо иметь в штате достаточно квалифицированных ИТ-специалистов или воспользоваться услугами ИТ-консультанта. Полученное ТЗ можно использовать в составе тендерной документации для того, чтобы дать большому количеству потенциальных подрядчиков четкое понимание требуемого результата и получить от них предложения.
Еще одно преимущество ТЗ разработанного собственными силами в том, что оно будет отражать исключительно ваши потребности, а не ограничения используемых исполнителем технологических платформ и имеющихся у него наработок для повторного использования. Конечно, исполнителю может потребоваться провести дополнительное обследование и разработать собственную проектную документацию, но все эти документы должны будут соответствовать требованиям в разработанном вами ТЗ. Если же какие-то из ваших требований окажутся нереализуемыми для конкретного исполнителя, то вы непременно об этом узнаете и сможете принять соответствующие решения.