Стратегия изменений. Часть 1
Очень вдохновилась тут заметками от Unusual Concept с интервью практикующих agile-коучей и scrum-мастеров. Особенно понравилось интервью с Лешей Пикулевым, и ответ на вопрос:
Пытаюсь анализировать, как двигаюсь я. Многие шаги, которые они перечисляют в ответе на вопрос “Вас закинули к новой команде, ваши действия в первый месяц?“, я совершаю сама. Поэтому кажется, что на верном пути, ну и помню, что единственного верного пути нет :)
Поэтому у меня плавно созрел собственный план трасформации. Чем хочу поделиться. Это тот самый стратегический уровень, про который я упоминала в прошлый раз.
Как мы живем сейчас
Сейчас царит хаос, который плавно стараются перевести из этого домена в простой и свалить все в водопад. Моя же задача перевести в домен запутанный и показать им, что мы действительно не знаем что будет завтра. Подробнее, о чем я говорю, можно почитать здесь.
Команда сейчас находится под огромным прессингом со всех сторон, а именно, они не знают кто к ним может прийти сегодня и завтра. Это могут быть:
- менеджеры проектов, получившие задачу от других подразделений или от реального владельца продуктов
- служба поддержки, успокаивающая всю ночью юзеров, у которых все сломалось
- юристы, потому что законодательство РФ в очередной раз поменялось
- другие смежные продукты, которым нужна интеграция с нами
- реальный владелец продукта, который пообщался с партнерами и они договорились о новом функционале
- начальник разработки, который придумал, как облегчить жизнь разработчикам, и сформулировал это в виде нового технического проекта
- аналитики, которые думали думали и придумали новый функционал, который вроде бы должен выстрелить
- собственные же тестировщики, которые нашли багу
Это далеко не полный список тех, кто может приходить к ребятам в любое время, не учитывая того, чем они сейчас занимаются, впихивать своё и уходить довольными.
При этом, настоящий владелец продукта редко приходит в команды и общается с ними тет-а-тет, он делает это настолько редко, что многие не знают, как его зовут. Приходит он только в единичных случаях и то очень злой, потому что находит баги, которые возникают лично у него. Поэтому за ним закрепилась репутация очень злого человека. Забегу вперед и скажу, что это не так, я с ним общалась :)
В последнее время начальник разработки начал брать бразды по разгребанию всего этого на себя, пытаться выстраивать диалог со стейкхолдерами. Конечно, стало меньше времени уходить на команду, а команда не маленькая, и стали появляться такие функциональные роли как тех.лиды, отдельно про это еще расскажу.
Часть 1
Боремся с хаосом и снимаем с ребят и с начальника разработки всю эту волокиту по общению с любыми стейкхолдерами. Вводим мини владельца продукта, чуть позже я напишу, почему мини. Пока это выходец из команды аналитиков, который месяц поработал, погрузился в продукт и понимает, как двигаться дальше. Он знает ответы на все вопросы “зачем и почему?”, он всегда доступен для команды, команда понимает, в случае чего к нему надо идти.
И вводим профессионального скрам-мастера — это я, конечно же, про себя :)
Теперь:
- владелец продукта всегда с командой и знает ответы на все вопросы, а ребята, в свою очередь, могут начинать задавать вопросы
- у ребят остается больше времени на свою работу, а больше работы, значит больше проблем, ведь команда то огромная
- скрам мастер помогает двигаться команде вперед
Но у такого решения есть свои подводные камни, потому что мы пока никак не задействуем умственные способности нашего мини владельца продукта, он пока простой передатчик. Это утомляет и он и постепенно теряет мотивацию, работая таким образом.
Но об этом в следующих сериях…
Originally published at spotykashka.wordpress.com on July 27, 2017.
