Проблема овертайма

[Amalgam]

Негосударственные пенсионные фонды(и государственные тоже), есть они или нет их, как-то совершенно не портят мне жизнь. Поэтому думаю, что вопрос интересен с точки зрения практической риторики, но не идет ни в какое сравнение с проблемами овертайма, например.
Вопрос к гуру ERP консалтинга: в чем причины постоянного овертайма? Чтобы не быть абстрактным приведу собственный пример: сейчас я работаю в консалтинговой компании N, занимающейся внедрением Axapta. Идет уже второй проект. И каждый проект - страшные овертаймы, когда сотрудники днюют и ночуют на проекте, когда вик-энды пускаются вразнос легко, когда эти овертаймы считаются НОРМАЛЬНОЙ работой на проекте.
Сейлзы виноваты? Указали нереальные сроки?
До этого я работал в софверных компаниях девелопером. Дедлайны нормальное являние, сроки релизов и прочие даты проставлены, сейлз менеджеры - те же самые сейлз менеджеры, с теми же самыми стратегиями продаж. Бывают овертаймы. Но. Во-первых, овертаймы редки и не считаются нормальным явлением. Во-вторых каждый период овертайма оговаривается специально, и к сотрудникам выражается просьба поработать сверх обычного рабочего времени.
При этом происходят поставки, идет нормальное общение с клиентами, и система им нужна не в принципе, а реально, сейчас.
Так же работают филд - инженеры в своих командировках.

Я нарисовал идиллию? Вовсе нет. Почему же в области ERP не так? Почему сроки внедрения столь важны и при этом столь нереальны?

Почему компания, годами обходившаяся без нормальной ERP вдруг хочет внедрить ее НЕПРЕМЕННО за пару месяцев? Ведь страдает и качество.

[mazzy]

Цитата:

Изначально опубликовано Amalgam
в чем причины постоянного овертайма?

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

С другой стороны, романтика, новые острые ощущения, мир полон красок, каждый может внести что-то новое, перевернуть мир.

Устаканится. Все это пройдет и здесь тоже станет скушно и рутинно.

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

[komar]

Да и сами системы еще.... того....не того..... Да и коллектив у внедренцев в основном молодой, считается нормальным работать круглые сутки.
Еще - неумение планировать работу, когда овертаймы закладываются в план. Ну нету в России профессии "внедренец", никто и планировать работу по-человечески не умеет. Вот профессия "программист" есть.

[Eduard]

Цитата:

Изначально опубликовано Amalgam
в чем причины постоянного овертайма?. [/B]

У меня несколько ответов на этот вопрос.

Ответ первый - не заблуждайтесь, overitime - это не специфика ERP-консалтинга, это специфика консалтинга вообще, или, если точнее, консалтинга, использующего проектные подходы. Такие же переработки и в бизнес-консалтинге, и в финансовом консалтинге.

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

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

С другой стороны, в хорошо организованном проекте существуют два-три ключевых момента, когда вероятность поработать overtime высока. Так что в подобных проектах реально вы работаете поздними вечерами/ночами 2-3 недели из полугода...

[komar]

Цитата:

Изначально опубликовано Eduard
Ответ первый - не заблуждайтесь, overitime - это не специфика ERP-консалтинга, это специфика консалтинга вообще, или, если точнее, консалтинга, использующего проектные подходы. Такие же переработки и в бизнес-консалтинге, и в финансовом консалтинге.

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

[Eduard]

Цитата:

Изначально опубликовано komar


Нет, это не специфика консалтинга, это специфика продаж

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

[mazzy]

Цитата:

Изначально опубликовано Eduard
Скорее, опыт позволяет иначе к ним относится .

Можно и так сказать.

[Amalgam]

Цитата:

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

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

Цитата:

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

Я так понимаю, данное определение не только консалтинговым проектам свойственно? Или только, тогда почему?

Цитата:

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

привыкнуть к плохому? ((

[Amalgam]

Цитата:

Изначально опубликовано Eduard


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

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

[ТРЕНЕР]

Вопрос: если прогнозируемую длительность проекта умножить на два, времени все равно не хватит? а на полтора - хватит или нет ?
Можно использовать например такой повышающий коэффициент :
<b>K = 1,1 + A x 0,10 + B x 0,05 + (2 - C) x 0,20</b>
где :
A - число уровней иерархии в организации-клиенте, через которые проходят управленческие решения (начиная с менеджеров среднего звена)
B - то же самое для организации-внедренца
C - соотношение числа человек в проектных группах клиента / внедренцев
Пример
У клиента:
- старший менеджер, начальник отдела, зам.директора, директор/фин.директор = 4
- проектная группа: 1 бух.+2 менеджера+2ИТ = 5
У внедренцев:
- рук.проекта, нач.службы внедрения, директор = 3
- проектная группа: 1 рук.проекта+2 конс.+1прогр. = 4
Итого:
К = 1,1 + 4 х 0,10 + 3 х 0,05 + (2 - 5 / 4) х 0,2 = 1,1 + 0,4 + 0,15 + 0,15 = 1,8
Смело увеличивайте первоначальные сроки в 1,8 раза.

[komar]

В аудиторских конторах продает фактически только один человек - директор (партнер, менеджер, у кого как называется). Ему не интересно следить за тем, кто сколько перерабатывает, ему нужно получить контракт. В консалтинговых же фирмах (тех, которые занимаются внедрением) понятие продавца таки есть, и опять-таки есть менеджер, которому интересно получить контракт любой ценой. Именно поэтому ошибки только в сторону занижения сроков.
Когда на продажи привлекают реальных консультантов, руководителей проектов - сроки могут оказаться даже несколько завышенными. Только потом придет некто и скажет, что у конкурентов вот цена меньше - результат предсказуем.
Свойственно не только консалтинговым проектам, но и любым другим, которые оцениваются не по реальным срокам, а по политическим "хотелкам".
Два примера - Петербург, участок метро Лесная-Пл. Мужества - уже года 3 плавает под водой, причина известна - хотели построить к "красной" дате.
Более успешный пример - московское метро - строилось в ударные сроки ценой круглосуточной работы (т.е. имеем запланированный овертайм), к тому же бесплатной.
Принцип понятен - сначала кто-то большой хочет чего-то большого и светлого, потом гробится куча народу, чтобы это сделать. Вот и вся "специфика"...

[Борисыч]

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

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

[komar]

Цитата:

Изначально опубликовано ТРЕНЕР
Вопрос: если прогнозируемую длительность проекта умножить на два, времени все равно не хватит? а на полтора - хватит или нет ?
Можно использовать например такой повышающий коэффициент :
<b>K = 1,1 + A x 0,10 + B x 0,05 + (2 - C) x 0,20</b>

А поправка на кривизну системы? А на мероприятия по преодолению сопротивления юзеров на местах? А территориальная распределенность?

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

[ТРЕНЕР]

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

[Alex_K]

Цитата:

Изначально опубликовано Борисыч

Идея пиццы за счет фирмы в случае переработок мне понравилась

Хи-хи... Кое-где есть просто бесплатный ужин. И так каждый день...

[Amalgam]

Цитата:

Изначально опубликовано Борисыч
Только что прочел Йордона "Путь камикадзе. Руководство по выживанию в безнадежных проектах".
Там проблема переработок в софт-индустрии досконально обсосана.

В той же книге есть еще и рецепты выживания.

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

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

Вероятно потому, что книга завязана именно на существовании безнадежных/ужасных/кошмарных проектов (хотя оптимизм автора говорит о том, что все они такие).


Интересно сейлзы, менеджеры и прочие ее читают? Или только те кто делают проекты понимают все что там написано?

[komar]

Читают. Я вот всем даю почитать, и менеджерам тоже.
Говорят, сильно пессимистическая.