13. Будьте осторожны в своих желаниях. Если ваш проект изменений будет успешен, то готовы ли вы взять на себя ответственность за то, что будет дальше?
Если вы захотите прочесть историю изменений, вдохновившую автора на эти советы, то можете найти ее онлайн на веб-странице [Shore2006]. Подробное руководство по изменениям изнутри содержится в книге More Fearless Change: Strategies for Making Your Ideas Happen [Manns2015].
Заинтересуйте команду
Agile ставит интересы людей на первое место, поэтому для вас не должно стать сюрпризом, что нужно получить согласие вашей будущей Agile-команды на то, чтобы попробовать новый подход. Можно заставить людей согласно кивнуть, стиснув зубы, но (и я говорю это, основываясь на моем нелегком опыте) это обычно приводит к потере кадров.
Когда меня просят помочь компаниям с внедрением Agile, я всегда разговариваю с каждой командой отдельно от ее руководителей. Нужно дать членам команды возможность высказаться в комфортных для них условиях, не опасаясь возмездия. Пригласите на встречу и коуча команды, и если вы сами руководитель, то начните разговор с того, что поддержите решение команды, каким бы оно ни было. Затем дайте людям поговорить с коучем без вас.
Вы или коуч можете сказать команде, что ее выбрали возможным кандидатом на тестирование Agile. Я обычно объясняю, почему руководство заинтересовано в Agile, какие выгоды он принесет организации и как это повлияет на членов команды лично. Я также объясняю, что изменение рабочих привычек – это стресс и команде следует ожидать хаоса (обычно на период до трех месяцев), пока каждый разберется, как сработаться с Agile. Еще я часто рисую набросок и поясняю модель изменений Вирджинии Сатир (см. рис. 5.1).
Я говорю: «Если вы согласитесь, то я предложу вам попробовать стандартный вариант Agile в течение трех месяцев. После этого мы оценим, что работает, что нет, и попробуем что-то улучшить[19 - Это не совсем правда. Agile подразумевает постоянное совершенствование, поэтому мы оценим, что работает, а что нет, уже в течение нескольких недель. Но по истечении трех месяцев мы делаем паузу, чтобы дать более значительную оценку.]. Спустя шесть месяцев у вас будет возможность принять решение – продолжаем мы работать с Agile или остаемся с тем, что есть сейчас».
Затем я даю всем возможность задать вопросы. У команд обычно множество вопросов касательно процесса, но один вопрос возникает всегда: «Что будет, если мы скажем “нет”?» Мой ответ всегда один и тот же: «Ничего не произойдет». Это важно! Должна быть реальная возможность наложить вето. Если вы не дадите людям возможность сказать «нет», то их «да» ничего не будет значить. Давая людям шанс отказаться сейчас и конкретную возможность передумать позже, вы позволяете им в безопасном режиме попробовать что-то новое.
Выделите достаточно времени на то, чтобы ответить на все вопросы. Встреча обычно занимает около часа, но иногда может затянуться. Ответив на все вопросы, напомните, что не будет никаких последствий для проголосовавших против. Еще раз подчеркните это. И затем приступите к голосованию.
Если команда настроена скептически…
Скептический настрой – нормальное явление, его следует ожидать. Будьте честны с вашим коллективом: изменения разрушительны, но результаты себя оправдывают. Поясните практики, которые, по вашему мнению, люди поначалу могут счесть странными или даже раздражающими, например парное программирование. Это поможет снизить градус скептицизма и в будущем облегчит процесс внедрения этих практик.
Может быть полезно подчеркнуть, что это эксперимент и за командой будет последнее слово в вопросе, придерживаться Agile или нет.
Если несколько членов команды против…
Если не согласны лишь несколько человек, то попросите их объяснить причины и подумайте, можно ли разрешить эти разногласия. Если не получается, то предложите им пока воздержаться от суждений и присоединиться к остальным членам коллектива на ближайшие шесть месяцев.
Если они все равно не согласны, то предложите им перейти в другую команду, при условии, что руководство одобрит это решение. Если же это невозможно или вы не знаете, кто именно не согласен (в случае анонимного голосования), что ж, значит, эта команда – неподходящий кандидат.
Если большинство членов команды против…
Если команда не согласна, то вам придется выбрать другую. В моей практике это случалось редко, но так бывает. В одном из случаев это было потому, что коллектив не верил, что их организация даст им достаточно времени на обучение. Теперь, оглядываясь назад, я понимаю, что они были правы, и хорошо, что мы тогда не приступили к изменениям.
Если люди обманывают насчет своего согласия…
Иногда люди голосуют за Agile, при этом внутренне выступая против. С этим вы ничего не можете сделать, кроме как приложить все усилия, чтобы люди не чувствовали себя принуждаемыми. Пытаться угадывать чужие мысли непродуктивно.
Даже если никто не обманывает сейчас, природа изменений такова, что время от времени всех будут посещать сомнения. Вам придется работать с этими сомнениями по мере их появления. И будет полезно иметь возможность напомнить людям, что они согласились принять участие в эксперименте длиной в шесть месяцев, что есть точная дата его окончания и если все не заработает к этой дате, то они смогут отказаться. Отнеситесь к ним с сочувствием и уважением; изменение привычек требует времени, и люди могут чувствовать, что устои, на которые они привыкли опираться, полностью утрачены.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/chitat-onlayn/?art=70277095&lfrom=174836202&ffile=1) на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
notes
Примечания
1
Agile Fluency – зарегистрированный товарный знак Agile Fluency Project LLC.
2
Дерби Э., Ларсен Д. Agile ретроспектива. Как превратить хорошую команду в великую.
3
Бьянкуцци Ф., Уорден Ш. Пионеры программирования: диалоги с создателями наиболее популярных языков программирования.
4
Источником появления подхода Waterfall часто ошибочно считают статью Уинстона Ройса, написанную в 1970 году. Однако применение фазового подхода восходит еще к 1950-м, а статья Ройса не пользовалась широкой известностью до конца 1980-х, когда к ней стали прибегать для описания того, что люди уже давно делали [Bossavit2013, chapt. 7].
5
Алистер Кокберн, цитата Джима Хайсмита в [Highsmith2001]. Полная цитата: «Лично я не ожидал… что эта конкретная группа приверженцев различных гибких методик сможет договориться о чем-либо по существу… Что касается меня, я в восторге от окончательной формулировки [Манифеста]. Я был удивлен, что и другие оказались так же довольны окончательной формулировкой. Таким образом, мы все же смогли договориться о чем-то по существу».
6
Фаулер выражал эту идею множество раз в течение нескольких лет. Оригинальную версию можно найти в статье [Fowler2000].
7
Источники: Mueller’s February 3, 2005, testimony to Congress (https://oreil.ly/GlQSa) и Inspector General Glenn Fine’s May 2, 2005, testimony to Congress (https://oig.justice.gov/node/672).
8
Впервые я прочел эту историю в трудах Ричарда Фейнмана, где в числе прочего была представлена его речь на церемонии вручения дипломов в Калтехе в 1974 году [Feynman1974]. История основана на реальных ритуалах, практиковавшихся в Меланезии после Второй мировой войны.
9
Эта последовательность действий следует из рассуждений Алистера Кокберна о сюхари (Shu-Ha-Ri).
10
Временные рамки, приведенные в этой главе, приблизительны и основаны на моем опыте. Ваш опыт может быть другим.
11
Отрывок из статьи Мартина Фаулера Enterprise Rails (http://martinfowler.com/bliki/EnterpriseRails.html).
12
Спасибо Джорджу Динвидди за это замечание.
13
Спасибо Джею Базузи за то, что обратил мое внимание на эти соглашения о commit-сообщениях (https://oreil.ly/7vSmz).
14
У Стивена Смита есть хорошая статья об этой модели (https://oreil.ly/1KQ38), включающая советы о том, как помочь команде на каждом этапе.
15
