Все разработчикам знаком момент, когда заказчик просит что — то сделать, но толком не вдается в детали? У меня были примеры, когда заказчик вообще не описывал требования, а ожидал, что ему ЧТО‑ТО создадут, а ну уж потом он/она скажут что не так. Или так. Или не так:‑) Предлагаю разобраться, когда гибкость превращается в ад
Сколько вешать в граммах...
Всем нравится определенность и ясность. И очень редко они действительно доступны. Тогда мы определяем желаемый результат в виде требований. Заказчики любят жаловаться на то, что их заставляют делать то что они вроде как не могут. И оно понятно, любой человек понимает, что когда его спрашивают какой дом он хочет, он может объяснить сколько комнат ему надо, какой площади, где санузел и так далее Для обывателя это исчерпывающее описание дома, хотя любой специалист понимает, что конкретикой тут и не пахнет, строителям нужно знать требования по электрике, материалам и так далее Так вот когда заказчика ПО просят предоставить требования, ему почему‑то кажется, что он должен описать буквально каждый шаг работы программы. И да, это его пугает. Нам бы, конечно, хватило описания, мы хотим видеть метрики А, чтобы принять решение о действии Б, в результате получит В. И тут начинается самое интересное. Заказчик желает сохранить гибкость, а на деле выдает амбивалентность требований.
Что такое амбивалентность требований?
Амбивалентность требований (или двойственность требований) — это ситуация, когда одно и то же требование может интерпретироваться двумя или более взаимоисключающими способами. Другими словами, требование сформулировано настолько расплывчато, двусмысленно или содержит внутренние противоречия, что разные заинтересованные стороны могут понять его по‑разному.
Люблю слово «отчет». Что только под ним не подразумевают:‑) Для пользователя как правило, отчет — это готовые выводы, которые он получил. Как это технически реализовано ему сильно все равно. А 1С ники под отчетом понимают.... отчет как выборку данных.
Как это проявляется в бизнесе и проектировании процессов?
Вот несколько конкретных примеров того, как может проявиться амбивалентность требований, с точки зрения проектировщика бизнес‑процессов:
Неоднозначные формулировки: Например, требование «Улучшить обслуживание клиентов». Что это значит? Уменьшить время ответа? Увеличить процент решенных проблем с первого обращения? Повысить удовлетворенность клиентов? Без конкретики, невозможно разработать процесс, который бы однозначно отвечал этому требованию.
Противоречивые требования: Например, «Необходимо сократить расходы, но при этом улучшить качество продукта». Сокращение расходов часто влечет за собой снижение качества (например, использование более дешевых материалов). Требуется прояснение приоритетов и компромиссов.
Один мой руководитель использовал приоритет “ Немедленный«. Да, был еще и „Срочный“, „Важный“:‑) Ну а че они?:‑) Это еще цветочки. В практике был один бизнес — заказчик, который в плане на месяц всем задачам ставил приоритет 1. По шкале от 1 до 3 от самого важного до низкого. Получался прекрасный список из 15 задач с одинаковым приоритетом. »
Неявные предположения: «Система должна отправлять уведомления». Неясно, какие уведомления? Когда? Кому? В каком формате? Предположения о подтексте могут привести к неправильной реализации.
Субъективные термины: «Быстрый отклик», «удобный интерфейс», «эффективный процесс». Что является «быстрым» для одного, может быть медленным для другого. Нужны четкие метрики и критерии.
Требования, зависящие от контекста: «Принять платеж». Для какой валюты? Какими способами (банковская карта, наличные, электронные деньги)? Какие комиссии? В каких странах?
Раньше я относилась к тем людям, которые любят говорить: «без воды». Оказалось, что «вода» — это часто контекст, то есть чуть ли не самая важная часть. Сейчас я склонна думать, что амбивалентность требований чаще присуща таким же врагам «воды».
Почему амбивалентность требований опасна?
Неустранение амбивалентности требований может привести к серьезным проблемам:
Неправильная реализация проекта: Разработчики или исполнители могут реализовать процесс, исходя из своего собственного понимания требования, которое может отличаться от того, что ожидали заказчики.
Переделки и задержки: Выявление расхождений на поздних этапах проекта потребует переделок, что приведет к увеличению сроков и затрат.
Недовольство заинтересованных сторон: Если результат не соответствует ожиданиям, заинтересованные стороны будут разочарованы и потеряют доверие к проекту.
Снижение эффективности: Нечетко определенный процесс будет работать неэффективно и не сможет достичь поставленных целей.
Под каждый из этих пунктов можно приводить огромное количество примеров, но думаю, что у всех при чтении возникли вьетнамские флешбэки.
Я использую ряд техник, чтобы выявлять и устранять амбивалентность требований:
Тщательный сбор требований: Устанавливаем цель выраженную в явном виде — как мы понимаем что работы завершены? Какова конечная цель? Какие у нас ресурсы? Какие ограничения есть?
Использование техник моделирования: Создание диаграмм бизнес‑процессов (BPMN, IDEF0) позволяет визуализировать требования и выявить противоречия. Смотрим, где процесс заходит в тупик, или где вариантов отработки стало слишком много.
Проведение воркшопов с заинтересованными сторонами: Совместное обсуждение требований помогает достичь общего понимания.
Написание четких и конкретных спецификаций требований: Документирую требования в форме, понятной всем участникам проекта. Использую язык, который минимизирует двусмысленность.
Определение критериев приемки: Четко указываю, какие результаты должны быть достигнуты для того, чтобы требование считалось выполненным.
Прототипирование: Создание прототипов позволяет визуально проверить понимание требований.
Использование глоссария: Согласовываю определения ключевых терминов, чтобы избежать разночтений.
Применение USE‑кейсов и User Stories: Описывают взаимодействие пользователей с системой и дают четкое представление о функциональности.
Я бы вообще сказала, не нужно переживать что о вас подумают какой же зануда, сколько же времени отнимает, не понимает нашего контекста и так далее Все указанные приемы — это не прихоть, а суровая необходимость. 1) Дает всем ясность которая позволяет проявлять гибкость в решениях, 2) оставляет артефакты по разработке, все понимают как пришли в ту точку, где находятся сейчас.
Выявление и устранение амбивалентности на ранних этапах — залог э��фективного проектирования бизнес‑процессов и достижения поставленных целей.
Давайте разберемся с гибкостью требований и ее отличием от амбивалентности.
Гибкость требований (Requirement Flexibility) — это осознанное и намеренное проектирование процесса сбора и управления требованиями таким образом, чтобы они могли эволюционировать и адаптироваться к изменяющимся обстоятельствам, новым знаниям и обратной связи на протяжении всего жизненного цикла проекта. Да‑да, это SCRUM.
Ключевые аспекты гибкости требований:
Признание изменений: Гибкость подразумевает понимание того, что требования не являются высеченными в камне. Изменения неизбежны, особенно в быстро меняющейся бизнес‑среде.
Итеративность и инкрементность: Процесс разработки разбит на небольшие циклы (итерации), позволяющие часто получать обратную связь и вносить корректировки. Требования детализируются по мере продвижения проекта (инкрементность).
Приоритезация: Требования ранжируются по важности и ценности, что позволяет фокусироваться на наиболее критичных аспектах и отложить или исключить менее важные.
Оценка влияния: Каждое изменение требования оценивается на предмет его влияния на другие части системы, сроки и бюджет.
Коммуникация: Открытая и прозрачная коммуникация между всеми заинтересованными сторонами является ключевым элементом управления гибкими требованиями.
В чем отличие гибкости требований от амбивалентности?
Характеристика
Амбивалентность требований
Гибкость требований
Природа
Неоднозначность, неясность, внутреннее противоречие в самом требовании.
Способность процесса управления требованиями адаптироваться к изменениям.
Причина
Плохое формулирование, недостаток детализации, предположения.
Неизбежная динамика бизнес‑среды, получение новой информации, обратная связь.
Цель
Устранение неопределенности и достижение четкого понимания.
Управление изменениями и адаптация к ним.
Подход
Уточнение, детализация, перефразировка, исключение противоречий.
Приоритезация, оценка влияния, итеративное развитие, изменение плана.
Результат
Четкое и однозначное требование.
Адаптированный к текущим условиям и потребностям набор требований.
Отношение к проблемам
Сама является проблемой, ошибкой.
Является намеренным подходом к решению потенциальных проблем, связанных с изменениями.
Проще говоря:
Амбивалентность — это ошибка. Это дефект в самом требовании, который нужно исправить. Мы стремимся исключить амбивалентность.
Гибкость — это стратегия. Это сознательное принятие того, что требования будут меняться, и подготовка к этим изменениям. Мы стремимся обеспечить гибкость.
Мне нравится думать об этом так: амбивалентные требования — это фрейм проблемы. Я говорю, как мне не нравится, а как нравится — не думаю. Как правило, здесь много негативных эмоций и катастрофизации. Гибкость мышления — это фрейм решения. Я называю, что я собираюсь чинить/создавать. Согласитесь, очень по — разному звучит: «Тут давно нужен ремонт» и «Нужно обновить обои в спальне и гостиной». Хотя по сути, замена обоев в комнате — это тоже ремонт.
Да. изменения неизбежны, и никто не сможет предоставить исчерпывающие требования для больших изменений, однако, когда мы даем контекст, четко обозначаем что мы хотим решить у нас гораздо больше шансов реализовать свои задачи и по пути не выгореть.
Всем успехов в работе и позитивного настроения!
