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

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

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

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

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

– Получение части функций решения (непосредственно приближает к цели);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.