Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Ищем причины овертаймов в команде: чек-лист для менеджера

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

Рассматривайте список как неприоритизированный и не являющийся конечным. Вы можете пробовать все нижеперечисленное (в формате healthcheck) или применять при анализе проекта на ретроспективах или других встречах, чтобы определить конкретные шаги более предметно.

Процесс составления/обновления расписания проекта

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

Логично, что менеджер проектов должен разбираться не только с метриками и информацией, но и с процессом как таковым. Ниже представлен ряд вопросов для проверки:

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

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

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

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

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

Проработка содержания проекта

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

Если брать управление изменениями в проекте в целом, то именно изменения в содержании проекта, как правило, влекут за собой перепланирование проекта в целом или, как минимум, значимых его частей (риски, бюджет, расписание и прочее). Что интересно, подход, который исповедуется в проекте, практически никак не страхует команду от сверхурочной работы. Предиктивные подходы формируют давление жесткими ограничениями, тогда как для гибких подходов характерна некорректная трактовка «гибкости», что может вести буквально к ежедневным изменениям работ в проекте.

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

  • Существует ли процесс управления изменениями в проекте?
  • Осведомлены ли все участники проекта о том, каким образом обрабатываются изменения в проекте?
  • Есть ли на проекте steering committee? Прописана ли его роль в разрешении конфликтов, связанных с изменениями в содержании?
  • Как выглядит сессия product backlog refinement, если она есть?
  • Каковы обязанности и роль владельца продукта, если таковой имеется?

Основываясь на своем опыте, выделю наиболее часто встречающиеся проблемы:

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

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

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

Управление требованиями

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

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

  • Всем ли вовлеченным сотрудникам известна цель проекта/видение продукта?
  • Используются ли гибкие цели при построении дорожных карт? Как они формулируются?
  • Какая документация используется для трассировки требований?

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

Управление вовлечением заинтересованных сторон

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

Я неоднократно становился свидетелем «мотивирующих» диалогов директоров или собственников компании с командами в духе «Ребята, я же знаю, что вы молодцы/звери/машины». И ребята, разумеется, не могут подорвать веру начальства в себя каким-то отказом посидеть до 10 вечера над срочной поставкой клиенту. Я не буду в тысячный раз пересказывать все возможные последствия переработок, скажу лишь, что последствия такой тактики выжженной земли впоследствии ложатся на плечи именно проектного менеджера, который вынужден будет работать с выгоревшей и уставшей командой над проектом, которому все желают скорейшей смерти.

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

  • Возникают ли ситуации, когда клиент ходит к вашему начальству с просьбой «продавить» изменения в проекте?
  • Является ли проектный менеджер конечной точкой контактов с клиентом? Если нет, какие решения принимает аккаунт-менеджер?

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

  • Существует ли список всех заинтересованных сторон проекта?
  • Существует ли градация заинтересованных сторон проекта? На что она влияет?
  • Используются ли продвинутые модели анализа стейкхолдеров (матрицы, когнитивные карты)? Если да, каким образом эти артефакты обновляются?
  • Каким образом собирается обратная связь от заинтересованных сторон?
  • Каков сейчас уровень удовлетворенности разных стейкхолдеров от проекта? Какие последние действия предприняты для изменения этого показателя?

Наиболее распространенные практические проблемы:

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

Пример из практики. После каждого демо по проекту команда несколько дней оставалась работать сверхурочно. Причиной этого явления было то, что на демо приходили высокопоставленные стейкхолдеры, мнения которых о продукте не спрашивали ни разу, кроме как на самих демо. Никакая работа с ними не велась. Решением стал сбор общего steering committee, обсуждение ролей и интересов каждого стейкхолдера, маппинг стейкхолдеров (более 10 человек) на матрицу «влияние — интерес». Например, несколько человек приходили на демо, потому что это был их единственный источник информации о проекте.

Результатом таких действий явилось радикальное сокращение количества лиц, непосредственно влияющих на разработку продукта, и повышение удовлетворенности стейкхолдеров из-за уместных по объему и своевременных статус-отчетов.

Взаимные уступки

Взаимные уступки (лучший перевод trade-offs, который мне удалось придумать) могут относиться ко всем вышеперечисленным областям. В широком смысле я отношу взаимные уступки к части работы с заинтересованными сторонами, так как самый распространенный trade-off — это соотношение бизнес-задач и технических задач. Вспомните, например, как определяется длина спринта в Scrum: одним из критериев является как раз trade-off между бизнесом (которому нужно побольше и побыстрее) и технологией (нужно подольше делать и поменьше распыляться).

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

Воспользуйтесь следующими вопросами:

  • Используется ли на проекте понятие технического долга? Все ли ознакомлены со смыслом?
  • Каким образом команда проекта управляет техническим долгом (визуализация, мониторинг, репортинг и прочее)?
  • Включена ли работа над техническим долгом в повестку сессий планирования?
  • Каким образом ведется приоритизация задач с учетом накопленного технического долга?
  • Каким образом технические задачи включаются в список работ? Насколько сильно сопротивляется бизнес и насколько команда способна коммуницировать потребности?
  • Включают ли дорожные карты проекта работу над техническими enablers?

Пример из практики. После очередного релиза и в отсутствие бюджета команда несколько дней в авральном порядке решала задачи технического долга. При анализе ситуации выяснилось несколько вещей. Во-первых, клиент не был tech-savvy, и работы по разъяснению того, из каких элементов может состоять бэклог, с ним никогда не проводились. Во-вторых, в команде отсутствовал definition of done, чтобы работать с ожиданиями клиента по готовности новой функциональности. Итак, сначала на очередном обзоре спринта подняли вопрос о том, что большинство обратной связи от клиента должно быть маркировано как «технический долг».

Например, возникли вопросы к быстродействию системы. Вместо создания бессмысленных карточек типа «я, как система, хочу работать быстрее» (да-да, такое, как оказалось, на проекте бывало) внесли пометки, чтобы отличать задачи, связанные с техническим долгом. Во-вторых, немного позже разработали и утвердили definition of done, отдельным пунктом которого стало: «Не создано технического долга, или создан элемент технического долга со сложностью не более 5 стори-пойнтов». Команда перестала работать над ним сверхурочно и сделала большой шаг на пути к zero debt policy.

Система метрик

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

Предлагаю обратить внимание на следующие аспекты:

  • Влияют ли проектные метрики на сотрудника напрямую (пересмотр зарплаты, получение отпуска и прочее)?
  • На какие области проекта направлены метрики? Направлены ли они на сотрудника, команду, проект в целом?
  • Кому и как репортятся проектные метрики?
  • Какие решения принимаются на основании проектных метрик?
  • Кто имеет доступ к проектным метрикам?

На практике часто встречаются следующие случаи:

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

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

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

Вместо послесловия

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному8
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Имхо, овертаймы предупреждаются тремя вещами:
1. Финансовой подушкой на случай увольнения
2. По***змом, снятием лапши с ушей, пониманием что этот проект не твой, менеджер не лучший друг, коллеги — не кровные братья. Наличием яиц в конце концов.
3. Как финал заявлением: я буду овертаймить только за двойную (тройную) оплату. Что, нет бюджета? Тогда у меня нет времени на сверхурочную работу! Что, заказчик будет недоволен, мне какое дело? Хотите — увольняйте, благо в айти дефицита работы нет.

И всё. Менеджер побурчит, попробует задвигать о командном духе, увидит что не колышет (особо тупым можно прямо сказать) и отстанет. Нового то программиста ему быстро не найти и не факт что новый будет лучше старого. Да, в случае передряг ты первый кандидат на вылет, но это лучше чем быть послушным зайкой решая чужие проблемы за счет своей жизни и здоровья

Сложилось ощущение что в сухом остатке получается 2 причины овертаймов:
1. Плохое планирование со стороны ПМа, который не учел что-то, не поработал с рисками, плохо составил расписание и т.д.
2. Желание компании (или заказчика) сэкономить или прыгнуть выше головы( 9 женщин должны родить ребенка за месяц).
Первый случай лечиться относительно легко. А вот второй....

Овертайм має ціну: 1 година овертайму сьогодні коштує 2 години непродуктивної праці завтра. Таким чином, 12 годинний робочий день означає, що наступного дня можна просто не виходити, все одно результату не буде.

Мне понравилась статья — хорошие проверочные вопросы.

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

Нередко в них виноваты сами же инженеры, их низкий профессионализм и поганые инженерные практики.

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

Ещё круче, когда вместо того, чтобы как в первом примере хотя бы делать полезный рефакторинг, повышающий качество кода, инженеры втихаря занимаются экспериментами: «о, а давай попробуем ту новую архитектуру, про которую рассказывал рыжий бородач на конфе — щас перепишем вот этот [идеально работающий] модуль». Очень распространено в аутсорсинге, где у инженеров нет личной заинтересованности в успехе продукта и где любят учиться за счёт проектов заказчика.

Или команды, которые сознательно и по собственной инициативе (а это всегда инженерная инициатива) полностью отказываются от тестирования кода, месяцами пишут в режиме ad hoc и каждую пятницу вечером поднимают упавший прод. Нуачо, починить упавший в пятницу вечером прод — это же героизм.

Или обратная ситуация — стоит задача сделать пару пробным статических экранов а ля «About us» и вместо какого-нибудь MVP инженер решает сразу строить на века — Clean Architecture, пронизанный DI с полностью конфигурабельным со стороны бекенда UI, поддержкой A/B тестирования и полным покрытием тестами. Естественно, это все втихаря и по личной инициативе, чтобы коллеги на ревью потом сказали: «вот это да, вот это Палыч голова!». Ради такого не грех и до утра посидеть.

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

Комментарии сотрудников под статьей про Genesis тому подтверждение.

Какое же это счастье не работать в аутсорсинге. Спасибо за статью! :)

93 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Мне понравилась статья — хорошие проверочные вопросы.

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

Нередко в них виноваты сами же инженеры, их низкий профессионализм и поганые инженерные практики.

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

Ещё круче, когда вместо того, чтобы как в первом примере хотя бы делать полезный рефакторинг, повышающий качество кода, инженеры втихаря занимаются экспериментами: «о, а давай попробуем ту новую архитектуру, про которую рассказывал рыжий бородач на конфе — щас перепишем вот этот [идеально работающий] модуль». Очень распространено в аутсорсинге, где у инженеров нет личной заинтересованности в успехе продукта и где любят учиться за счёт проектов заказчика.

Или команды, которые сознательно и по собственной инициативе (а это всегда инженерная инициатива) полностью отказываются от тестирования кода, месяцами пишут в режиме ad hoc и каждую пятницу вечером поднимают упавший прод. Нуачо, починить упавший в пятницу вечером прод — это же героизм.

Или обратная ситуация — стоит задача сделать пару пробным статических экранов а ля «About us» и вместо какого-нибудь MVP инженер решает сразу строить на века — Clean Architecture, пронизанный DI с полностью конфигурабельным со стороны бекенда UI, поддержкой A/B тестирования и полным покрытием тестами. Естественно, это все втихаря и по личной инициативе, чтобы коллеги на ревью потом сказали: «вот это да, вот это Палыч голова!». Ради такого не грех и до утра посидеть.

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

Комментарии сотрудников под статьей про Genesis тому подтверждение.

Овертайм має ціну: 1 година овертайму сьогодні коштує 2 години непродуктивної праці завтра. Таким чином, 12 годинний робочий день означає, що наступного дня можна просто не виходити, все одно результату не буде.

Практика AIR (After-Incident Review) хороша в любом случае. Отличный комментарий.

Хорошая статья, спасибо!
Осознание проблемы и попытки ее решить уже многого стоят.
А то, судя по комментам, или все очень просто (почему же проблема тогда часто встречается?) или очень сложно (что ни делай, а овертаймы будут потому что: «ряд причин которым нет конца») :)

Самый простой способ избежать овертаймов — предупредить кастомера, если овертайм вызван действиями кастомера, то:
1. команда будет работать в аврале по первому требованию кастомера;
2. Все часы работы умножаются на 3.

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

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

И они идут нахер в тот же день. Тем, кто не понимает «как это» учить слово «предоплата»

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

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

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

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

А если кастомер вам предложит поработать бесплатно ради положительного фидбека (ну там у него деньги закончились или просто денег жалко) тоже согласитесь?

Дык встречались это не работал с ними, я обычно предупреждаю что в случае чего овертаймить не смогу, у меня всего за 10 лет овертаймов мож часов 20, не больше

Это в случае T&M модели. В случае fixedPrice заказчику абсолютно пох на овертаймы, его бюджет от этого не зависит никак.

Fixed price делается ровно по ТЗ, любые изменения идут отдельным прайсом. Да, менеджер должен быть достаточно скиловый чтобы правильно писать ТЗ.

Разумеется. Но заявки «эта фича нужна мне позавчера» никакой контракт и ТЗ не нарушают.

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

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

Сложилось ощущение что в сухом остатке получается 2 причины овертаймов:
1. Плохое планирование со стороны ПМа, который не учел что-то, не поработал с рисками, плохо составил расписание и т.д.
2. Желание компании (или заказчика) сэкономить или прыгнуть выше головы( 9 женщин должны родить ребенка за месяц).
Первый случай лечиться относительно легко. А вот второй....

... что можно, в свою очередь, сократить до 1 проблемы — люди =).

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

Оказалось, что расписание составлено путем деления выделенных на дисциплину часов на 8

Тоесть числа для одного значали дни, а для другого часы?)
Это как я спорил с бомжом, у нас все не сходилось, я считал в бутылках, а он в ящиках)

Нет, имелся ввиду такой кейс:
— Сколько займет времени задача А?
— 32 часа
— Ок, пишем 4 дня.

На выходе какашка.

Есть вторая команда — идусы, котрый бажат. Потом перед релизом прибегает кастомер с воплями «Шеф всё пропало» так и получается овертайм. youtu.be/Dtx9BIbFaCQ

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

Сверхурочная работа у девов — это зло. И ее не компенсировать двойным/тройным тарифом, потому что овертайм — это стресс, а стресс — это недосып. А недосып — топливо для выгорания.
У опсов это иногда бывает, но компенсируется тем, что обычно все работает как надо и это задает спокойный темп.

Имхо, овертаймы предупреждаются тремя вещами:
1. Финансовой подушкой на случай увольнения
2. По***змом, снятием лапши с ушей, пониманием что этот проект не твой, менеджер не лучший друг, коллеги — не кровные братья. Наличием яиц в конце концов.
3. Как финал заявлением: я буду овертаймить только за двойную (тройную) оплату. Что, нет бюджета? Тогда у меня нет времени на сверхурочную работу! Что, заказчик будет недоволен, мне какое дело? Хотите — увольняйте, благо в айти дефицита работы нет.

И всё. Менеджер побурчит, попробует задвигать о командном духе, увидит что не колышет (особо тупым можно прямо сказать) и отстанет. Нового то программиста ему быстро не найти и не факт что новый будет лучше старого. Да, в случае передряг ты первый кандидат на вылет, но это лучше чем быть послушным зайкой решая чужие проблемы за счет своей жизни и здоровья

Финансовая подушка нужна всем, независимо от того, овертаймишь или нет)

По***зм — отличное качество вплоть до миддла. На сеньоров такие не идут (сразу замечу — да, идут в соседний двор на +500 и сеньорскую лычку, что говорит ни о чем другом, кроме кислого уровня менеджмента в соседнем дворе).

Заявления о тарифах хорошо бы иметь на уровне контрактов, а не 1-1 митингов.

И да, таких увольняют. Из моей практики, такие персонажи никогда не являются топ-перформерами, и команда только улучшается их устранением.

На сеньоров такие не идут (сразу замечу — да, идут в соседний двор на +500 и сеньорскую лычку, что говорит ни о чем другом, кроме кислого уровня менеджмента в соседнем дворе).

Синьор это 5000+, остальное не существенно.

Заявления о тарифах хорошо бы иметь на уровне контрактов, а не 1-1 митингов.

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

Из моей практики, такие персонажи никогда не являются топ-перформерами, и команда только улучшается их устранением.

Правильно, это я описывал в статье «разумный эгоизм»: в таких «командах» сознательно выбирают трудоголиков потому, что не трудоголикам за дополнительную работу придётся платить. Именно поэтому я работаю во фриланс, с почасовой оплатой.

Синьор — это умение выполнять задачи, которые стоят 5000+. Не стоит путать причину и следствие.

Не видел такого в контрактах, однозначно рад за людей, у которых так написано.

Я не ставил знак равенства между «топ-перформер» и «готовый на все трудоголик». Это разные люди.

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

П.С. Меня зацензурили, Владимира нет. Что за избирательность? =)

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

Чувак, поскольку я постоянно задумываюсь о планировании, я и написал эту статью =)

Я не говорил, что топ-перформеры — это те, кто вкалывает больше всех. Но, определенно, те, кто больше всех «мне на все плевать», редко (в моей практике — никогда) не являются таковыми. Я чувствую путаницу между output и outcome в твоем посыле.

Из моей практики, такие персонажи никогда не являются топ-перформерами, и команда только улучшается их устранением.

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

я не ставил знак равенства между топ-перформером и терпилой.


агенда
Предиктивные подходы формируют давление жесткими ограничениями
Управление вовлечением

Блджад... Нафіга так ускладнювати... :)
Автор, будь проще и люди к тебе потянуться ©

Эта статья мотивировала качнуть с сайта PMI русскоязычный PMBOK, вот где жесть-то. Не думаю, что существует хотя бы один живой PM, который так говорит в жизни.

Я так действительно не говорю (к сожалению, наверное). Но я не люблю говорить калькой с английского. Из двух зол я выбрал меньшее.

Какое же это счастье не работать в аутсорсинге. Спасибо за статью! :)

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

никто не берёт обязательств

А какие обязательства в оутсорсинге берёт на себя рядовой разработчик?

Поставка в сроки и в качестве.

Замечу, что это обязательство существует независимо от того, взято оно по собственной воле или навязано. Случаи «тим лид/менеджер взял обязательство за разработчика» в статье описан.

Поставка в сроки и в качестве.

С чего ты это взял? Я сразу говорю: нет оплаты — нет работы. Если овертаймы на шару, ровно через 8 часов + обед я иду домой

Мне кажется, эта дискуссия не имеет смысла. Ты рассуждаешь со стороны фрилансера, топ-перформера, возможно, в каком-то очень редком домене. Я говорю о компаниях с менеджментом, которому нужно расти. О чем мы спорим?

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

Это не мазохисты, желающие бесплатно работать.

Иногда это «отложенное вознаграждение». Иногда это (очень древнее) знание о том, куда и как давить на страхи и/или сопричастность.

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

(1)

Иногда это не срабатывает.

— Товарищ Комрад, вы были назначены ответственным за этот проект, и говорите, что проект в сроки не укладывается. В эту субботу мы отрежем вам за это всё ваши яйца, вот этой лопатой.

— Да? А я выхвачу лопату, и на вас пойду,
Вовремя напомнили вы все мне про неё,
Говорю вам — я таких слов не потерплю,
Я сейчас лопатой отрублю
Вам ваши Ред Хот Чили Пеперс
Всем поочередно
Ваши Ред Хот Чили Пеперс нахер отрублю!

Конфликт исчерпан, проект продолжается без участия уволенного товарища.

(2)

Иногда это срабатывает.

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

— О, нет! Но моя ипотека!!!111!!!!

— Да-да, пострадают и ваша ипотека, и ваши 40 котов, и ваши мечты освободиться от гнета офисного рабства!

— Неужели нет никакого выхода?

— Ну, не знаю... Я же хочу вам помочь...

— Да, да, пожалуйста, давайте рассмотрим варианты...

— Ну... разве что, можно постараться как-то успеть к сроку...

— Да! Да! Например, я могу работать сверхурочно!

— Это, вероятно, выход, но товарищ Комрад, учтите, что ой да бюджет проекта ой да накрениииивсяяя... Надо как-то спасать ситуацию.

— Неважно! Надо спасать проект! Надо выходить в выходные! Я готов!

— Молодец, товарищ Комрад! Возвращайтесь на ваше рабочее место. Лопата у нас тут полежит. Для порядка.

Конфликт исчерпан, проект продолжается. С неоплачиваемыми сверхурочными. Торжество галерного менеджмента. i.stack.imgur.com/mqxMR.png

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

А если время гибкое, и в контракте записано не 8 часов в день, а 40 часов в неделю, и тебя просят поработать 12 часов сегодня, говоря, что завтра можешь поработать 4 часа, ты соглашаешься? Или принципиально такие контракты не подписываешь, а требуешь, чтобы были указаны часы в день?

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

Если это не ваш стартап/компания то для вас нет большой разницы «летит самолет» или нет, покуда стабильно платят зарплату. Да, в успешной растущей компании атмосфера может быть оптимистичнее, но зачастую на уровне разработки продукта все отлично в обоих случаях, если люди знают свое дело.
И никакой это не экстремум с противоположной стороны — никаких тупых практик со всякими прокси-владельцами продукта, нифига не понимающих в разработке софта линейных менеджеров и всяких проджект-менеджеров, которые каждый чих должны «променеджить» по заветным учебникам PMI.
Жопа в продуктовых компаниях начинаетя когда какой-то недалекий менеджер решает отдать разработку на аутсорсинг.

Жопа начинается везде, где заводятся недалекие

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

И невдомек оптимистичным, не затравленным тупыми практиками разработчикам, что решение build or buy принято не в их пользу именно из-за их низкой эффективности, инфантильности и непредсказуемости. Видал я и такое не раз.

что решение build or buy принято не в их пользу именно из-за их низкой эффективности, инфантильности и непредсказуемости.

Бгг, становится веселее :)
Ну то есть по твоему самые эффективные софтверные продукты созданы суперэффективным аутсорсом под предводительством прокси-владельцев продукта и менеджером вооружённым PMBook?

Я, вроде бы, этого нигде не написал. Что я написал — что очень часто, в успешных продуктовых компаниях, 80% людей не делает ничего полезного. И иногда уходят в аутсорс, потому что никто не может сказать, а сколько же займет усилий/денег/времени сделать внутри. При этом выбирают меньшее зло, которое хотя бы озвучит цену и с вероятностью, отличной от нуля, может в нее попасть.

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

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

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

Вот смотри, годовая з.п. это всего лишь 10-12 человек. И каждому в месяц по денке

инфантильности

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

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

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

Это потому что вы — суровый восточно-европеец) Шутка с долей шутки
Стукнулся в линкедин

А что вы делаете для того, чтобы минимизировать риск работы с такими людьми?

Если мы говорим о проектном менеджере, то минимизировать не особо выходит, работаешь с ресурс менеджментом плотно, но часто берешь, что дают. Итого 2 варианта:
— работаешь с людьми и их функциональными руководителями, чтобы улучшить ситуацию;
— принимаешь все как есть, работаешь с фактом как ограничением/риском на проекте.

У обоих подходов есть свои плюсы и минусы.

никто не берёт обязательств

Обовязки чудово беруться якщо працівник напряму зацікавлений в успіху фічі/релізу/проекту/контори.
А от як його в цьому зацікавити, це вже питання менеджменту. Можна мотивувати опціонами, акціями, фючерсами, преміями у випадку успіх або навпаки штрафами у випадку провалу або ж якусь софтскілову пісню завести в стилі «дайош пятілєтку за год» і т.д.
По дефолту кожен найманий працівник відповідає лише за таску в джирі яка на ньому висить, якщо не озвучено іншого.
Написане стосується всіх форм ІТ контор.

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

Мое утверждение касалось того факта, что в аутсорсинге, из-за бизнес-модели, такие обязательства существуют.

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

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

Эта ветка сильно отклонилась от темы статьи, на самом деле.

Это ты не работал в продуктовых конторах, наверное. Рассказываю популярно: у работы есть сроки. Часто вообще не понятно как её делать потому, что не ясно что имел ввиду вышестоящий менеджер, но сроки есть и они очень жёсткие — приурочены к какой то выставке, например. Но это не значит, что я буду в продукте работать овертайм без компенсации.

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

Вы точно говорите сейчас о продуктовых *технологических* компаниях? Потому что когда говорят «продукт», обычно имеют в виду не компании типа «Наша Ряба» и их заграничные аналоги, у которых есть незрелый айти-отдел, педалящий сайт, а компании, у которых основной продукт — это цифра. MacPaw, Grammarly, Spotify, Booking и т.д. Там все нормально с планированием.

Ещё не стоит грести под термин «продукт» стартапы, педалящие MVP: там понятно, что планирование крайне условное — «успеть к зиме».

Объективно, единственное, за счёт чего аутсорсинг может выдавать более качественные процессы и даже техническую экспертизу — это масштабы компании. Например, когда аутсорсеру размером 3000 человек отдают разработку от продуктовой компании размером 30 человек.

Но тут обратная сторона — обмазанный процессами аутсорсер может убить динамику развития продукта, которому как раз нужен более гибкий и креативный стиль компании на 30 человек. Такое я тоже видел, когда работал в аутсорсерах. (Уточню, тут речь не о стартапе, а о маленьком цифровом продукте, который давно на рынке, но должен бороться с конкурентами за миллениалов).

А еще есть такая штука, что даже если тебе нужно напедалить сайт с двумя прогерами, то аутсорсер сверху к ним добавить менеджера — у них же процессы такие, какого-то эйчара, который будет приходить каждый месяц с тестами и ретеншенами и остальными «процессами» в компании, которые не нужны ни заказчику, ни самим программистам.
На мой взгляд аутсорсинг хорошо подходит только для одного случая — когда есть необходимость саппортить легаси. Тогда назначается «линейный менеджер» — передающий задачи из саппорта и других отделов, и следит чтобы аутсорсер не совсем наглел со счетами за работу. Всё.
Я не то, чтобы против аутсорса, им пользуются — значит он кому-то нужен, хотя и далеко не всегда это хорошее решение. Особенно когда речь идет про разработку инновационных продуктов, в условиях неизвестности и высокой динамики.
Аутстаффинг кстати, гораздо лучше в таком случае, но тоже имеет ряд существенных проблем.

Основная проблема аутстафа — это когда человек туда пришел из аутсорса :)) с унаследованным мышлением и подходом.

Вы точно говорите сейчас о продуктовых *технологических* компаниях?

да, я говорил о, по-вашему, компаниях с цифровыми продуктами.

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

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

И ребята, разумеется, не могут подорвать веру начальства в себя каким-то отказом посидеть до 10 вечера над срочной поставкой клиенту.

Олени.

Не всегда. Все-таки, рынок не такой уж рынок кандидата иногда, как принято считать.

Это смотря кто ты есть. Если синьор-помидор, за принятие оффера чего только не делают

Я уже ответил тебе выше, мы с тобой с абсолютно разных сторон смотрим на вопрос. Не все люди входят в топ-5% отрасли.

Не все люди входят в топ-5% отрасли.

Та какой там топ 5, с понтом я туда вхожу :)

Всегда. Есть достаточно немного причин овертаймить бесплатно, и «вера начальства в тебя» к ним не относится.

По-моему, тут одна причина: экономия.

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

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

Підписатись на коментарі