Продолжаем рассуждать на тему привлечения конечных пользователей к работе над требованиями к программному продукту. В прошлой части статьи мы взяли крупное исследование, которое показало, что лишь в 70% (точнее 67%) случаев этот подход признан позитивно влияющим на результаты проекта. Сегодня мы расскажем еще один интересный момент про User-involvement.
Мы решили обратиться к самым новейшим исследованиям, которые появились только в начале 2017 года, и детально их проанализировать. Общепринятым утверждением сегодня является то, что успех программного продукта в большей степени прячется на фазе Выявления требований к системе, и, чем более точно аналитик и разработчики их поймут, чем точнее сформулирует их заказчик, тем успешнее будет система. Конечно, важным моментом является и то, как этими требованиями управлять, ведь даже очень точно выявить их в начале, но затем “заморозить” — это очень плохая затея и является одним из ключевых факторов провалов проектов (по отчету Chaos report от Gartner).
Мир меняется быстро, среда, в которой обитает компания, меняется тоже быстро, если не быстрее, потребности пользователей/клиентов могут изменить направление в течение периода времени. Вопрос управления изменениями — очень сложный и комплексный, о нем мы обязательно еще упомянем, но сегодня мы разбираемся, хорошо ли все-таки или плохо привлекать пользователя к работе над требованиям и когда стоит это делать.
Одна из сложностей, о которой говорят последние исследования, при анализе провалов IT проектов — это “Difficulty of indirect communication with the ordering sides”, а если по-простому — принцип “испорченного телефона”. Представьте, команда Заказчика выбирает представителей пользователей, а еще назначают руководителя проекта со своей стороны, который зачастую является ответственным лицом за конечный продукт (в некоторых методологиях — Владелец продукта). Что происходит дальше? Пользователи формулируют свои потребности, передают их своему представителю, а тот их передает менеджеру проекта со стороны заказчика, а далее они уже передаются команде разработки. Страшно подумать, сколько недопониманий и неточностей может быть в этом процессе, даже с учетом формирования больших объемов документации (будем честными, документы мало кто читает). Работа напрямую с пользователями — простое и эффективное решение для устранения такой проблемы. В этом случае команда разработки напрямую берет на себя ответственность за точное понимание бизнес-потребностей пользователей и находится в постоянном контакте с ними для более точного выполнения их требований. Самые последние исследования показали, что среди 20 наиболее популярных критических факторов IT проекта, привлечение пользователей оказывает самое большое влияние на его результаты.
В заключение хотим добавить, что, как известно, IT проекты — вещь весьма неоднозначная, а все факторы, которые влияют на принятие управленческих решений в их реализации, вероятно, не скоро будут найдены. Решение по какому-либо управленческому аспекту можно принимать лишь опираясь на собственный научный и практический опыт, надеясь, что ты попал в точку.
(Оригинал — Komai, S., Saidi, H., & Nakanishi, H. (2017). Study on Critical Success Factors Estimation in IT System Development. Sains Humanika, 9(1-3).)
Первую часть статьи можно прочитать здесь
