Отсутствие примеров, с моей стороны, как вы правильно заметили, «характерно» и вот почему: выше я уже предложил Kanut79 попробовать *вместе* создать KPI для небольшой команды — в кач-ве тренировки. Ответный посыл был «ну вы тут накидайте, а я посмотрю». Вы, как я вижу, тоже собрались «откинуться на спинку кресла» как рекомендует Windows во время установки. :-)
Нет, ребятки, так это не работает. Это *вам* надо, а не мне. У меня с составлением KPI для кросс-функциональных команд проблем нет. Если вы управленцы, то должны знать, что мы учимся всю жизнь и это прекрасно. А если вы исполнители, тогда не забивайте себе голову составлением KPI — это не входит в ваши задачи.
См. мой комментарий Kanut79 выше. Предлагаемые вами KPI, во-первых, исключительно количественные, во-вторых, однобокие в разрезе "больше — лучше". Отсюда и сложность в решении задачи.
Не могу отвечать чаще, чем раз в час, к сожалению. Если вы можете как-то на это повлиять (карму там плюсануть или еще как) — буду благодарен. :-)
То, что люди начинают «подстраиваться» под KPI — это хорошо и так и должно быть, для этого KPI и создаются. То, что вы видите проблемой — не проблема KPI как такового (это просто инструмент, как нож — можно резать колбасу, а можно под ребра), а проблема неправильно *выстроенных* KPI.
На самом деле это довольно сложная штука, потому что построить систему KPI, в которых они будут работать органично между различными бизнес-юнитами — достаточно большое искусство (которым, к слову, мало кто владеет), но выстроив эту систему, понимаешь, что она начинает работать.
Если хотите — можем вместе построить такую систему. Создавайте виртуальную команду из 3 функций (чтобы не закапываться на неделю с этим упражнением) и составим для нее KPI. Ну если я буду понимать эти профессии, конечно. Ну, например, Product Manager, Project Manager и программист. Или Data Scientist и Data Engineer (2 функции). Это я привел в пример тех, чью работу я *понимаю*.
Я так понимаю из контекста, посыл — "нет работаюших KPI в IT"?
Я рассуждаю так: KPI (в любой индустрии) это система оценки эффективности сотрудника, работающая на том уровне точности, который позволяет компании осуществлять планирование своего развития и воплощение в жизнь принятой стратегии.
Если вы согласны с вышеуказанной формулировкой (она исключительно моя, основанная на опыте, не из книг, при всем к ним, разумеется, уважении), то напишите пару аргументов в пользу утверждения почему именно в IT KPI работать не могут.
Вы уводили разговор в сторону с самого начала, но теперь начали просто хамить и переходить на личности. "Предиктивные манагеры" ставят для меня точку в этой дискуссии.
Вы пытаетесь бороться со мной количеством слов, это непродуктивно — лучше просто по существу. Меняется всё и вся и любой бизнес и как раз искусство — подстраиваться под изменения: любая выигрышная вдолгую стратегия — не статична. Поэтому повторю еще раз: IT не исключение. Мне видится, что в силу молодости этой индустрии в ней велико желание акторов (на всех уровнях) изобрести колесо, в то время как проще было бы перенять все хорошее (как тот же Lean от Тойоты) и тратить энергию на развитие.
Я все же являюсь адептом парадигмы, что нет неизмеримых вещей: есть либо плохие измерители, либо мерила. Обычно второе, следующее из первого.
IT- индустрия не уникальна в этом контексте. Эффективность вполне, извиняюсь, эффективно меряется в производстве, космической промышленности и даже в такой мегасложной с операц. т.зрения штуке как аэропорт. Поэтому затруднения в налаживании работы цепочки из 3 звеньев я относил и всегда буду относить исключительно к непрофессионализму отвечающего за эту цепочку.
Я, простите, оцениваю ситуацию как рук-ль со стороны, так сказать "бизнеса" (причем не IT): а в чем проблема, что каждый будет заниматься своей зоной ответственности, нести за нее ответственность (на уровне KPI) и таки да — в компании начнут с доверия сотрудникам.
Product генерит список фич (это его работа, ее маркетинговая часть), Project — связующее звено между бизнесом и программистами, который позволит и сроки не "накрутить" и загрузить команду невозможным, в результате происходит нормальная оценка в разрезе "ожидаемая прибыль/затраты на реализацию (в т.ч. временнЫе)" и всё работает.
На примере норвежского: Hvordan har du det? Вурьдан харь дю дэ. Да простят меня норвежцы. Что в этом, сложного — что "h" не читается? Что "o" это "у"? Тогда все языки сложны. Насчет "один из сложнейших" давайте не будем: я лингвист и ответственно заявляю, что в романо-германской группе самый сложный во всех смыслах однозначно немецкий, а в финно-угорской — пожалуй, венгерский. Датский в сравнении с обоими — агуканье 3-летнего ребенка.
"Но при этом медицина бесплатна почти полностью, образование — тоже"
Когда уже среднестатистический россиянин поймет, что нет понятия "бесплатно", а есть понятие "за мои налоги".
И насчет датского. Как человек, владеюший норвежским (а это, грубо говоря, то же самое, что шведский и датский) могу сказать, что все эти 3 языка в разы проще английского, так что не пугайте общественность.
Странная статья. Мышечные волокна не красные/белые, а быстрые и медленные. Причем говорить "в этой части тела такие-то волокна" — в корне неправильно, т.к. оба типа есть в любой части тела.
Разные стратегии занятий развивают в большей степени либо тот, либо другой тип, но самая забавная вещь в том, что правильнее всего — развтвать поочередно оба типа волокон. Поэтому и чередуют силовые тренировки с, например, интервальными — они совершенно по разному устроены.
Короче, непростая тема, на самом деле. :-)
Разработчик, безусловно, должен делать работу, соответствующую решению задач пользователя, но в разрезе технологий. Условно говоря, чтобы работало быстрее, хранилось надежнее, откликалось эффективнее и т.д. Это синергия, а у нас вечно х*ями меряются — кто главнее. Как маркетинг и продажи. Теперь программисты и бизнес (продакты). Ну окей, поезд-то (рынок) идет не останавливаясь, а ехать в нем или драться, выйдя на полустанке — дело вольное. Я об этом.
Ну если "программист + бизнесмен" это Product Manager, то я китайский летчик.
У меня ощущение, что я помру, но так и не прочитаю на этом ресурсе какое-то более-менее правильное определение этой роли. Печаль.
"Если коротко, то это человек, который должен привести продукт из точки А, где продукт находится сейчас, в точку Б, где его хотят видеть топ-менеджмент или фаундеры через Х месяцев."
Какое на редкость неправильное понимание роли. Product Manager это специалист, чья задача максимально увеличить прибыльность продукта, исходя из имеющихся и возможных ресурсов, работая на стыке Бизнеса, Технологии и UX.
Мда, видосы показательные. Как и глупые слова Тиграна. Можно сколько угодно не понимать BLM или гей-парады, но глупо отрицать, что т.н. западная модель цивилизации — human-oriented, как ни крути. И это прекрасно.
Нет, ребятки, так это не работает. Это *вам* надо, а не мне. У меня с составлением KPI для кросс-функциональных команд проблем нет. Если вы управленцы, то должны знать, что мы учимся всю жизнь и это прекрасно. А если вы исполнители, тогда не забивайте себе голову составлением KPI — это не входит в ваши задачи.
См. мой комментарий Kanut79 выше. Предлагаемые вами KPI, во-первых, исключительно количественные, во-вторых, однобокие в разрезе "больше — лучше". Отсюда и сложность в решении задачи.
То, что люди начинают «подстраиваться» под KPI — это хорошо и так и должно быть, для этого KPI и создаются. То, что вы видите проблемой — не проблема KPI как такового (это просто инструмент, как нож — можно резать колбасу, а можно под ребра), а проблема неправильно *выстроенных* KPI.
На самом деле это довольно сложная штука, потому что построить систему KPI, в которых они будут работать органично между различными бизнес-юнитами — достаточно большое искусство (которым, к слову, мало кто владеет), но выстроив эту систему, понимаешь, что она начинает работать.
Если хотите — можем вместе построить такую систему. Создавайте виртуальную команду из 3 функций (чтобы не закапываться на неделю с этим упражнением) и составим для нее KPI. Ну если я буду понимать эти профессии, конечно. Ну, например, Product Manager, Project Manager и программист. Или Data Scientist и Data Engineer (2 функции). Это я привел в пример тех, чью работу я *понимаю*.
Я так понимаю из контекста, посыл — "нет работаюших KPI в IT"?
Я рассуждаю так: KPI (в любой индустрии) это система оценки эффективности сотрудника, работающая на том уровне точности, который позволяет компании осуществлять планирование своего развития и воплощение в жизнь принятой стратегии.
Если вы согласны с вышеуказанной формулировкой (она исключительно моя, основанная на опыте, не из книг, при всем к ним, разумеется, уважении), то напишите пару аргументов в пользу утверждения почему именно в IT KPI работать не могут.
Вы уводили разговор в сторону с самого начала, но теперь начали просто хамить и переходить на личности. "Предиктивные манагеры" ставят для меня точку в этой дискуссии.
Вы пытаетесь бороться со мной количеством слов, это непродуктивно — лучше просто по существу. Меняется всё и вся и любой бизнес и как раз искусство — подстраиваться под изменения: любая выигрышная вдолгую стратегия — не статична. Поэтому повторю еще раз: IT не исключение. Мне видится, что в силу молодости этой индустрии в ней велико желание акторов (на всех уровнях) изобрести колесо, в то время как проще было бы перенять все хорошее (как тот же Lean от Тойоты) и тратить энергию на развитие.
Я все же являюсь адептом парадигмы, что нет неизмеримых вещей: есть либо плохие измерители, либо мерила. Обычно второе, следующее из первого.
IT- индустрия не уникальна в этом контексте. Эффективность вполне, извиняюсь, эффективно меряется в производстве, космической промышленности и даже в такой мегасложной с операц. т.зрения штуке как аэропорт. Поэтому затруднения в налаживании работы цепочки из 3 звеньев я относил и всегда буду относить исключительно к непрофессионализму отвечающего за эту цепочку.
Я, простите, оцениваю ситуацию как рук-ль со стороны, так сказать "бизнеса" (причем не IT): а в чем проблема, что каждый будет заниматься своей зоной ответственности, нести за нее ответственность (на уровне KPI) и таки да — в компании начнут с доверия сотрудникам.
Product генерит список фич (это его работа, ее маркетинговая часть), Project — связующее звено между бизнесом и программистами, который позволит и сроки не "накрутить" и загрузить команду невозможным, в результате происходит нормальная оценка в разрезе "ожидаемая прибыль/затраты на реализацию (в т.ч. временнЫе)" и всё работает.
Я даже во сне улыбаюсь, не то, что на резюме.
Я не прогадал, выбрав либертарианство.
На примере норвежского: Hvordan har du det? Вурьдан харь дю дэ. Да простят меня норвежцы. Что в этом, сложного — что "h" не читается? Что "o" это "у"? Тогда все языки сложны. Насчет "один из сложнейших" давайте не будем: я лингвист и ответственно заявляю, что в романо-германской группе самый сложный во всех смыслах однозначно немецкий, а в финно-угорской — пожалуй, венгерский. Датский в сравнении с обоими — агуканье 3-летнего ребенка.
"Но при этом медицина бесплатна почти полностью, образование — тоже"
Когда уже среднестатистический россиянин поймет, что нет понятия "бесплатно", а есть понятие "за мои налоги".
И насчет датского. Как человек, владеюший норвежским (а это, грубо говоря, то же самое, что шведский и датский) могу сказать, что все эти 3 языка в разы проще английского, так что не пугайте общественность.
Странная статья. Мышечные волокна не красные/белые, а быстрые и медленные. Причем говорить "в этой части тела такие-то волокна" — в корне неправильно, т.к. оба типа есть в любой части тела.
Разные стратегии занятий развивают в большей степени либо тот, либо другой тип, но самая забавная вещь в том, что правильнее всего — развтвать поочередно оба типа волокон. Поэтому и чередуют силовые тренировки с, например, интервальными — они совершенно по разному устроены.
Короче, непростая тема, на самом деле. :-)
Разработчик, безусловно, должен делать работу, соответствующую решению задач пользователя, но в разрезе технологий. Условно говоря, чтобы работало быстрее, хранилось надежнее, откликалось эффективнее и т.д. Это синергия, а у нас вечно х*ями меряются — кто главнее. Как маркетинг и продажи. Теперь программисты и бизнес (продакты). Ну окей, поезд-то (рынок) идет не останавливаясь, а ехать в нем или драться, выйдя на полустанке — дело вольное. Я об этом.
Ну если "программист + бизнесмен" это Product Manager, то я китайский летчик.
У меня ощущение, что я помру, но так и не прочитаю на этом ресурсе какое-то более-менее правильное определение этой роли. Печаль.
Т.е. изменения, например, касающиеся рекламодателей и не видимые простому обывателю, не в счет? :-)
Какая настроениеподнимательная статья, спасибо.
"Если коротко, то это человек, который должен привести продукт из точки А, где продукт находится сейчас, в точку Б, где его хотят видеть топ-менеджмент или фаундеры через Х месяцев."
Какое на редкость неправильное понимание роли. Product Manager это специалист, чья задача максимально увеличить прибыльность продукта, исходя из имеющихся и возможных ресурсов, работая на стыке Бизнеса, Технологии и UX.
"В суть всякой вещи вникнешь, когда правдиво наречешь ее" (с) "Андрей Рублев"
"По факту продакт-менеджер — это сотрудник, который может делать абсолютно все, не являясь профессионалом в каждой области."
После этих слов чтение прекратил. Это апогей, безусловно. Думаю, понятно чего именно.
Да, но маятник качнется обратно — надеюсь еще при моей жизни.
Мда, видосы показательные. Как и глупые слова Тиграна. Можно сколько угодно не понимать BLM или гей-парады, но глупо отрицать, что т.н. западная модель цивилизации — human-oriented, как ни крути. И это прекрасно.