Если бы корпоративные ИТ создавали гоночные автомобили

Проектирование и создание гоночного автомобиля с применением типичных процессов жизненного цикла, которые используются в корпоративном ИТ-отделе. Неплохая идея, не так ли?

Не так. Ужасная идея, но все равно интересно представить, как она может помочь разобраться в ошибках корпоративных отделов.

Предположим, что существует четыре основных группы. Команда проектировщиков (ИТ-архитекторы), команда, ответственная за производство (разработка), команда отвечающая за безопасность и механики (операции). Что бы из этого могло получиться:

Проектирование

Пришел запрос на изготовление гоночного автомобиля. После подтверждения его передают прямо команде проектировщиков. И она принимается за проект самого грандиозного гоночного автомобиля, который когда-либо производила компания.

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

Участники проводят дружеский анализ и оформляют готовый проект в подходящем, по их мнению, формате Word и Visio. Затем команда проектировщиков отправляет проект на рассмотрение и переходит к следующему.

Производство

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

До того, как открыть письмо, они выдают порцию брани. Далее - все еще хуже. Проскакивают фразы вроде "нафантазировали", "оптимистично", "оторванный от реальности". Чаще всего звучит слово "фигня".

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

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

Безопасность и удобство эксплуатации не играют критическую роль, поскольку не столь видимы по окончанию процесса производства.

Безопасность

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

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

Механики

До этого этапа разработки автомобиль кажется красивой игрушкой. Все довольны. Кроме, конечно, механиков и водителей. Они получают свое авто и радужная картина очень быстро тускнеет. Управлять им - сущий ад. Он постоянно ломается. Одним словом, "гроб на колесиках".

Но такое положение вещей никого не удивляет. Руководство уже заявило об успехе. Подпортить их репутацию сможет разве чья-либо смерть. У механиков есть список рекомендаций, которые необходимо удовлетворить, но им говорят забыть о них на неопределенное время и довольствоваться обходными приемами.    

Выводы

Сотрудничество между командами корпоративных ИТ все еще представляет серьезную проблему. Методика Agile является эффективной, но только что касается функциональных требований.

Успех концепции DevOps свидетельствует об улучшениях отношений между разработчиками и эксплуатационным персоналом. Но значит ли это, что произошли позитивные сдвиги в отношениях с командами архитекторов и специалистов по безопасности? Не совсем.

Не всегда удается добиться слаженной работы между командами. Хотя вы можете заставить их документировать свои требования.

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

источник