Треугольник качества проекта = треугольник вины менеджера

Кто я: меня зовут Науменко Алексей и я руководитель ИТ-проектов с более чем 5 летним стажем и с профессиональным образованием в области ИТ-менеджмента.

Цель статьи: Я описываю свой опыт в реализации ИТ-проектов для повышения своей сознательности и профессионализма, а также для обмена опыта с представителями профессионального сообщества, для личного роста в профессиональной сфере.

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

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

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

Проблема №1: Треугольник качества проекта

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

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

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

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

Правила параметров:

• Правило содержания проекта: содержание проекта можно и увеличить, и уменьшить. Этот параметр наиболее гибок и часто именно он и подвергается корректировке, разумеется, в сторону уменьшения. Это происходит потому, что доказать нарушение контракта в части сроков и стоимости намного легче, чем доказать несоответствие функциональности. При этом укладывание проекта в сроки и стоимость при результате в виде продукта, который не удовлетворяет практические потребности заказчика, делает этот продукт просто никому ненужным мусором.
• Правило сроков проекта: “Невозможно сократить сроки проекта без сокращения содержания” или “Никакие деньги не помогут снизить сроки проекта”. Сроками проекта управлять невозможно, так как сроки всегда стремятся увеличиться и никогда не поддаются сокращению без кардинального упрощения содержания проекта. Как 9 женщин не смогут родить 1 ребенка за 1 месяц, так и 9 разработчиков не смогут написать девятимесячный функционал за 1 месяц. Более того, в классической работе “Мифический человеко-месяц” показано, что увеличение количества сотрудников в проектной команде приводит к увеличение и сроков проекта

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

Решение проблемы треугольника качества:

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

Хорошая новость для РП заключается в том, что заказчики, отвечающие за результаты перед инвесторами, разумеется, не мазохисты, чтобы нести крест ответственности на себе, но и не азартные безумцы, чтобы делегировать управление деньгами и результатами проекта на нанятого РП, который сегодня есть, а завтра нет. Риски РП несоизмеримо меньше рисков заказчика и сводятся к увольнению или потере годовой премии, которая может быть меньше 0,1% от стоимости проекта.

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

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

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

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

Как применять треугольник качества проекта на практике:

• Начните сотрудничество с заказчиком с демонстрации треугольника качества проекта = вины РП. Заказчик должен видеть треугольник качества как только он приходит к РП с новой идеей после старта проекта.
• Нацеленность на плановый функционал, несмотря превышение затрат и сроков - наиболее эффективный вариант применения треугольника качества. Команда проекта, создающая продукт, может сохранить заинтересованность в проекте при снижении доходов и увеличении сроков решения задачи, но не сможет быть заинтересована в создании заведомого мусора даже при условии повышения доходов и сокращении сроков решения задачи. Людям присуще стремление к достижениям, повышению своего имиджа и самооценки через достижение значимых и прогрессивных решений, развивающих корпоративную культуру значимого результата.
• Для проекта со сроком, который закреплен и не подлежит пролонгации подходит модель из теории ограничений Голдрата: сократить критический путь. Критический путь - это серия взаимозависимых задач, последняя задача которых заканчивается в дату окончания проекта.

Вывод: выбор в пользу сохранения качества и соответствия требованиям в ущерб срокам и стоимости сохраняет ценность продукта является единственно правильным решением в неразрешимом конфликте “сроки/затраты/практическая ценность”