Прежде всего стоит оговориться. Я читал эту книгу, вернее слушал, за год до настоящих событий. Дело в том, что не возможно работать в ИТ, жить в современном мире и не слышать ни разу о так называемом гибком (эджайл) подходе. Эти слова используются министрами, программистами, руководителями и просто, причастными к технологиям, людьми.
Признаюсь, что я относительно поздно отреагировал на запрос современности и только год назад приступил нахрапом брать эту предметную область. Почему?
Все дело в том, что как аналитика меня прежде всего волнует вопрос методики построения процессов, организационных подходов на производстве и то, от чего должны отталкиваться специалисты, предлагая процессы, предлагая развитие компаниям в процессе постоянного совершенствования. Так, в начале 2019 года обновилась очень известная в ИТ методология ITIL, достигнув 4 версии. Начиная со свода знаний лучших практик в инфраструктуре ИТ, эта методология сейчас включает такие новые веяния как DevOps, Lean и тот самый Agile.
Гибкий подход учли и при обновлении и еще нескольких сводов знаний, а именно свод знаний по управлению проектами PMBoK6 и свод знаний по бизнес-анализу BABoK3.0. С последним кстати я очень плотно работаю и не редко провожу семинары своим коллегам. Но что же я хочу сказать, излагая свои познания о веяниях методик. Хочу сказать о том, что именно повсеместная интеграция гибкого подхода подтолкнула меня год назад приступить к подробному изучению этого понятия, подхода и состава этой предметной области знаний.
Как я уже говорил выше, книгу Кона прослушал второй раз. За последний год я не раз привел коллегам и близким пример работы опытного модератора на покере планирования. Когда во избежание ухода в дискуссию, фасилитатор вежливо предлагает присоединиться к общей оценке тому сотруднику, кто дал оценку, которая отличилась от остальных. Мне понравился сквозной пример в окончании книги, где упомянули методику Кано для определения приоритета полезных для рынка функций. Пожалуй один из самых важных пунктов в книге, это пункт, где предлагают взглянуть на практику оценки и попробовать применить гибкий подход, сочетающий обстоятельную точность с одной стороны и проактивную манеру общей оценки будущих работ с другой стороны. Понятие ценности, которое то тут, то там всплывает по тексту, мне кажется не совсем явно, но подталкивает читателя к пониманию самого главного принципа гибкого подхода.
Если копаться в голове и пытаться выявить слабые места в книге, то я бы сказал, что не хватает в ней структурности. Такая структурность помогла бы не перечитывать книгу, а пользоваться ей в качестве справочника. Но крепко встав на такую позицию, я буду лукавить. Во-первых потому что справочные пособия и своды знаний и методики уже существуют. А во-вторых тогда книга потеряла бы свой облик не назидательного источника новых мыслей, которые не так просто принять. Ведь на самом деле проект не всегда похож на программирование нового приложения или игры. Существует множество проектов, про которых и не сразу скажешь, мол это проект. Строительство моста, проведение инвентаризации на складе по новой технологии, ремонт в квартире, перевод бухгалтерии на новую учетную политику, планирование масштабного лечения зубов в конце концов. Все это может быть проектом. Любая деятельность, которую человек выполняет впервые или желает от нее получить разнообразные дивиденды в виде достижения стратегических целей, всему этому можно давать имя Проект, а значит в парадигме 21 века предлагать этой деятельности гибкий подход или даже философию.
Независимо от того, что книга была прослушана второй раз, мне удалось почерпнуть из нее несколько новых мыслей. Одна из которых, калибровка длительности итераций. В моей голове мелькнула следующая мысль. Ведь одной из самых главных ценностей итерационного подхода в том, что в сложных и запутанных проектах появляется свежая обратная связь, полезная для обсуждения и применяемая к снижению неопределенности проекта и его элементов. Разбивая поставки на малые партии, мы безусловно выигрываем на конкретности работ, на способности их атомарно проверить и качественнее проработать. Но тут важно понимать, что особенно при малой скорости команды и сложности проекта, можно не успеть своевременно трассировать полезные связи элементов невыполненных работ и информации, а вместе с тем последующие активности (обзор, анализ) пройдут в холостую, то есть снизят эффективность затраченных усилий.
В повседневной жизни, пожалуй, я давно взял за хорошую практику применять методику оценки по величине порядка и приоритета дел в зависимости от того, что на данный момент мне ценнее. Такой подход, скажу, продуктовика, упрощает любой выбор. Когда мне предстоит выбрать между посещением музея или пробежки с близкими в выходные, я в первую очередь рассматриваю эти активности как на букет разного рода ценностей, которые можно конвертировать в некую валюту моих текущих целей.
В работе же чаще применяю методику оценки, приходится все чаще говорить о разнице обязательств и оценки, которые помогают планировать работы, применяю ранжирование задач, а еще перемещение задач по доскам. Последняя техника не такая простая как на первый взгляд может показаться и ее эффективность действительно раскачивается в зависимости от контекста (проект, команда, предметная область, внешние условия, такие как карантинные меры).
Мой приговор тем, кто выбирает что читать среди книг, когда есть альтернатива Кону — читать эту книгу. Тем, кто занимается проектной деятельностью и хочет завиваться или зашивается и не успевает в работе — читать эту книгу. И всем, кто живет «на нашем веку» однозначно следует прочитать эту книгу, отвлекаясь немного от того, что она в первую очередь для оценки и планирования, проектов, в ИТ. Просто абстрагируйтесь и начните читать. Нужные идеи полетят из глубины подсознания уже на второй главе.
Ссылка на аудиокнигу: https://www.litres.ru/mayk-kon-13942345/agile-ocenka-i-planirovanie-proektov-39827354/?lfrom=143937599&ref_key=5cabc5499319ff6d1ef88f009c935147a181aa85d528ce8313d51b36dc2520fb&ref_offer=1
0 комментариев