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

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

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

Поэтому нужен какой-то критерий. Сформулировать его нам поможет представление о рисках проекта, которое поверхностно сводится к тому, что:

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

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

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

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

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

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

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

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

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

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

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

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

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