Как дружить с принципиальными партнерами, решать сложные задачи вместе с заказчиком, вовлекая его в продажи, и не разориться на его капризах, при этом сохранить взаимное доверие, а также о том, зачем вообще нужно учиться проектному менеджменту, мы поговорили с Олегом Тумасовым. В 2003 году Олег стал одним из первых экспертов в России, сертифицированных PMI (Project Management Institute, всемирная профессиональная организация по управлению проектами), и сегодня возглавляет редакцию журнала «Управление Проектами».
– В своем докладе на IE 2018, рассуждая о взаимоотношениях с ключевыми участниками проекта, вы отметили, что с принципиальными людьми их строить проще и удобнее. А что делать, если в одной команде оказались принципиально не согласные друг с другом люди?
Особенно если разногласия касаются технических или технологических аспектов (но не только), их почти всегда возможно разрешить логически – проанализировать разные решения, взвесить все за и против каждого из них и обоснованно выбрать лучшее. То есть перейти от эмоций к цифрам и фактам. Но самое важное – это вырабатывать у всех участников команды не просто командный дух, а командную ответственность за результат проекта. В этом случае сложный вопрос, возможно, потребует общего внимания и усилий всей команды, но в результате приведет уже не к компромиссному, а, возможно, даже совершенно к иному решению, которое устроит всех принципиальных людей.
– Среди методов решения сложных проектных задач вы называете инкрементный подход – делаем поставку по частям, внедряем систему этапами и, тем самым, вовлекаем заказчика в продажу. Это важно для долгосрочных проектов, но что делать тем, кто, грубо говоря, продает коробки 1С?
Вопрос слишком простой и слишком сложный одновременно. Ответ – продолжать продавать коробки и запускать проекты и программы развития этого коробочного продукта, от релиза к релизу улучшая и совершенствуя его, на основе анализа запросов постоянных и потенциальных клиентов. На мой взгляд, продукт, который постоянно совершенствуется и развивается, будет пользоваться большим интересом у клиентов, причем интерес этот будет обусловлен и технически, и психологически. Покупая продукт, клиент хочет приобрести его у компании, которая, по его мнению, будет развиваться и оказывать сервис в длительной перспективе после потенциальной покупки.
– Вы утверждаете, что ИТ-решение можно считать проданным не по факту оплаты, а лишь когда заказчик включил его в свои бизнес-процессы. В продолжение сказанного вами, звучит логично и здорово, а как на деле? Кто должен взять на себя ответственность за качество внедрения, чтобы отношения между вендором и заказчиком проекта стали конструктивными и долгими?
Во-первых, вопрос качества – это всегда вопрос метрик, показателей качества, которые должны совместно выработать и согласовать заказчик и вендор. Качество не должно измеряться субъективно ни одной из сторон. Во-вторых, нужно стремиться к тому, чтобы не было так, что за качество проекта в целом полностью отвечала одна из сторон. Отношения заказчик – вендор не должны превращаться в отношения начальник – подчиненный, нужно всегда стремиться к построению партнерских отношений. В частности, такие отношения предполагают, что каждая из сторон, как минимум, с пониманием и уважением относится к тому, как устроен и развивается бизнес ее партнера.
– Если формально техподдержка и сопровождение системы в договоре не предусмотрены – допустим, у заказчика для этого есть свои ресурсы, – что может сделать исполнитель, чтобы обеспечить полезность внедренного решения, чтобы гарантировать достижение целей проекта?
Важным моментом, о котором, к сожалению, часто забывают, является необходимый уровень документирования нестандартных решений, «фич», специфических настроек, нестандартных договоренностей, которые были только в данном конкретном проекте. Эта документация будет крайне полезна как заказчику, так и самому вендору. При этом заниматься документированием лучше не на финальной стадии внедрения, когда разработчик/внедренец может и забыть, что он настроил «впопыхах» месяц назад или ранее, а по ходу выполнения работ, например, в форме журнала открытых/значимых вопросов (Issue Log).
– А вообще, на ваш взгляд, чем отличается проект внедрения системы с постпродажным обслуживанием и поддержкой и без них? Какие нюансы в управлении следует учесть?
В идеале, ничем не должен отличаться. Описание технически обоснованного SLA («Соглашение об уровне сервиса»), требуемого или рекомендуемого для внедряемой системы, должно быть частью поставки. Изучив этот документ, заказчик может принять решение о том, как будет организована поддержка системы после внедрения. Иногда вендоры ведут себя недальновидно с заказчиками, которые не хотят заказывать постпродажное обслуживание, невольно или вольно оставляя за собой «грабли», на которые неизбежно наткнется заказчик, поддерживая систему самостоятельно. Видимо, считая, что заказчик помучается и придет к выводу, что система слишком сложна, чтобы поддерживать ее самостоятельно и с некоторым опозданием все-таки заключит договор на поддержку.
– Тогда как можно предотвратить увеличение стоимости проекта после запуска, в том числе, когда заказчик начинает менять требования?
Предотвратить изменения вряд ли удастся (проект без изменений по ходу реализации – большая редкость), но можно подготовиться к управлению изменениями и стоимостью проекта, включив в контракт соответствующий пункт или отдельный раздел, описывающий механизм работы с изменениями. Подобный механизм, согласованный заранее, позволит не только работать с действительно важными для заказчика изменениями, но и избежать совершенно необязательных. Заказчик обоснованно сможет принимать решения по изменениям, когда будет понимать цену каждого из них.
– С чего начинать обсуждение и формализацию – с функциональных или нефункциональных требований к системе? Как выстроить понятные для заказчика приоритеты реализации?
Чтобы расставить приоритеты реализации, нужно выяснить приоритеты заказчика. Если он не готов сформулировать свои приоритеты, и даже если готов, – нужно презентовать ему предлагаемый план внедрения, чтобы он мог сопоставить его со своими планами развития. После этого заново обсудить и согласовать приоритеты.
Функциональные требования обычно касаются основных бизнес-процессов и более интересны функциональному заказчику, нефункциональные больше связаны с поддерживающими процессами и часто выражены в форме ограничений, они больше затрагивают службу поддержки.
Ну, и очень простой практический совет. Часто так бывает, что на стадии подписания контракта с внешним заказчиком присутствуют одни его менеджеры, а акты подписывают и решения об оплате принимают совсем другие. И эти другие бывают очень недовольны, когда, возможно, видят готовый продукт впервые и не видят отражения одного или даже всех своих требований. Поэтому обязательно добивайтесь встречи с «руководством» на ранней стадии проекта, чтобы не упустить их требования.
– Вы утверждаете, что доверие и открытость – основа корпоративной культуры и успеха проекта. Однако у всех есть личные карьерные интересы и прочие скрытые мотивы, более того, не всегда понятные им самим. В каких условиях и как сохранять необходимую и достаточную степень открытости, чтобы не навредить доверию, но сохранить приватность?
Термин «приватность», на мой взгляд, некорректно применять к проектной информации. Есть открытая проектная информация, которую нельзя придерживать для «приватного» обсуждения – поскольку такое организационное поведение тормозит принятие управленческих решений и снижает их качество. При этом есть служебная или секретная информация, оборот которой регламентируется отдельно, желательно, без фанатизма. Приватно можно и нужно обсуждать все, что касается личной информации, личной жизни, иногда даже опасений отдельных участников относительно того, как проект может повлиять или уже повлиял на них.
Хороший руководитель проекта должен создавать и поддерживать здоровую атмосферу в команде, к которой плести интриги и вести кулуарную борьбу не выгодно. Для этого он, в первую очередь, должен выяснять и учитывать интересы всех участников команды – это его прямая работа.
– Как настроить заказчика и спонсора проекта на долгосрочные отношения?
Можно сказать, что и заказчик, и спонсор изначально настроены на долгосрочные отношения, поскольку их горизонт планирования заведомо превышает срок реализации отдельного проекта. Более того, они потенциально ожидают подобного отношения от руководителя проекта. Настроить ПМ-а может помочь грамотная система мотивации, сбалансированные KPI (ключевые показатели эффективности), система MBO (система управления по целям), в рамках которых ПМ-у ставятся не только краткосрочные (проектные), но и долгосрочные цели.
– В скором времени начнется ваш новый тренинг, поэтому не могу не спросить, в чем смысл сертификации, скажем, от PMI? Зачем руководителю проектов, тем более, действующему, нужен сертификат?
Могу выделить два плюса. Первый состоит в следующем. Сертификация PMP® PMI® основана на обширном сбалансированном объеме практических знаний и рекомендаций, собранном и структурированном профессионалами управления проектами со всего мира. Поэтому сама подготовка к экзамену принесет огромную пользу, даст возможность выявить и прокачать навыки, которые по разным причинам не использовались в текущей работе и которыми, как следствие, не удалось овладеть в совершенстве на практике.
Кто-то может возразить, что «кун-фу не обязательно должно быть разнообразным, чтобы быть эффективным – можно натренировать всего два-три удара, но выполнять их лучше всех». Но такой подход хорош только для однотипных проектов. Если вы выбрали управление проектами своей профессией и стремитесь к тому, чтобы каждый новый проект был интереснее и масштабнее предыдущего, то есть, нацелены на карьерный рост, вам необходимо владеть не только отдельными инструментами, но понимать общие взаимосвязи и подходы к организации работ в проекте, который потенциально намного сложнее того, которым вы уже управляете сейчас.
Второй плюс, на мой взгляд, в том, что сертификация PMP® PMI® – международная, она признана и ценится во всем мире, во всех странах и на всех континентах. Тесты построены так, что вы не сможете пройти их случайно, без подготовки, вам обязательно придется «попотеть», но дело того стоит. Время, потраченное на подготовку, точно окупится.
– По вашему мнению, руководить проектом может научиться каждый? В какой степени ИТ-директор должен владеть профессией проектного менеджера?
Да, научиться управлять проектами может каждый, причем овладеть как техническими, так и лидерскими навыками, особенно если есть склонность и желание создавать, организовывать команды и мотивировать их на достижение общих результатов. Эффективный ИТ-директор не только должен, но и почти всегда, в той или иной степени, владеет профессией проектного менеджера, даже если это пока не подтверждено сертификатом.
– Есть какие-то характерные отличия руководителя ИТ-проектов от остальных сфер бизнеса? Какие из них отличают хорошего ПМ-а, в вашем понимании?
Умение понимать людей и вести их за собой важно для всех сфер. Отличия касаются знания и понимания предметной области для данной сферы бизнеса, а также трендов в области применения методологий, фреймворков и даже отдельных инструментов. При этом, важны не только знания и умение использовать PMI® PMBOK®, Scrum, KANBAN, SAFe или LESS, но и понимание границ каждого из подходов и условий наиболее эффективного их применения, а также умение комбинировать и совмещать подходы.
Приглашаем на тренинг Олега Тумасова
27 февраля приглашаем принять участие в очном тренинге Олега Тумасова по управлению проектами, целью которого станет подготовка к сертификации PMP® PMI®.
Также предлагаем вам стать спикерами нашей рубрики и дать интервью, в котором вы сможете поделиться своим профессиональным опытом, историями успеха ваших компаний и высказаться по широкому кругу вопросов из сферы ИТ и 1С-разработки. Просто обратитесь в редакцию Инфостарт: dkochergov@infostart.ru, +7(812)309-06-46, доб. 138.