Давайте возьмем пример классического большого ИТ проекта и разберем, какие роли выполняют сотрудники в ходе работ по проекту.
Ну, наверное, первое, что приходит сразу в голову, так это роль разработчика. В описании ниже мною было выделено 5 типовых ролей. При этом не обязательно, что роль представителя заказчика выполняет именно представитель заказчика. Эта роль может частично выполняться на стороне исполнителя (руководителем проекта со стороны исполнителя). Ну, и совсем спорная роль – руководитель проекта. Думаю, что многие руководители проекта со мной будут готовы поспорить за клевету на данную профессию, но надеюсь на снисхождение, так как я более 10 лет потратил на управление проектами и прекрасно себе отдаю отчет в том, что такое роль руководителя проекта, очищенная от консалтинга, административного управления и продаж.
ИТ Разработчик – он всему голова, и центр любого ИТ проекта. Этот человек отлично знает свою область деятельности, ориентирован четко на результат. Очень трудолюбив и верен своей работе. Лучше всех знает, что должно быть сделано и как, и если бы ему не мешали менеджеры проектов и представители заказчиков, то он мог бы быть еще более продуктивным. Ну, как минимум, он в это свято верит. Проблема в том, он бросается от одного дела к другому, от кризиса к кризису. Он не создает команду, не обучает подчиненных, и некоммуникабелен. Нехватка этих качеств не позволит ему в одиночку вытянуть большой ИТ проект, и поэтому ему нужны помощники.
Представитель заказчика – это человек, который контролирует, доведена ли работа до конца, и реализуются ли решения. Он управляет системой, которая поддерживает в порядке все бизнес-процессы в компании. Как правило, хорошо организован и внимателен к деталям. Очень часто эту роль выполняет ИТ директор. У него много подчиненных, он управляет посредством директив, как правило, в письменной форме. Для него хороший сотрудник тот, кто четко следует правилам и не создает проблем. Как правило, он разбирается в применимых технологиях, стоимости и основных рисков. Он не очень любит перемены, так как перемены угрожают стабильности отстроенной им ИТ системы. Проблема в том, что рядом с ним творческие люди задыхаются, так как для него важнее соблюдение плана и правил, чем целесообразность всего проекта.
Заказчик – человек предпринимательского толка. Легко приспосабливается к изменениям. Умеет чувствовать конъюнктуру рынка. Как правило, фонтанирует идеями. Готов брать на себя риск и достаточно креативен. Проблема у него в том, что он раздает очень много поручений, и не всегда у него хватает времени контролировать их выполнение. Также для такого человека достаточно тяжело и трудоемко дать детальное и глубоко проработанное поручение. У него на это попросту нет времени.
Консультант – может и умеет слушать других и взаимоувязывать их идеи и потребности, он пытается прояснить спорные моменты, определить общие взгляды и подобрать правильные технологии и бизнес-процессы для решения этих проблем. Проблема в том, что у него нет собственных идей, он не стремится достичь ощутимых результатов. Он попросту предлагает варианты решения проблемы и поменяет свое мнение в соответствии с тем, что предлагает большинство.
Руководитель проекта – человек, занимающий управленческую позицию и не исполняющий ни одной из классических менеджерских функций. Функциональные обязанности такого менеджера разработчики в шутку называют «передаст». У заказчика взял задание и передал его разработчикам. Потом в обратном направлении, потом передал результаты тестирования. В западных оргструктурах, бывает, так и называют такую роль «Interface». Проблема в том, что он не созидает, по сути не администрирует. На некоторых своих проектах я полностью соответствовал этой роли, и в шутку называл себя «обезьяной с визиткой». Он озабочен в первую очередь тем, как не нарушить свой маленький мир и как бы не увязнуть в водовороте проблем и конфликтов по очередному проекту.
А насколько нужны все эти роли?
За свою, уже, наверное, достаточно длительную практику я убедился в том, что если что-то существуют в этом мире, это не потому, что это нужно и без этого не обойтись, а потому, что есть возможности. Т.е. первичен не спрос, и не предложение, а возможность себе это позволить.
Получается, что в больших проектах и при больших бюджетах мы можем себе позволить создать организационную структуру и заполнить сотрудниками, которые будут исполнять данные роли.
Доводилось ли вам сталкиваться с сложностями коммуникации бизнеса и ИТ? Приходилось ли слышать на ИТ конференциях мнения о том, что ИТ плохо понимает, что нужно бизнесу, а бизнес плохо понимает, что делает ИТ. Это все в западной бизнес практике называется проблемой коммуникации. И западный же бизнес мир давно придумал такие вещи, как регулярные собрания топ менеджмента, защита стратегий и статус отчеты. Так или иначе, это делается во всех средних и крупных организациях, но мало где это делается достаточно качественно.
Давайте возьмем пример классического большого ИТ проекта и разберем, какие роли выполняют сотрудники в ходе работ по проекту.