{"id":14291,"url":"\/distributions\/14291\/click?bit=1&hash=257d5375fbb462be671b713a7a4184bd5d4f9c6ce46e0d204104db0e88eadadd","title":"\u0420\u0435\u043a\u043b\u0430\u043c\u0430 \u043d\u0430 Ozon \u0434\u043b\u044f \u0442\u0435\u0445, \u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0442\u0430\u043c \u043d\u0435 \u043f\u0440\u043e\u0434\u0430\u0451\u0442","buttonText":"","imageUuid":""}

Agile: теория заговора

Последние два года я огнем и мечом меняю в командах подход к управлению проектами и продуктами с классического или какого-нибудь самобытного на гибкий – тот самый Agile.

Agile – это система ценностей, на которой основаны несколько методологий управления разработкой продуктов. Вместо того, чтобы долго создавать что-то большое и очень качественное, предлагается сначала создать что-то простенькое, так сказать, на коленке, и убедиться что на этом действительно можно заработать. Дальше — постепенно работать над повышением качества и усложнением функционала или увеличением ассортимента продуктов.

Чаще всего моя работа очень напоминает мультик «Крылья, ноги, хвост», где я участвую в роли грифа. "Полетели", — говорю командам, а они бегут. Но настойчивости мне не занимать, поэтому рано или поздно мы находим способ договориться. Чаще всего драма заканчивается настройкой регулярного менеджмента, которая радует и команду, и заказчика, ну и меня. И тогда я отправляюсь сеять доброе и светлое в следующую команду.

Я: Итерации, Скрам, дисковери, инкремент! Полетели говорю!   Владелец продукта: Нам бы архитектуру с СБ до конца года согласовать…

На самом деле никакого противостояния между каскадом (классический проектный подход) и скрамом (методика гибкого управления) нет. Потому что нормальные менеджеры проектов знают, что управление неопределенностью — это часть управления проектом. И одним из частных случаев управления неопределенностью является методика Скрам.Например, когда перед нами неопределенность, характеризующаяся высокой неоднозначностью, то есть в которой сложно установить причинно-следственные связи между событиями, есть всего 3 эффективных стратегии работы. Последовательное уточнение, эксперименты и прототипирование. Все три стратегии в сумме дают методологию Скрам или ее масштабированные версии.

Короче, мне постоянно приходится рассказывать командам сказку про то, как в феврале 2001 года лучшие воины-разработчики собрались на курорте в штате Юта, и в ходе непродолжительных попыток удивить друг друга лучшими практиками создали манифест из 4 ценностей и 12 заповедей. А потом уже на основе этого манифеста и фреймворков всяких насочиняли такое, что разработчикам во всем мире стало жить гораздо лучше.

- А есть хоть какой-то мануал к колечку? - Эмм, рабочий продукт, важнее документации.

И вот я подумал такую вещь. Нафига им было вообще делиться друг с другом конкурентными преимуществами? И тем более пулять в мир, чтобы все начали жить по их заветам? Причем очевидно что многим продуктам ни пришей — ни пристегни ни экстремальное программирование, ни бережливое производство, ни гибкое управление.

И тогда я вспомнил, что в американской стартап среде очень важно не столько создать единорога, сколько продать его подороже, пока он совсем младенец, а затем еще и еще. Такой вот рынок инноваций.И как вам такая идея? Для того, чтобы консалтинговые агентства могли ставить более низкие оценки управленческих рисков, а банки могли охотней давать инвесторам деньги под меньший процент и была придумана эта конференция и аджайл и все гибкие методологии управления.

Не чтобы командам было удобней и быстрее, а чтобы любая аудиторская компания могла прийти в стартап, и по формальным признакам поставить галочки напротив всех событий, которые предусмотрены фреймворком Скрам. Сказать, кому надо, что качество управления на уровне А, и значит можно продать подороже.

Ну а дальше пошло-поехало. Стало ясно, что все это можно еще и сертифицировать бесконечно, и обучать всех, кого только можно. Соответственно, появились гильдии, институты и тренеры для каждого фреймворка, а вместе с ними — целый рынок.Такая вот теория заговора. Пока мы тут на земле пытаемся натянуть сову на глобус, настоящие парни колотят состояния на консалтинге.

Интересно, что у нас на родине всем вообще пофигу, как там команда управляется… по скраму или нет, морковкой спереди или сзади...Одна надежда на здравый смысл. Ну или на качественный регулярный менеджмент.

0
9 комментариев
Написать комментарий...
Илья

Когда-нибудь я увижу статью где объяснят, почему скрам мастера столько зарабатывают

Ответить
Развернуть ветку
Павел Оберемко
Автор

В защиту скрам мастеров мне есть много чего сказать. Но из сильных аргументов есть такие:

В компании где я сейчас работаю эту роль чаще всего берут на себя аналитики и никто им дополнительно за это не доплачивает.
Здесь работает такая мотивация. С одной стороны выход за рпмки привычной роли - это стратегия саморазвития, ребята действительно получают удовольствие. С другой стороны, это отличный способ продать себя на роль владельца продукта ну или хотя бы менеджера продукта, и многие действительно так строят карьеру.

Второй. Если внимательно вглядываться в вакансии СМ, то часто компании вместо того чтобы нанять отдельных аналитика и менеджера продукта, пытаются получить весь их функционал в одной роли.

Ну и третий. Такой рынок. 🤷‍♂️

Ответить
Развернуть ветку
Илья

Круто расписал, спасибо тебе большое)

Ответить
Развернуть ветку
Andrey Harchenko

Можно более развернуто чем отличается в процессе:
Последовательное уточнение от эксперименты от прототипирование?

Ответить
Развернуть ветку
Павел Оберемко
Автор

Последовательное уточнение. Это итеративный процесс повышения уровня детализации плана управления проектом по мере получения большего объема информации и более точных оценок.
Например на старте проекта нам сложно определить сколько времени будет занимать каждый этап проекта. Мы сможем оперировать только диапазонами. И при хороших раскладах проект можно будет реализовать за 3 месяца, а при плохих за 1 год. Соответственно необходимо часть деятельности направить уменьшение этих диапазонов.
Изначально большие диапазоны связаны с недостатком информации что делать и как делать, касающейся ресурсов, технологии, среды и т.п. Задача Руководителя проекта посвятить часть работы сбору этой информации.

Эксперименты. Серия хорошо спроектированных экспериментов может помочь идентифицировать причинно-следственные связи или по крайней мере снизить степень неоднозначности.
Эксперимент – направлен на установление одной конкретной причинно-следственной связи. Например мы берем гипотезу, что от местоположения кнопки на экране зависит количество переходов, и на нескольких схожих выборках тестируем несколько экранов с кнопками в разных местах. Если получаем значимые различия в переходах, то эксперимент успешен.

Прототипы. Прототипы могут помочь в различении взаимосвязей между различными переменными.
Прототип - это рабочий продукт с ограниченным функционалом. Если мы хорошо его разметим пикселями, то сможем наблюдать эффективность его работы, как системы и экспериментировать с параметрами этой системы.

Таким образом эксперимент это часть процесса создания прототипа или MVP, ну и неотъемлемая часть работы по продвижению и развитию продукта.

Ответить
Развернуть ветку
Ха Ха

Нифига ты крутой!

Ответить
Развернуть ветку
Jan BeLL

Управление неопределённостью. - Вот ключевое слово. Полная хрень, придуманная на западе для того, чтобы с умным видом рассказывать заказчику сказки, и бесконечно вытаскивать из него бабки под предлогом доработок каждой отдельной части проекта.
Удобно для компании реализующей проект, дорого для заказчика.

Ответить
Развернуть ветку
Андрей Дрямкин

Павел Владимирович, уважаю твоё мнение, но не всё так однозначно - они создали себе рынок для получения беззаботных денег )) Если бы не было неудовлетворённой потребности - не взлетело ни со скрамом/канбаном и проч. джайл

Ответить
Развернуть ветку
Павел Оберемко
Автор

Я надеюсь ты понимаешь, что это иронический пост, который позволяет взглянуть на ценность своей работы чуть шире ;)

Конечно "все не так однозначно" )))

Ответить
Развернуть ветку
6 комментариев
Раскрывать всегда