Два дня до демки. Команда пилит специфичный функционал — интеграция нашего продукта с Google Maps. Интеграция пилится «на коленке» — главное успеть показать потенциальному клиенту возможности системы.
Демка проходит и клиент берет паузу на подумать.
Спустя полгода продажники продают другому клиенту решение с интеграцией Google Maps. Ну они же видели, что пол года назад на демке все работало.
В чем здесь проблема?
Я работал в разных фирмах. Где-то было понятно, то что мы собираемся делать это проект. Почему это было понятно? Приходил клиент и говорил, мне нужно сделать вот такую систему и описывает ее. Менеджер планирует сколько проект займет по времени и деньгам, договаривается с клиентом и вперед работать. Он составляет — устав, план проекта, риски, контроль качества и прочие проектные артефакты. Четко и понятно.
В других организациях проект спускали сверху — делаем вот это и это, бери людей и вперед. Раздолья меньше, но тоже четко и понятно.
В третьих, самых сложных, с проектами непросто. На мой взгляд здесь есть ряд проблем о которых мне сложно судить со своего уровня. Все происходило так, как описывал в начале — проект скорее мертв чем жив.
Какие проблемы всплывают?
Команда проекта начала прорабатывать план внедрения и «внезапно» появились нюансы.
Классика жанра однако — и мы, и клиент по-разному понимали «интеграцию» например, или термин «аудит». Для них это было страшное слово связанное со злыми проверяющими, а у нас — термин который обозначает функциональность.
В итоге процесс внедрения выливается в проект доработки. Формально, устав проекта не менялся, все высокоуровневые цели остались прежними.
Как выруливать? Главная задача — выяснить, что именно нужно сделать, определить приоритеты, сроки, ресурсы, риски, оповестить все заинтересованные стороны, подготовить несколько сценариев развития. Как итог — договориться с клиентом о необходимом объеме который будет вписываться в доступный бюджет.
Основные нюансы — проект уже продан, у него уже есть бюджет и объем работы. Довольно жесткие ограничения. Но это не значит, что нужно это все проглотить и принять за истину в первой инстанции. В 99% случаях можно передоговориться, будь то клиент или спонсор.
Так сложилось, что я больше сторонник четких планов. Waterfall и PMI подход близки по духу, хотя не чужды и некоторые аспекты Agile.
Так вот, начинается проект и доказательством того, что проект запущен является устав проекта. Для тех кто мало знаком или незнаком поясню, что это за зверь.
Согласно идеологии PMI это документ который описывает верхнеуровневые цели, сроки, бюджет, риски, а также дает формальные полномочия менеджеру проекта и что немаловажно — определяет название проекта. Ниже поясню почему.
Зачастую, устав готовит менеджер проекта, согласовывает со спонсором, заказчиком и другими ключевыми заинтересованными сторонами.
В одной из фирм, где я работал, не было четкого определения, что такое проект. Была некая деятельность, некий поток, который назывался проектом, но по факту этим не являлся. Это было допущение. Окей, давайте назовем это проектом и как минимум определимся с названием, чтобы все понимали о чем мы говорим. С названиями была путаница, когда спонсор говорил — «Какой прогресс по проекту интеграции решений?», то руководитель направления и менеджер думали о разном. Руководитель направления называл этот проект «интеграция клиентов», а менеджер проектов «оптимизация БД». Каждый думал на своем уровне.
У Agile нет бюджета и сроков, даже верхнеуровневых, так как все гибко и может поменяться в любой момент. Да, Agile может оценить срок завершения, но только после нескольких итераций, когда будет оценена производительность команды. Но цели то есть. Мы же знаем, что хотим сделать.
Приведу пример. Есть две команды разработки. У обеих одинаковый проект — разработать мобильное решение для контроля качества продуктов питания.
Команда А работает по Waterfall. Команда Б работает по Agile. Разные подходы к планированию и разработке. Но цель одна. Так почему бы на старте ее не зафиксировать? Какова вероятность, что команда Б посреди спринта поймет, что клиенту не нужно приложение для контроля качества, а нужно приложение для записи футбольных матчей? Очень мала, с большей вероятностью они все таки придут к изначальной цели.
NB: Я делаю допущение и говорю про заказную разработку, а не про стартапы.
С названием, сроками, бюджетом более-менее понятно. А что с рисками?
PMI относится к этому формально. На мой взгляд, процесс управления рисками это самостоятельная вещь. Поясню, что имею ввиду.
Процесс управления рисками состоит из этапов:
По сути, это итеративный процесс. Он применим и в операционной деятельности и в Agile подходах.
При запуске проекта, существует один глобальный риск — он может провалиться.
Многие начинающие менеджеры проектов проходили через это — нужно составить устав и определить цель(-и) проекта. И вот рождаются такие монстры:
Почему «корпоративная система» должна улучшить взаимодействие? Как заказчик поймет, что она это сделала?
«Переработка системы учета» — переработает мы ее, но как? Пункты меню в интерфейсе поменяем. Это оптимизирует процесс учета?
«Внедрение системы контроля» — как мы поймем что система внедрена? Допустим, что все сошлись на том, что она внедрена, но повысит ли это прибыль отделов? Что если ничего не внедрим, но прибыль увеличится, по независящим от нас причинам? Можно считать что проект достиг цели?
Если формулируем цели проекта, то это должен быть набор целей: что нужно сделать конкретно и как мы поймем что мы это сделали? Что мы должны увидеть, почувствовать? Что должно поменяться? С какими расходами это должно быть достигнуто? Когда? Если целей несколько, то каковы их приоритеты. Может оказаться, что цели зависят друг от друга, а может оказаться, что какие-то цели взаимоисключают друг друга.
Пример: Внедрить систему управления проектами на базе Project Server для 20 рабочих места проектного офиса с использованием электронного реестра рисков и электронных писем с функцией автоматического оповещения о переносе сроков.
Система должна помочь сократить расписания каждого из проектов на 15% в течении 2 месяцев после запуска.
Система должна быть внедрена за 6 месяцев, не позднее 15 декабря.
Уже ближе, но все еще можно доработать.
Дополнительные вопросы которые можно задать:
Два последних вопроса это так называемые «не цели».
Они описывают, что не относится к проекту и чего не должно произойти, так как это мешает ходу проекта или нарушает внутренние ограничения. Результаты, которые не относятся к проекту, не следует характеризовать как вредные, но следует знать, что заказчик их получение не оплачивает.
Видите, что появился некий объем работы с некими очертаниями и на него даже есть сроки и бюджет? С большой долей вероятности это проект. Договариваемся с продажниками, чтобы и менеджеров и инженеров вовлекали в процесс продажи. Хотя бы как консультантов — им же потом и работать с этим.
До запуска определяемся с названием проекта и терминологией. Пишем устав и формируем четкие и понятные цели. SMART наше все.
Демка проходит и клиент берет паузу на подумать.
Спустя полгода продажники продают другому клиенту решение с интеграцией Google Maps. Ну они же видели, что пол года назад на демке все работало.
В чем здесь проблема?
Я работал в разных фирмах. Где-то было понятно, то что мы собираемся делать это проект. Почему это было понятно? Приходил клиент и говорил, мне нужно сделать вот такую систему и описывает ее. Менеджер планирует сколько проект займет по времени и деньгам, договаривается с клиентом и вперед работать. Он составляет — устав, план проекта, риски, контроль качества и прочие проектные артефакты. Четко и понятно.
В других организациях проект спускали сверху — делаем вот это и это, бери людей и вперед. Раздолья меньше, но тоже четко и понятно.
В третьих, самых сложных, с проектами непросто. На мой взгляд здесь есть ряд проблем о которых мне сложно судить со своего уровня. Все происходило так, как описывал в начале — проект скорее мертв чем жив.
Какие проблемы всплывают?
- При продаже софта, клиенту была показана только верхушка айсберга — фантики и конфетки. Под капот никто не смотрел, а там еще работать и работать.
- В процесс продажи не были вовлечены технические специалисты в качестве консультантов.
- Продавцы пообещали клиентам некие сроки, без консультации с технической командой.
Команда проекта начала прорабатывать план внедрения и «внезапно» появились нюансы.
Классика жанра однако — и мы, и клиент по-разному понимали «интеграцию» например, или термин «аудит». Для них это было страшное слово связанное со злыми проверяющими, а у нас — термин который обозначает функциональность.
В итоге процесс внедрения выливается в проект доработки. Формально, устав проекта не менялся, все высокоуровневые цели остались прежними.
Как выруливать? Главная задача — выяснить, что именно нужно сделать, определить приоритеты, сроки, ресурсы, риски, оповестить все заинтересованные стороны, подготовить несколько сценариев развития. Как итог — договориться с клиентом о необходимом объеме который будет вписываться в доступный бюджет.
Основные нюансы — проект уже продан, у него уже есть бюджет и объем работы. Довольно жесткие ограничения. Но это не значит, что нужно это все проглотить и принять за истину в первой инстанции. В 99% случаях можно передоговориться, будь то клиент или спонсор.
Запускаем проект
Так сложилось, что я больше сторонник четких планов. Waterfall и PMI подход близки по духу, хотя не чужды и некоторые аспекты Agile.
Так вот, начинается проект и доказательством того, что проект запущен является устав проекта. Для тех кто мало знаком или незнаком поясню, что это за зверь.
Согласно идеологии PMI это документ который описывает верхнеуровневые цели, сроки, бюджет, риски, а также дает формальные полномочия менеджеру проекта и что немаловажно — определяет название проекта. Ниже поясню почему.
Зачастую, устав готовит менеджер проекта, согласовывает со спонсором, заказчиком и другими ключевыми заинтересованными сторонами.
В одной из фирм, где я работал, не было четкого определения, что такое проект. Была некая деятельность, некий поток, который назывался проектом, но по факту этим не являлся. Это было допущение. Окей, давайте назовем это проектом и как минимум определимся с названием, чтобы все понимали о чем мы говорим. С названиями была путаница, когда спонсор говорил — «Какой прогресс по проекту интеграции решений?», то руководитель направления и менеджер думали о разном. Руководитель направления называл этот проект «интеграция клиентов», а менеджер проектов «оптимизация БД». Каждый думал на своем уровне.
У Agile нет бюджета и сроков, даже верхнеуровневых, так как все гибко и может поменяться в любой момент. Да, Agile может оценить срок завершения, но только после нескольких итераций, когда будет оценена производительность команды. Но цели то есть. Мы же знаем, что хотим сделать.
Приведу пример. Есть две команды разработки. У обеих одинаковый проект — разработать мобильное решение для контроля качества продуктов питания.
Команда А работает по Waterfall. Команда Б работает по Agile. Разные подходы к планированию и разработке. Но цель одна. Так почему бы на старте ее не зафиксировать? Какова вероятность, что команда Б посреди спринта поймет, что клиенту не нужно приложение для контроля качества, а нужно приложение для записи футбольных матчей? Очень мала, с большей вероятностью они все таки придут к изначальной цели.
NB: Я делаю допущение и говорю про заказную разработку, а не про стартапы.
С названием, сроками, бюджетом более-менее понятно. А что с рисками?
PMI относится к этому формально. На мой взгляд, процесс управления рисками это самостоятельная вещь. Поясню, что имею ввиду.
Процесс управления рисками состоит из этапов:
- Идентификация
- Анализ
- Планирование
- Мониторинг
По сути, это итеративный процесс. Он применим и в операционной деятельности и в Agile подходах.
При запуске проекта, существует один глобальный риск — он может провалиться.
В книге Эдварда Йордона «Путь Камикадзе» есть интересная мысль — к любому проекту стоит относиться как к провальному. С таким отношением нужно выстраивать стратегию развития, то есть продумывать набор тех действий, которые сделают из провального проекта успешный.Итого — устав проекта это документ, который позволяет всем ключевым сторонам договориться об одной терминологии, о глобальных целях, о высокоуровневых рисках. Все понимают куда идем, чего хотим достичь и что может случиться не так.
Так почему бы не оттолкнуться от этой мысли и сделать так чтобы этого не случилось? Да, на старте пока мало данных. Но на то они и высокоуровневые риски, чтобы показать заинтересованным сторонам, что может пойти не так.
Постановка цели проекта
Многие начинающие менеджеры проектов проходили через это — нужно составить устав и определить цель(-и) проекта. И вот рождаются такие монстры:
- Разработка и внедрение корпоративной системы управления программами и проектами для улучшения взаимодействия между отделами;
- Переработка системы учета налоговых отчислений для оптимизации процесса учета;
- Внедрение системы контроля затрат для повышения прибыли отделов.
- Такие проекты невозможно завершить. Если видите такую формулировку в уставе, значит этот проект уже мертв.
Почему «корпоративная система» должна улучшить взаимодействие? Как заказчик поймет, что она это сделала?
«Переработка системы учета» — переработает мы ее, но как? Пункты меню в интерфейсе поменяем. Это оптимизирует процесс учета?
«Внедрение системы контроля» — как мы поймем что система внедрена? Допустим, что все сошлись на том, что она внедрена, но повысит ли это прибыль отделов? Что если ничего не внедрим, но прибыль увеличится, по независящим от нас причинам? Можно считать что проект достиг цели?
Если формулируем цели проекта, то это должен быть набор целей: что нужно сделать конкретно и как мы поймем что мы это сделали? Что мы должны увидеть, почувствовать? Что должно поменяться? С какими расходами это должно быть достигнуто? Когда? Если целей несколько, то каковы их приоритеты. Может оказаться, что цели зависят друг от друга, а может оказаться, что какие-то цели взаимоисключают друг друга.
Ставим цели по SMART
- Specific — конкретный.
Что мы хотим сделать? Что-то улучшить? А на сколько? - Measurable — измеримый.
Можем померить цель в деньгах, процентах, сэкономленном времени? - Achievable — достижимый.Достаточно ли у нас ресурсов, знаний, опыта, времени для достижения цели?
- Relevant — соответствующий или значимый.
Здесь нужно определить для чего требуется достижение цели? - Time bound — ограниченный во времени.
За какое время цель должна быть достигнута?
Пример: Внедрить систему управления проектами на базе Project Server для 20 рабочих места проектного офиса с использованием электронного реестра рисков и электронных писем с функцией автоматического оповещения о переносе сроков.
Система должна помочь сократить расписания каждого из проектов на 15% в течении 2 месяцев после запуска.
Система должна быть внедрена за 6 месяцев, не позднее 15 декабря.
Уже ближе, но все еще можно доработать.
Дополнительные вопросы которые можно задать:
- Что должно быть сделано?
- Почему это нужно делать?
- Какую пользу должен принести проект?
- Все ли знакомы с этим замыслом?
- Все ли одинаково его понимают?
- Все ли с ним согласны?
- Когда нужно закончить работу?
- Кто является конечным пользователем?
- Какое качество ожидают получить?
- Какая функциональность ожидается?
- Какие средства имеются в распоряжении?
- Кто контролирует достижение успеха и по каким критериям?
- Что не должно произойти ни в коем случае?
- Какая работа к проекту не относится?
Два последних вопроса это так называемые «не цели».
Они описывают, что не относится к проекту и чего не должно произойти, так как это мешает ходу проекта или нарушает внутренние ограничения. Результаты, которые не относятся к проекту, не следует характеризовать как вредные, но следует знать, что заказчик их получение не оплачивает.
Резюме
Видите, что появился некий объем работы с некими очертаниями и на него даже есть сроки и бюджет? С большой долей вероятности это проект. Договариваемся с продажниками, чтобы и менеджеров и инженеров вовлекали в процесс продажи. Хотя бы как консультантов — им же потом и работать с этим.
До запуска определяемся с названием проекта и терминологией. Пишем устав и формируем четкие и понятные цели. SMART наше все.
