Нужна помощь!

Привет! Если кто-то все же читает этот блог - обратите внимание, что нашему коллеге - Владимиру Левчуку нужна помощь. Если коротко - рак. Все кто хотел бы помочь отцу троих замечательных детей и просто хорошему человеку - заходите на ЖЖ Владимира и сами решайте, как Вы лично можете помочь...

Manager 2.0

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

"Проще говоря, менеджер в Scrum не столько 'нянька' для команды, а скорее ментор и гуру, помогающий им учиться, расти и продуктивно работать. Это и есть переход от Manager 1.0 к Manager 2.0"

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

Помимо примеров и идей о "новом" менеджере, в статье приводится анализ обязанностей менеджера, которые "дружат" и "не дружат" со Scrum-ом. Осень хороший анализ, которые несколько отличается от анализа по PMBook, который в свое время делал Асхат Уразбаев на сайте ScrumTrek (или на AgileRussia...не помню).
Так что статься по-любому идет в must read для старых и новых менеджеров, из подчиненных и начальников :)

Сама статья: http://www.infoq.com/articles/scrum-management-deemer

Еще цитаты из Паркера

Вот еще немного цитат для размышления из книги Джеймса Паркера "Поступай Правильно". Книга настолько впечатлила, что для того, что бы вернуть ее владельцу надо уже, наконец записать их на-память :)

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

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

"Необходимо серьезно относиться к работе, но не стоит слишком серьезно относиться к себе"

"Зарплата не создает ощущения, что данная компания - ваша, а ее цели - ваши цели"

"Каждая возможность нанять нового служащего - это возможность улучшить команду или отправить ее ко дну"

думаю, достаточно цитат для одного поста...а что Вы извлекли из этой книги?

Шесть качеств Agile-команды. Анализ

Итак, давайте рассмотрим (возможно, даже критически) эти мистические качества члена Agile-команды, которые нам предлагали принять в предыдущем посте. Чем же выделяются такие люди:

1. Они готовы работать сообща
2. Не отказываются от помощи
3. Двигаются небольшими шажками и ориентируются на обратную связь(feedback)
4. Делают то, что нужно именно сейчас
5. Адаптируются к различным (не всегда привычным) условиям

6. Готовы работать вне своих ключевых навыков
Знаете, что интересно? Взглянув на этот список я вижу, что чем больше у разработчика опыт работы (в условиях традиционного менеджмента и процесса), тем хуже у него с этими навыками. Фактически, опыт в этой ситуации является главным врагом! Потому что наиболее профессиональные и опытные разработчики с которыми я сталкивался обычно обладают следующими чертами:

1. Яркие индивидуалисты, которые любят сконцентрироваться на своей задаче(области, технологии)
2. Они с сомнением относятся к возможности помощи со стороны коллег, так как прекрасно осознают, насколько они сам круты. Причем это распространяется и на ситуации, когда им нужна помощь в чем-то ином(например, отладка, поиск ошибки, выбор алгоритма и т.д.)
3. Они действительно рады уйти "в забой" на недельку и полировать свои торпеды до блеска, утверждая, что пока все не будет готово - показывать нечего. Просто у них есть собственные высокие критерии качества и они не готовы показать "недоделанный" код никому.
4. Они склонны к подходу BUFD (Big UpFront Design). То есть еще на этапе прототипирования они уже стараются ввести в архитектуру массу прикольных паттернов и решений, которые должны (в будущем) спасти систему от переделок.
5. Они по-хорошему избалованы. Ведь их ценность очевидна для работодателя и у них, зачастую, есть условия труда, которые их устраивают. Поэтому, попадая в зону дискомфорта(даже минимального, например, низкий уровень влажности в помещении) они весьма болезненно реагируют.
6. Им настолько "в кайф" заниматься своими любимыми технологиями или предметной областью, что они с огромным неудовольствием воспринимают любые идеи о кроссфункциональности. Не то, чтобы они не любят помогать коллегам. Но за ними водится привычка "отсылать к специалистам". Например, они лучше будут попинывать админов, чтобы те настроили выделенный домен и развернули там SQL-кластер чем сами займутся этим. Один из разработчиков объяснял мне это так: "Эта проблема не лежит в сфере моих профессиональных интересов и изучая администрирование WinNT домена я получу опыт и знания, бесполезные для меня в будущем"

Вот такая петрушка получается. Имея возможность поработать с менее амбициозными и "продвинутыми" разработчиками я с удивлением обнаружил, что идеи Agile ими принимаются гораздо более заинтересованно и с большим энтузиазмом. У них часто более острый и жадный ум. Им, черт побери, интересно все!(Или почти все :)) В то же время при наличии ума и правильной мотивации они со временем осваивают и рефакторинг и "правильные" архитектурные решения.
Вторая категория людей, которые воспринимают Agile дружественно находится в другой части шкалы - это уже состоявшиеся люди, которые со спокойным интересом смотрят на этот мир во всем его многообразии, принимая тот факт, что все вертится не вокруг их профессиональных навыков и карьеры. Иметь такого человека в команде по-настоящему здорово, так как он, без навязчивого скепсиса сможет слегка сдеарживать команду от слишком резких движений (например, влезать в рефакторинг без достаточного покрытия автоматизированными тестами).

Так что, соглашаясь с тем, что предложенные критерии действительно крайне желательны для члена Agile-команды, я хочу добавить еще предложение присмотреться к молодым энергичным разработчикам, а так же к их спокойным коллегам за 30, исповедующим (явно или лучше неявно) принципы дзен :)