Нaтaлья Гaрaxaнoвa, дирeктoр пo мaркeтингу в digital aгeнтствe Black Engine и кooрдинaтoр курсa «Сoздaниe прoдуктa», дaeт сeмь прoстыx сoвeтoв, кoтoрыe пoмoгут спрaвиться сo стрeссoм пeрexoдa нa гибкиe мeтoдoлoгии и сдeлaть прoцeсс aдaптивным.
Всe бoльшe кoмпaний пeрexoдит с прoвeрeннoй врeмeнeм кaскaднoй мoдeли рaзрaбoтки нa гибкиe мeтoдoлoгии Agile. Mail.Ru использует их с 2012 года, позже на Agile перешли команды Сбербанка, Dodo Pizza и другие.
Здесь все построено на итеративной разработке — то есть, подход не комплексный, а по частям. Требования к проекту формируются динамически, меняясь по ходу процесса. Agile не содержит практик, а определяет ценности и принципы, которыми руководствуются успешные команды.
Самые популярные методологии гибкой разработки — это Скрам (Scrum), Канбан (Kanban) и бережливое производство (Lean production). Хотя они предназначены для разных задач, но все способствуют улучшению производительности, более быстрому выходу продукта на рынок и повышению эффективности командной работы.
Scrum — наиболее распространенная методология по принципам Agile, поэтому в статье будем опираться на его постулаты, чтобы не сбить читателя с толку.
Переход на Scrum, первоначально сопровождается потерей эффективности и может происходить остро и утомительно для сотрудников и руководства.
Иллюстрации представлены отечественными художниками, чтобы затронуть архетипичные струны таинственной русской души.
Обеспечьте поддержку высшего руководства
Шепелюк. М.И. Кутузов на командном пункте в день Бородинского сражения
Если компания решается начать работать по одной из гибких методологий, то все изменения необходимо начинать с топ-менеджмента. Иначе это может вызвать ощутимый конфликт интересов.
Начиная работать по-новому, сотрудники выходят из зоны комфорта. Привычное уже не работает, а полного понимания новых процессов еще нет. Сотрудники встретят любое нововведение с обоснованным сопротивлением. Могут начаться постоянные жалобы: то «слишком много задач», то «недостаточно ресурсов», то «если по-старому быстрее, то почему надо делать по-новому медленнее?».
Только полная и безоговорочная поддержка со стороны высшего руководства поможет избежать столкновений. Переход проходит более гладко, если топ-менеджмент поддерживает и приветствует командное принятие решений.
Пригласите в команду Agile-коуча или отправьте сотрудников на курсы
Богданов-Бельский. Устный счёт. В народной школе С.А. Рачинского
При переходе на Scrum очень важно выстроить все процессы изначально правильно. Иначе это будет псевдо-Scrum, что приведет компанию к плачевным результатам.
Пригласите для сотрудничества эксперта-практика по гибким методологиям — Agile-коуча.
Он должен быть не из команды, а профессионалом извне, и иметь опыт внедрения Agile в разных ситуациях.
Услуги таких экспертов стоят дорого, и не каждая компания может себе это позволить. Если на данный момент эксперт-практик не по карману, то есть более бюджетный вариант. Выберите людей, которые будут ответственны за внедрение гибких методологий и отправьте их на курсы.
Чтение книг не заменит опыта внедрения Agile в реальной жизни, поэтому обучение сотрудников у профессионалов гарантированно убережет вас от дорогостоящих ошибок.
Выберите Scrum-мастера из команды
Репин. Пушкин в Царском Селе
Что будет, если в сформированный коллектив внедрить нового человека, да еще и заявить, что он будет курировать и направлять процесс разработки? Все побегут плакаться ему в жилетку или объединятся против?
Именно поэтому Scrum-мастер, в отличие от Agile-коуча, должен быть своим в доску.
Миссия приглашенного коуча — смотреть на процесс со стороны и подсказывать нужные действия. Scrum-мастер полностью погружается в жизнь команды.
Это лидер, который старается направить команду в русло соблюдения принципов Scrum. Он помогает команде в коммуникациях друг с другом, поддерживает открытое высказывание мнений среди коллег. Нередко ему приходится разрешать конфликты и улаживать ссоры. Внимательно наблюдая за процессом, за проведением daily-scrum встреч, ретроспектив, чтобы все понимали и принимали Scrum, поддерживая позитивный настрой, всегда готовый прийти на помощь, этот человек своим личным примером мотивирует команду на успех.
Scrum-мастер часто выполняет роль «слуги». На английском языке это звучит как «servant-leader» («служащий лидер»). Scrum-мастер устраняет препятствия на пути команды и обеспечивает ее всем необходимым для эффективной работы.
Если завис сервер, или случились другие технические неполадки, он обращается к системным администраторам и решает проблему. Закупает методические пособия и техническую литературу, обеспечивает досками для брейнстормов и выполняет много другой рутинной работы, чтобы процессы в команде шли гладко.
Когда Scrum-мастер понимает, что проблема не может быть решена на его уровне, он обращается к высшему руководству.
Добивайтесь самоорганизации внутри команды
Репин. Сходка (При свете лампы)
Необходимо дать понять команде, что «главного» нет. Главный — это сама команда, у которой есть общая цель. Наличие общей цели предполагает и общую ответственность. Практика показывает, что в самоорганизующихся командах повышается мотивация. При общей заинтересованности в таких командах развивается доброжелательность и взаимопомощь.
Если что-то идет не по плану, или член команды не справляется с задачей, все помогают друг другу, на благо общей задаче. Никто не будет сидеть сложа руки во время спринта и ждать, пока «Вася пофиксит баги», так как он утащил к себе эту задачу из бэклога.
Спринт — отрезок времени, который берется для выполнения определенного (ограниченного) списка задач. Часто команда разработки выбирает интервал 2–4 недели (длительность определяется командой один раз).
Бэклог Спринта — это список работ, который определила команда и согласовала с Владельцем продукта на ближайший отчетный период (спринт). Задания в спринт-бэклог берутся из product-бэклога.
Бэклог Продукта — это упорядоченный список всего, что может понадобиться в продукте. Это единственный источник требований для любого вида изменений которые могут быть внесены в продукт.
Все понимают, что если Вася этого не сделает или сделает не вовремя, то эффективность снизится, и запланированный результат не будет достигнут. Поэтому баги пофиксит тот, кто менее загружен и уже справился со своими текущими задачами.
Формируйте кросс-функциональные команды
Перов. Охотники на привале
Эффективная реализация бизнес-проектов требует наличия сотрудников, которые обладают знаниями и навыками в самых разных областях. Могут понадобиться инженеры, программисты, дизайнеры, маркетологи, финансисты, ученые.
Прежде всего, работа в такой команде будет мощным развитием soft-skills для ее участников. Эти люди часто говорят на разных языках, и им трудно понять друг друга. Могут возникнуть конфликты. Но если каждый участник команды будет стремиться развиваться и добиваться взаимозаменяемости, то это значительно снизит риск возникновения споров и недопонимания.
Польза кросс-функциональных команд в том, что они способны совершить прорыв, предложить и внедрить нестандартное решение. Разные точки зрения будут подталкивать команду к поиску оптимальных методов реализации проекта и способствовать появлению творческих подходов к решению проблем.
Главное — обеспечить в команде здоровую обстановку и следить, чтобы никто из ее участников не отгораживался от остальных, а свободно делился идеями и мнением.
«Создавай команду-звезду, а не команду звезд» © Джек Уэлч, бывший известный СЕО General Electric Company
Обязательно проводите ретроспективу
Репин. Запорожцы пишут письмо турецкому султану
Ретроспектива — обязательное мероприятие в Scrum. Это командная встреча, во время которой все участники обсуждают и пересматривают работу во время последнего спринта или итерации.
Когда команда сформировалась недавно и имеет не совсем четкие представления о работе по Agile, результатом будет плохое планирование, срыв сроков, и путаница с задачами. Конечно, на помощь придут и Scrum-мастер, и Владелец продукта. Но ретроспектива полезна тем, что помогает команде не только анализировать свои действия, работать над ошибками, но и создавать план улучшений.
Основное правило во время ретроспективы — это соблюдать доброжелательность и давать высказаться всем по очереди. Не следует слишком акцентировать внимание на провалах, лучше подробно проработать план работы над ошибками. Если команда встала в тупик и не может найти решение проблемы, или появились явные разногласия на уровне конфликта, то следует разбить проблему на мелкие части и вносить изменения постепенно, проверяя их эффективность.
У каждой ретроспективы должна быть цель. Не стоит превращать мероприятие в Open Mic, когда каждый участник может излить свою душу, поговорить о своей боли и разойтись. Цель ретроспективы — всегда получить четкий план, по которому команда будет работать дальше.
Быстро решайте конфликты
Худяков. Стычка с финляндскими контрабандистами
Самоорганизующиеся и кросс-функциональные команды часто бывают благодатной средой для конфликтов. На первых порах избежать столкновений не получится, поэтому надо научиться быстро устранять их разрушительные последствия.
Главное — вовремя выявить конфликт в команде. Он может вспыхнуть внезапно по вполне понятной причине, а может протекать в скрытой форме без видимых причин.
Если внимательно наблюдать и обращать внимание на опасные признаки, то можно урегулировать конфликт в зачаточной стадии. Это сэкономит не только много времени в будущем, но и позволит не потерять в эффективности. Если вы не уследили, и бомба все-таки взорвалась, то после нейтрализации последствий столкновения, мудро потратить время на выяснение причины конфликта. Были ли это разногласия по поводу рабочего процесса или межличностные противоречия? Присмотритесь к участникам конфликта, подумайте, что именно могло вызвать такую реакцию сотрудника и какие меры можно принять, чтобы такая ситуация не повторилась в будущем.
Призовите сотрудников высказаться открыто, но в конструктивном ключе. Пусть каждый внесет свои предложения по урегулированию ситуации. Если люди сами предложат мирный путь разрешения проблемы, то станут придерживаться его с большим энтузиазмом, так как это была командная идея. В конечном итоге это еще больше сплотит коллектив.
Если вы задаетесь вопросом — стоит или не стоит переходить на гибкие методологии, то ответ по большей части «да». Есть области, где лучше использовать модифицированную модель водопада. Но в большинстве проектов гибкие методологии помогут сэкономить время, увеличить производительность и наладит процесс. И теперь вы знаете, как начать переход менее безболезненно!
Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.
