Читать книгу Как написать бизнес-требования? Бизнес-специалисту – как разговаривать на одном языке с ИТ - Юрий Дубровский - Страница 10

Строить или перестраивать?

Мне нравится подход, восходящий к ТРИЗ (Теория решения изобретательских задач, разработанная Г.Альтшуллером в середине 20 века), который предполагает, что идеальное решение задачи, когда она сама себя решает. В рамках этого подхода при появлении любого нового компонента стоит спросить себя, а зачем он? Нельзя ли прийти к цели без него?

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

Так зачем же нам тратить усилия на них? Все дело в затратах и вероятности. Как и в когда-то популярной вероятностной задаче о вероятности того, что обезьяна, сидящая за пишущей машинкой, напечатает роман «Война и Мир», в нашем ответе также нужно указать вероятность того, что полученное решение без требований совпадет с задачей.

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

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

Такое решение обычно существенно дешевле по стоимости внедрения, но может нести риски потери части бизнес-процессов, ухода персонала при переучивании на новые процессы (изменения не всем по душе) и утрате каких-то важных «ноу-хау», запрятанных в процессе и составлявших конкурентные преимущества.

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

Вопрос, нужны ли требования, еще и сводится к тому, хотим ли мы максимально быстро построить целевое решение, или готовы постепенно и последовательно приближаться к целевому, перестраивая и перестраивая?

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

– это исследования и уточнения требований, когда в некоторый момент можно просто остановиться, сказать себе «стоп, теперь нам все понятно» и приступить к разработке решения с понятными требованиями или просто получить необходимые выводы и остановиться (например, CusDev прототипы);

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

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

Проект или прототип?

Любое дело (конечно, не приводящее к разрушениям) можно делать, по крайней мере, двумя способами:

– сначала подумать, потом сделать;

– сначала сделать потом посмотреть на результат, подумать и переделать.

Разработка программного обеспечения не является исключением, поэтому есть способ разработки с предварительным проектированием (сначала подумать), и с прототипированием (сначала сделать, потом поправить).

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