Как сформировать требования для IT-инфраструктуры, чтобы уложиться в сроки и бюджет?

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

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

Так что форма не особо-то и важна. Главное, чтобы то, как составлены требования, удовлетворяло всех участников процесса.

В требованиях важнее всего наполнение, ведь в них есть такие пункты, без которых попросту нельзя написать нормальное ТЗ. Чтобы составить их правильно, достаточно задать себе несколько вопросов.

От этого точно пострадают дедлайн и бюджет — сроки и затраты увеличатся. И, в некоторых, очень редких случаях, ухудшится качество конечного результата.

Составить требования можно двумя способами: самостоятельно, перед тем, как обратиться к потенциальному подрядчику и вместе с ним.

В первом случае требования составляет менеджмент вместе со штатными DevOps-специалистами и разработчиками. Почему менеджмент, а не одни инженеры? Любые работы с инфраструктурой решают некую бизнес-задачу. Например, оптимизацию ресурсов за счет масштабирования только высоконагруженных компонентов. Для её понимания и четкой формулировки необходимо, чтобы управленцы взаимодействовали с технарями.

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

Самая частая причина — заказчик упустил какой-то важный пункт или умолчал о чем-то.

Например, в одном из проектов клиент не предупредил, что ему недостает компетенций в построении процессов CI/CD и не рассказал, что в штате нет специалиста, который смог бы написать пайплайны для внутренних сервисов. Мы выяснили это уже после начала работ, которые пришлось приостановить, чтобы проконсультировать заказчика. Это увеличило сроки и затраты на проект.

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

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

Вот два примера хорошо сформированных требований, из которых потом получилось прекрасное ТЗ.

Первый — требования для переезда в новую инфраструктуру для увеличения пропускной способности системы.

Второй пример — это требования для миграции текущего решения в контейнеры, переезда в K8s и микросервисы.

Как видите, требования расписаны очень подробно: описана система, связи, что и как работает, как настроено. Во втором варианте прекрасно описан конечный результат — то каким видят его заказчики.

Есть хорошо составленные требования, но есть и плохие. Самый неудачный вариант — это их полное отсутствие, как и понимание, что и для чего нужно сделать. Менее плохой — это хоть какое-то понимание в духе двух примеров ниже:

Пример 1:

Бизнес-задача

Оптимизация действующей инфраструктуры, перенос к другому хостеру и организация отказоустойчивого решения для бд и веб-серверов в Selectel.

Пример 2:

Бизнес-задача

Жалобы на медленную работу серверов. Необходимость обновления версии PHP и БД. Обеспечение стабильности бизнеса и безопасность инфраструктуры, повышение отказоустойчивости. Настройка системы мониторинга.

Реструктуризация действующей инфраструктуры

Контекст

Бывает и так, что требования описаны достаточно подробно, но там совсем нет важной информации. Именно такой случай показан ниже. Требования были составлены для построения отказоустойчивой инфраструктуры.

Мы сталкивались с самыми разными видами требований. Поэтому, чтобы работа с большей вероятностью закончилась в срок и не вышла за рамки бюджета, мы просим заказчика заполнить небольшой бриф.

Так выглядит документ для заполнения, по которому будет организован процесс CI/CD.

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

Вкратце флоу процесса выглядит так:

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

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

Иногда инфраструктурные работы — то ещё приключение и далеко не всегда веселое. Хотя бы потому что не всегда сразу можно вспомнить все важные детали. Если у вас стоит задача оптимизировать систему, перехать в новую инфраструктуру или микросервисы — смело обращайтесь к нам. Мы поможем правильно сформировать требования, подскажем, если чего-то не хватает, напишем ТЗ и уложимся в бюджет и сроки.

Записаться на консультацию по инфраструктурным работам можно по ссылке.

Как сформировать требования для IT-инфраструктуры, чтобы уложиться в сроки и бюджет?

Что из себя представляют требования к ИТ-инфраструктуре?

Что обязательно должно быть в них?

Что будет, если составить требования некорректно?

Кто составляет требования?

Почему они могут быть составлен некорректно и как этого избежать?

Как выглядят идеальные требования к инфраструктуре?

Как мы формируем требования в ITSumma

Подводим итог