☠️ Вред KPI: личный пример
В споре, говорят, рождается истина, только в вопросе как формализовать оценку эффективности работы большой группы или нескольких групп людей консенсуса до сих пор не достигнуто: без KPI плохо, с ними ещё хуже. Как только появляются какие-то метрики производительности, появляются и способы их эксплоитить с целью личной выгоды (удовлетворение интересов оценивающих ради продвижения по карьерной лестнице; не важно какой при этом итоговый результат, если формально требования соблюдены): если пожарных оценивать по количеству потушенных пожаров, то вскоре они сами начнут поджигать дома.
Проблема усугубляется тем, что при разработке OKR, скажем, для оценки результативности по кварталу тщательности проработки уделяется наименьшее внимание: обе стороны, и принимающая, и предоставляющая результат, относятся к квартальному планированию как к обязаловке, очередной нудный митинг, с которого поскорее бы свалить. Начинается всеми любимый байкшеддинг, в квартальные параметры оценки эффективности пролезают заведомо бредовые или заведомо упрощённые варианты, потому что см. выше: всем ненавистный добровольно принудительный митинг, помимо которого и своих дел по зарез. KPI придумываются от балды, методом бля буду, жопой чую вот это вот охуеть как важно и полезно для бизнеса.
Именно так в один из квартальных OKR пролезла задача перенести все существующие AWS Security groups в IaC-инфраструктуру под управлением Terraform. Вроде бы всё понятно, цель благая (ускорение выкатки изменений в инфраструктуре), да и сама задача выросла из тикета, который уже был в беклоге, так что суть вопроса была нам уже ясна.
В теории всё выглядело хорошо: два месяца до дедлайна, можно успеть горы свернуть... Если помимо OKR нет других задач и прерываний. Ситуация в IT operations почти всегда близка к военной: тут взорвётся, там упадёт, всё плохо, надежды нет. Посему на практике вышло так, что задача, не будь смертельно важной, делалась по остаточному принципу, то есть в последнюю неделю в репозиторий приезжает коммит, сгенеренный скриптом, который тупо прошёлся по AWS API, взял оттуда названия security groups и сделал terraform import.
Формально задача выполнена? Выполнена. В срок? В срок! Можно ли результатом пользоваться? Абсолютно невозможно. Terraform при импорте объектов копирует их текущий стейт, поэтому в манифестах был сплошной хардкод, который теперь усложнял выкатку и изменение security groups. Либо по прежнему приходилось делать руками и изменять стейт, либо перемещать группу уже как положено, в составе модуля, и следить при этом за тем, чтобы не было конфликтов в стейте.
Лучше бы вовсе не трогали, ей богу.
Что бы предложил я лично? Да пёс его знает, у меня нет ни качественных, ни количественных метрик чтобы с уверенностью сказать что что-то сработает, а что-то не сработает. Все оценки и прикидки строго индивидуальны как ты ни пытайся их формализовать. Поэтому могу только сказать "бля буду, жопой чую это сработает":
- Не надо привязывать формализованные метрики к срокам. Ставить дедлайны на OKR почти всегда означает, что желающие карьерного продвижения срежут все возможные углы, лишь бы достигнуть цели, остальные же повозмущаются, но сделают спустя рукава. В обоих случаях результат создаст больше проблем, чем решит, а решение этих проблем не принесёт ни одной из сторон никакой видимой пользы: работников за это не повысят, а для компании такой рефакторинг станет в несколько раз дороже. К слову, именно рефакторинг, поддерживаемость и безопасность продать бизнесу сложнее всего — это всё отложенная выгода, а кровавый энтерпрайз хочет рост прибыли уже вчера. Будь я менеджером (вряд ли случится в этой жизни, но представить можно), попробовал бы отвязать OKR от интервалов — эпики и майлстоуны в джире есть у всех, а задачи по ним можно упаковывать в чуть более осязаемые двухнедельные спринты с коротким циклом фидбека: и понять можно быстрее что идёт не так, и сложить из этих кирпичиков целостный продукт-результат будет проще.
- Если есть временной/финансовый бюджеты на простой сервиса, на обучение сотрудников и на прочее необходимое зло, то почему не завести временной бюджет на обслуживание, поддержку и улучшение безопасности? 20% времени для начала было бы очень неплохо.
Как-то так. Жду следующего пяти-десятилетного витка развития коммуникации. Того гляди и Agile подохнет, наконец.
Tue, 12 Oct 2021 19:47:37 +0200
RSS // Telegram // Статистика