Согласование требований с точки зрения теории вариаций

Курс естествознания по разработке программного обеспечения
Раздел “Вариации”

– Преамбула —————-
Согласование требований к ПО достаточно распространенная процедура, описанная во множестве источников. С точки зрения здравого смысла – все прекрасно. Действительно, ведь так мы должны уменьшить риски того, что продукт будет не слишком соответствовать ожиданиям. Все отлично в теории. Ну и в книгах.
– Конец преамбулы ——————–

Но практика показывает, что не всегда все бывает сильно хорошо. Иногда, а вернее чаще, чем просто иногда, согласование требований идет «Не совсем так, как в теории».

Рассмотрим этот процесс с точки зрения одного из раздела глубинных знаний, выделенных Демингом, с точки зрения теория вариации.

На вебинаре «Влияния вариаций на календарный график проекта» я показываю, как передача артефакта в другой рабочий центр влияет на календарный график. Математическая модель, выбранная мной очень щадящая, она показывает, что включение очередного рабочего центра в процесс ведет к смешным календарным потерям. Ну, всего то,  увеличится время проекта в пару раз. Если же изменить модель и привести ее в соответствие с практикой (или если поставить натурный эксперимент), то мы увидим, что добавление фазы «согласование требований» ведет к очень существенному замедлению работы и существенной просадке эффективности рабочего цикла. Иногда в десятки раз.

Антипаттерн. Один из лучших способов увеличить потери на вариациях (и уменьшить прибыль фирмы) – это включение дополнительного рабочего центра в процесс.

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

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

Вы должны войти, чтобы оставить свой комментарий.