Пару лет назад я встретился с родственником. Мой бедный двоюродный брат (генеральный директор страховой компании) продался Agile Silver Bullet и сильно пожалел. Он сказал что-то вроде:
Это надувательство! Мы изменили весь рабочий процесс. Мы пригласили консультантов. Мы наняли этих мастер-PMов. И ничего не работает! Нет никакого результата. Нет никакой ответственности. Все, что я получаю — это отмазки.Я забыл, как я ответил, но я знаю, как бы я ответил сегодня. Я бы нарисовал несколько картинок и даже не упомянул бы слово Agile. Существует несколько ключевых концепций, о которых мне нужно будет ему сообщить.
1. Эффективность потока
Во-первых, если мы посмотрим на время выполнения — время от того, когда мы придумываем идею, до того пока она не дойдет до клиентов — вы заметите, что большую часть времени тратится на “ожидание”. 15%-ная эффективность потока (рабочее время / время выполнения) является нормальной. Ужас, не так ли? Тем не менее мы сосредоточим внимание на том, что (относительно) видно… очень мало времени потрачено непосредственно на выполнение работы. Лучшие компании достигли показателя 40%. Вывод: чтобы продвигаться быстрее, вам нужно устранить время ожидания.
2. Незапланированная работа и многозадачность
Не редкость, когда коллективу платят 75% “за выгоду” в сочетании с незапланированной работой и переключением задач. Коллективу можно даже не платить в принципе. Это буквально надбавка и часто никогда не отслеживается в системе учета. Скорее всего, коллектив будет жаловаться на происходящее (это ужасно скучная ситуация). Коллектив будет игнорировать достаточно долго и примет суровую реальность.
Теперь представьте это “коллективное обслуживание”, коллектив отвечает за решение производственных проблем или за предоставление новой инфраструктуры при одновременном выполнении “проектов”. И тут у вас появится проблема.
Вывод: укажите средства незапланированной работы и определите экономические последствия использования коллективного обслуживания. Коллективное обслуживание имеют интуитивно понятный смысл, но оно часто является причиной дорогостоящего предварительного планирования.
3. S, M и L
Это довольно забавный прием. Запланируйте сроки выполнения для больших, средних и небольших рабочих задач. Попытайтесь подняться над собой и сосредоточиться на элементах фактической ценности клиента, а не на задачах. Во многих организациях вы заметите, что “размер” работы не влияет на сроки выполнения. Почему? Слишком много других факторов, влияющих на продолжительность для завершения работы (напр. исходные данные, предоставляемые заказчиком; незапланированная работа; много работы в процессе и т.д.),
4. Реализация преимуществ
Так много усилий затрачено на сокращение того, что я называю “риском доставки”. Это определение имеет смысл, если вы поставляете индивидуальные проекты, и клиент платит наличные при выполнении. В SaaS (software as a service/программное обеспечение как услуга) нам не платят, когда мы доставляем работу. Выплаты начисляются со временем. Я называю это «выгодным риском» (риск того, что работа будет неудачной).
Для крупных организаций принято использовать Agile, но как таковых финансовых преимуществ не наблюдается. Почему? Развитие происходит быстрее, но оно никак не может повлиять на: 1) принятие правильных решений; 2) процесс по реализации преимуществ. Весь СМЫСЛ Agile — это снизить риск. В проектной работе этот риск можно выразить как проблему: “вовремя / в пределах объема”. В производстве продукта — “эта штука, ***, не работает”. В этом и заключается вся ошибка при заказе когда ”принимается” установление одного из этих рисков. Нет никакой выгоды!
Многие компании используют модель слева. Мало кто согласен с моделью справа. Когда они получают дерьмовые результаты, они пытаются запихнуть больше усилий в систему, которая влечет за собой мир боли.
5. Неуправляемая сложность
Ну и в конце концов, возьмите обычную функцию координат и пропустите ее через вашу систему разработки продукта. Без управления множеством составляющих / рефакторингом / автоматизацией потребуется больше времени для завершения этой функции из года в год. Даже если ваш коллектив останется прежним. То что происходит с 3-го дня к 6-й неделе — это неслыханно.
Agile
Почему я выбираю Agile. Agile бесполезен при условии, что он не является катализатором постоянного улучшения. Scrum и SAFe бесполезны при условии, что они не являются катализаторами непрерывного улучшения. Почему? Потому что факторы, которые замедляют вас, объясняются лишь частично тем, что вы бегаете, записываете истории пользователей и делаете двухнедельные демо-версии. Я бы сказал, что эти вещи относительно незначительны (как только вы погрузитесь с головой в идею постепенного снижения риска).
Чтобы «быть гибким», вам нужно потратить много денег и энергии на:
- Выполнение работы, которая действительно имеет значение (выгоду), значит, делать меньше.
- Автоматизацию, оснастку, конвейер развертывания, функциональное выделение и т.д. (DevOps)
- Изменение культуры управления
- Настройка того, как вы финансируете инициативы. Переход на поэтапное финансирование на основе задач и целей против финансирования проектов
- Выделение ресурсов для преодоления сложностей (регулярная реорганизация кода и изменение архитектуры)
- Сопоставление потоков стоимости и обработка вашего бизнеса экологической службой
- Новый взгляд на совместное обслуживание
Какого-то чудодейственного средства тут не существует. Работу надо делать. Остерегайтесь тех, кто говорит иначе.
Перевод: Влад Дубовский
