Юрий Дубровский
Как написать бизнес-требования? Бизнес-специалисту – как разговаривать на одном языке с ИТ
Эта книга посвящается:
Функциональным заказчикам, бизнес-заказчикам нашей ИТ-отрасли, которые своим великим терпением и энтузиазмом двигают эту отрасль вперед, несмотря на то, что разработчики и заказчики живут в параллельных мирах и говорят на разных языках. Без них не было бы этой книги, да и автоматизации бизнеса как отрасли тоже.
Введение
Вы функциональный специалист бизнеса и решили автоматизировать свой бизнес-процесс? Вы уже делали это и знаете по собственному опыту, как порой нелегко донести до разработчика свои потребности? Вы аналитик, которому поручено выяснить бизнес-потребности? Вы разработчик, который хочет понять, что него хочет его заказчик?
Значит Вам нужно определить бизнес-требования.
Именно они станут общим языком, на котором смогут разговаривать разработчик и заказчик.
В этой книге обобщен опыт автора и его коллег по взаимодействию с заказчиком в крупных и небольших проектах, осмыслены ошибки и их последствия и выстроен подход к написанию бизнес-требований, который позволяет минимизировать непонимание заказчика и разработчика.
Это приводит, к лучшим из возможных результатов проекта с точки зрения удовлетворения потребностей заказчика.
Материал этой книги – попытка поделиться опытом и его систематизация, что всегда полезно. Это дает уверенность, что в какой бы роли вы ни вступали, описанные в этой книге подходы и примеры расширят ваш профессиональный кругозор, придадут больше системности вашим знаниям вопроса. И даже дадут повод задуматься и пересмотреть что-то в своей повседневной деятельности.
Вместе мы создадим еще более профессиональную и эффективно помогающую бизнесу отрасль ИТ!
Благодарим за выбор этой книги и желаем интересного чтения!
ЧАСТЬ I. Что такое бизнес-требования и зачем они нужны
Глава 1. Как начинается разработка
Вместо эпиграфа
Заказчик на объекте принимает работу у подрядчика. Заказчик смотрит: вырыта глубокая узкая круглая яма, на дне которой горит прожектор. Он гневно спрашивает:
– Что за чёрт?!
Подрядчик:
– Всё сделано по чертежу, вот, посмотрите.
Заказчик, переворачивая чертеж вверх ногами:
– Это должен был быть маяк!
Все знают этот старый анекдот. Но вот вопрос, почему подрядчик копал яму по чертежу, и даже не подумал его перевернуть? Хочется ответить, что просто неграмотный и не перевернул чертеж.
Да, возможно, это и так. Ну, а, если ошибся чертежник и переворачивать чертеж по правилам не было нужно? Почему возможна такая дикая нестыковка с ожиданиями заказчика?
Ответ простой – подрядчик исполнял задание, не задумываясь о бизнес-задачах заказчика! Он просто не знал, зачем заказчику то, что он делает. Возможно, заказчик собирался указывать путь кораблям? Но это предположение. Может быть, маяк ему нужен был совсем для другого, и тогда нужно было бы строить совсем другой маяк, или вообще не маяк?
Подрядчик всего этого не знал и не спросил, вот и получился анекдот вместо результата.
К сожалению, непопадание в ожидания и потребности заказчика – одна из животрепещущих проблем создания ИТ-решений. Такие промахи в состоянии погубить проект целиком, испортить репутацию и расшатать нервы всем участникам.
Давайте посмотрим, почему это происходит и как это можно улучшить.
Как начинается разработка
Как начинается разработка ИТ-решения?
Обычно у кого-то из ответственных лиц возникает идея «пора бы это автоматизировать». Подтолкнуть к этому жизнь может с разной стороны, например, побуждающими факторами могут быть:
– Конкуренция и то, что у других компаний данный процесс работает лучше.
– Время на принятие решений и выполнение операций превышает желаемое.
– Оптимизации и прочие внутрикорпоративные движения повышения эффективности.
– Желание стать более современным и цифровизированным подразделением.
– Хайп на рынке, влияние внешнего маркетинга.
– Вера в чудесное новое решение всех проблем.
– Новости законодательства и отраслевых регуляторов.
– Воля вышестоящего руководства.
Кроме того, может быть и множество других причин. Здесь важно, что появляется воля лица, принимающего решения, которая может быть выражена в выделении на создание ИТ-решения некоторого количества ресурсов (финансовых, временных, экспертных и др.), что должно привести к автоматизации какого-то участка бизнеса и изменить показатели, характеризующие этот участок, соответственно ожиданиям.
Появляется критерий «соответствие ожиданиям», то есть:
– ожидания должны быть сформированы;
– ожидания должны быть формализованы до метрик или категорий, которые позволили ли бы определить меру соответствия ситуации этим ожиданиям;
– для метрик и категорий определены целевые значения.
В реальности так бывает редко. Обычно ожидания сродни мечте или иллюзорному образу «светлого будущего». При этом воля (или драйв, как нынче модно говорить) имеется, а, значит, есть и движение к мечте.
Особенность мечты, как мы все знаем из многочисленных трудов по мотивации, в том, что пока не выстроен более-менее измеримый и непротиворечивый образ этой мечты, движение носит хаотический характер, а шансов достичь цели немного.
Более того, велик шанс не понять, что цель уже достигнута и разочароваться. Увы, все тоже самое, часто с куда большими затратами, верно и для создания ИТ-решений.
Чем более размыты и абстрактны ожидания, тем меньше шансов на удовлетворенность результатами проекта.
Итак, ключевые факторы начала разработки это:
– Желание, или даже мечта, драйв;
– Возможность привлечь для создания решения необходимые ресурсы;
– Понимание целей того, что собрались сделать, и вера в бизнес-полезность этого.
Пока мы говорили о желании, мечте, но всем известно, что разработка ведется на основе требований. И если мечты и желания исследуются поэтами, писателями, психологами, то требования – область деятельности аналитиков, менеджеров продуктов и разработчиков.
Немного остановимся, на том, что такое требование и каковы его свойства.
Глава 2. Немного о требованиях
Основные виды требований
Детально требования и все аспекты работы с ними проработаны книгах по управлению требованиями, например, Карла Вигерса и соавторов. Приведем необходимый для дальнейшего изложения минимум, а за остальным предлагаем обратиться к упомянутой классике.
Итак, выделяются следующие виды требований:
Бизнес-требование – высокоуровневая бизнес-цель организации или заказчиков системы, в то же время под бизнес-требованием может пониматься достаточно детализированное требование любой другой категории, если его выполнение прямо связано с достижением бизнес-цели заказчика, а отклонение от него ведет к не достижению или неполному достижению этой цели. Обычно, говоря о подготовке качественных бизнес-требований, имеют в виду эту расширенную трактовку.
Бизнес-правило – политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. По своей сути это не требование к программному обеспечению (ПО), но оно служит источником нескольких типов требований к ПО.
Ограничение – ограничение на выбор вариантов, доступных разработчику при проектировании и разработке решения
Требование к взаимодействию – описание взаимодействия с пользователем, другой программной системой или устройством.
Функциональное требование – описание требуемого поведения системы в определенных условиях. Функциональные требования описываются в форме традиционных утверждений со словами «должен» или «должна».
Нефункциональное требование – описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.
Среди нефункциональных требований обычно выделяют:
Требования по удобству использования – достаточно сложно формализуемый пункт, но часто важный, например, «размещение заказа из корзины должно выполняться не более, чем двумя кликами мыши».
Требования к производительности – нагрузочные характеристики системы по количеству пользователей, запросов, профилю нагрузки, объему данных и т.п.
Требования к безопасности – все, что касается обеспечения информационной безопасности и защиты информации, включая требования по криптографической защите.
Требование к доступности и надежности – необходимые параметры, определяющие доступность системы, простои (например, по рабочим дням с 9:00 до 18:00 московского времени, с не более, чем двумя перерывами обслуживания в день продолжительностью до 5 минут), резервирование данных и вычислительных средств.
Далее покажем основные пути, как из мечты или представлений формируются требования.
Способы сбора требований
Источников требований к ИТ-решению не так много. Вот основные из них:
– Лицо, принимающее решения по проекту и эксперты его команды, то есть те, кого абстрактно именуют заказчиком. Они имеют мечту и представление о том, чего хотят добиться ИТ-решением и потому являются основным источником требований.
– Нормативно-регулятивное окружение бизнеса. Это законодательство, регуляторные требования, обычаи делового оборота, внутрикорпоративные и даже этические нормы, в пределах которых должно строиться ИТ-решение.
– Ресурсно-технологическое окружение бизнеса. Это наличие и возможность использования ресурсов, технических средств, технологий, которые могут быть применены для ИТ-решения.
Среди традиционных способов сбора требований упомянем такие как:
– Проведение фокус-групп типичных пользователей.
– Работа с пользователями для выяснения назначения продукта.
– Проведение интервью для выявления требований.
– Проведение совместных семинаров.
– Наблюдение за пользователями на рабочих местах.
– Разработка и раздача опросных листов.
– Анализ документов.
Здесь важно отметить, что многое можно узнать анализом документов, однако их актуальность, понимание, трактовка, практика применения и степень влияния определяется лицами, принимающими решения, и экспертами команды.
Если говорить о ведении разработки в зависимости от формы требований, стоит выделить следующие подходы:
– со слов, без документирования;
– с использованием спецификаций требований, то есть с предварительным документированием и согласованием требований до разработки;
– гибкий итерационный подход (Agile), когда требования формируются с минимальной формализацией, последовательной реализацией, уточнением и доработкой.
Ознакомимся детальнее с каждым из перечисленных подходов.
Разработка «со слов»
Желание начать разработку немедленно, не тратя времени и ресурсов на подготовку, потребность обойти конкурентов, сократив до минимума время, проходящее от идеи до работающего ИТ-решения – все это породило разработку «со слов». Сюда же добавляется отношение к документации, как пережитку забюрократизированных старорежимных контор.
Так в чем же сильные и слабые стороны такого подхода? Какие условия необходимы для достижения успеха проекта при его реализации?
Сначала определим, что такое разработка «со слов». Это метод ведения разработки ИТ-решений, когда не разрабатывается никаких технических спецификаций требований в письменном виде (схемы и эскизы – тоже письменные документы), а все необходимые требования излагаются разработчику заказчиком устно.
Как это может выглядеть? Например, так: заказчик вызывает к себе разработчика и рассказывает ему, что хотел бы видеть в ИТ-решении. Разработчик его выслушивает, возможно конспектирует, и после этого начинает разработку.
Важно, что этапа согласования письменных требований нет – как понял разработчик, так и реализует.
Это может быть реализовано в рамках небольшой компании или функционального подразделения корпорации, когда ключевое лицо заказчика и разработчика работают в нем.
Возможно, что разработчик и заказчик настолько глубоко погружены в бизнес-процесс, что понимают друг друга с полуслова, а, может быть, наоборот, совершенно не понимают друг друга. Возможны, конечно, и не столь крайние вариант – в любом случае, получив информацию устно, разработчик будет руководствоваться ею сразу как требованиями, минуя согласование их с заказчиком.
Преимущества метода очевидны – скорость перехода от идеи к реализации, отсутствие для заказчика необходимости глубоко продумывать и детализировать свою идею, отсутствие трудозатрат на разработку и документирование требований.
Также ценным является ощущение отсутствия потери информации, передаваемой заказчиком разработчику – что рассказал, то и идет сразу в разработку, а не перерабатывается в требования. Поэтому кажется, что информация не может быть искажена по ходу переработки.
Ценна и возможность оперативной обратной связи разработчика с заказчиком – можно просто быстро устно спросить, получить ответ и сразу брать его в разработку.
Недостатки не столь очевидны, но они есть:
– существенные искажения, если они случились при восприятии разработчиком требований, будут выявлены только при демонстрации результатов разработки. То есть высок риски доработок и переделок (причем многократных, так как искажения возможны и в восприятии замечаний);
– перенос единолично на разработчика задачи детализации требований и разрешения противоречий, существующих в требованиях, так как не делается детальной проработки и согласования требований с заказчиком;
– отсутствие возможности восстановления истории требований. Это негативно влияет на ведение изменений, может привести к «хождению по кругу», когда одно и то же требование то возникает, то пропадает в последовательных правках решения;
– практическая сложность и высокая стоимость поддержки и развития как сторонними разработчиками, так и самим автором по истечении времени. Это произойдет потому, что требования, под которые построена система, забудутся или просто будут неизвестны новому разработчику, принятые технические решения и их обоснование, известное только первоначальному разработчику, будет непросто понять и развить (в том числе, возможны ошибочные представления, ведущие к нарушению работоспособности ИТ-решения при попытках его модификации и развития);
– неконтролируемость движения к результату, невозможность планирования на основе исполнения требований, декомпозиции процессов и частей системы. Невозможно составить письменный план работ по исполнению требований, если нет письменно зафиксированных требований;
– потребность в многократном объяснении запутанных моментов со стороны заказчика при доведении информации до разработчика – излишние временные затраты и все тот же риск недопонимания и искажения восприятия;
Таким образом, решение разрабатывать «со слов» целесообразно для небольших задач без необходимости сопровождения и развития, выполняемых в хорошо сработанных командах, где заказчик и разработчик отлично понимают детали бизнес-процесса и идеи друг друга с полуслова.
В иных случаях шанс достижения цели разработки «со слов» без разочарований невелик.
Письменная спецификация требований к разработке
Другой крайностью является старт проектирования и разработки только по окончании детальной проработки требований, оформленных и согласованных письменно, в виде документа.
Называться он может по-разному, в зависимости от принятых у заказчика или разработчика стандартов. Это могут быть и бизнес-требования, и требования к системе, и программная спецификация – перечень не полный, встречаются разные креативные варианты.
Первое ощущение, которое возникает при описании такого подхода – долго, нудно и, скорее всего, дорого. И это ощущение имеет под собой реальную почву. Так почему же и в каких случаях имеет смысл использовать такой подход?
Что дает нам письменная согласованная специалистами заказчика спецификация требований (пропустим про спокойный сон руководителя проекта, поскольку у него юридически ограничены рамки проекта, хотя это тоже есть)?
Хорошая спецификация дает нам предварительно построенную достаточно детальную и непротиворечивую картину, что же мы должны построить.
При этом еще и определены приоритеты, как это строить, проработаны и сняты основные нестыковки, с которыми при построении решения столкнется разработчик.
То есть, хорошая спецификация существенно повышает шансы достигнуть цель разработки в плановые сроки и бюджет. Также проще планировать путь и ресурсы исполнения проекта.
Здесь важно отметить, что речь идет о хорошей спецификации, а не о томах сказок и легенд, которые нередко выдаются за бизнес-требования. Только согласованные, достоверно отражающие реальность, однозначно толкуемые, проверяемые и непротиворечивые требования, определяющие искомую цель автоматизации и изложенные в спецификации обладают названными достоинствами.
Некоторые недостатки подхода очевидны – сравнительно долго и трудозатратно – нужно время, чтобы формализовать замысел, записать и оформить требования, согласовать их. Это явно дольше, чем просто рассказать.
Из неочевидного – если разработчик неправильно поймет спецификацию или она по содержанию не несет в себе требований, то может возникнуть опасная иллюзия, что все под контролем и работа идет к цели по плану, хотя на самом деле разработка ведется даже не «со слов», а из предположений разработчика как это могло бы быть в спецификации.
Письменные спецификации требований характерны для сложных проектов с широким охватом бизнес-процессов, интеграционными взаимодействиями, длительным жизненным циклом решения и, соответственно, сроком сопровождения. Применяются чаще в крупных организациях, склонных к тяжелым, например, водопадным, методологиям внедрения.
Еще один момент – время разработки спецификации. Мир сейчас меняется быстро, и бизнес-среда тоже, поэтому время создания решения, в том числе требований к нему, часто критично.
Проработка хорошей спецификации требований требует времени, которого может и не быть – это следует сопоставить с бизнес-окружением, конкурентами, сроком жизни разрабатываемого решения и вовремя остановиться с детализацией.
Случаи, когда требования к моменту завершения их подготовки уже устарели – увы, обычная история в современном корпоративном мире.
Поэтому хорошая спецификация требований – отличное подспорье проекту разработки ИТ-решений, но нужно чтобы она была действительно хорошей и завершалась до того момента, когда ее содержание устареет.
