«Дьявол таится в мелочах». Ваш пример всего лишь демонстрирует субъективность, нелинейно увеличивающуюся при увеличении количества сотрудников. При тысяче сотрудников определить действительно самого эффективного сотрудника очень нелегко, даже скорее всего невозможно. Так что по общему закону о наказании невиновных и награждении непричастных премию скорее всего получат те сотрудники, которые ближе всех к телу руководителя.
В дискуссии перепутаны два понятия:
1. Аксиома о том, что управлять можно только измеряемым.
2. Вера в «волшебную таблетку» в виде KPI.
Индивидуальные показатели абсолютно не обязательно являются KPI — то есть по русски показателями Системы согласованных показателей. Потому что системность установки именно согласованных в масштабе всей организации индивидуальных показателей как декомпозиции показателей всей организации очень затруднительна, а зачастую невозможна. Не зря еще в прошлом веке придумали несколько вариантов оплаты труда, одной из которых была сдельная и сдельно-премиальная. То что многие называют KPI, по сути является попыткой сделать любую работу сдельной или сдельно-премиальной. Однако еще в прошлом веке знали о том, что для многих работ годится только повременная оплата и перевод ее на сдельную кроме вреда ничего не приносит. Почитайте основу установления норм труда — систему Тейлора. Хорошо расписаны основы установления показателей для повышения производительности труда рабочими, но ни слова не говорится об установлении аналогичных показателей для инженеров. Установить показатели для сдельной оплаты любой работы «головой» невозможно. Точнее вредно. Показатели могут устанавливаться только для проекта.
Вот я тоже считаю индивидуальные KPI злом. Но при этом возникает вопрос: если нет инд.показателей, то как будем определять и поощрять лучших сотрудников (которые приносят наибольшую пользу компании) и как определять отстающих (чтобы помочь им улучшить свою работу)? Никто ж не будет спорить, что люди работают с разной отдачей и обладают разным уровнем развития способностей и т.п.? Так что делать — никому не платить бонусы и не повышать зп? Или всем платить и повышать поровну? И есть ли третий приемлемый вариант в случае отказа от индивидуальных КПЭ?
Любая формальная логическая система претендующая на полноту противоречива. Задача менеджера, в отличии от программиста, как раз решать задачи, которые находятся в логическом противоречии. То есть не могут быть решены через формальную логику. Се ля ви. Человек настолько сложная биологическая система, что ее невозможно описать через логику. Даже формальной модели одной клетки нет. А там их ...., и связей еще больше. У вас жизни не хватит, чтоб просто их перечислить. Поэтому всегда есть противоречия. Их кто-то в компании должен пытаться решать. Делается это только волевым решением. Такие решения принимает управленец. Для того, чтобы это делать проще, в крупных компаниях прописывают регламенты. И если вы как сотрудник чихаете на них, то организация теряет управляемость. Дешевле и проще вас уволить. Так как вы резко усложняете систему своим формальным кодингом и конфликтом с менеджером и всей организацией. Вы по определению не можете быть объективным, так как вы субъект. И менеджер субъект, и организация субъект. И бизнес всегда субъективен, так как это всегда отношения между субъектами. Объектам ваша работа не нужна. Компьютеру вы не нужны. Вы нужны своими знаниями и умениями только людям, которые вас нанимают на работу, чтобы сделать свою жизнь и жизнь своих близких лучше.
Так аутсорсные конторы и не дают надежд на изменение мира, славу и признание, и очень наивно полагать, что идя в такую компанию с устоявшимися целями и стратегиями, человек будет чем-то большим, чем винтиком в механизме. И даже при всем этом в аутсорсах можно (а иногда и требуется) сделать карьеру, если она так важна для собственной самооценки.
До тех пор, пока к программисту отношение как к «ресурсу», нет смысла ждать к себе человеческого отношения.
Капиталистическое общество не может не относиться к людям как к ресурсу. Все остальные принципы отношения в конечном счете вредны для бизнеса.
«Ничего личного, просто бизнес».
Возможно, подчеркиваю, возможно на уровне высшего руководства гугла или другой транснациональной корпорации все иначе. Но, сдается мне, там все та же грызня за власть и бабло. И ровно то же самое отношение: Полезен — значит друг. Не полезен — пшел вон.
Возможно ли иначе? В современном мире — ой, сомневаюсь.
А если у вас 200 принтеров, а кроме них еще куча техники. Будете ли вы бегать за КАЖДЫМ принтером, в поисках его идеального использования, или создадите набор правил, что займет у вас минимум времени (не забываем у вас еще куча другой техники) и обеспечат эффективность использования например 80-90% принтеров?
поймите меня правильно, я технический специалист и привык, что использовать ресурсы надо предельно грамотно, используя их характеристики и области применения.
Вот у меня, допустим, ресурс — домашний лазерный принтер. Я знаю его характеристики и соответственно их применяю. Я не пытаюсь распечатать на нем цветное фото (он черно-белый). Я не засовываю в него плакатный формат А1 (он формата А4/Letter). Я не ищу путей сэкономить и, к примеру, запитать его от двух пальчиковых батареек.
Другими словами, мне кажется, что проблемы автора заключаются в том, что его использовали с предельным пренебрежением к его особенностям, способностям и областям применения. Это не использование ресурсов в реальной жизни, это техническая безграмотность по отношению к human resources
было бы полезно предельно детально описать, что вы вкладываете в понятие «относиться как к ресурсу» — потому что сама по себе такая формулировка кажется оскорбительной, хотя она настолько туманна, что в нее можно вместить что угодно
Не питайте иллюзий, кроме, может, совсем уже ламповых стартапов, любой наемный работник — это ресурс. И это нормально. Посудите сами, будь вы владельцем бизнеса, и у вас закончилась работа для работника, вот совсем, без всякой перспективы в будущем и возможности переквалификации, долго бы вы стали его держать? Максимум, что можно ожидать от честного бизнеса — открытый разговор, выходное пособие и отличные рекомендации.
Так что вы — ресурс. И у вас деловые взаимовыгодные отношения с вашим работодаетлем. Если вы считаете, что эти отношения значительно выгоднее работодателю, чем вам — вы всегда можете попробовать их пересмотреть или поискать более выгодные для вас, как сделал автор. Но я хочу подчеркнуть, выгода — это далеко не только деньги.
Нет, поэтому в такие компании идти смысла нет. Иначе будет как в статье — все силы направлены не на работу, а на имитацию деятельности.
> очень хороший метод
Отличный. Разработчик делает лучше — проваливается, дальше он исследует уязвимости системы и эксплуатирует их. Как написано в статье — Гугл от этого плюсов не получает (а платит разработчику за попытки продвижения внутри себя). Просто отличная и если (когда) количество таких понимающих перевалит некоторый предел — болезнь станет видна снаружи, пока вливание новой «вау!-мы-в-Гугл» крови спасают ситуацию, но кто знает.
А потом вдруг окажется, что механизм AB тестирования работал неправильно, и дизайны Васи всегда работали на 70% медленнее. Или еще хуже, дизайны Васи всегда писал один и тот же фронендер, причем дико криво, из-за чего они постоянно тупили.
Так можно продолжать долго, на самом деле. Вы будете давать ситуацию, я буду давать пример, который будет показывать, что ваша метрики не очень показательна. Причем в зависимости от случая она может не работать на 100%.
В современной разработке у вас не получится совсем сделать идеальный стерильный эксперимент без сайд-факторов. А раз они будут, то и анализировать их нужно будет и следовательно ваша KPI метрика становится больше вспомогательной.
Я бы еще добавил, что обычно дизайнер Вася не сам себе генерал, а над ним есть приемщик и тот, кто ставит задания. И вполне возможно, что потеря качества произошла именно на том, кто ставил дизайнеру задание.
И еще раз, если вы хотите валить результат комплексной работы кучи людей, каждый из которых не может работать как робот и даже взаимодействуют они с друг другом по разному (например, продукт овнер к дизайнеру Пете нашел подход, а к Васе еще не успел) — это ваше право. Но лично мне это кажется жутко неправильным. Но, вполне возможно, будет работать.
Метод хорош но не панацея — в частности не аргумент против «Неверно старгетированная рекламная компания» Именно это и позволяет Артемию Лебедеву утверждать что дизайн был норм.
Люди видят цельный продукт. Я просто пытаюсь сказать, что вы ставите дизайнера в ответе за то, что люди не пользуются сайтом, а проблема может быть:
Тупящий фронт-енд
Тупящий бек-енд
Неверно старгетированная рекламная компания
И еще что угодно.
Я просто не понимаю, почему вы метрики, которые зависят от кучи факторов сваливаете на дизайнера, который имеет к этому не так много отношения. Если мы говорим про KPI, то обычно это метрики, которые не нужно дополнительно анализировать, что бы получить из них результат. А тут получается, что по нормальному вы не можете взять эти метрики как KPI по дизайнеру, так как вам надо будет удостоверится, что это и правда виноват дизайнер, а не скажем, каждый второй запрос на сайт падает.
Ну, а еще это может быть тупняки сайта, потому что у вас скажем, добавление товара работает минуту.
Смысл моего комментария был в другом, в том что чистых метрик для дизайнера не получится все равно, так как надо будет понимать, на каком из этапов работы дизайн -> фронт-енд -> бекенд произошла ошибка.
Мы можем оценить поведение посетителей сайта. А чем оно обусловлено – другой вопрос, но зачастую это дизайн, поскольку фронтенд это лишь размещение элементов + адаптивность + прописывание анимации + скрипты, и всё это полностью определяется дизайном, если вам, конечно же, не приходится поддерживать какой-нибудь IE (а даже если и так, есть хаки).
При этом, если вы делегируете решение команде близких, то возникают крайне негативные сценарии:
А. Выпихнем наверх пару своих парней, а там они и нас подтянут.
Б. Я не проголосую за Боба, потому что он и без меня многовато наберёт.
Вывод автора верный, только он должен был прийти в старшей школе, университете или армии, до получения места постоянной работы. Google это обыкновенная рекламная компания, которая к IT имеет опосредованное отношение, это даже не Siemens или Neusoft, где реально нужны умные головы. Google набирает средних специалистов, что бы им на фоне друг-друга было как можно труднее выделиться для повышения (повышение по карьерной лестнице это не только новые лычки, но и самое главное улучшенное довольствие), у комиссии просто есть план повышений на год, связанный с бюджетом компании, а автор текста вероятно программирует не хуже и не лучше других сотрудников Гугл и делает все тоже самое, что делают другие. Все таки человек приходит в компанию зарабатывать, а не работать, если окружающая действительность показывает, что повышают не тех, кто лучше работает, а тех кто лучше делает что-то другое (самопиарится, взаимодействует с руководством) то и стоит прогнуться под эти обстоятельства? Зачем играть не по правилам, тем более, если это приносит меньше материальных выгод?
Да не в успехе гугла дело. Просто когда корпоративное дерево становится гигантским, то оно либо широкое, либо глубокое. И рано или поздно контроль будет не таким, каким он был при 2 сотрудниках.
Рано или поздно, менеджер любого звена перестанет реально оценивать качество работы своей группы, и тем более тех, кто ниже. Потому что не существует тех самых «объективных метрик» в сложных системах, требующих взаимодействия и взаимопомощи.
1. Аксиома о том, что управлять можно только измеряемым.
2. Вера в «волшебную таблетку» в виде KPI.
Индивидуальные показатели абсолютно не обязательно являются KPI — то есть по русски показателями Системы согласованных показателей. Потому что системность установки именно согласованных в масштабе всей организации индивидуальных показателей как декомпозиции показателей всей организации очень затруднительна, а зачастую невозможна. Не зря еще в прошлом веке придумали несколько вариантов оплаты труда, одной из которых была сдельная и сдельно-премиальная. То что многие называют KPI, по сути является попыткой сделать любую работу сдельной или сдельно-премиальной. Однако еще в прошлом веке знали о том, что для многих работ годится только повременная оплата и перевод ее на сдельную кроме вреда ничего не приносит. Почитайте основу установления норм труда — систему Тейлора. Хорошо расписаны основы установления показателей для повышения производительности труда рабочими, но ни слова не говорится об установлении аналогичных показателей для инженеров. Установить показатели для сдельной оплаты любой работы «головой» невозможно. Точнее вредно. Показатели могут устанавливаться только для проекта.
Капиталистическое общество не может не относиться к людям как к ресурсу. Все остальные принципы отношения в конечном счете вредны для бизнеса.
«Ничего личного, просто бизнес».
Возможно, подчеркиваю, возможно на уровне высшего руководства гугла или другой транснациональной корпорации все иначе. Но, сдается мне, там все та же грызня за власть и бабло. И ровно то же самое отношение: Полезен — значит друг. Не полезен — пшел вон.
Возможно ли иначе? В современном мире — ой, сомневаюсь.
Вот у меня, допустим, ресурс — домашний лазерный принтер. Я знаю его характеристики и соответственно их применяю. Я не пытаюсь распечатать на нем цветное фото (он черно-белый). Я не засовываю в него плакатный формат А1 (он формата А4/Letter). Я не ищу путей сэкономить и, к примеру, запитать его от двух пальчиковых батареек.
Другими словами, мне кажется, что проблемы автора заключаются в том, что его использовали с предельным пренебрежением к его особенностям, способностям и областям применения. Это не использование ресурсов в реальной жизни, это техническая безграмотность по отношению к human resources
Так что вы — ресурс. И у вас деловые взаимовыгодные отношения с вашим работодаетлем. Если вы считаете, что эти отношения значительно выгоднее работодателю, чем вам — вы всегда можете попробовать их пересмотреть или поискать более выгодные для вас, как сделал автор. Но я хочу подчеркнуть, выгода — это далеко не только деньги.
Нет, поэтому в такие компании идти смысла нет. Иначе будет как в статье — все силы направлены не на работу, а на имитацию деятельности.
> очень хороший метод
Отличный. Разработчик делает лучше — проваливается, дальше он исследует уязвимости системы и эксплуатирует их. Как написано в статье — Гугл от этого плюсов не получает (а платит разработчику за попытки продвижения внутри себя). Просто отличная и если (когда) количество таких понимающих перевалит некоторый предел — болезнь станет видна снаружи, пока вливание новой «вау!-мы-в-Гугл» крови спасают ситуацию, но кто знает.
А потом вдруг окажется, что механизм AB тестирования работал неправильно, и дизайны Васи всегда работали на 70% медленнее. Или еще хуже, дизайны Васи всегда писал один и тот же фронендер, причем дико криво, из-за чего они постоянно тупили.
Так можно продолжать долго, на самом деле. Вы будете давать ситуацию, я буду давать пример, который будет показывать, что ваша метрики не очень показательна. Причем в зависимости от случая она может не работать на 100%.
В современной разработке у вас не получится совсем сделать идеальный стерильный эксперимент без сайд-факторов. А раз они будут, то и анализировать их нужно будет и следовательно ваша KPI метрика становится больше вспомогательной.
Я бы еще добавил, что обычно дизайнер Вася не сам себе генерал, а над ним есть приемщик и тот, кто ставит задания. И вполне возможно, что потеря качества произошла именно на том, кто ставил дизайнеру задание.
И еще раз, если вы хотите валить результат комплексной работы кучи людей, каждый из которых не может работать как робот и даже взаимодействуют они с друг другом по разному (например, продукт овнер к дизайнеру Пете нашел подход, а к Васе еще не успел) — это ваше право. Но лично мне это кажется жутко неправильным. Но, вполне возможно, будет работать.
Люди видят цельный продукт. Я просто пытаюсь сказать, что вы ставите дизайнера в ответе за то, что люди не пользуются сайтом, а проблема может быть:
Я просто не понимаю, почему вы метрики, которые зависят от кучи факторов сваливаете на дизайнера, который имеет к этому не так много отношения. Если мы говорим про KPI, то обычно это метрики, которые не нужно дополнительно анализировать, что бы получить из них результат. А тут получается, что по нормальному вы не можете взять эти метрики как KPI по дизайнеру, так как вам надо будет удостоверится, что это и правда виноват дизайнер, а не скажем, каждый второй запрос на сайт падает.
Ну, а еще это может быть тупняки сайта, потому что у вас скажем, добавление товара работает минуту.
Смысл моего комментария был в другом, в том что чистых метрик для дизайнера не получится все равно, так как надо будет понимать, на каком из этапов работы дизайн -> фронт-енд -> бекенд произошла ошибка.
А. Выпихнем наверх пару своих парней, а там они и нас подтянут.
Б. Я не проголосую за Боба, потому что он и без меня многовато наберёт.
Рано или поздно, менеджер любого звена перестанет реально оценивать качество работы своей группы, и тем более тех, кто ниже. Потому что не существует тех самых «объективных метрик» в сложных системах, требующих взаимодействия и взаимопомощи.