Люди очень сильно сопротивляются переменам. Для всех, от новичка до основателя компании, перемены очень болезненны!

Внедрение новой информационной системы управления означает не только замену программного обеспечения, которым пользуется большинство сотрудников, но и убеждение конечных пользователей в том, что это необходимо для достижения целей компании. Это очень важно для сотрудников. Как вы не станете использовать палочки для еды, чтобы почистить морковь, так и сотрудники должны быть уверены, что новое управленческое ПО – это лучший выбор для работы!

Чтобы это сделать, у руководителя проекта есть следующие ресурсы:

• сам продукт: как только сотрудники убедятся в преимуществах и функциональных возможностях системы, общий уровень принятия возрастет. Обучите скептически настроенных пользователей ключевым функциям, которые принесут им пользу;

• поддержка SPoC и ключевых пользователей: их роль в компании и демонстрация позитивного отношения к проекту перед коллегами, облегчат управление изменениями;

• спонсоры проекта (например, генеральный директор), поддерживающие его. Их вовлеченность и авторитет помогают убедить команду в важности перехода.

Проекты завершаются успехом, если они имеют широкую поддержку со стороны конечных пользователей, что делает процесс внедрения в Odoo более плавным и эффективным.

The Odoo Change Management Approach

Распространенная ошибка — игнорировать тех, кто не убежден в необходимости изменений (ведь всем удобнее работать с теми, кто соглашается с тобой). Если человек сомневается, делайте противоположное: потратьте время на объяснение «почему» и «как» , и «продайте» ему решение через обучение.

Изменения всегда воспринимаются как затраты и риск для тех, кто через них проходит. А риск стоит принимать, только если польза от этого явно перевешивает затраты. Пытаясь убедить людей, не утверждайте, что риска нет или что это просто. Изменение – всегда серьезное дело.

Вместо этого вы должны «продать» преимущества использования нового решения. Организуйте демонстрацию продукта, покажите, как мы можем решить их болевые точки, и объясните им, почему выбран такой подход. Если они увидят преимущества, то согласятся на риск.

Этот субподрядчик выполняет обработку деталей ветряных мельниц. Цех использует Odoo для управления операциями обработки

Во время внедрения системы в компании «Casual Cushions» больше всех сопротивлялась бухгалтер. А производственники была в восторге от смены старой системы и подходила к проекту с большим энтузиазмом. Несколько месяцев бухгалтер продолжала бросать мне вызов на каждом тренинге и обсуждении – мы до изнеможения разбирали каждый бизнес-процесс (сверка банковских счетов была, пожалуй, самой сложной). С другой стороны, производственникам нравились все тренинги, и у них никогда не возникало много вопросов.

Наконец, когда мы начали работать, все изменилось. Бухгалтер приняла изменения – и, поскольку она глубоко изучила Odoo и его возможности, была к этому готова. Она знала, куда идти, что делать, и все ее проблемы и возможные ошибки были учтены.

А производственная команда столкнулась с серьезными сложностями. Они забыли, чему учились на тренингах и столкнулись с множеством «непредвиденных ситуаций» в работе, которые не обсуждались ранее. Они работали допоздна, чтобы уложиться в сроки, и были разочарованы.

На прошлой неделе я поговорил с бухгалтером, и она отметила, как стала лучше сверка счетов в Odoo и как ей нравится двигаться вперед. Оказалось, что когда пользователь готов задавать вопросы, тестировать процессы и участвовать в проекте, это в разы повышает шансы на успех.

– Матеус, руководитель проекта – Odoo SF

Клиентам свойственно все усложнять:

• не предлагайте клиенту несколько вариантов. Вместо этого предложите лучшее решение и не показывайте альтернативы, пока они не скажут, что ваш вариант их не устраивает;

• не затягивайте с решениями. Настаивайте на принятии решения, даже если люди колеблются. Не соглашайтесь с фразами вроде: «Мы спросим ключевых пользователей» или «Надо посоветоваться с руководителем».

Даже если вы думаете, что все максимально упростили, можно сделать это еще лучше:

• вовлекайте эксперта по системе (например, на этапе анализа ROI) для peer-review. Поскольку он не участвует в проекте напрямую, ему проще принимать сложные решения и находить сложности, которые вы могли упустить.

Несколько лет назад генеральный директор одной из перспективных компаний попросила меня о встрече перед подписанием контракта. Она сказала мне: «Этот проект – жизнь или смерть для моей компании, пожалуйста, скажите мне, что все пройдет гладко». Я ответил примерно следующее: «Нет. Этот проект очень сложен. У нас будет много проблем. Но в конце концов ваша компания станет лучше. И мне нужно, чтобы вы, как генеральный директор, поддерживали проект, когда ваши команды жалуются, чтобы преодолеть эти трудности».

С ней не было контакта около двух лет. Проект был серьезно просрочен, ключевые пользователи потеряли доверие к продукту. Позвонив мне, она сказала: «Этот проект стал кошмаром, мы отстали на 12 месяцев, и я не вижу конца. Но я сделала то, о чем вы просили: всегда поддерживала проект, никогда не критиковала ваш продукт перед командой и постоянно мотивировала ключевых пользователей, которые хотели бросить проект. Но сейчас мы подходим к завершению, и мне нужно, чтобы вы сделали кое-что для меня …»

Эта двухминутная беседа перед контрактом фактически спасла проект. Если бы CEO встала на сторону ключевых пользователей, проект был бы сорван еще месяцев шесть назад. Благодаря ее приверженности проекту он все же был запущен в эксплуатацию через два месяца.

– Фабиен, основатель Odoo , о первом клиенте, купившем приложение Point of Sale

Эта история прекрасно иллюстрирует силу управления ожиданиями клиентов. Если бы Фабьен сказал: «Не волнуйтесь, проект легкий», генеральный директор потерял бы доверие к проекту и, вероятно, поддалась бы давлению ключевых пользователей, как только сопротивление усилилось.

Хорошая спецификация должна быть короткой, иллюстрированной и структурированной по следующим пунктам:

1. Бизнес-потребности: Вариант использования («use case») («что») и его обоснование, объясняющее, почему заказчику нужна именно эта функция (не более 2-3 абзацев).

2. Функциональные требования: Предлагаемое решение с использованием Odoo («как»), проиллюстрированное, если возможно, серией скриншотов или макетов с пояснительными записками.

3. Технические подсказки: Особенности, на которые разработчику нужно обратить внимание.

Помимо основных данных, клиенты часто просят импортировать всю историю данных, например, коммерческие предложения и продажи за 7 лет. Это занимает много времени и съедает значительную часть бюджета. Поскольку это увеличивает риски для успеха проекта, мы должны делать это только тогда, когда это действительно необходимо.

Чтобы проверить, действительно ли это необходимо, задайте клиенту следующие вопросы:

1. Можно ли сохранить эту информацию в старом программном обеспечении или экспортировать в файл?

2. Как часто клиент будет обращаться к этим данным? Для каких целей?

3. Какое стратегическое значение она может иметь через 2, 3 или 4 года?

Как и в случае с любым другим запросом, если клиент не может вас убедить, откажитесь от импорта или запланируйте его на более поздний этап.

Несколько месяцев назад я внедрял модуль «Accounting» для фармацевтической группы из трех компаний во Франции («Ibbeo Cosmetiques»). Во время запуска проекта мой SPoC сказал мне, что перенос всех исторических данных из Sage – это обязательное условие. Ей нужно, чтобы все эти данные были в Odoo, чтобы проверять их в случае необходимости. Я объяснил ей, что импорт исторических данных ставит под угрозу график проекта, и что это займет много времени, а пользы от этого будет очень мало.

Я предложил ей сделку: мы запустим бухгалтерский учет для всех трех компаний всего за три недели, при этом с ее стороны потребуется минимум усилий. Если мы сделаем все по-моему, у нас останется несколько часов из пакета услуг, которые можно будет использовать в будущем. А если позже она решит, что нужно импортировать исторические данные в Odoo, мы сможем сделать это на втором этапе. Она согласилась.

Через неделю после запуска мы уже импортировали начальные остатки и основные данные. После обучения, проект был запущен для всех трех компаний всего через 2,5 недели, при этом осталось 9 часов из пакета услуг.

Месяц назад она прислала мне письмо, в котором поблагодарила меня за быстрый запуск и за то, что Odoo гораздо более удобнее в использовании, чем предыдущая ERP, с которой она работала. Она также сказала мне, что за последние 3 месяца ей не пришлось ни разу проверять предыдущие бухгалтерские проводки и что она находится в контакте с консультантом по продажам, чтобы добавить больше модулей и перенести всю свою деятельность в Odoo.

Поскольку к Odoo присоединяется все больше бухгалтерских фирм, я часто получаю запросы на импорт бухгалтерских проводок за последние 5 лет. Каждый раз я использую этот проект в качестве примера и предоставляю им самим решать. Либо развернуть проект только за 2 недели без особых усилий, или развернуть систему за 2 месяца и заплатить в 4 раза больше за то, что они будут использовать раз в год.

– Винанд, руководитель проекта, Odoo BE

При внедрении Odoo вы можете столкнуться с необходимостью создания специальной документации, чтобы облегчить конечным пользователям процесс адаптации. Даже если это кажется хорошей идеей, вы поймете, что польза, которую вы можете принести, не стоит потраченного времени. Как руководитель проекта, вы должны сосредоточиться на задачах, которые можете выполнить только вы.

Другими словами, руководители проектов не должны тратить время на повторение объяснений, уже данных на протяжении всего проекта. Клиент (как правило SPoC) должен сам создать собственную документацию, основанную на собственных бизнес-кейсах и терминологии. Кроме того, SPoC – это человек, обладающий самыми широкими бизнес-знаниями о компании.

Более того, предоставление клиенту возможности написать собственную документацию гарантирует, что настроенные рабочие процессы Odoo правильно понимаются и обрабатываются SpoC. Это облегчает процесс управления изменениями, поскольку конечные пользователи имеют прямой доступ к надежному источнику знаний в своей собственной компании.

Большинство стандартных процессов уже описаны в существующей документации, информацию легко можно найти в Интернете. Небольшие проекты обычно не требуют специальной документации.

Когда вы работаете с клиентами, помните, что существует разница между целями лиц принимающих решения и потребностями ключевых пользователей. Приоритет большинства лиц, принимающих решения, — это время и бюджет, в то время как ключевые пользователи в основном будут просить о конкретных функциях. Поскольку эти цели противоречат друг другу, вам придется решать: «Вам придется решить: кому вы хотите угодить?»

Вы всегда должны делать то, что считаете лучшим для проекта: это означает оспаривать просьбы ключевых пользователей, вплоть до отказа от выполнения, если вы считаете, что это нецелесообразно для проекта. Используйте следующую тактику работы с запросами на разработку:

1. Действительно ли это необходимо?

2. Не превысят ли затраты на разработку и поддержку выгоду от этой доработки?

3. Достаточно ли существенна выгода?

4. Можно ли решить задачу иначе?

Если вы пришли к выводу, что разработка специфичной функции не оправдана, постарайтесь убедить клиента отказаться от нее. Для этого существуют разные тактики.

Внедрение Odoo в «Lab Society», фабрике лабораторного оборудования.

Допустим, у вас есть запрос на следующую индивидуальную разработку:

У клиента есть сайт, разработанный с помощью Magento Commerce, и он не хочет менять свой сайт, так как уже вложил в него много средств. Но они хотели бы, чтобы Odoo был полностью интегрирован с их сайтом Magento (включая продукты, купоны, отслеживание брошенных корзин и т.д.).

Лучший способ оценить, насколько это необходимо, - проверить, есть ли у клиента эта функция в его старом программном обеспечении или нет. Если клиент регистрировал все заказы вручную, он может делать это и в Odoo. В таком случае мы бы рекомендовали сначала запустить Odoo в продакшн, не разрабатывая интеграцию с Magento, попользоваться им несколько месяцев, а затем решить, стоит ли оно того. Очень часто приоритеты клиентов меняются, когда они начинают работать в новой системе.

С точки зрения управления изменениями, легче внедрять изменения бизнес-процессов постепенно, а не все сразу. Благодаря модульности Odoo имеет смысл развертывать в несколько этапов: сначала с тем, что клиенту абсолютно необходимо для ведения бизнеса, и только после перехода ко второму этапу, другие функции для повышения эффективности.

Один из ключевых пользователей попросил меня воспроизвести сложный отчет, который он строил каждую неделю в Excel. По словам пользователя, этот отчет был очень важен для генерального директора. Однако я задал пользователю вопрос о том, какие KPI важны для генерального директора.

Оказалось, что генеральный директор проверял только несколько показателей, которые были остатками некоторых аналитических счетов. Вместо того чтобы продолжать разработку, я показал генеральному директору, как проверить эти остатки непосредственно в Odoo, и они были довольны.

Общение с клиентом не только снижает затраты на разработку и риски задержки, но и приносит большую пользу бизнесу».

– Седрик, руководитель проекта, Odoo BE

Вам нужно оценить выгоду: сколько человеко-дней в месяц сэкономит клиент благодаря этой функции? Часто заказчик учитывает только то, сколько времени он тратит на выполнение подобной задачи в настоящее время и сколько, по его мнению, он сэкономит в будущем. В реальности ему все равно придется записывать все данные, необходимые для вычислений, вручную разбираться с исключениями и т.д.

Пример: Даже если клиент разработает коннектор для Magento, ему все равно придется решать все конфликты, записывать скидки на цены в обоих программных решениях, решать конфликты со складом, поскольку синхронизация происходит не в режиме реального времени, и т.д.

Затем необходимо оценить текущие расходы. Часто заказчик видит только «разовую стоимость разработки». На самом деле эту стоимость можно умножить на 2 или 3 для будущего обслуживания и обновлений в течение следующих 5 лет.

Обратите внимание, что использование модулей Community Elition (бесплатных с открытым исходным кодом) позволяет сэкономить время на первоначальной разработке, но при этом вам все равно придется учитывать в стоимости тестирование, сопровождение, задержки проекта и обновления. Модуль сообщества - это тоже технический долг.

Допустим, у вас есть запрос на следующую разработку:

Когда мы подтверждаем заказ на продажу строительного проекта, мы хотим создать серию задач на основе набора правил, которые зависят от продуктов, клиентов и местоположения.

Когда к вам поступает запрос на индивидуальную разработку, в первую очередь следует задать вопрос об объеме: «Сколько строительных проектов вы выигрываете в месяц?». Допустим, заказчик выигрывает 10 таких проектов в месяц. Вероятно, создание и обновление задач путем дублирования и обновления шаблонов проектов занимает 10 минут.

Пару лет назад мы работали с Bioulvax – бельгийским производителем вина. Ответственный за проект (SPoC) был увлечен, но считал, что его подход к работе – идеален для всей компании.

Мы пошли на компромисс, внедрив его требования: добавили редко используемые поля дат, перегруженные выпадающие списки, неудобные меню.

Стоит ли запускать сложную разработку, чтобы сэкономить менее 2 часов работы в месяц? Конечно, нет, эта функция будет стоить около 10 дней разработки, плюс 25 % от этой суммы каждый год.

Допустим, у вас есть следующий запрос клиента:

Я хочу синхронизировать наш календарь Outlook с Odoo CRM.

В Odoo есть стандартный коннектор с Google Calendar, но нет коннектора с Outlook. Однако можно использовать сторонние сервисы, такие как IFTTT, для синхронизации Google Calendar с Outlook. Это решение потребует настройки для каждого нового сотрудника, но займет всего 10 минут, что гораздо быстрее и дешевле, чем разработка собственного коннектора, особенно если в компании менее 100 человек.

Через пару месяцев сотрудники массово вернулись к старому софту – система была слишком сложной.

Когда мы поняли это, то предложили следующее: «Давайте вернемся к тому, как система работает в стандартном варианте, и поговорим с командой, чтобы узнать, что они хотят получить от системы». Другими словами, мы спросили людей, чего они хотят, вместо того чтобы навязывать им конкретный способ работы. Мы организовали демонстрации, полностью основанные на стандарте, с учетом целей команды.

Они не могли поверить, насколько просто пользоваться системой, и, когда мы снова начали работать, вся команда приняла Odoo и отказалась от старых привычек. Я научился всегда оспаривать требования SPoC и постоянно фокусироваться на бизнес-целях. Часто заказчики знают свой бизнес, но не знают, как его реализовать.

– Седрик, руководитель проекта, Odoo BE & SF

Для клиентов разработка под заказ приводит к дополнительным затратам и задержкам по срокам, иногда до такой степени, что проект оказывается под угрозой. Кроме того, индивидуальная разработка приводит к возникновению технического долга, который заказчику придется оплачивать в ближайшие годы в виде расходов на обслуживание и модернизацию. Такой технический долг стоит около 25% от стоимости разработки каждый год (~17% на сопровождение + ~8% на обновление).

Каждая разработка может показаться простой и доступной. Но, как уже объяснялось, сложность проекта растет не линейно, а экспоненциально по мере роста количества кастомизаций. Вероятно, клиенты хотят изменить, что им не нравилось в предыдущем программном обеспечении, но не лучше ли стандартизировать их бизнес-процессы и реализовать проект в два раза быстрее и в два раза дешевле?

Для компаний, предоставляющих услуги по внедрению, индивидуальная разработка как правило, обходится в кругленькую сумму при низкой ценности для клиента. Вот типичный сценарий:

Вы оценили 10 дней на разработку функции. Заказчик считает, что это слишком много для такой базовой функции, поэтому вы берете на нее только 8 дней. В итоге вы тратите на это 12 дней. Позже обнаруживаются проблемы, которые появились из-за спешки, а заказчик не хочет платить дополнительно, поскольку это ваша вина. То, что должно было принести 35% маржи, в итоге приносит 6% убытка!

Чтобы компания росла, надо сосредоточиться на услугах с более высокой маржой, и снизить риск не оплачиваемых часов. К таким услугам относятся: управление проектами, бизнес-анализ, кастомизация без разработки, управление изменениями и обучение. Сервисные компании, которые строят свое мышление на сокращении разработки, рано или поздно окажутся более конкурентоспособными, чем другие.

Компании, которые лучше управляют ожиданиями клиентов, значительно снижают затраты на реализацию проектов. Конечно, разработка на заказ иногда необходима для бизнеса. Но, как показывает наш опыт, большинство запросов клиентов либо не стоят затрат, либо не актуальны. Как только сотрудники начинают использовать Odoo, они могут обойтись без доработок, так как это не является необходимым.

«Mecatis» – компания, специализирующаяся на проектировании, производстве и обслуживании оборудования. Компания начала использовать Odoo community в 2013 году и не обновляла версию системы. В 2017 году они обратились к нам, чтобы перейти на Odoo 11. У них было настроено 4 пользовательских модуля и 55 модулей сообщества.

Они потратили десятки тысяч евро на разработку и поддержку, что не является нормальным для компании из 10 сотрудников. У них был огромный технический долг, и стоимость обновления этих модулей была бы астрономической.

Вместо того чтобы обновлять эти модули, мы проанализировали каждый из них: некоторые модули можно было заменить существующими функциями в Odoo 11, некоторые функции не использовались, а в остальных клиент даже не знал, что эти модули делают. Поэтому, вместо того чтобы обновлять пользовательские модули, мы обучили их стандартным и помогли изменить подход к работе. Всего за 100 часов работы мы перевели их на Odoo Online без единой разработки. Их ежемесячные расходы сократились в 10 раз.

Я уверен, что во время внедрения Mecatis или их партнер думали, что им нужны эти модули сообщества. Но в итоге оказалось, что для небольшой компании выгоднее придерживаться стандартных решений, чтобы не застрять в старых версиях. После перехода на Odoo Online клиент был так счастлив, что мы продолжили сотрудничество; они подписались как партнеры, чтобы перепродавать Odoo Online своим клиентам, делегируя обслуживание нашим командам.

– Фабьен, основатель Odoo

Когда что-то идет не так, люди пытаются найти виновных и придумывают оправдания, чтобы защитить себя. Такое часто случается, когда в проекте участвуют несколько сервисных компаний. В случае неудачи они будут утверждать, что их вины нет, и будут говорить, что виноваты другие.

Внутренние разборки – это игра, в которой проигрывают все. Лучший способ справиться с этим – не играть в эту игру. Когда проект проваливается, обычно виноваты все. Поэтому, когда случается жопа, не тратьте время на споры о том, кто виноват. Не стройте линию обороны.

Вместо этого сосредоточьтесь на движении вперед и решении проблемы (независимо от того, ваша это проблема или нет; нам не важно, кто виноват, нам важен успех проекта).

Minerex – это компания, которая импортирует различные строительные материалы из США, и реализует их на территории Мексики. Все их офисы расположены в Мексике. До 2016 г. они использовали SAP для управления своим бизнесом.

Владельцы Minirex жили в США (Джексонвилл, ФЛОРИДА). Они решили внедрить Odoo, но при этом не участвовали в деятельности компании. Они не знали о различных процессах, бизнес-документах используемых в компании, и т. д. Компания эффективно управлялась сотрудниками офиса в Мексике.

И это было причиной провала. Почему?

Решение о внедрении Odoo было принято владельцами компании, без согласования с кем-либо из сотрудников мексиканского офиса. С момента проведения конференции стало очевидно, что никто из сотрудников в Мексике не ждал внедрения Odoo. Поскольку никто не спрашивал их мнения, они воспринимали Odoo как нечто, навязанное им (например, «владельцы просто пытаются сэкономить деньги, навязывая нам это программное обеспечение").

На протяжении всего процесса внедрения они сопротивлялись изменениям: все шло медленно, внедрение не было для них приоритетной задачей. Изначально мы не знали об этой ситуации. Как только мы это поняли, мы поговорили с владельцами.

И владельцы, и консультант отправились в Мексику, чтобы заручиться поддержкой мексиканского офиса. Мы показали им, на что способна Odoo и как она сможет обрабатывать их процессы более эффективно, чем в предыдущей системе SAP. Только в этот момент внедрение стало действительно продвигаться вперед.

В заключение хочу сказать, что прежде чем приступать к внедрению, убедитесь, что ключевые пользователи согласны с решением. В конце концов, именно эти ключевые пользователи будут использовать Odoo и сотрудничать с вами в процессе внедрения.

– Микель, директор, Odoo Мексика

Управлять множеством проектов сложно, а подстраиваться под каждого участника – невозможно. Но если вы научитесь распознавать типы личности, это упростит задачу:

«Сделаем это сейчас» – человек, который сразу переходит к сути.

Ваш SPoC, как правило, не будет уделять достаточно времени процессу обучения и может действовать слишком быстро, чтобы конечные пользователи успели освоиться в Odoo.

Ваши действия:

• убедитесь, что SPoC хорошо знает Odoo (проверьте три раза);

• контролируйте, как он объясняет проект команде (например, проверьте его материалы для обучения);

• убедитесь, что людей, сопротивляющихся проекту, вовлекают в работу (например, через выбор ключевых пользователей);

• проводите обучение конечных пользователей вместе с SPoC.

«Сделаем это правильно» – человек, который соблюдает правила до мельчайших деталей.

Такой SPoC цепляется за старые процессы («мы всегда так работали!») и сомневается в ваших решениях.

Ваши действия:

• оспаривайте его требования (больше внимания уделяйте выгоде от внедрения, а не тому, что это стандарт);

• привлекайте экспертов по приложениям, чтобы укрепить легитимность ваших предложений.

«Сделаем это гармонично» – хорошо разбирается в своем бизнесе и захочет контролировать все – от деталей до общей картины.

Ваши действия:

• отправьте ключевых пользователей на курсы: https://odoo.com/learn;

• добейтесь, чтобы они стали экспертами в Odoo (дополнительные тренинги при необходимости).

«Сделаем это вместе» – такой SPoC генерирует идеи каждую минуту и часто меняет свое мнение.

Ваши действия:

• четко обозначьте роли: SPoC выражает потребности бизнеса («что и почему»), а вы принимаете решения о том, как они должны использовать Odoo («как»).

Слишком часто начинающие лидеры считают себя «недостаточно компетентными» на фоне опытных коллег и боятся высказывать своё мнение.

Опыт – не панацея. Бизнес-решения должны опираться на логику и здравый смысл, а не только на прошлые кейсы. Более того, иногда опыт становится ловушкой: люди действуют по инерции («как раньше»), даже если это неэффективно в новых условиях.

Поэтому молодые руководители проектов не должны бояться отстаивать свою точку зрения и ставить под сомнение мнение опытных людей. Если они правы, они убедят вас. Если нет, смело отстаивайте свою точку зрения.

За последние несколько лет я нанял более 60 руководителей проектов, и большинство из них были свежими выпускниками. Они мотивированы, полны энергии и хотят проявить себя.

Наша методология реализации проектов делает кривую обучения наших «новичков» почти вертикальной в первые месяцы их работы. Хорошее обучение дает им не столько опыт, сколько правильные инструменты для убеждения клиентов.

Важнейшее послание, которое я передаю своим новичкам: независимо от знаний и опыта, самый важный навык для достижения успеха в качестве руководителя проекта – это сильный образ мышления».

– Катерина, руководитель отдела руководителей проектов, Odoo Бельгия