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