Я предполагаю, что вы технический руководитель.

Спросите о приоритетах

Как только вы узнаете список дел, отправьте электронное письмо своему менеджеру:

Привет, [Имя] (или Здравствуйте, мистер (ы) [Имя] , если вы не так близки)

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

С уважением,

[Бла-бла]

(вы также можете представить список приоритетов и попросить согласия)

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

Прекратите работать в «сумеречной зоне»

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

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

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

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

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

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

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

• Как вы знаете, мы взяли на себя больше, чем могли сделать, поэтому нам пришлось расставить приоритеты X, Y и Z.

• Как вы помните, я упомянул, что мы не сможем сделать больше, чем X, и что мы сможем сделать Y только в том случае, если значительно опередим график.

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

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

• Насколько я понимаю, X и Y считались статистами, которые мы взяли бы на себя, если бы у нас еще оставалось свободное время. Наша первоначальная оценка/цель была довольно точной, поэтому мы не смогли принять эту.

• Я не уверен, что понимаю, вы сказали, что это растянутые мишени, верно? Мы сосредоточились на основных целях (X, Y и Z), и они выполнены, но у нас не было времени заняться дополнительными задачами.

Если вы используете гибкую модель доставки, вам может помочь использование жаргона:

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

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

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

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

Бизнес должен определить приоритеты рабочей нагрузки с менеджером проекта.

Я не могу рекомендовать перегружать спринт (потому что, если вы не выполняете то, что было согласовано, это противоречит цели планирования и Agile). Если истории не доставляются вовремя, ответственность в конечном итоге ложится на менеджера по проектам.

Кроме того, предполагая, что продакт-менеджер разумен (и знает, как работать в Agile), он должен знать, что если что-то добавляется в спринт, то что-то еще должно быть удалено — это также его ответственность.

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

Редактировать: просто перечитал ваш пост - « растягивающая цель » совершенно нормально. Это просто означает, что если команда завершит всю работу спринта, вы сможете добавить дополнительную работу... но только если вы закончите то, что было согласовано. Редко бывает, по моему опыту.

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

Как технический руководитель, вот несколько советов по улучшению:

• Требуйте, чтобы любые запросы на завершение «Больше баллов» были конкретными запросами о том, какие истории они хотят видеть в приоритете над текущей работой.
• Объясните, что вы выполняете работу в соответствии с ее приоритетом на доске. Что ваша команда работает настолько быстро и усердно, насколько это можно разумно ожидать, и что если у менеджера проекта есть опасения по поводу того, что конкретные члены команды не справляются со своей задачей, он должен обратиться к тем, кто находится с руководителем группы.
• Предложите, что если ваш PM хочет, чтобы количество очков MVP увеличилось, лучшим способом было бы увеличить размер команды. Обратите внимание, что если у вас надвигается крайний срок, то этот вариант нецелесообразен. Если у вас остались месяцы работы, то да.
• Когда ваш продакт-менеджер пытается сделать что-то, выходящее за рамки Agile-методологии вашего бизнеса, вы объясняете продакт-менеджеру, что он делает, почему это проблема и как правильно решить его проблемы в рамках используемой методологии.

Назвать вещи — половина дела.

Не называйте их «целями растяжки», постоянно называйте их «подготовкой к следующему спринту». Если вам зададут прямой вопрос, вы можете сказать: «У нас нет целей в agile, у нас есть прогнозы, и нет такой вещи, как расширенный прогноз».

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