My Story: «Путь овертаймов»

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

Путь овертаймов from anotherpm on Vimeo.

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

В случае обсуждения перегрузки с командой, было ли что-то более разумное, чем стандартное «Нам нужно это доделать к этой дате!»?

Nov 9th, 2011
  1. Ни колай
    Nov 9th, 2011 at 21:35 | #1

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

  2. Nov 9th, 2011 at 21:44 | #2

    Ни колай
    Вроде бы вывод из видео о том, что путь овертаймов – неправильный. И “умный Заказчик” это усиленно доказывает.
    Может быть вам повезло, но овертаймы – довольно распространенный метод для многих менеджеров, который нужно искоренять.

    Кстати, если вы владаете методологией – поделитесь. Буду только рад увидеть Ваш разбор истории на страницах блога. Писать можно сюда: story@anotherpm.com Да и другие ребята оценят!

  3. Sergey.M
    Nov 9th, 2011 at 21:59 | #3

    Интересно было послушать, спасибо.

    Ни колай :
    Путь овертайма это уже неправильное решение, и это не стандартное решение, оно в корне неверное уже.

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

    У меня был подобный кейс. Может не 7 недель овертаймов, но 2-3 для всей команды было точно.. Я считаю, что это было оправдано. Команда сделала “косяк” (неверное планирование, архитектура, недостаточная коммуникация), сделали поспешные выводы, подписались под дату. Работали на заказчика, в которого инвестировали деньги “кошельки” (с ними подписанный кровный договор на поставку фич). Доказывать и убеждать в том, что овертаймы это лишнее было не уместным по причине того, что начались бы судебные тяжбы и все бы от этого проиграли (кроме “кошельков”). Испортили бы жизнь всем (по сути косяк был наш и нашего заказчика, на стороне которого также был девелопмент). Мы убойно потрудились, но дальше уже осторожничали и продумывали все гораздо серьезней и эффективней. Это был урок.
    Поэтому я считаю, что длинный овертайм один раз иногда возможен. Главное правильно объяснить команде почему так произошло ну и пообещать какую-то плюшку, которую обязательно выполнить.

    • Ни колай
      Nov 10th, 2011 at 09:14 | #4

      неверное планирование, архитектура, недостаточная коммуникация – Это прямые обязанности менеджера проекта. Пока большинство PM в Росии похожи на секретарш с большой ЗП. PM должен 90 % своего времени проводить в коммуникациях и организовывать ход работ получая экспертные оценки с менеджерским запасом и строя план проекта с учетом оисков. Овертаймы же происходят из-за того, что все эскалируется на экспертов в то время, как PM сушит вафли в интернете, а не делает свою работу в грамотном планировании и митигировании рисков на этапе планирования, а не этапе реализация решая авральные работы.

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

  4. Борис
    Nov 9th, 2011 at 22:13 | #5

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

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

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

    Тут важно, что по факту очень много зависело от того, что будет именно в этот день и именно в этом билде, к тому же и исполнителем и заказчиком были мы. Так что решение было оправданным. ИМХО.

    Но это почти синтетический случай :)

  5. AlexanderN
    Nov 9th, 2011 at 23:59 | #6

    Sergey.M :
    Главное правильно объяснить команде почему так произошло ну и пообещать какую-то плюшку, которую обязательно выполнить.

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

  6. Nov 10th, 2011 at 03:40 | #7

    Полностью согласен с тем что усталость накапливается и это очень плохо влияет на следующий проект (

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

  7. Элла
    Nov 10th, 2011 at 07:59 | #8

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

    • Nov 10th, 2011 at 12:54 | #9

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

      Такой себе парадокс…

  8. Nov 10th, 2011 at 08:17 | #10

    Если РМ-у не все-равно с какой командой заходить в следующий проект/итерацию, то ему стоит научиться говорить “нет” заказчику, руководству.

  9. Nov 10th, 2011 at 08:54 | #11

    Нельзя не согласиться.

    Но есть одно “но”. Сильный акцент сделан на Заказчика и на его умение быть “умным” и не допускать ситуации “предпочитаю не обращать внимание”. В аутсортинге, наверное, это справедливо.
    Но есть немало и таких проектов, в которых Заказчик данной информацией не может (а часто и не должен) обладать.

    Я считаю, что “беда овертаймов” – это прежде всего “косяк” менеджерского состава (причем всех – от продавцов до рук.проектов и тех.лидов).
    Поэтому намного эффективнее не “работать в направлении поиска умных Заказчиков”, а готовить свой персонал не допускать таких ситуаций (функции рук.проекта) или умело их “разруливать” с Заказчиком (продавцы, клиент-менеджеры).
    Ну и плюс готовить самого Заказчика. Умного найти трудно, а вот сделать (научить) Заказчика быть таковым – вполне реально.

    Кстати, чтобы не было все так грустно. Лично у меня есть положительный опыт овертаймов (правда чуть меньше – порядка 5 недель). Отличительная особенность: интересный проект; новые технологии; новые “высоты”; молодая и амбициозная команда. Никто не сгорел, да и “пряников” особых не было.

    P.S. Да, кстати, а почему “плюшки”, а не “пряники” :) ?

  10. Stas
    Nov 10th, 2011 at 09:41 | #12

    Хороший разбор ситуации!

    Работал я 3,5 года в такой компании, где стиль работы был постоянные авралы, правда после авральной работы по 2-3 месяца, 2-3 месяца все были на раслабоне: ничего не делалось, потом цикл повторялся.

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

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

    Все взаимосвязано.

    • Nov 10th, 2011 at 12:52 | #13

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

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

  11. Nov 10th, 2011 at 10:03 | #14

    Вы в основном говорите о ситуации когда оплата проект time & material. В этом случае много, о чём вы говорите про умного заказчика верно.
    Но если проект фикс прайс, то заказчику по большому счёту на всё это плевать.
    Сделано будет то, что пообещали (иначе не заплатим), сколько бы вы там не работали, мы о цене уже договорились…

    Ох, ну а по поводу искать умного заказчика… По моим ощущениям (которые никак не могут претендовать на абсолютность), вход к новому заказчику редко связан с компетенцией исполнителя, как правило всё строится на наличии неформальных отношений с представителями заказчика.

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

  12. Nov 10th, 2011 at 10:06 | #15

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

    тут мне сразу очевиден момент – нафига было делать итерацию в 14 недель? длинная итерация потянула ошибки в планировании…

    • Nov 10th, 2011 at 12:49 | #16

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

      Анализ все таки вынудите меня написать более подробным :)

  13. Nov 10th, 2011 at 11:59 | #17

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

    По оси X откладываем экономическую обоснованность, по шкале от 0 до 1 для разработчика, по оси Y для заказчика.
    01 11
    00 10

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

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

    01 – у разработчика выгода есть, заказчик имеет право поступать как ему удобно, а не вести сложные переговоры с менеджерами

    10 – у разработчика выгоды нет, а у заказчика есть, это тот редкий случай, когда заказчику нужно становиться “умным”

    Спасибо

    • Nov 10th, 2011 at 12:47 | #18

      Красиво, только как любая матрица имеет свой недостаток. Все упрощенное.

      Ситуации типа “11″ нередко заканчиваются “10, 01, 00″ только потому, что все считают, что и так хорошо… прижмемся и “посидим на попе ровно”.

  14. Nov 10th, 2011 at 13:15 | #19

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

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

    В диаграмме я перепутал…
    10 11
    00 01

  15. Nov 10th, 2011 at 13:30 | #20

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

    Да, это эксплуатация человека человеком :) но это бизнес.

  16. Nikolay Nikolenko
    Nov 10th, 2011 at 13:31 | #21

    (Сергей Бережной – автору не удалось запостить, пощу от себя под его именем)
    Все очень правильно рассказано и выводы достаточно логичные. Однако есть один (вероятно – больше) не учтенный, но у меня – часто встречающийся, момент – команда _сама_хочет_работать_overtime! Вот с этим бороться практически невозможно. У меня – не получается. В приказном порядке заставляли не работать? Так технически – это практически не запретить. Из отпуска, в выходной, ночью они же сами подключаются, отвечают на письма, готовят отчеты и другие документы. Фишка в том, что я ценю то, что они делают, но я не прошу об этом и даже пытаюсь запрещать. Как быть в такой ситуации?

  17. Ответил статьей – в комментарий бы не влезло. :) Спасибо за интересную тему для обсуждения! http://xpinjection.com/2011/11/10/do-we-need-overtimes/

  18. Yura
    Nov 10th, 2011 at 15:21 | #23

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

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

  19. Valeryi
    Nov 10th, 2011 at 20:21 | #24

    У меня после просмотра в голове сразу возник извечный русский вопрос: Кто же виноват?
    Менеджер, в том что он не способен обосновать реальные сроки заказчику и грамотно распланировать работы?
    Или разработчик, который видит что все так плохо, понимает что не успеет, но сидит и молча перерабатывает, а не идет разбираться со своим менеджером, вплоть до того, что в особо клинических случаях, просто увольняется?

    Ну и дополнение из собственного опыта: сейчас я разработчик, работаю в такой компании где переработки это почти норма, они есть у 80-90 процентов персонала (проектировщиков, дизайнеров, разработчиков, тестировщиков). В среднем стандартная неделя это примерно 50 часов. При этом, внимание, за переработки отдельно ничего не платят! И этот постулат лежит в основе корпоративной культуры достаточно успешной компании которой уже 20 лет. Да текучка есть, но не настолько большая какую можно было бы ожидать в таких случаях. Создается впечатление что народ просто втягивается в такой режим, и он становится для них привычным. Как такое можно понять?

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

  20. Valeryi
    Nov 10th, 2011 at 20:25 | #25

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

  21. Nov 10th, 2011 at 20:33 | #26

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

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

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

  22. Nov 10th, 2011 at 20:35 | #27

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

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

  23. Не стоит сравнивать интеллектуальный труд с физическим. И не приплетайте механика или строителя. Стоитель смену на работе закончил и дальше хоть все развалится. Так и грузчики и продавцы. Кроме тех, кто работает на свою прибыль. Так вот и в IT – дайте процент акций и посмотрите как работать будут. Тогда есть мотивация. А так какого черта работать по 10 часов, если отпахал на полную 8 часов? Непонятно. А проблема с оплатой за результат в том, что результат слишком неосязаем. “Классность” работы программиста тяжело померять. Да и изначально как раз так и платили за результат – fixed price контракты. Сделайте и мы заплатим. И что из этого вышло мы тоже все видели.

    А про корпоративную культуру вообще молчу. Назовите хоть одну компанию, которая будет париться в аутсорсе за своих сотрудников и не выкидывать их с работы, если нет проектов, платя из своего кармана. Или может есть такие, которые компенсацию за 3-6 месяцев выплачивают при увольнении? Или льготные кредиты под 5% дают? Так о какой корпоративной культуре вы говорите? О той, которая заставляет вас верить в мифическую цель и работать как папа Карло? Очень выгодная, скажу вам, корпоративная культура. :)

  24. Stas
    Nov 11th, 2011 at 15:51 | #30

    > Создается впечатление что народ просто втягивается в такой режим, и он становится для них привычным. Как такое можно понять?

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

    > Причем, хотелось бы заметить, что большая часть народа в этой компании это молодые в диапозоне 20-35. Т.е. в принципе они могут найти работу в другой компании где будет спокойней, а не как описано выше.

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

  25. Andrey
    Nov 11th, 2011 at 22:04 | #31

    Сергей, Вы все верно изложили. Но у меня до конца видео был один вопрос – почему мы говорим про умного Заказчика, а не умного ПМ-а. И только вконце Вы затронули этот аспект. (Заранее сорри, возможно я что-то не внимательно смотрел). Все что Вы описали – это классика cхемы T&M которая во многом всех нас извратила. Если мы говорим про Fixe Price, то Заказчик вообще не вмешивается в темы по мотивации, увольнения, перегрузки, передачи знаний. Все эти риски на менеджере и компании. И в этом случаи действительно Заказчик не причем. Ну пришел “Умный ПМ” на переговоры с Заказчиком – пообещал дату за стоимость Релиза и все. Просто если это Fixed Price per Release или вообще на весь проект – то ПМ не сможет так легко за счет конторы включать овертаймы, ведь тогда бюджет будет overrun. А значит, его начальник за это не погладит по голове.
    Другой аспект – это Business Case для Заказчика. Бывают случаи, что какой-то конкретный релиз и дата его сдачи, на вес золота. Тоесть, если не успеваешь сделать до этой даты, то Заказчик своим контр агентам платит такую сумму неустойки, что равна стоимости всего проекта+ все овертаймы*10. Поэтому для Заказчика это означает или сделал, или все, что сделал можно выкинуть в ведро для мусора. Это как билет на самолет, ты его не можешь использовать на следующий день после вылета, даже если он стоит очень дорого.
    Так что вывод очень простой, что ПМ должен быть умный и в рамках T&M проектов и тем более в рамках Fixed price.

  26. Dec 17th, 2011 at 14:16 | #32

    Полностью согласен с вами Андрей, очень часто встречается что проблема также и в ПМ-е. Если человек не успевает то вполне нормально что он работает в овертайм.

  27. Sergey
    Apr 21st, 2015 at 01:10 | #33

    Очень крутое видео :)

Leave a comment