Гибкие подходы и практики не панацея в проектом управлении, все есть яд, если применять не по делу. Можно постоянно наблюдать как те-же практики или фреймворки (привет SCRUM) применяют в областях где неопределеность это что-то что случается раз в 10 лет, но при этом там настойчиво пихают хайповые практики не понимая для что они решают в их контексте.
Это я к чему, а к тому что в тотм же ИТ общий уровень руководителей как в прочим и инженеров не высок, требуются квалифицированные сотрудники, а приходится латать дыры тем что найдётся, а сколько проблем можно было бы решить просто грамотным управлением и возможно бы не подталнтколо когда из утюга кричат про Agile..
Карта больше похожа просто на набор всего что может пригодится когда либо, особо я бы уделил внимание IT скилам, но алгоритмы, osi, вы забыли только SIEM и вот все что связано с ИБ и полный комплект.
Если обратиться к PMI и прочим серьёзным организациям работающими с менеджерами мирового уровня там вы такого не найдёте, безусловно менеджер должен знать домпнную область, но не надо ему давать то что ему не нужно, он нанесёт больше вреда чем пользы...
ДД, прочёл пост, спс за информацию, концепция описанная заинтересовала, но большая беда с английским, нет ли на просторах рунета перевода документации, можно конечно скачать и ковыряться, но хотелось бы прочесть
Автору спасибо за статью, такой вопрос, интересна веб разработка, даже знаю какой стек нужен, но изучение нативного JS даётся безумно тяжело даже основы, когда встаёт даже простая задача я +- понимаю логическую цепочку решения её, но описать кодом не могу, но из за упорства перечитываю основы языка уже раз 20, но не всегда помогает даже пустяки как кажется бывает трудно понят, назревает вопрос как определить что это не моё, зная себя я могу и год и больше положить на это, но если результата не будет, затраченное время никто не вернёт, т.е есть до фига упорства, но как понять
Совершенно не понятно о чем статья, к тому же как мне кажется даже у автора нет понимания роли менеджера/руководителя проекта
Гибкие подходы и практики не панацея в проектом управлении, все есть яд, если применять не по делу. Можно постоянно наблюдать как те-же практики или фреймворки (привет SCRUM) применяют в областях где неопределеность это что-то что случается раз в 10 лет, но при этом там настойчиво пихают хайповые практики не понимая для что они решают в их контексте.
Это я к чему, а к тому что в тотм же ИТ общий уровень руководителей как в прочим и инженеров не высок, требуются квалифицированные сотрудники, а приходится латать дыры тем что найдётся, а сколько проблем можно было бы решить просто грамотным управлением и возможно бы не подталнтколо когда из утюга кричат про Agile..
Карта больше похожа просто на набор всего что может пригодится когда либо, особо я бы уделил внимание IT скилам, но алгоритмы, osi, вы забыли только SIEM и вот все что связано с ИБ и полный комплект.
Если обратиться к PMI и прочим серьёзным организациям работающими с менеджерами мирового уровня там вы такого не найдёте, безусловно менеджер должен знать домпнную область, но не надо ему давать то что ему не нужно, он нанесёт больше вреда чем пользы...
ДД, прочёл пост, спс за информацию, концепция описанная заинтересовала, но большая беда с английским, нет ли на просторах рунета перевода документации, можно конечно скачать и ковыряться, но хотелось бы прочесть
Автору спасибо за статью, такой вопрос, интересна веб разработка, даже знаю какой стек нужен, но изучение нативного JS даётся безумно тяжело даже основы, когда встаёт даже простая задача я +- понимаю логическую цепочку решения её, но описать кодом не могу, но из за упорства перечитываю основы языка уже раз 20, но не всегда помогает даже пустяки как кажется бывает трудно понят, назревает вопрос как определить что это не моё, зная себя я могу и год и больше положить на это, но если результата не будет, затраченное время никто не вернёт, т.е есть до фига упорства, но как понять