Я получил книгу от автора с автографом и решил, что обязательно ее прочитаю. Выделил время и детально изучил Метод параноика, описанный Вадимом Митякиным.
Позиция, с которой я читал книгу и с которой буду писать рецензию:
- Я уже 17 лет в коммерческом IT, до этого учился 5 лет на инженера-программиста.
- На данный момент у меня уже 12 лет своя IT-компания, где мы создаем с нуля ключевые бизнес-системы для крупного бизнеса.
- Я автор книги Антихрупкость в IT и Карта гипотез, множества курсов и тренингов для инженеров и руководителей.
Возможно, если вы видели IT только издалека, или вы недавно начали свой путь в этой сфере, то о книге у вас сложится другое впечатление, сильно отличное от моего. Тем не менее я не буду гадать за другие ЦА, а расскажу про то, что увидел сам.
В этой рецензии я сначала поделюсь общим впечатлением, потом будет критика, дальше то, что мне очень понравилось, а в конце сделаю вывод и поделюсь своими ожиданиями от следующей книги.
1. Общее впечатление
Книга подводит к тому, что самый эффективный подход к созданию сложных IT-проектов – это модель похожая на создание фильмов. В киноиндустрии за всё отвечает продюсер: организует пробы, понимает как организовать процесс создания, отвечает за результат, руководит созданием фильма и максимально вовлекается в решение задач. Вадим много раз возвращается к этой метафоре и сам себя позиционирует как продюсер. Книга рассказывает его эзотерический (персональный, внутренний, субъективный) опыт в управлении IT-проектами.
К сожалению, прочитав всю книгу, вы так и не узнаете, как лично вам прийти к тем же блестящим результатам, которые автор приписывает своим проектам. Автор свой опыт не систематизировал, чтобы им можно было воспользоваться в отрыве от самого автора. Книга выглядит как автобиография с призывом «делай как я».
Например, вы решили стать продюсером и создавать динамические команды. Как это делать? В какой ситуации и как поступать? Исходя из каких принципов и практик действовать? Ответом на эти вопросы нет в книге.
В этом я вижу главную проблему всей книги – метод отсутствует. Вот типичный отрывок, где Вадим говорит нам делать хорошо, а плохо не делать:
Чтобы проектировщик мог передать разработчикам действительно работающие решения, он должен иметь опыт в соответствующих областях. В противном случае его решения будут просто «абстракциями на заданную тему», нежели чем действительно путеводной картой для проектной команды. Иными словами, не существует такого универсального навыка, позволяющего проектировать любые системы на любых технологиях для любых прикладных отраслей. За полезностью проектировщика, помимо его системного подхода, должен стоять реальный опыт создания систем...
Если вы думаете, что дальше в книге идет описание конкретных инструментов, с помощью которых проектировщик и команда добиваются успеха, то ошибаетесь. И так по всей книге автор повторяет нам: просто делайте хорошо, что тут неясно?
2. Вопросы к автору
Пока я читал книгу у меня возникали вопросы к автору, которые я собрал в этом списке. Сейчас будет жестковато, но без этого мое впечатление будет однобоким. После я вернусь к позитивным сторонам книги.
Поехали:
1. А существует ли «Метод параноика»? Не является ли метод просто персональной способностью Вадима к созданию IT-проектов? Если метод есть, то передаваем ли этот метод от автора другим людям?
Я хочу увидеть конкретные инструменты «Метода параноика». Автор несколько раз говорит, что они будут опубликованы в следующей книге. Что ж, я прочитаю и ее. Если там будет по-настоящему методологически проработанный и хорошо обоснованный метод, то буду очень рад о нем узнать.
2. Продюсер — это разве не Владелец Продукта? В чем разница? А если ее нет, то зачем придумывать новый термин, который не добавляет новых смыслов? Я ориентируюсь на стандарт и схему из этого видео. Кто понял разницу между продюсером и Владельцем продукта, напишите ее в комментарии, пожалуйста.
3. Про то, что бизнес должен напрямую участвовать в создании продукта, я слышал еще в Экстремальном программировании (книге 25 лет) и там это называлось Customer Onside. Зачем по-своему пытаться объяснить то, что уже имеет название?
4. Зачем нужно было вводить свои термины сложности систем? Вадим пишет о проектах типа Мозги, Седина и Процедуры. Уже 25 лет есть Кеневин фреймворк, в котором всё это подробно изучено и описано. Что добавили новые термины автора?
5. Зачем столько максимализма? В книге автор напирает на то, что никто не читает документацию, никто ее не пишет, никто не занимается проектированием, заказчик никогда не умеет управлять IT и так далее многократное повторение про «никто» и «никогда». Это чтобы напугать читателя или автор правда верит в то, что пишет? Выглядит необъективно.
Хуже всего в этом замесе необъективности пришлось маркетологам. Вадим, не будучи профессиональным маркетологом, написал целую главу об их бесполезности. Это выглядит жалко. Уверен, что автор уберет эту хулу на маркетологов и заодно извинится перед экспертами в этом деле.
Хотелось бы увидеть объективный взгляд автора на действительность, а не сталкиваться с его фантазиями и травмами. Больше анализа, меньше эмоций.
6. Есть в книге глава про банковские приложения. Сначала автор пишет о двух заказчиках, называя их имена, а на следующей странице обвиняет их в манипуляциях и чуть ли не в мошенничестве. Во-первых, я считаю неэтичным так отзываться о клиентах, с которыми работаешь. Во-вторых, призываю Вадима быть последовательным в своих этических воззрениях: если проект был так неприятен, то хочется узнать отказался ли он от проекта и вернул ли он деньги, которые ему заплатили? Если нет, то вообще неясно, зачем было сотрясать воздух этими обвинениями в адрес заказчиков? Показать их манипуляторами, а себя Д’Артаньяном на белом коне?
Если подвести общую черту, то в книге бросается в глаза отсутствие конкретики, необъективность, эмоциональность и придумывание новых терминов, которые не добавляют новых смыслов. Это меня сильно расстроило, я ожидал большего.
3. Что понравилось
Есть много хоть и разрозненных, но точных мыслей об устройстве IT-отрасли. Например, понравилось про тендеры и ТЗ. Вадим написал, что искать подрядчиков на сложные проекты через тендер – это бессмысленное занятие, с чем я согласен. Или, например, что основная проблема сложности создания IT-продуктов – это высокая неопределенность, с которой нужно постоянно бороться.
Была классная метафора про то, что создание сложных продуктов – это как игра в шахматы, когда нужно думать о каждом следующем шаге. А также про то, что процесс похож на съемку многосерийного фильма, когда всё от всего зависит и нужно уметь удерживать рамку процесса.
Понравилось, как Вадим пишет о месте IT в бизнесе в целом. Тут мы с автором сходимся, вот моя статья на эту тему. Прочитайте статью и, если вы с ней не согласны, то обязательно прочитайте книгу Вадима. Он подробно раскрывает тезис о том, что IT служит для обслуживания бизнес-модели.
4. В итоге
Для меня на данный момент «Метод параноика» выглядит как манифест, который еще нужно доказывать конкретными методами и инструментами. Метод сформирован довольно рыхло и сыро. Уверен, что автор большой профессионал в своем деле организации IT-проектов, но по моему мнению передать этот опыт в форме книги у него пока не получилось.
С другой стороны, хорошо, что в книге есть широкий взгляд на основные моменты в создании ПО. Это было интересно читать. Кажется, что эти мысли могут быть полезны бизнесу, который раньше не вникал в IT, а также начинающим инженерам.
Надеюсь, что в следующей обещанной книге Вадим предложит набор конкретных инструментов для своего метода. Вторая книга покажет может ли быть «Метод параноика» отделим от автора.
Комментариев нет:
Отправить комментарий