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

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

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

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

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


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

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

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

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

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

Комментарии

  1. Петелин на последнем вебинаре гворил, что лучше использовать треугольник "цена - сроки - эффорт". Звучит интересно, правда я плохо понял как его применять на практике.

    ОтветитьУдалить
  2. Если честно, слабо понимаю смысл треугольника "цена - сроки - эффорт". И цена, и сроки вроде как эффортом определяются. Поэтому в этой системе координат движение получается по прямой цена - сроки.

    Я так подозреваю, надо в Петеленские митинги включаться. Там можно вопросы задавать?

    ОтветитьУдалить
  3. да, он прямо-таки жаждет этого =)
    Денис как раз и сказал, что при эффорте треугольник вырождается, и цель проекта сановится гораздо более понятной.

    ОтветитьУдалить
  4. Если целью проекта считать срубить денег - то да :) Выкидывая качество, мы выкидываем нацеленность на производства продукта, соответствующего ожиданиям Заказчика. Получается настрой на чистую прибыль, а именно это в прошлом году чуть и не завалило наш аккаунт (не буду поминать название) :)

    ОтветитьУдалить
  5. Концепция -соответствия продукта требованиям заказчика - это 20 век!
    Дизайн проекта - в предвосхищении запросам будущего!

    ОтветитьУдалить

Отправить комментарий

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

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

Драйв

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