Нерациональное руководство

Менеджмент и фриланс

20 июня 2013

Название анти-паттерна: Нерациональное руководство
Также известен как: Патологический Куратор, Краткосрочное Суждение, Что Первое Пришло В голову, Страх Принятия Решений, Администраторы, Играющие В Технические Игрушки
Уровень, на котором чаще всего встречается: Компания
Название решения, направленного на улучшение: Рациональное Принятие Решений
Тип решения, направленного на улучшение: Роль и процесс
Основные причины: Ответственность (первопричина)
Неуравновешенные силы: Административное Управление Ресурсами
Примеры из жизни:
«Кто занимается этим проектом?» «Я бы хотел, чтобы он наконец принял это чёртово решение!» «Что мы сейчас делаем?» «Лучше выясним это с руководством до того, как начнём». «Можешь не спрашивать, они просто сказали нет».

Вводная информация

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

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

Общая форма

Руководитель (административная группа) одного или нескольких проектов по разработке не может принимать решения. Это может быть его недостаток как личности или результат навязчивого внимания к мелочам.

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

Анти-паттерн Нерационального Руководства осложняется неспособностью руководителя управлять разработчиками. Это также называют нехваткой способностей к управлению персоналом. Она характеризуется неспособностью:

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

Симптомы и последствия

Основной признак анти-паттерна Нерациональное Руководство ? пробуксовка проекта, постоянные споры по важным вопросам. Должно быть принято такое решение, которое бы позволило разработчикам идти вперёд. Результаты пробуксовки могут быть самыми негативными.

Упадок духа работников.
Задержки в сдаче проекта.
Ситуацией воспользуются Перцы.

Стандартные причины

У руководителя не хватает способностей руководить:

Разработчиками.
Другими руководителями.
Процессами разработки.

У него нет чёткого понимания стратегии, и поэтому он:

Не может принимать решения.
Боится успеха
Не имеет представления о том, что в действительности происходит с проектом.

Возможные исключения

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

Решения для улучшения

Придерживайтесь этих правил, чтобы справиться с анти-паттерном Нерационального Руководства:

Признайте, что у вас есть проблема, и воспользуйтесь помощью. Когда у руководителей возникают проблемы, вызванные стандартными причинами анти-паттерна, прежде всего они должны осознать, что у них возникли проблемы.
Поскольку предполагается, что они не владеют ситуацией, первым шагом будет определить ключевые показатели, самый типичный из которых «учиться на горьком опыте».
Например, нерациональный руководитель узнаёт о проблеме тогда, когда она дошла до критической точки, хотя технический персонал мог бы справиться с нарастающими проблемами или попросить помочь их решить. Никто не хочет обсуждать проблему, потому что в этом нет смысла. Руководители должны окружить себя способными сотрудниками (или консультантами), которые бы разделили с ними сложности руководства и выслушивали бы их.
Учитесь понимать разработчиков. Руководителю необходимо разбираться и в технической стороне вопроса, и в личных качествах своих сотрудников. Понимание технической стороны поможет руководителю распределять работу, а понимание людей поможет руководителю строить рабочие отношения.
Ставьте чёткие краткосрочные цели. Для проекта должны быть определены легко достижимые цели. Цели в долгосрочной перспективе тоже необходимы, но они не настолько хорошо мотивируют персонал на выполнение повседневной работы. Руководитель должен удостовериться, что поставлены четкие краткосрочные цели и персонал понимает, что нужно сделать для их достижения.
Определите направление работы. Сотрудники, которые работают над проектом, должны знать, какова цель проекта, чтобы все работали над достижением одной цели. Руководитель должен определять приоритеты и направлять работу.
Думайте над тем, как усовершенствовать проект. Руководитель должен понимать, что каждый проект слегка отличается от предыдущего, и следить за процессами разработки, корректируя их в случае необходимости. Хотя обычно уловки, которые позволяют усовершенствовать специализированный процесс, и не масштабны, они могут значительно увеличить производительность.
Наладьте контакт и обмен информацией. Каждый раз, когда «горячие» темы вызывают споры, решение о дальнейшем пути развития проще принять, когда вы держите совещание под контролем. Чтобы этого добиться:
- Определите основных участников.
- Соберите факты для обсуждения.
- Придите к недвусмысленному соглашению по проблеме (проблемам).
- Убедитесь, что мнение каждого было услышано.
- Удостоверьтесь, что все поняли, какие есть варианты решения проблемы.
- Согласитесь с наиболее предпочтительным вариантом.
- По мере возможности привлекать к воплощению решения тех работников, которым оно небезразлично.
Управляйте механизмами обмена информацией. Электронная почта и тематические конференции в сети полезны для обмена информацией, но могут способствовать разладу. Переписка по электронной почте может быстро выйти из-под контроля, а конференции в сети могут породить громкие и агрессивные споры.
Решение ежедневно отслеживать электронную переписку и сообщения сетевых конференций и определять признаки непонимания. Поговорите прямо со сторонами, вовлечёнными в конфликт, и предложите им остановить этот спор. Если действительно важно найти решение, то в большинстве случаев быстрее и эффективнее будет провести специальное заседание.
Регулируйте ход процесса лишь при возникновении отклонений. Крайности всегда опасны, и чрезмерный контроль со стороны руководителя не исключение. Ежедневные заседания и еженедельные отчёты, которые требуют погружения руководителя во все мельчайшие подробности проекта ? вот примеры чрезмерного контроля и микроменеджмента. Вместо этого действуйте лишь тогда, когда течение процесса нарушается; наблюдайте, но не вмешивайтесь. Дайте возможность другим решить проблемы. Подключайтесь к решению только тогда, когда это необходимо.
Применяйте эффективные методы принятия решений. Два метода рационального руководства Кепнера и Трего особенно эффективны для принятия решения при создании программного обеспечения. Первый из них называется «анализ ситуации». Этот метод помогает организовать и руководить в обстановке, когда отсутствует система. Он может быть использован как для взаимодействия с конкретным человеком, так и для взаимодействия с группой.
Второй называется «анализ решения». Этот метод важен для беспристрастного принятия решений. Личная необъективность при принятии решения может иметь плачевные последствия для проекта. Мы нередко видели результаты подобной необъективности.
Необъективность может порождаться дружбой, сжатыми сроками, ограничениями, накладываемыми техническими характеристиками платформы и невидимыми ограничениями инфраструктуры.

Эти два метода подробнее рассмотрены в следующих параграфах.

Анализ ситуации

Цель анализа ситуации определить первоочередные проблемы в сложной ситуации. Специально адаптированная версия этого метода включает следующие этапы:

Составьте список всех вопросов, требующих решения. В него могут войти все известные проблемы, незавершённые задачи, обязательства, недостатки технического обеспечения и другие моменты. Другими словами, в список может войти практически всё, что влияет на текущий проект.
Оцените вопросы по следующим критериям: важность, срочность и возможность усугубления. Используйте три уровня: высокий, средний и низкий. Например, если проблема имеет решающее значение для успешного завершения проекта, то она высокой степени важности. Если проблему необходимо решить прямо сейчас, иначе решение не будет эффективным, то она оценивается как высокой степени срочности. Если вы понимаете, что её серьёзность со временем существенно усугубится, то её оцениваем как проблему высокой степени усугубления.
Составьте таблицу на основе баллов каждой проблемы. Присвойте номера уровням оценки: высокий = 2, средний = 1, низкий = 0. Например, оценка высокий/средний/низкий наберёт 3 балла (2 + 1 + 0).
Определите приоритетные задачи на основании этих баллов. Ранжируйте по важности все те проблемы, которые набрали по 6 баллов. Затем определите приоритеты среди тех проблем, которые набрали по 5 баллов и меньше, пока весь список проблем не будет ранжирован по важности.
Решите, какие проблемы можно передать компетентным работникам. Некоторые проблемы могут быть под контролем сторонних людей, и было бы неразумным тратить энергию на их решение. Другие проблемы необходимо решить прежде остальных, из-за взаимозависимостей проблем. У квалифицированных специалистов решение большинства проблем не вызовет затруднений: составить план, создать аналитическую модель, снизить риски с помощью тестирования и т. д. Руководитель должен подобрать такой персонал, который сможет решить проблему.
Работайте с самыми приоритетными проблемами вашего списка. Метод анализа ситуации работает на принципе работы с наиболее важными вопросами, не затрагивая неважные. С помощью анализа ситуации руководитель может эффективно решать самые важные вопросы этого запутанного списка проблем, с которыми сталкиваются при выполнении проекта по разработке ПО.

Анализ решения

Специально адаптированные действия по этому методу включают следующие этапы:

Определите, какое решение вам необходимо рассмотреть. Другими словами, ваши действия должны начаться с письменного вопроса, подлежащего решению.
Определите альтернативные возможности для принятия решения. Это могут быть специфические конкретные альтернативы, такие как специализированные программы или категории решений, которые можно оценить.
Определите критерии решения. Для создания этого списка можно использовать анализ ситуации.
Распределите критерии в две группы: необходимые и желательные. Основными критериями будут характеристики, без которых решение не может быть приемлемым. Если какой-то важный критерий отсутствует в варианте решения, то от этого варианта необходимо отказаться. Поэтому необходимые критерии должны быть тщательно отобраны. Уменьшите список. Все остальные критерии являются желательными и их необходимо расположить в порядке очерёдности. Для этой цели используйте метод определения приоритетов из анализа ситуации. Затем присвойте желательным вариантам степени важности. Например, если всего семь критериев, то степень важности самого важного будет равна 7, следующий по важности критерий будет идти под цифрой 6 и так далее.
Определите, все ли варианты охватывают все необходимые критерии. Если нет, исключите те варианты, которые их не охватывают.
Выясните все детали. Оцените, насколько каждый вариант охватывает все критерии.
Создайте таблицу, в колонках которой будут отражены варианты, а в рядах критерии. Классифицируйте все варианты в таблице по желательным критериям. Например, если есть пять вариантов, самый лучший вариант получает оценку 5, следующий получает оценку 4 и так далее.
Умножьте степень важности на оценки и подсчитайте баллы каждого пункта таблиц. Добавьте в каждую колонку оценки и подсчитайте баллы для каждого варианта. Вариант с самым высоким баллом будет самым целесообразным.
Не забывайте о том, что самый целесообразный вариант не обязательно будет принят руководством или потребителями. Причиной этого может стать серьёзная ошибка или критерий, который не нашёл отражения в анализе решения. Поэтому важно оценить критерии принятия решения. Поэкспериментируйте со степенями важности и желательными критериями, добавляйте новые критерии, выбирая приемлемые варианты. Убедите окружающих, что суммарно критерии и степень важности соответствуют тем субъективным критериям принятия решения, которые послужили его причиной. Возможно, руководство, от которого зависит принятие решения, изменит свои критерии на более реалистичные, когда увидит, какое воздействие оказывают его ложные предпосылки на проект.

Вариации

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

Пара рук.
Технический специалист.
Такой же руководитель.

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

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

Примеры

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

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

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

В другой ситуации разработчик архитектуры (Перец) высказывал своё мнение о стандартах программирования на С++ по электронной почте всем сотрудникам, занятым в проекте. В проекте принимали участие несколько специалистов по С++ очень высокого уровня, которые обиделись на некоторые утверждения разработчика архитектуры.

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

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

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

После нескольких войн было принято окончательное решение, которое свелось к назначению координатора процесса, в обязанности которого входило контролировать: