Заключительная часть (см. часть первую и вторую).
В двух предыдущих частях я постарался показать, что у KPI есть серьезные проблемы, которые делают бесполезным и даже вредным применение KPI в творческих коллективах, в частности, занимающихся разработкой ПО. В заключительной части я попробую рассказать о тех вещах, которые, как мне представляется, работают и применяя которые можно обойтись без KPI.
Но сперва нужно обозначить границы разговора, дабы не пытаться объять необъятное. По моему опыту, системы KPI пытаются использовать для достижения двух целей, не важно по отдельности или же вместе:
- организация эффективного рабочего процесса с прозрачным определением сильных и слабых "звеньев цепи". Т.е. посредством введения KPI компания пытается диагностировать, где у нее есть проблемы с персоналом, кем нужно заняться очень плотно (вплоть до расставания), а кого нужно повышать и продвигать;
- организации прозрачной системы финансовой мотивации сотрудников, основанной на трансформации показателей KPI в проценты от максимальной квартальной/полугодовой/годовой премии.
На мой взгляд, это две совершенно разные цели и попытка их достижения посредством одного инструмента заставляет вспомнить житейскую мудрость про погоню за двумя зайцами :) Ну да хватит сарказма, пора переходить к сути. То, что я описываю ниже, по моим наблюдениям, работает. По крайней мере в небольших продуктовых софтверных компаниях.
Организация эффективного рабочего процесса без KPI
Сразу скажу, что написанное ниже, это трудный путь, требующий приложения массы усилий, времени, терпения, нервов и денег. Тут, как и в спорте, нельзя выпить какую-то волшебную пилюлю и всех забороть. Получение результата связано с большим трудом, потом, болью и кровью.
Главная вещь, которую нужно осознать и запомнить: работу выполняют люди. Поэтому организация нормального рабочего процесса -- это организация нормального взаимодействия людей. Подчеркиваю -- взаимодействия людей.
Вам нужны правильные люди на своих местах. Люди, которые могут и хотят выполнять ту работу, которая им поручена. Прежде всего они должны мочь и хотеть. Умение делать конкретный тип работы (будь то общение с заказчиком, написание кода, тестирование, управление проектной командой) -- это наживное. Мы все когда-то были новичками в своей профессии, и постоянно оказываемся новичками где-то еще. Тем не менее, мы успешно обучаемся и достигаем хороших результатов в том, чем занимаемся. Поэтому, если у вас есть готовые классные менеджеры, программисты, тестировщики, дизайнеры, внедренцы и т.д. -- вам повезло. Если нет готовых, но есть желающие и способные, то будет чуть тяжелее, но все равно все будет. А вот если у вас нет людей, которые желают делать то, что вы хотите, чтобы они делали -- тогда у вас проблема.
Не должно быть людей, которые находятся "не в теме". Разработчики (тестировщики, внедренцы, техписатели и т.д.) совершенно не уважают тех, кто не понимает, чем и как живет разработка. Разработчик может признавать формальную власть менеджера, который не понимает, что такое написание и отладка кода, не разбирается в предметной области и не знает особенностей продуктовой линейки компании. Но доверия и нормальных отношений с таким менеджером не будет. Однако, если разработчик знает, что менеджера "на мякине не проведешь", что даже ТОП-овый руководитель может задать серию уточняющих вопросов, отвечая на которые разработчику придется с головой погрузиться в самые непролазные дебри кода... Если руководитель с полуслова понимает, почему новое решение нужно собирать вот из этих компонентов... Если не нужно тратить рабочий день на объяснение того, почему нельзя за неделю поднять производительность на 150%... В общем, если на всех уровнях управляющей цепочки находятся грамотные, полностью погруженные в тему специалисты, то рабочий процесс оказывается действительно рабочим, а не процессом.
Открытость, прозрачность и вовлеченность. Люди хотят знать где находится компания, почему она там, что она делает, почему и зачем она это делает, что ее ждет, как и чем они могут помочь компании. Просто запомните: люди хотят это знать. Каждый по своим причинам, но знать хотят. Поэтому нужно об этом сотрудникам рассказывать. Не все можно говорить, но то, что можно говорить нужно. Максимально откровенно, очень осторожно относитесь к преукрашиванию. Оптимизм -- это классно, но если оптимизм базируется на недостаточной информированности, то это обязательно аукнется потерей доверия.
Открытость и прозрачность должна обеспечиваться не только по линии "руководитель-подчиненный", но и в обратную сторону, а так же между подразделениями. Знают ли соседние отделы в вашей компании, чем люди занимаются в каждом из них? Хотя бы над какими проблемами работают, какими технологиями пользуются? Какие у них были успехи в последнее время? Какие провалы? Чем они были обусловлены, какие выводы были сделаны? Как у вас вообще налажен обмен такой информацией? Выслушиваете ли вы идеи своих людей, вне зависимости от того, на какой ступеньке иерархии они находятся? Есть ли у них вообще такая возможность: высказать вам то, что они думают? И знают ли они об этом?
Растить нужно своих людей. Любой работающий коллектив -- это своя культура, неписанных правил и традиций в которой в разы больше, чем в письменных инструкциях и регламентах. Это знания и опыт людей. Это сложившиеся симпатии и антипатии, это уже сформировавшиеся приемы эксплуатации симпатий и преодоления антипатий. Это авторитет одних. Это амбиции (или их отсутствие) других. Это куча всего самого разного и разнообразного. И, что архиважно, все это уже работает. Правильные люди уже находятся на правильных местах. Они в теме. Они впитали и поддерживают атмосферу открытости, прозрачности и вовлеченности. Они носители вашей корпоративной и производственной культуры.
Если вы думаете, что вы легко внедрите в уже работающий коллектив менеджера со стороны, то вы сильно ошибаетесь. Легко точно не будет. И хорошего результата никто вам не гарантирует. И вероятность получения хорошего результата тем меньше, чем более высокого уровня приходит менеджер. Поскольку чем выше менеджер, тем вероятнее, что он придет не один, а приведет с собой свою команду (которая, так уж получается в природе, нафиг никому не нужна на прежнем месте работы менеджера, по целому ряду причин). Приход чужой команды управленцев -- это страшно. Из-за множества факторов. Начиная от необходимости взаимоувязывать разные корпоративные и производственные культуры между собой, заканчивая решением персональных проблем тех, кто не смог или не захотел искать общий язык с новыми менеджерами, а так же с теми, кто почувствовал, что перед ним только что громко захлопнули дверь к следующей ступеньке на карьерной лестнице.
Всего этого можно избежать, если делать ставку на своих людей. "Свежая кровь" со стороны, конечно же, нужна. Но это можно и нужно делать точечно, дозировано, эпизодически и очень-очень осторожно, руководствуясь принципом "не навреди". Растить своих людей крайне не просто. Об этом нужно думать постоянно, нужно заблаговременно прорабатывать варианты, готовить замену. А иногда и отпускать своих людей, если они выросли раньше, чем у вас появился подходящий вариант повышения. В общем, это тема для отдельного разговора.
Компактное размещение (все люди в шаговой доступности) и возможность прямого общения (внезапный разговор с руководителем на кухне). Чем меньше барьеров, чем проще найти и очно пообщаться с любым разработчиком или менеджером, тем лучше. Сложно передать, как много полезной информации можно получить от разработчика, которого менеджер встретил в коридоре и случайно чем-то поинтересовался. Сложно переоценить вклад в открытость и прозрачность компании возможность рядового сотрудника задать любой вопрос руководителю на офисной кухне или в спортзале. Насколько же проще становится жизнь, когда тебе не жалуются, что начальник сидит за тридевять земель и не может оценить объем проделанной работы, а судит о работе сотрудника на основании двух-трех телефонных звонков в неделю. Невозможно переоценить возможность размещения молодого специалиста рядом с опытными сотрудниками, когда он получает возможность учиться не только работая над порученными ему задачами, а просто находясь в подходящей творческой атмосфере, ежедневно наблюдая за работой "старичков", сидящих за соседним столом. В общем, территориальная разнесенность офисов и удаленная работа -- это может быть продиктовано жизнью и приносить свои плоды. Но когда есть возможность разместить весь коллектив компактно и предоставить ему достаточно условий для рабочего и нерабочего общения не мешая работе остальных (open space must die!), то нужно это сделать.
Небольшие команды. Чем меньше команда, тем эффективнее она работает. Меньше коммуникаций, быстрее обмен знаниями и идеями. Но, в контексте данного разговора, намного важнее степень прозрачности, которая существует в небольшой команде. В отделе из 50 человек наверняка найдутся 2-3 сотрудника, которые позволяют себе работать спустя рукава. В команде из 5 человек все на виду и если кто-то филонит или не справляется со своей работой, то это сразу же заметно всем.
Реальная ориентация на качество. Любые разговоры об эффективной организации труда, нацеленности на результат, приоритете качества и пр. разбиваются в пух и прах одной простой фразой: "Да и хрен с ним, давайте по-быстрому слепим вот так, а потом разберемся!" Вы не заставите людей работать хорошо, если после правильных разговорах о сроках, качестве, мотивации, процессах и пр., вы будете демонстрировать, что на качество можно "забить" из-за сроков или стоимости. Что производительностью или функциональностью можно пожертвовать ради плана. Что к развитию проекта вернемся когда к тому возникнут предпосылки (т.е. когда жареный петух клюнет из-за невозможности справится с нагрузкой или слишком большой стоимостью очередной доработки). Если вы хотите качественной работы от своих сотрудников, то наглядно продемонстрируйте им, что качество востребовано. Что этапность плана можно подкорретировать, если что-то нужно довести до ума. Что над развитием проекта кто-то работает постоянно (пусть даже всего один-два дня в неделю). Что в поиске компромиссов между бизнесом и технологией далеко не всегда победа достается бизнесу. Что вы помните о какашечках, которые пришлось наложить в проекте техническом долге и находите время на его оплату, а не тратите силы в очередном релизе на красочную упаковку для старой какашечки.
Пожалуй, на этом перечисление организационных моментов в формировании нормального рабочего процесса без KPI я прерву. Можно было бы и еще что-то вспомнить, но суть, я надеюсь, уже и так ясна. Вместо того, чтобы получать качественные параметры своего процесса в количественно-цифровом выражении посредством какого-либо KPI, лучше сконцентрироваться на таком процессе и взаимодействии людей, где вся информация и реальная картина происходящего сама по себе оказывается на поверхности.
Финансовое премирование без KPI
Теперь перейдем к более простому вопросу. О материальной составляющей. Т.е. о том, как премировать людей без показателей KPI. Тут не о чем особо разговаривать. Перечислю всего пару вещей, которые работают. Особенно в коллективах, где выполняются перечисленные выше условия и где есть нормально работающий производственный процесс.
Работают проектные премии. Сдали проект или большой этап проекта вовремя и с должным качеством -- проектная команда (а так же те, кто находились рядом с ней) получили проектную премию. Не сдали, не обеспечили качества -- не получили. Все просто.
Работают индексации зарплат по итогам года. Прошел год работы человека в компании, если к нему нет претензий (а их не должно быть, если же есть, то с присутствием человека в компании нужно что-то решать), то его зарплата должна быть проиндексирована. Пусть символически, пусть только для компенсации инфляции, но должна. Это не так просто, как проектные премии, но все же не бином Ньютона.
Еще в ряде случаев, на небольших временных интервалах, может работать штрафная система. Т.е. проектной команде объясняется, что их зарплата состоит из двух частей: фиксированной N и переменной M. По итогам каждого месяца от M могут отниматься некоторые суммы, если к работе сотрудника были претензии. Например, выкатил билд с большим количеством багов, т.е. не потратил достаточного количества своего времени -- вместо (N+M) получил (N+M/2). Пообещал что-то сделать, но не сделал -- лишился M вообще и получил только N. Это не простая схема, и работает она при соблюдении важных условий. Во-первых, важно выдерживать принцип уменьшения зарплаты при плохой работе (это совсем другое дело, чем премирование за хорошую работу). Во-вторых, обоснование уменьшения переменной части должно быть максимально объективным, схема перестанет работать, если сюда будут вмешиваться личные отношения. Поэтому здесь хорошо работает фиксация целей/обещаний, количественные оценки (количество ошибок, частота возникновения отказов в эксплуатации и т.д.), перекрестные оценки работы (например, работу программиста оценивают другие программисты, тестировщики, внедренцы, техписатели). В-третьих, сроки применения такой схемы должны быть небольшими и ограниченными (например, такая система может быть введена при вытаскивании проекта, оказавшегося в жопе в сложной ситуации, или при серьезном обновлении/запуске нового сервиса).
Другие схемы премирования, например, оплата формально зафиксированных сверхурочных, или же выплата привязанных к календарю премий (за квартал, полугодие, год), в принципе, тоже могут работать. Но здесь не так все однозначно и скрытых проблем не меньше, чем явных достоинств. Скажем, какой вообще смысл в квартальных премиях, если компания занимается выпуском версий своих продуктов, даты релизов не привязаны к концам кварталов и по итогам релиза выплачивается проектная премия? Или, например, наличие квартальной премии может стать поводом не увольняться сразу, а просидеть на работе тихо и спокойно еще месяц-полтора, чтобы увеличить свое выходное пособие. Т.е. у человека желания работать уже нет, но место он занимать будет. А то и не просто занимать, но и демотивировать своих коллег, если те окажутся в курсе его намерений. В общем, тут нужно вспоминать про наличие собственной головы на плечах...
Пожалуй, на этом очередное разбирательство с темой KPI завершу. Спасибо всем прочитавшим до этого места, значит писал что-то интересное и, возможно, полезное :) Если же кто-то сочтет возможным распространить ссылку на эту серию постов, то я буду очень этому рад и это будет самая лучшая компенсация за потраченное время.
Комментариев нет:
Отправить комментарий