Что такое agile коуч
Что такое Agile-коучинг и зачем он нужен?
Считается, что Agile-коучинг помогает командам становиться выдающимися и создавать продукты, которыми они будут гордиться. Вместе с Лиссой Адкинс (Lyssa Adkins) — сертифицированным специалистом по Scrum и проджект-менеджменту, автором книги «Коучинг agile-команд» (Coaching Agile Teams) — разбираемся, что такое Agile-коучинг и в чём преимущества этого подхода.
Что такое agile-коучинг?
Чтобы понять agile-коучинг, посмотрим сначала на мир профессионального коучинга. В нем коучинг существует в атмосфере искусных разговоров, благодаря которым коуч помогает ученику увидеть новые перспективы. Благодаря этому ученики могут представить свой следующий шаг в личностном и профессиональном росте и двигаться в нужном направлении.
В контексте agile-команд к коучингу добавляется функция наставника. Да, вы занимаетесь коучингом личностного роста, чтобы помочь человеку достичь следующей цели в жизни. Но вы также делитесь собственным опытом и идеями как наставник, помогая правильно применять Agile. То есть коучинг и наставничество переплелись между собой, чтобы развивать талантливых специалистов в области Agile. Благодаря этому результаты работы появляются чаще и становятся лучше.
Шаблон повторяется на командном уровне. Коучинг помогает повысить эффективность, когда вы предпринимаете определенные шаги как коуч, а команда делает свой выбор. При помощи наставничества вы передаете команде agile-знание и опыт, так же как конкретное знание становится актуальным, потому что было получено на собственном опыте.
И коучинг, и наставничество полезны и могут быть эффективны сами по себе. Но, соединяясь вместе, они становятся особенно выигрышной комбинацией, помогающей людям внедрять и использовать Agile. Контекст Agile превращает вас в наставника, а акцентирование на результативности команды — в коуча. Обе части уравнения объединяются, чтобы оживить Agile и сделать его досягаемым.
В мире Agile коучинг и наставничество объединены в понятие «коучинг». Вам просто следует знать, что agile-коуч совмещает в себе коуча и наставника. Кроме того, известно, что мы используем навыки из мира профессионального коучинга, но не являемся настоящими профессионалами. Важная составляющая профессиональной этики заключается в том, что расписание клиента — это настоящая путеводная звезда для ученика и коуча в их взаимоотношениях.
Коуч существует исключительно для клиентов. Но мы — нет. Нельзя позволять их расписанию полностью управлять нами. Мы также должны согласовывать их повестку с нашей собственной, приучая тем самым учеников правильно использовать Agile.
Главное — знать, что мы как коучи применяем инструменты профессионального коучинга и являемся наставниками в правильном применении Agile. Мы обучаем исходя из этого опыта и используем навыки коучинга, чтобы помочь каждому человеку осуществить переход к Agile.
Зачем заниматься коучингом?
Люди, которым помогал agile-коуч (в профессиональном коучинге таких называют чемпионами), блестяще используют Agile, поэтому быстрее достигают впечатляющих бизнес-результатов. Если мы хотим полной отдачи от Agile, нужен стремиться работать не только быстрее и лучше, но еще и на основе лучших инноваций. Для этого и был создан Agile.
Возможно, появление переполняющего чувства радости у каждого члена команды и есть ваша цель. Как правило, команды, ценящие ощущение радости от проделанной работы, выполняют ее с большим удовольствием. Таким образом, образуется замкнутый круг.
Тональность коучинга
И при работе с целой командой, и при индивидуальном коучинге необходимо проявлять любовь, сочувствие и бескомпромиссность. Любите своих учеников просто потому, что они такие же люди, как вы. Подарите им признание, чтобы они понимали: их поддерживают в стремлении стать лучше. Сочувствуйте в выборе пути каждому человеку, чтобы он знал: вы проявляете к нему уважение на том этапе, на котором он находится в данный момент, так же как вы помогаете ему приобрести то, что он желает получить за определенную плату. Когда люди понимают, что вы относитесь к ним с любовью и сочувствием, они забывают о позерстве и становятся сами собой. После этого начинается коучинг.
Чтобы привнести любовь и сочувствие в вашу коуч-практику, вовсе не нужно разводить сантименты. Неискренние объятия и возгласы вроде «До чего же я люблю этого парня!» не заменят истинного чувства, которое от вас требуется. Люди увидят воплощение любви и сочувствия в ваших глазах, в том, как вы их слушаете, и в уважении их как экспертов по собственной жизни.
Не следует произносить слова «любовь» или «сочувствие» в их присутствии для подтверждения того, чтобы они знали: их поддерживают и ценят. Лучше не делайте этого, а просто искренне любите и сочувствуйте. Но главное вот в чем: можно быть одновременно любящим, сочувствующим — и бескомпромиссным.
Sidenis о работе со страховыми корпорациями, agile-коучинге и запрещенных технологиях
Sidenis — относительно небольшая ИТ-компания, которая на первый взгляд не отличается от сотен других аутсорсинговых фирм. Но мы ищем рассказы об уникальном опыте и ситуациях, с которым сталкиваются далеко не везде. И здесь они, конечно, тоже есть. Сиденис 20 лет работает в страховой сфере, работает на крупнейшие корпорации и пытается создавать свои продукты.
По итогам оценки компании, которую Sidenis получили на «Моем круге», сотрудники особенно благодарны компании за хороший соц.пакет, комфортные условия работы и профессиональный рост.
Мы поговорили с Виктором Климовым, agile-коучем Sidenis, и попытались узнать, трудно ли связать двести человек между часовыми поясами, как бороться со списком запрещенных технологий от заказчика, заниматься на работе личными проектами и зачем гениальным программистам знать английский язык.
Что такое agile-коуч и зачем он нужен?
Виктор Климов
Я работаю agile-коучем, а раньше был программистом. В Sidenis я чуть больше семи лет. У меня был долгий путь от джуниора до сеньор java-разработчика. Почти на протяжении всего этого пути я еще попутно был скрам-мастером. И понял, что люди должны заниматься тем, что у них получается лучше всего. Поэтому перешел на agile-коучинг. Общаться с людьми у меня получается лучше, нежели программировать.
— И как давно ты это понял?
Уже год. Сейчас возникла не только моя потребность в этом, но и потребность компании. Мы выросли, сотрудников стало больше, и времени на то, чтобы работать с людьми, спорить с ними, что-то объяснять, рассказывать, показывать новое — стало уходить сильно больше.
Тогда я принял важное для меня решение и закончил с разработкой. Пришлось чем-то пожертвовать. Не могу сказать, что мне не нравится разработка — нравится. Ты получаешь удовольствие, когда делаешь и видишь результат. Но, к сожалению, рано или поздно приходится делать выбор.
— Agile-коуч — звучит экзотично. Расскажи что конкретно ты делаешь?
Agile-коуч — это человек, который вдохновляют коллектив на изучение чего-то нового, помогает применять новые практики, помогает уменьшить сопротивление компании этим изменениям, и может объяснять, что это, для чего нужно и к чему это может привести. Дать сравнительные характеристики. Он несет знания в массы.
Я провожу тренинги для команд — в том числе для новых людей — рассказываю про основные ценности, что за agile мышление и почему оно работает. Это полезно знать как и новичкам, так и проговорить с уже существующими командами, чтобы выработать единый стиль, единое мышление.
— Может быть расскажешь конкретную историю, где команды делают что-то, что ты считаешь неправильным, а ты приходишь и помогаешь исправить?
Например, у нас одна команда, скажем так, разочаровалась в скраме. Они пытались воплотить более книжный вариант, по наитию, и посчитали, что скрам в принципе не применим в их работе. Хотели уже отказываться от данного фреймворка и склонялись в сторону Kanban.
Мы с ними провели тренинг, они переосмыслили свой подход, подумали что у них раньше было не так. Мы проговорили, что такое Agile, каковы его принципы, обсудили Scrum, все его ритуалы — что это, для чего это нужно и как это применять. После этого ребята переосмыслили, подумали еще раз и поняли, что это может сработать. Дали фреймворку второй шанс. Сейчас работают успешно.
Какие продукты делает Sidenis
— Когда ты пришел, компании уже было много лет?
Она намного старше. Компания существует более 20 лет. На протяжении всего этого времени она оказывает услуги по разработке ИТ решений для страхового и перестраховочного бизнеса. Наши основные заказчики — это большие корпорации, такие как SwissRe или Allianz. Они занимают лидирующие позиции в области перестрахования и страхования.
У нас есть в офисы в четырех городах. В Санкт-Петербурге, там больше всего людей. Есть офис в Томске, Калининграде и Цюрихе. В Цюрихе сосредоточена в основном бизнес-часть, в Санкт-Петербурге, Томске и Калининграде — центры разработки.
— Я так понимаю, компанию создали специально, чтобы работать со SwissRe?
SwissRe наш самый крупный и давний партнер. Но это только часть бизнеса, у нас есть и другие заказчики, и свои собственные продукты. Например, сервис онлайн-страхования RiskMarket. Сервис интегрирован с ИТ системами страховых компаний и позволяет искать страховки с лучшими условиями по актуальным тарифам. Сиденис является ИТ партнером Ooniq — платформы социального страхования, основанной на блокчейне.
Есть еще интегрированная ИТ-платформа, которая называется Actus. Она помогает актуариям и андеррайтерам разрешать их повседневные задачи легче и эффективнее. Там несколько модулей, базовых математических библиотек, которые содержат весь необходимый набор функции для актуариев и андеррайтеров. Там есть веб-приложение для расчета рисков и различные графики.
— У вас больше собственных проектов или проектов для других компаний?
Пока у нас больше заказных проектов, но наша цель сделать их соотношение 50 на 50. В основном заказчики — большие страховые и перестраховые компании, и мы работаем с ИТ-инфраструктурой, включающей сотни различных приложений и систем. Плюс каждый год меняются требования для страховых компаний, нужно добавлять новые критерии.
Есть веб-приложение, куда ты вбиваешь данные и получаешь результат. Там прописаны математические операции, матмодели. Есть приложение, которое предоставляет интерфейсы для того, чтобы рассчитывать и сохранять данные о заключенных сделках. Проект дает понимание руководству, соответствует цена контракта ожиданиям или нет. Все эти проекты помогают с разных сторон сделать жизни андеррайтеров проще.
Структура компании и работа между часовыми поясами
— Ты говорил, вы растете. Становится больше задач на текущем проекте или появляются новые клиенты?
Да, мы растем. Растет портфель заказов от текущих партнеров, появляются новые заказчики, да и разработка собственных продуктов также требует больше ресурсов. Сейчас у нас в компании во всех четырех офисах больше 200 человек — около 140 в Питере, около 50 в Томске, 15 в Калининграде и примерно 20 человек в Цюрихе. У нас интернациональная команда. Есть люди из России, Швейцарии, Германии, Австрии, Франции, Китая и других стран.
— В чем была логика такого распределения по городам? Между Томском и Петербургом далеко, разные часовые пояса. Наверное, неудобно.
Разные часовые пояса действительно накладывают некоторые неудобства. Но мы привыкли к работе в распределенных командах. В Томске есть технические университеты, и там можно найти специалистов. Плюс Томск находится ближе к Индии, где у нас тоже есть коллеги. Это упрощает ситуацию.
Для разработки неудобно, когда есть четыре часа разницы. Но в то же время ребята в Томске приходят на работу раньше нас — если вдруг какое-то приложение не работает, упал сервер или еще что-то, они его могут оперативно перезапустить. Так что из этого тоже можно извлечь пользу.
— У вас сотрудники работают только в офисах или есть удаленные?
Только в офисах. Есть возможность один день в неделю работать удаленно из дома, но в основном — работа идет в офисе. Когда мы находим сотрудников в других городах, мы им предлагаем переезд в Питер, Калининград или Томск. Так сложилось исторически. У нас никогда не было удаленных сотрудников.
— Как люди распределены по командам?
Некоторые команды включают в себя людей из всех четырех офисов, но это редкость. Команды довольно автономные, и могут самостоятельно делать любые задачи, которые им поступают. Туда входят и тестировщики, и дизайнеры, и девопсы, представители бизнеса, продакты, аналитики.
— Как проходит работа — от принятия заказа до сдачи продукта заказчику?
Мы работаем короткими спринтами — от двух до трех недель в зависимости от проекта. В каждой команде есть продукт-оунер, человек который обладает видением, куда нужно идти. Задачи разработке поступают от него, поскольку он общается с заказчиком и с теми, кто будет пользоваться данной системой.
Он описывает задачи, предоставляет их команде, команда задает уточняющие вопросы, продакт уточняет детали, и команда берет задачу в работу. На протяжении двух-трех недель работает над ними, и в конце итерации показывает результат. У кого-то релиз в продакшен происходит раз в спринт, у кого-то раз в два спринта. Есть команды, которые релизятся не так часто, например два-три раза в год. Но тем не менее, после каждой итерации они показывают продакту и пользователям, что те смогут увидеть в следующем продакшн релизе.
Вся документация, все общение с заказчиком ведутся по-английски, поэтому знание языка для нас важно. Общения разработчика с заказчиком мы даже приветствуем. Все-таки разработчики ближе всего к коду и лучше знают, как все работает.
— На собрания и переговоры уходит много времени?
Ну, разработчики иногда жалуются. Они, конечно, ответят, что много. Но у каждого совещания и митинга есть цель — чтобы разработчики тоже узнали, как развивается наш проект, куда он движется, чем занимаются другие люди. Все должны быть в курсе, чтобы понимание не висело на одном человеке.
— Ты считаешь, разработчикам это действительно нужно — знать, как работают другие?
Я считаю, что да. Лично для меня это было важно. Я знал области, в которых разбираются другие сотрудники, и мы могли друг другу помогать. Задачи идут потоком, может получиться так, что в один момент тебе надо будет разбираться в новой области, а так ты уже про нее хотя бы слышал.
Специфика заказчика и список запрещенных технологий
— Можешь рассказать про особенности и специфику работы со страховой корпорацией?
Так как это большая компания, у них достаточно жесткий список технологий, которые мы можем использовать. Периодически мы сквозь него прорываемся, но позицию нужно отстоять. Если удастся доказать, что это действительно нужно и важно — то они принимают нашу точку зрения и идут на уступки.
Но список есть. С одной стороны это плохо, потому что он ограничивает людей. Но с другой стороны это предотвращает хаос, потому что поддерживать большое количество одинаковых приложений и разных версий дорого, тяжело и требует много времени.
— Расскажешь про этот список?
Например, нам был нужен фреймворк Spring для Java, но он был запрещен. Разрешали только Java Enterprise Edition. Нам удалось доказать, что это для нас важно и нужно, что это ускоряет разработку.
Во фронтенде у нас разрешены Angular 6, JavaScript c React и TypeScript.
— Для чего нужен список технологий?
Когда есть четкий и понятный список, это дает предсказуемость. Иначе поддержка будет очень дорого стоить. О рабочем приложении судят по тому, насколько оно нравится пользователям. Но минимальный технический контроль со стороны заказчика есть — статистические анализаторы кода или службы, которые отвечают за качество кода и проверяют наши репозитории (это, в основном только на новых проектах).
Но супер жестких регламентов к коду у нас нет. Ничего сверхъестественного, никаких «обязательно пишем скобочку на одной строке, а не на другой».
Мы живем с этим списком. Не сказать, что очень радуемся, но и ничего плохого нет. Он нас ограничивает в рамках разумного. Нет такого, что мы используем только древние технологии, и никто не слушает наших советов.
— Есть технологии, которые вы хотели бы применить, но не можете?
Мы хотим писать на Go. По нему идут просьбы со всех сторон, потому что язык легковесный, занимает меньше памяти, чем Java, быстрее работает. Но идет процесс обсуждения. Некоторые проекты используют его в своих сервисах.
В редких случаях от списка можно отходить, главное, чтоб заказчик понимал зачем это нужно и какую проблему мы хотим решить. Мы не можем приходить и говорить, «сегодня мы используем такой JS фреймворк, а завтра другой». Они рождаются каждый год, и если постоянно переходить, заказчики не будут понимать, что происходит.
Найм в компании без разрекламированного бренда
— Где вы ищете людей?
В основном на HeadHunter, «Моем круге», в Linkedin, на конференциях. В Томске в этом году мы провели небольшой эксперимент и запустили несколько академий по Java, тестированию и фронтенд-разработке. Обучали там людей с разным опытом. Сейчас идет уже второй набор, и думаю мы будем с этим продолжать. В среднем, мы принимаем на работу половину прошедших обучение, что является очень хорошим результатом.
С сарафанным радио сложнее, до недавнего времени мы активно не продвигали свой HR-бренд. Но в то же время, если люди о нас знают, то охотно идут. Было даже такое, что некоторые работали у нас, уходили, работали в других компаниях, и в итоге возвращались обратно. Это о чем-то да говорит.
— Как проводите собеседование?
Оно проводится в два этапа. Первый проходит по скайпу. Мы стараемся узнать общепринятые вещи: техническую грамотность, теоретический материал, даем не очень сложные практические задания, чтобы можно было прикинуть уровень человека.
Второе собеседование проходит в офисе компании. Там уже могут даваться задачи на программирование. Мы смотрим, как человек пишет код, как думает. Интересно посмотреть, как приходит к ответам, задает ли уточняющие вопросы, как их формулирует, корректирует ли свой код по ходу дела.
Спрашиваем более глубокие теоретические вопросы, чтобы понять, с каким опытом человек к нам пришел.
— Не кажется, что теорией можно отсеять и хорошего разработчика? Все же гуглится.
Умение быстро проанализировать информацию и дойти до ответа — вот это важно. Если человек сталкивался с проблемами и решал их, то он сумеет аргументированно обосновать, почему это решено так, а не иначе. У опытного человека всегда есть аргументы, а не просто чутье, и мне кажется — это ценнее. Чутье и наитие в духе «я уже десять раз так делал и всегда работало» — это, конечно, хорошо, но узко.
Я не говорю, что человек должен все досконально знать. Но если он разбирается в том, что делает, то может прийти к лучшему решению, нежели просто копируя куски кода со StackOverflow без знания теории.
— Есть черта, из-за которой вы точно откажете кандидату?
Отсутствие английского. Если человек не может разговаривать, мы вынуждены отказать. Поэтому на собеседовании уделяем время языку, просим поговорить с нами на английском.
— Если разработчик гениален, но не знает английского — все равно не возьмете?
К сожалению, да. К тому же, гениальные разработчики сложно приживаются в энтерпрайз разработке. Как он будет общаться с заказчиком? Как будет разрешать свои вопросы?
Всегда работать через продакта не очень эффективно. А при использовании скрама практически невозможно.
Но в наше время английский знают почти все — читают уж точно. Многие пытаются говорить. Плюс у нас в компании есть собственные курсы английского и немецкого. Преподаватели могут подтянуть. Если человек гений программирования и он хоть как-то говорит на английском, то ему помогут развиться.
— Как много времени проходит от заявки кандидата до оффера?
На самом деле, все проходит быстро. После собеседования мы берем день-два на подумать, посовещаться. Потом назначаем второе собеседование, и как скоро оно пройдет, зависит от кандидата, есть ли у него время в ближайшие дни. После второго собеседования тоже день-два. Так проходит неделя, максимум две, и кандидат уже получает оффер или отказ.
— Человек попадает в компанию. Что дальше?
У нас есть welcome-тренинг. Там все рассказывается про компанию, как мы живем и работаем. Человека знакомят с офисом, людьми и проектами, а дальше ответственность за то, как он вольется в коллектив, лежит на команде.
Поначалу идет изучение страхового бизнеса. Это достаточно специфичная вещь. Когда ты видишь это в первый раз, то может выглядеть не очень понятно. Поэтому сначала идет погружение, это не совсем легко, но все справляются. Плюс когда поступает задача, с ней дается и контекст — для чего это делается, чтобы человек не бездумно писал код, а понимал зачем его писать.
— Что вообще привлекает людей идти к вам работать?
Я бы сказал печеньки…
— Печеньками никого не удивишь.
На самом деле, мы поняли, что печеньки — это действительно зло, и перешли на фрукты и овощи. У нас достаточно неплохой социальный пакет, есть ДМС, виртуальные счета.
Жизнь внутри, виртуальные счета и время на саморазвитие
— Чем вы мотивируете и поощряете сотрудников?
У нас есть виртуальные счета на каждую команду. Виртуальный счет выдается сразу на год и рассчитывается в зависимости от количества людей в команде. Они распоряжаются счетом, как хотят. Могут отметить, например, свой релиз, посидеть в баре, пообщаться в нерабочей атмосфере, сходить на какой-нибудь квест, попрыгать на батутах.
Такой же виртуальный счет есть на каждого отдельного человека. Его можно тратить на улучшение рабочего места, фитнесс, образование, конференции, книжки.
— А как боретесь с выгоранием?
У нас есть система учета рабочего времени, и мы следим, как много времени люди тратят на проект, насколько сильно вовлечены. Если переработок очень много, то стараемся отправлять в отпуск, либо давать дополнительные дни отдыха. Работать в одном и том же ритме и показывать одинаковую продуктивность — это сложно.
Плюс люди сами выбирают себе задачи из тех, что есть в спринте. Интересные задачи держат человека в состоянии потока. Но иногда бывают и рутинные — от этого никуда не деться.
Зачастую не сильно заметно, что человек выгорел. Он по-прежнему ходит на работу, но его ничего не интересует. И если это уже случилось, значит что-то пошло не так. Это надо обсуждать с каждым отдельно и решать, что конкретно сделать. Я знаю одного человека, который решил эту проблему переводом на другой проект. У него появилась мотивация работать из-за смены деятельности, задачи приносили больше радости.
Важно, что люди у нас могут заниматься не только рабочими проектами. Внутри компании существуют «Гильдии», объединяющие разработчиков, тестировщиков, дизайнеров. Мы выделяем до 200 часов в год на каждого сотрудника, которые они могут посвящать саморазвитию и творчеству. Изучать в рабочее время новые технологии, объединяться с коллегами по интересам, создавать новые продукты. Например, у нас так одни ребята занимались машинным обучением, алгоритмами.
— А сами рабочие задачи интересные?
Конечно, зависит от проекта, но интересную можно найти везде. Пусть сильных технических вызовов в них нет — работы с большим объемом данных или с высоконагруженными системами. Но в то же время, сделать правильную архитектуру, хорошо поддерживаемую и легко изменяемую — это тоже достаточно сложно. То есть, технически есть куда развиваться.
Agile-коучинг
Будучи гуманитарием до мозга костей, могла ли я когда-нибудь подумать, что всерьёз заинтересуюсь изучением практических наработок из IT-области?
Но жизнь так стремительно меняется, что ничего не остаётся, как принимать её вызов и пробовать новые походы не только в оптимизации производства, изобретении новых технологий, продуктов и услуг, но и в эффективном управлении людьми.
Всё чаще руководителям приходится признавать, что классические методы работы с сотрудниками дают сбой. Конечно же факторов, влияющих на эффективность управления, огромное множество.
Однако современные реалии жизни, такие как многозадачность, требования к быстроте исполнения, работа в условиях неопределённости, создание инновационных проектов и продуктов, требуют от руководителя и проектной команды чёткой, слаженной и эффективной работы, которая зачастую возможна только при использовании новых подходов к управлению такой проектной группой.
И несмотря на то, что agile-подход зародился и активно используется в IT-индустрии, его принципы могут быть отлично встроены в работу любых проектных команд, которые трудятся над решением новых, не типовых задач. Но обо всём по порядку.
Как появился agile-подход и что это такое?
Зачастую разработчикам ПО приходится не легко, особенно если продукт не стандартный. Это означает, что требования к разработке могут меняться в течение всего процесса создания продукта. И если их не учитывать, то на выходе может получиться вовсе не тот результат, который понравится Заказчику.
Ещё несколько лет назад срок разработки программного продукта мог составлять 3 года, в то время как сейчас – 3 месяца! Задача современного бизнеса – реализовывать проекты быстро и качественно! Как же этого добиться? Командам разработчиков пришлось пересмотреть подходы, в которых они работали. Дело в том, что разработка раньше велась определёнными этапами по принципу каскадной реализации проекта. Пока не завершался один этап невозможно было перейти к следующему.
Не было возможности постоянно тестировать и улучшать продукт уже в процессе разработки проекта, т.к. всё упиралось в исходное ТЗ. Такой подход являлся совсем не гибким и был сопряжён с бюрократией и множеством разрабатываемой документации, которая зачастую становилась неактуальной к моменту окончания проекта. Именно поэтому взамен классическим были придуманы гибкие подходы в ведении проекта, не требующие длительных согласований по поводу малейших изменений в проекте.
Так появилось понятие, agile – как философия, объединившая в себе принципы всех гибких методологий по разработке программного обеспечения (ПО). К ним относится Scrum, Kanban и др.
В 2001 году, благодаря команде разработчиков, которые поняли, что жить и творить, как раньше, становится неэффективно, появился на свет Agile-манифест, содержащий в себе основные принципы работы в Agile-подходе.
Ключевыми из них стали:
1. Люди и их взаимодействие важнее, чем технологии. Причём самый эффективный метод взаимодействия и обмена информацией – это личная беседа.
2. Готовый продукт важнее, чем прописанная документация по нему. Важно поставлять Заказчику полностью рабочее программное обеспечение каждые несколько недель
3. Постоянный диалог с Заказчиком в процессе разработки продукта важнее жёстких ограничений, прописанных в контракте
4. Чуткая реакция на изменения важнее, чем следование исходному плану действий
Как мы видим, в этих принципах прослеживается готовность к изменениям, ценность людей и ориентация на результат.
Причём, наивысший приоритет – это удовлетворение заказчика/пользователя с помощью частых и непрерывных поставок продукта, ценного для него, чтобы можно было получать обратную связь для последующих доработок проекта.
Ни к этому ли стремится любая команда, работающая над проектом?
Спасибо, дорогие «айтишники», теперь мы можем смело перенимать ваш опыт!
Давайте посмотрим, как выглядит на практике такой подход? И причём здесь коучинг?
Как мы знаем, коучинг – это всегда работа над построением желаемого будущего и всегда работа на результат. В процессе коучинга, как правило, используются техники задавания вопросов, которые позволяют человеку лучше понять стоящую перед ним задачу, увидеть ресурсы и пути её достижения. И если в классическом варианте коучинг – это индивидуальная работа коуча с клиентом, то в контексте проектных разработок используется командный коучинг, который очень похож на фасилитацию. Кроме того, как правило, agile-коучинг требует экспертизы коуча в той сфере, где он помогает команде идти к результатам, поэтому иногда agile-коуч может также вступать в качестве ментора и наставника.
Процесс agile-коучинга позволяет сделать работу команды прозрачной, слаженной и в то же время сфокусированной на конкретных целях.
Пример 1.
Представьте себе утро рабочего дня, которое ежедневно начинается с 15-ти минутной Daily stand-up сессии. Это такое мини-собрание всех участников команды, на котором все стоят. Да, неудобно. Зато снижается риск затянуть мероприятие Поэтому обсуждается только самое важное, что будет двигать процесс реализации проекта вперёд.
А именно — каждый участник команды отвечает друг другу на 3 вопроса:
1. Что я делал по проекту
2. Что я планирую сделать
3. Что мне мешает продвигаться вперёд?
Такое короткое собрание помогает обнаружить запараллеливание процессов, понять стадию реализации проекта, сложности, которые нужно решить, а также повысить ответственность каждого сотрудника перед другими участниками команды.
Важно, что решение озвученных проблемных моментов будет происходить уже позже, не на самой stand-up сессии.
Цель такой встречи – удерживать фокус на текущем этапе и в то же время смотреть в перспективу. То есть увидеть, как то, что команда делает сейчас, влияет на реализацию проекта в будущем, и при необходимости вовремя скорректировать план действий.
Пример 2.
Чтобы визуализировать процесс исполняемых задач, можно использовать такой инструмент, как Kanban-доска.
Она может быть, как в виде реальной доски со стикерами, на которых написаны задачи, либо в виртуальном виде, в случае, если команда работает удалённо.
В случае, если это физическая доска задач, сотрудники пишут свои задачи на стикерах и расклеивают их в соответствующие столбцы, в зависимости от стадии выполнения задачи. Таким образом, вырисовывается общая картина работы над проектом в текущий период, а также возникает понимание, на каких этапах проекта наблюдаются «узкие места», где, к примеру, возникает наибольшее скопление задач.
В самом простом виде стадии проекта могут обозначаться как:
1. Нужно сделать
2. В процессе
3. Сделано
Можно также немного разбить процессы на составные части, тогда доска задач может выглядеть таким образом:
При необходимости, можно визуализировать на доске другие этапы проекта, характерные для деятельности конкретной команды.
В процессе утренней Daily stand-up сессии сотрудники, рассказывая о проделанной и предстоящей работе, переклеивают стикеры из одного этапа в другой и могут отчётливее видеть те моменты, которые затрудняют их работу.
На основании такого наглядного анализа могут вырисовываться «срочные задачи», которые тормозят проект в целом. Такие задачи выносятся в отдельную графу на доске визуализации.
Эта активность позволяет понять, успевает ли данный проект быть реализованным в заданные сроки или нужны дополнительные ресурсы, в том числе временные. В этом случае, можно заранее предупредить заказчика о предстоящей корректировке сроков, а не сообщать об этом в последний момент.
Пример 3.
Матрица приоритезации требований заказчиков
Как говорилось ранее, для проектной команды очень важно поддерживать постоянный контакт с заказчиком. Заказчики, в свою очередь могут довольно активно предлагать множество идей для реализации, не все из которых целесообразны или могут быть тут же реализованы. Кроме того, для реализации каких-то идей могут потребоваться дополнительные расходы.
Поэтому необходимо совместно с заказчиком прояснять ценность каждой задачи для его бизнеса.
Работа с ценностями и приоритетами– это тоже коучинговый подход, который может быть легко осуществим с помощью специальной матрицы приоритетов требований заказчиков. Задачи раскидываются по всем квадрантам матрицы в зависимости от их ценности для заказчика и предполагаемых затрат. После чего происходит анализ того, какие задачи мы оставляем в работу (это задачи, попавшие в квадрант высокой ценности при минимальных затратах), а над какими — необходимо подумать относительно повышения ценности или сокращения требуемых ресурсов.
Так что, если вдруг кто-то из вас, читая эту статью, противился мысли о постоянном взаимодействии с очередным Феликсом Сигизмундовичем из рядов ваших заказчиков с целью внесения новых корректировок в проект, то не переживайте! Эти встречи не будут выматывать вам нервы, потому, что, используя данный инструмент, вам не нужно будет слепо кидаться исполнять любую новую безумную идею из 1000 подобных… Работа с этой матрицей на встречах с заказчиком поможет сделать ваше общение максимально продуктивным и по-настоящему вовлекающим.
Что хотят наши заказчики? Качественной и своевременной реализации проекта, а также внимания к своим пожеланиям.
Что хотят руководители проектных команд? Чтобы все участники команды помимо профессионализма имели высокую степень ответственности за результат и были вовлечены в процесс реализации проекта. Это в конечном счёте, приведёт к слаженной работе и созданию продукта, способного удовлетворить пожелания заказчика, а возможно, и превзойти их.
Agile-подход позволяет нам добиться и первого, и второго.
Однако, важно понимать, что в этом случае Agile становится вашим стилем управления и коммуникации. И точно так же, как в традиционных стилях управления существуют свои положительные стороны и риски, управление в стиле agile имеет свои «узкие места».
Когда мы говорим про управление в стиле коучинг, то подразумеваем, что команда, с которой мы имеем дело, достаточно зрелая. Это творческие люди, у которых изначально есть интерес к делу, желание реализовываться, определённое чувство ответственности и вовлечённости.
Мы говорим о том, что коучинг – это всегда работа с осознанностью и со 100% чувством ответственности. И если эти качества ваших сотрудников пока ещё не находятся на нужном уровне, то вам будет довольно сложно применять Agile-коучинг в чистом виде. Поэтому вы можете использовать смешанные стили управления, постепенно «выращивая» свою команду до уровня, на котором вы без риска сможете использовать Agile-подход в управлении.
И это несомненно приведёт вас и вашу команду к новым вершинам! А ваши довольные и благодарные клиенты никогда не захотят променять вас ни на кого другого!
Екатерина Кудрявцева, бизнес-тренер, коуч