The Programmers' Stone (Программистский камень) - страница 35

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

Это отнимает время у настоящей работы. Некоторые организации требуют, чтобы работники заполняли отчеты о командировках, такие сложные, что люди на самом деле выделяют полдня в месяц только на заполнение этих отчетов. Да что там — 10 % времени (и зарплаты) тратится на тупой ритуальный административный процедурализм! Данные отчетов могли бы собирать гораздо проще, а остальную конторскую обработку, если это так необходимо, могли бы делать клерки, которым платят меньше и которые многочисленнее.

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

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

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

Помните, что паковщики в организации не поймут описанные выше эффекты, поскольку они не признают существование такого подхода и состояния ума, с которым мы программируем. Это проблема офиса с открытой планировкой[14]!

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

Книга «Справочник рейнджера Слоана» (Sloane Ranger's Handbook) включает карту мира для рейнджеров Слоана. Около 50 % всей карты занято Площадью Слоана, Шотландия соединена с Лондоном узенькой дорожкой M1, а континенты отодвинуты к краям карты. Шутка заключается в том, что у всех нас собственная искаженная карта мира, но карта рейнджеров уж очень сильно искажена по сравнению с географической. Для рейнджеров Слоана это не шутка — это правильное представление их мира, и они утверждают, что их представление не более нереальное, чем какое бы то ни было другое. (Некоторые из них купили книгу, чтобы иметь возможность проверить правильность. Она прошла проверку.)

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