Системный подход в создании ТЗ

Эта статья предназначена для людей, которые столкнулись с необходимостью написать техническое задание (ТЗ), но ранее этим не занимались. Метод, описанный ниже прост в понимании и в применении. Уверен, что существуют более надежные методологии и подходы в написании ТЗ. Тем не менее, кому-то может быть полезна и эта информация.

Я не являюсь опытным проектным менеджером и в этой области у меня знания минимальные. Делюсь лишь тем, как мне удалось выйти из ситуации, когда мне надо было писать ТЗ, а я этого делать не умел.

Много лет назад я устроился в веб-студию менеджером продаж. Оказалось, что с функционалом сейлза я получал в дополнение функционал руководителя проектов. Я отвечал за коммуникацию с заказчиками и исполнителями, которые напрямую друг с другом не взаимодействовали. Неудивительно, учитывая насколько неструктурированным может быть запрос заказчика и насколько структурированной должна быть задача, чтобы разработчики за нее взялись. Мне было необходимо выслушать заказчика и понять, что он хочет. А затем эту информацию в более упорядоченном виде передать разработчикам.

Результатом такой работы является техническое задание (ТЗ) – документ, который содержит описание желаемого продукта. Это описание должно быть понятно как заказчику, так и техническим специалистам.

Не имея никакого опыта в написании ТЗ, я воспользовался имеющимися знаниями, полученными в университете при изучении психологии, а именно системным подходом.

Системный подход – это способ познания в основе которого лежит рассмотрение объекта как системы.

Если говорить проще, системный подход – это такой взгляд на мир, который повсюду видит только системы и их части. Все – системы. Я – система. Вы – система. Яичница с утра – система. Даже мысли ваши – тоже система.

Так как все называется одним словом – то и имеет много общего. Все системы могут быть описаны на следующих уровнях:

1. Элементный уровень (он же содержательный) – это то, из каких частей состоит система.

2. Структурный уровень (он же интегральный) – это то, как элементы системы связаны друг с другом.

3. Функциональный уровень (он же целевой) – это то, что элементы системы делают.

4. Динамический уровень (он же эволюционный) – это то, как изменяется система и ее элементы вследствие взаимодействия друг с другом.

Возьмем в качестве примера что-нибудь простое, бутылку воды, и опишем с помощью системного подхода.

Элементный уровень. Бутылка воды состоит из 1) цельного корпуса бутылки 2) этикетки 3) воды 3) винтовой крышки и 4) контрольного кольца.

Структурный уровень. Вода находится внутри бутылки. Этикетка наклеена на середину корпуса бутылки. Крышка накручивается с помощью резьбы сверху бутылки. Контрольное кольцо находится внизу крышки.

Функциональный уровень. Корпус бутылки предназначен для удержания воды внутри. Этикетка — для нанесения на нее информации о содержимом бутылки. Винтовая крышка — для многократного открывания и закрывания бутылки. Контрольное кольцо — для информирования пользователя о первом открывании. Оно является частью крышки, но при первом открывании отделяется от неё. Вода используется для утоления жажды.

Динамический уровень это уже все, что будет происходить с бутылкой, водой, крышкой, этикеткой и кольцом в процессе использования. А происходить может разное. К примеру, вода может проливаться из бутылки, либо крышка может не открываться. Либо кольцо может не оторваться и откручиваться вместе с крышкой. По сути, это уже уровень реальности.

Описание бутылки было сделано при помощи 150 слов. Более сложные объекты требуют большего количества слов.

Всякое описание объекта – это создание его модели, то есть моделирование. Описание словами – это вербальное моделирование. Рисунок объекта – это графическое моделирование. Рисунок объекта в трехмерном пространстве – это 3D- моделирование. Описание объекта с помощью математических формул – это математическое моделирование.

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

Теперь можно потренироваться и написать ТЗ какого-нибудь простого приложения. К примеру, фонарика на смартфоне. Попробуйте сделать это сами – потом сравним результаты.

Элементный уровень. Фонарик на смартфоне состоит из следующих элементов: 1) иконка фонарика 2) светодиод.

Структурный уровень. Иконка фонарика располагается на экране приложений смартфона. Светодиод располагается на задней панели смартфона.

Функциональный уровень. Когда пользователь нажимает на иконку фонарика, она меняет свое изображение схематичного фонарика с перечеркнутого на неперечеркнутое. Одновременно с этим, светодиод на задней панели смартфона загорается постоянным светом.

Когда пользователь повторно нажимает на иконку фонарика, она меняет свое изображение на перечеркнутое. В этот момент светодиод перестает излучать свет.

Динамический уровень. В ТЗ динамический уровень как таковой отсутствует. Потому что, это уже и есть реализованное приложение. И в реальности, оно может начать себя вести иначе. К примеру, может оказаться, что светодиод загорается произвольно без нажатия на иконку. Либо, иконка не меняет своего изображения. В этом случае надо разбираться, что пошло не так.

Все уровни системы могут быть описаны как угодно, чтобы это было удобно разработчикам. К примеру, можно использовать условные знаки. Иконка перечеркнутого фонарика -> клик -> светодиод загорается. Иконка неперечеркнутого фонарика + клик = светодиод гаснет.

При создании приложения не всегда сразу известны все элементы системы. В этом случае надо двигаться от той информации, что имеется. Вот как будет выглядеть алгоритм написания ТЗ с помощью системного подхода:

1) Опишите, нарисуйте в общих чертах каким будет ваше приложение, из каких блоков оно будет состоять.

2) Опишите, нарисуйте как эти блоки будут взаимодействовать друг с другом и что будут делать.

3) Опишите подробнее какие именно части блоков и какие действия совершают.

4) Теперь идите по каждому уровню системного подхода, используя полученную информацию. Опишите элементы приложения. Опишите блоки, в которые входят эти элементы. Опишите действия, которые делают все элементы.

Готово. Этот документ можно отдавать разработчику для ознакомления. Понадобится время, чтобы у вас сформировался общий словарь, придется вносить ряд исправлений, но по итогу разработчик будет благодарен вам за простой понятный документ, который избавляет его от необходимости лишний раз с вами общаться.

Какие еще преимущества есть у системного подхода в написании ТЗ?

• Системный подход уменьшает количество необходимой мыслительной энергии, т.к. дает простую понятную схему описания.

• Системный подход позволяет уменьшить количество ошибок при запуске приложения за счет более тщательного его продумывания.

• Системный подход увеличивает удовлетворение заказчика от конечного продукта за счет его подробного согласования на раннем этапе.

Системный подход удобен и в других областях применения. К примеру, системный подход отлично вписывается в типологию личностей или стилей менеджмента. Если будет интересно узнать об этом подробнее – напишите в комментариях.

Данная статья написана в рамках курса Product Management от Product University.