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

Чтение книги онлайн.

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

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

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

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

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

      Глава 3. Зачем бизнес-требования?

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

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

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

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

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

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

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