Как сделать вашу команду несчастной: 3 анти-шаблона, которым (не) следует следовать

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

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

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

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

Три так называемых «антишаблона»

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

Три секретных антипаттерна:

1. Беговая дорожка

1. Agile на миллион совещаний

1. Ганттоголик

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

Задача беговая дорожка

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

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

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

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

1. Команда работает над этими задачами.

1. Каждую неделю вы переносите то, что не сделали.

1. В идеале, в конце у вас есть полностью законченная работа.

Преимущества беговой дорожки для задач

1. Работа таким образом — это конвейерная работа, а не работа по решению проблем. Это приводит к тому, что инженеры отвлекаются от проблем клиентов, которые они должны решать. Это приводит к поверхностным и неполным решениям. Вы выполняете задачи, а не решаете проблемы.

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

1. Если у вас есть какая-то исследовательская работа в рамках проекта, или проект может быть изменен (т. е. большая часть работы по разработке продукта), ваша подробная разбивка просто стала помехой — вы накопили огромное количество заявок, которые нужно быть переработанным. Прекрасная трата времени!

1. Часто этот подход осуществляется без дисциплины в процессе разбивки, так что в конечном итоге вы создаете заявки по ходу дела. Это приводит к тому, что вы понятия не имеете, сколько времени все займет или насколько хорошо вы справляетесь. Будь ты проклят, если ты сломаешься, и будь ты проклят, если ты этого не сделаешь! Гений!

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

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

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

Недостатки беговой дорожки задач

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

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

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

Agile на миллион совещаний

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

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

1. Проведите совещание для подготовки бэклога (всей командой). Пройдитесь по каждому пункту всей группой.

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

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

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

1. Проведите демонстрационную встречу. Каждый демонстрирует свою работу. Хотя это могут быть хорошие демонстрации, это еще одна встреча.

1. Проводите ретроспективу спринта после каждого спринта. Отличная практика, но, боже мой, еще одна встреча?!

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

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

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

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

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

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

Недостатки гибкой разработки на миллион совещаний

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

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

1. Этот подход хорошо помогает в создании общего контекста.

Управление проектами по методу Ганта

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

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

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

1. Менеджер проекта строит диаграммы Ганта или диаграммы PERT и использует программное обеспечение для управления проектами или сложные электронные таблицы для управления делами.

1. Каждую неделю они тратят много времени на управление проектом и поддержку своих моделей.

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

1. Они часто ведут список рисков. И журнал решений.

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

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

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

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

1. Поскольку он основан на модели, оценки обычно вычисляются. Это приводит к оценкам, которые колеблются повсюду.

1. Менеджеру проекта приходится тратить много времени на управление моделью (иногда даже отнимая у себя управление самим проектом).

1. Обычно руководитель проекта — единственный человек, который может обновлять модель, так как она слишком сложна для понимания кем-либо еще. Это означает, что они не могут уйти в отпуск, не потеряв при этом вашу способность управлять проектом.

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

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

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

Что лучше"?

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

Спасибо

Многие опытные инженеры дают полезные отзывы о первых черновиках этого поста. Спасибо Сету Фалькону, Бьорну Фримену-Бенсону и Кеничи Накамуре за многочисленные предложения по структуре и содержанию, которые сделали этот пост более сильным и целенаправленным. И спасибо Бренту Миллеру, Дэви Стивенсону и Дарину Суонсону за их улучшения!