scrum менеджер есть ли такая профессия
Разбор полётов. Уроки и выводы начинающего Scrum-мастера
Источник фото
Уже третий год я внедряю ценности и принципы Agile в жизни команд разработчиков. За плечами – работа Scrum-мастером в двух крупных компаниях, опыт удаленного внедрения гибких методологий в совершенно разных отраслях, бесчисленное количество прочитанных книг и посещенных митапов.
Но начиналось всё с малого, и за это время я набила не одну шишку. А со временем стала замечать, что шишки эти были довольно типовыми, и коллеги-новички сталкиваются с ними на регулярной основе. Не желая оставаться в стороне, и дабы предостеречь коллег от возможных неудач, решила поделиться своим опытом в этой статье.
Итак, какие уроки я извлекла и выводы сделала в первый год работы в роли Scrum-мастера (о которых кратко пунктами изложила в самом конце):
Розовые очки
После двухдневного тренинга по Scrum я была готова сворачивать горы, изменять мир на пути компании к лучшему. Ничто так не вдохновляет, как грамотный коуч и команда единомышленников! Но стоит только начать, как вдруг ты остаёшься один на один со своим фреймворком Scrum. Есть ребята, загруженные собственными задачами, есть привычки и ценности, которые уже сложились в работе команды, есть менеджмент, который по-своему видит процессы, и это не всегда идёт параллельно с ценностями и представлениями Agile. В общем, добро пожаловать в реальный мир.
А потому еще в начале предстоит заслужить доверие и открытость команды. Важно опираться на свой предыдущий опыт и здравый смысл. Поймите, в чём действительно сейчас нуждается ваша команда, какие проблемы и недосказанности существуют и как вы можете им помочь, чтобы закрыть хотя бы часть возникающих вопросов.
Сопротивление
Безусловно, нововведениям и очевидным грядущим изменениям не очень обрадовались. В моем случае скорее это было смирение с тем, что пришёл ещё кто-то, чтобы управлять и учить: «ну ведь и так всё хорошо». Делать нечего – пришлось доказывать, что я пришла помогать, и на практике это демонстрировать.
Важный момент: если в самом начале вы не найдёте в команде разработчиков сторонников, рискуете быть отвергнутыми.
Первое, с чем сталкивается новоиспечённый Scrum-мастер при попытке изменения, – это сопротивление. Процесс, конечно, естественный, но не безболезненный. Люди готовы меняться только тогда, когда видят в этом ценность для себя. Поэтому самый выигрышный вариант – дать возможность команде самой прийти к мысли, что Scrum улучшит и их процессы, и жизнь.
Задайте себе вопрос: «какова цель моего присутствия в этой роли и как я могу помочь своей команде улучшить существующие процессы работы?». Если ответ нашёлся – отлично, вперёд к изменениям! Если нет, то стоит понаблюдать ещё.
Говоря об улучшении – можно провести серию встреч, направленных на выявление болей команды и формирование открытости, к примеру. Но об этом я хочу поговорить в следующих статьях.
Спешка – худший помощник
Спешка и желание показать себя с первых дней работы – наверное, самая большая ошибка начинающего Scrum-мастера. Жизненно важно знать, что резкие изменения без понимания, зачем это нужно и как повлияет на сложившийся уклад жизни команды, может вызвать ещё большее сопротивление и недоверие. Бывали случаи, когда Scrum-мастер вредил командам именно вследствие непродуманных и непроработанных изменений.
Готовность к изменениям наступает у команды постепенно. Понаблюдайте за командой в течение 1-2 недель, не вмешиваясь в «естественный» ход вещей. На первых этапах необходимо понять для себя логическую цепочку процессов и сложившихся ценностей, увидеть уязвимые места в работе и, собственно, предложить решение. Шаг за шагом пытайтесь внедрять события и ценности методологии в сознание и жизнедеятельность своей команды.
В этом вам поможет фасилитация встреч, частое взаимодействие с командой, как личное, так и в формате событий, коучинг. И, конечно, доверие и открытость к диалогу.
Понимание среды
Когда я лишь начинала работу с командой, допустила большую оплошность, которая поначалу не бросалась в глаза и казалась пустяком. А именно – упускала из виду множество тематических чатов разработчиков, которые раскрывали их с другой стороны. Дистанцировалась от руководства и пропускала важную информацию, которую можно было бы, в свою очередь, донести до команды.
Не повторяйте мою ошибку: не важно, маленькая у вас компания или большая, но понимать коммуникацию между отделами и знать лично пару ключевых коллег нужно. Говорят, что Scrum-мастер должен устранять препятствия, отвлекающие команду от создания ИТ-продукта. Но как это сделать, если вы не будете знать, к кому обратиться?
Итак, в самом начале особенно важно:
Присутствие стратегии
И вот мы поговорили с командой и руководством, задали интересующие вопросы, получили на них ответы, зашли во все чаты и получили приглашения на все мероприятия. Мы видим проблему, знаем цели менеджмента – но с чего начать, чтобы её решить, пока не понятно. Что делать дальше?
Для того, чтобы прийти к решению, важно сформулировать чёткие цели того, что именно и почему мы хотим изменить. А после – составить план работ, отвечающий на вопрос, «как мы это будем делать?».
Чаще всего, приходя в команду, я видела, как ребята проводят ежедневные совещания по 1,5-2 часа, на которых пытаются проработать все вопросы. А это, между прочим, – колоссальное количество времени, которое вычитается из рабочих часов и снижает эффективность работ команд. Да и Scrum Guide предполагает на это событие только 15 минут и ни минутой больше.
Как быть: самым правильным подходом, на мой взгляд, является разделение таких активностей и фокусировка на поставленных задачах в рамках целей Sprint.
Отталкиваясь от болей и наиболее частых вопросов, помимо основных событий Scrum (планирование, daily, demo, retro) может формироваться, например, еженедельная исследовательская встреча, обсуждение бэклога идей или же мозговые штурмы для обсуждения углубленных вопросов, как происходит сегодня у нас в ICL Services. Мы видим боль, знаем, как исправить ситуацию и что нужно сделать – остаётся лишь обсудить изменение формата работ с менеджментом и командой для достижения наилучшего эффекта.
План тоже должен быть гибким и изменяться в зависимости от условий и особенностей членов команды. Немаловажно обсудить намеченный путь с руководством, ведь не всегда всё предложенное вами будет немедленно внедрено в работу. А что-то и вовсе может видоизмениться в зависимости от целеполагания и запросов самого руководства.
Нехватка технических знаний
Технического образования у меня нет, а потому досконально разобраться в обширной терминологии команды разработчиков для меня было (и местами остаётся) довольно сложной задачей, учитывая, что технологии не стоят на месте.
Но и здесь есть довольно простые лайфхаки:
Кто эти люди? Зачем я им нужна? и другие проблемы скрам-мастера
Что чувствует скрам-мастер, который знает о скраме только из гайда? Как он пытается помочь команде не развалить и улучшить существующие процессы? Статья о трудностях, с которыми я столкнулась в начале своего пути самурая.
Команда, в которую я пришла как QA-инженер, была уже сформирована: стандартные процессы построены, атмосфера в коллективе — дружелюбная и спокойная. Через год моей работы встал вопрос о том, кто заменит скрам-мастера, который перешел в другую команду. Мне захотелось попробовать. Опыта в управлении и построении процессов не было, но почва для старта доброжелательная. Почему бы и нет?
Сложности
Через неделю эйфории (еее, новая ачивка!) на голову свалилась тысяча и одна проблема (мама, помоги!). Большая часть из них — личные, банальные или решаются прохождением пары тренингов. Я хочу поделиться четырьмя основными сложностями, с которыми может столкнуться начинающий скрам-мастер.
Отсутствие авторитета
Несмотря на то, что я работала в команде год, роль скрам-мастера была для меня новой. Для построения новых процессов авторитет — одна из важных составляющих. Когда пытаешься изменить привычные практики, основываясь только на теоретических знаниях, скептического отношения со стороны команды избежать сложно. Даже введение одной из самых распространенных практик — скрам-покера — было для меня проблематичным.
Тень бывшего мастера
От сравнений никуда не деться. Если до моего появления что-то работало плохо, и после моего прихода ничего не изменилось, возникали запросы: «У нас слишком сложный планнинг, давай сделаем уже что-нибудь с ним!». В случае, когда что-то было удобно для команды, например, физическая доска на дейли, а после появилась я и сказала: «Мне неудобно, давайте менять!», команда не понимала, зачем это необходимо.
Другая сложность связана с коммуникацией. Предыдущий скрам-мастер довольно остро воспринимал отзывы о своей работе, а мне было важно получать обратную связь. В итоге, первый полезный фидбек удалось собрать только через пару месяцев — помогли упорство и разговоры с глазу на глаз. На личных встречах некоторые ребята рассказали, что им было некомфортно критиковать мою работу: предыдущий опыт говорил о том, что задеть чувства скрам-мастера легко, и фидбек воспринимается как оскорбление.
Коммуникация с командой
Идеальный скрам-мастер наблюдает за настроением в команде, анализирует, как работают процессы, понимает, как команда реагирует на изменения. Как не перепутать безразличие к процессу со стороны команды с тем, что уже хорошо работает? Как собрать адекватный фидбек? Здесь мне явно не хватало практики. Особенно сильно эти вопросы беспокоили на ретроспективе, когда на общей встрече на обсуждение выносились незначительные проблемы или не выносились вовсе. Такое происходит, если команда хорошо провела спринт или если проблемы умалчиваются.
Синдром волонтера
В начале пути хочется выложиться на максимум, чтобы команда сразу осознала, какая я крутая и как много могу. Почему я должна делать меньше, если могу делать больше?
Способы решения
Универсального решения для всех трудностей быть не может. Ниже перечислю шаблоны поведения, которые мне когда-то помогли привыкнуть к новой роли.
Решать проблемы поэтапно
Роль скрам-мастера я совмещала с должностью QA-инженера и физически не могла позволить себе заниматься только улучшением процессов в команде. Я пыталась найти баланс и, как следствие, избежала серьезных проблем от изменения всего и вся в команде. Поэтапное решение помогало не только не закопаться в изменениях ради изменений, но и отслеживать, как какое-то конкретное нововведение повлияло на проблему, которая решалась изначально.
Я хотела изменить несколько вещей в работе команды. Одной из них была физическая доска для дейли. Мне было лень заниматься её оформлением из спринта в спринт. Ситуация усложнялась тем, что эта проблема не затрагивала всю команду. Другая проблема с доской — это реактивное обновление статусов задач. Так как команда находилась в одном кабинете, узнать прогресс по задаче было достаточно легко — спросить коллегу или посмотреть на доску. Трудности в тот момент это не вызывало, но могло поломать процессы в случае продолжительной удаленной работы кого-нибудь из коллег или появления удаленного сотрудника.
Решением первой проблемы было делегирование оформления доски или переход на какой-нибудь электронный инструмент. Второй — развитие культуры поддержания порядка. Кстати, аргумент «когда-нибудь нам это, может быть, поможет» недостаточно мотивирует команду на изменения.
Аргументировать любое изменение
Не нужно бросаться с места в карьер с криком: «Сейчас всё будет!». В самом начале пути скрам-мастерства есть вероятность наворотить процессы ради процессов, это может ухудшить карму. Сначала стоит понять, зачем, а потом транслировать идею команде.
В ситуации с отказом от физической доски, я проговорила команде, что мне сложно заниматься оформлением, а если альтернативного варианта для доски не найдется, то я попрошу команду разделить со мной обязанности по разрезанию и развешиванию стикеров.
Изучить поведение авторитета
Видите, что кто-то в команде удачно рассказывает о своих идеях? К мнению лидера прислушиваются? Можно понаблюдать за тем, как этот человек доносит информацию, скорее всего, он с командой на одной волне. Важно так же настроиться на эту волну.
Душой нашей команды был менеджер продукта. Важность и необходимость фичей, над которыми он предлагал работать, команда разделяла. И дело не только в том, что это были очевидно необходимые и важные изменения. Менеджер аргументировал предложение, освещал плюсы, вносил ясность — это помогало осознать и принять новую задачу.
Найти единомышленников
Одна голова хорошо, а имей сто друзей. Коллективный разум — это прекрасно, но не все вопросы можно выносить на командное обсуждение. Можете найти одного/двух неравнодушных коллег и советоваться с ними. Но разные члены команды обладают навыками в разных аспектах работы, поэтому лучше не держать фокус на паре советников. Расширяйте круг общения.
За новыми идеями по части процессов я обращалась к менеджеру продукта. Острые углы и проблемы мне помог найти инженер по тестированию. На выходе получалось приятное и провалидированное решение.
Необходимый для скрам-мастера опыт помогут получить книги, тренинги и практика. Но количество советов зашкаливает, и трудности вызывает даже приоритезация советов в порядке необходимости. Осознание сложностей — шаг в правильном направлении к поддержанию и построению процессов.
А что дальше?
Теперь, когда хаос упорядочен, можно подумать о работе над конкретными навыками и задачами.
Кто такой scrum master: обязанности
Узнайте, как стать scrum master
Scrum master — это специалист, который следит за соблюдением принципов scrum на всех этапах работы. Он обучает команду самоуправлению, а также использованию методов скрам для повышения эффективности и достижения поставленных целей.
Содержание
Обязанности scrum master
Скрам — это методология гибкого управления проектами, которая предусматривает три главные роли.
Скрам-мастер тесно взаимодействует с другими участниками процесса создания нового продукта. Он активно помогает им в работе, однако он не устанавливает что, как, когда и кому делать, как это может показаться. Ознакомьтесь с его основными обязанностями:
Поскольку на плечах скрам-мастера лежит большая ответственность за работу команды и ее результативность, его часто сравнивают с менеджером проекта. В следующем разделе вы узнаете об отличиях между этими двумя специалистами.
Чем scrum master отличается от менеджера проекта
Самое первое и главное отличие scrum master от менеджера проекта — это его цель. Он сосредоточен на совершенствовании работы команды, повышении самоуправления ее членов и улучшении коммуникации внутри нее. Менеджер проекта отвечает за бюджет, планирование, соблюдение сроков, управление командой и результаты проекта.
Скрам-мастер — это коуч, тренер и мотиватор. Благодаря повышению самоорганизации членов команды и улучшению понимания между ними он помогает работать эффективнее и быстрее достигать поставленных целей. В скрам-мастеры часто приходят специалисты из смежных областей. Например, бизнес-аналитики, менеджеры проектов, бизнес-консультанты, маркетологи, представители IT-сферы и просто заинтересованные в личностном росте фрилансеры. Далее вы узнаете, что нужно, чтобы стать scrum master.
Как стать scrum master
Стать скрам-мастером можно независимо от своего образования и существующих навыков. Для этого необходимо большое желание, время на обучение и успешная сертификация. Последнее является неотъемлемой частью успешного и конкурентоспособного специалиста.
Для обучения в этой области сегодня доступно множество материалов. Вы можете использовать книги, а также онлайн-курсы на Coursera, Udemy, EdX и других платформах. Чтобы стать сертифицированным специалистом и получить конкурентное преимущество на рынке, нужно пройти сертификацию. Ниже вы видите лишь некоторые компании, которые предоставляют эту возможность:
Наибольшим авторитетом и популярностью пользуются сертификаты первых двух компаний. Сертификация и обучение в них платное. Срок действия сертификатов зависит от компании. Одни необходимо подтверждать через каждые несколько лет, другие — бессрочные.
Чтобы не потратить время и деньги зря, начните свой путь скрам-мастера с изучения кейсов специалистов. Углубитесь в специфику работы, изучите обязанности, плюсы и минусы профессии. Проанализируйте, какие навыки у вас есть, а какие еще предстоит получить. Изучите все доступные материалы для новичков и ответьте на главный вопрос: «Действительно ли вы готовы работать и развиваться как scrum master?».
Scrum Master или Project Manager: кто нужен вашей команде
Чем отличаются две популярные профессии.
Если на джоб-сайтах ввести в поиск «Scrum Master» — большинство вакансий будут содержать обязанности проджект-менеджера.
Впервые методику Scrum применили в 1993 году, но до сих пор многие работодатели не понимают разницы между Scrum-мастером и проджект-менеджером. Вдохновившись примерами быстрых и эффективных разработок, они тоже хотят работать по Скраму, но не знают, нужны ли им Scrum-команды, ежедневные стендапы, спринты и Scrum-мастер.
Разбираемся, чем Scrum-подход отличается от традиционного менеджмента проектов.
Когда появились первые проджект-менеджеры
Традиционный Project Management стал отдельной дисциплиной в середине XX века, хотя основы управления проектами уходят корнями далеко в историю. Египетские пирамиды, Великая Китайская стена, Колизей так и не стали бы архитектурными шедеврами, если бы не правильное руководство.
Принято считать, что современный проектный менеджмент возник после того, как в 1910-х годах Г. Гант разработал диаграмму, которой проджекты пользуются и сейчас. Это принцип, по которому крупный проект разбивают на небольшие задачи и фиксируют их на временной шкале — получается своеобразный road map.
Проектный менеджмент стал активно развиваться в послевоенное время в Америке. Например, в 1957 году Военно-морские силы США начали разработку ракетной системы Polaris. У них были жесткие дедлайны: ее нужно было завершить раньше, чем СССР создаст свою ракетную систему, угрожающую безопасности США. Проект разбили на 60 тыс. задач, над которыми работали почти 4 тыс. подрядчиков.
Специально для него создали метод PERT (Program Evaluation and Review Technique), с помощью которого можно оценить продолжительность проекта, если время на выполнение каждой отдельной задачи предсказать сложно. Благодаря правильному менеджменту разработку удалось закончить раньше заявленного срока.
В 1969 году был создан PMI (Project Management Institute), а проджект-менеджмент стал отдельной дисциплиной. Вскоре PMI издал «Свод знаний по управлению проектами» (The Project Management Body of Knowledge, PMBOK) — настольную книгу любого PM, в которой собраны лучшие мировые практики в этой сфере.
PMI называет проджект-менеджеров агентами изменений, потому что именно от них зависит успех команды или организации. Project Manager принимает все решения, связанные с проектом: от его запуска до реализации. Стратегическая задача такого специалиста заключается в том, чтобы клиент и команда были довольны работой, качеством коммуникации и финальным продуктом.
По описанию PMI настоящий проджект-менеджер:
Также от PM требуются профессиональные навыки в той сфере, где он работает. Например, проджект в IT управляет командой разработчиков, поэтому ему необходимы технические знания и опыт.
Проблемы, с которыми сталкивается project manager
Scrum-менеджер
Скрам ― менеджером является специалист, который отвечает за соблюдение Скрам-процесса.
Содержание:
История профессии
В 1986 году мир увидела статья «The New Product Development Game» авторства Хиротаки Такэути и Икудзиро Нонаки, где были описаны основные положения Scrum.
В 1990-х Кен Швабер внедрил метод SCRUM фирму, владельцем которой он являлся, с целью увеличить эффективность работы всех сотрудников без исключения.
В 2001 году он совместно с Майком Бидлом издали книгу «Agile Software Development with SCRUM», что содержала детальную информацию об особенностях и пользе метода.
Особенности профессии
Недостаточно просто объединять специалистов, которым поручили вместе работать над определенным проектом. Участники команды должны действовать слажено, научиться находить общий язык и решать поставленные задачи в короткие сроки.
Таким образом, удается не только оптимизировать ряд процессов, но и повысить эффективность работы всего коллектива.
В Scrum ― команду, помимо менеджера также входят команда разработки и непосредственно владелец продукта. Последний отвечает за получение наибольшей ценности продукта, составляет перечень требований относительно его функциональности, утверждает бюджет. При этом команда разработки включает в себя работников разных направлений деятельности.
Профессия Scrum ― менеджер является востребованной и достойно оплачиваемой.
Она остается наиболее подходящей для специалистов, которым нравится работать с людьми. Следует учесть тот факт, что он не принимает ключевых решений по проекту. Специалист вправе только направлять и мотивировать остальных сотрудников компании.
Обязанности
Scrum-менеджер ― это специалист, который:
Важные качества
Необходимые качества, которыми должен обладать менеджер:
Навыки и знания
Scrum-менеджер ― это специалист, который должен практиковаться в «мягких навыках» (soft skills), быть хорошим слушателем и обладать качествами лидера.
Ему необходимо знать особенности процессов разработки и поставки. Дополнительно, следует научиться разбираться в групповой динамике команд и конфликтологии.
Перспективы и карьера
Профессия Scrum ― менеджер предусматривает несколько направлений продвижения по карьерной лестнице:
Обучение
Курс Scrum позволит ознакомиться с эффективными подходами относительно разработки продукта, а также ― освоить тонкости организации гибких проектов. Программа одинаково полезна как для опытных специалистов, так и для новичков в данной сфере.
«Scrum Alliance» ― всемирно известная школа по Скрам. Чтобы получить сертификат об успешном обучении, потребуется обязательно посещать офлайн тренинг.