Мы переходим к рассмотрению различных типов утечек ресурсов. Первая большая группа - это утечки, возникающие из-за ошибок при постановке задач. О том, что такое SMART-критерии, наверное, знает любой начинающий РП. Но вот на том, каким образом их нарушение приводит к возникновению утечек ресурсов, стоит остановиться подробнее.

Начнем с первых двух букв, S (конкретность) и M (измеримость). При нарушении этих принципов возникает ситуация, которую будем называть задачей про бабушкины котлеты.

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

При первом показе заказчику выясняется, что то, что мы ваяли на этапе реализации, это вовсе не котлета. Потому что в изначальных требованиях был упущен ответ на вопрос "а что считать котлетой?". То есть нарушен принцип конкретности. Соответственно, команда входит в каскад переделок для того, чтобы получить нечто, что заказчик признает котлетой. Время (а соответственно и деньги), потраченные на эти переделки, как мы выяснили раньше, уже представляют собой утечку ресурсов.

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

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

И да, написанные аналитиком требования и постановки хорошо бы валидировать с РП и исполнителями до начала работ по реализации. Потому как ошибки, исправленные на бумаге, обходятся примерно в 10 раз дешевле, чем те, которые приходится исправлять, переделывая готовый продукт.