Почему Agile не работает, и как наладить работу IT-команды

Agile считается одним из универсальных способов выстраивания работы IT-команд. Про него написано множество книг, по нему проводятся курсы, на его основе создаются новые профессии для внедрения итеративного подхода к управлению проектами и разработке программного обеспечения. Но так ли всё гладко? Заместитель начальника управления автоматизации брокерского бизнеса Группы «Иннотех» Роман Островский готов поделиться подводными камнями методологии Agile и особенностями выстраивания эффективных IT-команд на практике.

1. Agile vs современный мир
2. О важности командной работы
3. Роли, неофициальные лидеры и условия
4. Выстраивание общения
5. Выгорание и снижение мотивации
6. Главный принцип создания эффективной команды

Роман Островский

заместитель начальника управления автоматизации брокерского бизнеса Группы «Иннотех»

Agile vs современный мир

В теории внедрение Agile начинается с изучения манифеста с 12 принципами разработки. Кстати говоря, их придумали 17 человек, собравшихся в начале 2001 года в городе Сноуберд, штат Юта. Они были обеспокоены, что в разных компаниях по-разному представляют оптимальный процесс разработки программного обеспечения. Но один вывод был общим для всех: компании настолько сосредоточены на избыточном планировании и документировании циклов разработки ПО, что уже неспособны эффективно и вовремя решать задачи клиентов.

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

В чём же сложности внедрения, казалось бы, разумных подходов? Скорее всего, не очень умеем пока. К тому же в больших компаниях много бюрократии, что накладывает отпечаток.

Методология даёт определённую свободу. Именно поэтому её так любят многие молодые специалисты. Но всё равно команде нужен такой «бесполезный» человек, как руководитель проекта. Он приземляет команду в желаниях по улучшению MVP и чётко блюдёт интересы заказчика. Мы в IT работаем в первую очередь на продукт, результат.

О важности командной работы

Необходимо правильно понимать, что неработающие принципы не повод отказываться от всей философии. Agile на самом деле гораздо обширнее, чем кажется. Приведу пример не из IT-отрасли.

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

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

По итогу в команде организовался «самоназванный лидер», причём именно «самоназванный». Как выяснилось, по факту какими-то лидерскими качествами он и не обладал, всё, что делал: раздавал ЦУ и возмущался, если что-то было не так, как он считал нужным. Влезал в создаваемые рабочие процессы и вносил лишь сумятицу. Никого не напоминает?

Вдогонку пошли конфликты, наезды, поклёпы, полураспад команды, дотаскивание со скрипом того, что осталось. Результат — кое-как и кое-что вынесли в «прод», получили по 4 балла и разбежались, перекрестившись, что это закончилось.

В чём тут мораль? Да, наверное, в том, что правила, описание процессов и прочее — не главное в командной работе. Главное — это именно командная работа. Ответственность всей команды, а не одного конкретного её члена, помощь в сложных ситуациях и прочее. К сожалению, в реальности далеко не всегда так получается. И это печалит, потому что этому очень мало уделяют внимание.

Роли, неофициальные лидеры и условия

А теперь перенесём эту детскую историю на рабочие проекты. По моему мнению, чётких ролей в проектах быть не должно: каждый член команды должен делать то, что позволит получить максимальный результат, в силу своих знаний, умений и опыта. Это не значит, что тестировщик должен разрабатывать программный код продукта. Но если он знает программирование, то пусть внедряет автотесты. Тот же тестировщик может где-то подсобить с аналитикой, технической документацией, согласованиями или ещё чем-то. Главное — помнить: если ты такой везде помощник, но свои задачи не успеваешь выполнять, лучше уж не помогай.

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

При этом условия работы, о которых также говорится в манифесте Agile, должна создавать сама команда.

Выстраивание общения

Если говорим про условия работы команды, то коммуникация — один из ключевых моментов. К сожалению, стоит констатировать факт: многие люди разучились говорить простым человеческим языком. И дело даже не в пресловутых софт-скилах, а в навыке донести точку зрения, передать информацию и так далее.

Можно внедрить довольно простые принципы коммуникации в команде. Сейчас большая часть общения проходит в чатиках, и тут многое зависит от их состава. Где-то нужно поофициальнее — когда в участниках продукт-овнеры, руководители. А в иных стоит и неформально — вспоминая наследие Нассима Талеба, можно и выматериться, если так информация дойдёт более точно до собеседников.

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

Про топ-менеджмент сложно найти универсальные стратегии коммуникаций. Но точно могу сказать, как с ними не нужно общаться. Точно не нужно подключать их к темам из серии «в туалете закончилась туалетная бумага, мне не выдают ручку, почему мне выдали монитор 27″, а не 4К».

Выгорание и снижение мотивации

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

Расскажу собственную историю. Больше года я работал в режиме с 9 до 23 в офисе. Как следствие, уходил из дома, когда дети ещё спали, а приходил — когда они уже спали. Видел их в лучшем случае только на выходных в тот небольшой период, когда не отсыпался.

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

Тогда понял, что работа в таком режиме — совсем не вариант. Дети — это, наверное, главное, что есть в жизни, по крайней мере, для меня. Сделав неглубокий анализ, я решил всё поменять. Привело это, правда, к смене работы, но это немного другая история.

Шли годы, и при очередном проекте с жесточайшими сроками, оглядываясь на прошлый опыт, я пришёл к такому графику:

• с 9 до 18 — стандартный рабочий день в основном с акцентом на встречи, обязательные задачи и прочее;
• с 18 до 22 или 23 (по ситуации) — личная жизнь, дети, семья, друзья, уроки, посиделки;
• с 23 до 2 или 3 (по состоянию и критичности задач) работа над какой-то текучкой, которая, с одной стороны, не требует большого количества умственных затрат, а с другой — отнимает довольно много времени, и если её не делать, количество задач скопится до необозримых размеров.

Но этот режим подходит мне как «сове». Я отказался от залипания в YouTube или книжку в пользу работы. Не удивлюсь, если найдутся «жаворонки», которым по кайфу будет работать в период с 6 до 9 утра, ещё до начала стандартного рабочего периода.

Также добавлю, что работа в выходные должна быть по возможности исключением, чем правилом. И уж тем более не нужно рассматривать работу в выходные как возможность дополнительного заработка. На восстановление после выгорания уйдёт наверняка больше денег.

Главный принцип создания эффективной команды

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

Буду рад в комментариях почитать опыт построения эффективных команд в других компаниях. Возможно, что положительных примеров использования Agile будет больше, чем негативных.