Как правило, у компании по дОбыче - IT выделена в отдельное ЮЛ. Работать в самых "токсичных" "Big IT" после "Heavy Digital" как в детский сад ходить. Этика труда в "Heavy Digital" по моему мнению отсутсвует.
"Heavy Digital" - в 99% ненормированный рабочий день, где вам очень ясно объяснят что по ТК это как привлечение к переработкам не только после рабочего дня, но и до.
"Heavy Digital" - имеет смысл если какая-то большая тема и есть реальная перспектива. Но приготовьтесь работать по 60 - 100 часов в неделю сразу и скорей всего только в офисе. Конечно и компенсация должна быть достойна.
"Heavy Digital" - была прописана в трудовом договоре годовая премия и прозраные механимзы её получения. В "Big IT" - не была прописана, формально могли не платить, в 2020 году для многих коллег из "Big IT" это был сюрприз.
Добрый день!
Очень хотелось бы увидеть третью часть с подробным описанием, как и что делал ваш друг :)
Первые две части были отличным вступлением.
А в целом то, что не хватает полномочий — это норма для менеджеров проектов.
В таком случае можно сделать так:
1. Коммит от нач. отделов по срокам его подчинённых. Можно и перед заказчиком.
Это справедливо — разделять ответственность с владельцем ресурсов. Часто нач. отделов не беспокоит, чем его подчинённые заняты если не прилетает эскалаций и «все тихо».
2. Разбивка задачи на более мелкие с расстановкой промежуточных вех и коммиты под них от исполнителей.
Работа занимает всё отведённое на неё время. (с) Паркинсон.
Проваливают строки = эскалация в мягкой форме, пытаетесь договориться о SLA и за чей счёт дальше гуляем. Далее по ситуации.
3. Понять на сколько интересен проект исполнителям, если не интересен, то попробовать изменить на тех, кому интересен.
Казалось бы, банально, но часто рядовых гребцов даже не спрашивают, что они хотят и кто бы их мог заменить.
Из «софт» составляющей:
1. Налаживать рабочие отношения с нач. отделами.
2. Перенимать авторитет заказчика и заинтересованных лиц в проекте (если он — авторитет есть).
3. Налаживать рабочие отношения с исполнителями.
Менее формально артефакты PMI (PMBoK) можно составить так:
Устав проекта = договорённости с заинтересованными лицами и исполнителями, можно устно и в почте подкрепить договорённости: как, кто и что будет делать для проекта.
План управления проектом = аналогично как с уставом, можно на берегу или в процессе договориться с членами команд:
1) Что делать если заказчик меняет скоуп проекта.
2) Что делать если исполнитель ошибся с оценкой.
3) Что делать если исполнитель не выполнил согласованные работы в срок.
и т.п.
Два артефакта могут по ходу изменяться или наполняться новыми договорённостями, это не отлитые в бетон вещи.
Всё достаточно банально и не претендую на полноту, но сила в простых вещах.
Приношу Вам извинения, лучше ознакомился с Вашей деятельностью. Вы человек достойный, мой "подкол" был неуместный.
Работал в "Big IT" и в "Heavy Digital".
Как правило, у компании по дОбыче - IT выделена в отдельное ЮЛ.
Работать в самых "токсичных" "Big IT" после "Heavy Digital" как в детский сад ходить.
Этика труда в "Heavy Digital" по моему мнению отсутсвует.
"Heavy Digital" - в 99% ненормированный рабочий день, где вам очень ясно объяснят что по ТК это как привлечение к переработкам не только после рабочего дня, но и до.
"Heavy Digital" - имеет смысл если какая-то большая тема и есть реальная перспектива. Но приготовьтесь работать по 60 - 100 часов в неделю сразу и скорей всего только в офисе. Конечно и компенсация должна быть достойна.
"Heavy Digital" - была прописана в трудовом договоре годовая премия и прозраные механимзы её получения. В "Big IT" - не была прописана, формально могли не платить, в 2020 году для многих коллег из "Big IT" это был сюрприз.
(c) Наркоман Павлик
Могли бы уехать, уехали. Нужны ли там эффективные менеджеры?
Если бы пост написал обычный рядовой сотрудник одно дело, м.б. Сошло за альтруизм или наивность.
В РФ у ТОП менеджмента - это роскошь. Продавать "помощь" со своим интересом - обыденный ход.
То что Вы хотите кому-то помочь, кроме себя этим постом, кто в это поверит?
Валера, настало твоё время!
Очень хотелось бы увидеть третью часть с подробным описанием, как и что делал ваш друг :)
Первые две части были отличным вступлением.
А в целом то, что не хватает полномочий — это норма для менеджеров проектов.
В таком случае можно сделать так:
1. Коммит от нач. отделов по срокам его подчинённых. Можно и перед заказчиком.
Это справедливо — разделять ответственность с владельцем ресурсов. Часто нач. отделов не беспокоит, чем его подчинённые заняты если не прилетает эскалаций и «все тихо».
2. Разбивка задачи на более мелкие с расстановкой промежуточных вех и коммиты под них от исполнителей.
Работа занимает всё отведённое на неё время. (с) Паркинсон.
Проваливают строки = эскалация в мягкой форме, пытаетесь договориться о SLA и за чей счёт дальше гуляем. Далее по ситуации.
3. Понять на сколько интересен проект исполнителям, если не интересен, то попробовать изменить на тех, кому интересен.
Казалось бы, банально, но часто рядовых гребцов даже не спрашивают, что они хотят и кто бы их мог заменить.
Из «софт» составляющей:
1. Налаживать рабочие отношения с нач. отделами.
2. Перенимать авторитет заказчика и заинтересованных лиц в проекте (если он — авторитет есть).
3. Налаживать рабочие отношения с исполнителями.
Менее формально артефакты PMI (PMBoK) можно составить так:
Устав проекта = договорённости с заинтересованными лицами и исполнителями, можно устно и в почте подкрепить договорённости: как, кто и что будет делать для проекта.
План управления проектом = аналогично как с уставом, можно на берегу или в процессе договориться с членами команд:
1) Что делать если заказчик меняет скоуп проекта.
2) Что делать если исполнитель ошибся с оценкой.
3) Что делать если исполнитель не выполнил согласованные работы в срок.
и т.п.
Два артефакта могут по ходу изменяться или наполняться новыми договорённостями, это не отлитые в бетон вещи.
Всё достаточно банально и не претендую на полноту, но сила в простых вещах.