Доброго времени суток! Спасибо за такой большой комментарий. Тоже отвечу вам пошире:
Это не совсем так. Зависит от культуры организации и от самого менеджера. При слабой культуре (в частности, не прислушивается к сотрудникам) сложнее, при сильной - легче. Аналогично с силой и опытом менеджера.
Трудно не согласиться, но вот только чаще всего человеку с улицы редко дают нужный уровень агентности.
Это "база" (про ответственность и полномочия). Надо было сразу начинать искать работу, как только проигнорировали риски автора - не надо соглашаться руководить, не имея полномочий. Результат был предсказуем - и всё равно работу искать пришлось, но в худшей ситуации.
Верно. В тот момент, как только я получил странную реакцию - сразу конец. Не обязательно нужны первичные данные. Если метрика продумана верно, а расчёт её автоматизирован (т.е. фальсификация невозможна), то первичные данные нужны лишь для детального анализа причин в отдельных случаях. А вот правила про автоматизацию и систему управления проектами я у автора не вижу:-)
Да какая там продумка. Просто собирали файлик в экселе и считали все. Не было понятной методики, которыми можно было бы проверить. Соглашусь с вами, что если метрика собирается автоматом без возможности мутить можно обойтись и без доступа в условную JIRA.
Не очень понятен смысл фразы "саботировать данные". Если речь про их искажение, то искажать будут и в случае, если будут знать "зачем". Даже ещё и активнее.Правила фиксировать нужно, чтобы все на одном языке говорили и чтобы прозрачность была в команде и доверие было.А чтобы данные не искажали нужны другие методы (автоматизация внесения; внесение теми, кто не зависит от результатов и т.д.).
Верно. Часто просто не фиксируется это никак. А денег на автоматизацию нет. И еще комбо: руководитель хочет, чтобы метрика собиралась секретно
Приветствую. Не кажется, а так и есть. Чаще всего ИТ-менеджер просто разменная монета. Такого много очень видел. Человек, имеющий возможность что-то менять обычно приходит не с улицы
Согласен, только вот даже когда роли довольно хорошо закреплены - у менеджера все равуно нет достаточного уровня агентности (полномочий/админ ресурса), чтобы на что-то влиять
Спасибо за развёрнутый комментарий. С тезисом про агентность согласен: работа менеджера - приносить варианты, считать эффект, обозначать риски и договариваться. Ровно поэтому я отделяю OKR как инструмент фокуса и синхронизации от схем вознаграждений: прямая привязка к премиям обычно ведёт к занижению планки и игре в метрики/политику вместо работы, ведущей к успеху.
Про «комфорт». Речь все же об условиях, которые ускоряют бизнес-результаты: ясные приоритеты, границы ролей и бюджет с доказуемой окупаемостью. Это все же о возможности влиять на метрики, ответственность за которые вам передают в рамках процесса.
Про «идти и выбивать». Чаще всего так и делаю. В реальных кейсах сталкивался с ситуациями, когда рассчитанное ТЭО отклонялось — собственники осознанно выбирали сохранить маржу. Это логичный и понятный выбор. В этом случае моя задача зафиксировать требования и условия, предложить альтернативы с меньшей ценой задержки и прозрачными критериями проверки.
Про двусторонность. Проблемы редко односторонние. Поэтому я держу обсуждение в плоскости запроса от бизнеса и так часто упоминаю RACI. Важно понимать зоны ответственности и реальные возможности повлиять на участников процесса. На практике часто выясняется, что бизнесу нужен администратор процессов, а не менеджер изменений. Это расхождение ожиданий и становится причиной для неэффективного сотрудничества. Больше об этой теме рассказываю в этом выпуске подкаста.
Про OKR. Считаю OKR отличным инструментом фокуса — именно при разрыве с премиальными формулами. Собственно, мой упрёк не «людям», а способу применения: когда OKR превращают в KPI-контракт, люди теряют мотивацию, а то и вовсе политизируют процесс.
Если у вас есть классные кейсы работы с OKR и метриками для ИТ-менеджера в целом - жду вас нашем подкасте, посвященном эффективности линейного управленца.
Про роль менеджера. Здесь полностью согласен: никакие артефакты не заменят ежедневной работы со стейкхолдерами. Однако, надо держать в уме, что это желание чаще всего одностороннее. Топ-менеджмент хочет получить результат и желательно не вкладывая никаких ресурсов. Если вам повезло работать с людьми, которые способны адекватно воспринимать действительность и увеличивать агентность ИТ-менеджера, то это не повсеместная практика, к сожалению.
Про OKR и деньги. Действительно, OKR задумывались как инструмент целеполагания и синхронизации, а не как система вознаграждений. Но вот незадача - оказывается чаще всего именно так ее и используют. О чем я собственно и пишу в статье. Одно дело синхронизироваться со стратегией компании, приготовить цели, релевантные плану. И совсем другое, когда этот прекрасный инструмент используют исключительно в качестве способа урезания издержек на команду.
Про "вот это все." Чаще всего те самые диаграммы и таблички в экселе являются инструментом донести до руководство позицию относительно вашей позиции на сроки, риски и бюджет. Всегда ли это работает? Это уже совсем другой вопрос. Соглашусь, в большинстве случаев руководство не просто "ждет чуда", но все же не готово двигать свои интересы в угоду полностью укомплектованной команды, комфортного процесса и уж тем более комфорта в работе ИТ-менеджера. А корень этой проблемы в том, что цели у бизнеса и линейного управляющего разные. Тут бы помог OKR, но увы - как я и писал выше, чаще всего это инструмент контроля и репрессий.
Это как раз и происходит потому, что руководство не понимает, кто им нужен: управленец или администратор? И чаще всего происходит такое, что управленцев уже и так хватает (буквально реальных людей, принимающих какие-то решения по проекту), а вот администраторов не хватает. Но ведь мало кто пойдет просто админом. Там и денег меньше и задачи проще. Поэтому ставится позиция ПМ. А по факту ты аккаунт. Еще и многие фирмы привязывают метрики к продажам. То есть буквально, чем больше ты продал дополнительно работ, тем больше заработал. При этом те самые операционные задачи про которые вы пишите никто не отменял. В итоге у нас "менеджер среднего звена, работает с утра до утра". Когда же тебя полностью выжмут, то просто скажут что-то вроде:"Мы поняли, что не нуждаемся в данной позиции. Химии не случилось. Вы не оправдали наших ожиданий".
Вы же немного неправы, когда пишите, что ЛПР должен знать "что и как". Он должен знать "что", но "как" должны выяснить вы и принести варианты, и вот тут ЛПР, как вы правильно заметили, должен принять решение.
Соглашусь, но еще чаще бывает так, что ЛПР не хочет трезво смотреть те самые варинты "как?". Классический прием принести три решения, разные по цене. Но даже тщательно подготовленные ТЭО отметаются в угоду экономии. Проблема в том, что цели менеджера и ЛПР не совпадают. Ты условно приходишь делать процесс эффективнее, а это не всегда значит дешевле.
Моло написано про управленческие моменты. Статья могла бы быть эталонной, от проблемы бизнеса и инструментов их решения до лайфхаков управленца
Спасибо. Над этим можем подумать вместе на одном из будущих подкастов. Соглашусь, что с позиции ЛПР многие предложения видятся несерьезными - ведь ресурс всегда ограничен.
Трудно не согласиться с вашим аргументом, но на собеседовании мы совершенно другое обсуждали. Поэтому для меня был неприятный шок, учитывая, что вести клиентов и заниматься продажами я не люблю.
Если он есть. В большинстве команд аналитик - это роскошь, которую стараются срезать любыми способами. Опять же из личного опыта, но это приводит к удорожанию производства продукта, однако для этого у менеджмента не всегда хватает дальновидности
Про границы. Ваш пункт абсолютно в тему. Большинство сотрудников в принципе не хотятя делать что-то больше их должностной инструкции по многим причинам. Самая важная из которых банально денежная мотивация. Как правило любые доп функции - это ответственность, которая никак не компенсируется. Приятного в этом крайне мало. Поэтому и воспринимается это соответствующе
Первое, на что бы я обратил внимание - наличие лица, способного принимать решения и понимать, какие именно решения придется принимать, даже если они не совсем "удобные".
Согласен. ЛПР должен понимать, что именно планируется делать. И как. Если нет такого понимания - то на этом все.
Где-то на просторах Хабра не очень хорошо отзывались о RACI (за себя скажу, что читается она тяжело).
Сложно спорить. Но из личной практики - это самый эффективный способ расписать процесс
Доброго времени суток! Спасибо за такой большой комментарий. Тоже отвечу вам пошире:
Это не совсем так. Зависит от культуры организации и от самого менеджера. При слабой культуре (в частности, не прислушивается к сотрудникам) сложнее, при сильной - легче. Аналогично с силой и опытом менеджера.
Трудно не согласиться, но вот только чаще всего человеку с улицы редко дают нужный уровень агентности.
Это "база" (про ответственность и полномочия). Надо было сразу начинать искать работу, как только проигнорировали риски автора - не надо соглашаться руководить, не имея полномочий. Результат был предсказуем - и всё равно работу искать пришлось, но в худшей ситуации.
Верно. В тот момент, как только я получил странную реакцию - сразу конец.
Не обязательно нужны первичные данные. Если метрика продумана верно, а расчёт её автоматизирован (т.е. фальсификация невозможна), то первичные данные нужны лишь для детального анализа причин в отдельных случаях. А вот правила про автоматизацию и систему управления проектами я у автора не вижу:-)
Да какая там продумка. Просто собирали файлик в экселе и считали все. Не было понятной методики, которыми можно было бы проверить. Соглашусь с вами, что если метрика собирается автоматом без возможности мутить можно обойтись и без доступа в условную JIRA.
Не очень понятен смысл фразы "саботировать данные". Если речь про их искажение, то искажать будут и в случае, если будут знать "зачем". Даже ещё и активнее.Правила фиксировать нужно, чтобы все на одном языке говорили и чтобы прозрачность была в команде и доверие было.А чтобы данные не искажали нужны другие методы (автоматизация внесения; внесение теми, кто не зависит от результатов и т.д.).
Верно. Часто просто не фиксируется это никак. А денег на автоматизацию нет. И еще комбо: руководитель хочет, чтобы метрика собиралась секретно
Приветствую. Не кажется, а так и есть. Чаще всего ИТ-менеджер просто разменная монета. Такого много очень видел. Человек, имеющий возможность что-то менять обычно приходит не с улицы
Верно. Человек в целом не любит, когда за ним что-то считают. А ИТ- ребята так особенно. Они люди творческие все же. Так что вот и ответ.
Согласен, только вот даже когда роли довольно хорошо закреплены - у менеджера все равуно нет достаточного уровня агентности (полномочий/админ ресурса), чтобы на что-то влиять
Мне понравилась аналогия, поэтому использовал
Все так. Самое распространенная ситуация: говорят одно, а по факту ты в аквариуме
Привет! Интересный кейс. Надо посмотреть, что будет в ближайшие пару месяцев. Как боролся с сопротивлением команды?
Это очень хороший вопрос
Все так. Сам смотрю во время подбора резюме после скрина только. Сначала ИИ, потом рекрутер и только потом нанимающий менеджер. Приколов много
Спасибо за ваш комментарий. Так получается, потому что магии не бывает.
Спасибо за развёрнутый комментарий. С тезисом про агентность согласен: работа менеджера - приносить варианты, считать эффект, обозначать риски и договариваться. Ровно поэтому я отделяю OKR как инструмент фокуса и синхронизации от схем вознаграждений: прямая привязка к премиям обычно ведёт к занижению планки и игре в метрики/политику вместо работы, ведущей к успеху.
Про «комфорт». Речь все же об условиях, которые ускоряют бизнес-результаты: ясные приоритеты, границы ролей и бюджет с доказуемой окупаемостью. Это все же о возможности влиять на метрики, ответственность за которые вам передают в рамках процесса.
Про «идти и выбивать». Чаще всего так и делаю. В реальных кейсах сталкивался с ситуациями, когда рассчитанное ТЭО отклонялось — собственники осознанно выбирали сохранить маржу. Это логичный и понятный выбор. В этом случае моя задача зафиксировать требования и условия, предложить альтернативы с меньшей ценой задержки и прозрачными критериями проверки.
Про двусторонность. Проблемы редко односторонние. Поэтому я держу обсуждение в плоскости запроса от бизнеса и так часто упоминаю RACI. Важно понимать зоны ответственности и реальные возможности повлиять на участников процесса. На практике часто выясняется, что бизнесу нужен администратор процессов, а не менеджер изменений. Это расхождение ожиданий и становится причиной для неэффективного сотрудничества. Больше об этой теме рассказываю в этом выпуске подкаста.
Про OKR. Считаю OKR отличным инструментом фокуса — именно при разрыве с премиальными формулами. Собственно, мой упрёк не «людям», а способу применения: когда OKR превращают в KPI-контракт, люди теряют мотивацию, а то и вовсе политизируют процесс.
Если у вас есть классные кейсы работы с OKR и метриками для ИТ-менеджера в целом - жду вас нашем подкасте, посвященном эффективности линейного управленца.
Про роль менеджера. Здесь полностью согласен: никакие артефакты не заменят ежедневной работы со стейкхолдерами. Однако, надо держать в уме, что это желание чаще всего одностороннее. Топ-менеджмент хочет получить результат и желательно не вкладывая никаких ресурсов. Если вам повезло работать с людьми, которые способны адекватно воспринимать действительность и увеличивать агентность ИТ-менеджера, то это не повсеместная практика, к сожалению.
Про OKR и деньги. Действительно, OKR задумывались как инструмент целеполагания и синхронизации, а не как система вознаграждений. Но вот незадача - оказывается чаще всего именно так ее и используют. О чем я собственно и пишу в статье. Одно дело синхронизироваться со стратегией компании, приготовить цели, релевантные плану. И совсем другое, когда этот прекрасный инструмент используют исключительно в качестве способа урезания издержек на команду.
Про "вот это все." Чаще всего те самые диаграммы и таблички в экселе являются инструментом донести до руководство позицию относительно вашей позиции на сроки, риски и бюджет. Всегда ли это работает? Это уже совсем другой вопрос. Соглашусь, в большинстве случаев руководство не просто "ждет чуда", но все же не готово двигать свои интересы в угоду полностью укомплектованной команды, комфортного процесса и уж тем более комфорта в работе ИТ-менеджера. А корень этой проблемы в том, что цели у бизнеса и линейного управляющего разные. Тут бы помог OKR, но увы - как я и писал выше, чаще всего это инструмент контроля и репрессий.
Это как раз и происходит потому, что руководство не понимает, кто им нужен: управленец или администратор? И чаще всего происходит такое, что управленцев уже и так хватает (буквально реальных людей, принимающих какие-то решения по проекту), а вот администраторов не хватает. Но ведь мало кто пойдет просто админом. Там и денег меньше и задачи проще. Поэтому ставится позиция ПМ. А по факту ты аккаунт. Еще и многие фирмы привязывают метрики к продажам. То есть буквально, чем больше ты продал дополнительно работ, тем больше заработал. При этом те самые операционные задачи про которые вы пишите никто не отменял. В итоге у нас "менеджер среднего звена, работает с утра до утра". Когда же тебя полностью выжмут, то просто скажут что-то вроде:"Мы поняли, что не нуждаемся в данной позиции. Химии не случилось. Вы не оправдали наших ожиданий".
Спасибо за такой развернутый комментарий!
Вы же немного неправы, когда пишите, что ЛПР должен знать "что и как". Он должен знать "что", но "как" должны выяснить вы и принести варианты, и вот тут ЛПР, как вы правильно заметили, должен принять решение.
Соглашусь, но еще чаще бывает так, что ЛПР не хочет трезво смотреть те самые варинты "как?". Классический прием принести три решения, разные по цене. Но даже тщательно подготовленные ТЭО отметаются в угоду экономии. Проблема в том, что цели менеджера и ЛПР не совпадают. Ты условно приходишь делать процесс эффективнее, а это не всегда значит дешевле.
Моло написано про управленческие моменты. Статья могла бы быть эталонной, от проблемы бизнеса и инструментов их решения до лайфхаков управленца
Спасибо. Над этим можем подумать вместе на одном из будущих подкастов. Соглашусь, что с позиции ЛПР многие предложения видятся несерьезными - ведь ресурс всегда ограничен.
Трудно не согласиться с вашим аргументом, но на собеседовании мы совершенно другое обсуждали. Поэтому для меня был неприятный шок, учитывая, что вести клиентов и заниматься продажами я не люблю.
Если он есть. В большинстве команд аналитик - это роскошь, которую стараются срезать любыми способами. Опять же из личного опыта, но это приводит к удорожанию производства продукта, однако для этого у менеджмента не всегда хватает дальновидности
Про границы. Ваш пункт абсолютно в тему. Большинство сотрудников в принципе не хотятя делать что-то больше их должностной инструкции по многим причинам. Самая важная из которых банально денежная мотивация. Как правило любые доп функции - это ответственность, которая никак не компенсируется. Приятного в этом крайне мало. Поэтому и воспринимается это соответствующе
Первое, на что бы я обратил внимание - наличие лица, способного принимать решения и понимать, какие именно решения придется принимать, даже если они не совсем "удобные".
Согласен. ЛПР должен понимать, что именно планируется делать. И как. Если нет такого понимания - то на этом все.
Где-то на просторах Хабра не очень хорошо отзывались о RACI (за себя скажу, что читается она тяжело).
Сложно спорить. Но из личной практики - это самый эффективный способ расписать процесс
Все так. Чаще всего события разиваются именно так
Возможно хорошая идея
Есть такое. Реально много людей в это верит
Да, я просто проводил эксперименты. Было интересно, что он выдаст. Но ты прав, большая часть того, что он генерит - это контекст переписок