По законодательству работодатели обязаны регулярно индексировать зп (не только бюджетные организации, но и коммерческие), тут лишь вопрос к насколько адекватному работодателю вы пришли работать
Какой нахрен проект, вы описываете стандартную работу тимлида. Никакой реальный проект вы этим не вытянете, максимум - сделаете минимальное командообразование для обработки задач на потоке. А чтобы вытягивать проект - нужны фреймворки управления проектами, где управление командой - лишь 1 из 7 групп процессов
Все как будто бы и правильно, так сказать "по книжке", но в реальности слишком много лишней навесухи. ИМХО, спасает грамотное составление вопросов для технического собеседования на конкретную позицию. Если вы изначально строите на нем валидные кейсы - здесь и можно будет оценить опыт кандидата в наиболее распространенных ситуациях именно для вас. Ну и вишенка на торте: если спустя 3 месяца вы обнаруживаете, что у сотрудника что-то не так - вероятно вы забили огромный болт на процессы онбординга и не выделили ему бадди
В наиболее продвинутых крупных IT-компаниях серьезно следят за конфликтом интересов, поэтому кум-сват-брат это скорее про второ-/третьесортные компании
Госуху в пример не беру, она всегда строилась в своей собственной резервации отдельно от рыночной коммерции
Достаточно защитного бампера на любом адекватном не-200граммовом смартфоне начиная с медиум-сегмента, айфоны всегда были хрупкими
У меня в свое время 4s из рук упал на линолеум с высоты меньше полуметра, как итог откололся кусок угла в пару миллиметров толщиной, с тех пор зарекся брать айфоны учитывая какой я рукожоп
Если уж и хотите продавать свой материал, то не нужно это делать на примере сотрудника, который достаточно простые проекты называет "сложными" и способен тащить без мигрени лишь один проект
Статья выглядит как выдранный из контекста кусок. Какое имеет отношение улучшение процессов к OKR по компании в целом? О каких именно процессах идет речь - бизнесовых или административных? Где базовые цифры - насколько быстрее "залетает" OKR если настроен процесс непрерывных изменений? Где ссылка на какое-то подтверждающее тезисы исследование? Причем здесь вообще выращивание линейных руководителей?
Про масштабы смешно - если я сейчас открою Jira своей компании (российской), то увижу там тысяч 40 пользователей, сотни пространств и сотни дашбордов. Лично я своими руками настраивал пространство для нескольких сотен пользователей и все необходимые им дашборды, и на это ушло пару недель, а не 8 месяцев :)
Ну и вишенка на торте: Jira - это не ИСУП, а таск-трекер. Да, в Jira можно строить ганты и чекать загруженность команд по ресурсам, но это не делает из Jira полноценный ИСУП:)
Вы все верно говорите, нужны и те и те, и вместо того чтобы лезть в область управления проектами (попытка определения целей и критериев успешности проекта), тимлиду бы сконцентрироваться на описанных вами делах
Например, интервьюирование бизнеса на предмет целей и критериев успешности - тимлиду это должно поставляться в готовом виде от ПМа. Также как и требования, собранные бизнес-аналитиком. Также как и концепт архитектуры, проработанный архитектором
Вы понимаете разницу между руководством процесса разработки и руководством проекта? Тимлид - это одна из ролей в проекте, которая действительно подразумевает управление процессом разработки. Однако процесс разработки не включает в себя интервьюирование заказчиков проекта, сбор требований, бизнес-анализ, проработку архитектуры и т.д. - это функции совсем других ролей в проекте. Теоретически и тимлид их может выполнять, но только на крохотных проектах
Таск-трекер и СУП - очень близкие, зачастую спаренные в одном инструменты, но все же разные. Ваша статья - это обзор таск-трекеров, а не СУПов, что бы там не говорили вендоры в своих рекламных материалах. Да и судя по содержанию статьи вы скорее подыскивали инструмент для тимлида, а не для проджект-менеджера
Вы видели как выглядит Microsoft Project? Это самый что ни на есть классический СУП. А где ж вы там основу из канбана увидели?
Как много всем чего-то кажется, и как мало (ни одного не нашел) случаев, когда кто-то из-за этой функции реально потерял деньги. Казаться может что угодно, но время показывает реальность
А что, есть сеньоры, готовые работать за 3к? Не каждый мидл согласится на такие копейки
По законодательству работодатели обязаны регулярно индексировать зп (не только бюджетные организации, но и коммерческие), тут лишь вопрос к насколько адекватному работодателю вы пришли работать
"Вытянет любой проект"
Какой нахрен проект, вы описываете стандартную работу тимлида. Никакой реальный проект вы этим не вытянете, максимум - сделаете минимальное командообразование для обработки задач на потоке. А чтобы вытягивать проект - нужны фреймворки управления проектами, где управление командой - лишь 1 из 7 групп процессов
Все как будто бы и правильно, так сказать "по книжке", но в реальности слишком много лишней навесухи. ИМХО, спасает грамотное составление вопросов для технического собеседования на конкретную позицию. Если вы изначально строите на нем валидные кейсы - здесь и можно будет оценить опыт кандидата в наиболее распространенных ситуациях именно для вас. Ну и вишенка на торте: если спустя 3 месяца вы обнаруживаете, что у сотрудника что-то не так - вероятно вы забили огромный болт на процессы онбординга и не выделили ему бадди
Чего только не сделают чтобы протолкнуть свой MAX. Лично у меня от этого лишь больше отторжения к "отечественному мессенджеру"
Да тут пол хабра этих пассажиров и прыгунковых недомиддлов, вот и минусят
В наиболее продвинутых крупных IT-компаниях серьезно следят за конфликтом интересов, поэтому кум-сват-брат это скорее про второ-/третьесортные компании
Госуху в пример не беру, она всегда строилась в своей собственной резервации отдельно от рыночной коммерции
Достаточно защитного бампера на любом адекватном не-200граммовом смартфоне начиная с медиум-сегмента, айфоны всегда были хрупкими
У меня в свое время 4s из рук упал на линолеум с высоты меньше полуметра, как итог откололся кусок угла в пару миллиметров толщиной, с тех пор зарекся брать айфоны учитывая какой я рукожоп
Точнее будет "старшеклассница"
Просьба к автору: раскрывайте смысл используемых аббревиатур. Я до конца статьи не понимал идет ли речь о продакт менеджере или о прожект менеджере
И опять реклама минервасофт
Если уж и хотите продавать свой материал, то не нужно это делать на примере сотрудника, который достаточно простые проекты называет "сложными" и способен тащить без мигрени лишь один проект
Статья выглядит как выдранный из контекста кусок. Какое имеет отношение улучшение процессов к OKR по компании в целом? О каких именно процессах идет речь - бизнесовых или административных? Где базовые цифры - насколько быстрее "залетает" OKR если настроен процесс непрерывных изменений? Где ссылка на какое-то подтверждающее тезисы исследование? Причем здесь вообще выращивание линейных руководителей?
Про масштабы смешно - если я сейчас открою Jira своей компании (российской), то увижу там тысяч 40 пользователей, сотни пространств и сотни дашбордов. Лично я своими руками настраивал пространство для нескольких сотен пользователей и все необходимые им дашборды, и на это ушло пару недель, а не 8 месяцев :)
Ну и вишенка на торте: Jira - это не ИСУП, а таск-трекер. Да, в Jira можно строить ганты и чекать загруженность команд по ресурсам, но это не делает из Jira полноценный ИСУП:)
Вы все верно говорите, нужны и те и те, и вместо того чтобы лезть в область управления проектами (попытка определения целей и критериев успешности проекта), тимлиду бы сконцентрироваться на описанных вами делах
Например, интервьюирование бизнеса на предмет целей и критериев успешности - тимлиду это должно поставляться в готовом виде от ПМа. Также как и требования, собранные бизнес-аналитиком. Также как и концепт архитектуры, проработанный архитектором
Вы понимаете разницу между руководством процесса разработки и руководством проекта? Тимлид - это одна из ролей в проекте, которая действительно подразумевает управление процессом разработки. Однако процесс разработки не включает в себя интервьюирование заказчиков проекта, сбор требований, бизнес-анализ, проработку архитектуры и т.д. - это функции совсем других ролей в проекте. Теоретически и тимлид их может выполнять, но только на крохотных проектах
Таск-трекер и СУП - очень близкие, зачастую спаренные в одном инструменты, но все же разные. Ваша статья - это обзор таск-трекеров, а не СУПов, что бы там не говорили вендоры в своих рекламных материалах. Да и судя по содержанию статьи вы скорее подыскивали инструмент для тимлида, а не для проджект-менеджера
Вы видели как выглядит Microsoft Project? Это самый что ни на есть классический СУП. А где ж вы там основу из канбана увидели?
"Я" - это кто? Какой уровень? Какого масштаба и сложности проекты? От этого зависит, для кого статья может быть релевантна
Где PMBoK?
Жизнь всех наладится, если тимлиды поймут наконец, что управление проектом - это работа проджекта, а не тимлида
Как много всем чего-то кажется, и как мало (ни одного не нашел) случаев, когда кто-то из-за этой функции реально потерял деньги. Казаться может что угодно, но время показывает реальность