4. Согласно идее ОКР, их выполнение не должно быть привязано к вознаграждению (чтобы избежать проблемы КПИ, когда все улучшают КПИ, а не продукт).
felipecastro.com/...ate-okr-and-compensation
Правильная система мотивации учитывает влияние вклада конкретного сотрудника на компанию в целом.
Поэтому вознаграждение все-таки привязано к OKR компании.
Просто связь не жесткая.
Например, в случае конфликта между OKR сотрудника и OKR более высокого уровня, в приоритете последние.
законы Хаммурапи
Также любые законы и правила.
Только это не KPI.
У «преступления» 2 состояния — совершено/не совершено и т.д.
Тогда как KPI — это показатель «больше значит лучше».
Security analysis
Компании в целом вполне себе описываются с помощью KPI — выручка, прибыль и т.п.
С KPI государств — это вообще очень сложная тема, поэтому не хочу даже прикасаться этой темы, потому что точно знаю, что это будут только спекуляции :)
Уточню, что имел ввиду.
В посте шла речь о показателях на конкретной позиции.
И вот мой тезис в том, что для интеллектуального труда невозможно построить KPI.
Для производства достаточно легко — «100 втулок по ГОСТу за смену».
Для продавцов тоже — «1М продаж в месяц».
Или «100 лидов в месяц» для маркетолога.
Но вот практически невозможно получить «интегральные показатель ох**ности разработчика».
И чтобы потом к этому показателю напрямую привязать вознаграждение, потому что сразу пойдет оптимизация показателя при сохранении минимальных затрат труда.
Аналогично с тестировщиками, дизайнерами, аналитиками, копирайтерами и т.д.
Максимум — это формально описать критерии «явно плохо», своего рода «стандарты качества».
С другой стороны, когда «явно плохо», то для адекватного менеджера это очевидно и без KPI. Зачем тогда тратиться на систему отслеживания KPI?
Поэтому и существует альтернативная стратегия — пытаться укомплектовать максимально качественными кадрами, которые мотивированны на достижения, ставить им прозрачные цели и не мешать им со всякими отчетами и KPI ;)
Не невозможно, а трудно. И это не значит, что не нужно стараться это сделать. Везде, где можно, нужно субъективные критерии объективизировать. Главное — трезво оценивать применимость модели и последствия ее применения.
Вы можете привести хоть один пример объективизации субъективного критерия? Который был сформулирован, и успешно использовался?
Конечно, поэтому КПИ надо ставить таким образом, чтобы они максимально отражали пользу для компании.
И согласно «закону», любой КПИ будет взломан ;)
Если оценщик мотивирован интересами компании ...Но как часто это так?
Наворачивать систему KPI, потому что оценщик играет против компании — это лечение подорожником перелома.
Корневая причина — это отсутствие доверия к оценщику. Надо сменить или оценщика или отношение к нему.
Доверие кадрам — это ключевой вопрос.
Если оценщик не мотивирован интересам компании, то что ему мешает подделывать результаты?
Критерии оценки производительности и качества интеллектуального труда на данном этапе развития цивилизации невозможно формализовать.
Поэтому даже есть «закон» (к сожалению, не могу вспомнить автора): при введении метрики оценки производительности сотрудника он всегда найдет такой способ работы, который максимизирует метрику и при этом минимизирует свои затраты на достижения максимальных показателй. (В другом варианте — максимизирует метрику и минимизирует пользу для компании).
В Украине через «лотереи» идет отмывание бабла, и это причина того что они так «популярны».
Легализация черного кеша с помощью серого бизнеса? :)
Зачем «отмывателям» усложнять себе жизнь?
Открывают себе «мебельный магазин», через него пропускают черный кеш.
Зачем нести дополнительные риски, что отмывка накроется (точнее, приостановится на несколько дней) через очередную «акцию» по борьбе с игровым бизнесом?
1)
В ней я постараюсь показать, как компания на любом этапе развития может получить пользу от пользовательских исследований. Все на примерах.
Очень уместный формат для данной темы.
2)
Понравилась манера/структура изложения.
Небольшие абзацы, маркированные списки, уместные иллюстрации цифрами — удобно читать по-диагонали (быстро скроллить и выдергивать ключевые идеи). При чтении «подряд» не устаешь от портянок текста.
Спасибо за статью.
О да, это было бы неплохо.
После того, как они начали использовать похожий домен, нам теперь регулярно в саппорт пишут по поводу ElasticSearch.
А чого ви хочете?
тіпо «стартову з.п. у долині» добитися так само легко
Ні, я ж сам писав про:
Хоча і вимоги там вищі.
Навіть 4.3 уже мало де дають :)
Ось і виходить, що «стартова» ЗП в Долині після базових витрат дає «в залишку» скільки ж, скільки далеко не стартова в Україні.
НО!
Русскоязычные «местные» в Долине используют название «силиконовая», что уже можно считать традиционным названием.
Кремниевая — это академическое название, которое используют больше у нас.
залишок: 3.5
В Україні у багатьох ІТшників весь дохід складає 3.5.
Щоб на руках залишалось 3.5, то потрібно мати «брутто-дохід» хоча б в 5. А це вже третя квартиль розподілу компенсацій для більшості позицій в Україні.
зп 120000$)
Наскільки я орієнтуюсь, то це не сама велика ЗП для Долини.
при цьому маючи більше грошей, ніж той, хто переїхав у Долину.
Ні, навіть з врахуванням дорожчих цін (і дуже дорогої нерухомості), в Долині залишається більше «на руках».
Хоча і вимоги там вищі.
Так.
За моїми спостереженнями, у 95% ФОПів, в якості накопичення «капіталу» — це хіба-що нерухомість.
создать/иметь референсную тестовую копию базы, которую беречь-любить-накатывать
У вас есть опыт поддержания референсной копии БД сложной системы в течении года и больше? Где хотя-бы пару десятков моделей в доменной области, со сложной иерархией, связями многие ко многим и все такое.
Я наблюдал пару раз попытки работы с таким подходом, но потом это приводило к тому, что из-за комбинаторного взрыва там находилось очень много тестовых объектов (иначе покрытие было не полным). И со временем, под каждое новое изменение в структуре данных приходилось делать трудоемкое обновление референсной базы (или фиксить текущую или заново создавать новую).
Интересно, как кто-то решает эту проблему?
Подход ущербный
При желании любое тестирование (в т.ч. и мануальное) можно назвать ущербным, потому что системы сложные, всех случаев никогда не предусмотришь и на production всегда может произойти ситуация, о которой никто не знал.
Но несмотря на это, тестирование имеет смысл. Даже при невозможности достижения 100% покрытия, какую-то часть функционала они покрывают.
То же самое можно сказать и в данном случае — тестирование со сгенерированными данными.
Из практики — у нас API почти полностью покрыта integration-tests, для которых на ходу создаются данные, примерно так-же, как это описано в статье.
Да, случаются баги, которых нет в этих тестах. Но это происходит редко. Зато ежедневно, внося очередную правку в API можно быстро проверить и быть уверенным, что основне кейсы работают.
Цитирование без указания первоисточника — да, нарушает.
Вы написали over 9000 (в данном случае буквально) комментариев, и не заметили, что при ответах ссылки проставляются автоматически (там же видно, к чему относится ответ)?
Лол, загляните в мой профиль перед тем как раздавать такие полезные советы.
9207 комментариев
Извините, товарищ дедушка, не признал сразу :)
Цитирование, тем-более в диалоге, нарушает авторские права? Вы серьезно?
(Подсказка — можете съехать на то, что это была неудачная шутка, тогда это не будет так глупо выглядеть)
Пруфы есть?
Потому что даже на Википедии за 30 секунд можно найти противоположную инфу:
Таблица 4. Индекс сверхсмертности в 1933 г.
Сибирь 1,1
Украина 3,2
ru.wikipedia.org/.../Голод_в_СССР_(1932—1933