www.gnuman.ru

Резюме | Контакты | Работа | Page Title Eraser | GrayModern2 | Статьи
Путешествия | Фотоальбомы | Проект 365 | Блог | Черный список
Как выиграть суд у ГИБДД и вернуть права | Технический департамент своими руками

Командный метод управления

Автор: Джоэл Спольски
Переводчик: Александр Лебедев
В оригинале статья называлась The Command and control Management Method и была написана 8 августа 2006


Фридрих Великий (PDF): "Солдаты должны бояться своих офицеров больше, чем любых опасностей, которым они подвергаются... Невозможно добром побудить обычного солдата противостоять таким опасностям; он может сделать это только из страха большего наказания."

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

Существуют тысячи приемов, которыми вы можете воспользоваться. Посмотрите фильмы Biloxi Blues и An Officer and a Gentleman - это даст вам несколько отличных идей.

Некоторые менеджеры используют эти приемы потому, что они действительно научились этому в армии. Другие выросли в авторитарных семьях или странах и думают, что это естественный способ добиться подчинения. Третьи просто не знают ничего лучше. Блин, если это работает в армии, это должно работать в интернет-стартапе!

Существуют, как выясняется, три недостатка применения этого метода в хайтек-команде.

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

Более серьезный недостаток командного метода управления в том, что у руководста, на самом деле, нет времени на микроменеджмент на армейском уровне, просто потому что на это не хватит менеджеров. В армии можно отдать приказ одновременно большой группе людей потому, что все, как правило, заняты одним и тем же. "Чистить оружие!" - можете сказать вы взводу из 28 человек, а затем пойти вздремнуть и выпить чаю со льдом на веранде Офицерского Клуба. В команде по разработке ПО каждый работает над чем-то своим, так что попытки заниматься микроменеджментом приводят к управлению методом порулил и убегай (прим. пер.: этот способ автор отлично описывает в статье "Я начальник - ты дурак" и команда клоунов). Это когда вы активно "рулите" разработчиком, а затем внезапно исчезаете из его жизни на несколько недель, пока вы занимаетесь остальными разработчиками. Проблема "управления методом налетов" в том, что вы не остаетесь достаточно долго на одном месте, чтобы увидеть, почему ваши решения не работают или чтобы скорректировать курс. В результате, всё, чего вы добиваетесь - это периодически сносите ваших бедных программистов с рельсов, так что, истощенные от пережитого опыта, они тратят всю следующую неделю на то, чтобы найти свои вагоны, поставить их обратно на пути и опять привести всё в порядок.

Третий недостаток в том, что в хайтек-команде отдельные исполнители всегда имеют больше информации, чем "лидеры", так что именно исполнители находятся в наилучшей позиции для того, чтобы принимать решения. В ситуации, когда босс забредает в офис, где два программиста уже третий час спорят про то, как лучше осуществлять сжатие картинки, человек, обладающий наименьшим объемом информации - это босс, так что это последний человек, которого вы хотите видеть принимающим технические решения. Я помню, когда Майк Мэйпз (Mike Maples) был моим большим начальником, отвечая за Microsoft Applications, он был каменно тверд в нежелании принимать чью-либо сторону в технических спорах. В конце концов, люди поняли, что нет смысла приходить к нему за решением спорных вопросов. Это заставило людей обсуждать достоинства и недостатки решений, и разногласия всегда решались в пользу того, кто был лучшим оратором, хм, то есть, я имел в виду, решались лучшим возможным способом.

Если командный метод так плох, то почему армия использует его?

Мне объяснили это в сержантской школе. Я служил в десанте в Израиле в 1986-м. Вероятно, я был самым плохом десантником, который у них когда-либо был, думаю я сейчас, вспоминая те годы.

Для солдат существует несколько правил. Правило номер один: если ты на минном поле - замри. Логично, правда? Это правило вбивали в тебя постоянно в течение начального обучения. Время от времени инструктор кричит "Мина!" и все должны замереть, так что через некоторое время это просто входит в привычку.

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

Хорошо, теперь контрольный вопрос. Что делать если вы на минном поле и на вас напали?

Это не такая уж гипотетическая ситуация, это просто досадный способ попасть в засаду.

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

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

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

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

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

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

Завтра я рассмотрю так называемый "метод экономической мотивации".

Альтернативный перевод.


Оригинал статьи: http://local.joelonsoftware.com/wiki/Командный метод управления


Другие статьи Джоэла Спольски (The Joel on Software) на русском языке
Маркетологи vs. Разработчики
Похож ли медленный рост на медленную смерть?
О чем ваша компания?
Студенческие проекты и тайм-менеджмент
Особенности Вайфая на конференциях
Новый Офис Fog Creek
Почему форматы Microsoft Office такие сложные? (И как это обойти)
Речь в Йельском университете 1
Речь в Йельском университете 2
Речь в Йельском университете 3
Письмо о стратегии VI
Семь шагов на пути к восхитительной службе по работе с клиентами
Общая картина
Консалтинг по оценке производительности (из писем)
Измерения продуктивности
В поисках Великих Разработчиков
Не дайте Астронавтам Архитектуры вас запугать
Секрет айсберга
Метод отождествления
Метод экономической мотивации
Командный метод управления
Три метода управления (введение)
А ваш язык программирования так может?
Контракты и соглашения которые не стоит подписывать
Ежедневная сборка - ваш союзник и друг
Моя первая проверка Билла Г
Испытание Удобства и Простоты Использования с Морами
Опасности обучения на Java
Как поставлять что-нибудь по почте
Превращение денег в программное обеспечение, которое работает
Три заблуждения теории вычислительной техники
Достигая тех высот
Выбор даты выпуска
Как заставить неправильный код выглядеть неправильно
Совет студентам изучающим вычислительную технику
Верблюды и песочница
Пожалуйста, сэр, могу ли я получить компоновщик?
Как Microsoft проиграла битву за API
Не просто удобство использования
Абсолютный Минимум, который Каждый Разработчик Программного Обеспечения Обязательно Должен Знать о Unicode и Наборах Символов
Как сделать так, чтобы ваше резюме прочитали
Двоекультурие
Бионический офис
Лорд Палмерстон в программировании
Закон Дырявых Абстракций
О вреде премирования
Пять миров
Огонь и движение
Назад, к основам
Весна в Кэмбридже
О вреде многозадачности применительно к людям
По главной улице без оркестра
Тест Джоэла: 12 шагов к лучшему коду
У Microsoft поехала крыша
Cтратегические заметки III. Позвольте мне отказаться!
Пять (неуважительных) причин не иметь тестеров
Ну откуда все эти (неоригинальные) мысли?
Планирование программного обеспечения малой кровью
Стратегические заметки II: Вопрос о курице и яйце
"Я начальник - ты дурак" и команда клоунов
Искусство проведения интервью
А вот ещё про отпуск
Введение в Восхитительный Дизайн
Для чего нужны тестировщики



Правильный CSS! Valid XHTML 1.0 Transitional