{"id":14291,"url":"\/distributions\/14291\/click?bit=1&hash=257d5375fbb462be671b713a7a4184bd5d4f9c6ce46e0d204104db0e88eadadd","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? Почему в 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 )
Соберите требования, оцените сверху и разбейте их на этапы-проекты, в рамках каждого проекта произведите детальную декомпозицию, уточните сроки и пилите себе спокойно продукт законченными кусками фич в рамках проектов, не переживая, что продукт еще не может быть использован вообще.
В рамках проектной деятельности полно способов повышения видимости и получения обратной связи - вехи, опытная эксплуатация, эскизное проектирование... Если вам нужно работать по ЕСПД - работайте. Вряд ли только у кого-то хватит на это денег и терпения )

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

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

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

Вы писали когда-нибудь "Обоснование выбора программных средств" на 200 страниц, а потом "Обоснование выбора проектных решений" на пять томов перед разработкой системы? Я писал. )
Отличие Scrum от традиционного подхода в том, что в нем требования уточняются в процессе проекта и через разработку. Когда как в традиционном подходе требования уточняются и фиксируются в рамках нескольких этапов проектирования, предваряющих разработку в рамках проекта.
Блин, вы рассуждаете о предмете, не имея базовых понятий о нем, которые рассказываются на 4-5 курсе института )
Какое у вас образование вообще, если не секрет?

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

Вы писали когда-нибудь "Обоснование выбора программных средств" на 200 страниц, а потом "Обоснование выбора проектных решений" на пять томов перед разработкой системы? — это же не вопрос скрам или не скрам, это вопрос принятых верхнеуровневых стандартов в документообороте. При этом, внутри могут быть скрам-команды вполне, но наружу вам придется отдавать тома документации все равно.

У меня три класса церковно-приходской школы, а что?

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

Ну про отсутствие базового образования в computer science и результирующую кашу в голове сильно заметно. Стандарты документирования хех

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