Ваши требования … не SMART
Люди учатся на опыте; эффективнее — на своем, но интереснее учиться на чужих ошибках. Все просят меньше теории и больше кейсов из практики. Привет, Хабр! Накипело, накопилось, ловите пару кейсов и пару правил работы с требованиями. Мотайте на ус, системные и бизнес-аналитики, владельцы продукта и разработчики.
На связи Валерий Львов, который уже много лет работает переводчиком между бизнес-заказчиком и проектировщиками систем. Моего опыта хватит, чтобы и характерные истории вспомнить, и систематизировать их, и совет дать.
Уверен, вы слышали, что требования к разрабатываемому ПО должны быть S.M. A.R.T. — Specific (конкретные), Measurable (измеримые), Attainable (достижимые), Relevant (значимые) и Time-bound (своевременные). Слышали это правило все, но часто ли мы соблюдаем его? Часто ли проверяем требования по этим критериям? Если нет — мало обжигались. Давайте пофантазируем с примерами: «Что, если…».
Не конкретные
Маркеры: общие слова — «почти всегда», «как правило», «понятный», «при наличии возможности», «допускается».
Пример НФТ: «приложение должно иметь интуитивно понятный и дружеский интерфейс».
Пример требования к функциональности: «поле ИНН обязательное, но допускается его отсутствие, если клиент не знает своего ИНН».
Здесь хочется процитировать Сергея Мартыненко: «Тестируемость — важнейшее и достаточное свойство требований».
Hidden text
Сергей Мартыненко — замечательный аналитик, слушать выступления которого — одно удовольствие
Придумайте тест (ы), как проверить систему на заполнение этого поля ИНН. Какое поведение системы ожидается, если
ИНН заполнен
ИНН не заполнен
ИНН не заполнен, потому то пользователь его не знает
Не смогли написать тест — значит, требование негодное. Уточняйте.
User-friendly интерфейс как будете проверять? Если через экспертное мнение приёмщика, то вряд ли сдадите систему. Интерфейс соответствует style-guide или другому документу? А вот теперь понятно, что делать и что проверять.
Аккуратнее с оборотами »… и …»,»… или …», «любой». Для заказчика — это в первую очередь части речи, он может не воспринимать их так, как программисты или математики. «Или», кстати, есть двух сортов — OR и XOR.
Так, «Список клиентов, проживающих в Москве и Питере» не выдаст ни одного клиента, потому что проживать в двух города одновременно нельзя.
»…при наличии у клиента паспорта или водительского удостоверения…» — как быть с клиентами, у которых есть и паспорт, и права одновременно?
А что такое «любой»? any of или one of?
Отдельно хочется рассказать про пассивный залог, когда нет действующего лица. Например, «Отчёт должен направляться…». Кто его должен сделать? Система сама сгенерирует? У человека есть возможность нажать на кнопку? Если мы сейчас находимся на уровне ФТ, то предлагаю писать кто — что — над чем совершает.
Исключение: такая абстрактная формулировка хорошо работает на высокоуровневых требованиях, когда мы не определяем вариант реализации. И даже не ограничиваем, что решение бизнес-задачи вообще должно быть обязательно в ИТ-системе. И в acceptance criteria, которые тоже пишутся на бизнес-языке.
История из практики. Небольшая международная компания. Задача: «Отчет по операциям за день должен направляться банку-партнеру до 9:00». Отчет нужной структуры мы с программистом сделали за 20 минут. Теперь этот отчет «должен направляться». База вот в этом сегменте сети, FTP-сервер — в другом, между ними — многоточие. За час мы собрали в кучу десяток людей — админов всех родов и безопасников, которые так и не смогли договориться между собой о сети и правилах. В этот момент мой коллега задал несколько интересных вопросов:
Есть ли условие, каким именно сервисом это должно быть реализовано? Нет.
Нужен ли этот отчет нам навсегда? Нет, только до Нового года.
А что, если генератор отчетов будет делать отчет, кидать его по электронной почте менеджеру, а утром я буду первым делом нажимать «сохранить как…» и сохранять файл на сетевой диск? Максимум 2 минуты х 60 дней = 2 часа. Это дешевле, чем уже потраченные 10 человеко-часов админов, которые еще не закончили спорить про свои сегменты. В требовании ведь нет пункта, что все должно быть автоматизировано на 100%. И, кстати, персонал — тоже часть информационной системы.
Так вот, общие слова работают на верхнем уровне, при первом подходе к фиксации требований, когда нужно зафиксировать бизнес-цель и не ограничивать исполнителя в фантазии, как это лучше реализовать. А когда проваливаемся в детальные требования и готовимся проектировать — только схема «при каких условиях — кто — что делает — над чем». «Система по рабочим дням в интервале 8:00 — 9:00 должна генерировать отчет по операциям за предыдущий день (структуру см. в приложении 1), архивировать его (формат — gzip) и публиковать в FTP-каталоге //server/ftp/{partnrtname}».
Не измеримые
Маркеры: «самый», «лучший», «удобный».
User-friendly интерфейс как будете проверять — личное мнение приёмщика? Вряд ли сдадите систему.
Интерфейс соответствует style-guide или другому документу? Понятно, конкретно что делать и что проверять.
Правило то же: если не можете сформулировать, как будем проверять— значит, требование не прошло проверку на качество.
Не достижимые
Маркеры: «Мгновенно». «Доступность 24×7». «Доступность 100%». «Одновременно».
У автора требований есть своя картинка, как это работает, и он думает, что остальные его понимают. Хотя не исключен злой умысел — поставить неразрешимую задачу, а вдруг выполнят.
«Деньги должны зачисляться онлайн» — такое требование к зачислению прозвучало изначально. Аналитики вздрогнули, но больше всех напряглись архитекторы, которые теперь должны довести скорость получения данных, расчет и зачисление до… кстати, до чего?
— Онлайн — это как? — не постеснялся спросить кто-то.
— Ну, что тут непонятного? Онлайн. Быстро.
— Можно на примере?
— Вы, когда карточкой в магазине платите, получаете онлайн смс о списании. Вот и здесь должна быть такая же скорость.
— То есть, если сумма зачислится в пределах двух минут, клиента эта порадует?
— Да, именно!
Архитекторы и инфраструктура облегченно выдохнули. Превысить скорость света не потребовалось.
Уточняйте, сколько вешать в граммах. Скорее всего все эти «одновременно» на самом деле означают «в пределах пяти минут».
«Доступность 100%» недостижима. «Одновременно» не бывает. «Непрерывный» в результате уточнений сдуется до «раз в пятнадцать минут».
Не значимые и не своевременные
— Эта штука действительно нужна и нужна в первую очередь?
— Нет, ну что вы. Но не помешает сделать по возможности.
Или же…
— Ну хорошо, раз уж 100% не бывает, давайте тогда уж 99,999%!
Стоимость решений с доступностью 99,9%, 99,99% и 99,999% отличаются на порядок. Если вы — каталог районной библиотеки, то зачем вам доступность как у атомной станции? Будьте реалистами, заказывайте доступность 95%.
Котик-аналитик визуализирует
Вывод
Все мы знаем про эти требования к требованиям и здравую логику, но на грабли все равно наступаем. И речь не про то, что они бездумно передают нам требования в кривом виде. Увы, формирование и формулирование требований — это совместный процесс заказчика и исполнителя, да еще и итеративный.
Если требования (и вообще важную мысль) формулируются и высказываются устно, то на слух трудно уловить некачественную формулировку. Это яркая картинка, она зайдёт. А когда попытаетесь написать эту же вещь на бумаге (и еще лучше — нарисовать), то тут как раз полезут вопросы. Вывод? Для структурирования переносите принятую информацию в иной формат. Из голоса — в текст. Из текста — в схемку.
Не понравились мои заметки? Читайте ISO 29148:2018, там про требования в хорошем и плохом смысле написано.
