Как не налажать в коммуникации в большом проекте

В который раз вижу одну и ту же ошибку в относительно крупных проектах, затрагивающих большое количество конечных пользователей – отсутствие этапной коммуникации о намерении сделать проект, о ходе проекта и о предстоящих изменениях.

Ну, знаете, когда ты говоришь заказчику, может, давайте рассказывать людям, что происходит и готовить их как-то? А заказчик делает таинственное лицо и говорит, нет, мол, рано еще, вау-эффекта не будет. Хочу сначала получить весь функционал и потрясающее юзабилити, чтобы все просто в обморок упали от восторга и от того, какие результаты я могу давать компании! Чаще всего руководитель проекта с заказчиком соглашается (особенно если руководитель проекта неопытный), а зря.

В итоге мы в 100% случаев получаем офигевших (и это мягко говоря) пользователей, но совсем не от восторга, как планировал заказчик. Потому что любое изменение – это, блин, больно! И какой бы чудесной не была ваша новая система управления обучением или хранения проектных документов – никто не будет рад узнать, что завтра будет работать в новой системе! Такие вещи надо рассказывать очень и очень заранее, готовить людей.

Почему я об этом вдруг вспомнила? Да вот прямо вчерашний кейс, с полей – в рамках большой программы проектов планируется замена очень-очень-очень старого авиационного ПО 90х годов (90х, не вру!) на новое. С моей точки зрения как ИТ-специалиста – этим старым ПО можно пользоваться только для изощренных пыток или вместо депремирования, настолько оно нефункциональное, медленное, неудобное, с огромных количеством лишних телодвижений.  Прихожу на объект пообщаться с будущими пользователями, расспрашиваю, как им работается сейчас, радостно говорю, вот, мол, как хорошо, через год вместо этого у вас будет новое современное ПО. Пользователь (чуть старше меня) потрясенно на меня смотрит и очень искренне спрашивает: «Что, ЕЩЕ СОВРЕМЕННЕЕ, чем это?! Жалко, мне так нравится, ничего на бумаге вести не надо, представляете, все в компьютере!». Вот он обрадуется внезапной замене, правда?

Вроде бы прямо совсем основы управления изменениями, но почему-то именно в таких случаях разум отказывает даже у заказчика и спонсора. Не надо так.

P.S. Про риски такого подхода с минимальным вовлечением конечных пользователей для проекта в целом я вообще не говорю, цензурные слова тут неприменимы.