прочитано
#IT и телеком #персонал #agile #гайд

При смене модели жизненного цикла проекта с классической водопадной на гибкую – проблема кадров становится чуть ли не самой острой. И неудивительно: в рамках Agile не работает принцип «ты начальник...». От всех участников проекта требуется существенно большее участие в процессах. Как решить проблему: привлекать специалистов со стороны или растить собственных?

0 1

Agile-команды: что на кону

Agile, по мнению Gartner, уже через год с небольшим будет претендовать на половину ИТ-бюджетов, а не на 1%, как два года назад.

126Муп_СТАТИСТИКА-ОЦЕНКА-GARTNER.jpg

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

Без топов не получится, или Почему первый блин комом

В мире традиционных информационных технологий IT-специалисты разрабатывают, потом тестируют, затем предъявляют результаты долгого труда бизнес-заказчикам.

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

Например, в «Райффайзенбанке» три года экспериментировали с внедрением Scrum и Kanban внутри команды IT-отдела. Но поскольку топ-менеджмент не знал, что в компании пытаются что-то трансформировать, время было потрачено впустую.

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

C этого года СEO и совет директоров взяли на себя роль «команды трансформации», что позволило начать преобразования всей компании.

Вовлечения исключительно СEO недостаточно. Средний менеджмент также должен стать ключевым заинтересованным участником

126Муп_Николай-Кныш.jpg Николай Кныш
директор по развитию ИТ-продуктов «Райффайзенбанка»
 

Персонажи в поисках мастера

По замечанию управляющего партнера компании Cleverics Олега Скрынника все специалисты, работающие над одной задачей, взаимно считают, что они умнее своих визави. Разработчики – что они умнее аналитиков и тестировщиков. Аналитики, что они умнее разработчиков, не говоря уже о тестировщиках. И все считают себя многократно умнее бизнес-заказчика.

126муп_ВЗАИМОДЕЙСТВИЕ-ВНУТРИ-КОМАНДЫ.jpg


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

Для этого и нужны наставники – scrum-мастера. Правда, вопрос с тем, где их взять – остается открытым.

Scrum-мастер из менеджеров привык руководить и «не зажигать у подчиненных глаза, а поджигать под ними стулья». Он продолжает давить на программистов, как раньше на «обычных» подчиненных, требовать взять больше обязательств, чем они готовы. Если его вовремя не остановить, то разработчики «возьмут, сколько не смогут». Процедуры самоуправления выродятся: от Agile останется одно название.

Scrum-мастер из программистов в силу специфики прошлой работы, как правило, не склонен к общению. Та же проблема с «зажиганием глаз». И вообще обычно такой специалист «слишком программист», т.е. плохо знает какие-либо смежные области. Иными словами, не достаточно «Т» в концепции Т-Shape

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

В условиях большого дефицита кадров любая попытка не пытка. Однако реакция на scrum-психолога может быть неоднозначной. Кроме того, в букве «T» большое значение играет вертикаль, подразумевающая знание предметной области.

Эволюция: от лени к ответственности

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

Иначе, по мнению руководителя проектов компании HeadHunter Павла Капусткина, будет срабатывать эффект «социальной лени». Он состоит в том, что члены команды выкладываются не полностью, а стараются переложить работу на плечи остальных.

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

  1. «Детский сад» – члены команды жалуются на все подряд и совершенно не интересуются делами коллег.

  2. «Пубертатный период» – наблюдается некоторое сплочение, но исключительно против внешних факторов/врагов, которые «во всем виноваты». Притом внутри коллектива по-прежнему сложные отношения: непонимание, борьба за лидерство.

  3. «Молодость» – коллектив сплачивается, в процессе обсуждения задач нет лишних людей. Вопросы и проблемы члены команды решают сами, не утруждая ими руководство.

  4. «Зрелость» – в случае удачной эволюции коллектив дорастает до уровня, на котором члены проникаются целями и ценностями своей компании настолько, что готовы сами ставить задачу собственному менеджеру, если таковой вообще имеется.

И если с точки зрения теории такой подход логичен и оправдан, на практике создать Agile-команду – задача непростая.

Если обратиться к опыту компании Wildberries, команды формируются с учетом психотипов на основе методологии Александра Афанасьева.

Мы классифицируем сотрудников по четырем характеристикам в зависимости от того, что в них преобладает: логика, воля, физика или эмоция. У ИТ-специалистов логика берет верх над волей, а у управленцев – наоборот

126Муп_Ревяшко-Андрей.jpg Андрей Ревяшко
ИТ-директор компании Wildberries

В «Ростелекоме» полагают, что помочь может создание «гильдий» – неформальных сообществ сотрудников, работающих как над разными продуктами, так и над одним, но в различных офисах.
Таким образом выстраиваются горизонтальные связи между сотрудниками. Это способствует расширению их кругозора, повышает лояльность к компании и одновременно снижает остроту кадровой проблемы по двум причинам.

  1. Члены гильдии хорошо представляют, кого из своих рядов они могут порекомендовать на нужную позицию.
  2. Компания, в которой они работают, представляется более привлекательным работодателем.

Однако полностью самодеятельные «гильдии» не очень эффективны. Другое дело, если их работу поддерживает руководство: оплачивает обучение, участие в конференциях и т.д. Тогда тяга к нетворкингу и совершенствованию перевесит желание создать очередную фишку ради фишки.

При создании статьи использовались материалы конференции Agile.DevOps.ITSM 2018 издательства «Открытые системы»