Mobile Menu

Декомпозиция требований возможна всегда!

Один из самых интересных вопросов, возникающий в любой компании при внедрении agile, является декомпозиция требований. Не верите?

Попросите своего коллегу аналитика рассказать вам о любом своем недавнем требовании, которое невозможно разбить на отдельные части и можно сделать только целиком?

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

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

Проблема в том, что по-умолчанию почти в каждой голове сидит фраза:

«Заказчику нужно это только целиком. На часть он даже смотреть не будет, не говоря уже о выкладке в эксплуатацию!»

И в целом, конечно, это действительно так. Но!

Остановитесь на минуту.

Поставьте себя на место заказчика, почему он так говорит?
Неужели он хочет ждать несколько месяцев, чтобы получить результат, и не хочет увидеть его, скажем, в два раза раньше?
Может быть он не хочет как можно быстрее посмотреть на результат и дать вам по нему пару новых доработок в качестве обратной связи? :)

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

Выход из этой ситуации на самом деле только один (так, чтобы была ситуация win-win) — нужно научиться поставлять результат максимально быстро, причем не обязательно даже в продакшн, можно и просто в качестве демо заказчику, на котором он сможет дать обратную связь и понимать, что если доработки действительно важны — то вы их сделаете в первую очередь.

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

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

У вас есть требование, которое невозможно разбить на части? Давайте обсудим в комментариях!

 

  • Роман Усов

    Получился очень интересный опыт попытки подвести команду к мысли о необходимости декомпозиции. Поняли, что последние месяцы размеры решаемых задач значительно увеличились в размерах и стали достигать 80-200 часов, включая полный цикл разработки. Успеть выполнить такие задачи в наши двухнедельные итерации стало просто невозможным. Дошли до того, что по итогам итерации в виде результата стали представлять бизнесу «продукт» в виде завершенного анализа, написанного ТЗ, выполненной разработки и т.д. Всё чаще и чаще стали звучать вопросы от бизнеса о том, где же наш новый функционал.

    Решили обсудить эту тему с командой. Собрали материал по проблеме, разборали преимуществ декомпозиции, предложили рассмотреть возможные варианты декомпозиции задач, описали, как можно вписать эту процедуру в наш существующий процесс.

    Вот, как была представлена проблема:

    — Мы часто получаем задачи от бизнеса в
    виде концепций, описывающих необходимую бизнесу функциональность. Это задачи с
    большой ценностью для бизнеса, но они, чаще всего, слишком сложны и слишком
    велики для того, чтобы быть реализованными в течение одного спринта.

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

    — В результате бизнес потерял главную
    ценность от коротких итераций, смысл которых – быстро и часто поставлять
    бизнесу работающий функционал. Сейчас мы стали работать в режиме, когда в
    качестве результата по итогам спринта мы презентуем бизнесу «Анализ», «ТЗ»,
    «тест-кейс» и т.д. Вопрос, который бизнес постоянно задает – почему мы по
    итогам спринта получаем, в лучшем случае, одну две задачи?

    Проблема

    •Бизнес перестал получать результат и ценность по итогам каждой итерации

    •Бизнес недоволен, что его задачи выполняются медленно

    •Бизнес не знает, когда он сможет получить то, что ему нужно

    Вот такой вариант решения был предложен:

    •Результат частями максимально быстро

    •Результат не в «продакшн»

    •Результат в качестве демо

    •Быстрая обратная связь

    •Готовность к уточнению требований и
    доработкам

    Вот такие были представлены преимущества декомпозиции:

    •Гарантированный результат каждые две недели

    •Более точные оценки

    •Более простая реализация

    •Регулярные поставки

    •Более простое управление и контроль (Done/Not Done)

    •Более полные требования

    •Возможность уточнить и скорректировать требования на демо

    •Быстрая обратная связь от бизнеса

    •Большая вовлеченность бизнеса

    •Прозрачность для бизнеса (снижение эффекта черного ящика)

    Удалось ли стимулировать команду задуматься о необходимости декомпозиции, получилась ли продуктивное дискуссия? Скорее, да.

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

    Вот, на что обратила внимание команда при всех неоспоримых преимуществах декомпозиции.

    Ничего удивительного, но одним из центральных аргументов остался именно тезис, указанный в статье: «Заказчику не нужна законченная часть функционала, в этом нет никакой ценности для бизнеса, он будет смотреть только на функционал целиком».

    Среди прочей аргументации прозвучали вот такие вещи:

    1) Если задача большая, но при этом представляет собой целостный функционал, нет смысла дробить ее на более мелкие составляющие.

    2) Если мы дробим целостную задачу, даже если она большая по размеру, на более мелкие мы:

    — увеличиваем издержки на администрирование каждой отдельной задачи

    — увеличиваем издержки на тестирование (тестировать лучше полный функционал, а не его части), тестировать отдельные части в разы более трудозатратно, и, все равно, потом придется тестировать полный функционал, лучше тестировать сразу все

    — увеличиваем издержки на интеграцию (отдельные части функционала нужно затем интегрировать, а это дополнительные трудозатраты)

    — увеличиваем издержки на подготовку демо каждой отдельной части функционала, а потом еще нужно представить демо полного функционала

    3) Бизнесу будет неинтересно смотреть на часть функционала, они будут жаловаться, что мы просто тратим их время («Лучше скажите, когда сможете показать все»)

    4) Ничего страшного, если мы представим бизнесу завершенный функционал не после одной итерации, а после двух или трех, зато бизнес увидит все сразу

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