Классика Project Management-a Vol. 3:"Проект Феникс" и "Kanban. Альтернативный путь в Agile"

Всем привет.

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

Почему это может показаться важным

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

Почему это заинтересовало конкретно меня

Мы в Smilart по-старинке используем всем известный Scrum с недельными итерациями, ретроспективами, стендапами и всеми остальными необходимыми атрибутами. Но часто бывает так, что правила этого процесса со временем приходится нарушать: добавлять задачи во время спринта, пропускать ненужные порой демонстрации, не тратить кучу времени на планирование, не использовать концепции User Story или Story Points. В общем, пытаемся заниматься реальной работой и не тратить время на неработающие в нашем случае церемонии, которые требует Scrum. Масла в огонь подливает шаблон JIRA для Scrum проектов, который в работе постоянно намекает, что "вы что-то делаете не так".
В общем, со временем у меня всё крепло ощущение, что нам нужно что-то другое, более гибкое, но дающее важные свойства для бизнеса: готовность к изменениям, достаточная производительность и "заканчиваемость задач". Понятно, что до каких-то идей можно дойти самостоятельно, но чем дальше, тем больше во мне крепло ощущение, что вряд ли я один впервые задаюсь этими вопросами. Программистское нутро активно предлагало воспользоваться идеологией продвинутого компилятора, который тем лучше оптимизирует код, чем больше данных из исходного кода способен в себе анализировать. И эти две книги как раз об этом.

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

Проект Феникс

Полное название книги - "Проект "Феникс". Роман о том, как DevOps меняет бизнес к лучшему".

И вот прямо в названии тут небольшой подвох: это книга не для инженеров-гиков, которые слышали про DevOps и хотят почитать про соответствующие инструменты. Это книга - объяснение для менеджеров. Зачем именно им внедрять DevOps в своей компании. Формат повествования - бизнес-роман. Есть вымышленная компания, которая занимается большим offline бизнесом по торговле запчастями для автомобилей. У неё большой ИТ штат для поддержки её front office и back office. И как всегда - конкуренты жмут со всех сторон и уже всё меньше шансов, что получится их догнать. В добавок, как на зло, в компании внезапно увольняются руководители ИТ отдела, оставляя разгневанных директоров наедине с ИТ-шниками, которые уже зашиваются постоянно тушить пожары. И одному из оставшихся менеджеров предлагают занять пост руководителя этим бардаком. Он сперва, как неоперённый птенец, мечется из угла в угол и офигевает от происходящего, потом его знакомят с гуру технического менеджмента, который уже вытаскивал компании из подобных ситуаций. И этот гуру постепенно начинает раскрывать новоиспечённому директору заповеди эффективных организаций. Особенно меня умилял эпизод, когда гуру объяснял, почему разработка ПО и завод имеют очень много общего, несмотря на устоявшееся мнение в индустрии об обратном :)

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

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

Читал я именно русское издание этой книги, а не оригинал. Качество перевода - вполне достойное, его делали наши "люди из отрасли", поэтому проблем с терминологией я там не нашёл.

Kanban. Альтернативный путь в Agile

Не Scrum-ом единым, или как написано в одном из отзывов о книге - "Agile for adults" :)

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

Если вы хотите сосредоточиться на процессе разработки как на процессе получения ценностей для компании, а не просто выполнении шаблонных действий и слепо доверяя коучам по Scrum - это книга для вас. Если у вас, как и у нас возник "адаптированный Scrum",- тоже посмотрите на Kanban. С ним вы не будете чувствовать, что натягиваете сову на глобус. Kanban допускает, что компании уникальны и одним строгим процессом всех случаев не покрыть. Но даёт методику оценки текущих процессов, объясняет, почему надо "начинать заканчивать работу и заканчивать её начинать", как начать процесс трансформации с минимальным сопротивлением от участников и заручиться доверием у руководства, и самое главное - даёт инструмент, который "подсвечивает" те моменты в текущих процессах, которые негативно влияют на процесс получения ценности. 

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

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

Дополнительно отмечу приятную фишку книги - в конце каждой главы есть сводка с основными мыслями и выводами, что положительно влияет на "усвояемость" книги.

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

В общем, кажется достаточно большой гештальт по теме управления проектами я наконец закрыл. Можно вернуться обратно в чтение уже чисто технической и более приземлённой литературы по CI/CD/DevOps и как создать эффективные регламенты для них в компании. Но это уже совсем другая история ...