30/01/2020
Наступил Новый 2020 год, прошло время небольшого расслабления, которое как-то само по себе приходит на стыке лет. У меня раскачка заняла довольно таки много времени в этом году. Пришло время для концентрации и нового рывка длиною в год. В первой части статьи о том как построить IT инфраструктуру стартапу, была поднята тематика как подступиться к этой задаче людям, которые далеки от этой области. Потом была статья в блоге – Нужна ли нам облачная инфраструктура, которая рассказывала о плюсах и минусах облаков. Она была своеобразным продолжением первой статьи и затрагивала популярную тему облачных вычислений, и то, когда нужно стартапу обращаться к ним. Развивая тематику из вышеупомянутых статей, тут хотелось бы акцентировать внимание на вопросах формализации инфраструктуры, а также такого важного документа в повседневной работе ITшника, как Техническое Задание.
Необходимость документации и формализации процессов создания и работы IT инфраструктуры обусловлена сложностью и большим разнообразием компонентов. Успешность внедрения и дальнейшего функционирования во многом зависит от того, насколько все правильно расписано на бумаге. Однако, большинство организаций пренебрегает этими пунктами при своей работе. Как результат, уже при приемке сколько-то технологически сложных работ у подрядчиков начинаются постоянные трения и недовольства с ними. Заказчик думает, что исполнитель должен сделать на свое усмотрение так, чтобы все было идеально, однако в большинстве случаев исполнитель смотрит на то, что указано в Техническом Задании. И как следствие возникает конфликт ожиданий и полученного в результате. У меня до сих пор в голове периодически крутится аббревиатура из курса Cisco CCDA – PPDIOO, которая обозначает основные вехи IT проекта, и первые 3 буквы расшифровываются как Prepare (Подготовка), Plan (Планирование) и Design (Дизайн). Именно с этого должен начинаться любой IT проект.
Проблематика
Как уже указал выше во вступительной части этой статьи, документирование является одним из важных компонентов при создании и дальнейшей эксплуатации Вашей IT инфраструктуры. И заниматься этим в том или ином виде придется. Выделю в данной области 2 важных компонента.
Во-первых, это создание рабочей документации по всем IT системам. И в моем понимании, это не масса бамажных листиков, которые особо никто не читает, а хорошо продуманная система, в которой хранится важная для работы IT инфраструктуры информация. Как простейший пример, можно привести данные по используемым IP адресам в корпоративной сети. Если не вести их учет, со временем в работе инженеров настанет момент, когда на поиск нужной информации будет уходить неоправданно большое количество времени. И таких различного типа данных и настроек, которые используются в работе IT систем очень много. Без формализации всей этой информации, особенно при работе совместно команды специалистов, Вы получите бардак и неразбериху, а также несогласованность в общей работе.
Пожалуй, только начинающие в компьютерных технологиях, думают что основное в их работе – это взаимодействие с оборудованием и программным обеспечением. В реальности все оказывается немного по другому. Как только Вы начинаете работать с серьезными комплексными IT продуктами, Вы понимаете, что без системы управления знаниями и хорошей документации не обойтись. Это касается и случая, когда Вам приходится создавать непорседственно программный код, и тогда, когда Вы внедряете уже готовые программные или аппаратные решения в свою инфраструктуру. Основная архитектура Ваших подсистем обязательно должна быть формализована и расписана в документации. Это позволит всем сопричастным специалистам и не совсем таковым быть в курсе того, что и как работает или должно работать в вычислительных системах организации.
Во-вторых, разработка грамотных и детальных документов с техническим заданием на вновь внедряемые или модернизируемые системы. Данный тип документации специально выделяю отдельно, так как именно он частно становится камнем преткновения и источником многих бед. Данный документ по сути своей воплощает Ваши планы, видение, знания, которыми Вы обладаете в данной области и направляет исполнителя по тому пути, который Вы задумали. Так, например, попросив без хорошего ТЗ построить подрядчика мост через реку, можно получить и деревянную времянку для переправы по одному человеку за раз и железобетонную магистраль на десяток полос. Но, если у Вас не прописаны детали в Техническом Задании, то скорее всего Вы получите продукт, который будет в лучшем случае вызывать определенные нарекания, в худшем, данный продукт будет не годен для использования в задуманных целях.
Наихудший сценарий построения сложных IT систем в своей организации – абсолютное не использование Технических Заданий в этом процессе. Как не удивительно, но это часто встречающаяся ошибка во многих проектах и стартапах. Хорошо, если Исполнитель обладает отличной квалификацией в своей области и имеет при этом совесть, что встречается далеко не всегда. Тогда Вы скорее всего получите удобоваримое решение, которое будет рабочим. Если же нет, то считайте, что Вы выкинете деньги и время на ветер, а также потенциально получите еще и дополнительные проблемы от данного проекта. Поэтому совет начинающим стартаперам в области IT – обязательно составляйте ТЗ, не важно будет ли при этом внутренний или внешний исполнитель.
Также при составлении требований к создаваемой IT системе необходимо максимально детально углубиться в технические детали ее работы. Мой горький опыт мне сейчас говорит, что если Вы что-то четко не прописали в тех задании, то с большой степень вероятности этого или не будет в реализованном проекте, либо это будет работать не так, как ожидается. Поэтому, к созданию Технического Задания необходимо подходить очень деликатно, осознанно и тщательно. Его разработка – является серьезной работой, которая как правило требует хорошей экспертизы в конкретной предметной области, коммуникаций и переговоров с потенциальными исполнителями, а также интеллектуальных усилий по грамотной формализации всего документа. И это должно быть не просто “отпиской”, а полноценным инструментом, который будет лежать в качестве фундамента той или иной IT системы.
Заключение
Во второй статье цикла сосредоточился на проблемах документирования и формализации процессов запуска и эксплуатации IT инфраструктуры. Для многих, кто только начинает окунаться в мир информационных технологий, эти вещи кажутся малозначительными и зачастую ненужными. Однако именно они позволяют создать логический каркас вашей инфраструктуры и обеспечивать максимально беспроблемное внедрение и эксплуатацию всех технологических компонентов. В следующей заверщающей части цикла рассмотрим основной движущий фактор построения эффективной IT системы – людей и их профессиональную квалификацию.
