Comments 80
- Общее количество отработанных часов
- Процентное соотношение часов отработанных по коммерческим задачам к общему объёму отработанных часов
- Расхождение между оценкой задач и реальным временем выполнения
- Процентное соотношение реально отработанных часов в месяц к плановым
Если задача типовая — то менеджер
Если не типовая, то оценку делает руководитель подразделения
2) По планированию производства
Тут у нас есть годовой финансовый план, исходя из него мы планируем загрузку производства по месяцам. А уже по реальным данным, ежемесячно за это отвечает руководитель производства и руководитель производственных подразделений.
2) На рост по грейдам
3) Да, на распределение премиального фонда внутри подразделения. На начальника тоже.
Смотря каких. Наши изменения мы вводили постепенно и явных зависимостей не заметили. Сейчас стало гораздо проще выявить проблемные места и заранее спровоцировать разговор с сотрудником. Многие сотрудники, которые по тем или иным причинам поменяли место работы, наоборот отмечали факт, что уровень нашей автоматизации гораздо сильнее, чем в новых компаниях и что многое приходилось делать в вордах и эксклюзив.
Походы в туалет или в курилку тоже учитываются?
На мой взгляд такая система на корню убивает желание сделать задачу раньше срока и распорядиться по-своему освободившимся временем.
Мало кто из программистов способен еффективно пахать по восемь часов в день, но при должной организации труда он вполне сможет справиться с восьмичасовым заданием за три-пять часов. Но при этом он уже будет не в состоянии сделать что-либо существенное. И что — тупить в монитор, высиживая положенное время?
Такое сильно демотивирует и побуждает искать более адекватную работу.
И уж, разумеется, на лояльность сотрудников компания может не расчитывать.
Конечно до такого бреда мы не доходим и не планируем, а постепенно переходим к более гибкой организации команд и их рабочего времени.
Ну и да, разработчик — молодец, решил задачу, на которую запланировано 8 часов за 4. Повысим норматив. Теперь подобная задача будет планироваться к выполнению за 6 часов. Так что разработчик, если он понял систему попросту будет затягивать выполнение задачи. Печально, но так ему будет «выгоднее».
Получается, не выгодно делать задачи быстрее, чтобы нормативы не пересматривали.
Почему? Поясните вашу логику.
Потому что у него не будет запаса по времени в следующий раз и он получит штраф (в виде отсутствия бонуса и поднятия грейда) и повышение плана на выработку. Поэтому разработчик, видя уязвимости вашего KPI (а их видно даже из статьи), будет максимально их эксплуатировать, а не стремиться получить себе больше проблем с их помощью.
PS. У нас "типовая задача" часто получается — "сделать неведомое нечто, что не делалось до сих пор", а "сделать отчёт", скорее, нетипичная.
Если же вы смогли найти сотрудников, которые искренне поддерживают ваш KPI и не стараются сломать/обойти/хакнуть его, а стопроцентно соблюдают (даже в ущерб себе) — ну молодцы вы. Счастья, здоровья и как там наш премьер говорил
У нас не ищут — нет формального KPI. А вот в Гугле ищут (об этом на Хабре была статья), и тут ищут, но это скрыто от начальства (никто же не будет хвастаться — "смотрите как я обманул вашу систему"). Так что посочувствуйте себе — вас обманывают, а вы делаете вид что всё нормально.
И я работал в компании, где одним из аспектов KPI было нахождение на рабочем месте (как коэффициент <=1, т.е. 146% было не получить пересиживая, но помножить з/п на <1 легко). Как итог — это был отличный опыт и он помог мне осознать что такие компании ~можно~нужно игнорировать сразу.
Да, разработчику в итоге нет смысла делать быстрее что-то, при этом он всегда будет время закладывать на оценке. Если оценили слишком мало, то даст понять почему задача сложная, найдет барьеры
Мне тут вот что интересно — а какая цель компании в связи с этой системой? Получить рентабельность за счет удешевления внутренних ресурсов? за счет большего контроля?
Если да, то это напоминает попытку выжать максимум от всего возможного, в том числе от сотрудников, и плевать на клиентов, ведь от них тоже будут все соки выжимать.
В таких местах каждый программист чувствует себя рабом, ресурсом, которого утилизируют по максимуму, не давая ни минуты простоя. Поэтому выше и были намеки на утечки кадров — в системе тотального контроля нет места внутренней мотивации делать крутой продукт.
В компаниях, где целью является, например «довольный клиент», все по-другому: там бизнес доверяет программистам, не следит за ними, за их «часами отработки». В то же время программисты доверяют бизнесу по части направления и стратегии и хотят делать лучший продукт на рынке
А вообще, бОльшая часть задач по разработке сайта (если не брать дизайн), они типовые, по которым у нас есть статистика за 2 года, и предварительная оценка довольна точная. Если программист не успевает ее сделать, значит проблема в его квалификации и повод его обучить и т.д.
«всегда ходите в туалет по большому на работе, вы не только используете туалетную бумагу, воду и унитаз работодателя, но вам за это еще и заплатят»
Несколько раз на нескольких предприятиях попадал на внедрение листков описания выполненной работы за день. Обычно у всех это был творческий процесс, который отнимал большой кусок рабочего времени, но очень развивал фантазию. Но, как временная мера для оценки работы отдела/организации, довольно эффективна.
У Болида есть возможность забрать данные из СКУД? Радуйтесь, что у вас не PERCo. Эти ребята даже баги закрывают с большой неохотой, а уж о доработке некоторых функций можно вообще забыть. Толком интеграции с другими системами нет, даже за деньги. И делать не собираются.
Сейчас на предприятии используем 1С Документооборот. Вот эти люди знают толк в извращениях.
Радуйтесь, что у вас не PERCo. Эти ребята даже баги закрывают с большой неохотой, а уж о доработке некоторых функций можно вообще забыть. Толком интеграции с другими системами нет, даже за деньги.
Не совсем понимаю, о чем Вы говорите, У нас полноростовые турникеты PERCo, датчики Biosmart и СКУД «Сигур».
" Сигур" вполне корректно управляет всей этой бодягой и скидывает табели рабочего времени в 1С.
СКУД у нас самый простейший, из него забираем сырые данные и далее визуализируем.
СКУД PERCo-WEB продолжает активно развиваться. Реализованы проекты: поддержка API; поддержка БД MySQL; поддержка биометрии PERCo; интеграция с 1С, мобильное приложение для удаленной регистрации событий и ряд других доработок. Новая версия системы выйдет уже в 3-ем квартале 2019 года. Если у вас есть дополнительные примечания/пожелания к доработкам, вы можете оставить координаты для связи или просто написать нам: feedback@perco.ru. Спасибо, отличного дня!
Ваша техподдержка меня уверяла еще в ноябре, что вы переходите на поквартальный выпуск релизов и в следующем релизе, то есть в 1 квартале 2019 года все будет исправлено. Вы сообщаете, что новая версия выйдет в 3 квартале. Пока я только слышал, что ваше ПО будет поддерживать
«поддержка API; поддержка БД MySQL; поддержка биометрии PERCo; интеграция с 1С, мобильное приложение для удаленной регистрации событий». Предоставить доступ в базу и описание полей вы отказываетесь, мотивируя это тем, что у вас там все может поменяться. Но, мне кажется, что это просто отговорка и не более. Если честно, то мне, например, API не нужно, а нужет просто доступ в базу, где я мог бы взять данные о проходах. Я в состоянии осознавать эти риски и, если что-то поменяется, исправить. Хотелось бы узнать реальную причину того, что вы не даете доступ к базе.
Я звонил в техподдержку раз 10 и написал не одно письмо для того, чтобы получить патч, который исправляет некоторые недоработки. И это касается неправильного учета рабочего времени. Сообщили мы об этом в ноябре, патч получили в феврале. Если бы вы знали, сколько раз я пожалел о выборе вашего продукта, выслушивая лекции руководителя о том, что я его убедил, что нам надо переходить на новый СКУД, т.к. он больше не поддерживается и если что-то сломается, то мы ничего сделать не сможем. Что у нас там был доступ к базе и запросами все доставалось. Что теперь не обойдешься простым изменением запросов к базе и небольшим исправлением логики. Что все наши самописные инструменты можно Shift+del. Что потратили деньги и теперь действительно ничего сделать не можем. Даже исправления бага с учетом мы ждем столько времени. Каждое начало месяца я выслушивал жалобы от отдела кадров и требования руководителя решить вопрос в конце концов. И, к сожалению, они были правы. Я сам наступил на эти грабли и втянул в это своих коллег.
И даже когда у вас выйдет новая версия, я 10 раз подумаю, переходить мне на нее или нет, т.к. если что-то не заработает, то за 4 месяца, пока будет предоставлен патч, я буду уволен или сам вручную буду записывать людей на проходной. Вам надо не новую версию выпускать, а пересмотреть подход к техподдержке.
ЗЫ Софт у вас неплохой, поэтому я его и выбрал, но я в который раз убеждаюсь, что техподдержка, возможность получения информации по запросу, быстрое исправление багов, обратная связь — это основной критерий по выбору продукта.
любой штраф,
камера в помещении,
расписание чего либо, касающееся жизнедеятельности,
дресскод для бэкенд работников,
появление необходимости расписывать свои действия.
Сейчас мы по пятницам играем в настолки, все вместе и руководство тоже, не заметил, чтобы были проблемы от этого.
Не считаю что видеть коллег(я сейчас про разработчиков) это хорошо. Все разные. Это задача руководителя взаимодействовать с сотрудником и давать обратную связь по вопросам его эффективновности.
На счет видимости коллег — возможно вы правы, но у себя мы такой проблемы не заметили или не замечаем)
Я отошел от точечных оценок и для разработчиков и планирования использую интервальные, что бы с одной стгроны разработчики не были постоянно под прессингом, с другой были границы и задача не «занимала все отведенное для нее время».
У нас небрльшой коллектив. Поэтомк особо не до экспериментов. Но подозреваю, что если раскрыть для всех статистику, то производительность выравняется, но не в лучшую сторону. Сейчас у всех она равна/лучше нормативной, при этом, понятно, у всех свои отклонения…
Увлекательно у вас работать, наверное. /сарказм
Я работаю в компании со свободным графиком, которая не занимается подсчётом секунд, проведённых в туалете и не использует в качестве KPI расхождение между плановыми и реальными часами.
К вам работать я пойду только в аварийной ситуации.
А есть большая разница между учётом секунд в туалете и "Учет времени нахождения на рабочем месте. У каждого сотрудника есть индивидуальный электронный ключ, которым он открывает дверь, чтобы попасть в офис. Мы установили систему контроля доступа Bolid, которая собирает все данные о входе и выходе сотрудников. Так мы знаем, сколько времени каждый человек находится в офисе."?
Я вполне серьёзно говорю, что при таком отношении к сотрудникам вы — работодатель последнего уровня.
Дело не в логах доступа, а в использовании этих данных для оценки времени наличия человека в офисе и использования этих данных для оценки его продуктивности.
Возможно стиль материала получился такой, что кажется, что отслеживание времени сотрудника сведено до параноидального, но это совершенно не так.
Весь процесс мониторинга сводится не к разбирательству, почему конкретный сотрудник делал задачу долго или обедал дольше положенного, а к выявлению узких мест в бизнес процессах на основе данных из разных источников.
В ходе объединения разного рода статистических данных по сотрудникам/отделам/проектам и дальнейшего их анализа нам многое удалось улучшить, в том числе и в жизни персонала.
если человек не справляется, его лучше уволить, чем стоять надсмотрщиком
Уволить это самое простое. Мы стараемся за счет подобных анализов выявлять пробелы и тонкие места и решать их. Кроме этого, наличие, назовем так «логирования» действий сотрудников, позволяет быстро разобраться в разного рода форс-мажорах.
До этого я работал в конторе, где даже выходить покурить нужно было по карточке и в конце месяца считалась каждая минута. Кто сколько обедал, кто не доработал, кто опоздал. Это трэш и содомия, в конце недели многие тупили в соцсеточках чтобы нагнать нужные часы, хотя таски все по сути были сделаны (до людей через некоторе время дошло, что лучше закладывать планы с запасом). В яндексе такого совершенно не наблюдалось, по крайней мере для кодеров, единственно выжным был только результат а не просиживание штанов или микроменеджмент.
Уволить это не простое. Но и воспитывать человека не получится. Может для грузчиков или первой линии саппорта это и сработает, но для работников интеллектуального труда это не вариант. Я сам увольнял людей и увольнялся оттуда. Пытаться «воспитать» кодера, который выдохся по той или иной причине практически не реально. Можно только перевести в другую команду (отдел) или уволить.
Человеческие проблемы надо решать человеческим общением, а не метриками над данными. И в общении не использовать эти метрики и сами данные, это только испортит нормальные рабочие отношения.
отдельные моменты улыбнули:
Мы вышли из этой ситуации, зашив количество проектов и сроки их сдачи в KPI менеджера и разработчика. Так менедджер всеми силами старается контролировать разработчиков, чтобы те не превышали свои сроки по задачам и сдавали их вовремя.
Менеджеры когда то не наседали? по моему опыту руководители всегда хотят получить вчера, то что им пришло в голову сегодня. Мне исполнителя жалко, он и раньше не знал как сделать работу что бы не потерять в качестве, а теперь вы его ещё и с секундомером у него над душой стоите. Хотя если работа типовая, то это наверное правильная практика.
Совсем другое дело что с вводом лимитов на «операции» и наглядной демонстрацией истечения сроков — исполнители могут наглядно понимать что уже нет времени копаться в нюансах и пора форсировать работу. Это плюс.
Мы видим, кто постоянно опаздывает, а кто приходит вовремя.
а тех кто постоянно задерживается? Или после часа X охрана всех выгоняет?
По задержкам — охрана не выгоняет, но мы контролем этот показатель и работаем с сотрудниками, кто допоздна сидит в офисе, выясняем причины переработок, т.к. это один из первых признаков выгорания.
Kuz_ma
Вообще — все что вы делаете это правильно. Просто в РФ еще много народу, который думает что бизнес это такая социальная функция. В большинстве стран с высокой производительностью труда ни кто не удивляется СКУД, подсчёту часов и нормированию. Не сдавайтесь ;)
А про менеджеров пишите — интересно почитать.
Да, если вам и дальше будут возражать и говорить про "компании со свободным графиком", то тут все достаточно просто.
Если, грубо, 2 типа производства: в одном территориальная составляющая важна, во втором — нет.
Если дизайнер может делать макет сам общаясь по телефону, то верстальщик, скажем, должен переодически сверяться с коллегой все ли верно + там рядом QA.
И сверху этого — личная культура сотрудника. Т.е. есть люди, которые не могут работать "вне офиса".
Я видел схемы, при которых у сотрудников есть 5 дней в месяц, которые они могут работать удаленно. Контролируется все так же: логин в систему, сдача задач и т.п. часто такое решение позволяет выпустить пар и снять иллюзию "потогонного производства". Но, повторюсь, это не со всеми людьми работает и нагружает менеджера юнита (ему же нужно понять пойдет ли и на сколько хорошо).
Мы делаем так: у нас у всех почасовая ставка + нормирование. План идёт на неделю, месяц, квартал. Строится сверху вниз от воронки продаж. Часть сотрудников может не приходить в офис, но обязана быть доступен по 3 каналам в течение рабочего дня (у нас своя рабочая среда и, по сути, это значит что он должен рагировать на push из мобильного клиента.
Некоторым (около 25% штата) такой вольницы не досталось и они обязаны быть в офисе и каждый рабочий день.
У нас есть бот, которому можно быстро отписать по задаче комментарий или закрыть ее со списанием часов. Даже логинется в систему не нужно. Т е. Мы постарались максимально разгрузить и упростить отчётный функции для человека, не потеряв в качестве.
KPI для разработчика строим на основе ножниц оценка/факт. Сам KPI идет снизу вверх, т.е.если у меня сфакапил Петя из отдела А, то я, как директор компании, не получаю часть своего бонуса. + кросс-отдельные KPI — когда руководитель отдела Б зависит от результатов отдела А, а руководитель отдела А зависит от скорости решения задачи отделом Б (т.е. ему нужно передать задачу так, что бы Б уложился в план).
Получается некая война внутри — но сверху находится линейный руководитель который всех мирит + hr постоянно оценивает эффективность kpi и помогает.
Если мы видим, что какая-то функция у нас не нагружается нужным образом, мы ее выносим на аутсорс. Скажем бухгалтерия, первая линяя поддержки.
Сей час 120+ человек, при этом мы скакнули с 50 за год.
снижаться рентабельность проектов
Если не секрет, как вы эту самую рентабельность подсчтиваете?
habr.com/ru/company/twins/blog/181886
habr.com/ru/company/twins/blog/311380
Потому мы не считаем время, которое уходит на выполнение работы менеджерами и аккаунт-менеджерами
А вы учитываете, что эти же самые менеджеры могут за день написать разработчику, который занят одной системой, «100500 сообщений» по системам, которыми сейчас разработчик не должен заниматься? По-сути получается, что разработчик может вести еще 10 систем других 10 менеджеров в чисто консультативном порядке.
У меня был опыт, что из-за таких моментов время на текущую задачу уходило намного больше чем ожидалось.
Пот, слезы и учет времени — как мы повышали рентабельность компании