Статьи

Планирование и инженерия

в рубрике Peopleware

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

Такое бывает не всегда, не все инженеры такие, но это распространенный паттерн поведения.

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

Такое бывает не всегда, не все менеджеры такие, но это распространенный паттерн поведения.

Том ДеМарко написал на эту тему целую книгу (Peopleware). “Часто менеджеры относятся к своим инженерам и ученым как к умственно отсталым детям”. В этой книге, он написал, что так нехорошо, что надо по другому. Но он не написал главного. Почему все происходит именно так. А ведь слишком часто происходит именно так, и до, и после его книги. Воспроизводится регулярно, на местах, где в том числе никто не читает никаких книг. То есть, кто бы что ни говорил, но это устойчивое состояние системы, к которому она приходит самостоятельно.

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

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

С этого мы и начнем. Это очень важно. Недостаточно быть хорошим инженером, понимать и всей душой разделять убеждения Peopleware, чтобы быть хорошим менеджером. Это, знаете ли, я в свое время испытал на себе.

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

И тут дело не только и не столько в квалификации. Вся хохма в том, что сами инженеры не так глубоко разбираются в проблемах соседних инженеров. Так же часто, как они считают менеджеров идиотами, они склонны считать проблемы соседних инженеров простыми. А свои собственные - сложными. Задача, над которой работает сосед - проста, и только своя собственная - “по-настоящему серьезна”. (1)

Сами понимаете, такое бывает не всегда, не все инженеры такие, но это распространенный паттерн поведения.

Дело в том, что только углубившись в технические проблемы (и потратив дохрена времени), можно понять, где лежат “грабли” (1а).

Слушайте, а может быть, можно тупо обойтись без менеджеров? Голубая мечта инженеров. Давайте просто устраним идиотов. И все станет хорошо. Заводы - рабочим. Землю - крестьянам.

Тут две проблемы. Первое - дело в том, что иногда задача настолько масштабна, что один инженер не в состоянии решить ее за вменяемое время. Говоря о “решить”, я говорю не о какой-то фигне, а о написании работающего кода, решающего проблему. В этом случае работать должны несколько инженеров, и возникает проблема координации. Результаты их труда должны как-то стыковаться.

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

Этот один вовсе не обязательно должен быть идиотом. Пусть он - наиболее талантливый инженер. Но и не будучи идиотом, он все равно подвержен интуитивному фактору (1). Возможности человеческого мозга ограничены, и поэтому он не может понять все. Знать и понимать все в принципе невозможно. См (1а).

И в этой ситуации - у некоторых инженеров уже возникает повод таки считать его идиотом.

И тут уместно сказать, что подозрения менеджеров также не беспочвенны. Инженеры часто ведут себя как избалованные дети. Вынуждая менеджеров относится к себе, как к избалованным (и умственно отсталым, ибо не понимают объяснений) детям. Том ДеМарко очень много говорит о том, как надо себя вести менеджерам (которые часто вчерашние инженеры), но ничего не говорит про то, что инженеры частенько ведут себя именно как дети. Как еще к ним относиться, блин?

ОK, согласимся с ДеМарко в том, что нянчиться неправильно. Но что нужно сделать, чтобы повзрослеть? Надо получить больше ответственности. И при этом ошибаться. И учиться на ошибках. Другого способа человечество не придумало. Советы тупо “стать умнее” или относится к коллегам “более терпимо” не работают.

Нельзя успешно руководить, не умея подчиняться. Но, с другой стороны, часто умение подчиняться приходит только с опытом руководства. Имея это в виду, руководитель получает в свои руки неплохой рецепт. Устраивайте ротацию руководителей. Каждый инженер должен хотя бы временно побыть руководителем - с полной ответственностью, и следующей из нее возможностью ошибиться. Хотите, чтобы люди “повзрослели”? Дайте им ответственность.

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

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

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

Почему это бывает именно так? Потому, что не инженер выбирает себе менеджера. А менеджеру для того, чтобы быть успешным, достаточно “слушаться начальства”, и быть организованным. Это даже до тупых доходит. Чтобы “слушаться” и “быть организованным” - ума много не надо.

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

Поэтому Том ДеМарко подводит черту простой фразой. “Эти проблемы снизу не решаются”. Вот и все резюме “человеческого фактора”. В этом с ним можно согласиться, но он не приводит рецептов для изменения даже сверху. А понимание требуется для действия. Для чего оно, если действия нет?

Решение? Оно есть. Auftragstaktik. Философия и практика руководства, предлагающая как руководителям, так и починенным измениться, и выйти из описанного порочного круга.

Про Auftragstaktik и “декларативное планирование” здесь уже рассказывалось и будет рассказываться дальше.

VN:R_U [1.9.5_1105]
Rating: 0 (from 0 votes)

Один комментарий на “Планирование и инженерия”

  1. Все так и все не так. Позволю себе не согласиться с вами. Никогда еще не встречал когда умных и уважаемых людей считали идиотами, но вот идиотов часто считают умными. Обычно “собратья по разуму”. Ситуация описанная в статье имеет место быть. Но только когда все герои именно такие полностью удовлетворяющие этому “распространенному паттерну поведения”. Описанная ситуация в статье это классическая ошибка выстраивания процесса программирования плюс подмена понятий. Просто не хватает важных звеньев в цепочке. То что называется в статье менеджером на самом деле является ведущим инженером, а то что часто обзывают словом менеджер подразумевает под собой связку координатора проекта и аналитика. Так что если человек не компетентен на занимаемой должности, то это не оправдается ни каким стечением обстоятельств. А то что этому человеку приходится выполнять несколько ролей, несовместимых между собой, то это ошибка построения схемы работы подразделения. Что я хочу сказать? Просто описанная ситуация это декларация некомпетентности и ошибок участников процесса.

    VN:R_U [1.9.5_1105]
    Rating: 0 (from 0 votes)

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

Вы должны быть авторизованы для комментирования.

Партнеры

Microsoft ITONLINE Group ScrimTrek IT Trainings

© Careerlab, ITONLINE GROUP 2012 Команда Software People

+7 (495) 933-01-33

team@softwarepeople.ru