Я начала кодить в 12 лет: 2000 год, Turbo Pascal 7.0, привет! Образование у меня тоже техническое, судя по диплому, я должна была стать программисткой. Нравилось ли мне это? НЕТ!
Но IT-сфера – однозначно моё. Поэтому в 2013 году я нашла себя в роли менеджера IT-проектов. Летом 2017 года попала в международную компанию. Менеджерила в проекте “VEON Engagement Platform”, который внезапно «закончили» (об этом можно найти много статей). Так я перешла из Beeline Евразия в Beeline Казахстан.
Меня зовут Катя Тен, и сегодня я расскажу про внедрение Scrum и что я думаю по этому поводу. Скорее всего, эта статья будет интересна менеджерам, Scrum-мастерам, Agile-коучам и тем, кто начинает работать или работает по Scrum в средних и крупных компаниях.
Как мы внедряли Scrum
После закрытия моего проекта компания предложила не уходить, а попробовать себя в Agile, точнее – в Scrum в роли Scrum-мастера. По секрету: тогда я думала, что меня просто не знают куда девать и таким образом сливают =) Я ничего не знала о будущей профессии, понимала, что это «как-то связано с разработкой», поэтому решила попробовать. И втянулась.
2018–2019. До внедрения Scrum продукты разрабатывались по водопадному принципу годами: сначала полгода обсуждений и согласований бюджета, долгий анализ, затем выбор вендоров и наконец реализация, по итогу получаем не то, что хотели.
Решили все-таки попробовать in-house разработку. В качестве пилота запустили новый подход в нашей дирекции (IT): 1 продукт = 1 кросс-функциональная команда. За пару дней прошли с командой тренинг по Scrum, закик-оффились – всё по-фэншую. Итого по окончанию пилота (запуск MVP за 2 месяца) в компании приняли решение запускать по Scrum остальных, а это плюс ещё 5 команд.
Какие проблемы решали:
Бюрократия: бессрочные доступы разрабам на скачивание ПО для работы.
«Выбивали» нормальные ноутбуки, мониторы, SSD, ОЗУ и т. д.
Первый год был сфокусирован на развитие инфраструктуры для разработчиков. По мне – это самое важное. То, с чего нужно начинать.
2019–2020. Команд становилось больше, проблемы, которые мы решаем, – масштабнее. Коронавирус, мотивация, культура, общение. Интересно, что из-за локдаунов спада производительности команд не наблюдалось. Скорее всего, потому что инфраструктура хоть и имела ряд ограничений, но в целом была готова к переводу сотрудников на формат удалёнки. У нас уже практиковали формат гибрида: можно было работать удалённо несколько раз в неделю.
Какие проблемы решали:
Нехватка живого общения и выгорание.
Получение доступов в корпоративные сервисы, обновление сертификатов вне локальной сети.
Фокус был на том, чтобы сотрудник мог работать комфортно – со своего или рабочего ноутбука, не выходя из дома. Плюс нужна была не только техническая поддержка, но и поддержание здоровой обстановки в командах.
2020–2021. Развиваем продуктовый майндсет: от целей через метрики к валидации гипотез. Запускаем SAFe-поезда (Scaled Agile Framework), реинкарнируем Change Agent’ов 2.0 – инициативы, которые влияют на организационные изменения в компании.
Какие проблемы решаем:
Удержание сотрудников. Из-за удалёнки двери в иностранные компании открылись для всех умных и знающих иностранный язык. Рынок программистов из стран СНГ начал меняться. Все, кто как-то мечтал или хотел работать за рубежом, решились на это. Если уехать в другую страну бывает страшно, то сейчас можно поработать на иностранный рынок не переезжая. А если понравится – релоцироваться. Плюс к этому – ЖИРНАЯ зарплата в валюте, с которой мы пока не можем конкурировать. И да, конкуренцию на местном рынке тоже никто не отменял.
Новая стадия выгорания – год без отпусков в 4 стенах, конечно же, доканает любого. Помимо этого, на удалёнке есть возможность пофрилансить. Никто же не видит, чем ты занимаешься помимо основных задач. Фриланс не всегда идёт на пользу. Получается, что ты фигачишь на работе + у тебя есть дополнительная нагрузка. Как итог – идеальное выгорание, с которым потом бороться нам. (Это, скорее, моя гипотеза).
Количество команд выросло до 40, в среднем это около 150 человек, не считая саппорт-функций. Управлять стало очень-очень тяжело. У большинства команд больше двух бизнес-оунеров, соответственно, цели у всех разные. Поэтому сфокусировались на запусках поездов (там, где много пересечений) и дискавери команд со сквозными целями с командами разработки.
Кого и как мы теряем, переходя на Scrum
Дисклеймер: наблюдая за развитием Scrum в нашей компании и у коллег, с которыми часто общаюсь, могу сделать небольшие выводы. Эта статья – моё видение и мнение. Возможно, оно не совпадает с вашим. Поэтому хотелось бы обсудить это в комментариях, пишите – не стесняйтесь!
Незаменимые
Scrum может привести к потере незаменимых членов команд. Как именно? Всё просто – работа спринтами. Люди, не готовые работать в авральном режиме, быстро выдыхаются. Представьте, что каждый день вы должны показать результат. Если результата нет, но при этом вы много чего сделали, это демотивирует. Гиперответственному человеку и перфекционисту, наверное, сложно прийти на DSM без результата.
Такую работу можно сравнить с гончими собаками. Начиная забег, у гончих есть цель в виде кролика. Они бегут на полную мощь, ведь главное – добежать до цели. Кто первый прибежал, тот и победил. Но мало кто знает, что после такой гонки собака не может бегать ещё очень долгое время. Потому что у неё был забег на измор. Чтобы восстановиться, нужно время.
Попробуем переложить это на людей. Каждый раз мы собираемся всеми силами, чтобы сделать этот рывок, а как итог – через год-два в компаниях демотивированные сотрудники, которым ничего не приносит радости и мотивации: ни отпуск, ни новые продукты. Всё потому, что у них не было того самого восстановления: физического и морального отдыха.
Особо хочу подчеркнуть, что это происходит не со всеми. Если правильно выстроить процессы, такого вообще не должно происходить.
Как это лечить самому
Если честно, пока я не знаю. Потому что сама такой была: работала на измор, иногда понимая, что «что-то идёт не так и все задолбало». Но лично у меня есть пара моментов, которые не позволяют работать ручками во внерабочее время:
Муж и маленькие дети. После 6 я полностью занимаюсь семьей.
В выходные – только отдых и никакой работы. Уезжайте подальше от цивилизации, если любите тишину. Тусите в клубах, если любите движуху. Для любого человека важно восполнять ресурсы, и у каждого процесс восстановления свой.
При этом не нужно ожидать от компании или команды, что они за вас что-то порешают, насильно отправят в отпуск, заберут ноутбук, предложат другой вариант и т. д. Мы – взрослые люди. Поэтому прежде всего нужно думать о себе самостоятельно, а не перекладывать это на других.
Уверена, что если вы будете работать в таком же режиме еще парочку лет, то вам захочется запереться подальше от всех и никого не видеть и не слышать.
Что делать организации
Отправлять сотрудников в отпуск вовремя! Не разрешать работать без отпуска.
Если есть дежурства, давать отгулы, а не дополнительные деньги.
Взращивать кадры: брать джунов и околоджунов – тех, у кого есть желание и время.
Не замыкать всё на одном сотруднике. Если внедряете или разрабатываете что-то новое, вовлекайте, как минимум, двух людей.
Прививать сотрудникам привычку делиться опытом и знаниями. Создавайте для них подходящие площадки.
Не наши
Да, Scrum отлично помогает с опознанием: наш и не наш. После перехода на Scrum сразу отвалятся те, кто не подходит компании по продуктовому майндсету.
В каждой команде были те, кто не любит Scrum, как думаете, почему? По моему мнению, Scrum быстро выявляет тех, с кем нам не по пути, это и неплохо, просто каждый привык работать так, как ему комфортнее. Обычно такие ребята сопротивляются всему новому, не любят ивенты, им лишь бы по ТЗ работать и ни с кем не разговаривать, а мы, представьте, хотим, чтобы они с конечным пользователем заговорили и делали то, что нужно конечному пользователю.
На самом деле, майндсет людей поменять можно, если человек сам захочет этого, только важно правильно это сделать.
Рекомендации тем, кто чувствует себя некомфортно в продуктовой команде
Дайте этому шанс! Попробуйте или, как это модно говорить, – пропилотируйте. Только обязательно запишите на старте, какие у вас ожидания от пилота, а в конце подведите итоги. Важно понять, получили ли вы «тот самый эффект» или нет. Кстати, в этом вам наверняка сможет помочь Scrum Master или Team Lead.
Если все-таки продуктовая команда – не ваше, а компания в целом вас устраивает, попробуйте поговорить с руководителем. Расскажите какие у вас сложились обстоятельства, спросите, есть ли альтернативы. Дайте компании шанс, уйти вы всегда успеете.
Спрашивайте на собеседовании, как работает команда.
Что делать организации
Решайте на старте, куда лучше определить будущего сотрудника и как это сделать. Для этого можно на старте проверить продуктовый ли майндсет у человека. У меня есть простая задачка для такой проверки:
«Представь, у тебя 100 000 баксов, ты собираешься открывать интернет-магазин вещей/запчастей (неважно, всё зависит от увлечений человека). Как будешь наполнять витрину товаром?»
Из рассуждений или уточняющих вопросов сразу будет понятно, куда лучше определить человека. Если в итоге кандидат решит спросить потенциального клиента, провести ресёрчи, посмотреть на рынок и т. д. – его нужно определять в продуктовую команду. Иначе лучше отправить в другую команду, которая пилит кор-задачи или, например, переписывает чьё-то легаси.
Если все ваши вакансии только в продуктовые команды, человек на собеседовании крут, но точно не про вас – не берите его, пожалейте всех. Когда командные цели разные, вряд ли удастся реализовать что-то крутое.
Если с рынком всё негусто, заранее обговаривайте с кандидатами условия работы, чтобы ожидания соответствовали реальности.
Бюрократия больших компаний
Часть людей уходит из-за бюрократии и внутренних процессов. У нас тоже такое иногда случается: компания относительно большая (4K сотрудников), понятное дело, на каждый чих есть процедуры и куча людей, у которых нужно всё согласовать. Это довольно логично: чем больше людей, тем больше процессов, чтобы управлять этой махиной. Но бывает, что в команду разработки приходит человек из стартапа, и ему сложно.
В корпорации нужно быть готовым к тому, что не всё решается быстро. Те вопросы, которые в стартапе можно решить за один разговор, у нас займет вечность. Мой любимый пример – пересмотр зарплаты согласно рынку. Вроде как рынок изучили, зарплату пересмотрели, но пока согласовывали, рынок в очередной раз убежал.
В общем примеров много, но это не значит, что корпорация – зло и не стоит туда идти работать.
Советы тем, кто пришёл в такую компанию
Не миритесь с тем, что работает нелогично, пробуйте это менять.
Если не получается самостоятельно что-то изменить, эскалируйте выше. И, да, если хочется быстрых изменений, приходите с возможным решением проблемы, а не просто с «нытьём».
Делитесь результатами изменений со всеми заинтересованными лицами – в команде продвигать такие инициативы намного проще, чем в одиночку.
Что делать организации
Если вы нацелены занять определённую нишу среди разработки IT-продуктов (это сфера, в которой быстрее всего происходят изменения), нужно быстрее меняться. Особенно нужно менять процессы, которые уже очевидно не работают или требуют оптимизации.
Такое можно менять в рамках Change Agent’ов. Генерить идеи и change-стори, а потом прорабатывать задачи с теми, кто «держит» процесс. Тут важно помнить, что организационные изменения – это совсем не быстро.
LEAN всему голова. У нас есть целое подразделение, которое оптимизирует процессы, облегчая жизнь другим, вовлекая в это всё всю организацию. Это работает очень круто.
Менеджеры становятся «Do'ерами»
Тут всё просто. Часто менеджеры становятся решателями всех проблем команд. Команды несут и несут свои проблемы, по итогу менеджер становится сотрудником своих сотрудников. Это происходит потому, что никто в команде не готов взять ответственность и начать решать проблемы самостоятельно, без привлечения менеджера, а менеджер не может отказать.
Что делать, если понял, что ты «Do’ер»?
Задайте тому, кто пришёл с проблемой, вопрос: «Что ты пытался сделать до того, как пришёл, и почему это не помогло?» Уверена, часть людей ответит, что не подумал, что можно сделать что-то самостоятельно.
Учите сотрудников приходить с решением, а не с проблемой. Наверняка тот, у кого есть проблема, знает, как её решить, но, например, у него нет полномочий.
Не делайте из себя «узкое горлышко». Всё, что можно делегировать, – делегируйте.
Решайте проблемы согласно приоритету: сколько команд столкнулось с этой проблемой и на что она влияет. Так будет проще понять, за что браться. Применяйте в работе инструменты по приоритезации.
Сделайте свою работу прозрачной. Можно записывать свои таски в JIRA/notion/trello, чтобы у всех команд был к этому доступ. Это спасёт вас от тысячи сообщений: «Когда что-то решится?!»
Не бойтесь просить помощи, если понимаете, что не «вывозите».
За свою работу Scrum-мастером я сделала несколько выводов
Всем не угодишь. Иногда нужно смириться даже с потерями «незаменимых». Да, страшно, «Как же мы без него/неё?», «Все развалится на следующий день!!!» и т. д.
Могу сказать на своём примере: ничего не развалится. Да, какие-то процессы будут идти дольше, да, возможно, работа будет не на том уровне, как хотелось бы – но дай шанс тем, кто есть и новичкам. Со временем ситуация наладится. Также немаловажно дать шанс отдохнуть от нас и тому, кто уходит. Иногда человеку нужно посмотреть, как устроено всё в других компаниях, сравнить прошлый опыт с новым и вернуться «домой».
Если есть поддержка «сверху» и поддержка от тех, кто с тобой всегда за любой кипеж (обычно всегда есть пара таких человек) – то море по колено! Пробуйте что-то новое, если то старое не сработало. Все компании разные, а люди – тем более.
Развивайте корпоративную культуру так, чтобы это было «тортом», а не «вишенкой на торте».
Используйте продуктовый подход везде, не только в IT-продуктах.
PS: Scrum ли приводит к потерям?))
