Про треугольник цена – сроки – качество, особенно про качество

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

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

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

Казалось бы – очевидные вещи, но порой без рисования треугольника их бывает так сложно объяснить… За исключением одной лишь только мелочи – как фиксировать уровень качества и можно ли им управлять. И сразу-же мегавопрос – а что такое качество программного продукта?


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

Качество программного продукта складывается из двух составляющих:
  • качество программирования;
  • соответствие продукта ожиданиям Заказчика и конечных пользователей.
С первой состаляющей все понятно: она есть результат цепочки программирование – тестирование – багфиксинг. Т.е. это техническое качество.

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

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

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

Популярные сообщения из этого блога

Карта компетенции аналитика

Оценка эффективности работы аналитика – а чем он занимается и чего можно померить?

Оценка эффективности работы руководителя проектов