Антихрупкость в IT. Как достигать результатов в IT-проектах в условиях неопределенности
За пару дней прочитал книгу Александра Бындю и у меня остались очень смешанные ощущения от книги.
Сначала пробегусь по плюсам и разобранным темам
- В начале книги много времени уделяется полезным продуктовым практикам: impact mapping (я уже описывал одноименную книгу на эту тему), customer journey map, user story mapping
- Хорошо разобраны проблемы с большим и формальным техническим заданием (ТЗ)
- Рассказывается про работу с требованиями в agile проектах
- Неплохо обсуждаются причины провалов IT-проектов
- Здраво рассмотрены модели управления проектом: fixed price, time and materials и отчасти fff (fix time, fix budget, flex scope)
- Во второй части дается helicopter view относительно того, как строить процессы разработки в заказной моделе разработки -- Приводится рассказ про монолиты, микросервисные монолиты, микросервисы и дальше оркестраторы бизнес-сервисов -- Где стоит применять low-code платфомы и когда с них пора слезать -- Как работать с legacy системами и как запускать проекты по переходу с них -- Что делать с техническим долгом
А теперь немного про минусы
- Название книги - это отсылка к работе Насима Талеба, который, по-моему мнению, является графоманом, смысл произведений которого обычно легко укладывается в одну страничку
- Книга рассказывает про взаимодействия заказчиков/исполнителей в модели заказной разработки, другие модели не рассматриваются
- Понятия проект и продукт смешиваются и используются взаимозаменямо, что, с точки зрения компании-исполнителя, в модели заказной разработки понятно, но совсем не так в продуктовой компании (подробнее можно почитать в моей статье "Про управление проектами и продуктами")
Иногда я буду писать "проект", а иногда "продукт". Для себя я не разделяю два этих понятия (1 часть, глава 4)
- Часть глав выглядит как отработка возражений заказчика при продаже ему проекта - пример с работой по ТЗ или продажа FFF (fix time, fix budget, flex scope) концепции, которая для меня выглядит как просто по другому названый time & materials:)
- Большая часть графиков в книге приведены просто для иллюстраций мыслей автора - за этими графиками нет чисел и какой-то статистики, чисто иллюстрации
- Вообще, в книге нет следов научного подхода - аргументация строится на примерах из консалтинг практики Александра и альтернативных точек зрения не приводится
- В части про IT все написано настолько кратко и тезисно, что, если ты не знаешь всех источников, на которые ссылается Александр, то остается только поверить на слово
- Микросервисы продаются как ответ на запрос адаптивности к изменениям, а дальше все больше походит на рассказ о том, как запустить проект по переходу с монолита на новое решение и какие технические проблемы надо включить в контракт, чтобы не облажаться
- Много раз звучит рефрен про то, что надо вовремя позвать IT консультанта для технического аудита ... и не только
В общем, я бы назвал книгу "Как заказывать/продавать ИТ-проекты" и отметил бы, что книга может быть очень полезна двум категориям
- Бизнес-заказчикам, которым надо выполнить ИТ-проект и они хотят понять как это сделать и не облажаться
- Исполнителям, что продают свои услуги и выполняют проекты, но не хотят продавать руки по time & materials из-за низкой маржи, а также боятся рисков в схеме fix price:) Остальным рекомендую обратить больше внимания на материалы, к которым отсылает автор и которых к концу книги набежало 100 ссылок вида byndyu.ru/footnote/{id} ({id} от 1 до 100)
#Management #Software #Architecture #Processes #Project #ProductManagement #Engineering #Processes #Consulting