Наталья Гараханова, директор по маркетингу в digital агентстве Black Engine и координатор курса «Создание продукта», дает в Нетологии семь простых советов, которые помогут справиться со стрессом перехода на гибкие методологии и сделать процесс адаптивным.
Все больше компаний переходит с проверенной временем каскадной модели разработки на гибкие методологии 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, когда каждый участник может излить свою душу, поговорить о своей боли и разойтись. Цель ретроспективы — всегда получить четкий план, по которому команда будет работать дальше. |
Быстро решайте конфликтыСамоорганизующиеся и кросс-функциональные команды часто бывают благодатной средой для конфликтов. На первых порах избежать столкновений не получится, поэтому надо научиться быстро устранять их разрушительные последствия. Главное — вовремя выявить конфликт в команде. Он может вспыхнуть внезапно по вполне понятной причине, а может протекать в скрытой форме без видимых причин. Если внимательно наблюдать и обращать внимание на опасные признаки, то можно урегулировать конфликт в зачаточной стадии. Это сэкономит не только много времени в будущем, но и позволит не потерять в эффективности. Если вы не уследили, и бомба все-таки взорвалась, то после нейтрализации последствий столкновения, мудро потратить время на выяснение причины конфликта. Были ли это разногласия по поводу рабочего процесса или межличностные противоречия? Присмотритесь к участникам конфликта, подумайте, что именно могло вызвать такую реакцию сотрудника и какие меры можно принять, чтобы такая ситуация не повторилась в будущем. Призовите сотрудников высказаться открыто, но в конструктивном ключе. Пусть каждый внесет свои предложения по урегулированию ситуации. Если люди сами предложат мирный путь разрешения проблемы, то станут придерживаться его с большим энтузиазмом, так как это была командная идея. В конечном итоге это еще больше сплотит коллектив. |
Если вы задаетесь вопросом — стоит или не стоит переходить на гибкие методологии, то ответ по большей части «да». Есть области, где лучше использовать модифицированную модель водопада. Но в большинстве проектов гибкие методологии помогут сэкономить время, увеличить производительность и наладит процесс. И теперь вы знаете, как начать переход менее болезненно!
Оставить комментарий