- PVSM.RU - https://www.pvsm.ru -
Незнакомым с разработкой программного обеспечения может показаться странным, что у проекта есть и менеджер продукта, и менеджер проекта. Разница в том, что первый отвечает за определение продукта, а второй отвечает за состояние проекта и отчётность перед заинтересованными сторонами, если дата сдачи под угрозой.
Менеджеры проектов, как правило, стремятся обеспечить предсказуемость сроков путём стандартизации и соблюдения цикличности процессов. В этих процессах основное внимание уделяется отчётности по статусам, чтобы отслеживать прогресс. Общепринятое мнение, что чем тщательнее отслеживать процессы, тем более предсказуемым станет график проекта, и тем выше вероятность, что проект сдадут в срок.
Проклятие менеджера проекта — качество оценок по срокам, которые они получают от команды. Эти оценки могут дико варьироваться. Как правило, они отличаются от человека к человеку, и может потребоваться ежедневное обновление. Такая круговерть в оценках в конечном счёте может сделать невозможным определение сроков сдачи проекта, но от менеджера ждут твёрдой даты. Когда эти сроки в итоге пропускаются, менеджер должен найти способ объяснить, почему сроки пропущены, не делая крайними сотрудников, непосредственно ответственных за пропущенный срок. Недостаточная дипломатия в этой области часто приводит к тому, что сотрудники обвиняют руководителя проекта в том, что он «бросает их под поезд», независимо от точности своих предыдущих оценок.
Ниже приведены проблемные личности среди менеджеров проектов:
Руководитель проекта, который считает, что все проблемы проекта вызваны отсутствием связи и координации, а решением станет обильное количество собраний.
Теоретически, на собраниях люди собираются, чтобы обсудить варианты и принять решение. На самом деле такое случается редко. Планировщик собраний не в курсе этого феномена и старается планировать встречи как можно чаще, с как можно большим количеством людей. Он искренне полагает, что это улучшит сотрудничество в коллективе: в его сознании прочно укрепилась мысль, что для успеха проекта не хватает общения.
Менеджер такого типа усугубляет три основные проблемы, свойственные подавляющему большинству собраний:
Планировщик встреч не представляет серьёзной угрозы для проекта, потому что сотрудники обычно не ходят на собрания, которые вредят их производительности. Поэтому работа продолжается, несмотря на постоянные собрания.
Такого менеджера проекта можно исправить с помощью простой инструкции:
Собрания необходимы для выполнения проекта, но главное:
Как только планировщик собраний поймёт это, его поведение сразу изменится к лучшему.
Руководитель проекта, который занимается только созданием списков и проверкой пунктов, независимо от их содержания.
Завершение любого проекта требует двух обязательных шагов:
Руководитель проекта типа статистик пришёл к выводу, что ведение этого списка представляет собой всю полноту его должностных обязанностей. Он не обеспокоен тем, что находится в списке. Только тем, что в нём есть пункты и что они проверяются предсказуемыми темпами. Статистик не оценивает и не предлагает какого-то критического подхода к тому, что представляют собой пункты списка, а вместо этого полагается на других, сообщая им содержание пункта и срок выполнения.
Наибольшее беспокойство у такого менеджера вызывает то, что его работу может выполнить программное обеспечение для управления проектами. Таким образом, он становится не нужен. Часто статистику дают вести проекты в такой программе, и он очень тщательно поддерживает информацию в актуальном состоянии. Сам проект может быть в руинах, команда может выпустить совершенно не тот продукт с опозданием на месяцы и низкого качества, но пока всё должным образом документируется, статистик не видит проблем.
К счастью, если статистик только ведёт списки и вычёркивает пункты, он не наносит никакого вреда проекту, если не учитывать его неосведомлённость об истинном положении дел. Главная проблема заключается в том, что статистик может быстро мутировать во что-то гораздо худшее.
Статистика трудно исправить, потому что его внимание к деталям по своей природе глубоко укоренилось, вполне возможно, с детства. Если кто-то считает списки важными, он внезапно не изменит свое
Ключевой навык, которого не хватает статистику — навык работы с людьми. Менеджер скорее взаимодействует со списком, чем с людьми. Предложите им вживую поговорить с людьми о том, что они делают и почему, а не просто запросить список пунктов. Впрочем, в случае плохого исполнения статистик может скатиться до микроуправления (см. неуверенный [9] менеджер).
Наконец, попросите написать резюме из одного параграфа о статусе проекта, а не показывать результат в виде списка пунктов. Это заставит их более целостно представить проект.
Менеджер настолько оторван от реалий проекта, что даёт ложную информацию заинтересованным сторонам.
Основная обязанность менеджера — сообщать о состоянии проекта. Это называется «установкой ожиданий», а «соответствие ожиданиям» — мерило, по которому определяется успех проекта. Хороший менеджер проекта устанавливает ожидания на основе сочетания количественных и качественных данных, а также собственного профессионального опыта. С другой стороны, заблуждающийся менеджер основывается исключительно на своих инстинктах.
Ниже приведены ключевые фразы, которые позволяют распознать витающего в облаках менеджера проекта:
Обратите внимание на использование «я» и «мы» — это хорошие маркеры, что восприятие менеджера основано на субъективных впечатлениях, а не на собранных и проанализированных данных.
Важно отметить различие между заблуждающимся менеджером, пессимистом [4] и оптимистом [5]:
Это одна из немногих личностей, способная самостоятельно загубить целый проект. Если такой менеджер часто встречается с заинтересованными сторонами, то следует повысить бдительность, потому что может произойти следующее:
К счастью, такого менеджера можно исправить в два действия:
Зачем просить сформулировать, что он чувствует? Это поможет ему понять, что суждение основано не на чём-то материальном, а на субъективной оценке, то есть на чувствах. Жизненно важно, чтобы он пришёл к этому выводу самостоятельно — не нужно говорить, что у него плохие инстинкты. Продолжайте спрашивать «Почему ты так думаешь?», пока не достигнете прорыва.
Как только до менеджера дошло, покажите ему твёрдые факты о проекте. Например, если он говорит «Качество продукта никуда не годится», представьте график, показывающий неуклонное снижение количества багов в течение последних нескольких месяцев. Если он говорит «Мы будем готовы в срок», представьте список неполных задач и обычное время выполнения задач, которое доказывает обратное. На данном этапе это должно быть просто вопросом, чтобы разум и логика менеджера взяли верх. Если он остаётся в иллюзиях, повторите процесс столько раз, сколько необходимо.
Менеджер, который уверенно говорит в неудаче проекта, и его невозможно убедить в обратном.
Большинство проектов разработки ПО можно назвать неудачными с какой-то стороны:
В реальном мире этого можно ожидать, а иногда воспринимать как неизбежную реальность. Но пессимист предъявляет такие высокие требования, которым проект не может соответствовать, поэтому он объявляет его провал задолго фактической неудачи проекта.
Пессимиста легко выявить по двум ключевым характеристикам:
Такая позиция может убедить начальство, что проект безнадёжен, и его действительно отменяют.
Менеджера-пессимиста невозможно исправить, так как он часто несчастлив в личной жизни, недоволен работой, карьерой или самой компанией. Таким образом, его негатив не имеет ничего общего с самим проектом, а представляет личную проблему. Лучшее, что можно сделать, это предложить психологические консультации, на что идут немногие компании. Это приводит к часто неизбежному результату: менеджер либо сам уходит, либо компания его увольняет.
Руководитель проекта, который убедил себя в успехе проекта, независимо от доказательств обратного.
Как правило, людям нравится работать с позитивными людьми. Недостаток менеджера-оптимиста в том, что его позитивное мировоззрение не даёт понять предупреждающие знаки на проекте. Вместо того, чтобы принять меры для устранения проблем, он предпочитает игнорировать эти знаки, считая их нездоровым негативом, и вместо этого предпочитая сообщать только о хорошем. Это порождает культуру самоуспокоенности или уныния среди членов команды, в то время как начальство пребывает в иллюзии, что всё идет хорошо.
На любой руководящей должности оптимизм перед лицом невзгод — важное преимущество. Чтобы отличить менеджера-оптимиста от смелого лидера, используйте следующие тесты:
Менеджер-оптимист часто становится причиной провала проекта, поскольку он игнорирует проблемы, которые могут привести к провалу. Чем дольше идёт проект, тем хуже эффект.
Оптимиста легко спутать со смелым лидером, вот почему их редко выявляют, а поэтому и редко исправляют. К тому времени, когда личина оптимиста проявляет себя, часто бывает слишком поздно, так как проект уже провалился.
Организации стремятся продвигать смелых лидеров. В результате, менеджер-оптимист имеет более высокие шансы продвижения по службе, если может убедить начальство в том, что проект провалился по причинам, не зависящим от их контроля.
Независимо от причин, почему менеджер так себя ведёт — для личного карьерного роста, не желая сталкиваться с неудобной правдой или просто по наивности — ущерб проекту одинаков. Разница лишь в том, повышают его или увольняют.
Менеджер проекта, который фокусируется на том, чтобы все программисты были счастливы, а не на успехе проекта.
Высокий моральный дух важен для любого проекта: разработчики обычно более креативны и продуктивны, когда моральный дух высок. Когда проект идёт плохо, естественно, моральный дух падает, пока ситуация не улучшится. В это время вместо решения проблем проекта капитан команды занимается улучшением морального духа.
У капитана команды и оптимиста [5] общим является позитивный настрой, однако его проявление принципиально отличается:
Капитана команды очень легко обнаружить:
Такой человек кажется идеальным менеджером проекта, но есть две причины для беспокойства:
Таким образом, капитан команды в конечном итоге всем нравится, но на самом деле не выполняет работу менеджера проекта.
Основная проблема заключается в том, что у капитана команды обычно нет большого опыта в качестве менеджера проектов. Поэтому решение состоит в его обучении. К счастью, есть огромное количество обучающих ресурсов для менеджеров проектов.
Предоставив менеджеру необходимый инструментарий, нужно поощрить его к выявлению коренных причин низкого морального духа, а затем их исправлению. Принимая во внимание естественную склонность капитана команды улучшить настроение сотрудников, он наверняка предпримет агрессивные попытки найти и исправить коренные причины падения морали, как только поймёт, что искать.
На этом этапе вы получаете менеджера проектов с очень мощной смесью мотиваций: во-первых, он использует мораль как мерило проблем в проекте, во-вторых, он находит эти проблемы и исправляет их. Поскольку его мотивация исходит из сострадания к ближнему, то проблемы, лежащие в основе низкой морали, будут быстро искоренены.
Кстати, в их характере быть добрым к другим, поэтому маловероятно «вылечить» их от этой составляющей, и их «исправление» не должно подразумевать устранение положительных частей характера. В конце концов, если и возможно повысить уровень менеджера проектов, то сложно найти лучший вариант для таких инвестиций, чем капитан команды.
Менеджер, который относится к членам проекта с презрением во имя их мотивации больше работать.
В проектах по разработке программного обеспечения обычно участвует множество сильных личностей, но все должны быть подчинены одной цели каждый и сфокусированы на реализации проекта. Поэтому у менеджеров проекта есть полномочия руководить участниками проекта, чтобы обеспечить успех проекта. Тиран злоупотребляет этими полномочиями, используя негативное подкрепление для достижения результатов.
В то время как тиранов могут не любить, начальство часто считает, что их «твёрдая рука» — именно то, что необходимо для успеха проекта, особенно если тот отстаёт от графика. Угрозы и наказания в самом деле действуют как мотиватор для многих типов личности (см. разработчик типа солдат [11]), что способствует распространению тиранов.
Фактические проблемы с тиранами сложно обнаружить, но они невероятно вредны для проекта.
Чем дольше работает тиран, тем более драматичной будет эта медленная утечка талантов. В конце концов, как только все компетентные участники проекта изгнаны, станет невозможно пригласить в проект талантливых и опытных участников, так как потенциальные сотрудники не захотят работать с некомпетентной командой (факт легко всплывает во время собеседования).
Важно отметить, что тирана обычно вводят в проект в самый неподходящий момент: когда проект в беде. Проекты под угрозой неудачи должны сбрасывать некомпетентных членов команды, сохраняя при этом компетентных, но тиран вызывает совершенно противоположный эффект.
Чтобы исправить тирана, нужно довести до его сознания, что такое поведение негативно влияет на проект. Для этого существует два общих подхода:
Во-первых, представить количественные данные, отражающие их стиль управления проектом:
При сравнении этой информации особенно эффективны графики по времени.
Во-вторых, сообщите им, какие показатели ожидаете в ближайшем будущем. Скорее всего, они проявят раздражение и безнадёжность, поскольку не знают, как улучшить эти показатели. Но это идеальная возможность предложить им совет и обучение, как стать лучшим менеджером. Обучение должно охватывать следующее:
При условии, что есть подходящий специалист для такого обучения, то менеджерв-тирана можно полностью исправить, потому что следующие характеристики естественно присущи человеку:
Главное, чтобы команда приняля новый подход, несмотря на репутацию тирана в прошлом. Проблему можно решить очень просто, например, созвать собрание с темой «Я сожалею» и «Я изменился к лучшему».
Менеджер настолько одержим процессом, что забывает о своей задаче — помочь в достижении проектом успеха.
По окончании любого учебного курса или прочтении люьбой книги по менеджменту каждый менеджер рискует стать одержимым процессом. Это может случиться даже с лучшими, поэтому при их исправлении важно проявить терпение.
Есть две обширные категории процессов, в отношении которых проявляется одержимость:
Возможно, учебный курс или книга иначе именовали эти процессы, но вы можете легко можете поместить их в правильную категорию, применив следующий тест:
Цель любого менеджера — сдать проект в срок и в рамках бюджета. Процесс, который мы используем, облегчает это. Когда руководитель проекта становится одержимым, он может игнорировать основную цель, а вместо этого зациклиться на вопросе «Правильно ли идёт процесс?» в ущерб другим должностным обязанностям.
Что бы вы ни делали, не пытайтесь отнять у них процесс или оспорить его. Dы имеете дело скорее с религиозным фанатиком, чем рациональным человеком. Он убедил себя, что его процесс «исправит» проект. Если они считают, что проект «сломан», а вы попытаетесь сказать «это нам не поможет», они просто посчитают вас частью причины, по которой проект сломан.
Одержимого процессом исправить легко: просто соглашайтесь на всё, что он говорит, мягко напоминая, что «требуется время, чтобы повернуть большой корабль» и «Рим не строился за один день». Смысл в том, чтобы заставить его согласиться на реализацию нового процесса с помощью серии небольших нововведений, а не кардинального изменения. Это позволит им на собственном опыте узнать, какие методы эффективны, а какие нет. Приобретая этот опыт, они научатся адаптировать процесс к ситуации на местах. Есть надежда, что они поймут: процесс является средством достижения цели, а не самоцелью.
Менеджер проекта, который постоянно запрашивает текущий статус у сотрудников, считая это необходимым, чтобы те фокусировались на выполнении своих задач.
Когда менеджер сидит за своим столом вдали от участников проекта, выполняющих работу, то у него легко может сложиться чувство собственной бесполезности. Это заставляет их предпринять всё необходимое, чтобы почувствовать себя нужным и полезным. Для неуверенного менеджера наиболее очевидный способ показаться продуктивным — проверить текущую работу сотрудников. Это часто достигается с помощью следующих методов:
Неуверенный менеджер широко известен под другим названием: микроменеджер. Его методы управления проектами интерпретируются членами команды проекта как любой или всё из следующего:
Часто у сотрудников развивается глубокое негодование на неуверенного менеджера проекта, потому что в их восприятии:
Это восприятие порождает противостояние менеджера проекта и разработчиков, подавляет полезное общение, которое менеджер мог бы использовать для исправления реальных проблем. Вместо того, чтобы взаимодействовать с таким менеджером для сотрудничества и кооперации, разработчики избегают каких-то дополнительных контактов с ним, опасаясь, что у них (ещё раз) запросят статус.
Неуверенный менеджер — настолько распространённое явление, что подобное поведение считается основной рабочей обязанностью менеджера. Предполагая неизбежное, большинство разработчиков формируют определённый порог, как часто у них будут спрашивать текущий статус. Поскольку большинство научились приспосабливаться к постоянному преследованию о статусе, неуверенный менеджер не представляет высокого риска для проекта, хотя он лишает команду возможности полезных коммуникаций, которые могли бы состояться в противном случае.
Такой менеджер рождается из-за того, что производительность команды недостаточно хорошо ему видна. Таким образом, решение заключается в размещении этого менеджера рядом с командой. В противном случае этого менеджера одолевает желание напрямую спросить статус у каждого разработчика. Если же они находятся рядом, то менеджер может понять текущее состояние проекта, просто подслушивая разговоры разработчиков между собой. В этом режиме менеджер наиболее эффективен, поскольку потребность вмешаться возникает у него только когда производительность действительно затруднена.
См. также «Проблемные личности среди разработчиков» [18]
Автор: m1rko
Источник [19]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/300898
Ссылки в тексте:
[1] Планировщик собраний: #1
[2] Статистик: #2
[3] Заблуждающийся: #3
[4] Пессимист: #4
[5] Оптимист: #5
[6] Капитан команды: #6
[7] Тиран: #7
[8] Одержимый процессом: #8
[9] Неуверенный: #9
[10] автор патента: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/product-managers/the-patent-author/
[11] солдат: https://habr.com/post/431534/#10
[12] мышление: http://www.braintools.ru
[13] оптимистом: https://habr.com/post/431534/#8
[14] алармист: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/quality-assurance/the-alarmist/
[15] миротворец: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/development-managers/the-peacemaker/
[16] слон в посудной лавке: https://habr.com/post/431534/#6
[17] диктатор: http://neilonsoftware.com/books/personality-patterns-of-problematic-projects/product-managers/the-dictator/
[18] «Проблемные личности среди разработчиков»: https://habr.com/post/431534/
[19] Источник: https://habr.com/post/431802/?utm_source=habrahabr&utm_medium=rss&utm_campaign=431802
Нажмите здесь для печати.