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

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

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

Ниже приведены проблемные личности среди менеджеров проектов:

• Планировщик собраний
• Статистик
• Заблуждающийся
• Пессимист
• Оптимист
• Капитан команды
• Тиран
• Одержимый процессом
• Неуверенный

Планировщик cобраний

Руководитель проекта, который считает, что все проблемы проекта вызваны отсутствием связи и координации, а решением станет обильное количество собраний.

• Может мутировать в статистика
• Опасен в сочетании с менеджером по продукту типа автор патента
• Вероятность исправления: высокая
• Опасность для проекта: низкая

Проблема

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

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

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

Решение

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

Такого менеджера проекта можно исправить с помощью простой инструкции:

1. Классифицируйте все типы собраний, которые они обычно созывают: отчёты о состоянии, обзоры проекта, планирование расписания и т.д.
2. Определите, какие результаты (если они есть) этих совещаний можно достичь иными средствами, например, по электронной почте, инструментами трекинга, неофициальными беседами.
3. Для обязательных встреч определите, как часто они должны проходить и кто должен присутствовать.
4. Планируйте встречи блоками, чтобы избежать многократного отвлечения сотрудников из-за переключения контекста.
5. Оставьте несколько дней недели свободными от собраний.
6. Освободите от собраний несколько недель целиком (вас полюбят за это).
7. Планируйте каждую встречу по крайней мере за неделю до её начала с опубликованной повесткой дня и любыми материалами, которые необходимо рассмотреть до встречи.
8. В начале совещания проводите обзор повестки дня, целей совещания и содействуйте достижению этих целей.
9. Завершайте собрание сразу: не продолжайте его, если исходная цель достигнута.

Собрания необходимы для выполнения проекта, но главное:

1. Сделать каждую встречу максимально эффективной.
2. Минимизировать негативное влияние на производительность.

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

Cтатистик

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

• Может мутировать в неуверенного, планировщика собраний, заблуждающегося или тирана
• Опасен в сочетании с менеджером по продукту типа автор патента или разработчиком типа солдат
• Вероятность исправления: низкая
• Опасность для проекта: низкая

Проблема

Завершение любого проекта требует двух обязательных шагов:

1. Составить список дел.
2. Отметить пункты из списка, которые сделаны.

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

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

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

Решение

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

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

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

Заблуждающийся

Менеджер настолько оторван от реалий проекта, что даёт ложную информацию заинтересованным сторонам.

• Может мутировать в оптимиста или пессимиста
• Опасен в сочетании с разработчиком-оптимистом
• Вероятность исправления: высокая
• Опасность для проекта: очень высокая

Проблема

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

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

• «У меня плохое предчувствие».
• «Не думаю, что мы успеем к этому сроку».
• «Думаю, у нас всё будет хорошо».
• «Не вижу никаких проблем».
• «Это решение меня смущает».

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

Важно отметить различие между заблуждающимся менеджером, пессимистом и оптимистом:

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

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

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

Решение

К счастью, такого менеджера можно исправить в два действия:

1. Спросите его, почему он чувствует то, что чувствует.
2. Покажите ему количественные и качественные данные, противоречащие его инстинктам.

Зачем просить сформулировать, что он чувствует? Это поможет ему понять, что суждение основано не на чём-то материальном, а на субъективной оценке, то есть на чувствах. Жизненно важно, чтобы он пришёл к этому выводу самостоятельно — не нужно говорить, что у него плохие инстинкты. Продолжайте спрашивать «Почему ты так думаешь?», пока не достигнете прорыва.

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

Пессимист

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

• Может мутировать в заблуждающегося
• Опасен в сочетании с тестировщиком типа паникёр
• Вероятность исправления: нет
• Опасность для проекта: чрезвычайно высокая

Проблема

Большинство проектов разработки ПО можно назвать неудачными с какой-то стороны:

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

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

Пессимиста легко выявить по двум ключевым характеристикам:

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

Такая позиция может убедить начальство, что проект безнадёжен, и его действительно отменяют.

Решение

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

Оптимист

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

• Может мутировать в капитана команды или заблуждающегося
• Опасен в сочетании с разработчиком-оптимистом
• Вероятность исправления: низкая
• Опасность для проекта: чрезвычайно высокая

Проблема

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

На любой руководящей должности оптимизм перед лицом невзгод — важное преимущество. Чтобы отличить менеджера-оптимиста от смелого лидера, используйте следующие тесты:

• Чувствует ли он благодарность за плохие новости?
• Как часто он делает необоснованные комплименты?
• Находится ли он постоянно в хорошем настроении, независимо от того, насколько низок моральный дух коллектива?
• Избегает ли он конфронтации, даже если она оправдана?
• Не кажется ли, что для него нравиться окружающим важнее, чем успех проекта?

Менеджер-оптимист часто становится причиной провала проекта, поскольку он игнорирует проблемы, которые могут привести к провалу. Чем дольше идёт проект, тем хуже эффект.

Решение

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

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

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

Капитан команды

Менеджер проекта, который фокусируется на том, чтобы все программисты были счастливы, а не на успехе проекта.

• Может мутировать в оптимиста
• Опасен в сочетании с менеджером по разработке типа миротворец
• Вероятность исправления: высокая
• Опасность для проекта: низкая

Проблема

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

У капитана команды и оптимиста общим является позитивный настрой, однако его проявление принципиально отличается:

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

Капитана команды очень легко обнаружить:

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

Такой человек кажется идеальным менеджером проекта, но есть две причины для беспокойства:

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

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

Решение

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

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

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

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

Тиран

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

• Может мутировать в пессимиста
• Опасен в сочетании с разработчиками типа солдат и слон в посудной лавке
• Вероятность исправления: высокая
• Опасность для проекта: чрезвычайно высокая

Проблема

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

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

Фактические проблемы с тиранами сложно обнаружить, но они невероятно вредны для проекта.

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

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

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

Решение

Чтобы исправить тирана, нужно довести до его сознания, что такое поведение негативно влияет на проект. Для этого существует два общих подхода:

Во-первых, представить количественные данные, отражающие их стиль управления проектом:

• Сколько ценных сотрудников покинуло штат.
• Успехи в привлечении талантов.
• Сколько выпущено функций.
• Сколько зарегистрировано багов.
• Сколько пропущено сроков.

При сравнении этой информации особенно эффективны графики по времени.

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

• Как они ведут себя с сотрудниками.
• Как они обсуждают неудачи и успехи проектов.
• Как определить и отсеять некомпетентных участников проекта.
• Как привлечь и удержать компетентных участников.

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

• Люди не хотят быть подлыми.
• Людям нравится, когда их любят.
• Людям нравится быть эффективными.

Главное, чтобы команда приняла новый подход, несмотря на репутацию тирана в прошлом. Проблему можно решить очень просто, например, созвать собрание с темой «Я сожалею» и «Я изменился к лучшему».

Одержимый процессом

Менеджер настолько одержим процессом, что забывает о своей задаче — помочь в достижении проектом успеха.

• Может мутировать в тирана
• Опасен в сочетании с менеджером продукта типа диктатор
• Вероятность исправления: высокая
• Опасность для проекта: низкая

Проблема

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

Есть две обширные категории процессов, в отношении которых проявляется одержимость:

1. Одержимость водопадом
2. Одержимость гибкой разработкой (Agile)

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

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

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

Решение

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

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

Неуверенный

Менеджер проекта, который постоянно запрашивает текущий статус у сотрудников, считая это необходимым, чтобы те фокусировались на выполнении своих задач.

• Может мутировать в статистика
• Опасен в сочетании с разработчиками типа солдат и слон в посудной лавке
• Вероятность исправления: высокая
• Опасность для проекта: низкая

Проблема

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

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

Неуверенный менеджер широко известен под другим названием: микроменеджер. Его методы управления проектами интерпретируются членами команды проекта как любой или всё из следующего:

• Придирки
• Приставание
• Беспокойство
• Отвлечение
• Прерывание
• Надоедание

Часто у сотрудников развивается глубокое негодование на неуверенного менеджера проекта, потому что в их восприятии:

• Менеджер не доверяет их навыкам управления своим временем.
• Менеджер не верит их оценке сроков.
• Менеджер не понимает необходимости остаться в одиночестве для решения проблем.
• Менеджеру нечем заняться, кроме как спрашивать и сообщать статусы.

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

Решение

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

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

См. также:

• «Проблемные личности среди разработчиков»
• «Проблемные личности среди тестировщиков»