Человеческий фактор в программировании

ОглавлениеДобавить в закладки К обложке

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

Властная пирамида

Когда речь идет о проектах по разработке программного обеспечения и командной работе, традиционная модель лучше всего подходит для того, что называется тактической работой. В тактических проектах территория знакома, а параметры известны. Самое главное — это выполнить работу. Я заточил свои «программистские зубы» на тактических проектах, в которых разрабатывались стандартные бизнес-приложения, например платежные ведомости, исчисление себестоимости и кадровые архивы. После того как вы сделаете пару систем ведения платежных ведомостей, они все начинают казаться одинаковыми. Даже если это не так, такой взгляд позволяет упростить работу и дает возможность применять стан-дартные подходы. В итоге вы знаете каждый свой шаг и сможете сделать их даже во сне.

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

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

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

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

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


-= 34 =-
Регистрация.
Забыли пароль?
Логин
Пароль
Запомнить меня