Олег Тумасов: «Проекту нужна такая атмосфера, чтоб интриги были не выгодны»

Возврат к списку

Олег Тумасов: «Проекту нужна такая атмосфера, чтоб интриги были не выгодны»

20.02.2019     

Как дружить с принципиальными партнерами, решать сложные задачи вместе с заказчиком, вовлекая его в продажи, и не разориться на его капризах, при этом сохранить взаимное доверие, а также о том, зачем вообще нужно учиться проектному менеджменту, мы поговорили с Олегом Тумасовым. В 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.




Источник: https://infostart.ru/journal/news/zhizn/oleg-tumasov-proektu-nuzhna-takaya-atmosfera-chtob-intrigi-byli-ne-vygodny_1007837/
Автор:
Дмитрий Кочергов Аналитик


Комментарии
Избранное Подписка Сортировка: Древо
1. user1140989 20.02.19 14:57 Сейчас в теме
Я могу пройти этот курс и стану Руководителем проектов? Можно будет в резюме так писать и на работу устраиваться?
Kochergov; +1 Ответить
4. A_Kriulina 20.02.19 17:19 Сейчас в теме
(1) Тренинг ориентирован на уже работающих руководителей проектов, которые хотят повысить свой профессиональный статус и подтвердить свои знания и навыки. Тренинг готовит к к сертификации PMP®. Если вы сдадите экзамен и получите международный сертификат PMP® PMI®, то это определенно придаст вес вашему резюме и многократно увеличит шансы трудоустройства.
Kochergov; +1 Ответить
2. wowik 573 20.02.19 15:59 Сейчас в теме
Фотографа уволить.
kuzyara; acanta; +2 2 Ответить
3. acanta 55 20.02.19 16:11 Сейчас в теме
(2) Руководитель проекта - это не наш круг общения (ну какие интриги, вы о чем). Поэтому только тренинг, только..
Оставьте свое сообщение

См. также