… а еще — я уже согласен уменьшить требования к hard skills выпускников. Если речь идет о региональных технических вузах — пусть они хотя бы две вещи сделают. Первое — перестанут выдавать дипломы программистов людям, которые настолько генетически к этому не склонны, что на выходе не понимают разницы между переменной и ссылкой на нее. Второе — обучат студентов «общей культуре» программирования. Ну то есть — исходники в git, автотесты (и вытекающий из этого testable design), scrum/kanban и обязанности участника проекта. Конкретным технологиям в конкретном проекте — один фиг доучивать. Пусть хоть знают, что за столом надо вилкой и ложкой пользоваться, а не прямо с блюда ртом есть…
Мой личный опыт (не в условиях ВУЗа, а когда студенты на практику приходили): например, изучаем паттерны проектирования (бо студенты за год до выпуска пишут всю программу в одном методе main!...). У меня нет ни времени, ни сил чтобы читать им полноценный курс лекций. Поэтому я сначала создаю им проблемную ситуацию (лучше всего заходят, опять-же игры!). Показываю, насколько плохо кончится попытка ее решения «в лоб». Потом они смотрят лекцию или ее кусок. Потом коллективно проектируется решение предложенной мной проблемы. И я не вижу ни одной причины, по которой так нельзя работать в ВУЗе! Я понимаю, что это утопия — но если мы хотим научить инженера-программиста, невозможно программировать только один раз в две недели на практиках по программированию — а в остальное время переписывать лекции с доски. Разработка ПО должна проходить сквозным способом через философию, охрану труда, экономику и т.д. Проблема в том, что хрен найдешь на кафедре философии человека с опытом программирования, если его и на профильной кафедре нету… В этой связи единственное разумное решение — это сильным ВУЗам записывать обучающие материалы, а доцентам региональных обучалок становиться де-факто ассистентами при говорящей голове с экрана. То есть — создавать обучающую ситуацию, разбивать удаленную лекцию на части практической работой и сессиями вопросов-ответов, и т.д. В этом случае можно сильно уменьшить нагрузку на преподавателя — и затащить на нее не мытьем-так катанием практикующего программиста из индустрии.
Но это боль и слезы — так как специалисты в ИТ большей частью не умеют преподавать и не имеют соотв. опыта.
В частности, во время чтения лекций они увлекаются и начинают «рисовать сову» — т.е. рассказывать о вещах, им самим совершенно понятных и очевидных.
Можно сэкономить массу времени и сил, если брать хорошие учебные курсы или их отрывки с ютуба и смотреть их со студентами. Понятно, что идея «дети, смотрите полтора часа видео на экране» — не работает. Но если вы берете нормальное учебное видео, дЕлите на фрагменты, и разбавляете его практикой от преподавателя-разработчика — это лучше чем просто видео, и лучше чем просто преподаватель-разработчик. Плюс еще есть классный формат лекции — онлайн программирование.
Вот тут я по своему опыту могу сказать, что печатный самолет значительно менее ремонто-пригоден, нежели модель стандартной (каркас+обшивка) конструкции. Потому что по-сути, печатная модель — это работающая обшивка (плюс сотовое заполнение, которое не дает обшивке терять устойчивость в ответственных местах). Если в ней сделалась дыра или пошла трещина — невозможно вырезать кусок и вставить замену — просто не к чему цепляться! В традиционной модели — полотняная или потолочная обшивка режется до силового элемента (полки лонжерона, нервюры, стрингера). В тяжелом случае усиливается поврежденный силовой элемент… Вклеивается секция обшивки на замену — и снова в воздух! А тут — только крупноузловая замена разве… Хотя опять-таки, если модель одноразовая — запустил-навел-поразил, то ничего. И вес излишний в принципе, никого не волнует — запустить один раз и с катапульты можно, или РДТТ в качестве ускорителя. А если предполагается ее сажать и снова поднимать в воздух, я рекомендую вернуться к дедовским технологиям, но ответственные детали, которые задают геометрию поверхностей — делать не из бальзы выпиливанием, а на 3D-принтере. При большом желании, можно даже уложиться в бородатый советский авиамодельный норматив — 6 граммов на квадратный дециметр конструкции. Если с карбоном — то можно и еще лучше…
Я бы еще аккуратно подчеркнул одну сторону проблемы. В остальных областях материального производства мы имеем более-менее стабильное «плато технологий». Ну то есть автомобиль, выпущенный 10-20 лет назад принципиально не отличается от текущего (имея в виду железо и собственно ездовые функции). Аналогично, я бы сказал про авиацию, строительство и прочие вещи. В софте у нас идет «планирование от достигнутого». Если сегодня группа разработчиков делает state-of-the-art проект, завтра десять компаний начнут делать его клоны, а через 5 лет проект такого уровня и функционала будет считаться абсолютной нормой. Приведу пример — в 40-х 50-х годах весь бухгалтерский (суммовой и количественный учет) промышленного предприятия (на минуточку, магнитки, КМК, да еще мало ли чего!) делался на счетах. Теперь его автоматизировали. И что, он стал менее трудоемким? Да фиг там — сначала правила бухучета хитровывернули, чтобы предприниматели не скрывали прибыль. Потом (привет кто помнит!) сделали отдельный налоговый учет со своими регистрами и правилами. То есть как только софт и хард позволили легко решать текущие задачи — их (задачи) немедленно усложнили. И это продолжается и продолжается — и конца-края этому не видно… :-(
Я по этому примеру не могу сделать определенных выводов. Как минимум, я хотел бы выслушать точку зрения руководства. Иногда, реальность с угла зрения технарей и с угла зрения бизнеса — различается кардинально. В любом случае цифры сами по себе не панацея… Я даже не знаю, какой еще пример привести… Ну вот например, все же согласны что летчик-испытатель высокой квалификации в принципе может вести и посадить самолет даже с отказавшими приборами. Однако для среднего экипажа в кабине приборы все-таки нужны. Опять же, бывают трагические случаи когда и с исправными приборами летчики по причине человеческого фактора загоняют самолет в землю (CFIT). Опытный водитель на знакомой машине практически не смотрит на спидометр — но для среднего водителя без показаний скорости ехать затруднительно. И да, это не мешает особо выдающимся индивидам при исправном указателе скорости размазать себя о невинных людей на встречке на скорости 120+ в городе. :-( То есть к цифрам в обязательном порядке должно прилагаться умение и желание их применять. Но (опять — мое личное мнение) — с цифрами в среднем лучше, чем без них!
… и кстати, я нигде не говорю что нужно изобретать свои показатели. Велосипедостроение опасно не только в программировании… :-) Если есть в отрасли хорошо известные и зарекомендовавшие себя KPI (любой врач по почти любому поводу спросит у вас температуру и давление!) — берем и пользуемся. Вопрос в том, чтобы эти показатели регулярно считались, и как-то осмысливались (текущее значение, норма, динамика, и т.д.). Я так вижу…
Вопрос в том, что вы согласитесь считать «удачным внедрением»? Я circa 2002-2006 годы отслеживал KPI своей группы разработчиков. Количество строк кода в коммитах вытаскивалось из CVS (позже, из SVN). Time-factor (на сколько надо умножить оценочные часы разработчика, чтобы перейти к календарному времени) вытаскивался из projections taskjuggler-а. Зарплата упомянутых разработчиков вообще никак не зависела от этих показателей. Они были важны мне для процесса управления, чтобы регулировать загрузку людей и давать во внешний мир реалистичные сроки доработок. Мог бы я управлять без показателей? Да конечно — другие отделы не страдали цифрами KPI и как-то управлялись! Было ли это закреплено в руководящих документах? Разумеется нет — мне не нужен приказ, чтобы самому работать! Вижу ли я разницу между управлением без показателей и с таковыми — да, безусловно. Применил бы я то же самое еще раз в такой ситуации — разумеется, да. Более того, мое мнение — выбрать показатели, регулярно их считать, и принимать решения на основе фактов — является прямой обязанностью руководителя. Какие показатели он отберет, из чего будет считать — это его управленческое решение и жизненный опыт. Но если руководитель не может назвать показатели по которым он оценивает работу своего подразделения, или объяснить как тот или иной показатель используется для принятия решений — зарплату руководителя он получает по-ошибке.
Ну так вот оно и есть — бригадир (опираясь на богатый жизненный опыт) отслеживает KPI вверенной ему бригады. Это уже хорошо. Но если удается отслеживать в сравнимых единицах для разных людей, бригад и проектов — сам бригадир может смотреть и сравнивать показатели своей бригады и других, и делать выводы. В общем, я еще раз повторюсь, что не строитель и не могу диктовать решения в этой области. Однако, по опыту управления программными проектами — управление с цифрами значительно веселее, чем управление без цифр «одним чутьем»…
Давайте отвяжем KPI от оплаты, OK? Я не строитель, поэтому возможно (и даже скорее всего) мои рассуждения несколько наивны. Но если вы ввязались в проект по укладке кирпича — значит как минимум у вас есть представление сколько тысяч штук его придется уложить. Кроме того, у вас есть какой-то срок (либо по контракту, либо диктуется климатом и погодой). Таким образом, вам жизненно необходимо отслеживать KPI «уложено кирпичей в день» чтобы понимать, вылетаете вы за условия контракта, или пока нет. Далее — если этот KPI отслеживается — желательно хоть как-то отслеживать его с привязкой к людям (хотя бы и с какой-то погрешностью). Потому что если Вася кладет условную сотню кирпичей в день, а Петя — две сотни, то у начальника обязан возникнуть вопрос, откуда разница? Либо Петя халтурит, либо он классный работник. Либо Вася — лентяй, либо у него особо трудный участок. Я всю дорогу пытаюсь донести мысль, что руководитель обязан знать и отслеживать KPI вверенного ему подразделения — и устранять (или объяснять хотя бы для себя) причины аномалий. Если KPI отслеживаются систематически — накапливается статистика скорости кладки кирпичей на разных объектах и разными людьми. В дальнейшем эта статистика уже может использоваться для прогнозирования сроков и затрат на будущих проектах. Я уж напомню что даже в древней модели CMM для перехода с уровня «Chaotic» на уровень «Repeatable» требуется ведение записей и статистики…
Еще раз повторюсь, что нигде я не призываю платить работнику только за количество уложенных кирпичей. Я вообще сторонник волюнтаристского подхода к зарплате: фиксированная часть и премиальная. Если человек работает так плохо, что не окупает даже фиксированную часть — его нужно уволить и послать заниматься чем-то другим (к чему он имеет бОльшую склонность и способности). Премиальная часть определяется либо начальником единолично, либо через КТУ бригадой. Возможны и более сложные комбинации с грейдами/разрядами и так далее. Но KPI — это прежде всего инструмент руководителя и для руководителя. Он может вводить новые формы работы, организации бригады, механизацию и что угодно еще — и оценивать через KPI — какие изменения являются полезными, а какие не окупаются. Но если руководитель лентяй (или не умеет руководить), то ему в голову приходит простое, логичное, легко реализуемое, неправильное решение — надо поставить зарплату рабочих в зависимость от KPI, и они сами все улучшат. Да, улучшат — но нет, не процесс, а только сам показатель за который стали платить. Дальше будет гонка брони и снаряда, пока либо KPI не умрут, либо фирма не сдохнет (потому что ничего полезного она производить с этими KPI не в состоянии).
Ну, справедливости ради — KPI обычно все-таки вектор. То есть набор параметров, которые с одной стороны описывают эффективность и жизнеспособность организации — а с другой, на которые человек своей деятельностью влияет. Теоретически, я могу представить себе в российских реалиях диалог: "- Какой у тебя KPI? — Шестьдесят два! — Шестьдесят два чего? — Шестьдесят два КиПиАй!". Но на практике до такого (!) идиотизма еще нигде не доходило. :-)
Я не готов утверждать наверняка — но скорее всего авторы KPI (вспоминается тут еще balanced scorecard почему-то) как раз имели в виду управлять по естественным, легко извлекающимся из текущей деятельности показателям. Опять же, обращаясь к врачебной аналогии — температуру и давление замерить можно за 5 минут… Потом зачем-то решили привязать KPI к ФОТ. Немедленно оказалось, что простыми показателями легко манипулировать. Как это было при СССР — если заводу устанавливали план в миллионах штук гвоздей, он начинал выпускать гвозди толщиной с иголку, которые невозможно было никуда забить. Если устанавливали план в тысячах тонн гвоздей — он менял настройки оборудования и выпускал гвозди тощиной с палец, чтобы скорее отчитаться о выполнении пятилетки. В ответ менеджмент начинает усложнять системы показателей и увеличивать количество таковых. Народ это продолжает хакать и производить показатели, раз уж дурное начальство решило за это платить… Плюс на этом кормятся толпы консультантов… В результате — если сейчас сказать «КПИ» — все понимают что речь идет о дорогущем монстре из сотен показателей, который якобы должен заставить всех трудиться на благо фирмы — но в конце концов, так и не заработает.
Мне кажется, что проблема не в KPI как в идее. Беда в головах. У нас полный провал в управленческих компетенциях — я это говорю серьезно, так как имею (не)счастье взаимодействовать с остатками т.н. «реальной экономики» в регионах. Даже то, что копируется с западных учебников — копируется в виде карго-культа. То есть внешне — почти то же самое, но функционально — совершенно не работоспособно… :-( Еще хуже — экономисты-юристы-менеджеры в региональных вузах обучаются этому карго-культу еще на университетской скамье (ну потому что посмотрите, кто их там учит!). То есть они убеждены, что самолет и радиостанция из банановых стволов и пальмовых листьев — так и должно быть!.. :-(
Мое частное мнение — управлять по KPI (по цифрам) лучше, чем без цифр. Даже если вас двое, или даже одиночка-ИП-фрилансер. Хотя бы фин.результат и распределение прибыли/затрат по проектам/заказчикам вести надо. Иначе есть риск от небольшого потрясения (заказчик ушел, неплатежи случились, etc) завалиться набок. Еще хуже — завалиться, но не понимать этого пока не станет поздно исправлять (совсем очевидно это становится когда деньги кончились, кредит уже не дают, а еще прошлые долги отдавать надо...). Дальше — в зависимости от отрасли и специфики можно найти другие индикаторы. Они сто процентов не должны быть сложными — это набор показателей, которые легко получить и по которым можно сразу сказать — хорошо или плохо. Если плохо — то в какой части фирмы хуже всего. И дальше работа управленцев — что-то с этим делать. Просто у нас любую хорошую идею вывернут до абсурда, лишь бы не работать… :-(
Если с «продающими» отделами все довольно просто, то в обслуживающих отделах что? быстрее обслуживать? это не принесет прибыли.
Вот тут очень классно руководителю знать не только KPI, но и теорию ограничений (ака Голдратт). Потому что даже если локальные KPI поставлены верно, и каждое подразделение действительно пытается максимизировать свою производительность — фирма как целое всегда будет настолько эффективна, насколько эффективно критичное ограничение. Если лучше работают подразделения до ограничения — оно забивает вход невыполненными работами. Если лучше работают подразделения после ограничения — они простаивают. В этом случае правильно выставлять KPI таким образом, чтобы подчинить все остальные подразделения имеющемуся критическому ограничению. В большинстве случаев, даже хуже — руководство предприятия обязано само установить — где будет это ограничение, и придерживаться потом выбранной стратегии. Есть соблазн, конечно — установить локальные KPI и завязать напрямую на ФОТ. И тут потом два варианта — либо на KPI забивают, и они перестают влиять на жизнь. Либо… все разваливается.
Вменяемый лидер команды разработчиков, IMHO обязан отслеживать ключевые KPI: кол-во строк кода на человека в день, количество тикетов/тасков, количество повторных дефектов в уже закрытых тасках. Может быть что-то еще — в зависимости от отраслевой специфики. Упаси бог его от соблазна платить зарплату от этих показателей! Как только он это сделает — разработка развалится. Если команда молодая и неопытная — руководителю лучше вообще не афишировать что(!) он отслеживает. В хорошей и крепкой команде — уже можно даже время от времени смотреть эти показатели вместе и обсуждать их. Но платить за показатели нельзя никому и никогда. Платить надо за проделанную полезную работу!
Всегда, когда обсуждается внедрение KPI — привожу один и тот же пример. Допустим, вы доктор — и лечите больного. Если вы не шарлатан — нужно опираться на какие-то данные. Например: температура, частота пульса, давление, СОЭ и так далее. Дальше вы назначаете лечение и отслеживаете изменение показателей. Если динамика удовлетворительная — продолжаете. Если неудовлетворительная — ищете причины и корректируете лечение. Но! Любой адекватный врач знает, что нельзя «лечить анализы» — то есть тупо давать таблетки от давления, колоть витамины от малокровия и одновременно синтетические гормоны чтобы СОЭ понизить. Нормальный врач по анализам строит в голове клиническую картину и подбирает препараты чтобы: во-первых сбить угрожающие жизни эффекты (тут допустимо кратковременно и анализы полечить), во-вторых стабилизировать организм, в третьих — по-возможности привести его к норме (и тут нужны не только препараты — а и образ жизни зачастую придется менять).
Так же и KPI в фирме — если Маша закрывает 20 сделок в месяц, а Витя — 10: не надо давать команду «Витя, делай в два раза больше звонков». Менеджер должен пойти и посмотреть — какова причина (!) наблюдаемой картины показателей. Возможно, это случайная флуктуация. Возможно, Витю надо обучать. Возможно, Витя выгорел. Возможно — у него просто более трудные клиенты. Возможно — он раздолбай и его надо уволить… В конце-концов, у руководителя зарплата больше именно потому, что он организует работу, а не просто циферки в отчете CRM смотрит…
И уж надо быть клиническим идиотом, чтобы начинать платить людям за KPI. Потому что закон Гудхарта: если вы платите людям за показатели — они производят показатели, а не полезный продукт. Представьте себе зав.отделением в больнице, который додумался поставить зарплату врачей в зависимость от средней температуры больных в отделении? Да пациенты пачками пойдут в морг с температурой 36.6+-0.2C… Так же и в компании — как только зарплата людей ставится в прямую зависимость от KPI — работа идет побоку, начинают рисоваться показатели. Поскольку у любой системы есть инерция — какое-то время кажется, что прямые KPI на ФОТ заработали. Ну а потом все, разумеется, разваливается…
Не могу полностью согласиться. Руководителю группы стоит отслеживать этот параметр. Им, разумеется, нельзя пользоваться в духе эффективных менеджеров — то есть за него платить или наказывать. А вот перераспределять работу и отслеживать угрозу выгорания — еще как можно. В больших организациях всегда есть тенденция перераспределять работу от тех, кто не хочет ее делать — к тем, кто может. Еще раз повторю отсылку к примеру из Брукса: долговременная производительность программиста на большом проекте составляет около 10 (десяти!) строк отлаженного кода в день. Современные языки и IDE может быть поднимают этот порог в разы, но не на порядки. Соответственно, если у вас человек в неделю зафигачил 500 строк изменений — и это не тривиальные геттеры-сеттеры-бойлерплейт — он выгорает. И в этот момент руководитель уже может начинать анализировать что происходит — и по-возможности корректировать нагрузку по людям. Или по-крайней мере, понимать что производительность этого человека через какое-то время просядет, и будет просажена пока тот не отдохнет (не обязательно в отпуске, может быть просто на других задачах).
С философской точки зрения, было бы правильно делить поля класса на first-class identifiers, изменение которых (скорее всего) не дает возможности дальше бизнес-логике мыслить объект до- и после изменения как эквивалентный. И second-class properties — для которых мы уверены, что объект до- и после изменения тот же самый, а какие-то его признаки изменились. При изменении first-class полей, надо создавать новый объект (в котором неплохо было бы прописать ссылку на старый — хотя бы для истории). При изменении вторичных признаков — просто меняется состояние объекта. Как это обычно бывает, однозначной трактовки — какое свойство куда отнести, нет. Это головная боль архитектора и техлида. :-) Пример из жизни: у заказа в системе есть признак «код склада». Его нельзя просто так взять и поменять. Хотя бы потому что на другом складе могут не быть доступны те же товары что и на исходном. Или на другом складе случайно может оказаться уже создан заказ с таким номером. Поэтому если пользователь хочет перенести задачу со склада на склад — на старом складе задача аннулируется, а на новом создается новая задача с теми пунктами, которые там можно исполнить. А если решили поменять комментарий у заказа — то это можно. Другой пример из жизни: у ящика с товаром есть уникальный штрихкод с ID. Его нельзя менять — просто потому что никто не может гарантировать что ваша операция по изменению ID в системе выполняется в реальности (этиктеку можно порвать, потерять, не наклеить, и т.д.). Поэтому менять ID ящика нельзя — можно только создать новый и переложить товар из старого. А вот менять location ящика — можно…
Ну да. Я же говорю: во-первых надо считать за какой-то период, а не за день. Во-вторых, начальнику надо разбираться в программировании — и понимать, что это за 500 строк кода. Если это геттеры и сеттеры, которые IDE на Java нагенерила — то и норм. Десятки строк — это именно код, над которым надо думать, когда пишешь или рефакторишь.
Для начала, руководителю программистов следует знать, что:
— При восьмичасовом рабочем дне программист эффективно программирует не более 4-6 часов в день. Это не значит, что он не может неделю пахать по 12 часов! Это значит, что если регулярно планируется длительность задач исходя хотя бы из 8 часов чистого программирования — люди выгорают.
— Средняя долговременная производительность разработчика на большом проекте составляет десятки (!) строк отлаженного кода в сутки. Это не значит, что нельзя за день написать и покрыть тестами, скажем, полтысячи. Можно! Но если недельная и месячная производительность разработчика поехала в сторону сотни строк в день по коммитам (и это не тривиальные search-and-replace) — он выгорает, причем быстро.
— В сколько-нибудь крупных компаниях есть еще феномен: «работа перемещается от тех, кто не хочет ее делать — к тем, кто может». В результате, один не знает чем себя занять — второй «морда в кофе, жопа в мыле...». А руководитель занимает позицию: «мне безразлично кто и как это будет делать — важно чтобы уложились в бюджет и сроки!».
Можно сэкономить массу времени и сил, если брать хорошие учебные курсы или их отрывки с ютуба и смотреть их со студентами. Понятно, что идея «дети, смотрите полтора часа видео на экране» — не работает. Но если вы берете нормальное учебное видео, дЕлите на фрагменты, и разбавляете его практикой от преподавателя-разработчика — это лучше чем просто видео, и лучше чем просто преподаватель-разработчик. Плюс еще есть классный формат лекции — онлайн программирование.
Еще раз повторюсь, что нигде я не призываю платить работнику только за количество уложенных кирпичей. Я вообще сторонник волюнтаристского подхода к зарплате: фиксированная часть и премиальная. Если человек работает так плохо, что не окупает даже фиксированную часть — его нужно уволить и послать заниматься чем-то другим (к чему он имеет бОльшую склонность и способности). Премиальная часть определяется либо начальником единолично, либо через КТУ бригадой. Возможны и более сложные комбинации с грейдами/разрядами и так далее. Но KPI — это прежде всего инструмент руководителя и для руководителя. Он может вводить новые формы работы, организации бригады, механизацию и что угодно еще — и оценивать через KPI — какие изменения являются полезными, а какие не окупаются. Но если руководитель лентяй (или не умеет руководить), то ему в голову приходит простое, логичное, легко реализуемое, неправильное решение — надо поставить зарплату рабочих в зависимость от KPI, и они сами все улучшат. Да, улучшат — но нет, не процесс, а только сам показатель за который стали платить. Дальше будет гонка брони и снаряда, пока либо KPI не умрут, либо фирма не сдохнет (потому что ничего полезного она производить с этими KPI не в состоянии).
Мне кажется, что проблема не в KPI как в идее. Беда в головах. У нас полный провал в управленческих компетенциях — я это говорю серьезно, так как имею (не)счастье взаимодействовать с остатками т.н. «реальной экономики» в регионах. Даже то, что копируется с западных учебников — копируется в виде карго-культа. То есть внешне — почти то же самое, но функционально — совершенно не работоспособно… :-( Еще хуже — экономисты-юристы-менеджеры в региональных вузах обучаются этому карго-культу еще на университетской скамье (ну потому что посмотрите, кто их там учит!). То есть они убеждены, что самолет и радиостанция из банановых стволов и пальмовых листьев — так и должно быть!.. :-(
Вот тут очень классно руководителю знать не только KPI, но и теорию ограничений (ака Голдратт). Потому что даже если локальные KPI поставлены верно, и каждое подразделение действительно пытается максимизировать свою производительность — фирма как целое всегда будет настолько эффективна, насколько эффективно критичное ограничение. Если лучше работают подразделения до ограничения — оно забивает вход невыполненными работами. Если лучше работают подразделения после ограничения — они простаивают. В этом случае правильно выставлять KPI таким образом, чтобы подчинить все остальные подразделения имеющемуся критическому ограничению. В большинстве случаев, даже хуже — руководство предприятия обязано само установить — где будет это ограничение, и придерживаться потом выбранной стратегии. Есть соблазн, конечно — установить локальные KPI и завязать напрямую на ФОТ. И тут потом два варианта — либо на KPI забивают, и они перестают влиять на жизнь. Либо… все разваливается.
Так же и KPI в фирме — если Маша закрывает 20 сделок в месяц, а Витя — 10: не надо давать команду «Витя, делай в два раза больше звонков». Менеджер должен пойти и посмотреть — какова причина (!) наблюдаемой картины показателей. Возможно, это случайная флуктуация. Возможно, Витю надо обучать. Возможно, Витя выгорел. Возможно — у него просто более трудные клиенты. Возможно — он раздолбай и его надо уволить… В конце-концов, у руководителя зарплата больше именно потому, что он организует работу, а не просто циферки в отчете CRM смотрит…
И уж надо быть клиническим идиотом, чтобы начинать платить людям за KPI. Потому что закон Гудхарта: если вы платите людям за показатели — они производят показатели, а не полезный продукт. Представьте себе зав.отделением в больнице, который додумался поставить зарплату врачей в зависимость от средней температуры больных в отделении? Да пациенты пачками пойдут в морг с температурой 36.6+-0.2C… Так же и в компании — как только зарплата людей ставится в прямую зависимость от KPI — работа идет побоку, начинают рисоваться показатели. Поскольку у любой системы есть инерция — какое-то время кажется, что прямые KPI на ФОТ заработали. Ну а потом все, разумеется, разваливается…
Мораль? «А вы так не делайте!» © :-)
— При восьмичасовом рабочем дне программист эффективно программирует не более 4-6 часов в день. Это не значит, что он не может неделю пахать по 12 часов! Это значит, что если регулярно планируется длительность задач исходя хотя бы из 8 часов чистого программирования — люди выгорают.
— Средняя долговременная производительность разработчика на большом проекте составляет десятки (!) строк отлаженного кода в сутки. Это не значит, что нельзя за день написать и покрыть тестами, скажем, полтысячи. Можно! Но если недельная и месячная производительность разработчика поехала в сторону сотни строк в день по коммитам (и это не тривиальные search-and-replace) — он выгорает, причем быстро.
— В сколько-нибудь крупных компаниях есть еще феномен: «работа перемещается от тех, кто не хочет ее делать — к тем, кто может». В результате, один не знает чем себя занять — второй «морда в кофе, жопа в мыле...». А руководитель занимает позицию: «мне безразлично кто и как это будет делать — важно чтобы уложились в бюджет и сроки!».
Так вот, задача руководителя — отслеживать метрики и балансировать долговременную и кратковременную производтельность команды. Лично у меня внутренние ориентиры были следующие: 6 часов разработки максимум, 50 строк кода в сутки максимум. Если отдел вылетал за них — я начинал разбираться, что случилось. Иногда оказывались случайные флуктуации (и делать ничего не надо — загрузка сама собой упадет, люди отдохнут). Иногда приходилось перераспределять функционал между сотрудниками. Иногда приходилось выскребать резервы и расписывать задачи на себя (и делать их после бюрократических упражнений, положенных начальнику отдела по штату). Потому что "… в космической пехоте в десант идут все. Армия, в которой офицеров больше, чем капралов, а сержантов больше, чем рядовых — обречена на поражение!" © Хайнлайн, «Звездная пехота» (книга, не фильм). А если начальник над программистами сам не программировал — тогда ой! Даже не знаю что и советовать…