Диагностика проблем с требованиями
Коротко Когда на проекте начинаются неприятности (недовольные заказчики, поздние сюрпризы, постоянные изменения), идите от симптома назад, к его вероятной причине в процессе работы с требованиями, а затем выберите средство, которое лечит причину. Вигерс раскладывает этот обратный поиск на десять проблемных областей.
По материалам: К. Вигерс, «Разработка требований к программному обеспечению», 2-е изд., прил. C (руководство по поиску и устранению проблем с требованиями).
На этой странице
Главные идеи#
Симптомы — не причины#
Симптом — это то, что вы наблюдаете; корневая причина — то, почему это происходит. Если лечить симптомы по одному (здесь лишнее совещание, там более строгий шаблон), результат редко держится долго. Руководство Вигерса по устранению проблем — приложение ко второму изданию его книги, которого нет в третьем, — сопоставляет частые симптомы с типичными причинами и возможными средствами и группирует их по областям работы с требованиями.
Десять проблемных областей#
Таблица ниже сводит идею к одной строке на область.
| Область | Типичные симптомы | Частые причины | Какие средства рассмотреть |
|---|---|---|---|
| Процесс | На каждом проекте свои шаблоны; инструментами почти не пользуются; аналитики не понимают своей роли | Нет общего процесса, нет интереса руководства, нет обучения | Описать текущий и целевой процесс; обучить людей; принять стандарт; назначить ответственного за внедрение инструмента |
| Продукт | Недовольные заказчики; продукт отвергают с первого взгляда; слабые продажи | Пользователи мало участвуют; нереалистичные ожидания; работа наугад | Фокус-группы; классы пользователей и сторонники продукта; прототипы; согласование ожиданий с бизнес-целями |
| Планирование | Разработка начинается по расплывчатым требованиям; сроки сокращают, не сокращая объём | Дату выпуска фиксируют раньше, чем поняли требования; границы не контролируются | Описать концепцию и границы до того, как брать обязательства по срокам |
| Коммуникация | Работа дублируется; принятые решения пересматриваются; люди используют разные термины | Неясные роли; нет того, кто принимает решения; нет глоссария | Определить роли и того, кто принимает решения; вести глоссарий |
| Выявление | Представители заказчика выбраны неверно или их нет вовсе; решения выдаются за потребности | У заказчиков нет времени; классы пользователей не определены | Определить классы пользователей и сторонников продукта; спрашивать «почему?», чтобы найти потребность за запрошенным решением |
| Анализ | «Позолота» (функции, о которых не просили); непроверяемые требования; у всего «наивысший приоритет»; конфликты | Нет контроля над тем, что утверждается; ценность и стоимость неизвестны; никто не отвечает за решения | Записывать источник и обоснование каждого требования; заранее договориться о процессе приоритизации; назначить ответственного за каждый открытый вопрос |
| Спецификация | Требования передают на словах; документы устарели; есть противоречащие друг другу версии | Убеждение, что записывать — значит замедлять работу; плохое управление версиями | Определить процесс работы с требованиями; проводить изменения через совет по изменениям, который обновляет документы; использовать инструмент управления требованиями |
| Валидация | Продукт не достигает бизнес-целей; есть скрытые требования; нет целевых показателей производительности | Атрибуты качества так и не обсуждались | Объяснить аналитикам и заказчикам, что такое атрибуты качества; выявлять их на ранней стадии с помощью шаблона |
| Управление требованиями | Часть запланированных требований так и не реализуется | Спецификацию не обновляют или не доводят до всех | Поддерживать спецификацию актуальной и доступной; трассировать требования |
| Управление изменениями | Поздние и частые изменения; растут границы; запросы теряются или уходят прямо разработчикам; изменения обходятся дороже, чем ожидалось | Неполное выявление; размытые границы; непрактичный или игнорируемый процесс изменений; нет анализа влияния | Практичный процесс изменений с советом и обязательным анализом влияния; ответственный за каждое требование; резерв в графике |
Как применять#
- Опишите симптом нейтрально, через наблюдаемые факты («восемь из 20 запросов на изменение за прошлый месяц ушли прямо разработчикам»), а не как обвинение.
- Найдите подходящую область в таблице. Подходить может сразу несколько.
- Снова и снова спрашивайте «почему?», пока не дойдёте до причины, с которой можно что-то сделать. Используйте причины из таблицы как гипотезы и подтверждайте их фактами со своего проекта.
- Выберите одно-два средства, которые устраняют причину, а не симптом.
- Решите, как вы поймёте, что средство сработало, и когда это проверите.
- Повторяющиеся причины передавайте в более широкий план совершенствования процесса.
Пример#
В «Мастерской», вымышленной сети веломастерских, управляющие мастерскими жалуются, что новое приложение для бронирования «постоянно меняется», а внешние разработчики говорят, что запросы приходят с трёх сторон. Симптомы — поздние изменения, запросы в обход любого процесса и дважды переделанные экраны. Они указывают на области «Управление изменениями» и «Коммуникация». Вопросы «почему?» показывают: управляющие пишут разработчикам напрямую, потому что никто не сказал им, кто принимает решения по требованиям, а журнала изменений нет. Средства: назначить владельца тем, кто принимает решения; создать совет по изменениям из двух человек (владелец и бизнес-аналитик) с общим журналом; попросить разработчиков направлять туда каждый запрос. Через месяц аналитик считает, сколько запросов всё ещё идёт мимо журнала.
Подводные камни#
- Принимать таблицу за готовый диагноз → она перечисляет вероятные причины; подтвердите их на своём проекте.
- Чинить все области сразу → начните с причины самого болезненного симптома.
- Винить конкретных людей → чаще всего причина в отсутствующих ролях, процессах или навыках.
- Останавливаться на первом «почему?» → первый ответ часто оказывается ещё одним симптомом.
Источники и что почитать#
- K. Wiegers. Software Requirements, 2nd ed. Microsoft Press, 2003. Рус. изд.: К. Вигерс. Разработка требований к программному обеспечению, 2-е изд. М.: Русская редакция, 2004. Прил. C (руководство по поиску и устранению проблем с требованиями).