Люди часто говорят о сборе требований к программному проекту, но это создает неверное впечатление. Слово «сбор» предполагает, что требования уже лежат где-то в готовом виде и только и ждут, чтобы их подобрали. Когда я слышу, как кто-то говорит «сбор требований», в моем воображении всплывает картинка сбора цветов или охоты за пасхальными яйцами. Увы, это не так просто.
Требования редко существуют в сознании пользователей в полностью сформированном виде, готовом для передачи бизнес-аналитику или команде разработки, только спроси. Создание набора требований определенно подразумевает этап сбора некой информации, но также включает открытие и изобретение (курсив мой. Смотрите, даже Вигерс пишет, что мы изобретаем требования!). Термин «выявление требований» (requirements elicitation) точнее описывает, как люди из ИТ сотрудничают с заинтересованными сторонами, чтобы изучить, как те работают сейчас, и определить, какие возможности должна предоставлять будущая программная система.
Согласно словарю The American Heritage Dictionary of the English Language (2020), под словом elicitation подразумевается выманивание, вытягивание или провоцирование. Слова «выманивание» и «вытягивание» точнее описывают процесс, чем слова выявление или сбор.
Самые бесполезные вопросы, которые не следует задавать при изучении требований: «Чего вы хотите?» и «Каковы ваши требования?». Такие расплывчатые вопросы вызывают поток множества случайных — но важных, конечно — сведений, смешанных с посторонней информацией и приправленных невысказанными предположениями. Бизнес-аналитик не просто записывает все, что ему говорят заинтересованные стороны. Опытный БА фасилитирует обсуждение, направляя участников на раскрытие имеющего отношение к проблеме знания в структурированном виде.
Далее он пишет, что с первого раза всё узнать не получится, что нужно вернуться к стейкхолдерам, преодолеть их "Ну мы же это уже обсуждали!", но без этого никак. Выявление требований, — пишет Вигерс, — это как очистка луковицы, только наоборот: чем больше слоев счищаешь, тем больше она становится.
Это из последней книги Вигерса: Software Development Pearls: Lessons from Fifty Years of Software Experience ("Жемчужины разработки: Чему мы научились за 50 лет создания ПО")
Книга, кажется, небезынтересная, придётся читать. Приведенная цитата — это Урок 11, а дальше он пишет, что
Две основные практики выявления требований — телепатия и ясновидение. Они не работают. (Урок 13)
Большая группа людей не способна организованно покинуть горящую комнату, не говоря уж о том, чтобы коллективно сформулировать какое-то требование (Урок 14)
И что идеальный вариант — когда разработчик один, пользователь один, они сидят за соседними столами, и пользователю можно сразу показать готовый результат. Тогда и требования не нужны. И к этой идеальной картине нужно стремиться — что я готов подтвердить, это и правда самый лучший способ!
В общем, любопытно. Напишу больше, как дочитаю 📕