Автор: Артур Леонов, Лига Цифровой Экономики, эксперт по digital-трансформации процессов компаний
Это вторая часть из цикла статей, посвященных вопросу использования AGILE в производстве нематериальных продуктов. В первой части постарался максимально кратко рассказать историю возникновения самого понятия AGILE. И подчеркнуть, что это не методология, а ментальная установка, ставящая во главу угла Человека, а не процессы и регламенты, и оценивающая его профессионализм и умение работать в команде, как главное мерило его достижений.
Начиная со второй половины 00-х годов весь, ИТ мир буквально взрывали новости о новых победах AGILE! С его помощью, как утверждают эксперты, можно повысить эффективность в десять раз, надо срочно внедрять его у себя или ваша корпорация обречена на провал! Такой же слоган ворвался на рынок интеллектуальных продуктов несколько лет назад и у нас в стране. Своей широкой популярностью AGILE в России обязан начинаниям Германа Оскаровича Грефа, именно он стал главными драйвером этого слова. Журнал Forbes постарался дать свое видение AGILE манифеста
Еще масла в огонь подлил перевод книги, опубликованной в России под заголовком «Революционный метод управлением проектами». Как видите, в оригинальном названии автор не употребляет слово PROJECT. Но для многих Прожект Менеджеров она стала настольной книгой.
Сразу уточню – это хорошая книга, которую я рекомендую к прочтению. В ней описаны рабочие методы, которыми я пользуюсь в текущей работе, несмотря на то, что я считаю, что использование Софт-Канбан более эффективным.
Основная мысль книги – как выполнить сложнейшие проекты в условиях катастрофической нехватки времени, когда единственный выход — это повышение эффективности текущей команды. Свое решение Джефф назвал SCRUM. И да, Джефф не призывает отказаться от проектного управления. Он лишь утверждает, что держаться за диаграммы Ганта, оторванные от реальной картины мира, и тратить 90 процентов времени на согласование изменений – тупиковый путь. Команда вместе с заказчиком должна оперативно решать, что делать в текущий момент. Несмотря на то, что сам метод SCRUM появился за 6 лет до рождения AGILE манифеста, сейчас между ними пытаются поставить знак «равно». Я думаю, что ключевая причина доминирования SCRUM над остальными методами гибкой разработки, например над ХР – это кажущаяся простота внедрения. Вам надо только назначить скрам-мастера и продукт-оуненера и посадить их в месте с командой разработчиков. Как будут чувствовать себя сотрудники при таких экспериментах, уходило на второй план. Перспективы повысить скорость разработки в два и более раз, убрав при этом высокооплачиваемого проект-менеджера, были слишком привлекательными, чтобы сразу не попробовать.
Сейчас мы видим закономерный результат такого подхода. В большинстве случаев утерян главный фокус AGILE на ЧЕЛОВЕКА, его индивидуальность, но работу в команде
Теперь первое, что я делаю, услышав от собеседника фразу: «Мы работаем по AGILE — это прошу рассказать о действиях по AGILE. В 90 процентах случаев я слышу про небольшие команды от 5-7 человек (иногда 30), работу строго по спринтам, ежедневные стенд-апы. Как вы помните, (из моей прошлой статьи) это артефакты SCRUM. Еще более грустно услышать тишину, задав вопрос про AGILE манифест или услышать: «А это разве не он?»
Как это могло случиться, почему произошла подмена смысла?
Как я вижу, это закономерное следствие желания получить быстрый результат без погружения в суть решаемой проблемы. Появился некий хайп — AGILE. Команды, которые внедрили у себя данный метод разработки, упомянутые авторами AGILE манифеста, добились выдающихся результатов. Многие захотели попробовать этот опыт у себя. Как правило, самым доступным способом внедрить у себя AGILE — было нанять сотрудников из организации, в которой уже есть AGILE культура. Если это были разработчики, работающие по SCRUM, то AGILE превращался в SCRUM, так как они находились уже внутри системы и не могли объяснить, какие базовые ценности находятся во главе угла.
Ситуация еще больше усугублялась тем, что на роль SCRUM master назначали даже не менеджера, а тимлида, то есть самого сильного разработчика в команде, в результате фокус еще больше смещался на процесс разработки и поддержание ритуалов. Новичков, приходящих в такие команды, подкупало видимое отсутствие руководства и явного контроля с его стороны. Это, в свою очередь, приводило к потере фокуса на конечный результат, сроки и качество. И, как следствие, вызывало резкую критику уже SCRUM, как метода разработки, и всего AGILE в целом.
На западе, осознав проблему, постарались ее решить, создав институт сертифицированных AGILE-coach, которые, помимо практического опыта, проходили соответствующее обучение и тестирование. Для нашей страны этот процесс был затруднен тем, что, например, получить сертификат ICP в России стало возможно только в конце прошлого года, а для подтверждения своих знаний по Софт-Канбан придется ехать в Европу. Это привело к очень большому числу самопровозглашённых Аджаил-коучей со своим видением на AGILE.
В результате даже один самых эффективных подходов – Scrum, начал претерпевать изменения в угоду существующей структуре или интересам внедряющих этот метод. Так, например, скрам-команда могла быть в тридцать человек (полная потеря связей внутри команды) или отказ от одного из главных артефактов, улучшающих процесс и продукт, — ретроспективы. Как показал мой грустный опыт в отечественной среде, даже среди руководителей ИТ компаний под AGILE подразумевают один из методов гибкой разработки, забывая о главном фокусе на человека, выраженном в AGILE Манифесте.
Как очевидно из всего выше сказанного, произошла подмена понятий. И именно эта подмена является одной из основных причин такого большого количества проваленных проектов, которые пытались реализовать по SCRUM. Во многих книгах и статьях подробно разобрано, какие ошибки бывают, когда руководство не вовлечено или вовлечено формально в процесс трансформации подразделений, занимающихся разработкой нематериальных продуктов. Все они подробно разбирают частные случаи, когда, например, руководство не приходит на демонстрации готового продукта или отменяет ретроспективы, а вместо планирования, проводимого всей командой, навязывает ТЗ. Безусловно, это показательные примеры, но, если посмотреть на картину в целом, то становится очевидным пренебрежение и невнимание к главному ресурсу любой корпорации, занимающейся созданием интеллектуальных продуктов – человеку.
Внедрение любого из методов гибкой разработки без вовлечения сотрудников приведет к сильному сопротивлению и желанию саботировать процесс или просто уйти
Даже декларативное внедрение Софт-Канбан может приводить к сопротивлению, несмотря на главную парадигму Софт-Канбан: уважение к людям и текущим процессам. Безусловно, без поддержки высшего руководства, внедрение новых методов управления производством, а в особенности AGILE-методов, требующих для их эффективной работы глубокой трансформации ценностей организации, задача практически невыполнимая.
Поэтому я искренне призываю всех руководителей, собирающихся начинать процессы трансформации в своих организациях, очень внимательно изучить базу, на которой основывается как успех внедрения методологий AGILE, так и провал очень многих проектов. Помните, ни одна методика не сможет поднять эффективность сотрудника, занятого интеллектуальным трудом, без его вовлеченности и желания работать по новым правилам.
Чем выше интеллект и творческий потенциал сотрудников, тем изощреннее они будут убивать все плюсы нового подхода и дискредитировать его в глазах остальных коллег и руководства
Помните также, что если вы, как руководитель, не сможете донести и продать те преимущества, которые скрывают в себе методики AGILE, самые талантливые, но не вовлеченные, очень быстро найдут все слабые места и воспользуются ими уже в своих личных интересах, которые уже никак не будут пересекаться с интересами компании. Вы — руководитель и вы должны не только помнить принципы AGILE манифеста, но и руководствоваться ими при принятии даже самых непростых решений. Помните, манифест придумали разработчики, он не отрицает ни организаций, ни регламентов, ни договоров. Он говорит, что в первую очередь надо смотреть на личность, команду, состоящую из личностей. Анархия и попустительство так же вредны, как и жесткие регламенты и планы, потерявшую всякую актуальность, но которым заставляют следовать. Вам необходим баланс, терпение и вера в свою команду.
Оглядываясь назад, я отчётливо вижу, что те фантастические успехи, которых добилась моя команда, в первую очередь связаны с духом взаимного уважения и открытости. Мы просто верили в себя и знали, что мы лучшие и нам по плечу сделать этот проект, я был экспертом в решении одних задач и новичком в других, и все мы были готовы помочь друг другу. Мы добровольно трудились иногда по 18-20 часов в сутки, потому что мы взяли задачу и теперь должны ее выполнить. Без такой установки я не верю в возможность создавать достойные решения и выполнять фантастические проекты. Мне потребовалось достаточно много времени, чтобы осознать главный источник нашего успеха. К сожалению, и я очень долго уходил вначале от XP, затем от SCRUM. Теперь я отдаю предпочтение Soft-Kanban, как самому экологичному методу, фундаментом в котором служит уважение к людям.
Видео. Что Agile меняет в работе с сотрудниками?
В завершение я хочу рассказать одну историю:
Один крупный руководитель решил внедрить у себя в компании Аджаил, о чем решил сообщить всем сотрудниками, отправив письмо со следующим заголовком: «Внедрим AGILE в сжатые сроки!» Он ошибся в слове СРоКИ, случайно заменив букву о на А. Получив письмо с таким заголовком, сотрудники почувствовали, что год будет непростым. К счастью, директор и сам заметил свою ошибку. Он не стал оправдываться, а лично провел первую встречу с сотрудниками и экспертами по AGILE, извинился за свою опечатку и сам рассказал о принципах AGILE манифеста и том, что лично он разделяет эти ценности и руководствуется ими. Также он попросил давать лично ему обратную связь и информировать в случае возникновения организационных проблем.
Как результат, все сотрудники увидели новые возможности, которые дает AGILE. Это дало ощущение уверенности, безопасности и, как следствие, повысило вовлеченность.
Процесс трансформации начался с доверия и открытости, благодаря чему самый трудный первый этап, когда обычно возникает спад производства, связанный с освоением новых приемов и методов, прошел намного быстрее. Уже спустя несколько месяцев компании удалось решить ряд проблем, связанных со срывами сроков реализации и качеством своих продуктов. Если есть вера в себя и команду, даже ошибки приносят на пользу.
Видео. Лидер в Agile и лидер традиционном понимании — в чем разница
