Part Time — это зло.
Не абсолютное, конечно, зло, но в 90% случаев это так.
Под part time я имею ввиду «параллельную» работу над разными задачами в рамках разных проектов и/или в одном проекте но в рамках различных областей компетенций. «Параллельная» в кавычках т.к. по имеет место переключение между задачами до их их полного завершения.
Давайте попробуем разобраться в причинах и последствиях такого широко распространенного явления.
Зачем?
Как правило part-time занятость применяется в следующих базовых случаях
- Для оптимизации использования ресурсов
Если сотрудник решает поставленную задачу за половину рабочего дня, совершенно логично озадачит его и на вторую половину (при плате 100% времени) - При недостатке компетенций
Чем больше уникальных компетенций сосредоточено в отдельном человеке, тем более востребованным он становится и тем большее количество проектов требуют их участия. - Внеплановые задачи
Куда ж без них… Такова реальность, что внеплановые задачи абсолютно различных приоритетов могут возникать на любом из проектов.
Кто-то может, а кто-то нет
Не стоит забывать и о сотрудниках. Есть «резиновые» и «нерезиновые» люди.
Первые достаточно гибки в своем подходе к задачам. Любая дополнительная активность не вызывает у них стресс, и они достаточно комфортно себя чувствуют, имея на руках большое количество задач.
Вторые же напротив — выстраивают жесткую очередь выполнения задач, а любое ее изменение вызывает стресс и как следствие — сопротивление.
Таким образом, если сотрудникам первого типа мы можем давать «параллельные» задачи, то сотрудникам второго типа — только под страхом расстрела.
А если на примере ...
В качестве примера можно рассмотреть 2 часто встречающиеся ситуации.
Пример 1:
Сидит программист Вася и пишет проект А. Приходит к Васе начальник и говорит человеческим голосом — а давай-ка ты, Вася, параллельно подключишься к проекту Б, потому что… Конечно, Вася «подключается»…
Пример 2:
Сидит программист Вася и пишет проект А. Пишет долго и успешно и в один прекрасный момент предлагают Васе дополнительно этим же проектом поуправлять. Важно — задачи по разработке с Василия не снимаются. Конечно, Вася соглашается…
И что же дальше ...
А дальше мы рискуем получить некоторое количество проблем.
С точки зрения сотрудника:
- Размывается фокус приложения усилий. При работе над одним проектом гораздо проще сконцентрироваться, чем при работе над 2-3-мя
- Появляются дополнительные косты на переключение между задачами. Мне очень понравилась аналогия Асхата Уразбаева на тренинге по Agile: компьютеру при переключении между задачами как минимум требуется выгрузить из памяти текущую и загрузить следующую из очереди. С людьми дело обстоит примерно так же
- Приходится устанавливать приоритеты проектам, и здесь уже не столь важно — самостоятельно или взаимодействуя я менеджером проекта.
С точки же зрения PMa:
- Проекты теряют управляемость, т.к. заранее не возможно понять сколько именно времени будет потрачено на конкретный проект. Увы, здесь не будут работать псевдодоговоренности «до обеда работаем по проекту А, после — по проекту Б»
- Существенно повышается риск получить bottleneck при одновременных авралах на конкурирующих проектах
Что касается второго примера — тут все прозаичнее — у нас больше нет программиста на проекте, а новоиспеченный PM лажает. Любые новые обязанности должны, на мой взгляд, развиваться изолированно и целенаправленно. Это тема для отдельного поста.
Классические антипаттерны
- Недооценка задач. Классический пример — «посмотри плз то письмо». Нужно переключиться, найти письмо, убедиться что это нужное письмо, прочитать, осознать, ответить, вспомнить чем занимался до того и на чем остановился… Ну вы поняли :)
- Неумение сказать «нет». Сотрудник зачастую не может отказать руководителю и принимает задачу. Важно понимать, что виноват не только PM, но и сотрудник, принявший задачу.
- Отсутствие элементарных навыков планирования и управления рисками
- ...
Что с этим делать ...
Идеальный случай — не допускать парт тайм задач.
Если параллельная загрузка все же случилась, несколько рекомендаций помогут снизить риски:
- Параллелить лучше задачи с полярными приоритетами с точки зрения проекта. Важная user story отлично сочетается с освоением новой технологии. Первая работает на проект, вторая — на скилы сотрудника.
- Четко ограничить лимит работам. Да, это в большинстве случаев не поможет, но у сотрудника появляются оринтиры
- Ограничить продолжительность такого режима работы. неделя — ок, 2 — куда ни шло, больше — готовьтесь к проблемам
- Поручать парт-тайм задачи проверенным и лояльным сотрудникам. В случае возникновения проблем — с такими людьми можно договориться быстро и безболезненно, не выслушивая аргументы «я же работал по проекту А, а на проект Б времени не осталось»
- Создать максимально комфортные условия для парт-тайм сотрудника
- ...
Безусловно, есть люди, способные эффективно работать в part-time режиме на среднесрочном и долгосрочном интервалах. Но о них — как-нибудь в другой раз.
Автор: kpeskov
