{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

Топ 5 ошибок менеджеров IT проектов и способы их избежать

За последние около 10-ти лет работы в управлении командой менеджеров проектов я выделил для себя самые частые ошибки, которые приводят, если не к полному краху проектов, то как минимум к значительному снижению прибыли по ним. Хочу поделиться с вами этим опытом, чтобы спасти сотню другую проектов, которым суждено было провалиться)

Ошибка 1: “Все будет хорошо”

“Думаю, успеем выполнить без закладывания буфера в срок выполнения проекта”, - часто слышу я от менеджеров: “что может пойти не так?”. Менеджеру проекта важно иметь здоровый скептицизм (а иногда неплохо иметь и нездоровый), чтобы предусматривать заранее проблемные моменты и страховать сроки проекта. Так например, вы должны ожидать, что клиент будет тянуть с заверением дизайна, вовремя не предоставит нужную информацию, программист ко времени выдачи задачи в работу может быть занят другим проектом, может неверно осметить время и затянуть выполнение, ответственный может заболеть или уволиться и т.д. и т.п.

Закон Мерфи гласит, что “если что-нибудь может пойти не так, оно пойдёт не так”. Задача менеджера предвидеть и нейтрализовать. Как минимум, иметь план “Б” на каждый такой случай. А если вас сжатые сроки проекта, которые “нельзя нарушать”, то вы на это время должны превратиться в параноика.

Ошибка 2: “У меня хорошие отношения с клиентом”

Надеяться на то, что можно пренебрегать предварительными заверениями, подписанием документов и согласованием новых сроков под роспись клиента, потому что вы с ним “вась-вась” не стоит. А если это ответственный от имени фирмы, тем более. Сегодня он один, а завтра уволился и пришел гораздо менее настроенный к вам положительно персонаж. Он пройдется по всем вашим недоделкам и заставит работать по ночам или платить неустойки.

Но даже если это владелец продукта и он вряд ли сменится, при сдаче он может быть совсем не таким добрым и покладистым, т.к. за свои деньги он планирует получить продукт, без которого он не заработает и тут уж как говорится “ничего личного”. Надо подстраховывать себя документом или как минимум подтверждением на почте при каждом дополнении в техническое задание и изменении сроков даже по запросу клиента. Иначе, потом “не отмахаетесь”.

Ошибка 3: “Клиент без вопросов заверил проектную документацию”

Повод насторожиться. Если вы отправили клиенту проектную документацию - он без вопросов ее заверил, значит, ждите проблем при сдаче. Скорее всего, это означает, что он, либо ее не понял и не задал вопросов, потому что постеснялся признать это, либо даже не читал и “доверяет экспертам”. Но проблема в том, что он этой экспертностью при сдаче вам и будет тыкать в лицо, когда увидит не тот продукт, который находится “у него в голове”.

Если клиент непосредственно не участвует в составлении проектной документации (что уже плохо), то ему, как минимум, надо сделать детальную ее презентацию. Проговорить основной функционал, остановившись отдельно на потенциально спорных моментах и четко проговорить ожидания. Отправлять на почту объемные документы без того, чтобы их детально проговорить вообще не советую.

Ошибка 4: “Сделал так, как клиент попросил”

Обычно, так отвечает менеджер проекта, когда ему предъявляют претензии по откровенно идиотским решениям в проекте. И аргумент это очень плохой, никогда им не пользуйтесь, т.к. вы таким образом расписываетесь в собственной некомпетентности. Лучше сразу скажите, что облажались.

Если необходимо было бы передать мысли клиента без обработки, то он мог бы воспользоваться диктофоном. Роль менеджера проекта пропустить задачи клиента через личный опыт и предложить оптимальное решение.

Ошибка 5: “ - А в чем была проблема? - Сейчас уточню у программиста”

В том, что вы советуетесь со специалистом перед тем как сообщить что-то клиенту нет ничего зазорного. Это гораздо лучше, чем уверенно сморозить ерунду.

Другой вопрос, если речь идет об исправлении ошибки и вы сообщаете Заказчику о ее исправлении не разобравшись детально в причинах. А ведь на исправлении бага не заканчивается работа менеджера проекта. Опытный менеджер проекта всегда сообщает Заказчику исправление ошибки по его проекту с анализом причин и решениями, как не допустить таких ошибок в будущем. Если задача горящая, будет целесообразно сообщить, что ее решили, а сейчас занимаетесь анализом причин и в ближайшее время дадите список мер по недопущению таких ситуаций в будущем.

Используйте в своей работе эти 5 простых советов и клиенты будут довольны и лояльны!

Материал статьи взят с курса на Udemy для менеджеров проектов (с)

0
4 комментария
Иоанн Грозный

И опять исполнитель виноват в том, что заказчик не хочет ни во что вникать и подписывает бумаги не глядя. Может хватит уже инфантилизировать заказчиков и давать им карт-бланш на любые нарушения договоренностей?
Заказчик - такой же равный участник сделки, как и исполнитель, и ответственность за свои косяки должен нести сам. 

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
ovchinikoff a

Клиент — это не проджект менеджер, и его взгляды даже на простые распространенные вещи могут разительно отличаться и тут соглашусь что ПМ ему в помощь.
Но иногда даже достижения науки ничего не могли поделать против "бараньего рога" ... )))

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
ndrozdova1

Ошибка 3: “Клиент без вопросов заверил проектную документацию”

Был в моей практике такой клиент - владелец крупной компании. Из-за нехватки времени никогда не выслушивал до конца, даже дизайн никогда до конца не просматривал. 

Готовишься к встрече, приходишь, начинаешь показывать и объяснять, а в ответ: "Мне некогда тебя слушать, иди делай!" 

Каждый раз приходилось проговаривать с ним и подписывать, что любые претензии и новые "хотелки" будут рассматриваться в качестве доработок к ТЗ. 

Ответить
Развернуть ветку
Azamat Akishev

В данном случае, владелец крупной компании должен был определить/закрепить ответственного со стороны заказчика. 

Ответить
Развернуть ветку
1 комментарий
Раскрывать всегда