Дискуссии на тему “где же менеджер в agile” ведутся давно, а чем конкретно занимается менеджер проекта продолжает интересовать людей и сейчас. Ответ же прост и одинаково формулируется и в диамате и в project management – “it depends”. И вот от чего.
Менеджер проекта отвечает за успех проекта. Но достигает или не достигает успеха команда. Если упростить модель реальности, в которой существует команда, то она обладает строго двумя характеристиками – она может мочь (или не мочь) достичь успеха и хотеть успеха проекта (или он может быть ей параллелен). Именно это и определяет необходимое поведение менеджера на проекте. Нарисую это схемой.
Под “способностью сделать этот проект” я в данном случае подразумеваю наличие всего необходимого набора знаний, навыков, инструментов, полномочий для того, чтобы иметь возможность придти к успеху. Соответственно при отсутствии способности от менеджера требуется активное вмешательство с разъяснениями, наделением полномочий, научению пользованием инструментами и так далее. Под “желанием сделать этот проект” я подразумеваю наличие морального духа на выполнение этого проекта (совпадение целей\интересов человека (его мотивов) и целей проекта). Соответственно от менеджера при отсутствиии морального духа требуется четкий и постоянный контроль, расстановка промежуточных точек и бдительный их контроль.
Таким образом поведение менеджера определяется сочетанием этих двух факторов. При ответе на каждый из вопросов “да\нет” мы получаем всего 4 возможных варианта поведения менеджера:
- Способности нет, желания сделать нет. Требуется постоянное руководство, активное вмешательство, постоянный контроль, “надзирание”. В литературе этот стиль называется, если не ошибаюсь, directing. Agile здесь невозможен. Сами такие люди не являются командой по канону agile – так как самоорганизация в такой среде – это нонсенс ин бэйсик. Единственная организующая сила в такой обстановке – сержант Хартманн.
- Способностей нет, но желание есть. Контролировать то, что человек работает, а не курит, не надо, но вот учить его придется постоянно. Впрочем, делать это легко и приятно, так как он сам хочет учиться. В литературе называется coaching. В agile есть такая роль – agile coach. Собственно, этим все сказано.
- Способности есть, но желания нет. Учить не надо, но контролировать надо очень жестко. И контрольные точки расставлять самому. И статус выбивать. И дисциплину поддерживать. Это называется controlling. Это не agile. И вместе с тем это то, что представляет собой менеджер в 90% софтверных контор. Естественно, зачастую он как надзиратель и двигатель прогресса имеет специальный бонус – ибо платить бонус ему дешевле чем искать ключики к удовлетворению целей команды.
- Способности есть и желание есть. Идеальный случай. Просто скажи что нужно. Народ организуется сам. Это и есть agile. Именно в таком случае менеджер действительно не создает никакой дополнительной полезности в команде, это называется delegating. Это та самая самоорганизующаяся agile-команда. Единственная задача менеджера – ее создать. Нет, даже вот так: Единственная задача менеджера – ее создать.
- Вот тут обычно следует вопли “ну как жеж ее такую создашь! где взять таких людей! такая удача бывает раз в сто лет!”.
- Точно. Такая удача – бывает раз в сто лет. Опытных людей вам никто не даст. Найти опытных людей, которые хотят делать ваш проект, да еще выдернуть их на него – это антинаучная фантастика, так не бывает.
- Поэтому единственный вариант получить ее скорее – это сделать своими руками. Можно найти людей, которые хотят делать ваш проект. Но затем их придется учить. То есть ваша дорога не пройдет мимо того, чтобы быть тренером ваших людей.
- В свое время я побыл сержантом Хартманном, и надзирателем на плантации, и захотелось вместо этого поделегировать умным людям. Чтоб ставишь задачу – и получаешь на выходе решение.
- Только естественно никто их не давал. Поэтому приходилось из добровольцев их выращивать. А для этого – учиться учить. И до сих пор я люблю открывать проекты буткэмпом, в котором на тренировочных задачах отрабатывается процесс и вырабатывается понимание. Хотите создавать свои команды – тогда вам придется этому научиться.
- Ну а если вы хотите стать agile coach’ем для своей команды или компании – научиться проводить такие воркшопы ваша первейшая обязанность.
P.S. Этот пост взят с thetorch.ru
Классная статья
Мне только один момент показался немного противоречивым.
Насколько я понял основную идею и посыл - идеальных условий для agile вам никто не даст, можно только самому их себе создать. А потому – активнее осваивайте agile coaching (в частности, с помощью небезызвестных тренингов
)
Но с другой стороны, в пункте 3 справедливо утверждается, что в 90% случаев есть проблема с мотивацией команды - люди, в принципе, способны делать проекты, но по разным причинам не горят желанием делать это. Хоть ты им agile предлагай, хоть waterfall – ну, нету у них желания напрягаться. Не следует ли отсюда, что при всем уважении к agile coaching гораздо более важной и базовой задачей является умение выстроить систему мотивации таким образом, чтобы народу хотелось работать? И, получается, не agile коучем тебе, Денис, надо было становится, а компанию свою создавать