Требования собираются на разных уровнях у разных классов пользователей, и неудивительно, что например, бизнес-требования и требования пользователей иногда противоречат друг другу. Но, выявить противоречие в требованиях не составит труда опытному аналитику, куда сложнее бороться с рисками, которые выражены не так явно.
А меж тем, предотвращение ошибок в требованиях и обнаружение их на ранних стадиях сильно уменьшает объем переделки:
“Ошибки в требованиях стоят от 70 до 85% стоимости переделки” (Leffingwell, 1997).
Предлагаю рассмотреть три айсбергоподобные проблемы в требованиях, предупреждение которых позволит существенно снизить объем доработки и выполнить работы качественно и в срок.
1. Недостаточность вовлечения пользователей: Заказчики зачастую слепо доверяют Исполнителю на этапе анализа, надеясь на его практический опыт и заявленные компетенции. Исполнители же позиционируют себя как консультанты, имеющих в своем арсенале проверенные методики и использующие только лучшие практики (best-practices). Безусловно, команда опытных разработчиков и аналитиков - это половина дела, но если пользователи не будут активно участвовать и осознавать всю важность сбора требований и обеспечения их качества, то в итоге они получат хорошую систему, но… будет ли она удовлетворять именно их требованиям? В конце концов, кто лучше знает, как должна работать буровая установка: инженер или разработчик программного обеспечения к данной установке? У разработчиков есть опыт, и они знают о возможностях реализации больше, но они не смогут предугадать, что нужно Заказчику.
Что делать: активно вовлекать Заказчика, доносить до него информацию о важности качественных требований. Мне в этом помогает проведение вводного семинара о требованиях. На семинар приглашаем кураторов проекта, владельцев процессов, экспертов в предметной области и ключевых пользователей, всех тех с кем активно будем взаимодействовать в ходе проекта. И хотя средняя продолжительность семинара 15-30 мин, бывает достаточно трудно обосновать Заказчику необходимость отдельной встречи посвященной проблемам в требованиях. Поэтому зачастую доносить информацию приходится в рамках первой встречи по запуску проекта (Kick-Off Meeting), на которой, как правило, в полном сборе присутствует наша целевая аудитория.
2. Двусмысленность требований: страшилка любой спецификации требований (Lawrence 1996).
«Система должна иметь дружественный интерфейс» - если вы пропустили такое требование, считайте, что вам обеспечены «задушевные» обсуждения на этапе приемке результатов, потому что понимание о “дружественном”, “удобном” и “легком” у каждого свое.
Что делать: проводить экспертизу требований различными группами пользователей и проговаривать основные моменты. Проводить общие семинары по обсуждению требований, чтобы убедиться что вы говорите об одном. В документах использовать общепринятую терминологию. Представлять требования с детализацией понятной пользователю и избегать неоднозначных терминов в требованиях: “удобно”, “быстро”, “гибко”, “легко” и прочее абстрактное, неизмеримое и не тестируемое явно. Наш девиз: Больше ясности и конкретики!
3. Золочение продукта (Gold Plating): Под «золочением» понимают такие ситуации, когда разработчики добавляют функции, которых нет в спецификации, но им кажется, что эти функции обязательно (!) понравятся пользователям (Wiegers K.E). Красивый и удобный интерфейс — это важно, дополнительная функциональность, которая, как правило, не является критической, но добавляет некую ценность продукту - или «фичи» - это важно. Но это должно быть в меру, чтобы не мешать плановой реализации основного функционала. Ведь если не реализован основной функционал, то все остальное не будет иметь никакого смысла. Кому нужен гоночный болид с фантастическим дизайном и аэродинамикой, но без ходовой части?
Однажды мы разрабатывали продукт с нуля. Все настолько прониклись идеей создания “самого лучшего программного продукта”, что источник идей не иссякал ни на день. Появлялись новые требования от пользователей, разработчики генерировали десятки “улучшалок”, так что наш список “желаемых и некритичных требований” в несколько раз превысил список с обязательными требованиями. Каждая “фича” яростно отстаивалась её хозяином, который с пеной у рта доказывал всем, что именно этот функционал - путь к бесконечному счастью и признанию.
Близился первый релиз, и в него было решено включать только обязательный критичный функционал и пару не дорогих в реализации “бантиков”. Сейчас мы понимаем, что это было верное решение, и хотя на тот момент система нам казалась ограниченной и даже немного примитивной, но Опытно-Промышленная Эксплуатация (ОПЭ) расставила все на свои места… После ОПЭ стало ясно, что текущего функционала более чем достаточно, а добавление дополнительного функционала на первоначальном этапе только бы перегрузило продукт, да и к тому же как оказалось, пользователям нужны совсем другие «бантики». Мораль: Первым делом — обязательный и критичный функционал ну, а feature потом.
Что делать: Ранжировать все требования по степени важности реализации для пользователя (тут вам в помощь методики ранжирования: MoSCoW, Kano), и сложности разработки (уповаем на архитектора или тимлидера). А ещё можно попробовать создавать Карты Бизнес-эффектов (Impact Mapping), например, с помощью инструмента http://effectcup.com.
Конечно, список можно продолжать до бесконечности, и поскольку каждый проект уникален и неповторим, то он имеет свои особенности и свои трудности - панацеи нет. Мы рассмотрели только основные проблемы требований и способы их решения. А, как известно, лучше заранее продумать решение проблемы, чем пытаться решить ее тогда, когда будет уже поздно.
А какие проблемы с требованиями и способы их решения знаете и применяете вы в своей работе?
Анастасия Сороковая
бизнес-аналитик
Анастасия, спасибо за статью, но позвольте немного покритиковать — к сожалению, статья получилась из разряда «О высоком», для всех — и ни для кого. Опытные аналитики скажут: «Ещё одна статья о том, что и так понятно», неопытные подумают, что понятно, и пойдут делать те ошибки, о которых вы писали. Нет качественных примеров для каждой проблемы, не хватает подробного разбора, как бороться с проблемами. Если говорить более конкретно:
Ошибка №1 — простите, но что вы доносите до заказчика за 15-30 минут в самом начале проекта? Этого даже для знакомства не совсем достаточно, а вы уже начинаете втирать «Наши космические корабли…»? А если заказчик покивал головой и забыл про ваши слова, что дальше?
Что делать, если системой пользоваться будут не сами сотрудники заказчики, а клиенты заказчика (то есть к пользователям у вас нет доступа)? Что делать, если у системы очень широкая целевая аудитория? Что делать, если система уникальна, или тщится быть таковой? А если у заказчика держателей одних и тех же требований больше трёх — это вообще беда.
Ошибка №2: двусмысленность требований — это не только «нетестируемость» формулировок. Двусмысленность подразумевает, что требование можно протестировать, но для приведенной формулировки может быть от двух до бесконечного числа толкований. Также в части «Что делать» вы сами пишете: «требования с детализацией понятной пользователю». Сможете перечислить критерии понятности? :)
Ошибка №3: опять те же грабли — «это должно быть в меру». Какие у нас есть меры «золочения»? :) В «что делать» вроде бы всё красиво, но в тоже время бесполезно — гораздо интересней было бы увидеть ссылки на статьи, где приводятся примеры применения методик ранжирования в аналитике.
Денис, спасибо за конструктивную критику, это моя первая статья и мне действительно очень важна обратная связь. Тема действительно очень общая, а мнение автора очень субъективное, да и может ли быть по-другому? Проекты уникальны и их проблемы тоже, и каждый находит для себя свои проверенные методы решения.
А теперь буду защищаться:
1. Недостаточность вовлечения требования: К сожалению, не имею опыта в разработке решений для рынка, и мой Заказчик всегда в зоне доступности, но даже его трудно привлечь для более продолжительных встреч. Согласна, что 15-30 минут очень мало, но этого достаточно, чтобы обратить на данную проблему внимание. Никто не мешает в ходе личных бесед/интервью и других активностей на этапе анализа доносить информацию. Но, первая встреча тем хороша, что там одновременно присутствуют наша ЦА и, что не маловажно, в добром расположении духа.
2. Двусмысленность требований: Чтобы избежать двусмысленности (не однозначного истолкования, не тестируемости, детализации не понятной пользователю…) я пока лучше чем ревью различными группами (аналитики, архитектор, QA, пользователи) ничего не нашла. Буду рада, если поделитесь проверенными методами.
3. Золочение продукта: Меры, как и потребности у каждого свои. И чтобы разобраться с тем, что в первую очередь нужно делать (и не дорого) уже используется ранжирование и приоритезация. Но это действительно темы отдельных статей (ссылки поищу)
Денис, вероятно вы действительно относитесь к опытным аналитика и заявленные в статье проблемы и способы их минимизации для вас не представляют ни какой ценности. И вам бы хотелось увидеть конкретные примеры, критерии оценки, способы решения, чтоб ещё пополнить багаж своего знания-опыта.
Но не нужно говорить за всех.
Лучше бы сами поделились конкретными приметами)
*примерами
Мне статья понравилась. Хорошо структурирована, легко читается.
Есть несколько спорных моментов… ИМХО, вовлеченность пользователей не сильно улучшится, если провести только короткое совещание в начале этапа сбора требований.
В своей практике я стремлюсь найти в требованиях противоречия и предложить пользователям обсудить их.
1) противоречие — это вызов для пользователей, следовательно, способ их расшевелить и заставить погрузиться в ситуацию.
2) погружение в ситуацию неизбежно устранит всякие многосмысленные формулировки требований
3) противоречие часто заставляет пользователей переосмыслить сложившуюся бизнес-практику и открыться для восприятия новых подходов. А в рамках новых подходов у программистов появляются большие возможности отвести душу на «золочении».
4) совместная работа при обсуждении противоречия способствует налаживанию тесных контактов аналитика с пользователями
Спасибо за комментарий!
Поиск противоречий, действительно позволяет расшевелить и погрузить пользователей. Про налаживание тесных контактов +1.
Особенно когда требования одной влиятельной группы пользователей противоречат требованиям другой не менее влиятельной, тут аналитик должен сыграть очень тонко и профессионально.
Ситуация, когда противоречие возникает между требованиями разных влиятельны групп пользователей, может быть даже забавной.
В особенности, если разрешение противоречия близко к идеальному конченому результату: обе группы пользователей тупо смотрят на аналитика и не понимают, почему потребовалось столько обсуждать, чтобы в конце концов именно их требования «взяли верх». :)
Андрей, идеальный конченый результат — это сильно:)
Идеальный конечный результат — это термин ТРИЗ, который обозначает, что разрешение противоречия достигается при минимальном изменении системы. В идеале, ничего не меняешь, а противоречие исчезает.