О техническом задании (ТЗ)…

…когда я слышу о техническом задании на оснащение (и разработку, адаптацию и т. п.) системой информационно-звукового обеспечения законодательного или административного органа, я внутренне улыбаюсь — еще одна система, устаревшая уже на момент выхода…

Первая проблема всех технических заданий на комплексные системы — предположение, что внешняя среда не меняется

Я не хочу доказать, что написание технического задания (далее — ТЗ) — зло и корень всех бед, нет, ни в коем случае. Все и всегда относительно, а в нашем случае — зависит от задачи.

Вторая проблема хорошо известна и отражена в древней мудрости: чтобы задать правильный вопрос, надо знать половину ответа. В ситуации, когда каждый новый объект Вы разрабатываете с использованием только что появившихся технологий (новые модули, новая версия собственного ПО, новая версия базы данных, и т. п.), — фактически Вы каждый раз многое делаете заново. Это значительно осложняет процесс оснащения (разработки), потому что Вы не знаете, как будете это решать (разрабатывать).

Третья проблема классическая — Заказчик не всегда точно знает, чего он хочет. И когда подходит срок сдачи объекта, Вы слышите, что вот здесь хорошо бы подправить, вот здесь изменить, а вот здесь добавить. Частично эту проблему решает моделирование конечного решения на иммитационном стенде, но, повторюсь, лишь частично.

Выпуск конкурентами (если они существуют не только в воображении Заказчика) нового изделия, появление нового брэнда, новой технологии, нового ПО, изменение предпочтений Заказчика — все это требует немедленной реакции, изменяет предметную область, описанную в ТЗ. Заказчик увидел какой-то объект (пусть даже Вашего оснащения) и хочет такую же «штуку». При этом Вы не знаете заранее, как будете реагировать и сколько времени потребует реализация той или иной Вашей реакции. Одним словом — хаос…

«Экстремальное» оснащение объектов.

А что у нас в последнее время не экстремально?

Ниже описаны простейшие методы, которые позволили нам постепенно уйти от классической каскадной модели цикла оснащения объекта. Каскадную модель вкратце можно описать так: сначала мы просим Заказчика сформулировать свои требования, затем разрабатываем проект системы, составляем техническое задание. Затем изготавливаем оборудование, тестируем его на стенде. Увы… Эта модель не годится для большинства проектов по оснащению законодательных и административных органов, да и…

Что же делать?

Ответ прост: принять окружающую действительность, принять изменчивый мир, принять хаос. Стать гибким и разрабатывать свою стратегию с учетом того, что нас окружает хаос. Это нормально. И убедиться при этом, что уже существуют инструменты, позволяющие успешно действовать в условиях хаоса. Например, инструменты экстремального оснащения. Все они создавались исходя из того, что окружающая среда гибко и динамично меняется, и не пытаются зафиксировать её, а наоборот — приспосабливают производственные и технологические процессы под подобную среду.

Итерации.

Итак, мы приняли концепцию изменчивого мира. Что это меняет? Сразу становится ясно, что писать подробнейшее техническое задание не имеет смысла — оно стремительно устаревает. Ограничимся описанием функций (см. примеры: «Базовые функции системы электронного подсчета голосов и регистрации» или «Базовые функции системы поддержки проведения мероприятий»), причем так, как их видит пользователь системы. Как правило Заказчик достаточно хорошо их представляет.

На основе такого описания команде наших разработчиков, дизайнеров, программистов становятся ясны их ближайшие шаги. Основные архитектурные и схемотехнические решения, общие рамки будущей системы, общее устройство. Но я подчеркиваю — ближайшие шаги. Достаточно одного-двух. Шаги должны быть небольшие (неделя, несколько дней). После каждого шага — пересмотр всех условий, учет всех изменений. В экстремальном оснащении оборудованием объектов (или экстремальном программировании) такие шаги называют итерациями. Итак, если мы на каком-то этапе работы пошли по неверному пути, мы очень быстро это поймем — одна-две итерации, и ошибка будет исправлена.

Общение с Заказчиком.

И все же нам нужно чем-то заменить отсутствие формального технического задания, — ведь мы должны сделать то, что требуется Заказчику. Выход — тесное общение с представителем заказчика и пользователями на всех этапах работ (не только в точках проверки, не только в начале и конце работ, а в течение всего времени работы над проектом).

Продолжение следует…

 
 

В. КОЗЛОВ


К началу страницы