День 1977. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 13. Две распространённые практики выявления требований — телепатия и ясновидение. Обе не работают

Иногда люди считают требования слишком очевидными, чтобы их озвучивать. Некоторые пользователи боятся говорить бизнес-аналитику то, что, по их мнению, он уже знает. Но я предпочел бы услышать что-то, о чём уже знаю (и укрепиться в убеждении, что я правильно всё понимаю), чем убедить кого-то в том, что я уже владею информацией, когда на самом деле это не так. А некоторые пользователи просто не хотят тратить время на обсуждение требований.

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

Старайтесь выражаться ясно
Важно открыто сообщать об известных ожиданиях и не надеяться, что кто-то догадается, о чём вы думаете. Очень хорошо, когда все заинтересованные стороны проекта имеют единый взгляд на задачу. Чем дольше люди работают вместе и чем больше знают домен, тем легче им достичь такого единения. Но лучше придерживаться философии: «Если требования не описывают конкретную возможность или характеристику, то никто не должен ожидать, что она будет реализована в продукте».

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

Например, требование: «Система должна поддерживать...» Как разработчики компании-подрядчика узнают, какую именно функциональность подразумевает слово «поддерживать»?

Или предлагается предусмотреть возможность отмены некоторых операций. Разработчик реализует её, она работает. Но затем разработчика спрашивают, как выполнить повтор операции? Её не просили реализовывать, но пользователь, привыкший видеть отмену/повтор в других приложениях, подразумевал, что они реализуются в паре. Разработчик добавляет функцию повтора, и она работает. Но потом пользователь удивляется, почему повтор применяется только к последней отменённой операции. И так далее.

Если разработчики и пользователи находятся в тесном контакте, то могут начать с простого требования отмены и договориться, как именно должна вести себя функция отмены/повтора. Тогда не потребуется несколько итераций, чтобы заказчик получил то, что хотел. Но если разработка передаётся на аутсорсинг, то о подобных вещах лучше подумать заранее и включить все особенности в требования. Подрядчик может даже обнаружить эту подразумеваемую функциональность в описании, но будет основываться только на оригинальном требовании, ожидая, что вы предоставите дополнительную информацию, а он сможет запросить больше денег и времени, чтобы реализовать «расширенные» требования.

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

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

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 2.