Выбираем методологию для своего проекта

Виктория Солонтай

Менеджер Офиса блока «Технологии»

Жизненный цикл — это стадии, которые проходит проект от момента создания до передачи в ОПЭ. Его чёткое видение и понимание позволяет команде:

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

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

Избежать этого помогает грамотно выбранная методология работы. В данной статье рассмотрим некоторые из них.

MSCW

Впервые этот метод использовали Oracle UK в 1994 году. Он подходит для простых проектов (где есть чёткое понимание от А до Б). Или для очень больших, растянутых по времени и трудозатратам.

Согласные буквы в MSCW обозначают степени приоритетности задач/требований:

• M (или must) – задачи/требования, представляющие основной функционал или ядро задачи. Например, изменение платформы, на которой должно быть представлено решение. Если цель работы — запустить продукт именно на новой платформе, первой задачей будет — установить эту самую платформу.
• S (или should) – задачи/требования второго приоритета, которые ещё обязательны к исполнению и в отсутствии задач категории M становятся главными. Это, например, добавление функционала или обязательных программ для работы.
• C (или could) – задачи/требования, желательные для реализации, но не обязательные для работы продукта. Например, если есть пробный период программы и нужно изучить функционал, чтобы принять решение о её покупке.
• W (или would)– задачи/требования «по возможности», которыми можно пренебречь. Пример такой задачи — изменение цветовой палитры при визуализации приложения.

Преимущество MSCW — в простоте. Задачи делятся только по «критичности», и их не приходится переносить в другой класс с течением времени.

Минусы:

• Субъективность определения приоритетов. Неотъемлемые для заказчика функции могут быть «желательными» для руководителя проекта. И «дополнительными» для разработчика. Так что приоритеты стоит обсудить «на берегу».
• Какой бы, возможно, неприоритетной не стала со временем доработка из первой группы, её придётся доделать. Иначе будет невозможно приступить к задачам следующей категории.

RICE

Эта методология позволяет оценивать каждое требование или задачу по четырём параметрам:

• Reach или охват — количество пользователей/транзакций/задач в измеряемую единицу день, месяц, год;
• Impact или влияние — оценочная субъективная величина влияния на конечного пользователя/потребителя;
• Confidence или достоверность данных при оценке охвата и влияния — количество и структура данных для подтверждения своих выводов;
• Effort или требуемые усилия — оценка усилий для достижения результатов, оценивается в человекомесяцах.

Полученные оценки важно и нужно использовать в системе ранжирования задач/ требований. Это поможет определить, в каком порядке их выполнять, чтобы получить максимальный эффект от реализации. Я рекомендую также перед стартом любого проекта задавать «контрольный вопрос» заказчику: сколько на самом деле стоит проект и есть ли смысл вкладывать в него столько денег.

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

Основное преимущество в том, что это — универсальная методология. Она позволяет почти объективно оценить приоритетность задач (данные никогда не будут точны на 100%, но об этом поговорим ниже).

Минусы:

• Использование RICE, требует знание основ SMART.
• Модель не учитывает зависимости параметров. Например, очень трудозатратную задачу, важную для многих клиентов, откладывают и отдают предпочтение множеству задач, которые будут иметь то же влияние на клиентов по сумме, но могут оказаться потенциально дешевле;
• При оценке трудозатрат приходится просчитывать риски: поведут ли себя систему некорректно, «выпадут» ли разработчики из процесса, как отреагируют на доработку пользователи и так далее. Все оценки будут субъективными, и это — дополнительная сложность.

SMART

SMART позволяет прикинуть будущий результат и определить чёткие шаги к нему, оценить ресурсы и соответствие стратегии компании, сформулировать задачи с точки зрения бизнес-ценности по шести параметрам:

• Specific — точно определённая;
• Measurable — измеримая;
• Achievable — достижимая;
• Relevant — релевантная;
• Time Bound — ограниченная во времени; оптимальный срок выполнения — три, шесть или 12 месяцев.

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

Несколько преимуществ постановки целей с помощью SMART метода:

1. Пять критериев исключают неоднозначные формулировки, помогают оперативно ответить на любые вопросы.
2. Метод не требует времени на изучение.
3. Метод даёт возможность распределять задачи между подразделениями и отдельными сотрудниками.

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

Шесть сигм

Содержание проекта удобно подтверждать с помощью «Шести сигм». Эта система включает в себя статистические методы сбора и анализа данных и уникальный подход к организации командной работы. По ней все инициативы, связанные с исправлением или пересмотром бизнес-процессов, нужно вести как проекты.

Процесс выглядит так.

Отбираем первую задачу

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

• экономическая целесообразность — максимальный доход/экономия;
• реализуемость — наличие необходимых ресурсов;
• вероятность успеха — субъективный критерий для мотивации команды на успешную реализацию;
• охват — вовлечение в процесс небольшого количества бизнес-процесса;
• безопасность — снижение воздействия на соседние бизнес-процессы;
• стоимость реализации.

В зависимости от первоначальных условий количество и значимость критериев могут меняться.

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

Планирование действий

Это даёт следующие преимущества:

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

Планирование действий разбивается на 6 стадий:

1. Определяем меры, необходимые для реализации проекта/задачи.
2. Оцениваем, сколько времени уйдёт на каждую задачу и подзадачу.
3. Считаем, сколько ресурсов уйдёт на каждую задачу. Сделать это до старта проекта особенно важно.
4. Уточняем показатели, по которым будем оценивать успешность работы.
5. Проверяем сроки и корректируем план.

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

Я собрала методологии, которые считаются наиболее успешными. Но признаю, что у каждого руководителя проектов может быть свой взгляд на тему — и любимая методология, которая лучше всего подходит ему/ей и его/её проекту.

Успехов в развитии и совершенствовании навыков. Экспериментируйте для достижения результатов!