Как и обещано на других ресурсах разберем инфоцыганскую статью, которая вышла, к моему удивлению, на РБК и я очень надеюсь что она платная.
Учитывая ограничения формата я буду копировать сюда цитаты из статьи и комментировать. Разбор будет состоять из двух частей, первая - пройдемся по тексту и разберем основные тезисы, а потом выскажу мое мнение по поводу общего тона статьи.
Итак, с нами играет Денис Мочалов, директор продукта ELMA365 Проекта. Я не знаю кто это, что это и специально не гуглил дабы максимально обсуждать статью, а не автора или его работу.
Статья позиционируется как описывающая методы избегания конфликта интересов и в целом, направлена на облегчение коммуникации внутри проекта. Наверное. Но, есть нюансы, давайте разбираться.
Приведу пример из практики. На проекте импортозамещения системы документооборота в госкорпорации мы столкнулись со следующей ситуацией. При сдаче работ появились критические замечания со стороны рабочей группы заказчика: рядовые сотрудники сопротивлялись переходу на новую систему. Проблема в итоге масштабировалась настолько, что под угрозой оказалось финансирование дальнейших контуров автоматизации. Нам пришлось дополнительно обучать сотрудников, но это привело к дополнительным финансовым затратам и переносу сроков сдачи проекта. Этой ситуации можно было избежать с помощью правильно выстроенного управления заинтересованными сторонами.
О чем нам говорит эта ситуация? О том, что проект фактически был провален. Как РП и внедренец с достаточно большим списком завершенных проектов я вижу здесь два очень больших провала:
- судя по всему рядовые сотрудники вообще не были в курсе изменений ИЛИ их мнение в принципе не учитывалось в процессе реализации проекта. Это нам говорит о серьезном провале на этапе определения проекта и том, что проектная команда была составлена неверно.
- если вы столкнулись с необходимостью дообучать сотрудников на этапе внедрения проекта и что еще важнее, вам пришлось привлекать дополнительные ресурсы к обучения - подготовка в внедрению также провалена.
Те, кто меня знает и со мной общается, скорее всего помнят как меня бомбило весь последний проект на тему вовлеченности местной команды и рядовых сотрудников в реализацию проекта и сколько яда я на них вылил. Но мы были готовы к проблемас, учли их в плане проекта, составили план действий и эти действия были корректно задокументированы, обсуждены и согласованы, а следовательно никаких «угроз финансированию» даже близко не наблюдалось. Соответственно, в нашем случае проблемы с операционной командой не привели ни к срыву проекта, ни к дополнительным серьезным расходам, более того, клиент даже не заметил, что у нас были какие-то явные сложности.
Цитата: При командной работе в крупном проекте важно выявить роли его участников и определить зоны ответственности. Лицо, которое так или иначе связано с проектом, называют стейкхолдером или заинтересованной стороной (или по ГОСТ 51897-2002 — «причастной стороной»).
0 вопросов, все верно, ссылка на ГОСТ доставляет отдельно. Этот тезис запомним, он важен для дальнейшего разбора. Далее автор разбирает разницу между классической и матричной структурами организации. Разница между ними как-то невнятна, но мы сейчас не об этом. В обеих структурах нижний уровень пирамиды у него указан как «исполнители» для классической модели или «руководители бизнес подразделений». Отсюда мы делаем вывод, что автор вообще не воспринимает линейный персонал как что-то достойное внимания.
Потом начинается дичь. Цитата из описания ролей в проекте: - рядовые пользователи дают обратную связь, по большей части негативную, но не имеют рычагов влияния на проект;
Автор в начале статьи пишет, что проект был под угрозой остановки финансирования из-за сопротивления рядовых сотрудников, а сейчас пишет, что они не имеют влияния на проект. Они чуть было не угробили твой проект, ты уверен что у них нет рычагов влияния?
Цитата: Коммуникации между стейкхолдерами — это всегда омниканальность: CRM, почта, мессенджеры, а также личные встречи и мероприятия. Свести все в один канал, как бы этого ни хотелось, никак не получится. Поэтому руководитель проекта берет на себя несколько ролей: и психолога, и организатора, и управленца, а иногда отчасти даже родительской фигуры.
Тут не очень понятен переход между омниканальностью и ролями РП, но суть не в этом. Сейчас бомбить буду уже я. Коллеги, вы там вообще без меня совсем с ума посходили? Какой из РП психолог, управленец и родительская фигура? Это именно то поведение, которое загубит весь проект. Два основных человека в проекте, РП и руководитель внедрения (РВ) - это люди, которые не могу себе позволить быть хоть немного человечными, потому что именно их волей проект двигается. Если я, как РП, начну проявлять эмоции по отношении к любой функции - это моментально бьет по всем остальным функциям. Если РВ начнет проявлять человечность к подчиненному ему запускающему тренеру, то моментально к нему возникнут вопросы от качества, локальной команды и прочих. Типа почему он, а не мы? Не делайте так, коллеги, это непозволительная роскошь в именно проектной деятельности, в отличие от нормальной. В проекте вы не руководите людьми. Вы руководите функциями и именно слаженность работы функций, а не людей реализует проекты. Проект не может зависеть от Никиты Иванова, потому что он может быть разгильдяем, проект должен зависеть от ИТ разработчиков и относиться к Никите вы должны как в функции, а не как к человеку. И именно поэтому в прошлой статье я говорил о правовом поле проектной деятельности. В компании могут быть разной степени расхлябанности сотрудники, но компания потому и компания, что она может из стада сделать функцию. И РП и вообще проектная деятельность связана с функциональными единицами, а не с конкретными индивидами.
Причем автор это явно понимает, но, возможно пытается сыграть на поле ассертивности, вовлеченности и вообще все РП такие проработанные лапки…
Цитата: Руководитель проекта взаимодействует со всеми стейкхолдерами: определяет локомотивные функции, управляет их влиянием, чтобы усилить позитивные возможности ролей и минимизировать негативные. Таким образом, руководитель играет ключевую роль в успехе проекта.
0 вопросов, хрен поспоришь.
Не все люди, способные влиять на ход проекта, в нем заинтересованы. Например, для HR не так важно, в какие сроки будет разработано и внедрено новое ПО. Руководитель проекта должен знать интересы всех участников. Для того чтобы систематизировать данные, он может использовать матрицу RACI.
Начинается моё любимое. Да, автор знает что есть что-то называемое на RACI, но не знает что уже много лет в подобных проектах используется расширенная модель RASIC или RASCI. Основная разница в том, что RACI — классическая матрица распределения ответственности (Responsible, Accountable, Consulted, Informed), а RACIS (RASCI/RASIC) это ее расширенный вариант с добавлением роли S (Support/Supportive), чтобы в явном виде включить роль поддержки. И весь прикол в том, что именно неверный выбор матрицы и привел товарища в то место, где он в итоге оказался, так как рядовой, линейный персонал и включается в такие проекты как Support, потому что именно они могут сказать как лучше сделать, как организовать обучение и переход на новые системы.
Кстати, мой последний разбор на сайте - как раз про нее, про RACIS.
Подведем итог. Когда-то давно я писал в одной из моих заметок про ИТ о том, что если вы проходите какую-то новую технологию в институте, то ей уже года 3-5, а если ваш учебник 2-го издания, то этой хренью уже давно никто не пользуется. Сейчас тоже самое происходит в российском операционном управлении и управлении проектами. Всякие странные люди пишут всякие странные статьи, лишенные внутренней логики, всякие автозаводы внедряют что-то лишь бы было и все это происходит на фоне общего отношения к линейному персоналу через губу, типа вы, смерды, будете делать то, что я тут вам придумал, ведь я прочитал книжку ДАО Тойоты, у меня в подписи написано Руководитель проектов и я точно знаю как лучше. И это, как по мне, очень грустно, потому что мы теряем очень большой пласт компетенций и идей, которые вполне могли быть дать хорошего пинка российской системе управления. А я считаю, что ей это прям необходимо.
Если хотите подискутировать на тему, то добро пожаловать в @scrllock.
Всякие прочие мысли тут: @myhorop
