Руководство командой разработчиков программного обеспечения
Прикладные мысли

С. Архипенков

Назад Содержание Вперёд

Проблемы неисполнения

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

1. Понимание целей работы. Роль лидера «штурман». Задача лидера обеспечить общее видение целей и стратегии их достижения.
2. Умение ее делать. Роль лидера «образец». Задача лидера — научить, быть наставником и образцом для подражания
3. Возможность ее сделать. Роль лидера «помощник». Задача лидера обеспечить для этого все необходимые условия.
4. Желание ее сделать. Роль лидера «вдохновитель». Обеспечить адекватную мотивацию участника на протяжении всего проекта, на мой взгляд, одна из самых сложных задач лидера.

История 16. «Делаем все по правилам!»

Симптомы:

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

Диагноз. «Зло преждевременной оптимизации». Причина: программист не научился управлять приоритетами. Не различает важные и не важные дела. Низкая эффективность. Для решения задач в срок постоянно не хватает времени. Сверхурочные. Раздражительность. В результате появляется большой и проблемный код.

Рекомендации. Более четко формулировать цели и расставлять приоритеты. Определить конкретные критерии оценки результата, директивное управление. Нацеливайте программистов на правильное решение задачи максимально быстрым способом. Опыт свидетельствует, что более чем в 90% случаев ее не придется переделывать. Если работа вашей подпрограммы занимает только 1% общего времени выполнения, то, затратив сколько угодно времени на оптимизацию ее алгоритма, вы не добьетесь улучшения системных характеристик более чем на 1%. Такой выигрыш вряд ли стоит того, чтобы тратить время на оптимизацию. Со всеми остальными «программистским наворотами» дело обычно обстоит так же.

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

Второе условие эффективной работы программиста — умение делать порученную работу. Как правило, начинающие программисты мало что умеют. Их главный метод программирования — копирование чужих образцов (Copy/Paste). Это естественный путь обучения ремеслу. Вспомним художников, которые учатся, копируя полотна великих мастеров. Важно, чтобы образцы для подражания были достойными. Поэтому целесообразно поручать задачу паре программистов, в которой один из них выступает наставником, а другой подмастерьем, перенимающим опыт.

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

Третье условие эффективной работы — программисту должна быть предоставлена возможность решить поставленную задачу. Здесь речь идет не о тривиальном наличии компьютера и инструментов разработки. И не о наличие отдельного кабинета, о котором пишет Де Марко. В творческой деятельности обязательным элементом ответственности является свобода выбора пути решения стоящей проблемы. Свобода не только необходимое условие творчества, но и важный мотивирующий фактор. Предоставьте членам проектной команды право на ошибку. Это нормальный атрибут творческого поиска. На ошибках учатся. Умный не тот, кто не делает ошибок, а тот, кто их не повторяет. Чем чаще мы ошибаемся, тем быстрее учимся и быстрее добиваемся успеха. Ошибки — это просто часть культуры инновации.

Одним из элементов свободы является отсутствие жестких сроков на выполнение задачи. Для профессиональных управленцев отсутствие жестких сроков может звучать как нонсенс, но в творческой деятельности это один из обязательных элементов эффективной работы. Бессмысленно заставлять программистов работать больше, устраивать сверхурочные авралы и субботники. Работать больше, это совсем не значит — работать продуктивнее. Наоборот. Излишнее давление и суета приводят к непродуманным решениям и многочисленным последующим переделкам. «Хорошо управляемое предприятие — это спокойное место. Зато «фабрика, отличающаяся "кипучей" деятельностью и "трудовым героизмом" работников, который бросается в глаза любому посетителю, является на самом деле плохо управляемой». Это не я сказал, это говорит управленец «в законе» [38].

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

Глава 5. Практики демотивации

Классификация антипаттернов руководства

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

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

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

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

Некомпетентность. Руководитель не самостоятелен. Не имеет необходимого опыта. Не является специалистом в своей области. Сильно зависим от окружения и обстоятельств. Не готов брать на себя ответственность. «Армия львов под управлением барана всегда проиграет армии баранов под управлением льва», (с) Наполеон Бонапарт.

Мнительность. Отсутствие доверия между руководителем и участниками проекта. Чрезмерная настороженность. Скрытность. Неспособность делегировать полномочия. Руководитель не осознал синергию взаимозависимости и взаимопомощи. Все взаимодействия рассматривает только в духе «выиграл/проиграл». Исходит из предпосылок индустриальной эпохи Генри Форда: «Работники ленивы, поэтому им необходимы внешние стимулы для работы. У людей нет честолюбия, и они стараются избавиться от ответственности. Чтобы заставить людей трудиться, необходимо использовать принуждение, контроль и угрозу наказания». Манфред Кетс де Врис называет данное отклонение «параноидальным управлением».

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

Антипаттерны некомпетентности

«Я сделал все, что мог!»

Руководитель не способен оценить сложность решаемых задач, эффективность способов их решения и реальное состояние проекта. Постоянные негативные оценки прогресса проекта: «Все плохо! Надо делать быстрее! Надо делать лучше!», не вдаваясь в подробности «как это надо делать». Раздувание недостатков до глобальных размеров. Постоянная публичная критика участников команды и жалобы вышестоящему руководству на некомпетентность исполнителей. Надежда на то, что если проект провалится, то удастся свалить вину на команду: «Я сделал все, что мог!». Если же проект окажется успешным — присвоить успех себе: «Если бы я не «строил» команду, ничего бы не получилось!»

«Yes-man!»

Руководитель, который полностью зависим от Босса. Всегда согласен с его мнением, как бы оно не расходилось с его собственными взглядами и мнением его команды. Руководствуется принципом: «Возлюби Босса своего и никогда не спорь с ним!». Интересы фирмы, команды, продукта и его пользователей не учитываются вовсе. «Босс хочет, что бы мы закончили проект в два раза быстрее. Как? Это ваша забота, вам за это деньги платят!». Не принимает ни одного решения без согласования с Боссом. Испытывает постоянную потребность «угадать и угодить» Культивирует любимчиков в команде, которые никогда с ним не спорят.

«Охота на ведьм»

Руководитель сознает свою некомпетентность и опасается, что если он не возглавит борьбу с «врагами» проекта, то «врагом» проекта может оказаться он сам. Постоянный поиск виновных и «козлов отпущения». Наказания. Разжигание конкуренции в команде: «После проекта останутся только лучшие!». Действия по принципу «разделяй и властвуй». Исполнители проекта разделяются на несколько противоборствующих клик. Пресечение любой критики и опасного для себя поведения подчиненных: «Ваше поведение непрофессионально / некорпоративно!» (Вы ни разу не слышали этой фразы — завидую, вам везло с начальниками).

«Нет времени точить пилу!»

Руководитель не умеет управлять приоритетами, постоянно занимается пожаротушением, полностью погружен в решение неотложных вопросов. Времени на уточнение целей, разработку стратегии, адекватное планирование, оценку и повышение эффективности применяемых процессов не остается. Героический труд («у плохих генералов всегда много героев»). Темп поступления проблем превышает скорость их решения. Большинство задач, которые получают участники проекта, имеют наивысший приоритет и срочность. «Это надо было сделать еще вчера!» Работа постоянно выполняется под давлением нереальных сроков. Обучение, анализ, проектирование и рефакторинг — «это все потом!». Постоянные сверхурочные и авралы. Большой проблемный код. В англоязычной википедии у этого антипаттерна другое, более жесткое название — «Headless chicken».

Антипаттерны мнительности

«Агрессия»

«На то и волк в лесу, чтоб пастух не дремал!» Руководитель стремится удерживать подчиненных вне «зоны комфорта». «Настоящие лидеры задают трудные вопросы и выбивают людей из зоны их комфорта. Затем они управляют возникающим стрессом!», (с) Р.А. Хейфетц, Д.Л. Лори, «Работа лидера», 1997. Постоянное давление. Нереальные сроки. Сверхурочные. Авралы. Непрерывная критика и понижение самооценки. «Заодно можно сэкономить на зарплате!». Грубость. Запугивание. «У нас незаменимых нет!» «Поощрение непричастных и наказание невиновных». Назначение в несколько проектов одновременно. «Чем больше, тем лучше — обязательно что-нибудь провалит! Сотрудник должен все время ощущать свою вину!» Постоянные перемещения людей по горизонтали и вверх-вниз. Обязанности определены самым общим образом: «Ты в ответе за все!» Поручения не зависят от обязанностей. Правила меняются по ходу игры.

«Управление грибами»

Удержание работников в неинформированном и постоянно занятом состоянии. Замыкание всех внешних и внутренних потоков информации на себя. Фильтрация и искажение информации в личных интересах. Удержание исполнителей в постоянной зависимости от более информированного начальника. Строгое разграничение прав доступа к проектной документации и исходным кодам. Ограничение доступа в Интернет («а вдруг узнают среднюю зарплату на рынке?»), запрет ICQ, препятствование общению с коллегами из других компаний. Загрузить работой так, чтобы времени на обдумывание чего-либо не оставалось. Постоянно находить какие-нибудь «важные и неотложные» дела. Почему управление грибами? Потому, что грибы держат в темноте и кормят навозом.

«Микроменеджмент»

Отсутствие делегирования в любом виде. Строгий контроль всех работ через активное личное наблюдение. Руководитель замыкает на себя принятие решений по всем вопросам. Влезает во все самые мелкие работы, от структуры таблиц в БД до цвета шрифтов в интерфейсе. Вместо объяснения того, что надо делать, постоянные указания на то, как надо делать. Считает себя самым компетентным. Навязывает собственные идеи. «Думать — это моя работа! Просто, делай, как я сказал!» Жестко контролирует, каждый шаг исполнителей.

«Методологическое безумие»

Безграничная вера руководителя в методологию с большой буквы «М» — всеобъемлющую теорию того, как следует решать весь класс задач, возникающих в процессе производства. «Методологию создавали умные люди, а исполнители некомпетентны!» Методология принимает все решения, люди не принимают решения вовсе. Многоступенчатая бюрократия. Все процессы регламентированы. Все делается по инструкции. Эксперименты запрещены. Применяемые методы ограничены. Установлен тотальный контроль соблюдения регламентов. Инструкции постоянно разрастаются вследствие попыток учесть все возникающие новые ситуации. Внедрены всеобъемлющие нормы и метрики. Большая часть времени исполнителей тратится на соблюдение правил и писанину, которую никто никогда не читает. Большая доля «сизифова труда».

Последствия применения антипаттернов

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

• Фатальная демотивация исполнителей. Вместо мотивирования сотрудников на успех, мотивирование их на избежание риска и негативных для себя последствий.
• Подавление свободы, самостоятельности, творчества и инициативы.
• Деструктивное подчинение. Это когда все работают строго по инструкции и только в соответствие с указаниями руководства. Отсутствие ответственности исполнителей. «А какие ко мне претензии? Как сказали, так я и сделал!»
• Низкая эффективность и качество работы.
• Ухудшение морального климата. Вместо доверия и сотрудничества подозрительность и формальное взаимодействие. А вы никогда не видели, как тимлид беседует с программистом только «под протокол» и с подписями на каждом листе?
• Стрессы. Усталость участников. Личные проблемы.
• Увольнение наиболее профессиональных сотрудников.
• Провал проекта.

Назад Содержание Вперёд