Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование.
https://ru.wikipedia.org/wiki/анализ_требований
Большинству уже интуитивно понятно, о чем идет речь, однако я еще не встречал людей, которые бы руководствовались интуицией в вопросах анализа требований и получили что-то годное к использованию.
Зачастую все заканчивается недописанной таблицей, составленной для галочки, живущей в отрыве от реального функционала системы.
На мой взгляд, для того чтобы избежать этой ситуации, надо всего-лишь посмотреть на процесс под другим углом…
Основная проблема сбора требований, на мой взгляд, в формулировках, которые использованы в статьях Википедии и профессиональной литературе.
Requirement is a singular documented physical and functional need that a particular design, product or process must be able to perform.
https://en.wikipedia.org/wiki/RequirementТребования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.
https://ru.wikipedia.org/wiki/Требования_к_программному_обеспечению
Читая данные определения, большинство профессионалов приходит к выводу, что в результате анализа требований должно появится высокоуровневое описание функций (сценариев работы) системы.
Далее они общаются с пользователями и заказчиками, составляют массив запутанной, противоречивой и неконсистентной информации, наполняют сарказмом Интернет и проектируют систему, отталкиваясь от своего субъективного понимания задачи.
Результаты подобного подхода в полной мере проявляются только на этапе приемки или запуска продукта, в форме фразы, которую минимум однажды слышал каждый из нас — “Мы хотели совсем не это, вы плохо выполнили свою работу”.
В случае waterfall процессов риски отчасти закрываются тем, что Заказчик согласовывает проектную документацию и мы можем сказать “Сами виноваты!”, но что это меняет, по сути?
На мой взгляд в определениях требований упущена ключевая деталь:
Требование это не “a need that a particular product must be able to perform”, требование это “an expectation of particular person, that a particular product should be able to perform”.
В новом контексте появляется множество идей по изменению процесса анализа требований, лично я считаю важнейшими следующий три:
Во-первых: Требование — это не функция системы, а описание задачи или проблемы, которую хочет решить конкретный человек.
Попытка вместе с заказчиком проектировать сценарии работы системы с большой вероятностью приведет к некачественному результату. Лучший способ понять требование, сделать все наоборот — Проявить эмпатию, погрузиться в терминологию, задачи и процессы заказчика. Именно после этого появится возможность применить к этому свой опыт и знания, и предложить Заказчику консистентное и эффективное решение.
Во-вторых: Так как требования это желания нескольких людей, то анализ требований начинается с выявления лиц, чьи желания система должна учитывать.
Выявление всех заинтересованных лиц и независимый опрос каждого, это работа, которую чаще всего игнорируют, причем сопротивление оказывают как раз заказчики и спонсоры проекта, из-за непонимания необходимости данной работы.
Безусловно, нужно поддерживать баланс между трудоемкостью и качеством результатов, но причиной большинства провалов стартапов и внедрений корпоративных систем, является именно то, что мнение заказчиков и создателей о том, что надо пользователям не совпало с реальностью.
В-третьих: Требования, это ожидание, то есть то, чего еще нет. Непостоянство будущего обусловлено самой природой, и желания человека постоянно подстраиваются под изменения. Причем речь идет не о неделях и месяцах, требования будут разными в зависимости от того, в какое время дня задать вопросы.
Требования — это ожидания. Ожидания не фиксируют, ожиданиями управляют.
Недостаточно собрать и подписать требования, надо их “продать” всем заинтересованным лицам, таким образом, чтобы они помнили о том — что они хотят, иначе в процессе всего проекта придется бороться с хаотичными изменениями функциональности и внезапными поворотами.
Слово “Продать” — точно характеризует процесс, но несет негативный оттенок. В данном контексте это не подразумевает никакого обмана или манипуляции.
Так как требования дают много лиц, имеющих влияние на систему, обязательно появятся противоречия, и чьи-то интересы будут ущемлены.
Процесс анализа требований нельзя считать успешным, если достигнутый компромисс делает часть из них равнодушными или негативно настроенными по отношению к системе. Если вы не предложите им решения их проблем, они придумают свои собственные и заставят вас их реализовать:)
Спасибо большое за внимание, приведенные выше идеи и примеры не новые, они упоминаются многими в той или иной форме, начиная с таких базовых документов как Agile-манифест и PMBoK, надеюсь, мой вариант интерпретации тоже будет полезен.
PS: Все написанное является моим частным мнением, которое я готов обсуждать в комментариях.
Автор: Александр Мокрышев
