Участие пользователя в разработке требований к системе — одно из самых спорных решений на проекте. На нашей практике мы, с одной стороны, слышим от пользователей в день старта опытной эксплуатации: “Отличная система, классный интерфейс, а когда мы уже будем разрабатывать то, что нужно нам?”, но в то же время в начале проекта функциональный заказчик (пользователи из определенного подразделения) почти наверняка вам скажут: “Вот Вася, Вася Вам сформулирует все требования, Вася в курсе чем мы тут занимаемся”. Почти наверняка этот “Вася” окажется не самым лучшим сотрудником, отсутствие которого в подразделении попросту никто не заметит, поэтому его и назначили представителем пользователей на проект. В результате такого подхода, вероятнее всего, пользователи получат систему, которая практически бесполезна для поддержки их ежедневной деятельности. С другой стороны, если переусердствовать с привлечением конечных пользователей к формированию требований к программному продукту, систематизировать эти требования будет весьма трудно, а многие из них не будут решать стратегические задачи, которые ставит перед системой руководство проекта со стороны заказчика.
Анализ 87 проектов различного класса и масштаба показал, что лишь в 59 случаях можно было однозначно сказать о позитивном влиянии вовлечения конечных пользователей в работу над проектом. Конечно, это почти 70%, но это достаточно маленькая доля, чтобы говорить об однозначном позитивном влиянии такого подхода к формированию требований. Были также выявлены случаи и негативного влияния участия пользователей в проекте, которые были связаны, прежде всего, с описанной выше ситуацией. Один из подходов к подбору представителей конечных пользователей, а также принцип, который нам предлагает одна из методологий проектного управления, мы опишем во второй части нашего рассуждения на тему привлечения пользователей к работе над проектом.
(Оригинал — Bano, M., & Zowghi, D. (2013, April). User involvement in software development and system success: a systematic literature review. In Proceedings of the 17th International Conference on Evaluation and Assessment in Software Engineering (pp. 125-130). ACM.)
Вторую часть статьи можно прочитать здесь
