Мы рассказывали в нашем блоге о важности понимания своих пользователей, об активной работе с ними и поиске обратной связи в рамках статьи про human-centered design. Мы также рассказывали вам о том, что на проектах разработки и внедрения софта вопрос вовлечения пользователя является одним из самых спорных. Сегодня мы решили поделиться с вами историей специалиста из отрасли, который на себе попробовал слишком активную работу с пользователями. Мы взяли интервью у Дениса Суркова, разработчика из “Venezia. Stone Company” об одном из его проектов, в рамках которого быть программистом было далеко не достаточно.
Проект, в котором участвовал Денис, — это проект внедрения информационной системы управления цепочками поставок. Систему требовалось внедрить в кратчайшие сроки, поэтому был выбран подход, при котором команда полностью подготовила новую конфигурацию и инструкции по ней, выложила в общий доступ и инициировала период обучения для пользователей перед тем, как часть их бизнес-процессов будет перенесена в новую систему.
Итак, чем же это закончилось? “Были вывешены инструкции, и в веб-доступе развернута тестовая база для пользователей. Ребята, зайдите, протестируйте, выполните какие-то свои рядовые действия, пару раз хотя бы прогоните, сделанные для вас видеоуроки. Никто ничего не сделал, пользователи просто не хотели готовиться”, — рассказал о результатах обучения специалист. Когда система запустилась, последствия для команды были весьма экстремальные: 50 новых добавившихся в скайп за первый день запуска системы, тонна вопросов, сотни запросов на доработку системы и волна негатива. Ситуация стабилизировалась через некоторое время только потому, что команда проекта обладала не только техническими, но и аналитическими компетенциями, специалисты не были сфокусированы лишь на разработке программного продукта, но обладали хорошими коммуникативными навыками, что оказалось решающим фактором в комбинации с навыками программирования. Разработчики были способны консультировать пользователей по тому, как должны работать их бизнес-процессы в новой информационной системе (о чем, кстати, также написано в инструкциях), какие их бизнес-функции в этих процессах, какие интерфейсы есть со смежными процессами. Все это позволило системе вскоре запуститься в полной мере, однако ряд плановых работ по проекту был существенно сдвинут по срокам.
“Случались такие ситуации, что у пользователей, например, сидит клиент, однако корректные действия в системе проведены быть не могут, из-за чего приходилось бросать текущие задачи и подключаться к этому пользователю”, — пояснил специалист. Планирование в таких условиях действительно практически невозможно, ведь непрерывная работа ключевых бизнес-процессов являлась в данном случае более высокоприоритетной, а пользователи могли в любой момент ее нарушить. С течением времени началась более планомерная разработка программного продукта, так как количество консультаций сократилось, однако этот кейс — отличный пример того, к чему должна быть готова команда проекта, когда пользователям ставится новый программный продукт. Анализируя данный кейс, интересно отметить, что такие подходы к ведению проектов практикуются в условиях повышенной неопределенности и сжатых сроков. Команда буквально “ныряет” в проект и постепенно выстраивает канву для работы в постоянно изменяющейся бизнес среде. Эту идею предложили авторы статьи Agile project management — agilism versus traditional approaches, мы проведем более детальный анализ этого научного труда в наших будущих публикациях и убедимся, что иногда подобный подход является единственно правильным решением.
