Психология управления проектом. Глава 1. Встречают по одёжке

05.07.18

Управление проектом

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

Много материалов написано о практиках, методиках и инструментах по управлению проектами. В основном это очень полезный материал, который как минимум стоит почитать хотя бы для общего представления, а как максимум - использовать в своей работе. Практически во всех попадавшихся мне материалах управление проектами описывается крайне технократично, как теоретический процесс взаимодействия между абстрактным заказчиком и виртуальным исполнителем, роль которого должны играть вы - потенциальный руководитель проекта (РП). Заказчик во всех этих материалах представляется в двух крайностях: первая, которая используется в подавляющем количестве примеров, - он всегда и во всём с вами согласен, и вторая, используется преимущественно в материалах по управлению рисками, - он вам во всём противостоит. В жизни же, как правило, всё обстоит гораздо сложнее, чем описано в этих учебниках, ведь вы имеете дело не с роботами, а с живыми людьми, которым что-то может понравится, а что-то нет. Представитель заказчика, который ещё вчера ловил каждое ваше слово и кивал при каждой вашей фразе, сегодня вдруг может стать чуть ли не злейшим противником всех ваших идей. А если в ваших планах он играет одну из ключевых ролей, то весь ваш проект одномоментно попадает под угрозу срыва.

Вероятнее всего подходы, которые я планирую раскрывать в данной серии статей, опытным РП вполне знакомы, и многие бывалые активно применяют их на практике. Но чаще я вижу картину обратную, когда даже признанные гуру проектного управления полностью игнорируют тот факт, что они работают с конкретными людьми, а каждый человек по своему индивидуален, и каких-то универсальных методов воздействия, которые бы одинаково влияли на разных людей, в природе, к сожалению, не существует. К каждому участнику проекта приходится искать свой уникальный подход. Моё личное мнение: хороший РП обязательно должен быть хорошим психологом. Человек, который не умеет "читать" людей маловероятно станет успешным РП. Собственные наблюдения и приёмы в этом направлении я для себя называю обобщённо "психологией управления проектами" и некоторыми из них хотел бы поделиться с коллегами по цеху.

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

Итак, самый первый совет, который бы я хотел дать всем РП, как начинающим, так и умудрённым опытом: всегда разговаривайте со своим заказчиком на том языке, который он готов воспринимать. Прежде чем идти на первую встречу с заказчиком, постарайтесь узнать кто будет присутствовать на совещании, выделить потенциальных ЛПР (лиц, принимающих решения) и выяснить хотя бы минимальную информацию о них: возраст, должность, срок работы в этой должности и на предприятии в целом, какую должность/должности занимал ранее, образование (высшее или среднее специальное, техническое или гуманитарное, специальность соответствует профилю работы или нет), увлечения/хобби и т.п. Не поленитесь залезть в интернет, социальные сети и попробовать найти необходимую информацию там. После этого выработайте стратегию общения с каждым возможным ЛПР-ом. Всегда помните, образ мышления человека формирует та среда, в которой он либо вырос, либо находился последние 2-3 года. Даже если должность человека называется "директор по развитию перспективных направлений бизнеса", а сам он всего лишь полгода назад был выдернут из производственной среды, не ждите от него благоговейного восторга, когда будете в беседе с ним жонглировать терминами типа "ABC-анализ", "модели as-is и to-be" или "ТОС-система". С высокой степенью вероятности вы заработаете себе титул "яйцеголового", с которым "нам не по пути". А может быть и совершенно обратная ситуация, когда вам попадётся выпускник МГУ, со степенью MBA, готовый презирать каждого, кто говорит "поиск неэффективных мест" вместо "GAP-анализ" или не понимает, что такое "схема в нотации BPMN". В этом случае, если вы выберете неправильную линию поведения при общении, за вами закрепится статус "рядового провинциала", с которым "вообще не о чем разговаривать". Если у вас не получилось предварительно исследовать участников совещания, начните с нейтральной темы, например, с описания компетенций вашей фирмы, и постепенно вкрапляйте в разговор "пробные" термины и внимательно следите за реакцией основных участников совещания. По возможности старайтесь перед совещанием оговорить со своими коллегами распределение, кто за кем смотрит, с обязательным перекрытием (т.е. чтобы за особо важными ЛПР "приглядывали" как минимум двое человек), дабы впоследствие сверить и подтвердить свои наблюдения, а также скорректировать тренд будущего общения.

Второй совет. 

Не совершайте базовой ошибки начинающих РП - совершенно необязательно степень влияния ЛПР-а на успешность завершения проекта прямо пропорциональна его должности. Как показывает моя практика, директор предприятия, вообще крайне редко бывает именно тем человеком, вокруг которого стоит сосредоточить свой основной "боевой арсенал". Конечно же, это утверждение абсолютно не означает, что его нужно игнорировать в беседе, совсем наоборот: следите за ним крайне внимательно, и ловите, на кого из присутствующих будет падать его взгляд, когда вы будете затрагивать важные темы о целях и методах реализации вашего проекта. С высокой долей вероятности именно от этого человека (или нескольких) в последствии и будет зависеть успешность приёмки ваших работ по проекту. Ваша первоочередная задача с первых минут проекта - вычислить таких людей и понять, кто будет "тащить" проект со стороны заказчика. Назовём такого сотрудника "драйвером" проекта. Директор же (или его заместитель, или функциональный директор), как правило, остается "спонсором" проекта, т.е. человеком, который а) в самом начале должен определить высокоуровневую цель проекта и б) при отмашке "драйвера" дать распоряжение на согласование и подписание акта приёмки работ по проекту в целом, либо по этапам проекта. Априори ошибочное мнение, что доказывать успешность достижения промежуточных целей нужно "спонсору", в 99% случаев промежуточные результаты его мало интересуют и в этом он полностью доверяет мнению "драйвера".

"Драйвер" и назначенный заказчиком руководитель проекта далеко не всегда являются одним человеком. У руководства свои соображения, и его мнение по РП совершенно не обязано совпадать с вашим. Ничего страшного в этом нет, но в таком случае нужно попытаться убедить РП в крайней полезности "драйвера" для проекта.

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

Третий совет.

При обследовании бизнес-процессов автоматизируемого предприятия, а также при формировании модели процессов "to-be" (впрочем иногда это применимо даже при построении модели "as-is"), никогда не ориентируйтесь на мнение одного человека. Всегда сопоставляйте то, что вам говорит подчинённый сотрудник, с мнением его руководителя, а в идеале ещё и подтвердить полученную информацию у коллег интервьюируемого сотрудника. Обычное явление, когда версии начальника и подчиненного совершенно не совпадают. "Полевой" работник прекрасно понимает, что вся работа по вводу данных в конечном итоге свалится именно на него и, соответственно, будет стараться максимально упростить жизнь себе. Часто это происходит в ущерб общей функциональности системы. Его начальник же обычно впадает в другую крайность: напихать систему по-максимуму данными, даже если они никогда в будущем не понадобятся. Такой подход приводит к существенной деградации скорости ввода данных, т.к. в этом случае практически не учитываются трудозатраты и ресурсы, задействованные при внесении данных. Золотую середину в этом случае придётся искать и предлагать либо вам самим, либо привлекать в качестве рефери третье "независимое" (с точки зрения данного процесса) лицо из ЛПР'ов проекта.

Для первого раза, думаю, будет вполне достаточно. Надеюсь данный материал будет полезен в нелёгкой работе РП, как начинающим, так и не очень.

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

И успешных проектов вам!

психология управление проект рп технологии совет прием практика руководитель теория

См. также.

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    2824    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    3855    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3232    0    user1853337    8    

29

Кейсы проектов Руководитель проекта Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    3211    0    1СERP    21    

31

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14921    0    ASchekachev    37    

55

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6107    0    stnslv    5    

25

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    5112    0    andironenko    2    

32

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5684    0    MariaTemchina    28    

22
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. serg_ps 05.07.18 11:35 Сейчас в теме
2. mbreaker 1416 05.07.18 11:40 Сейчас в теме
3. Manoshkin 357 06.07.18 04:49 Сейчас в теме
4. gaj-ka 7 11.07.18 20:07 Сейчас в теме
Оставьте свое сообщение