Рецензия на книгу Ильи Павличенко «Дизайн Agile-организаций»

Книгу я читал с большим интересном, потому что Илья Павличенко является одним из лучших экспертов в своей области:

1. Консультант по организационному дизайну и стратегии.
2. Работает с топ-менеджментом и собственниками больших компаний, помогая им в создании гибких организаций.
3. Лидер русскоязычного Скрам-сообщества. Со-основатель компании Scrum.ru

Я был уверен, что ему есть что сказать по теме дизайна agile-организаций, и не ошибся.

1. Черновик

Книгу Ильи я прочитал еще на этапе черновика. Подробно изучал все мысли, давал комментарии автору.

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

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

2. Вкусное содержание

Илья всесторонне прошелся по теме того, как должна быть устроена Agile-организация. Вот разделы книги:

1. Системное проектирование
2. Мышление
3. Структура
4. Процессы
5. Люди

Каждая часть книги представляет концентрацию опыта. Мне понравилось, что Илья не просто сказал, как надо делать, но и объяснил причины, по которым стоит выбрать тот или иной подход.

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

3. Критика

3.1. BANI-мир

Книга начинается с утверждения, что современный мир – это BANI-мир, то есть он хрупкий, беспокойный, нелинейный и непонятный. У меня есть претензия к слову «современный» в этом утверждении. Если кому-то показалось, что мир может быть не-BANI, то этот человек просто витал в облаках и не замечал даже ближайшей к себе надсистемы. Об этом я подробно писал в статье BANI – это неожиданная новость для пятилетних детей.

Кстати, к написанию статьи про BANI-мир меня подтолкнула как раз книга Ильи, когда я читал черновик. К сожалению, на автора книги это не произвело впечатления и он оставил свое утверждение без изменений.

3.2. Мультифункциональное развитие

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

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

Это называется мультифункциональностью и, судя по моему опыту, она не работает в реальности. В целом, мне эта идея нравится, она выглядит очень романтично, но есть причины, которые мешают воплотить ее в жизнь:

1. Трата времени на чуждую специализацию – люди не хотят отходить от своей специализации. Программисты не хотят тестировать, не хотят этому обучаться. Этот навык не добавляет ценности в резюме. Эта область разработки ПО им не интереса. Другими словами, люди хотят быть экспертами в той области, где им искренне интересно.
2. Поверхностное погружение не решает проблемы. Когда вы дообучаетесь чему-то смежному, что вам не особо интересно, вы никогда не сможете закрывать сложные задачи в этой области. Тогда чем ты можешь помочь, если задачи застряли на одном из этапов разработки, а твои навыки находятся на уровне новичка? Скорее всего тебе дадут что-то самое простое, что не является причиной затыка. Тогда вообще неясно, к чему эта мультифункциональность.
3. Низкое качество мультифункциональнищков. Когда недо-профи приходят делать работу, то потом профи приходится долго прибираться. Например, аналитик и сисадмин пришли тестировать. У тестировщиков есть свои системы для тестирования, написания тест-кейсов, свои процессы, свои стандарты и много чего еще специфического. Что могут сделать аналитик и сисадмин полезного в моменте? Только потыкать какие-то простые сценарии, как-то зафиксировать результат. Эффект от того, чтобы пустить не-профи тестировать, будет полностью съеден последующей приборкой. Качество работы недо-профи ниже и никак иначе не может быть. Профессиональный тестировщик всегда сделает работу качественней, чем программист, которые «просто мимо проходил».
4. Временщики без ответственности – ответственность у того, кто стоит на своем участке выше, чем у варяга, который пришел на время.

В футболе в случае каких-то проблем с нападающими можно поставить вратаря в нападение. Будет ли от этого польза команде? Приблизит ли этот шаг к победе? Скорее нет, чем да. Добавит ли это стресса вратарю? Конечно добавит, он вряд ли захочет делать эти подмены регулярно, не тому он учился. Усилит ли это нападение? Точно не усилит, потому что вратарь в лучшем случае сможет принимать пасы и давать пасы, а не виртуозно обводить защитников и пинать в девятку кручеными.

Вывод

Хоть я и не согласен с некоторыми утверждениями из книги Ильи Павличенко, но в целом книга великолепная. Рекомендую ее читать всем, кто занимается управлением, а также тем, кто является объектом управления.

Мой отзыв, который Илья любезно поместил в книгу:

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

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