Скрам-мастер vs мастер реальности
«Здравствуй, мама, я руководитель! Сейчас как все разрулю! как бы так всех организовать, чтобы больше ничего не делать.. Тем более когда есть такой выбор!»
_________________________________________________________________________
А что же организовывала я? И кто я такая вообще?
Меня зовут Яна. Мой стаж в ИТ 13+ лет, а начался еще в университете, ведь я инженер-программист, решившая, что сфера - огонь, но вот код писать - это не ее.
У меня почти 7 лет опыта работы с международными телеком операторами, среди которых Vodafone, Telefonica, Cox, GCI, GTD Chile, T-Mobile и еще ряд других. За этот период я не только прошла опыт от QA инженера до руководителя команды тестирования 70+ человек, но и погрузилась в задачи проектного управления крупными интеграционными проектами с миграцией данных, научилась строить экологические и конструктивные деловые отношения с заказчиками, и еще много чего, о чем расскажу как нибудь в другой раз.
Потом был и опыт работы в Яндексе с почти чистыми скрам процессами, и несколько лет работы в SberDevices, где я окончательно сменила сферу тестирования на управление проектными командами, а также прикоснулась к прекрасному миру разработки устройств со всеми его вытекающими в плане организации работ разрабатывающих их команд.
А теперь я участвую в создании системы спутниковой связи.
С таким багажом я вряд ли когда-нибудь впишусь в шаблонную позицию, такую как scrum-master, да и роль среднестатистического проектного менеджера явно не про меня.
И кто же тогда я? Кажется, я ближе всего к мастеру реальности 😄
_________________________________________________________________________
Да, когда нужно организовать реальность, то неплохо было бы знать методы, которыми это можно было бы сделать. И по моему опыту любой, даже самый крупный проект, смахивающий на waterfall, лучше всего организовывать итерационно.
Какие же сейчас есть наиболее известные гибкие методологии управления проектами и в чем их фишечки:
Scrum основан на итерациях (спринтах), ролях (Scrum Master, Product Owner, команда) и артефактах (бэклог продукта, бэклог спринта).
Kanban ориентирована на визуализацию рабочего процесса с использованием доски (Kanban board) и ограничения количества задач в работе.
Extreme Programming (XP) включает практики, такие как парное программирование, непрерывная интеграция, частые релизы и тестирование.
Lean (Бережливое производство) направлена на устранение потерь (муды) и оптимизацию процессов. Часто используется в сочетании с другими Agile-подходами.
Dynamic Systems Development Method (DSDM) фокусируется на быстрой доставке бизнес-ценности и активном вовлечении заинтересованных сторон.
Feature-Driven Development (FDD) ориентирована на разработку функций (фич) и их поэтапное внедрение.
Crystal - семейство методологий, которые адаптируются под размер команды и сложность проекта. Основной акцент делается на коммуникации и гибкости.
Adaptive Project Framework (APF) адаптируется под изменения в требованиях и фокусируется на достижении бизнес-целей.
Scaled Agile Framework (SAFe) - методология для масштабирования Agile в крупных организациях и проектах. Включает элементы Scrum, Kanban и Lean.
Large Scale Scrum (LeSS) - подход для масштабирования Scrum на большие команды и проекты.
А еще Nexus, Disciplined Agile Delivery (DAD), Agile PM, Rapid Application Development (RAD), Agile Unified Process (AUP), DevOps, Scrumban, Agile Portfolio Management (APM), Agile Modeling (AM), Agile Data Method, TDD и еще ряд более мелких или молодых.
Ну что? уже разбежались глаза от многообразия выбора? Пошли гуглить детали? или же пролистали со словами “ну и к чему мне этот шаблонный текст? я и так все знаю”?
Так что же все таки из этого ЛУЧШЕ выбрать и есть ли это ЛУЧШЕЕ решение, давайте разберемся дальше.
Внедрять или не внедрять? Вот в чем вопрос
Как мы все любим волшебную пилюлю, которая решит все наши проблемы. А есть ли она?
Прежде чем что то внедрять - для начала лучше честно и развернуто дать себе ответы на следующие вопросы:
Какой список проблем есть у вас на проекте / компании?
А какие проблемы есть в организации работы в команде?
Почему вы считаете, что тот или иной инструмент вам поможет?
Какие побочные эффекты может принести?
Все ли его ритуалы вам пригодятся в полном объеме?
Главный то вопрос конечно мой любимый “чтобы что?”, но он уже всем опостылел, да и не все сходу могут ответить на него так же содержательно, как на ряд более мелких.
_________________________________________________________________________
Почему же я так люблю эти вопросы? И откуда я их вообще взяла?
С одной стороны они лежат на поверхности для любого +- опытного человека, но с другой стороны, когда мы в потоке или в рабочей горячке - наш взгляд замыливается, и мы можем действовать либо на автопилоте, либо по совету руководителей, либо на основании чужого опыта и знатоков из интернетов, которые не знают вашу боль, контекст и проблематику.
Ровно поэтому я для себя держу их в загашнике.
Еще лет 8 назад, когда я работала с телеком операторами и достигла определенного уровня знаний, мое руководство начало подключать меня к различным соседним проектам с целью по быстренькому улучшить ситуацию, повысить прозрачность работы команды и исправить те или иные организационные проблемы, которые в конечном счете влияли на успешность проекта и сдачу его в срок заказчику. И конечно же, мое подключение начиналось с фразы “им надо внедрить вот ЭТО и все будет супер!”
Под ЭТИМ могла скрываться и определенная методология проектного управления, и различного уровня отчетность, и ритуалы взаимодействия с заказчиком.
Шла ли я внедрять то, что просят? Ни разу 🙂
Я всегда просила дать мне немного времени, чтобы погрузиться в текучку и рутину команды, дать себе ответы на вопросы выше и только потом предлагала план действий с различными внедрениями, которые на 95% отличались от того, что меня просили сделать изначально, но которые все таки приводили к желаемой цели.
Подобный опыт не закончился для меня в той компании и так и преследует по сей день, поэтому эти вопросы у меня уже как мантра где-то на подкорке.
_________________________________________________________________________
Какие еще факторы, на мой взгляд, стоит учитывать при внедрении той или иной методологии, да и в целом при организации работы команды:
сколько команд задействованы в функционале?
насколько они атомарно работают?
можно ли сделать работу этих команд более атомарной или параллелить их работу?
какая специфика продукта?
стоят ли долгосрочные цели перед командой? и есть ли более приближенные milestone?
есть ли заранее известный скоуп работ (например, подписанный контракт с заказчиком) ?
есть ли специфика задач, из-за которой они не могут быть выполнены любым членом команды?
Каждый из этих пунктов не является ограничивающим, но может добавить свою специфику и не должен быть упущен для успешного достижения результата
А может ну все эти пункты, вопросы и сложности, и есть универсальная таблетка?
Наверное скрам мастер на моем месте сказал, конечно есть! Ведь столько же крутых исследований, показывающих эффективность Scrum подходов.
Но вот, на мой взгляд, нет.
Я не хочу сказать, что методологии не работают, или среди них нет полезного. Наоборот, масштабы любого слона надо понимать, но есть то его проще частями, а самое главное гибкие методологии позволяют в данном случае на более коротких дистанциях понимать, все ли успевается в срок / какие есть проблемы / где можно улучшить подходы / как оптимизироваться в моменте, а не в конце проекта.
Или одна из частых, на мой взгляд, ошибок это когда используют не ту гибкую методологию и, например, на операционную деятельность или команду сопровождения, которой бы возможно (дада, ключевое возможно, так как это тоже не панацея) пытаются натянуть Scrum, в то время когда Kanban подошла как нельзя лучше. Или решили внедрять, а может даже внедрили, но процесс буксует и не дает желаемый результат.
Таких примеров множество. Не буду распыляться, но один свежий хочется рассказать
_________________________________________________________________________
Мы внедрили скрам, но у команды не получается по нему работать - сказал мой собеседник
Я задумалась. Сначала конечно была мысль “о боже опять”, но ее я быстро отогнала и перешла к более полезной рефлексии
А какую проблему вы хотите решить? Что вы хотите получить от данной методологии? Почему вы считаете, что он вам подходит? А чему сопротивляется команда?
После короткого диалога выяснилось, что в компании уже есть ряд успешных бизнес моделей, которые уже приносят свой стабильный доход, но собственник решил пойти на опережение и по ряду ключевых направлений выделить группу специалистов, которые будут не только работать по существующим процессам, но и искать их уязвимости, а может и точки оптимизации, навеянные временем. При этом ребята столкнулись с другой проблематикой, команда не понимала зачем это, да и придумывать новые решения оказалось не так просто (open mind, дивергентное мышление, да и в целом mindset, о которых поговорим как нибудь в следующий раз).
И вот по существу скрам то внедрили, но при цели “мы ищем новые решения и хотим проверить новые гипотезы на коротких итерациях” это внедрение обретает совершенно другой смысл, а главное ценность, и вот она, к сожалению, пока не получена, да и только появлением скрама ее не достичь, проблема сильно шире и не лечится данной таблеткой.
Мы еще немного поговорили о проблематике, и я поделилась своими мыслями насчет того, а как бы я поступила в ситуации ребят.
Интересно, чем завершится эта история, но собеседник ушел очень задумчивый, а как сказано в одной полезной книге “Пока вы не задаетесь вопросами, вы не думаете. Можно сказать так: думать — это значит задать себе вопросы и искать ответы на них.”
_________________________________________________________________________
А еще лично для себя я всегда стараюсь быть в курсе того, что же новенького появилось на рынке.
При этом я ни разу не внедряла ни одну методологию as is, да и на практике может только пару раз видела на 95% рабочую методологию (дада и снова не 100%).
Но зачем же я тогда слежу за тенденциями? К слову к этому я тоже пришла не сразу, собрав ряд шишек на собственном пути, которые и показали мне, что лучше знать и не использовать, чем ходить по знакомым кому то граблям.
Изучая новый подход, я в первую очередь знакомлюсь с проблематикой, которую он решает, а уже потом со списком новых активностей и ритуалов, которые он привносит
А еще не раз даже было так, что читаешь новую методологию, в рамках нее видишь кейс, который уже решали +- также, но по наитию, и тут же для него видишь термин)) и думаешь “вот какие мы молодцы! так вот, что мы, оказывается, используем”)) (например, так было у меня с LeSS и жаль, что в том случае я слишком поздно добралась до манифеста).
Иногда бывает и что наоборот, у тебя уже что то накипело, а какие то умные уже подумали за тебя и придумали анализ и устранение неэффективностей в рамках методологии Lean, да еще и так детально описали, что нужно просто применить.
Поэтому, прежде чем что то внедрять или не внедрять, в первую очередь проанализируй свою ситуацию в команде, ну а дальше не ленись и потрать время на ответы на вопросы 🙂
Ну и если решили внедрять — делайте это гибко и итеративно, ведь вы же внедряете agile, а не waterfall 😉