scrum master что это такое
Кто такой scrum-мастер?
Узнайте, кто такой scrum-мастер и как он помогает команде не выбиваться из графика работы
Просмотр тем
Описание. Scrum-мастер поддерживает в команде культуру scrum и следит за соблюдением ее принципов. Этот человек во всем следует ценностям и методикам scrum, при этом действует гибко и всегда готов использовать новые возможности на благо рабочего процесса команды.
Как следует из названия, такой человек действительно мастер, он в совершенстве владеет методами scrum и может сделать так, чтобы остальные тоже придерживались этого подхода. Метод scrum предписывает четкие роли и ритуалы. Scrum-мастер работает с каждым участником scrum-команды, предоставляя необходимые инструкции и ведя обучение с целью добиться воплощения принципов scrum.
Недавно компания Atlassian провела опрос в Twitter, который показал, что 92 % респондентов применяют собственные методы и подходят к правилам Scrum избирательно. Тогда мы задумались: что это означает для Scrum-мастеров, которые должны инструктировать команды и помогать им понять метод Scrum? Какова их роль в постоянно меняющемся agile-мире, где действуют «не по уставу»?
На эти вопросы мы хотели получить ответы, когда углубились в изучение ролей и обязанностей скромных героев agile — scrum-мастеров.
Кто такой scrum-мастер?
Scrum-мастера — это фасилитаторы scrum, легковесной agile-платформы, которая фокусируется на сгруппированных по времени итерациях, называемых спринтами. Как и фасилитаторы, scrum-мастера выступают в качестве коучей для остальной части команды. Руководство по scrum называет их «лидерами-служителями». Хорошие scrum-мастера преданы основам и ценностям метода scrum, но остаются гибкими и показывают команде возможности для улучшения рабочего процесса.
Обязанности scrum-мастера
В идеальном мире Agile команда сама управляет процессами и инструментами. Тем не менее мы обнаружили, что при переходе на Agile многие команды часто полагаются в этом на Scrum-мастера как владельца процесса. Требуется время, чтобы команда осознала и приняла на себя ответственность и обязанности. Чтобы это произошло быстрее, роль Scrum-мастера должна быть небольшой и сводиться к планированию Scrum-церемоний либо соответствовать по уровню вовлеченности ролям других участников команды Scrum. В руководстве по Scrum перечислены не все обязанности мастера по обеспечению работы других ролей в Scrum. Так, мы часто видим, что Scrum-мастер занимается кое-чем или всем из нижеперечисленного, причем не все из этого списка имеет прямое отношение к Scrum.
Нужен ли мне scrum-мастер?
Любой scrum-тренер учит, что в scrum-команде должен быть scrum-мастер. Без него вы будете работать не совсем так, как предполагает подлинный scrum. Подобную ситуацию часто называют «скрам-бат» (scrum-but).
Когда вы только начинаете работать по методу scrum, очень полезно взять на роль scrum-мастера человека, который уже видел, как ведется такая работа. Еще лучше, если он видел множество примеров того, как это работает. Именно поэтому scrum-мастеров часто нанимают как консультантов, а не штатных сотрудников.
Но все scrum-команды разные. Многие опытные команды выполняют все перечисленные обязанности, действуя как единое целое. Они гордятся и наслаждаются совместным управлением процессом. Роль scrum-мастера дрейфует между участниками команды, которые проводят стендапы и ретроспективы по очереди.
Для других команд будет лучше, если один и тот же человек изо дня в день выполняет эту роль.
К сожалению, неправильное понимание роли scrum-мастера часто приводит к тому, что существующие менеджеры начинают считать эти обязанности своими. Чтобы лучше понять, почему это может вылиться в проблему, давайте сравним роль scrum-мастера с ролями, не относящимися к scrum, которые, возможно, уже есть в вашей организации, и обсудим, почему важно не смешивать эти роли.
Scrum-мастер и менеджер по продукту
В обзоре управления проектами по методике agile мы отстаиваем такую точку зрения: чем больше менеджер по продукту будет вовлечен в работу команды разработчиков, тем лучше. Однако ему следует выступать в роли владельца продукта и защищать потребности клиента. Он должен отвечать на вопрос «зачем» в отношении целей разработки. Проблемы начинаются, когда менеджер по продукту составляет списки заданий для команды и ищет ответы на вопрос «как». Такая установка, даже при благих намерениях, приводит к дефектам, перепоручениям и неопределенности. Смешение таких уровней управления, как направление разработки и рабочий процесс, ведет к потере направления, нарушению графика работы и ухудшению качества. Это путь к провалу.
Вот почему владелец продукта и scrum-мастер должны играть в scrum-команде две разные роли. Однако при традиционном управлении разработкой эти роли часто соединяются в одном лице. Да, в небольших командах велико искушение избежать очевидных расходов на второго специалиста. Однако если появляются препятствия или неизбежны изменения, необходимо четко разделять управление процессом разработки и развитием продукта.
Scrum-мастер и менеджер проекта
Нетехническим (или не относящимся к agile) двойником scrum-мастера является менеджер проекта. Обе эти роли концентрируются на том, «как» выполнить работу и решить проблемы рабочего процесса через управление им и координацию. Нужны ли вам обе эти роли? Скорее всего, нет.
И традиционный менеджер проекта, и scrum-мастер помогают команде в выполнении работы, но их подходы очень разные. Менеджер проекта устанавливает и отслеживает временные рамки и контрольные точки, сообщает о прогрессе и координирует взаимодействие в команде. Вместе с тем он делает это с позиции контроля, играя более традиционную управленческую роль.
Scrum-мастер помогает команде улучшать и оптимизировать процессы, с помощью которых она достигает своих целей. Он действует как один из команды, как участник общего дела и в идеале не руководит в традиционном смысле слова. Лучшие scrum-команды практикуют самоорганизацию и потому плохо реагируют на управление «сверху вниз».
Это лишь некоторые из возможных форм управления scrum-командой. Одни организации применяют все эти роли, другие обходятся одной или двумя.
Scrum-мастер и улучшенная организация
При найме scrum-мастера стоит принять во внимание еще одно очень важное соображение. Делайте это только в случае, если организация активно настроена на работу по методу scrum и инвестирует в этот процесс. Все вышеперечисленные роли могут управлять командой разработчиков множеством способов, но scrum-мастер эффективен только при абсолютной приверженности методу scrum. Этим все сказано.
Благодаря scrum-мастеру, который помогает каждой команде управлять процессом, организация в целом может получить несколько серьезных преимуществ. Помимо регулярной поставки ценного продукта клиентам (основная цель scrum), участники команды и менеджеры смогут сосредоточиться на том, что они делают лучше всего. Менеджеры по продукту могут сфокусироваться на стратегии, разработчики получат возможность написать свой лучший код, а Кайл из отдела продаж наконец-то совершит звонок, до которого не доходили руки. На что это похоже? Это похоже на высокофункциональный 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-инженера и физически не могла позволить себе заниматься только улучшением процессов в команде. Я пыталась найти баланс и, как следствие, избежала серьезных проблем от изменения всего и вся в команде. Поэтапное решение помогало не только не закопаться в изменениях ради изменений, но и отслеживать, как какое-то конкретное нововведение повлияло на проблему, которая решалась изначально.
Я хотела изменить несколько вещей в работе команды. Одной из них была физическая доска для дейли. Мне было лень заниматься её оформлением из спринта в спринт. Ситуация усложнялась тем, что эта проблема не затрагивала всю команду. Другая проблема с доской — это реактивное обновление статусов задач. Так как команда находилась в одном кабинете, узнать прогресс по задаче было достаточно легко — спросить коллегу или посмотреть на доску. Трудности в тот момент это не вызывало, но могло поломать процессы в случае продолжительной удаленной работы кого-нибудь из коллег или появления удаленного сотрудника.
Решением первой проблемы было делегирование оформления доски или переход на какой-нибудь электронный инструмент. Второй — развитие культуры поддержания порядка. Кстати, аргумент «когда-нибудь нам это, может быть, поможет» недостаточно мотивирует команду на изменения.
Аргументировать любое изменение
Не нужно бросаться с места в карьер с криком: «Сейчас всё будет!». В самом начале пути скрам-мастерства есть вероятность наворотить процессы ради процессов, это может ухудшить карму. Сначала стоит понять, зачем, а потом транслировать идею команде.
В ситуации с отказом от физической доски, я проговорила команде, что мне сложно заниматься оформлением, а если альтернативного варианта для доски не найдется, то я попрошу команду разделить со мной обязанности по разрезанию и развешиванию стикеров.
Изучить поведение авторитета
Видите, что кто-то в команде удачно рассказывает о своих идеях? К мнению лидера прислушиваются? Можно понаблюдать за тем, как этот человек доносит информацию, скорее всего, он с командой на одной волне. Важно так же настроиться на эту волну.
Душой нашей команды был менеджер продукта. Важность и необходимость фичей, над которыми он предлагал работать, команда разделяла. И дело не только в том, что это были очевидно необходимые и важные изменения. Менеджер аргументировал предложение, освещал плюсы, вносил ясность — это помогало осознать и принять новую задачу.
Найти единомышленников
Одна голова хорошо, а имей сто друзей. Коллективный разум — это прекрасно, но не все вопросы можно выносить на командное обсуждение. Можете найти одного/двух неравнодушных коллег и советоваться с ними. Но разные члены команды обладают навыками в разных аспектах работы, поэтому лучше не держать фокус на паре советников. Расширяйте круг общения.
За новыми идеями по части процессов я обращалась к менеджеру продукта. Острые углы и проблемы мне помог найти инженер по тестированию. На выходе получалось приятное и провалидированное решение.
Необходимый для скрам-мастера опыт помогут получить книги, тренинги и практика. Но количество советов зашкаливает, и трудности вызывает даже приоритезация советов в порядке необходимости. Осознание сложностей — шаг в правильном направлении к поддержанию и построению процессов.
А что дальше?
Теперь, когда хаос упорядочен, можно подумать о работе над конкретными навыками и задачами.
Скрам-мастер: что это за специалист и как им стать?
Скрам-мастер в СИБУРе
Rusbase вместе с командой цифровизации СИБУРа продолжают разбираться в новых специалистах, которые двигают промышленную революцию в России. Мы уже рассказывали про дата-сайентиста и архитектора индустрии 4.0. Сегодня о своей профессии рассказывает Марина Лях — скрам-мастер в СИБУРе.
Кто такой скрам-мастер?
Это довольно популярный вопрос, он всегда возникает, когда речь заходит о моей работе. Например, на днях я оформляла медицинскую карту, и сотрудник регистратуры попросил меня записать должность на бумаге, так как со слов она звучала непонятно.
Односложно объяснить, что это за профессия, не получается, поэтому обычно у меня есть два варианта ответа — попроще и посложнее. В первом случае я говорю, что скрам-мастер — это человек, который работает с группой продуктовой разработки, помогает ей стать зрелой и продуктивной командой.
Могу углубиться в матчасть и рассказать, что скрам — это самый популярный фреймворк agile (гибких методологий разработки программного обеспечения). Agile-фреймворки базируются на ценностях, сформулированных в agile-манифесте.
У скрама есть своя настольная книга — скрам-гайд, переведенный на множество языков, в котором описано руководство по применению подхода. Он дает определение скраму, теоретическую выкладку о подходе, описывает ценности, роли и механизм работы.
Если вкратце, то продукт разрабатывается итеративно, длина итерации (спринта) обычно варьируется от 1 до 4 недель, но может быть выбран и другой интервал. Каждый спринт включает в себя полный цикл работ: от постановки задач до демонстрации готового функционала.
Готовый функционал – это результат каждого спринта, который можно показать пользователю, не дожидаясь завершения разработки всего продукта целиком. Итеративный подход позволяет команде работать слаженнее, быстрее получать обратную связь и вносить необходимые коррективы по ходу разработки, чтобы в итоге получился продукт, который действительно нужен пользователям.
Скрам-мастер помогает команде освоиться с фреймворком и решать различные трудности на пути к созданию идеального продукта.
Несмотря на наличие в названии должности слова «скрам», скрам-мастер не ограничен работой только по этому фреймворку. Он может использовать любые подходы и практики как Agile, так и других концепций, например, Kanban, Lean Startup, а также миксовать разные подходы.
Его задача заключается в умении найти подходящий вариант работы с учетом особенностей команды и проекта. Например, в СИБУРе я работаю с несколькими командами, но не все они работают по скраму. Допустим, когда речь идет о поиске и тестировании гипотез, и нет возможности планировать и оценивать работу итеративно, стоит использовать другие более подходящие подходы и инструменты, например, Kanban.
Как он это делает?
Обычно в команду, которая работает по скраму, входят владелец продукта, разработчики и скрам-мастер. Она может включать фронтенд-, бэкенд-разработчиков, продуктовых дизайнеров, тестировщиков ПО. Хорошо, когда такие команды небольшого размера, поскольку это позволяет упростить коммуникацию между специалистами. По ходу спринта команда занята в следующих активностях:
По ходу разработки продукта все циклично повторяется. При этом красной нитью через все эти активности проходит груминг бэклога. Знаете, есть такие ребята, грумеры, которые регулярно ухаживают за животными и приводят их в порядок? Вот такой же уход нужен и бэклогу — списку функциональности, который планируется реализовать в продукте.
Он может быть сформулирован и помещен в task-трекеры (Jira, trello), размещен в виде стикеров на стене или быть в каком-то другом формате, все зависит от предпочтений владельца продукта и команды. А груминг бэклога – это процесс уточнения деталей по задачам, их формулирование и подготовка к планированию, определение ценности, которую они принесут пользователю. Регулярный груминг – залог здорового бэклога.
Во всех этих активностях скрам-мастер выступает фасилитатором – человеком, который помогает команде успешно коммуницировать и достигать целей встреч. Вспомните, как часто вы бывали на встречах, которые уже с первой минуты становились сумбурными и в итоге шли совершенно не по плану?
Так вот основная задача фасилитатора — фокусировать внимание участников на цели встречи и помогать достигать ее. Именно он организует взаимодействие в команде так, чтобы встречи не превращались в холивар, а работа продвигалась.
Скрам-мастер готовится ко всем встречам, выбирает подходящий формат, собирает обратную связь. Например, с кем-то лучше вести диалог в игровой форме, кому-то удобнее рисовать на доске, а кому-то лучше работается в строгой деловой обстановке.
Другая важная функция скрам-мастера — просветительская. А что такое бэклог? Что мы будем с ним делать? А что это вообще за скрам такой и зачем он нам нужен? Он отвечает на подобные вопросы, объясняет суть agile и скрама в частности, их основные принципы и ценности.
При этом скрам-мастер не только организует команду, но и обучает ее самоорганизовываться. Если через какое-то время ребята начинают собираться, эффективно проводить встречи самостоятельно и договариваться, значит, ты все сделал правильно. Самое главное, настраивая работу команды, не увлечься процессом, а помнить, что главное – результат.
Если говорить не о теории, а о практике, то в СИБУРе я участвую в нескольких проектах. Одни связаны с индустриальным интернетом вещей. Это датчики температуры, вибраций для оборудования, взрывозащищенные устройства и софт под них.
Другие проекты – это AR/VR. Я участвую в разработке продукта «Удаленный эксперт», в рамках которого с помощью очков дополненной реальности эксперты могут провести удаленную диагностику оборудования, не выезжая на предприятие. Еще одна команда, с которой я работаю, занимается видеоаналитикой. Она решает задачи детектирования нештатных ситуаций на заводах СИБУРа.
Как стать скрам-мастером?
Мой путь к скраму сложно назвать прямым. В детстве меня увлекали иностранные языки. Помню, как бабушка мне рассказывала про сына маминой подруги, который сходу может понять, о чем поется в песне на иностранном языке. Я тогда думала, что это невероятно, и тоже так хотела, поэтому мечтала стать переводчиком. В каком-то смысле я им и стала, потому что большинство проектов я вела на английском языке, а еще – в работе постоянно приходилось переводить с технического на бизнес-язык и обратно.
Когда тебе 17 лет, ты не очень понимаешь, кем ты хочешь быть и работать всю оставшуюся жизнь, понимание приходит с опытом. После школы я училась менеджменту, а потом пошла в магистратуру на кафедру финансов.
Параллельно с учебой я работала в Лаборатории роста кристаллов Института неорганической химии (ИНХ СО РАН) в новосибирском Академгородке. Там я занималась внешнеэкономической деятельностью, взаимодействовала с иностранными клиентами. Но когда учеба закончилась, я всерьез задумалась, чем заниматься дальше.
Постоянно мониторила рынок труда и обратила внимание, что в сфере ИТ появилось много вакансий менеджеров проектов. Уже тогда я понимала, что за ИТ будущее, и решила попробовать. После пяти лет работы почувствовала, что пора переходить на гибкие методологии разработки в силу специфики моих текущих проектов. Так из менеджера проектов я стала скрам-мастером.
Теперь точно могу сказать, что нужно не бояться пробовать работать в разных сферах и в разных ролях. Только так можно найти то, что действительно по душе.
В СИБУРе несколько лет назад стартовала цифровизация и появилось много новых ролей. Когда мне предложили пройти собеседование в сфере нефтехимии, я удивилась, потому что скрам-мастеров обычно ищут компании, разрабатывающие программное обеспечение. А какая в нефтехимии разработка ПО? Пообщавшись с командами, я узнала про множество цифровых продуктов собственной разработки, которые СИБУР делает в рамках цифровизации.
У промышленности своя специфика. Здесь я взаимодействую не только с командой разработки, но и с владельцами процессов – они работают непосредственно на производствах и полностью погружены в то, что мы оцифровываем. Еще одна особенность в том, что ИТ-компании часто производят продукты для внешних заказчиков. Ты отдаешь его клиенту и часто не знаешь его дальнейшую судьбу. А в СИБУРе пользователи — вот они, рядом. К ним можно съездить на производство, поговорить, потом посмотреть, как продукт внедряется и работает в реальных условиях и сразу получить обратную связь.
На мой взгляд, если человек хочет стать скрам-мастером, общее понимание процессов разработки очень пригодится, потому что организовать людей, если ты не понимаешь, чем они занимаются, будет сложно. Но мне кажется, высшее техническое образование для этого необязательно.
Я, например, начала разбираться в ИТ на работе, и отсутствие «корочки» по ИТ-специальности мне не мешает: важно находить общий язык с командой, а все необходимое узнаешь в процессе работы.
А вот без базовых знаний agile, разумеется, не обойтись. Здесь пригодится информация из разных источников: скрам-гайд, статьи, книги про agile. Не менее важно общаться с практиками — посещать открытые митапы, где встречаются специалисты, практикующие гибкие методологии. Там можно узнать, как они внедряются в разных компаниях, какие методологии используются, какие бывают проблемы и необычные кейсы. Это поможет быть в тренде и развивать свои компетенции, а еще – это полезный нетворкинг.
Кстати, саморазвитие для скрам-мастера не менее важно, чем изучение методологий, потому что скрам-гайд — вот он, «лежит» в интернете, разобраться в нем достаточно просто. Сложнее развить в себе то, без чего нельзя быть хорошим скрам-мастером.
На мой взгляд, в ближайшем будущем роль скрам-мастера будет по-прежнему актуальна. Возможно, со временем некоторые функции изменятся в связи с появлением новых веяний и подходов к разработке ПО и расширением понимания этой роли.