Ошибки являются естественным явлением, с которым сталкивается каждый. Нет ни одного человека, который бы их не допускал. Но у всех ошибок разные последствия. Какие-то из них могут быть даже позитивными, но чаще всего ошибка несёт за собой негатив.
И если ошибки персонала и программ уже давно категоризированы, то почему-то ошибки управленцев (в том числе проектного менеджмента) классифицировать никто не спешит. А ведь ошибки руководителей, менеджеров проектов и менеджеров продуктов чаще всего имеют самые серьёзные последствия.
Ниже попытаемся исправить данную несправедливость.
Зачем нужна градация ошибок?
Ну, во-первых, человек привык всё вокруг себя классифицировать, ведь именно научный подход и всесторонний анализ помогают нам добиваться результатов. Стандартизация – это лучший друг технического прогресса и науки. Так проще всё задокументировать, а значит – передать следующим поколениям.
Но документирование – не первопричина. Важнее накопление опыта.
Ошибки могут быть одиночными или повторяющимися, иметь абсолютное и относительное измерение последствий, они могут оказывать прямое или косвенное воздействие на проект и т.п.
Систематизация ошибок помогает предусмотреть вероятность их возникновения, а значит, принять все возможные меры, чтобы минимизировать последствия в ситуациях их наступления, или вовсе предотвратить.
В рамках крупного предприятия процесс управления рисками и ошибками называется риск-менеджментом, подробнее об этом в статье «Система управления рисками в компании».
По аналогии может помочь система градации ошибок менеджмента (системы управления предприятием или проектом).
Если ошибки предотвратимые или имеют некритичные последствия для предприятия, то ответственные лица могут быть наказаны за них в соответствие с заранее разработанной градацией – в рамках премирования или депремирования.
Концепция «вина-ответственность» всегда остается актуальной.
Классификация рисков в IT-проектах
IT-шники и программисты больше всех любят всё детализировать и классифицировать. Но когда работаешь с новым проектом, нужно быть готовым ко всему. Несмотря на то, что многие команды обязательно организуют тестирование своих продуктов, а во многих гибких методологиях управления проектами (топ-10 методологий управления) контроль и выявление ошибок – это сквозной и непрерывный процесс, ошибки всё равно возникают. И возникают они как на стадии реализации проекта, так и после его сдачи.
Как ускорить обработку ошибок и их устранение? Логично категоризировать их на входе (при получении обратной связи от заказчиков или от конечных пользователей), чтобы в будущем распределять функции исправления по ответственным за них сотрудникам, желательно, обладающим необходимой квалификацией и полномочиями.
Внутри каждой команды могут быть свои группы ошибок, которые будут привязываться к частоте возникновения и к особенностям архитектуры проекта.
Сэм Канер в книге «Тестирование программного обеспечения» приводит следующую общую классификацию ошибок внутри программных продуктов:
- Ошибки интерфейса (UX/UI).
- Логика обработки ошибок (для облегчения их обнаружения).
- Ошибки вычислений.
- Ошибки обработки/интерпретации данных (очень близки по смыслу к вычислениям).
- Проблемы начального и конечного состояния.
- Превышение нагрузки.
- Ситуация спешки.
- Ошибки аппаратного обеспечения и несовместимость.
- Контроль идентификаторов (процессов).
- Ошибки, связанные с граничными условиями.
Но и это далеко не эталон. С появлением DevOps-подхода логика работы программ стала заметно сложнее. Ведь у вас в распоряжении могут быть контролируемые и неконтролируемые среды: сетевые стеки, сторонние сервисы и службы и прочее.
Как можно классифицировать ошибки проектного менеджмента?
Наиболее эффективную систему градации ошибок проектного менеджмента можно составить только с привязкой к конкретной команде и к руководителям, а также с учётом зависимости от текущих условий ведения проекта и различных внешних факторов.
Наиболее универсальный подход в классификации любых ошибок – опора на функции и задачи.
За что отвечает менеджер проекта? Ранее мы рассматривали обязанности администратора проекта, которые во многом дублируют обязанности менеджера (ведь администратор – правая рука руководителя команды).
Если обозначить общие задачи, то они сводятся к планированию, обеспечению коммуникаций, снабжению необходимыми материалами и ресурсами, к контролю и анализу.
Но менеджер проекта не действует в одиночку. Он исполняет директивы заказчика (спонсора, владельца, клиента и др., подробнее о стейкхолдерах — о тех, кто так или иначе влияет на проект).
Группы ошибок проектного менеджмента в зависимости от их источника
Руководитель проекта:
- Проблемы управления рисками или полное отсутствие такого управления.
- Отсутствие управления ожиданиями заказчиков (стейкхолдеров).
- Неправильная оценка имеющихся или необходимых для реализации задач ресурсов.
- Отсутствие управления изменениями.
- Неправильно выстроенная система коммуникаций и мотивации.
- Неправильный режим управления (например, бессистемность, аврал, слишком жесткий стиль или, наоборот, слишком мягкий контроль и прочее).
Заказчик:
- Неправильные критерии оценки проекта.
- Завышенные ожидания.
- Непонимание отдельных внутренних процессов работы проектной команды.
Команда в целом (включая руководителя):
- Неправильная оценка сроков реализации (слишком оптимистично, слишком пессимистично, нетипичная задача, которая повышает уровень неопределённости).
- Неправильная мотивация (отсутствие заинтересованности).
- Нежелание адаптироваться к новым задачам и целям, особенно при отсутствии конкретной программы управления изменениями.
Внешняя среда:
- Нестабильная экономическая ситуация на рынке или в конкретной (важной для проекта) сфере.
- Изменение условий поставщиков (а поставщики есть даже в IT-проектах).
Как снизить количество ошибок проектного менеджмента?
Во-первых, на качество планирования и организацию работ существенно влияет опыт и квалификация руководителя проекта. Именно он задаёт тон во всех направлениях деятельности. Самоорганизующиеся команды – это практически несбыточная мечта. Поэтому весь груз ответственности за любые решения внутри команды так или иначе взваливается на плечи гласного или негласного лидера.
Во-вторых, все потенциальные ошибки управления должны быть идентифицированы (как в матрице рисков), и для каждой конкретной ошибки должна быть определена вероятность наступления и эффект последствий (цена ошибки). Так вы сможете заранее оценить потенциальные проблемы и спланировать пути их обхода.
В-третьих, не менее важны участники команды. Можно сильно формализовать все отношения внутри, детализировать операции до мельчайших подробностей (микроменеджмент), но вы всё равно не сможете добиться нужной вам эффективности. В любой коллективной работе важен вклад каждого отдельного участника.
В-четвёртых, по возможности нужно стандартизировать подход к управлению. Каждый должен знать свои обязанности и задачи, чётко понимать сроки и ответственность, иметь достаточную свободу действий, чтобы не тормозить процесс.
И тут мы приходим к одному из важнейших пунктов – автоматизация рутины. Чтобы команда могла работать, руководитель — планировать, все могли общаться в едином формате, а прогресс можно было в любой момент отследить как заказчикам проекта, так и его участникам, нужна специальная система распределения задач.
Если вы хотите ознакомиться с примерами типовых ошибок в проектах, у нас есть отдельный материал – «Почему стартапы терпят неудачи».