Градации ошибок проектного менеджмента

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

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

Ниже попытаемся исправить данную несправедливость.

Зачем нужна градация ошибок?

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

Но документирование – не первопричина. Важнее накопление опыта.

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

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

В рамках крупного предприятия процесс управления рисками и ошибками называется риск-менеджментом, подробнее об этом в статье «Система управления рисками в компании».

По аналогии может помочь система градации ошибок менеджмента (системы управления предприятием или проектом).

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

Концепция «вина-ответственность» всегда остается актуальной.

Классификация рисков в IT-проектах

IT-шники и программисты больше всех любят всё детализировать и классифицировать. Но когда работаешь с новым проектом, нужно быть готовым ко всему. Несмотря на то, что многие команды обязательно организуют тестирование своих продуктов, а во многих гибких методологиях управления проектами (топ-10 методологий управления) контроль и выявление ошибок – это сквозной и непрерывный процесс, ошибки всё равно возникают. И возникают они как на стадии реализации проекта, так и после его сдачи.

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

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

Сэм Канер в книге «Тестирование программного обеспечения» приводит следующую общую классификацию ошибок внутри программных продуктов:

• Ошибки интерфейса (UX/UI).
• Логика обработки ошибок (для облегчения их обнаружения).
• Ошибки вычислений.
• Ошибки обработки/интерпретации данных (очень близки по смыслу к вычислениям).
• Проблемы начального и конечного состояния.
• Превышение нагрузки.
• Ситуация спешки.
• Ошибки аппаратного обеспечения и несовместимость.
• Контроль идентификаторов (процессов).
• Ошибки, связанные с граничными условиями.

Но и это далеко не эталон. С появлением DevOps-подхода логика работы программ стала заметно сложнее. Ведь у вас в распоряжении могут быть контролируемые и неконтролируемые среды: сетевые стеки, сторонние сервисы и службы и прочее.

Как можно классифицировать ошибки проектного менеджмента?

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

Наиболее универсальный подход в классификации любых ошибок – опора на функции и задачи.

За что отвечает менеджер проекта? Ранее мы рассматривали обязанности администратора проекта, которые во многом дублируют обязанности менеджера (ведь администратор – правая рука руководителя команды).

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

Но менеджер проекта не действует в одиночку. Он исполняет директивы заказчика (спонсора, владельца, клиента и др., подробнее о стейкхолдерах — о тех, кто так или иначе влияет на проект).

Группы ошибок проектного менеджмента в зависимости от их источника

Руководитель проекта:

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

Заказчик:

• Неправильные критерии оценки проекта.
• Завышенные ожидания.
• Непонимание отдельных внутренних процессов работы проектной команды.

Команда в целом (включая руководителя):

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

Внешняя среда:

• Нестабильная экономическая ситуация на рынке или в конкретной (важной для проекта) сфере.
• Изменение условий поставщиков (а поставщики есть даже в IT-проектах).

Как снизить количество ошибок проектного менеджмента?

Во-первых, на качество планирования и организацию работ существенно влияет опыт и квалификация руководителя проекта. Именно он задаёт тон во всех направлениях деятельности. Самоорганизующиеся команды – это практически несбыточная мечта. Поэтому весь груз ответственности за любые решения внутри команды так или иначе взваливается на плечи гласного или негласного лидера.

Во-вторых, все потенциальные ошибки управления должны быть идентифицированы (как в матрице рисков), и для каждой конкретной ошибки должна быть определена вероятность наступления и эффект последствий (цена ошибки). Так вы сможете заранее оценить потенциальные проблемы и спланировать пути их обхода.

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

В-четвёртых, по возможности нужно стандартизировать подход к управлению. Каждый должен знать свои обязанности и задачи, чётко понимать сроки и ответственность, иметь достаточную свободу действий, чтобы не тормозить процесс.

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

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