{"id":14293,"url":"\/distributions\/14293\/click?bit=1&hash=05c87a3ce0b7c4063dd46190317b7d4a16bc23b8ced3bfac605d44f253650a0f","hash":"05c87a3ce0b7c4063dd46190317b7d4a16bc23b8ced3bfac605d44f253650a0f","title":"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043d\u043e\u0432\u044b\u0439 \u0441\u0435\u0440\u0432\u0438\u0441 \u043d\u0435 \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0432 \u043d\u0438 \u043a\u043e\u043f\u0435\u0439\u043a\u0438","buttonText":"","imageUuid":""}

На смерть Agile

Вы, наверное, уже слышали о методологии (или если вам будет угодно, философии) Agile и о том, что это единственный способ эффективно разрабатывать программное обеспечение. Но как же так получается, что выдающиеся компании и продукты создаются без Agile? Почему в SpaceX нет scrum-мастеров, а в Apple нет специалистов по Agile-коучингу? Молодые успешные стартапы не кичатся тем, что у них свой уникальный подход к гибким методологиям разработки, который дает им уникальное преимущество в скорости разработки. С другой стороны, компаниям среднего уровня и крупным аутсорсерам продают Agile-трансформацию, а некоторые региональные банки кичатся своими Agile-методологиями. Мы, те, кто приносит ценность пользователям, уже поняли, что Agile не является серебряной пулей. Но чем же он является?

Agile — это секулярная религия.

  • Есть манифест наших великих предков. (вспомните несколько пунктов из него? Вот и с заповедями так же…)
  • Есть обязательные ритуалы, которые нужно выполнять.
  • Есть жрецы.
  • Существуют различные церкви, которые сертифицируют жрецов (например, ICAgile, Scrum Alliance и т.д.).

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

Религия начинается из благих побуждений

Как и у любой религии, у Аджайла есть благие побуждения. Ребята, которые его придумали, столкнулись с тем, что методы управления проектами, взятые из производства и строительства, не подходят для софтверных проектов. Именно поэтому они (точнее их последователи) взяли Канбан у Тойоты и придумали Pi-диаграмму, которое представляет собой переложенную на новый лад диаграмму Ганта. Вообще, идеологический разрыв между традиционным менеджментом производства/строительства и менеджментом проектов по разработке ПО связан с тем, что у софтверных проектов большой уровень неопределенности. Именно поэтому мы всегда успеваем построить все здания вовремя, а производства гарантированно отдают качественный продукт в рамках бюджета и сроков.

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

Вспомните свой кнопочный Айфон, который положил начало этому уникальному продукту (продажи которого за год в 4 раза больше продаж всей Икеи). А приложение вашего банка, где можно только смотреть баланс, это же было так здорово? Ой, оказывается что у продукта может быть достаточно масштабный набор качеств на старте, чтобы он был востребован. А еще у продукта есть бюджет, потому что денег физически не бывает бесконечно, даже у Apple (только у Федерального Резерва, но там не занимаются разработкой ПО). А так же у продукта обычно есть примерная дата релиза.

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

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

Ну что ты снова — никто никого не уволит, лучше расскажи главное — Agile учит людей персональной ответственности и мотивирует развивать продукт

Да, терапия принятия ответственности требует не менее 10 сессий (в реальной жизни — минимум полгода), чтобы изменить отношение человека к ответственности, и проводится специалистом, который учился годы с полного согласия и желания пациента. Однако Scrum мастер и ритуалы Agile быстро научат людей принимать ответственность! Кроме того, они мотивируют, поскольку мы знаем, что даже наличие акций не всегда способствует мотивации работать на благо компании. А в данном случае человек сам оценил задачу и сам выбрал метод ее решения и теперь уж точно он кровью и плотью связан с компанией и ее целями.

Но если все так почему так много людей на это покупаются?

Религия не требует рационального объяснения. Она просто дает людям в нее погруженных чувствовать себя лучше веря в свои идеалы и отправляя свои ритуалы. Ни один священник не вылечил молитвой рак, но продолжает говорить о том, как провидение поможет исцелиться. Все мы знаем, что провидение и химиотерапия эффективнее чем провидение, но вот эффективнее ли химиотерапия с провидением, чем без него? Здесь у нас есть сомнения, хотя без сомнения вера как источник психологического ресурса может быть полезной. В общем, Аджайл это способ для тревожных людей справляться с тревогой проводя рандомные ритуалы.

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

Лично мне никогда не требовалось НАСТОЛЬКО много внимания, поэтому я хочу просто ставить задачи и чтобы они были выполнены. Однако я осознаю, что мой стиль управления токсичный, потому что я не даю переносить задачу из спринта в спринт с умным видом people-focused лидера.

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

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

Но ведь Аджайл это в первую очередь модель коммуникации, а вопрос коммуникации все равно встанет с ростом коллектива

В данной модели церковные деятели отвечают за менеджмент, и каждому менеджеру приписывается “agile-священник”. К недовольным такому соседству отправляют инквизицию. Цель заключается в служении закону божьему (аджайлу), а не в том чтобы делать продукт.

Люди найдут способ общаться между собой, если:

  • Вы не ставите сертифицированного переводчика между ними и бизнесом.
  • Вы подбираете людей, которые могут общаться друг с другом, а не только хорошие сотрудники.
  • Вы не мешаете им общаться, возводя фиксированные процессы общения.
  • Вы направляете общение, используя правильные площадки (не создаете одну общую группу в Телеграмме на 100 человек, например).
  • Вы держите команды маленькими
  • Вы увольняете тех, кто не умеет общаться.

Но ведь аджайл ставит впереди всего пользователей и продукт

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

Командам нужен фасилитатор чтобы коммуницировать эффективно.

Фасилитатор это независимый человек. Не из компании. Человек работающий в компании уже не может быть фасилитатором, потому что у него есть интересы в этой компании. Но я бы задумался зачем нужен фасилитатор в команде. У вас бракоразводный процесс? Корпоративный конфликт? Кто-то взял кого-то в заложники? Если люди не могут делать свою ежедневную работу без фасилитации — единственная фасилитация которая нужна это фасилитация переговоров об увольнении.

А как же самоорганизация?

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

Причем здесь смерть?

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

А как нам тогда жить, скажи отец?

Это каждый пусть решает сам. Но есть несколько общих рекомендаций.

  • Для начала подумать зачем вы или ваши коллеги внедряете какие-то ритуалы? Для того чтобы уменьшить свою тревогу или потому что это реально помогает?
  • Закрывать потребности в религии, если она у вас есть, настоящей религией.
  • Нанимать хороших менеджеров, увольнять плохих.
  • Делегировать проекты вместо задач.
  • Дать свободу принятия решений тем, кому она нужна для дела, и дать понятную структуру тем, кому свобода и ответственность не нужна.
  • Воспринимать проекты как ставки.
  • Помнить, что проекты нельзя завершить, можно только прекратить.
  • Периодически спрашивать у менеджеров как идут дела.
  • Вместо один-на-один встреч ходить с коллегами на ланч.
  • Вместо оценок 360 полагаться на интуицию.
  • Учиться быть хорошим человеком и затем уже хорошим менеджером.
  • Делать вещи.

Подписывайтесь на мой телеграм-канал @dailykuznetsov. Я публикую в нем короткие заметки о том, как веду международный бизнес, а также о цифровых продуктах и финансах.

0
60 комментариев
Написать комментарий...
Николай Гончаров

"Делегировать проекты вместо задач" - правильная мысль

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

Да, это называется Scrum. Сюрприз!!!

Ответить
Развернуть ветку
Ivan Kuznetsov
Автор

есть немного разное понимание проекта. В моем мире — любая фича это проект. В скраме обычно выбирается набор задач из бэклога, которые войдут в спринт, планируются/оцениваются, и идут в разработку. Да, в идеале, каждый спринт должен завершаться, с новым функционалом который приносит ценность и можно было бы это обозначить как проект. На практике, это просто итеративный производственный процесс где бэклог переходит в фичи. К тому же — в процессе планирования участвует менеджер, иногда продакт-овнер, скрам-мастер. Кто в итоге планирует — команда или они, на практике сложно отличить (очевидно что человек способный к лидерству способен заставить команду делать как он хочет, так чтобы команда думала что она это хочет делать именно так). Можно ли считать это делегированием команде?

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

Еще раз повторюсь, вы не знает предмет, как и те, кто городит оргструктуры и процессы вокруг вас.
Scrum-команда работает над продуктом, а не над проектом. Отличие проекта от продукта - в жизненном цикле, очень упрощая проект конечен и органичен, продукт бесконечен и не ограничен. Аналог проекта - спринт, в рамках которого создается продакт-инкремент, который аналог скоупа проекта, с той разницей, что в спринте, вероятнее всего, происходят улучшения фич , реализованных в прошлых спринтах, так как в отличие от проекта, в спринт никто не должен пытаться впихнуть все фичи продукта в их полном объеме. Если это происходит, то чем тут виноват скрам?
Основной прикол коротких проектов-спринтов - перестать делать то, что уже всем понятно для продукта не нужно. Как Scrum-команда определяет, что это делать больше не нужно? Так по итогам ревью и анализа метрик использования продукта. Если ваш продукт-оунер и тим-лид не умеют в метрики, значит у вас нет итеративной и инкрементальной разработки. Если ваш продукт-оунер не знает, что нужно пользователям и не умеет это определять, и вы берете задачи из бэк-лога наугад или потому-то что так сказал биздев, то почему в этом виноват Scrum и Agile, а не вы сами?
В Scrum команде полностью делегирована ответственность за продукт. Но требования к продукту появляются от пользователей и стэйклохдеров, а не выдумываются командой на пустом месте. И, конечно, пользователи и стейкхолдеры должны влиять на приоритизацию задач в бэк-логе в момент планирования спринта, продукт же делается для них и по их заданию. Однако, в отличие от классических методологий, требования не декомпозируются до финальных задач, потому что никто не знает в начале работы на продуктом или спринтом всех деталей большинства требований, а то и вообще нужны ли эти требования. В этом и есть свобода команды - свобода выбора финальной реализации и изменения требований.
Суть же Scrum очень проста - послушали пользователя, записали на бумажку, то как его поняли, запилили как сумели - показали пользователю, внесли коррективы, уточнили понимание всех сторон, запилили новую версию или перешли к новым фичам. А если вы совсем экстраверт, а пользователь совсем хам, то скрам-мастер просто научит вас разговаривать друг с другом и слышать и уважать друг-друга. Нет ничего проще Scrum )))

Ответить
Развернуть ветку
Ivan Kuznetsov
Автор

"Scrum-команда работает над продуктом, а не над проектом." — за исключением ранних стадий, над продуктом работают несколько команд.

"В Scrum команде полностью делегирована ответственность за продукт." — ответственность обычно у того, кто рискует (деньгами, карьерой), делегировать ответственность не делегировав риск невозможно.

"Суть же Scrum очень проста - послушали пользователя, записали на бумажку, то как его поняли, запилили как сумели - показали пользователю," — кнопочный айфон часто показывали пользователю, как и многие другие продукты (gpt, ракеты spacex, впрочем назовите любой продукт, которым пользуетесь). Более того, пользователь, или даже внутренние стейкхолдеры способны дать вменяемый фидбек по прототипу, mvp етц.

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

1. Для сложных продуктов есть разбиение на вертикальные подпродукты (или чит с созданием внутреннего продукта, когда какая-то общая для всех часть функционала выделяется в продукт для других команд), Scrum of Scrums и SAFE. Если же вы про ситуацию, когда у вас есть команда фронта, команда бэка, команда поддержки, команда дизайнеров и бедные менеджеры "ставят туда задачки", то это просто не Scrum, тут хотя бы до проектного управления и матричной структуры дорасти, да.

2. Продукт Оунер должен быть одним из ключевых стейкхолдеров, а мотивация разработчиков должна быть подвязана на результаты, показываемые разрабатываемым продуктом. А, разрабы говорят, что от них ничего не зависит, они просто хотят зашипить код и получить лавэ? Ну тогда какой-то же вам Agile? Работайте, как на заводском конвейере тогда, просто закрывая задачки, не понимая откуда они пришли и зачем они нужны.

3. Вы путаете требования и реализацию. Судя по всему у вас отсутствуют базовые навыки проведения интервью и работы с потребностями пользователей. Ну и опять тогда причем тут Agile?

Ответить
Развернуть ветку
Ivan Kuznetsov
Автор

1. SAFE это чистый кровавый энтерпрайз, как и прочие попытки масштабирования Agile

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

3. Я плачу продактам не для того, чтобы они спрашивали у пользователей, что им нужно. А для того чтобы они делали то, что пользователь купит. Нужен пользователю blackberry с лучшим экраном и большей батарейков. А купит он Айфон. Интервью это один из инструментов проверки гипотез, заказчик и пользователь не знают что им нужно.

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

Вы даже до максимы "пользователю не нужно сверло на 3/4, ему нужна дырка на 3/4", которая сама спорна, потому что пользователю нужны не дырки для горшков или полок, а уют и порядок, а еще кого-то пытаетесь критиковать. Короче, вы сам источник всех своих проблем. Удачи вам в нелегкой борьбе с собой!

Ответить
Развернуть ветку
Ivan Kuznetsov
Автор

"вы сам источник всех своих проблем. Удачи вам в нелегкой борьбе с собой!" — так можно сказать про любого человека )

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