В работе над ИТ-проектом результат может зависеть даже не столько от хард скиллов, сколько от грамотного управления командой и взаимоотношений внутри нее. Эксперт «КОРУС Консалтинг» делится опытом и советами, как РП и ФА избежать конфликтов и научиться эффективно взаимодействовать на проекте.
Что делать, если руководитель проектов и функциональный архитектор используют разные подходы в работе над проектом? Как избежать конфликтов и научиться эффективно взаимодействовать? Максим Потапов, эксперт по внедрению и руководитель проектов департамента CRM ГК «КОРУС Консалтинг», на реальных кейсах расскажет, что делать в таких ситуациях.
Хороший РП = хороший проект?
Последние годы я активно участвую в пресейловых активностях департамента, помогаю клиентам правильно выстроить подход к внедрению CRM, сформировать дорожную карту, выбрать соответствующие инструменты для реализации своих задач. Часто бывает, что в самом конце пресейла, когда все решения приняты и согласованы, подходит ИТ-директор и говорит: «Дайте только хорошего РП, и все будет хорошо». В этот момент ты выдыхаешь. Уж руководителя проектов-то мы найдем. Значит все будет хорошо. А действительно ли «хороший РП = хороший проект»?
Руководитель проекта – это прежде всего про управление, планирование, согласование действий в проекте, контроль, работу с рисками и бюджетом. При этом, опыт показывает, что ценным является не только умение читать договор с его сухими рамками, датами и ограничениями, но и понимание истинных целей проекта, реальных потребностей, умение и готовность слушать и слышать клиента. Важная составляющая работы РП – создание команды единомышленников, которые вместе движутся к цели. К тому самому «хорошему проекту».
На больших проектах структура команды, конечно, комплексная. Но мне бы хотелось выделить и поговорить про столь значимую роль как архитектор, а именно, функциональный архитектор. А если быть еще точнее – про взаимоотношения функционального архитектора с РП на проекте.
Совместная работа ФА и РП
Задачи функционального архитектора, конечно, существенно шире, чем просто корректно спроектировать решение и удовлетворить заявленные потребности. Это прежде всего человек, с которым бизнес говорит на одном языке, видит в нем родственную душу, тот, кто понимает все требования и боли заказчика. А как насчет рамок проекта, сроков, бюджета, ограничений, регламентов совместной работы и прочих управленческих штук? Не возникают ли в этот момент первые шероховатости в его взаимоотношениях с РП? Искусство находить баланс между обсуждением «всех требований заказчика» и рамками, ограничениями текущего проекта – это невероятно крутой скил. Обладание этим навыком выводит специалиста на существенно новый уровень. По сути, на уровень гибрида ФА и РП. А если такого скила пока нет? В реалиях современного консалтинга в этом случае должна быть тесная совместная работа, чтобы не пострадал проект.
Конфликт или компромисс?
Кейс первый. Архитектор провел анализ результатов проведенных встреч и выяснил набор важных нюансов. До этого их не учитывали в рамках обсуждений, но без их реализации запуститься не получится. Кроме того, оказалось, что вместо планируемых 40 часов на ТЗ теперь надо 120, потому что все оказалось сложнее и надо много копать. Со всей этой информацией архитектор приходит к РП. Он внимательно все выслушал, даже немного погрузился в детали, но говорит о реализации в рамках запросов на изменение и прочие тому подобные варианты – мол, сроки, ресурсы и т.п. Однако, его аргументы разбиваются о стену непонимания. Ведь не сделать сейчас вообще никак нельзя, а если не погрузиться в детали, проект неправильно спроектируют, и потом уже ничего не исправишь.
И в итоге разговора все заканчивается фразами «ты, конечно, как знаешь, но я тебя предупреждаю» и что «ТЗ само себя не напишет». Ультиматумов не любит никто, зреет конфликт. Убрать «неудобного», конечно, можно, но проект идет, заказчик им доволен, да и специалист крутой, классные решения делал.
Кейс второй. Часто на проектах ФА курирует работу выделенных ему консультантов. Прежде всего, конечно, с функциональной точки зрения – проверяет корректность написания протоколов, точность постановок для разработчиков, качество тестирования и пр. Консультанты-исполнители отличаются не только опытом, но и человеческими качествами, в частности, ответственностью, пунктуальностью, пониманием правил работы в команде. И вот, типичный пример: утром прошла встреча с клиентом, консультант часам к 16 написал протокол и отправил ФА. Он протокол изучил и понял, что процент потерянной информации зашкаливает, а уровень неточностей близок к критическому. Совместно проговорили, консультант пошел вносить изменения и после прислал исправленный вариант. Надо ли говорить о том, что и там все было не чисто, а уже вечереет… А таких «точек взаимодействия» в проекте много. В конце концов недовольство архитектора может вылиться в ультиматум РП – «либо убирай их, либо уйду я».
Кейс третий. На встрече с клиентом обсуждался бизнес-процесс и его возможная реализация в системе. В ходе обсуждения выяснилось, что в части процесса есть неучтенная интеграция. Архитектор как эксперт, желающий сразу узнать «всю тяжесть ситуации», предлагает заказчику потратить время встречи и проговорить заодно и особенности этой интеграции. И сразу после этого предложения архитектор ловит на себе гневный взгляд РП – вообще-то есть повестка, а началась какая-то самодеятельность. Конфликт не остается незамеченным и клиентом – рейтинг и значимость ФА на проекте понижается, а с ним падает и продуктивность работы команды в целом.
А что делать?
За долгие годы работы в консалтинге я успел поработать на обеих ролях. Умышленно не говорю «по обе стороны баррикад» – здесь нет и не должно быть двух сторон.
Как руководителю проектов, мне посчастливилось работать с классными архитекторами, это были люди чьими решениями точно можно было гордиться. При этом, описанные выше сценарии были и с ними.
Что делать РП в таких ситуациях? К сожалению, универсальной рекомендации нет, но есть несколько советов:
Никаких резких движений, никаких «я – начальник, ты – дурак».
Конструктивный диалог с планом проекта, с рамками, с обсуждением вариантов, с проявлением максимального уважения, но в тоже время и с обозначением своих целей.
Хорошо работают мозговые штурмы с привлечением коллег-экспертов (эксперты обычно готовы слушать экспертов).
Что делать ФА в таких ситуациях? Работая архитектором и экспертом, я тоже оказывался в схожих ситуациях. И здесь, наверное, рекомендации чуть иные:
Как бы ты не хотел «только творить», как бы тебе не было чуждо «заполнение таймшитов», чтобы расти и двигаться вперед нужно научиться работать с рамками и в рамках.
Постарайся выйти на диалог с РП, будь готовым проверить на клиентах совместно выработанные гипотезы.
Несмотря на то, что глобальная цель – единая, члены команд идут к ней по-разному, выполняя каждый свои задачи. И здесь точно нельзя преуменьшать значение друг друга. На большом проекте совмещать в себе функции РП и ФА практически невозможно. Конечно, только если вы умеете эффективно работать круглосуточно и обладаете суперсилой и опытом? Скорее всего, нет. Поэтому нужно учиться эффективно работать именно в своей роли, с уважением относясь к задачам коллег. Могу дать три коротких, но универсальных совета: развивайтесь в своей роли, профессионалы востребованы всегда, доверяйте экспертизе других членов команды, и помните – цели проекта всегда важнее личных амбиций.