С каментом про детали согласен: чем точнее - тем лучше. А вот про "главное" скажу так: в моем опыте (сужу и по себе и по тем, с кем я работал и по теории от тех, у кого учился сам) человек, приходя в разговором уже имеет в голове вывод. Оно же - главное.
Но всегда вначале начинает излагать факты, потом выводы, потом - итог.
Все что я прошу: просто начинай с итога. А остальное потом.
в очень общем виде с вами невозможно не согласиться - так и есть.
статья о том, что для определенной выборки собеседников - а именно руководителей менеджера и руководителей от бизнеса, с которыми менеджеру приходится работать - стиль общий и они все ценят три вышеприведенные критерия. По крайней мере, если это касается РФ, США, Европы, Австралии и Канады.
Мой опыт говорит о том, что руководители в этих странах начинают зевать или вообще не встречаются, если говорить с ними иначе.
Она про то, что русская модель управления - когда матом в лицо говорят все, что думают - в других странах воспринимается как токсичная.
И я про это не говорил. Мои тезисы работают во всем англоязычном пространстве. Вот за Китай и Азию ничего не скажу - там не работал и там явно что-то другое.
У меня было похожее на вашу историю, и с тех пор когда мне англосаксы (условные канеш) говорят "все хорошо, и надо немного улучшить" - это для меня очень серьезный сигнал. Просто они вежливые, это надо помнить.
Но им точно также надо говорить коротко, начинать с конца и говорить, что нужно, а не почему это невозможно.
Я в Европе (Швейцария и Голландия) вполне себе работал. Нормальный у меня подход для них: говори с конца, говори кратко и говори, что тебе надо, чтобы решить вопрос - вполне рабочая схема.
Вы видите иначе - расскажите, что не так. Все, что я пишу, основано на моем опыте. Я допускаю, что он может быть и другой, мне интересно услышать примеры, когда то, о чем я пишу, не работает.
Но только реальными примерами давайте. Тиньков - фиг с ним он далеко и это не личный опыт, тут согласен.
Не соглашусь. Речь идет не про место, где человек работает, а его отношение к работе и окружающим. Если вы выбрали место, где начальник кого-то саботирует и вместо работы играет в игры - вы его выбрали и зачем ныть, какой начальник козел?
не нравится место и шеф - попробуйте сменить. Не хочется менять? Тогда смысл ныть?
да ладно: 5% не отменяют 95%. Кросскультурным особенностям можно посвятить отдельную статью (верно, я работаю в американо-российской системе ценностей менеджмента и в азии не прокатит), но
сколько у нас (= читающих данную статью) компаний и менеджеров, которые работают с Азией? не более 5%
у меня просто нет опыта в этом дальше Казахстана
ну и кстати, опыть Тинькова. развивающего Plata показывает, что культурные особенности можно сглаживать, если цель интересная.
Любой руководитель с определенного уровня должен принимать решения быстро, делегируя часть ответственности своим сотрудникам-менеджерам.
Не будет ответственной команды под таким менеджером среднего звена - он всегда (да, категорично) будет по уши в операционке. Потому что не умеет делегировать.
Я категоричен не просто так: у меня опыта в айти больше 25 лет , из которых 20 - управленческий, и я много общался с СЕО и другими менеджерами. Везде одно и тоже: если не учить своих РП разбираться самостоятельно (да, через боль и их ошибки) - они не научатся, сколько не разжевывай.
Больше того, сами ребята менеджеры мне много раз признавались, что так было им больнее, но намного эффективнее. Пока начальник - папка, можно прятаться за его спиной бесконечно.
если речь про менеджеров, то, независимо от возраста, менеджер должен уметь говорить кратко, по существу и выделяя самое главное.
Не умеет - должен учиться.
На практике сам проверил: пока решаешь задачи за менеджеров, объясняешь им все по 10 раз - они не учатся. Учить это 1-2 раза объяснить а дальше спрашивать результат. А реально крутого даже учить особо не надо - сам потыкается и найдет самые эффективные пути (но таких очень мало)
Удивительно мало комментариев, статья то хорошая. Ясно что ребята себя продвигают, ну и ничего страшного.
По трендам наблюдаю тоже самое, кроме ИИшницы. Нифига она не способна ничего заменить в проектном управлении, кроме ведения протоколов встреч.
Даже тупая работа Администратора проектов по сведению таймшитов из джиры не автоматизируется через ИИ, там просто правильно надо выстроить процесс и убрать администратора, как факт.
Облака, фокус на людей (привет комментатору выше) и data driven управление - это то что нас ждет.
хороший пример непроработанной для начальника эскаляции) вы скажете "нет бюджета, иди еще думай" - и пошлете менеджера подумать еще раз, не тратя кучу времени на выслушивание обоснования. Что и есть экономия вашего (и его) времени.
В следующий раз он придет с другими вариантами, которые вам подойдут лучше, но начнет не с прелюдии а с того, о чем я писал отдельно: "есть проблема, есть такие то варианты решения, прошу вас выбрать".
Суть подхода не в правильной формулировки цели - про это есть отдельная статья (кстати, надо добавить ссылку). Суть в том, чтобы сразу сказать цель, чтобы собеседник выбрал сам: слушать дальше или нет.
Одобряю в той части, где про выделение критичного для заказчика и максимального встраивания в существующие процессы.
В статье мало данных по примеру: реально сказано только о добавлении одного шага в процесс обновления базы знаний. И это серьезно все? Если так, зачем про это сказано, если не так, то где же детали (
В частности, очень хорошее начало про РП, которые там уже 15 лет EPR внедряют с помощью Экселя и такой то матери. И как именно вы их уговорили переехать на ИСУП? или не уговорили? Ведь главный их аргумент - "вы не ускорите, а замедлите нам работу, дорого СЕО, имей ввиду, что теперь я буду тратить времени больше на соблюдение этих глупых правил" не так то просто побить )
Если вы руководитель PMO, предлагаю вам подумать о следующем: ваши сотрудники, которые загружены до предела и не имеют времени/желания на прокачивание смежных навыков, по сути не растут, могут чаще выгорать, теряются как только попадают в непривычные условия и надо сделать шаг влево-вправо от привычной конвы. Это точно в интересах вашей организации?)
Мне мои менеджеры в полном составе говорят "спасибо" за развитие. Я даже менторингом занялся из-за этого.
Я наверное сходу резковато сказал, так иногда словами выглядит. Реально я категорически ЗА развитие любого человека в рамках организации. Сам писал про это: взаимное развитие возможно только при совпадении целей организации и сотрудника (тут можно сделать ремарку, что далеко не все сотрудники осознаны, чтобы понимать свои цели на 1-3-5 лет, но фиг с ним).
Но есть нюанс. У меня правда много опыта, я очень много где работал и сам в роли РП и я знаю, какие навыки РП нужны, а какие нет. И для меня, как представителя компании, и для моих РП, которые хотят и готовы расти профессионально, важно развивать то, что нужно чаще. А это софтскиллы: умение работать с заказчиками и капризным бизнесом, умение работать в потоке задач, делегирование и прочие веселости.
И вот этому я учу своих на практике. А заодно учу ценить себя, выпихиваю в отпуск, чтобы не выгорели (потому что нафиг оно мне надо - искать хорошего РП с рынка долго и дорого) и так далее.
В этом списке есть навык РП быть аналитиком и разбираться в технике ровно настолько, чтобы иногда взять на себя отвествтенность за какое-то решение, предложенное командой (или хотябы просто понять изменения и уметь пояснить заказчикам при необходимости).
Но нет навыка разработки, так как все кейсы, когда это было надо (и приведенный выше вами) решался на уровне описания требований и постановки тикета разработчику.
Так-то, разумеется, веселится каждый так, как хочет. Я вот знаю CDTO очень большой компании, который на досуге балуется Питончиком, чтобы чувствовать себя "в строю" :)
Но к его работе отношения это, конечно, не имеет. Когда ему необходимы серьезные дашборды (а у него 10 тыс человек в организации), он зовет свое аналитическое управление, а то управление зовет подрядчиков, чтобы те подогнали данные для отчетности. То есть в реале оно вот так.
судя по описанию и вашему ответу, б) у вас есть, это ясно. но а) у вас пока что нет, а точнее, вы выковыриваете его из заявок, что , скорее всего, боль и место для оцифровки.
собственно это то о чем я говорил в п 1 выше: обычное ресурсное планирование в ИСУП решает такую проблему: вам, как линейному руководителю на доске будет видна планируемая загрузка аналитиков, исходя из 90-100% вероятных входящих проектов на полгода, будет виден перегруз и все что вам нужно.
Далее у вас будет (уже есть) фактическая утилизация. А далее вы будете более точно стучать по рукам вашим нерадивым РП, которые всегда бронируют больше, а списывают меньше, а вы за утилизацию отвечай ))
Согласен с вами, пока что больше крики на хайпе. Ну ясно, что помогает продажам: курсов по ИИ и b2b продажам всяких "умных алгоритмов".
Вот че мне кажется интересным, так это если в компании есть нормальные трекер и проектная системы, он может давать интересные аналитические срезы.
Но тут можно ответить, что если есть проектная система и трекер, мне обычный Power bi выдаст все что надо ))
С каментом про детали согласен: чем точнее - тем лучше. А вот про "главное" скажу так: в моем опыте (сужу и по себе и по тем, с кем я работал и по теории от тех, у кого учился сам) человек, приходя в разговором уже имеет в голове вывод. Оно же - главное.
Но всегда вначале начинает излагать факты, потом выводы, потом - итог.
Все что я прошу: просто начинай с итога. А остальное потом.
это вот как на скрине
в очень общем виде с вами невозможно не согласиться - так и есть.
статья о том, что для определенной выборки собеседников - а именно руководителей менеджера и руководителей от бизнеса, с которыми менеджеру приходится работать - стиль общий и они все ценят три вышеприведенные критерия. По крайней мере, если это касается РФ, США, Европы, Австралии и Канады.
Мой опыт говорит о том, что руководители в этих странах начинают зевать или вообще не встречаются, если говорить с ними иначе.
а у вас другая история, я считаю.
Она про то, что русская модель управления - когда матом в лицо говорят все, что думают - в других странах воспринимается как токсичная.
И я про это не говорил. Мои тезисы работают во всем англоязычном пространстве. Вот за Китай и Азию ничего не скажу - там не работал и там явно что-то другое.
У меня было похожее на вашу историю, и с тех пор когда мне англосаксы (условные канеш) говорят "все хорошо, и надо немного улучшить" - это для меня очень серьезный сигнал. Просто они вежливые, это надо помнить.
Но им точно также надо говорить коротко, начинать с конца и говорить, что нужно, а не почему это невозможно.
Конечно спорно :)
Я в Европе (Швейцария и Голландия) вполне себе работал. Нормальный у меня подход для них: говори с конца, говори кратко и говори, что тебе надо, чтобы решить вопрос - вполне рабочая схема.
Вы видите иначе - расскажите, что не так. Все, что я пишу, основано на моем опыте. Я допускаю, что он может быть и другой, мне интересно услышать примеры, когда то, о чем я пишу, не работает.
Но только реальными примерами давайте. Тиньков - фиг с ним он далеко и это не личный опыт, тут согласен.
Сочувствую этой истории, но это явно не имеет никакого отношения ни к статье ни к отрасли ИТ.
Не соглашусь. Речь идет не про место, где человек работает, а его отношение к работе и окружающим. Если вы выбрали место, где начальник кого-то саботирует и вместо работы играет в игры - вы его выбрали и зачем ныть, какой начальник козел?
не нравится место и шеф - попробуйте сменить. Не хочется менять? Тогда смысл ныть?
да ладно: 5% не отменяют 95%.
Кросскультурным особенностям можно посвятить отдельную статью (верно, я работаю в американо-российской системе ценностей менеджмента и в азии не прокатит), но
сколько у нас (= читающих данную статью) компаний и менеджеров, которые работают с Азией? не более 5%
у меня просто нет опыта в этом дальше Казахстана
ну и кстати, опыть Тинькова. развивающего Plata показывает, что культурные особенности можно сглаживать, если цель интересная.
Если уж вы предлагаете раскрыть карты - расскажите для начала, какое это имеет отношение к разговору о коммуникации и делегировании?
Мне просто любопытно.
Это без агрессии, просто я,
а) когда открываю карты, всегда готов пояснить что и зачем первым.
б) не считаю возраст определяющим фактором для руководителя (только если ему не 25, там другой механизм).
Любой руководитель с определенного уровня должен принимать решения быстро, делегируя часть ответственности своим сотрудникам-менеджерам.
Не будет ответственной команды под таким менеджером среднего звена - он всегда (да, категорично) будет по уши в операционке. Потому что не умеет делегировать.
Я категоричен не просто так: у меня опыта в айти больше 25 лет , из которых 20 - управленческий, и я много общался с СЕО и другими менеджерами. Везде одно и тоже: если не учить своих РП разбираться самостоятельно (да, через боль и их ошибки) - они не научатся, сколько не разжевывай.
Больше того, сами ребята менеджеры мне много раз признавались, что так было им больнее, но намного эффективнее. Пока начальник - папка, можно прятаться за его спиной бесконечно.
когда речь про исполнителей - разговор один.
если речь про менеджеров, то, независимо от возраста, менеджер должен уметь говорить кратко, по существу и выделяя самое главное.
Не умеет - должен учиться.
На практике сам проверил: пока решаешь задачи за менеджеров, объясняешь им все по 10 раз - они не учатся. Учить это 1-2 раза объяснить а дальше спрашивать результат. А реально крутого даже учить особо не надо - сам потыкается и найдет самые эффективные пути (но таких очень мало)
Удивительно мало комментариев, статья то хорошая. Ясно что ребята себя продвигают, ну и ничего страшного.
По трендам наблюдаю тоже самое, кроме ИИшницы. Нифига она не способна ничего заменить в проектном управлении, кроме ведения протоколов встреч.
Даже тупая работа Администратора проектов по сведению таймшитов из джиры не автоматизируется через ИИ, там просто правильно надо выстроить процесс и убрать администратора, как факт.
Облака, фокус на людей (привет комментатору выше) и data driven управление - это то что нас ждет.
хороший пример непроработанной для начальника эскаляции) вы скажете "нет бюджета, иди еще думай" - и пошлете менеджера подумать еще раз, не тратя кучу времени на выслушивание обоснования. Что и есть экономия вашего (и его) времени.
В следующий раз он придет с другими вариантами, которые вам подойдут лучше, но начнет не с прелюдии а с того, о чем я писал отдельно: "есть проблема, есть такие то варианты решения, прошу вас выбрать".
Суть подхода не в правильной формулировки цели - про это есть отдельная статья (кстати, надо добавить ссылку). Суть в том, чтобы сразу сказать цель, чтобы собеседник выбрал сам: слушать дальше или нет.
Вы на своем примере тезис подтвердили )
Прикольно, спасибо. То есть каитен можно +- использовать в роли трекера.
Есть только большие вопросы к донастройке в нем рабочих правил вида:
на одном разработчике не должно быть более 2х задач в работе одновременно
счетчики возвратов (для расчета эффективности разработки)
и тп. Так как это проприетарный софт, наверняка невозможно, тогда как JIRA & Yt это позволяют.
Ну и без Гантта и ресурсов - это только у вас часть работы.
И да - контроль узких мест, контроль метрик. Короче, путь хороший, вы прошли где то процентов 30 :)
Одобряю в той части, где про выделение критичного для заказчика и максимального встраивания в существующие процессы.
В статье мало данных по примеру: реально сказано только о добавлении одного шага в процесс обновления базы знаний. И это серьезно все? Если так, зачем про это сказано, если не так, то где же детали (
В частности, очень хорошее начало про РП, которые там уже 15 лет EPR внедряют с помощью Экселя и такой то матери. И как именно вы их уговорили переехать на ИСУП? или не уговорили? Ведь главный их аргумент - "вы не ускорите, а замедлите нам работу, дорого СЕО, имей ввиду, что теперь я буду тратить времени больше на соблюдение этих глупых правил" не так то просто побить )
да, тут может быть прикольно, тем более, что можно чат гпт подогнать в помощь)
Мне мои менеджеры в полном составе говорят "спасибо" за развитие. Я даже менторингом занялся из-за этого.
Я наверное сходу резковато сказал, так иногда словами выглядит. Реально я категорически ЗА развитие любого человека в рамках организации. Сам писал про это: взаимное развитие возможно только при совпадении целей организации и сотрудника (тут можно сделать ремарку, что далеко не все сотрудники осознаны, чтобы понимать свои цели на 1-3-5 лет, но фиг с ним).
Но есть нюанс. У меня правда много опыта, я очень много где работал и сам в роли РП и я знаю, какие навыки РП нужны, а какие нет. И для меня, как представителя компании, и для моих РП, которые хотят и готовы расти профессионально, важно развивать то, что нужно чаще. А это софтскиллы: умение работать с заказчиками и капризным бизнесом, умение работать в потоке задач, делегирование и прочие веселости.
И вот этому я учу своих на практике. А заодно учу ценить себя, выпихиваю в отпуск, чтобы не выгорели (потому что нафиг оно мне надо - искать хорошего РП с рынка долго и дорого) и так далее.
В этом списке есть навык РП быть аналитиком и разбираться в технике ровно настолько, чтобы иногда взять на себя отвествтенность за какое-то решение, предложенное командой (или хотябы просто понять изменения и уметь пояснить заказчикам при необходимости).
Но нет навыка разработки, так как все кейсы, когда это было надо (и приведенный выше вами) решался на уровне описания требований и постановки тикета разработчику.
Так-то, разумеется, веселится каждый так, как хочет. Я вот знаю CDTO очень большой компании, который на досуге балуется Питончиком, чтобы чувствовать себя "в строю" :)
Но к его работе отношения это, конечно, не имеет. Когда ему необходимы серьезные дашборды (а у него 10 тыс человек в организации), он зовет свое аналитическое управление, а то управление зовет подрядчиков, чтобы те подогнали данные для отчетности. То есть в реале оно вот так.
ладно, если вам так нормально то и нормально, не буду брюзжать))
ага, все понял, да.
по пункту 2 вам помучаю еще:
что такое освоение ресурса?
а) Это планируемая загрузка
б) это фактическая загрузка
в) это планфактный анализ
судя по описанию и вашему ответу, б) у вас есть, это ясно. но а) у вас пока что нет, а точнее, вы выковыриваете его из заявок, что , скорее всего, боль и место для оцифровки.
собственно это то о чем я говорил в п 1 выше: обычное ресурсное планирование в ИСУП решает такую проблему: вам, как линейному руководителю на доске будет видна планируемая загрузка аналитиков, исходя из 90-100% вероятных входящих проектов на полгода, будет виден перегруз и все что вам нужно.
Далее у вас будет (уже есть) фактическая утилизация. А далее вы будете более точно стучать по рукам вашим нерадивым РП, которые всегда бронируют больше, а списывают меньше, а вы за утилизацию отвечай ))
речь идет о навыке, необходимом для работы менеджера. программирование - не нужно :)