Майско-июньские аналитики и Scope creep

18-го июня прошла очередная встреча членов сообщества analyst.by под кодовым названием «майские жуки».

Задуманный еще в мае, долгожданный слет аналитиков получился как никогда веселым и живым, так как все действие происходило на природе, в компании солнышка и свежего воздуха. Более 20 бизнес-аналитиков и представителей иных, как близких, так и далеких от IT профессий, получили мегапозитивный заряд энергии от непринужденного общения, приправленного вкуснейшим шашлыком, пивом и иными атрибутами природно-выездного отдыха. Солнечная погода, свежий воздух и хорошее настроение настолько расслабили участников, что вместо двух запланированных тем аналитики успели обсудить только одну, хотя и довольно глубоко – scope creep и борьба с этим явлением.

Фотосъемку встречи, как всегда, обеспечивала Катя Лобунец, за что ей превеликая благодарность! Также спасибо Андрею Курьяну и Сергею Шиманскому, поделившимся экспертными мнениями по обсуждаемой проблеме; Яне, Роме и всем, кто им помогал обеспечивать участников встречи обалденным шашлыком и прочими вкусностями; Сергею и Оле Кадомским, которые помогли найти место и организовали закупку и доставку провианта; всем водителям, которые поступились холодным пивом, чтобы доставить участников к месту назначения и обратно; и, конечно же, Юре Веденину, который по традиции все это дело организовал и воплотил в жизнь!

Обсуждаем встречу на форуме, там же следим за появлением фото!

 

Ну а ниже представлены краткие итоги дискуссии по scope creep.

Что такое scope creep? Это неконтролируемое разрастание границ проекта, приводящее к очевидной необходимости изменения одного/нескольких ключевых параметров проекта: бюджет, сроки или качество.

Что является причиной scope creep?

Основная причина — изменчивость требований, что крайне часто наблюдается в IT-проектах. При этом к scope creep относится именно неконтролируемое изменение требований.

На протяжении жизненного цикла проекта требования меняются потому, что:

•    Меняется бизнес заказчика;
•    Проблемы коммуникации между различными участниками проекта мешают выявить все требования заранее;
•    Заказчик не всегда четко понимает, что ему действительно нужно;
•    Учтены не все заинтересованные лица проекта.

Почему изменчивые требования приводят к scope creep:

•    Границы проекта (scope) не были четко зафиксированы;
•    Не всегда команда разработки (в частности, проектный менеджер и аналитик, как лицо, представляющее команду) умеют сказать «нет»  фонтанирующим «хотелкам» заказчика;
•    Отсутствие тщательного анализа влияния (impact analysis) изменения требований на ход проекта.
•    Отсутствует четкий процесс внесения изменений (change control process) в систему.

Как предотвратить scope creep?

(Комментарий от Екатерины, одной из участниц встречи: Как говорим мы, ветеринары, болезнь легче предупредить, чем потом ее потом  лечить:)).

1. Когда меняется бизнес заказчика:
•    Необходимо более тщательное изучение бизнес-области;
•    Нужно разобраться в бизнес-модели проектируемой системы и сделать прогноз ее развития;
•    Нужно заранее понимать и ожидать изменения требований;
•    Необходимо осуществлять управления рисками;
•    В архитектуру системы нужно закладывать возможность изменения наиболее рискованных требований.

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

3. Заказчик сам не до конца понимает, что ему нужно:
•    Нужен анализ «фишек» бизнеса заказчика, которые отличают его от конкурентов;
•    Необходимо в первую очередь разрешить туманные и неясно сформулированные вопросы и пожелания;
•    Желательно чаще применять прототипирование и визуализировать возможные решения проблем заказчика.

4. Границы проекта (scope) неконтролируемо растут:
•    Нужно вести список всех «хотелок» заказчика;
•    Запросы на изменение должны быть приоритизированы;
•    Каждый запрос должен тщательно оцениваться на предмет влияния на существующий функционал (impact analysis).

5. Границы проекта (scope) не зафиксированы:
•    Их нужно зафиксировать:);
•    Желательно писать детализированные спецификации;
•    Готовые спецификации от заказчика, при наличии таких, нужно анализировать на наличие неоднозначных и высокоуровневых требований.

6. Анализ влияния изменений (impact analysis) не проводится:
•    Проводить:);
•    Рекомендуется поддерживать трассировку требований всех уровней (traceability matrix);
•    Любое изменение должно быть согласовано с командой (менеджером, разработчиками, QA).

7. Заказчик хочет за счет изменений заработать/сэкономить дополнительные деньги:
•    Подобные ситуации нужно замечать и распознавать;
•    О таких ситуациях нужно оповещать менеджера проекта.

8. Не все заинтересованные лица (stakeholders) учтены:
•    Надо стараться учитывать интересы всех заинтересованных лиц проекта.
•    Необходимо вовремя выявить лиц, обладающих полномочиями принятия решений (decision makers);
•    Задать в конце вопрос «Есть ли еще что-то, о чем мы забыли у вас спросить».

Как бороться со scope creep?

Итак, границы проекта плывут. Беда ли это? Тут есть свои плюсы и минусы. Для заказчика это всегда – в плюс, так как за тот же бюджет он получит больше. Стоит отметить и некую степень самоудовлетворения – сумел-таки «развести» исполнителя:).

Для исполнителя же все не так просто.

Плюсы:
-    Отсроченная выгода для компании (заказчик доволен и рад).
-    Репутация компании возрастает.

Минусы:
-    Внутренний бюджет проекта растет.
-    Мораль команды падает.

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

1. Признать, что scope creep есть;
2. Обязательно сообщить о наличие scope creep руководству;
3. Проанализировать и рассчитать негативные последствия (провести impact analysis).
4. Предложить пути выхода:
4.1. Определить причину разрастания границ и метод устранения;
4.2. Предложить руководству видение решения проблемы, проговаривая необходимые действия и возможные последствия каждого варианта и рекомендуя наиболее подходящее:
-    Выбросить из проекта менее важный функционал в угоду запрашиваемым изменениям;
-    Пожертвовать качеством функционала, чтобы успеть разработать запрашиваемые изменения;
-    Вынести новые требования за пределы проекта/итерации;
-    Увеличить трудоемкость проекта («овертаймы» или увеличение команды);
-    Убедить заказчика оплатить изменения.

Продолжаем обсуждать scope creep на форуме.