Как сделать свою команду несчастной. Популярные антипаттерны управления проектами

Менеджеры обладают всеми возможностями, чтобы заставить команду страдать

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

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

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

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

«Белка в колесе»
«Миллион Agile-встреч»
«Гантаголик»

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

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

Вот как это работает:

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

Преимущества такого подхода

Работа таким образом — это сборочный конвейер, а не работа над решением проблем. Такой подход приводит к тому, что разработчики отвлекаются от потребностей клиентов, которые они должны удовлетворить. Это подталкивает к поверхностным и неполным решениям. Можно закончить задачи, но не решить проблемы.
Работа с задачками может отбить у людей охоту оспаривать или думать о работе, которую они выполняют. Это препятствует инновациям и свежему мышлению.
Если у вас есть какая-либо исследовательская работа в рамках проекта, или сам проект может быть изменён (как чаще всего бывает в работе с продуктом), ваша подробная декомпозиция становится обузой: вы накопили огромный бэклог задач, который теперь необходимо переработать. Великолепная трата времени!
Часто этот подход существует без упорядоченного процесса декомпозиции, поэтому в итоге задачки создаются по ходу дела. Это приводит к тому, что вы понятия не имеете, сколько времени займёт их выполнение или насколько хорошо вы справляетесь. Вы будете работать, как проклятый, или вас проклянут, если вы их не сделаете! Гениально!
Этот подход также побуждает менеджера проекта сосредоточиться на «сгоревших баллах» и механических оценках, основанных на историях в Jira. Это неплохо работает при хорошо декомпозированных задачах, но зачастую есть факторы риска или неопределённости, которые не учтены. Такая самоуверенность может основываться на ложных оценках.
Ещё одна распространённая ошибка заключается в том, что команды просто не планируют свою работу. Они не думают о том, что может пойти не так. Они не планируют накапливать опыт. Они не продумывают контуры проекта. Слишком много работы в противовес простой шлифовке тикетов в Jira.

Как видите, это очень эффективный способ демотивировать вашу команду.

«Белка в колесе» может сработать против ожиданий

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

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

Если вы действительно злой менеджер, вам нужно знать больше вариантов. Этот второй способ управления проектами непременно разозлит вашу команду! Этот подход повторяет форму Agile, но делает его тяжеловесным. Я называю этот подход «Миллион Agile-встреч».

Подход таков:

Проводите встречу по обработке бэклога (со всей командой). Пройдитесь по каждому пункту в списке задач всей группой.
Проводите ежедневные стендапы. Пройдитесь по каждому пункту плана спринта и попросите каждого участника обсудить сценарий. Обычно речь идёт о работе, которую вы сделали и планируете сделать, а также о препятствиях. В идеале это займёт час, лучше полтора, каждый день.
Проводите встречу по планированию спринта (со всей командой). Планируйте работу за рамками спринта. Подробно пройдитесь по каждому пункту и убедитесь, что все его понимают. Если вы всё делаете правильно, это должно занимать не меньше половины рабочего дня раз в неделю.
Проводите встречу по оценке проекта. Обычно это включает в себя использование Agile-покера для оценки каждой задачи и обсуждения любых разногласий. Бонус, если вы оцениваете вещи, над которыми, возможно, даже не будете работать!
Проводите демонстрационную встречу. Каждый должен продемонстрировать свою работу. Хотя это могут быть полезные демонстрации, мы имеем ещё одну встречу.
Проводите ретроспективу спринта после каждого спринта. Отличная практика, но ОМГ, ещё одна встреча?!

Преимущества миллиона Agile-встреч

Одним из самых больших преимуществ этого подхода является то, что он создает кажущееся равноправие. Все знают обо всем, все во всем согласны. Это прекрасное прикрытие для вашего коварства!
Почти всё, что делает команда, происходит последовательно. В итоге это занимает ОЧЕНЬ много времени. Аргумент в пользу того, чтобы соблюдать последовательность, заключается в том, что таким образом создаётся контекст между встречами. Такой общий контекст ценен (и может помочь команде почувствовать удовлетворение от своей работы)! К счастью, встречи можно сделать настолько скучными, что никто не выстроит контекст.
Миллион встреч работает особенно хорошо, если вы используете небольшие задачи. Таким образом, управленческие расходы для вашего процесса многократно умножаются. К счастью, большинство команд используют в своих задачах и требованиях точную детализацию, что идеально подходит для данного подхода. Это означает, что команда, по сути, пробирается через огромную очередь, чтобы определить, над чем работать каждую неделю, и создаёт контекст для вещей, которые на самом деле не так важны в данный момент.
Встречи обязательно синхронизируются, что может быть проблематично в удалённой команде или организации, распределённой по часовым поясам.
Неэффективность такого способа работы может привести к отчуждению. Членам команды будет казаться, что они посещают миллион совещаний, но не могут решить ни одной проблемы. Заставьте их чувствовать, что встречи бесполезны, чтобы сотрудничество с товарищами по команде относительно даже важных проблеме стало похоже на пытку!

Недостатки миллиона встреч

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

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

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

Последнее и наименее важное — это управление проектами, основанное на диаграммах Ганта. Такой подход обычно применяется теми, кто плохо знаком с управлением проектами. Они много читают о методах управления проектами и применяют их в разработке программного обеспечения. Это может причинить много боли!

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

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

Менеджер проекта строит диаграммы Ганта или диаграммы PERT и использует программное обеспечение для управления проектами или сложные электронные таблицы для управления задачами.
Каждую неделю они тратят много времени на проектирование и поддержку своих моделей.
Они запрашивают у команды оценки всего, чтобы собрать информацию, необходимую для их моделей. (Это часто идёт рука об руку со сложностью получения оценок.)
Они часто ведут список рисков. . . и журнал решений.

Преимущества управления проектами «гантоголиком»

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

Большинство проектов в области разработки продукта имеют большое количество изменений или неопределённости. Гантоголическое планирование плохо поддаётся изменениям. Оно обладает точностью, но оно не калибруется. Исследования или изменения в проекте трудно учесть, потому что они оцениваются индивидуально.
Поскольку план очень сложен, он требует значительных усилий, чтобы справиться с неизбежными изменениями. Это подталкивает к тому, чтобы сделать план более жёстким, чем должно быть, чтобы скомпенсировать высокую стоимость изменений. Такая негибкость может неестественным образом исказить результаты проекта, а также привести к тому, что реальная работа будет скрыта от модели или не учтена. Для оценки изменений может потребоваться некоторое время, поскольку время для построения нового плана также имеет стоимость. Обычно трудно экспериментировать с вариантами плана: поскольку менеджер проекта зависит от любых изменений плана, а план требует большого времени для обновления, гибкость такого планирования сводится на нет.
Поскольку такой подход основан на моделировании, оценки обычно вычисляются. Это приводит к плавающим значениям по каждому показателю.
Руководителю проекта приходится тратить много времени на управление моделью (иногда даже отнимая его от управление самим проектом).
Обычно менеджер проекта — единственный человек, который может обновлять модель, поскольку она слишком сложна для понимания кем-либо ещё. Это означает, что менеджер не может уйти в отпуск, не потеряв управляемости проекта.
Требуемый уровень детализации означает, что команде приходится тратить много времени на оценку задач.

Недостатки управления проектами «гантоголиком»

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

Иногда вы можете счесть нужным проявить милосердие к командам, которые вы угнетаете. В этом случае можно почитать о безболезненной альтернативе описанным стилям управления проектами, например, о так называемой демо-разработке (demo-driven development).

Еще больше статей от ИТ-экспертов на портале Cleverics Digital Enterprise

Полная линейка аккредитованных курсов ITIL4 и авторские курсы Cleverics на основе ITIL4 (Value Added Product)

Полноценная авторская линейка курсов по Agile: кратко, по делу, без евангелизма и холиваров

Курсы по ITAM, TOGAF, PRINCE2

Деловые игры для ИТ-департаментов