Agile-менеджмент. Лидерство и управление командами

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

Поэтому если вы считаете, что какая-либо практика (вроде коллективного владения кодом) необходима, то как вы собираетесь мотивировать кого-то, кто столь же упрям, как я?

Представьте себе баланс (рис. 5.2), в котором перечислены факторы, мотивирующие или демотивирующие одного из участников вашей команды. «Лучшие практики» по-разному воспринимаются разными людьми. Меня коллективное владение кодом демотивирует. Следовательно, из моего баланса нужно вычесть один пункт. А мой приятель Нильс, самый оголтелый из социалистов, которых я когда-либо допускал в свою жизнь, был бы, скорее всего, в восторге от идеи передать свой код другим. Таким образом, для него коллективное владение кодом будет сильнейшим мотиватором, а в его мотивационном балансе появляется жирный плюс.

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

Применяя Scrum, мы можем до бесконечности обсуждать, какой метод оценки объема работ лучше – с помощью «единиц истории», «идеальных дней», «размеров футболок» или «попугаев»? Какова оптимальная продолжительность одной итерации – одна неделя или четыре? А также чем лучше пользоваться при планировании – специальным приложением или стикерами розового цвета? И так далее… Все равно главное в том, что, стимулируя членов своей команды проводить такие обсуждения, вы добавляете плюсы в мотивационный баланс каждого сотрудника. И вам это ничего не стоит!

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

А что если у кого-то из сотрудников отрицательный мотивационный баланс?

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

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