Путь овертаймов. Часть 2
Эта ситуация стала для меня отличной иллюстрацией многих аспектов во взаимоотношениях Заказчик-Исполнитель. Предыдущий слайдкаст показал точку зрения “умного Заказчика” а сейчас я попытаюсь посмотреть на проблему с точки зрения команды и руководителей.
Команда
Самой простой в этой ситуации будет точка зрения команды. Ребята будут задавать себе простые вопросы, на которые сложно ответить:
1. «Почему я должен работать столько времени без выходных?» и «Что я получу в конце? Будут ли мои заслуги оценены по достоинству?».
2. Хватит ли мне сил «дотянуть» до конца этого марафона?
3. Примет ли моя семья тот факт, что меня нет дома?
А правильно ли я делаю, что вкалываю сейчас а не ищу новую работу? Окупятся ли мои усилия? Нужно ли оставаться работать в этой команде?
Вывод команды: Если проект на самом деле дал мне многое: развитие, карьеру, хороший коллектив и так далее, то какой-то уровень “перегрузки” будет приемлем. Еще больший уровень переработок будет приемлемым, если я получу какие-то преимущества после его окончания: очень солидную премию, повышение зарплаты или продвижение в карьере. Если нет ни первого ни второго, то пора собирать вещи, так как я (как представитель команды) ничего от этого не выиграю.
Большой руководитель
Давайте попробуем посмотреть объективно со стороны более высокого руководителя (например руководителя программы):
1. Сейчас мы теряем прибыль:
- Оплачиваем дополнительную работу в овертаймы. И это еще хорошо, если Заказчик платит двойной тариф, а если одинарный или полуторный, то прибыльность страдает. Как остаться в рамках бюджета?
- Делаем неоправданные инвестиции: Заказываем новое оборудование/тестовые сервера/платформы/свой_вариант, чтобы ускорить сдачу.
- Оплачиваем «дополнительные» расходы: пиццы, тим-билдинги и т.д.
2. В будущем мы потеряем прибыль:
- Нужно в конце проекта выплатить премии сотрудникам, иначе «не поймут». Просто оплаты овертаймов не хватит.
- После сдачи проекта многие из команды придут за повышением зарплаты и должности. Хватит ли у меня должностей для повышений и бюджета?
- Некачественный продукт (а мы это доказали) станет причиной недовольства Заказчика. А значит, у него появятся аргументы, чтобы просить скидки и уступки (а даже 5% скидка превращается с большие деньги на протяжении времени работы с этим Заказчиком).
3. Добавляем большой риск проекта: Мы потенциально будем искать новых людей вместо «перегоревших» и «разочаровавшихся». А простая калькуляция показывает, что это очень дорого в условиях перегретого айтишного рынка: найти, отобрать, продать компанию, обучить… несколько месяцев работы (переводите в деньги сами. Если лень, то Саша и Слава (С) посчитали, что это как в среднем 20К у.е. на человека)
4. Текущий ПМ приобретет негативную репутацию в компании, и в следующих проектах будет очень мало желающих с ним работать.
Посмотрев на это со стороны руководителя я задам себе вопрос: Зачем мне такой «толковый» ПМ, от которого так много потерь?
Вывод со стороны более высокого руководителя: ПМ выбрал очень агресивную модель работы с командой. Овертаймы и риски по качеству окупятся только в двух вариантах: если нам “грозит” большая прибыль от последующих проектов с этим Заказчиком (будущая прибыль) или нам грозят большие убытки от провала проекта сейчас. В обоих случаях есть большой повод поговорить с ПМом и Заказчиком о том насколько реальны будущие прибыли и грозящие убытки. Но если овертаймы вызваны просто амбициями ПМа или у него нет хороших причин, то существование такого руководителя команды – неоправданно в данной компании.
Руководитель проекта
Чтобы быть объективным нужно послушать мнение того самого менеджера, против которого настроены все. Что же думает он:
1. Я работаю по 20 часов в день, 7 дней в неделю, вытаскивая их проект, а они еще и меня обвиняют!
2. Я уговорил/мотивировал всю команду работать так много, чтобы хоть как-то спасти проект, а все без толку? Этого никто не оценил?
3. Заказчик ожидает от нас релиза в эту дату! Чего тут непонятного? Нужно успевать.
4. Руководитель не помогает. Вместо того, чтобы поговорить с Заказчиком «ноет» о прибыльности и долгосрочной мотивации. Зачем он вообще нужен?
Зачем мне компания и Заказчик, которые не ценят мои усилия?!
Вывод со стороны руководителя проекта (ПМа): Я ожидаю, что мои усилия поддержат на всех уровнях и оценят. Если этого не происходит, то я становлюсь заложником ситуации, когда мои профессиональные обязанности обязывают меня идти на непопулярные меры, а за это я получаю выговоры и проявление недовольства со стороны окружающих. Наверное, были ошибки, которые я попытался исправить, но методы выбраны не лучшие.
Что делать?
Интересно выглядит тот факт, что ситуация-то патовая. Каждый участник недоволен и устал. Как же помочь проекту в такой ситуации? Овертаймы очевидно себя не оправдали, потому давайте посмотрим на другие варианты:
1. Добавить новых людей, чтобы забрать часть нагрузки
Хорошо выглядит только на бумаге. В любом проекте люди, которые присоединились в самом конце проекта чтобы «помочь», приносят больше хаоса и ошибок, чем пользы. Их нужно обучить, им нужно все настроить, нужно отвечать на глупые и не глупые вопросы, а это все занимает время тех людей, которые и так перегружены!
2. Заготовить много плюшек и правильно пообещать все команде
Правильно мотивировать ребят большим бонусом или повышением или другими мыслимыми способами. Нужно постоянно проводить с ними мотивационные беседы в стиле «счастье уже рядом». И те, кто на самом деле «доживут» до этого счастья сорвут джек-пот. Дотянут ли все до этого джек-пота или пойдут искать этот джек-пот где-то в другом месте? Вот только куда девать высокое руководство, которое и так обеспокоено маленькой прибылью. А сможет ли менеджер утвердить ТАКОЙ бонус, чтобы мотивировал?
3. Поговорить с Заказчиком об изменении плана
Нужно подготовится, тратить время и идти к Заказчику. Долго и упорно объяснять ему, что нужно что-то менять. В этот момент может донести ему аргументы «умного Заказчика» из слайдкаста истории. И если аргументы будут звучать убедительно (изначальная нереальность сроков, новая функциональность, изменяемые требования и т.д.), то есть шанс его переубедить и сдвинуть сроки или уменьшить объем работ. В худшем случае, руководитель потеряет несколько дней времени.
4. Уволиться!
А что, тоже вариант! Руководитель проекта тоже человек! Хотя в последнее утверждение не верит команда, которую он «подписал» на 50 дней без выходных :). Решит проблему «крайнего», так как все дружно свалят все на него. Отношения с Заказчиком это исправит на доли секунды, а потом прийдет озарение о том «что все равно кто-то же должен это делать»,
Наверняка есть еще варианты того, как выйти из этой ситуации. Пишите, в комментариях, будем разбирать…
P.S. Перечитал еще раз все комментарии и сделаю отдельное отступление про проекты модели “fixed price”. Как то все верят, что при такой модели овертаймы и потери исключительно со стороны компании-поставщика логичны. То есть если проект опаздывает, то овертаймы, дополнительные траты и все такое ложатся только на Исполнителя. Получается, что проект становится выигрышным только для Заказчика!
Я один такой (С) считаю, что даже такую ситуацию можно исправить? И что такую ситуацию нужно менять с целью приведения всего в модель win-win!
А еще есть хрупкие люди, которые долгих овертаймов не выдерживают как факт. И их нельзя мотивировать “карьрой, деньгами и джек-потами”. И нередко это важные люди для команды…
На мой взгляд анализ ничего не добавил к части 1.
Суммируя: предположим что овертаймы это плохо и не выгодно, из этого вытекает логичный вывод что овертаймы это плохо и невыгодно
Почему же ничего не поменялось?
Мне кажется основным добавлением стала объяснение ситуации, когда овертаймы имеют смысл для команды, для ПМа и его руководителя.
А вывод так и остался выводом
Создается ощущение, что рассматривается ситуация, в которой команда не имела никакого отношения к оценке трудоемкости, а значит и сроков. Что сроки спустили сверху.
Если это так – то все описанное верно и поспорить с этим трудно.
Если нет – то команда сама подписалась на заявленные сроки и значит ответственность за то, что случились овертаймы, лежит и на команде тоже.
Касаемо модели “fixed price”. Лично я не считаю что овертаймы и потери в такой модели логичны. Не логичны, но если была проведена неверная оценка трудоемкости – то это целиком и полностью риск поставщика (Исполнителя). Можно ли ситуацию исправить? С госами – сложно. Практика показывает, что на изменение цены (при неверной оценке трудоемкости) они не идут. Максимум о чем можно договориться – это о сдвиге сроков без изменения цены (в этом случае хотя бы овертаймов можно будет избежать).
А я не говорю о том, что это просто. Я вот набил столько шишек уже в переговорах, что на лбу не осталось живого места
Работа ПМа как раз в том, чтобы минимизировать/оптимизировать внешнее давление. В любой модели…
А я хочу вот это прокомментировать:
1. «Почему я должен работать столько времени без выходных?» и «Что я получу в конце? Будут ли мои заслуги оценены по достоинству?».
Для многих это вполен приемлемая ситуация. Для них работа это клуб по интересам. Дома им скучно, всепоглощающего хобби нет, хоби одно – работа.
2. Хватит ли мне сил «дотянуть» до конца этого марафона?
А так ли много раьотает команда? Или половину времени слоняется по офису, точит лясы за чаем-кофе, перекуривает за обсуждением тенденций в современной геополитике, обсуждает достижения фототехники и мобильных приложений, читает блоги про управление проектами и пр.
Может отсюд аи овертаймы?
3. Примет ли моя семья тот факт, что меня нет дома?
Многие наоборот рады воспользоваться поводом сбежать из семьи от бытовых забот и поднадоевшей супруги.
Если не идеализировать работников, то надо учитывать и это.
P.S. Сергей, сделайте же что-то с формой отправик сообщений. Очень нервирует писать по два раза. Пишешь, отправляешь, и оказывается, что всё ушло в пустоту, потому что “надо было раскрыть ссылочку и там вписать циферки”…
PaSol
Какое-то у вас недоверительное отношение к команде. Это “типа они сами буратины такие…”. У меня в командах ребята, которые не показывают результат – уходят (с небольшой помощью). А если вы не доверяете им, то как же можно с ними делать хоть что-то?
P.S. Да если бы я знал, что нужно и где пофиксить, то даже подучил бы php, чтобы пофиксить, но баг не репродьюстся у меня. Если не сложно, напиши плиз на мыло steps-to-repro.
Сергей, вы же не конкретезируете, что “речь сейчас пойдёт про такую-то вот команду, которую я знаю лично, дела там обстоят так-то и так-то”.
Вы обсуждаете некий обобщённый случай, а я говорю о том, что нельзя отметать и другие точки зрения.
Что не всегда семья и свободное время превыше всего. Что не всегда команда напряшается так, как об этом рассказывает. что не всегда овертаймы из-за ПМ, сейла, закачика и т.д., а иногда и из-за самой команды.
P.S. Половины слов не понял, о чём Вы это?
>> Я один такой (С) считаю, что даже такую ситуацию можно
>> исправить? И что такую ситуацию нужно менять с целью
>> приведения всего в модель win-win!
fixed price контракт без внятной части про risk sharing – личные половые трудности сейла, которые это допустил.
и это основная проблема – продавать мы толком не умеем, т.к. блин взять и прочитать PMBoK, где это всё описано, а потом доносить до клиента, нам облом.
так и живём.
а вин-вин (в краткосрочной перспективе) часто невозможен. Особенно в FP проектах, т.к. они ж не от хорошей жизни случаются, а потому что у заказчика есть N денег. И если проект не доделать, то они _просто пропадут_, т.к. галимый проект не начнёт генерировать прибыль\привлекать инвесторов.
так что остаётся делать за свой счёт и надеяться на лонг-терм вин-вин, когда клиент таки получит свои инвестиции и про нас не забудет.
СОТОНА
А почему, если прошляпил сейл, то отдувается вся команда? Почему нет обратной связи и ПМ не может изменить даты/объем работ даже в FP?
Ну сложное это дело, да, но что-то же нужно делать! И Заказчики тоже не идиоты, если у них стоит выбор “выжить или нет”, то вероятно положится на бажный продукт – глупо. Они пропадут уже после того, как вам заплатят… где логика?
отдувается команда, потому что такова жисть
я не говорил, что ПМ не может. ПМ вообще всемогущь, если работает, а не пинает…
а вот случаи есть, когда вин-вин таки невозможен. и чаще, чем следовало-бы. потому что есть куча проектов заведомо провальных (дезмарши по терминологии Йордона), но за которые взялись (хелло сейлы) .
Овертаймы – это самое простое лобовое решение, если нет желания/умения решить этот вопрос по-другому (передоговориться с заказчиком, выбить дополнительные ресурсы, как написал Сергей).
Передоговоренность или выбивание ресурсов – это несомненно более сложно и требует бОльших знаний/умений/опыта и времени. Ну и стандартно: попу ж нужно подорвать и что-то делать, а не просто собрать всех на 5-минутку и объявить об овертаймах.
Если все остальное не сработало и остались только овертаймы – то это тоже выход, хоть после этого и нужно делать lessons learned, чтобы не повторить этого дальше. Если же овертаймы принимаются как первое и единственное решение – то это очень плохо и говорит, чаще всего, о недостаточной квалификации ПМ-а.
ИМХО.
Овертаймы – это самое простое лобовое решение!!! Согласен на 100%.
Наша некометентность и нежелание что-то менять (как бы это не звучало странно) как раз причина того, что нам легче “напрячь” ребят, которые прогнуться с большей вероятностью, чем исправлять свои же косяки и идти к тем “ребятам”, которые будут сложно “прогибаться”
“Наша некометентность и нежелание что-то менять (как бы это не звучало странно) как раз причина того, что нам легче “напрячь” ребят, которые прогнуться с большей вероятностью, чем исправлять свои же косяки и идти к тем “ребятам”, которые будут сложно “прогибаться””
ну зачем обобщать? “нам” – это кому?
@pmwoman
Мы – это руководители проектов. Я еще не стал тренером и “по-привычке” причисляю себя к ПМам
Про FP. Ситуация такова, что в таких проектах почти нереально ошибки планирования “переложить” на Заказчика, да и наверное неправильно это…
Ну да ладно, незачем лезть в “истоки” (ведь причин то может быть очень-очень много). По ситуации – наилучший путь, естественно, договариватья с Заказчиком. Но его тоже надо мотивировать на принятие решений (уверен, что в подавляющем большистве случаев даже для “умного” Заказчика приведенные в ч.1 доводы не будут весомым аргументом… о причинах могу написать отдельно…).
Так что надо внимательно спрогнозиновать возможные негативные экономические последствия (доп. затраты) и предложить Заказчику “пряник”, который обойдется нам дешевле (доп.сервис, доп.функционал и т.д.)
Сергей, понятно что это работа РМа, я ж не отрицаю этого (я как раз тот самый РМ который регулярно общается на эту тему с ГОСами).
Вот только есть такие гос-заказчики, с которыми это совершенно бесполезно.
Ну и ответственность команды, которая (в моем случае) не принудительно подписалась под сроками, тоже сбрасывать со счетов нельзя.
Я не знаю работал ли ты когда-нибудь с гос структурами, особенно с такими где ничего никому не нужно и каждый пытается прикрыть себя, а на результат в итоге наплевать.
В целом если резюмировать – ты прав, но жизнь гораздо разнообразнее, и нередки ситуации когда никакого искусства переговоров не хватит, чтобы сделать из простого заказчика “умного”.
У огромного количества заказчиков НЕ СТОИТ ВООБЩЕ выбор “выжить или нет”. Это я про госы. Они не пропадут после того как заплатят, даже если продукт бажный.
а ещё часто с заказчиком такой разговор:
- Нам надо чтобы вы сделали до ндцаттого-декабря.
- Это не реально…
- У вас нет компетенций и ресурсов? Ребята из-за угла обещали это сделать даже раньше. Мы тогда у них закажем…
И может действительно это сделать нереально и ребята из-за угла облажаются (а может действительно у вас нет компетенций и ресурсов), и может быть заказчик поумнев вернётся к вам, но хватит ли у вас подкожного жирка, чтобы его дождаться?
Ага, а если согласитесь, то хватит ли у вас подкожного жирка это сделать?
Прием “А я сделаю там, где дешевле” – примитивный и широко известный прием на переговорах, чтобы вас “отжать”. Если вы сами подвигаетесь, то Заказчик считает это своей победой!
Я если уверен, что дешевле сделать нельзя говорю нет… это сложно, но потом не бывает такой ситуации, которую мы разбираем.
Ага, а если согласитесь, то хватит ли у вас подкожного жирка это сделать
А тут применяется уже другой приём. Ввязаться, а потмо уже отдавливать заказчика на уменьшение требований, точнее на их конкретизацию ( в начале-то зачастую требования расплывчаты…).
Тут же понмиаете ещё какой момент, нам, например, часто приходится делать то, что мы никогда раньше не делали и ни сейл, ни ПМ, ни команда не могут точно сказать сколько времени это займёт. Но надо договориться на конкретные сроки и деньги – по другому нет у заказчика возможнсот платить.
А там как повезёт, или ничего не всплывёт и мы со сроками угадали, или будем заказчика отжимать или овертаймить… Фортуна…
Давайте тогда быть до конца честными. 90% гос заказов попадают к избранным Исполнителям. Там управление проектами идет по своим законам, когда нет смысла “клевать глаз”.
Это совсем другой мир, и переговоры о доп. бюджете и переносе сроков пойдут явно не на уровне руководителя проектов. В наших странах не принято наделять ПМа такими полномочиями для гос. проектов.
Да, это не уровень РМа. Но клевать глаз, печень и другие органы все равно будут и именно РМу :)))
> 1. «Почему я должен работать столько времени без выходных?» и «Что я получу в конце? Будут ли мои заслуги оценены по достоинству?».
Для многих это вполен приемлемая ситуация. Для них работа это клуб по интересам. Дома им скучно, всепоглощающего хобби нет, хоби одно – работа.
2. Хватит ли мне сил «дотянуть» до конца этого марафона?
А так ли много раьотает команда? Или половину времени слоняется по офису, точит лясы за чаем-кофе, перекуривает за обсуждением тенденций в современной геополитике, обсуждает достижения фототехники и мобильных приложений, читает блоги про управление проектами и пр.
Может отсюд аи овертаймы?
3. Примет ли моя семья тот факт, что меня нет дома?
Многие наоборот рады воспользоваться поводом сбежать из семьи от бытовых забот и поднадоевшей супруги.
Если не идеализировать работников, то надо учитывать и это.
Вот-вот. И это тоже наблюдалось в той компании, у которой стилем работы были авралы.
> Правильно мотивировать ребят большим бонусом или повышением или другими мыслимыми способами. Нужно постоянно проводить с ними мотивационные беседы в стиле «счастье уже рядом». И те, кто на самом деле «доживут» до этого счастья сорвут джек-пот.
А руководитель компании (как и некоторые менеджеры) владел этим искусством в совершенстве.
Он, несмотря на свою загруженность (тоже работал по 12 часов в день и постоянно пропадал в командировках), находил время чтобы с каждым поговорить лично раз в 1-2 месяца и рассказать про светлые перспективы и блестящее будущее, которое ждет работника, если он еще чуть-чуть поднапряжется.
Хотел бы я работать с таким умным Большим руководителем.
Мне чаще попадались такие, которым было наплевать на сотрудников по принципу “уйдут эти, наймем других”.
Сергей.. тогда странно что вы к себе применяете фразу “Наша некометентность и нежелание что-то менять” ((((
Если я начну думать, что все делаю только правильно, то мне место в “дурке”, а не в управлении проектами.
Я ошибался, ошибаюсь и буду это делать, так как я “всего лишь человек и живу первый раз” (С).
Ни в коем случае не оправдываю переработки, по умолчанию считаю такие прецеденты ошибками менеджмента. Однако некоторые фрагменты публикации представляются притягиванием аргументов за уши; некоторые другие – аргументы скорее против неправильных людей, нежели против переработок. Прокомментирую один раздел.
>>Большой руководитель
>>1. Сейчас мы теряем прибыль:
>>Делаем неоправданные инвестиции: Заказываем новое оборудование/тестовые сервера/платформы/свой_вариант, чтобы ускорить сдачу.
Всякое, конечно, может быть. Но необходимость в покупке чего-либо, отличного от дополнительных человеческих ресурсов, при переработках – вряд ли такой уж частый случай. В моей практике такого точно не было.
>>Оплачиваем «дополнительные» расходы: пиццы, тим-билдинги и т.д.
Ну, пицца – ещё куда ни шло; может быть. Но тим-билдинги во время переработок – извините. При правильной постановке процесса сама по себе переработка становится лучше всяких тим-билдингов. На которые как бы и время-то тратить некогда.
>>2. В будущем мы потеряем прибыль:
>>Нужно в конце проекта выплатить премии сотрудникам, иначе «не поймут». Просто оплаты овертаймов не хватит.
С какого это, извините? Тут уже напрашивается вывод, сделанный чуть позже по ходу статьи: менеджера, приведшего к такой ситуации, надо… пожурить. Только этот вывод, вообще говоря, не против переработок, а против дурного менеджмента.
>>После сдачи проекта многие из команды придут за повышением зарплаты и должности. Хватит ли у меня должностей для повышений и бюджета?
Неадекватных сотрудников более низких уровней – тоже надо того… пожурить.
>>Некачественный продукт (а мы это доказали) станет причиной недовольства Заказчика. А значит, у него появятся аргументы, чтобы просить скидки и уступки (а даже 5% скидка превращается с большие деньги на протяжении времени работы с этим Заказчиком).
Слабый Большой руководитель? Не нужно быть семи пядей во лбу, чтобы объяснить заказчику причины, по которым он получил недостаточно качественный продукт (что, кстати, вовсе и не обязательно при переработках), и как заказчику нужно сдерживать свои аппетиты, чтобы получать оптимум. Конечно, нужна определённая жилка, чтобы суметь общаться с заказчиком в таких условиях, но на то у нас тут и Большой руководитель.
>>3. Добавляем большой риск проекта: Мы потенциально будем искать новых людей вместо «перегоревших» и «разочаровавшихся».
Ну да, это опять про менеджмент, который не сумел. Если говорить точнее, про менеджмент, который беспокоился лишь о собственном тыле, а потому и у подчинённых погасил потенциальный азарт и вызвал заботу про свои зады. Но ПМ – он же не всегда такой.
Что мы в результате имеем? Простое предложение: давайте пофиксим ПМа, который без достаточных причин приводит свою команду к переработкам, при этом не умеет хотя бы представить эти переработки в правильном свете. (Хотя правильнее было бы допускать только те переработки, которые позволяет совесть, и тогда представлять эту ситуацию в каком-то конкретном свете не потребовалось бы – достаточно было бы просто быть честным со своей командой.) Другими словами, дело не в переработках, а в менеджере.
Да я и не спорю
Только пофиксить менеджера, когда переработки уже набрали обороты – НЕ ПОМОЖЕТ. Потому что новый не войдет быстро, а кто-то из команды его не заменит, так как и так все заняты.
Поменять менеджера нужно только после того, как дотащат проект. Может одним из вариантов станет подключение “большого Босса”, если он владеет достаточным пониманием деталей проекта.
Поэтому “финт ушами” с заменой руководителя – еще более рисковая операция. Очень она похожа не любимую присказку наших программеров: “Тут проще переписать все, чем разобраться. Я за 2 дня сделаю”… К чему приводит такое поведение мы все знаем… переписывали…
“Только пофиксить менеджера, когда переработки уже набрали обороты – НЕ ПОМОЖЕТ. Потому что новый не войдет быстро, а кто-то из команды его не заменит, так как и так все заняты.”
Ну не знаю. Между плохим и хорошим менеджером разница, пожалуй, существенней чем между плохим и хорошим инженером, в смысле влияния на проект.
Я думаю менять ПМа стоит – видела успешные примеры. Только конечно не в самый разгар такой ситуации, а уже после. Думаю если проект долгий, и ребята идут на такие овертаймы, видимо работают на нем давно, и уже имеют определенный уровень самостоятельности, так что смену ПМа переживут.
Да и подключение дополнительных сил для разработки тоже стоит рассматривать как реальный вариант. Как правило не все инженерные задачи требуют супер-экспертизы.
Катя
Да, да и еще раз да тому, что ПМа нужно менять после этого. Быстро этого сделать нельзя. Даже если ребята самостоятельные, то если убрать ПМа, то на них упадет дополнительная нагрузка и непонятные обязанности, ведь хоть что-то ПМ делал.
Подключение доп. людей – вопрос. очень это непросто, особенно если сложная область и большой проект. Время “входа в проект” будет исчислятся от нескольких дней до недель (установка, закачка кода, разворачивание доп. окружения, узнать подход в написании кода\тестов и т.д.). Денег вы потратите больш, а вот какой будет ROI?
Сергей,
затронутый вопрос актуален для многих. Но на мой взгляд обсуждать овертаймы как явление, не самое эффективное занятие. Все понимают овертайм, – это плохо, – но это результат, а не причина. Я бы рассматривал причины, которые приводят овертаймам:
- ошибочная оценка.
- условия контракта.
- события в ходе проекта (изменения, низкое качество)
- неэффективное планирование
- дефицит ресурсов
- т.д. (нет цели перечислить все).
Далее эти причины можно классифицировать и на основе этого рассматривать когда овертайм недопустим, а когда допустим, но вопрос в “дозе”.
Спасибо, очень трезвый комментарий
Причин может быть много, вопрос самый главный – ЧТО ДЕЛАТЬ!?
Ведь на вопрос “кто виноват” вроде уже ответили