Управление ожиданиями в ИТ проектах.
автор ТАЛАНОВ Виктор Александрович

Попробую без лишних умных терминов изложить свои соображения исходя из личного опыта. Ниже изложены приёмы которые я применяю во время реализации проекта, а так же те моменты, которые я стараюсь не упустить из виду.

Введение.
Как же так получается, что ваша проектная команда сделала всё согласно техническому заданию (ТЗ), а заказчик недоволен результатом (например, информационной системой), и пользователи выплёскивают на вас массу негатива. Что произошло? Вроде сделали то, что просили.
Предлагаю сразу определиться, что для меня значит управление ожиданиями. Это процесс в рамках проекта, которые приводит к моральному удовлетворению заказчика и пользователей. Другими словами, критерием вашего правильного управления ожиданиями является тот факт, что по окончанию проекта заказчик, глядя на систему, говорит: «Круто! Вот это то, что нужно! Даже лучше, чем я ОЖИДАЛ!».

Языковой барьер между заказчиком и исполнителем.
Это отдельная тема, о которой я уже писал . Тем не менее, кратко затрону этот вопрос, ибо непонимание на лингвистическом уровне может сильно влиять на процесс управления ожиданиями.
Всегда контролируйте правильность понимания сторон. При любом общении должна быть 100% уверенность, что стороны понимают друг друга. При малейшем сомнении, требуется прояснить ситуацию. Старайтесь свести до минимума общение людей, которые заведомо не поймут друг друга, например пользователя и программиста. Используйте больше наглядного материала при общении. Диаграммы, схемы, картинки минимизируют вероятность непонимания.

Как заказчик видит автоматизацию?
Попытайтесь встать на место заказчика. Встали? Если вы правильно «встали», то должны увидеть на экране компьютера «большую зелёную кнопку» с надписью «сделать всю работу %пользователя%». Как правило, даже подписанное ТЗ не развеевает такого радужного представления о системе. Поэтому с заказчиком и с будущими пользователями нужно регулярно проводить «душеспасительные» беседы. Нужно ласково и нежно объяснить заказчику и ключевым пользователям несколько следующих моментов:

Втолковать вышеизложенные вещи не так просто. Обычно этот процесс растягивается на весь проект разработки и внедрения. В любом случае, к началу эксплуатации системы, вам нужно развеять миф о «зелёной кнопке». Развеянный миф о «зелёной кнопке» может поднять вопрос у заказчика и пользователей «А зачем нам нужна автоматизация?». Чтобы ответить на этот вопрос потребуется талант пропагандиста светлого будущего. Об этом читайте чуть ниже.

Делай, как завещал великий Ленин. О важности "психологической обработки" заказчика.
Действительно, остаётся только завидовать великому вождю и его последователям, как они умудрялись поддерживать удовлетворённость жизнью основной массы народа. При этом народ жил только надеждой на светлое будущее. Правильная и неустанная пропаганда – вот залог успеха. Возьмите эту тактику себе на вооружение, и вы сможете манипулировать настроением и удовлетворённостью заказчика. Ведь главное, чтобы заказчик и пользователи сказали вам спасибо за сделанную систему. При таком раскладе никто не посмотрит в ТЗ и не будет искать расхождения между ТЗ и результатом вашей работы.
Для того чтобы грамотно построить пропагандистскую работу, нужно вникнуть в суть бизнеса, понять «надежды и чаяния народа».

Пойми заказчика.
Корень неоправданных ожиданий заказчика кроется в подходе к формированию границ проекта (в терминологии PMBOK «содержание проекта»). Обычный подход: «делаем то, что просит заказчик». Я считаю, что такой подход - это вектор в неправильном направлении. Я стараюсь использовать подход: «делаем то, что НУЖНО заказчику». Кто уловил разницу между «хочет» и «нужно», тот сможет управлять ожиданиями, кто не уловил, тот имеет большой риск не справиться с этой задачей.
Понять то, что нужно заказчику не так просто. Нужно вникнуть в предметную область, нужно много общаться с сотрудниками заказчика, нужно понять, что они «производят» и что они получают в виде «сырья». Фактически нужно изучить не только бизнес процесс, который вы автоматизируете, но и все смежные процессы. Т.е. нужно более широко взглянуть на жизнь :-).
При изучении процессов заказчика требуется обнаружить действительно узкие места в бизнес процессах. Именно их нужно автоматизировать.

Вывод: Чем больше вы общаетесь с заказчиком, тем выше вероятность держать под контролем ожидания, а стало быть, управлять ими. На самом деле ожидания - это в большей степени разрез человеческой психологии, а не точно выполненного ТЗ.

PS: Читая текст можно сделать ложный вывод, что я призываю не следовать ТЗ. Это не так. Я считаю, что ТЗ - это серьёзный документ, которому нужно следовать на 100%. В своих проектах я всегда чётко следую формальным документам и формальную сторону проекта никогда не выпускаю из виду. Так же использование лучших практик PMI или IPMA для меня является неотъемлемой частью управления каждым конкретным проектом.

 

На  первую страницу.