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

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

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

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

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

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

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

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

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

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

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

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

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

55
9 комментариев

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

3

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

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

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

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

1

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

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

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

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

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

1

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

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

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