Суперцитата от Александра Орлова

Александр Орлов, как всегда, радует грамотными цитатами великих умов :) На этот раз в очередной раз попал в яблочко с моими текущими проблемами со своей цитатой Генри Форда:

"Я лучше нанял бы человека с энтузиазмом, чем человека, который все знает."

Человеки с энтузиазмом - приходите к мне на собеседование. Вы мне сейчас так нужны!

Коммуникации с заказчиком. О сборе требований.

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

1. Правила хорошего слушания

• Перестаньте говорить
• Помогите говорящему раскрепоститься
• Покажите, что вы готовы слушать
• Устраните раздражающие моменты
• Сопереживайте говорящему
• Будьте терпеливы
• Сдерживайте свой характер
• Не допускайте споров и критики
• Задавайте вопросы
• Улыбайтесь
• Проявляйте искренний интерес

2. Восприятие информации

• На слух - 15%
• На глаз - 25%
• Аудио + Видео + Кинестетика - до 65%

По большому счету пункт 1 - это весьма вольное изложение идей активного слушания, о котором столько спето песен :) Активное слушание я люблю, стараюсь его активно использовать, так что авторы доклада молодцы, что затронули этот аспект. А вот пункт 2 будет вам гарантированно полезен если придется доказывать необходимость on-site визита к заказчику для уточнения требований или, напротив, для on-site визита к удаленной команде где-нибудь в Белоруссии для популярного выноса в массы идей проекта.

К слову сказать, мой последний проект показал на практике, что on-site визит - это просто волшебная штука и фактически must have во всех ситуациях, где вы делаете что-то хоть немного нетривиальное. Ну и не надо говорить, что особенно здорово, когда заказчик располагается в Вегасе, на Гавайах или хотя бы в Риме :)

Удачных вам проектов и непротиворечивых требований!

AD закончился...AD впереди

Отшумел, отговорил и отвыступал ADский сентябрь в Питере! По правде сказать, для меня это была весьма противоречивая конференция - с одной стороны, я познакомился с массой интересных людей, увидел и даже (хе-хе) потрогал живого Scrum-Coach, обсудил свои идеи и получил подтверждение того, что я на правильном пути (иногда это очень необходимо)...с другой стороны, только за день до этого я прилетел назад из командировки на другом конце земли и меня накрыло акклиматизацией по полной программе так, что я стал засыпать практически каждый раз, когда занимал неподвижную позицию :) т.е. : на докладе Девида Хассмана, на докладе Дэна Рострома, на окне, в кресле,...только беседа с Сергеем Дмитриевым (великим и ужасным :) dmitriev.com) не давала заснуть - спасибо ему за это огромное!
По этой же причине мой собственный доклад "Scrum-Master - кто ты?", задуманный как интересный, провокационный и яркий получился, на мой взгляд, скомканным и недостаточно выразительным... Сделаем зарубку на будущее - обратная акклиматизация исключает публичные выступления и эффективное общение :)
Зато у меня придумалась тема для выступления на московском AD'10. Думаю, что я ее обкатаю сначала в виде статьи в этом блоге (как и было с докладом про Scrum-Мастера)...тема интересная, как всегда провокациями :)

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

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

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, исповедующим (явно или лучше неявно) принципы дзен :)