Как выглядит управление проектами на практике: схема из 10 шагов

Хочу рассказать, как наша команда в действительности работает с проектами. Используем ли знаменитые методологии? Следуем им полностью или берем из них понравившиеся приемы? Предлагаю собственную схему работы над проектом, которая является компиляцией приемов из известных методологий, составленных и дополненных с учетом собственного опыта и опыта коллег.

Целью данной публикации является обмен опытом, поэтому буду рада получить в комментариях мнение, оценку и советы от членов Сообщества.

1. Определить цель – что хотим получить от реализации проекта?

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

Почему важно иметь четкое определение и фиксацию этой цели? Это поможет всем участникам процесса внутри компании (руководству проекта и членам проектной группы) правильно понять место проекта в жизни компании и свой статус. Что проектная группа – это не просто центр затрат, на содержание которой придется вычесть из суммы контракта. Проектная группа приносит профит – достигает цели за счет того, что управляет проектом, который непосредственно связан со стратегией компании.

2. Определить общие задачи

Для этого руководителю проекта нужно ответить на вопрос: «Что нужно сделать, чтобы достичь цели?». Задачи могут быть такими:

  • Качественное и прозрачное управление проектом.
  • Недопущение того, чтобы контроль реализации проекта превратился в излишнюю бюрократию.
  • Развитие проектной методологии.
  • Сокращение сроков реализации проекта.
  • Оптимизация ресурсов при реализации проекта.
  • Обучение сотрудников в процессе деятельности.

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

3. Определиться – на чем зарабатываем, а на чем экономим

Проектная группа должна зарабатывать для компании или экономить при реализации проектов? Если рассчитывать именно на профит, то – зарабатывать. Но обстоятельства заключения контрактов могут быть разными, поэтому иногда может стоять только задача сэкономить.

На чем можно заработать:

  • Краткосрочное – дополнительные работы.
  • Долгосрочное – новые контракты с более выгодными условиями, дополнительные сферы (ответвления) деятельности, которые удалось освоить в процессе работы над проектом.

На чем можно сэкономить:

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

На чем нельзя экономить: на качестве.

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

4. Сформировать бюджет проекта

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

  1. Для простых объектов с небольшой ценой и коротким сроком исполнения из суммы контракта сразу выделяется процент, планируемый как прибыль.
  2. Для сложных длительных проектов каждый этап рассчитывается отдельно и прикидываем, на чем сможем заработать больше, на чем меньше.
  3. Далее идет детальная оценка основных видов работ, которая опирается на данные из справочников базовых цен и опыт. Утверждается общая сумма расходов.
  4. Получив примерную разбивку по стоимости, делаются запросы коммерческих предложений и устраиваются тендеры, по результатам бюджет может быть откорректирован в деталях.
  5. Утверждается детальная разбивка бюджета для дальнейшего исполнения. Одновременно разрабатывается и утверждается регулятор расхода денежных ресурсов (подробнее в шаге 9).

5. Составить методологию управления проектом

Существует множество методологий по управлению проектами: классическая каскадная модель, Agile, Метод критического пути, PMBOK и другие. Некоторые возведены их авторами в статус философии, например Six Sigma, а некоторые в большей степени относятся к инструментам, например Kanban, Scrum.

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

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

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

Для заказчика, банка, госструктур

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

  • Четкая фиксация сроков и финансирования.
  • Удобство контроля исполнения и ведения отчетности.
  • Заказчик активно работает только на старте и на финише, а в остальное время только контролирует процесс.

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

Для руководителя проекта

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

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

Такой подход позволяет быстрее адаптировать исполнение проекта к меняющимся обстоятельствам, иметь запас по срокам, при необходимости можно быстро делать «срезы».

Для проектной группы внутри компании

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

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

Для достижения стратегических целей компании

В списке стратегических целей, наверное, любой компании есть улучшение процессов и устранение недостатков. Здесь удобнее использовать подход «Шесть сигм». Six Sigma создан для управления качеством, суть которого сводится к необходимости улучшения качества выходов каждого из процессов, а также минимизации дефектов и статистических отклонений. Достигается это за счет постоянного внесения улучшений.

6. Определить экстремальные точки проекта

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

7. Сформировать техническое задание

  1. Подготовить подробное техническое задание на все задачи. За основу берется ТЗ из контракта и тщательно прорабатывается, добавляются подробности, уточняются детали.
  2. Подготовить подробное анти-ТЗ – список того, что не приемлемо. Этот пункт необязателен, но может послужить дополнительным ориентиром и будет полезен в спорных ситуациях.

8. Определить риски

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

Есть два основных типа рисков:

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

9. Сформировать набор регуляторов

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

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

Первым из набора регуляторов является контроль сроков, поэтому на старте проекта разрабатывается график, который регулирует сроки всего жизненного цикла проекта, где отдельно фиксируем:

  • Контроль срока входа (получение задания, исходных данных, дополнительной информации, способной повлиять на ход проекта).
  • Контроль срока выхода (выдача промежуточных и итоговых результатов).

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

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

И наконец, регулятор для контроля расхода ресурсов:

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

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

  1. Откорректировать процесс.
  2. Если первый пункт не сработал, следует заменить участников процесса.

10. Выстроить работу со сторонами взаимодействия

Тезисы, которые помогут выстроить взаимодействие и послужат принципиальными выводами к данной методологии:

  • Стороны взаимодействия: заказчик, его подрядчики, надзорные органы, госструктуры, ресурсоснабжающие организации, субподрядчики, собственные сотрудники. Все находятся в равных партнерских отношениях. У всех сторон в цепочке зависимость круговая, а не линейная.
  • Руководитель проекта в этой цепочке – тот, кто запускает, контролирует и завершает процесс. Он – руководитель процесса, но не людей, а рациональный баланс между контролем и взаимодействием помогут выстроить описанные выше регуляторы.
  • Работа подрядчика себе в убыток ослабляет позицию подрядчика в глазах заказчика, независимо от статуса заказа.
  • Как ни настраивай процессы, человеческий фактор все равно будет иметь место. В основном работу усложняют два элемента: некомпетентность и отсутствие желания что-то делать. Прежде чем менять людей, необходимо выяснить причины их нежелания работать.
  • Проекты – это всегда о новом, о том, чтобы при необходимости выходить за рамки регламентов и типовых схем, создавая новые.

Также читайте:

Расскажите коллегам:
Комментарии
Генеральный директор, Москва
Ольга Паращак пишет:
Станислав Щербаков пишет:
Евгений Равич пишет:
Six Sigma на практике не пользовался и не видел хорошие примеры вокруг, только читал. Нужно посмотреть внимательно. Как это позволяет юристам работать более качественно - пока не понимаю. 

6Сигма - это метод последовательных улучшений на основе повторяющихся измерений результатов однотипных операций. Задача стабилизировать результат и добиться снижения сверхнормативного отклонения (брак) не более 1 на миллион повторений. Разработано и подходит для крупносерийного производства.

Ума не приложу как его можно использовать в данном контексте.

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

Если с руководстом компании заранее не была бы оговорена философия Six Sigma, то мне могли бы просто заблокировать эту работу с юристами, сказали бы, что вот есть типовая форма, мы ее утвердили 15 лет назад, она тогда хорошо работала и сейчас должна также хорошо работать, и не трогайте юристов - они заняты, погрязли в рутине, отрабатывают контракты каждый раз как в первый раз и готовят миллион протоколов разногласий

Полагаю, что внесение изменений в контракт никак не связано с Six Sigma. Это даже не оферта. Юристы с обеих сторон договариваются о приемлемом и прочем, менеджмент принимает решение. Обычная работа.

Генеральный директор, Москва
Ольга Паращак пишет:
1. Планирую процесс по принципам CCPM, т.е. запараллеливаю те работы, которые можно запараллелить.

Как Вы (как PM, использующий идеи CCPM) работаете с буферизацией?

Ольга Паращак пишет:
Привожу его к форме, визуально похожей на Waterfall

Простите, не понял.

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

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

А если проект большой, а задач и исполнителей много, частое общение физически невозможно. Проще договориться о контрольных точках. Но Вам виднее.

Руководитель проекта, Москва
Евгений Равич пишет:

Как Вы (как PM, использующий идеи CCPM) работаете с буферизацией?

через Адванту

Аналитик, Москва
Ольга Паращак пишет:
Анатолий Курочкин пишет:

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

Если Ваши рекомендации для руководства, то зачем пункт следующий:

 

Мне показалось, что в статье постянное перемещение от советов руководству/владельцу к советам руководителю проекта. Может что-то лишнее?

Анатолий,

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

Проект, который ведет РП - часть успеха (или провала) компании, поэтому придерживаюсь убеждения, что выполняя свой проект надо посматривать на картину в целом

Благодарю за ответ!
Мне сложно представить ситуацию, что руководство компании, инициируя проект, не понимает его цели. Например, проект строительства зданий банка. Какое непонимание целей здесь может возникнуть? Проект создания автоматизированной системы управления заводом - как это можно недопонимать? Есть контракт - ни усеч проект, ни расширить его цель невозможно. 

И ещё. Мне кажется, что надо более тонко употреблять термины проект, процесс, задача. Это далеко не одно и тоже. Как и стоит уточнить, что такое техническое задание. Вот у вас:

7. Сформировать техническое задание
Подготовить подробное техническое задание на все задачи. За основу берется ТЗ из контракта и тщательно прорабатывается, добавляются подробности, уточняются детали.
Подготовить подробное анти-ТЗ – список того, что не приемлемо. Этот пункт необязателен, но может послужить дополнительным ориентиром и будет полезен в спорных ситуациях.

Вот сейчас принимаю участие в проекте строительстве ситуационного центра. Огромное ТЗ, большая работа - от стен до серверов и линий связи. Зада просто огромное количество. Зачем для низ отдельные ТЗ? Во-первых, это неподъёмная работа, а во-вторых, огромная потеря времени. 

Всё это мне очень сложно представить. Хотя бы с рабочей документацией справиться.

 

Генеральный директор, Москва
Анатолий Курочкин пишет:
Мне сложно представить ситуацию, что руководство компании, инициируя проект, не понимает его цели.

Или это не проект.

Слушатель MBA, EMBA, Липецк
Анатолий Курочкин пишет:
Ольга Паращак пишет:
Анатолий Курочкин пишет:

 

И ещё. Мне кажется, что надо более тонко употреблять термины проект, процесс, задача. Это далеко не одно и тоже. Как и стоит уточнить, что такое техническое задание. Вот у вас:

7. Сформировать техническое задание
Подготовить подробное техническое задание на все задачи. За основу берется ТЗ из контракта и тщательно прорабатывается, добавляются подробности, уточняются детали.
Подготовить подробное анти-ТЗ – список того, что не приемлемо. Этот пункт необязателен, но может послужить дополнительным ориентиром и будет полезен в спорных ситуациях.

Вот сейчас принимаю участие в проекте строительстве ситуационного центра. Огромное ТЗ, большая работа - от стен до серверов и линий связи. Зада просто огромное количество. Зачем для низ отдельные ТЗ? Во-первых, это неподъёмная работа, а во-вторых, огромная потеря времени. 

Всё это мне очень сложно представить. Хотя бы с рабочей документацией справиться.

 

Анатолий, доброго.

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

Но это является обязательным процессом при проектировании, но не какая-то особенность проектного управления.

Аналитик, Москва
Андрей Мершинец пишет:
Анатолий Курочкин пишет:
Ольга Паращак пишет:
Анатолий Курочкин пишет:

 

И ещё. Мне кажется, что надо более тонко употреблять термины проект, процесс, задача. Это далеко не одно и тоже. Как и стоит уточнить, что такое техническое задание. Вот у вас:

7. Сформировать техническое задание
Подготовить подробное техническое задание на все задачи. За основу берется ТЗ из контракта и тщательно прорабатывается, добавляются подробности, уточняются детали.
Подготовить подробное анти-ТЗ – список того, что не приемлемо. Этот пункт необязателен, но может послужить дополнительным ориентиром и будет полезен в спорных ситуациях.

Вот сейчас принимаю участие в проекте строительстве ситуационного центра. Огромное ТЗ, большая работа - от стен до серверов и линий связи. Зада просто огромное количество. Зачем для низ отдельные ТЗ? Во-первых, это неподъёмная работа, а во-вторых, огромная потеря времени. 

Всё это мне очень сложно представить. Хотя бы с рабочей документацией справиться.

 

Анатолий, доброго.

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

Но это является обязательным процессом при проектировании, но не какая-то особенность проектного управления.

Согласен с вами! Я и предложил Ольге быть аккуратнее с терминами. Там же она приводит пример заключения контракта юристами. Это тоже не имеет никакого отношения к проектному управлению.

Руководитель проекта, Москва
Анатолий Курочкин пишет:
Андрей Мершинец пишет:
Анатолий, доброго.

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

Но это является обязательным процессом при проектировании, но не какая-то особенность проектного управления.

Согласен с вами! Я и предложил Ольге быть аккуратнее с терминами. Там же она приводит пример заключения контракта юристами. Это тоже не имеет никакого отношения к проектному управлению.

Я пишу о том, как работа происходит в реальности, а в реальности заключение договоров с контрагентами имеет прямое отношение к проектной деятельности и, кстати, отнимает много времени у РП. В проектировании и в строительстве сам текст договора конечно важен, но он краток и в основном состоит из отсылок на приложения, т.к. основная смысловая нагрузка ложится именно на приложения. Приложения обычно такие: 1. Техническое задание; 2. Календарный план работ; 3. Протокол согласования договорной цены; 4. Смета. Конечно же приложения готовит не юрист. Согласовывает с контрагентом приложения тоже не юрист

Слушатель MBA, EMBA, Липецк
Ольга Паращак пишет:
Анатолий Курочкин пишет:
Андрей Мершинец пишет:
Анатолий, доброго.

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

Но это является обязательным процессом при проектировании, но не какая-то особенность проектного управления.

Согласен с вами! Я и предложил Ольге быть аккуратнее с терминами. Там же она приводит пример заключения контракта юристами. Это тоже не имеет никакого отношения к проектному управлению.

Я пишу о том, как работа происходит в реальности, а в реальности заключение договоров с контрагентами имеет прямое отношение к проектной деятельности и, кстати, отнимает много времени у РП. В проектировании и в строительстве сам текст договора конечно важен, но он краток и в основном состоит из отсылок на приложения, т.к. основная смысловая нагрузка ложится именно на приложения. Приложения обычно такие: 1. Техническое задание; 2. Календарный план работ; 3. Протокол согласования договорной цены; 4. Смета. Конечно же приложения готовит не юрист. Согласовывает с контрагентом приложения тоже не юрист

Ольга, доброго.

В соответствии с ГОСТР ИСО 21500-2014, Договор (контракт) с контрагентом (как и Задание на проектирование) может являться основанием для инициирования проекта, но не как составная часть. Это называется "предпроектная деятельность".

"Работа в реальности" -- это частность деятельности в отдельной компании, но не всегда может применяться для создания унифицированной методики.

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

Работа в реальности как частность определенной компании: Задание на проектирование в полном объеме готовит Заказчик, Исполнитель его согласовывает; Календарный план -- да, готовит ГИП, согласовывает Заказчик; Протокол согласования -- готовят как раз юристы; Смета -- это одно из двух: либо согласование договорной стоимости Сторонами через Протокол, либо расчет стоимости через Смету.

В итоге, вовлеченность ГИПа (РП) -- условно на 1,5 Приложения.

Генеральный директор, Москва
Анатолий Курочкин пишет:
Там же она приводит пример заключения контракта юристами. Это тоже не имеет никакого отношения к проектному управлению.

Понятно, что юристы контракт не заключают. Стороной контракта они не являются. 

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

 

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Сколько компании тратят на обучение топ-менеджеров

Треть компаний выделяют на обучение одного топ-менеджера от 500 тыс. руб. в год.

56% россиян поддерживают наем сотрудников с ограниченными возможностями

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

Россияне назвали главные причины для увольнения

Топ причин для увольнения у опрошенных в возрасте 18-34 лет отличается от респондентов, которым 35-49 лет.

10% программистов крупных IT-компаний ничего не делают

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