Ольга Станиславовна Богдан "Анатомия одного проекта"

Анатомия одного проекта
Ольга Станиславовна Богдан

Книга об опыте внедрения проектного управления, в том числе гибких методологий не в IT. Применимо ли? Какие истории случались на пути? Переосмысление автора полученных книжных знаний после столкновения с реальностью ежедневного управления.Все иллюстрации в книге созданы с помощью нейросети ruDALL-E Kandinsky.

Ольга Богдан

Анатомия одного проекта

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

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

За основу этой книги беру теоретическую базу прекрасной для строительства методологии, разработанной институтом PMI. Десять областей знаний 10 притч про то, как надо или не надо. Мне очень хотелось, чтобы у читающих PMBOKбыло больше возможностей для применения этих принципов. Мне очень повезло, и я на практике в одной из компаний постоянно чувствовала в работе данные инструменты. Но оказалось я просто счастливчик, так как так бывает далеко не всегда. После того, как я перешла работать в другую компанию я прочувствовала, насколько было заряжено мое окружение на результат на достижение результата.

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

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

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

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

Часть 1 – классические метод ведения проектов, водопадная модель.

Интеграция

Думайте на бумаге. Каждая минута, затраченная на планирование, экономит 10 минут при осуществлении плана.

Брайан Трейси

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

На одном проектном совещании сидели лебедь рак и щука. Лебедь вел kickofmeetingпо проекту разработке дизайна современного транспортного средства. На совещании было принято решение что дизайном занимается лебедь, техническим наполнением рак, а щука будет координировать процессы. После не продолжительного времени лебедь и рак поняли, что у молчаливой щуки только выскальзывать хорошо получается и выходить из трудных ситуаций координатор из нее так себе. Лебедь и рак договорились о габаритах автомобиля и общих технических характеристиках и пошли делать каждый свою часть. Во время проектирования рак понял, что характеристики немного надо увеличить всего на 5% для того, чтобы транспортное средство качественно отличалось от аналогов, представленных на рынке, габариты оборудования конечно тоже немного увеличатся, но в размеры, обозначенные лебедем, оно уместится. Сообщать о таких мелочах при столь сжатых сроках себе дороже.Лебедь в свою очередь немного подкорректировал дизайн для того, чтобы автомобиль был более обтекаемым, настолько незначительно, что решил бессмысленным ставить в известность рака. После окончания первого этапа, лебедь и рак презентовали свои наработки. После презентации стало ясно, что для аггрегатов рака нет места в дизайне лебедя. После всевозможных итераций, так и не получилось понять, какая часть превалирует.

Переходя к следующей части главы, хочу написать небольшое вступление. В проектном управлении в методологиях и в разных компаниях выработано огромное количество стандартных документов, от уставов проектов до протоколов разного рода. Хорошо если подход вашей компании позволяет определиться проектному менеджеру какие из этих документов работают и позволяют выстраивать работу на проекте. Не всегда это так, и, если от вас требуется вести и вы не смогли донести руководству, что документ не работает в реальности вашего проекта, конечно я не советую вам их не вести. Но если у вас есть выбор какие документы вести, а какие нет, то прошу вас обратить внимание на один очень простой инструмент – если вы открываете документ реже чем раз в неделю, значит он не работает в отношении данного конкретного проекта. Для того, чтобы реанимировать документ, есть два простых шага. Первый шаг дать вторую жизнь документу: облегчить и сделать более информативным визуал. Второй шаг: посмотреть наполнение, сделать его более понятным, поменять подачу. Не работают тяжеловесные непонятные документы, которые не имеют ничего общего с быстрой изменяемостью на проекте. Старайтесь каждый раз сокращать количество информации, которая не нужна и не информативна, узнавать быстрые клавиши и другие полезные лайфхаки от коллег, это экономит время.

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

Инструменты

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

Есть разные методологии постановки целей,последнее время все чаще слышу, что используют OKR (objectivesandkeyresult) суть метода сведена к тому, что мы описываем цель и несколько ключевых результатов, чтобы измерить достигли ли мы эту цель. Бытовой пример, цель – похудеть к лету, ключевые результаты: вес до 58 кг, объем талии меньше 85 см, количество калорий потребляемое каждый день не более 1500 ккал и т.д. проверяем достигли ли цели по показателям 31 мая. Пример из проектной деятельности, цель –запуститьапарт отель со сроком окупаемости менее 3,5 лет. Параметры измерения: бюджет проекта – 1 млрд., срок реализации – 1,5 года, площадь – 15 000 кв.м.

Пару тезисов, не уходя в теорию, что делать чтобы поставить цели по OKR:

Держать себя в рамках. А именно, ставить цели на определенный период: год, квартал, спринт, заданный отрезок времени.

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

Быть амбициозным. А именно, ставить масштабные цели, а не заведомо сделанные. Если достигнуть 70% от поставленной амбициозной цели это лучше, чем выполнить цель, которая само собой должна была быть выполнена.

Быть конкретным. А именно, ключевые показатели оцифровывать, устанавливать метрики и т.д.

После постановки целей, плотно работаем над уставом проекта и планом управления, которые будут:

Определять участников проекта, в том числе указывая какие роли и задачи на проекте будут выполнять участники.

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

Определять бюджет и необходимые ресурсы для реализации проекта, такие как человеческие, финансовые, технические и т.д.

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

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

С чего начать

Прописать цели любой удобной методологией. Сейчас модно OKR можно ей, вопрос что удобнее.

Выбрать формат, который будет удобен для контроля и управления изменениями на проекте.

Выбрать удобный формат, который будет аккумулировать ваш опыт руководства проектами, командами, контрагентами и т.д.

!!! Важно: помните, что документы должны быть рабочими и удобными, а не для галочки.

Содержание

Знаете, что стоит дороже белого тигра? Содержание белого тигра.

Сериал Люцифер

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

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

Пригласил как-то волк группу козлят построить ему логово на берегу. Вы, козлята говорит постройте мне логово здесь, ну такое чтоб все было только, как в самом крутом логове. Козлята принялись за работу, и так как желания с волком общаться лишний раз не было, и из страха быть съеденными решили козлятушки строить как знают. А так, как о логове у них было немного знаний, так как оттуда никто не возвращался, стали они строить модернизированныйсарай. Сделали описание что нужно будет делать, и принялись за работу. Приходит волк, смотрит работа кипит. Хвалит козлят приговаривает, если понравится никого не съем. Работа еще упорнее началась строят и день и ночь приходит волк в следующий раз смотрит что-то не то…. Начал вопросы задавать, а что это, а что вот это? А козлята только в стороны разбегаются да быстрее саманные кирпичики таскают. А волк вообще не понимает причем тут саман. Плюнул на них поймал пару козлят и съел, на следующий день приносит обе шкуры и говорит это на стены, а не эти ваши саманы. И тут и ахнул сарай почти готов, переловил всех козлят волк говорит все равно строить не умеют, хоть вкусные, и то хорошо.

Инструменты

Хотела бы разделить на две части: общее содержание проекта и построение ИСР, и частные списки задач для команды на текущий период.

Для первого можно использовать банально excel (для почти всего в проектном управлении можно использовать банально excel), также miro и другие доски для построения дорожных карт. Но для меня удобнее делать некий список, который просто можно перенести в MSProjectи сделать график. Но хотя бы однажды советую сделать дорожную карту. Во-первых, это очень увлекательно, во-вторых, это довольно удобный инструмент, если его не закидывать, а пользоваться им с установленной периодичностью. Дорожная карта дает возможность управлять проектом в моменты неопределенности. Подходит определенная точка, где нужно принять решение смотрим дорожную карту и определяемся каким путем мы идем, как мы это делаем.

Для второго лично я использую Trello.Там можно делать и совместные доски и личные и не только по работе, это для меня инструмент на все области моей жизни. Более подробно о списках задач и как это работает я расскажу в главе «kanban». Для более продвинутых пользователей досок есть jiraconfluence.

С чего начать

Ответить себе на вопрос «Зачем?» реализуется данный проект. Этот ответ должен быть отражен в видении вашего проекта, и потом будет неоднократно подсказывать какую стратегию согласовать, в том или ином случае и принять стратегически верное решение в переломных моментах.

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