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

Почему валидация требований важна

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

На это влияет и тот момент, что IT-проекты сейчас стали сильно сложнее, чем 10 или даже 5 лет назад. Если раньше можно было как-то хватать знания по крохам, изучать что-то по ходу дела, то сейчас так уже нельзя. Нужно иметь хоть какую-то теоретическую базу, большинство работ уже нужно делать осознанно. Уровень неосознанной компетентности уже не прокатывает в текущих проектах. Нужно погружаться глубже в IT-анализ.

Немного теории

Что такое валидация требований?

Есть BABOK. Если вы его читали, но не помните про валидацию требований, значит, читали невнимательно. Но в целом я вас понимаю: это ужасное чтиво. Если экстраполировать на наш бизнес, это ничем не лучше, чем Налоговый кодекс или ПБУ. Но тем не менее это свод знаний, фундамент, который желательно хотя бы иметь, чтобы в него подглядывать и понимать, на чем вы строитесь.

В BABOK есть такая область знаний, как «Анализ требований». Мы аналитики, правильно? Мы должны анализировать. Значит, анализ требований – это про нас, мы должны это знать.

Согласно BABOK, эта область знаний состоит из нескольких частей:

• Спецификация – это формализованное описание требований, набора требований.

• Верификация – это про качество самих требований, об этом чуть позже.

• Валидация – проверка полезности требований для бизнеса. То есть первое, что нужно понять: валидация – это связь с бизнес-требованиями. И второе: это часть анализа требований, мы должны это делать.

• Определение архитектуры требований, то есть структурирование требований так, чтобы они поддерживали конечную цель бизнеса, как говорит BABOK.

• Подбор и оценка решения.

Естественно, если мы будем работать строго по BABOK, ни один проект у нас не взлетит. Нужно как-то эту теорию применять на практике.

На практике то, что я вижу чаще всего, – это примерно следующие этапы. Они могут быть неявными, могут быть скрытыми, но всегда так или иначе присутствуют:

• Верификация;

• Валидация;

• Приоритезация;

• Трассировка.

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

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

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

И еще трассировка. Это для меня лично больная тема. Трассировка очень важна, но ее никто не делает, потому что делать это сложно. Те, кто знает, что такое трассировка требований в бизнес-анализе, понимают, почему это делать сложно.

Верификацию и валидацию часто путают.

Верификация требований – это проверка качества: правильно ли записаны требования? Правильно ли мы строим систему с технической точки зрения, будет ли система правильно работать?

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

Немного практики

Валидация направлена на содержание требования, это его проверка. И важный момент, в котором BABOK абсолютно прав: валидация – процесс непрерывный.

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

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

Какие действия описывает BABOK, которые мы должны выполнять в рамках всего жизненного цикла наших требований?

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

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

Еще один момент – оценка соответствия границам. То есть укладывается требование в границы проекта или нет.

Приведу несколько условных примеров.

Есть бизнес-задача – сократить время ввода первички в систему на 20%. Изначально за ней есть какой-то контекст. Это не цель бизнеса как таковая, а задача, которая должна помочь достижению целей бизнеса.

У нас собран пул требований, и среди них есть внедрение ЭДО. Мы предполагаем, что это поможет достичь цели проекта.

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

Другой пример. Есть бизнес-задача: получать финансовую управленческую отчетность не позднее пятого числа месяца, следующего за отчетным.

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

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

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

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

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

Если требование нельзя связать с бизнес-задачей

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

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

И тут может возникнуть вопрос: «Я аналитик, я не бизнесмен. В бизнесе не разбираюсь. Как я могу решить, как определить, что система решает бизнес-задачи?»

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

У Елены Ивановой была очень хорошая статья //infostart.ru/pm/2706250/ про то, для чего аналитику нужно знать бизнес и как этот бизнес понять, как, по ее выражению, «нарастить мышцу».

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

Что делать

Как эту валидацию проводить?

Самый простой способ – матрицы валидации, они же матрицы трассировки.

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

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

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

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

Приоритизация требований как инструмент валидации

Какие еще есть методы? По сути, это техники приоритизации требований, основанные на ценности требований. Их на самом деле полно.

Я покажу только две, которые сама реально использовала и использую.

Первый – метод MoSCoW.

• Must have – должно быть обязательно. Это набор требований для MVP, критически важный. Без этих функций продукт вообще не будет работать, цель не будет достигнута. Тот самый MVP.

• Should have – важные, но некритичные функции. Без них продукт в целом будет работать, но не будет достигнута желаемая эффективность, он будет менее полезным.

• Could have – желательно. Различные дополнения, которые мы реализуем, если есть дополнительное время и дополнительные ресурсы.

• Won't have – то, что можно вообще отложить на когда-нибудь потом.

Второй метод чуть более сложный, но там есть формула, которую можно посчитать. Это стоимость задержки – Cost of Delay.

По сути, он позволяет превращать время, ваши часы, в деньги. И мы можем выяснять, какие требования, какие задачи принесут больше пользы.

Он включает бизнес-ценность, временную критичность и так далее. Принцип достаточно простой: мы оцениваем требования с точки зрения того, что будет, если мы их не сделаем. Допустим, если мы этого не сделаем, у нас машина со склада не уедет, отгрузка не пройдет, будут штрафы и недополученная прибыль – кранты. А если мы не сделаем что-то другое, бухгалтеру, тете Люде, придется просто побольше поработать. В целом все нормально, ничего критичного для нашей системы не произойдет.

Это интересный подход, который позволяет немного перестроить мышление в сторону вопроса: «А что будет, если не делать?» И тут могут выясняться интересные вещи: действительно необходимых требований для MVP совсем немного, а все остальное полотно вообще не нужно, без этого можно жить.

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

Где во всем этом заказчик

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

Если у вас самая хорошая в мире лопата, продавец, производитель лопаты и сама лопата не несут ответственности за вскопанные грядки. Это делаете вы – те, кто пользуется этим инструментом.

Это неприятная и очень непопулярная мысль о том, что заказчик за что-то отвечает.

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

Когда вы приходите к врачу и говорите: «У меня болит», врач выписывает вам лекарства, проводит процедуры, но боль все равно ваша. У вас болит, не у врача. Это нужно понять для себя раз и навсегда.

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

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

Ошибки

Теперь о самых частых ошибках и о том, как их можно избежать.

Первая – формальный подход.

Мы забыли про непрерывность. Что-то вначале формально сделали, подписали, галочку поставили – и все, дальше забыли и погнали делать.

А потом на тестировании или вообще на ПСИ вспоминаем об этом и понимаем, что требование, которое мы реализовали, никак не соотносится с исходными целями проекта и бизнес-целями.

Это снова отсылка к тому, о чем я говорила: нужна непрерывная валидация. Вы можете валидировать не только документы. Можно валидировать идеи, концепции, на первых стадиях проводить какие-то воркшопы с пользователями и так далее.

Главное – помнить, что валидация является процессом.

Вторая ошибка – валидировать только со стейкхолдером, только с «заказчиком банкета».

Мы приходим к нему, все рассказываем, он говорит: «Да, все круто, деньги есть, работайте, все замечательно», – и на этом забываем про валидацию.

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

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

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

Третья ошибка – игнорировать нефункциональные требования.

Нефункциональные требования – кому они вообще нужны? Мы что-то пропишем в проекте, где-то в ТЗ или уставе: какая у нас должна быть доступность или еще что-нибудь. А можно вообще про это забыть.

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

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

Поэтому с нефункциональными требованиями тоже нужно работать и валидировать их точно так же.

Четвертая ошибка – показывать «как» вместо «зачем».

Если мы проводим валидационные сессии, важно понимать: это не демо функционала. Это могут быть разовые ситуации, когда у нас возникают вопросы по требованиям, когда появляются сомнения: «А не фигню ли я делаю?»

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

То есть идем от общего к частному. Допустим, мы автоматизируем процесс согласования заявок, чтобы сократить время с трех дней до одного часа. Раньше у вас было пять бумажных согласований, а теперь будет один цифровой маршрут с согласованиями. Здесь работает менеджер, здесь – директор. Здесь есть форма с полями. Вы вообще с этой логикой в целом согласны? Примерно так это работает.

А если у нас Agile?

Валидация – это все, конечно, здорово, когда у нас проекты на целый год. Можно там еще и валидировать, и верифицировать, бюджеты на все это тратить. А если у нас спринты по две недели? Как тут валидировать?

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

В общем-то, Agile построен на валидации. Если вы раньше не знали, что это называется валидацией, то теперь знаете: если говорить языком умных книжек вроде BABOK, то это именно она.

Есть, например, очень старая статья https://habr.com/ru/companies/1c/articles/277237/ 2018 года о том, как наш любимый вендор, фирма «1С», решает, что возьмет в следующий релиз. По какому принципу они это решают? В ней ни разу не упоминается слово «валидация», но это она и есть. Это сама концепция.

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

Вместо заключения: валидируйте осознанно. Валидируйте хорошо. Просто валидируйте.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.