Не надейтесь на магию

(В оригинале - Don't Rely on "Magic Happens Here")

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

Самая сложная часть процесса программирования – мышление – одновременно и самая незаметная часть, а также наименее ценимая непосвященными. В течение десятилетий было много попыток устранить из процесса необходимость наличия мышления. Одна из самых ранних и наиболее запомнившихся попыток – это усилия Грейс Хоппер по созданию более понятного языка программирования, что по мнению некоторых должно было вообще снять потребность в специальности «Программист». Результат (язык COBOL) внес существенный вклад в привлечение в отрасль новых программистов в последующие десятилетия.

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

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

И когда кто-то не вовлечен в процесс, то он склонен неосознанно предполагать, что этот процесс – простой и делается «чудесным образом». Пока магия работает, все идет хорошо. Но когда (причем именно «когда», а не «если») магия вдруг перестает работать, начинаются серьезные проблемы.

Я знаю проекты, терявшие недели из-за того, что никто не понимал того, насколько проект зависим от «правильной» версии используемой библиотеки. И когда начались проблемы, члены команды искали причины во всех остальных местах, пока наконец-то кто-то не догадался, что причина в неправильной версии библиотеки.

Другой пример – один из отделов разработки работал очень хорошо: проекты выполнялись вовремя, никаких ночных сессий экстренной отладки, никаких аварийных заплаток. Все шло настолько хорошо, что руководство решило, что это «хорошо» происходит само собой, и менеджер проекта им не нужен. И через полгода в этом отделе все стало также, как и во всей остальной компании – задержки, ошибки, заплатки...

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

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

Автор оригинала - AlanGriffiths