Судя по нашей статистике — нет, не многие. За полтора года именно из-за «слежки» с нами отказалось работать человека 3-5.
Ну и вообще шпионом называть такой софт некорректно. Шпион — это когда он включается и что-то собирает без твоего ведома. А тут совсем другой случай: пока сотрудник сам программу не запустит, тем самым обозначив, что он «пришёл на работу» — никакой слежки не начнётся. Ну, я конкретно про хабстафф говорю, не сочтите за рекламу: мы его «поведение» детально тестировали.
Перед тем, как остановиться на конкретном решении, мы протестировали его на себе. И только потом стали требовать от остальных сотрудников.
Конечно, оно доставляет некоторые неудобства тем, кому часто приходится переключаться между задачами и проектами — в основном это тимлиды/руководитель офиса. То тут кодревью, то там джуну помогал, то здесь менеджера консультировал… но это неудобство обусловлено не слежкой как таковой, а тем, что сложно уследить, когда ты перестал заниматься одной задачей, и начал заниматься другой. Но частое переключение между задачами для программиста на любой позиции — в целом не норм, так что с этим явлением надо в принципе бороться.
Что касается конкретно меня — нет, я давно уже не запускал этот софт. Во-первых, было бы странно следить за самим собой. Прибыль компании — мой хлеб, если компания будет в убытке, то лично мне есть будет нечего, поэтому сценарий «солдат спит — служба идёт» как-то не работает :-) Во-вторых, со временем на непосредственное участие в разработке на каком-либо одном проекте стало оставаться всё меньше и меньше времени. Разве что «пожар тушить», а тут уже не до бюрократии (относится ко всем). Ну а когда пол дня проводишь на встрече с клиентом, то компьютер тут уже вообще ни при чем, хотя иногда беру его с собой.
Какой неожиданный вывод. К сожалению, «честность и адекватность» — качества, которые никак нельзя проверить на этапе собеседования. Это можно подтвердить только много… месячным, если не многолетним сотрудничеством с человеком. «Пусть он в связке в одной с тобой — там поймешь, кто такой».
Тут может всплыть вопрос о том, так ли необходимо требовать от проверенных сотрудников включение хабстаффа — ведь с ними уже всё ясно, в них можно быть уверенными. Думаю, хуже от этого точно не будет:
Мы потому в них и уверены, потому что в рабочее время они работают. А значит и им самим включить хабстафф не западло — всё равно на скриншотах мы увидим код наших проектов да знакомые чаты.
Это мотивирует как-то классифицировать свой труд, а не делать абстрактную «работу». Поясню. В хабстафф можно указывать, над каким конкретно таском в редмайне идёт работа в данный момент, сколько на него ушло времени. И эта информация важна уже не столько в плане контроля сотрудников, сколько для расчета с клиентами.
Всё в жизни меняется, и сотруднику может, например, перестать быть интересным с нами работать. Это нормально. Хорошо, если он прямо и открыто это скажет. Но бывали и случаи, когда добросовестный в прошлом сотрудник переставал выполнять свои обязанности, концентрируясь на личных делах, вроде поиска другой работы. Солдат спит, служба идёт, фиксированный оклад на карточку капает — ну не прелесть ли?
Вообще на случай любого факапа никогда не помешает иметь дополнительную «телеметрию», чтобы лучше провести «разбор полётов»
В команде из 5-7 хорошо знакомых человек и 1,5 проектами ещё можно все спорные вопросы разрулить «вручную». Когда же число разработчиков переваливает за 40, а число проектов близится к сотне, то анализ git log и проникновенные беседы с каждым разработчиком с целью выяснить причины инцидента могут занять катастрофически много времени. Наличие «фотографии рабочего дня» позволяет решать некоторые спорные ситуации за минуты, вместо многочасовых разборок.
Я, к примеру, ещё могу разобрать ситуацию, анализируя логи git, разгребая код на dev-площадках и т.п. А вот мои партнеры или менеджеры — уже не очень, т.к. не все обладают достаточными техническими знаниями на бэкенде. Но им тоже может понадобиться это делать, например как сейчас, когда я в отпуске. На случай «разбора полётов» человеком, не сильно разбирающимся в технических деталях, наличие данных о полноценном рабочем дне от такого треккера позволяет оградить разработчика от беспочвенных наездов.
Расскажу-ка я и о своём «болоте», в котором работаю руководителем отдела разработки.
У нас в DigitalWand распределенная команда разработчиков, почти все работают за личными компами. Но ещё на этапе собеседования я предупреждаю, что нужно будет поставить HubStaff на комп, который будет скринить экран и следить за активностью мышки-клавы. Те, кто на это не соглашаются, или соглашаются, но игнорируют это правило, с нами не работают.
Теперь о том, как мы используем имеющиеся данные.
Хороший начальник контролирует результат. Плохой — процесс.
Полностью согласен с данным утверждением. В нормальной ситуации мы контролируем именно результат, который показывает сотрудник: соблюдение сроков выполнения задачи, качество кода продукта и степень удовлетворённости клиента. Если тут всё хорошо или почти хорошо, то нет смысла тратить своё время и лезть изучать скриншоты с чужого экрана. В этом плане нам действительно абсолютно без разницы, чем занимается сотрудник во время рабочего дня. В тему про «нескучные видео»: за одним сотрудником было замечено, что он такое смотрел, но, тем не менее, за свой испытательный срок неплохо прокачался, показал отличный результат, так что всем в общем-то пофиг.
Однако бывают и грустные истории. Если сотрудник превращается в генератор факапов, то, конечно, можно начать «рубить головы» вслепую, но куда лучше было бы сначала разобраться. Как разобраться? Посмотреть на процесс! Если мы видим, что рабочий день сотрудника состоит из решения его личных проблем или «нескучного видео», то причина его неуспеваемости очевидна. Пока что мой опыт показывает, что увещевательные беседы с такими людьми не приносят результата, поэтому сейчас мы максимально быстро с ними расстаёмся.
Если же я вижу, что в целом человек занимался задачей, но по какой-то причине у него не получилось — начинаем искать причину. Пережатые сроки? Нечеткие требования? Слишком сложная задача? Не было помощи от тимлида? Не было информации от менеджера? И т.п.
В целом, на этом роль «слежения за сотрудниками» оканчивается. Время, отработанное в Hubstaff, не используется при вычислении KPI, равно как и скриншоты с экрана. Время от времени некоторые сотрудники в панике мне пишут: «Лёх, я забыл включить Hubstaff, что мне делать, как исправить, пол дня отметилось, что я не работал!.. Меня теперь покарают??..». «Забить, и не забыть включить в следующий раз» — единственный адекватный ответ.
Выше я писал, что встречаются люди, которые резко негативно относятся к «слежке», либо же на словах соглажаются с «правилами игры», на деле не собираясь их выполнять. Я порядком нагулялся по таким граблям, и лично для себя сделал вывод, что с такими удалёнщиками лучше сразу не связываться, или не тратить время на «второй шанс». Как правило, с ними все равно ничего не выходило, даже если они потом включали HubStaff, качество работы оставалось низким. Оно и логично: если человеку есть что скрывать в рабочее время, скорее всего он собирается заниматься чем-то ещё. К примеру, подхалтуривать, получая у вас фикс, а со стороны — почасовку.
Если бы все сотрудники поголовно были бы честными адекватными людьми, готовыми добросовестно выполнять взятые на себя обязательства, то не было бы такого обилия следящего софта на рынке. К которому я и сам по началу отнёсся негативно. Но сейчас должен признать, что польза от него все-таки есть.
Так я о том и пишу, что если серьёзная травма — то скорее всего «анастезия» получится сама собой, без какой-либо предварительной практики, у сколь угодно не подготовленного к этому человека. В остальных случаях уже становится меньше физиологии, больше психологии.
Ну травмы, как правило, достаточно внезапны, и это не просто с неприятные ощущения, а с серьёзные повреждения. Не знаю, с чем именно это связано: с избытком ли сигналов к мозгу, или с тем, что локальные болевые рецепторы сами повреждены, или с уровнем адреналина — а только боль в этом случае может начаться очень не сразу, первое время действительно не будешь понимать, что произошло. Зато потом…
Это так и выросло из «негативной обратной связи». Навсегда запомню этот день: 2013 год, обычный летний день, и ни что не предвещало беды, как вдруг…
Двое молодчиков написали каждый по своему модулю методом слепого копипаста. В результате появилось два класса-близнеца для работы с базой. Метод Add был скопирован у третьих лиц, а поэтому не добавлял элементы, если обязательные поля были, внимание, заполнены: функцию валидации тоже криво откуда-то скопировали. Но Add всё равно никто не пользовался, а добавляли новые записи методом Edit. На мой вопрос «почему» ответ был «а не знаю, я откуда-то скопировал».
После того, как эти люди были устранены с проекта, я ещё порядком начитался кода, написанного «в лучших традициях», а потом не выдержал. D7 тогда ещё не было, поэтому сначала пришлось написать простенькую ORM, чтобы генератор админки вообще стал возможен.
Так что не уверен, надо ли быть каким-то специальным человеком, чтобы заметить, что король-то голый…
Ну и вообще шпионом называть такой софт некорректно. Шпион — это когда он включается и что-то собирает без твоего ведома. А тут совсем другой случай: пока сотрудник сам программу не запустит, тем самым обозначив, что он «пришёл на работу» — никакой слежки не начнётся. Ну, я конкретно про хабстафф говорю, не сочтите за рекламу: мы его «поведение» детально тестировали.
Конечно, оно доставляет некоторые неудобства тем, кому часто приходится переключаться между задачами и проектами — в основном это тимлиды/руководитель офиса. То тут кодревью, то там джуну помогал, то здесь менеджера консультировал… но это неудобство обусловлено не слежкой как таковой, а тем, что сложно уследить, когда ты перестал заниматься одной задачей, и начал заниматься другой. Но частое переключение между задачами для программиста на любой позиции — в целом не норм, так что с этим явлением надо в принципе бороться.
Что касается конкретно меня — нет, я давно уже не запускал этот софт. Во-первых, было бы странно следить за самим собой. Прибыль компании — мой хлеб, если компания будет в убытке, то лично мне есть будет нечего, поэтому сценарий «солдат спит — служба идёт» как-то не работает :-) Во-вторых, со временем на непосредственное участие в разработке на каком-либо одном проекте стало оставаться всё меньше и меньше времени. Разве что «пожар тушить», а тут уже не до бюрократии (относится ко всем). Ну а когда пол дня проводишь на встрече с клиентом, то компьютер тут уже вообще ни при чем, хотя иногда беру его с собой.
Тут может всплыть вопрос о том, так ли необходимо требовать от проверенных сотрудников включение хабстаффа — ведь с ними уже всё ясно, в них можно быть уверенными. Думаю, хуже от этого точно не будет:
У нас в DigitalWand распределенная команда разработчиков, почти все работают за личными компами. Но ещё на этапе собеседования я предупреждаю, что нужно будет поставить HubStaff на комп, который будет скринить экран и следить за активностью мышки-клавы. Те, кто на это не соглашаются, или соглашаются, но игнорируют это правило, с нами не работают.
Теперь о том, как мы используем имеющиеся данные.
Полностью согласен с данным утверждением. В нормальной ситуации мы контролируем именно результат, который показывает сотрудник: соблюдение сроков выполнения задачи, качество кода продукта и степень удовлетворённости клиента. Если тут всё хорошо или почти хорошо, то нет смысла тратить своё время и лезть изучать скриншоты с чужого экрана. В этом плане нам действительно абсолютно без разницы, чем занимается сотрудник во время рабочего дня. В тему про «нескучные видео»: за одним сотрудником было замечено, что он такое смотрел, но, тем не менее, за свой испытательный срок неплохо прокачался, показал отличный результат, так что всем в общем-то пофиг.
Однако бывают и грустные истории. Если сотрудник превращается в генератор факапов, то, конечно, можно начать «рубить головы» вслепую, но куда лучше было бы сначала разобраться. Как разобраться? Посмотреть на процесс! Если мы видим, что рабочий день сотрудника состоит из решения его личных проблем или «нескучного видео», то причина его неуспеваемости очевидна. Пока что мой опыт показывает, что увещевательные беседы с такими людьми не приносят результата, поэтому сейчас мы максимально быстро с ними расстаёмся.
Если же я вижу, что в целом человек занимался задачей, но по какой-то причине у него не получилось — начинаем искать причину. Пережатые сроки? Нечеткие требования? Слишком сложная задача? Не было помощи от тимлида? Не было информации от менеджера? И т.п.
В целом, на этом роль «слежения за сотрудниками» оканчивается. Время, отработанное в Hubstaff, не используется при вычислении KPI, равно как и скриншоты с экрана. Время от времени некоторые сотрудники в панике мне пишут: «Лёх, я забыл включить Hubstaff, что мне делать, как исправить, пол дня отметилось, что я не работал!.. Меня теперь покарают??..». «Забить, и не забыть включить в следующий раз» — единственный адекватный ответ.
Выше я писал, что встречаются люди, которые резко негативно относятся к «слежке», либо же на словах соглажаются с «правилами игры», на деле не собираясь их выполнять. Я порядком нагулялся по таким граблям, и лично для себя сделал вывод, что с такими удалёнщиками лучше сразу не связываться, или не тратить время на «второй шанс». Как правило, с ними все равно ничего не выходило, даже если они потом включали HubStaff, качество работы оставалось низким. Оно и логично: если человеку есть что скрывать в рабочее время, скорее всего он собирается заниматься чем-то ещё. К примеру, подхалтуривать, получая у вас фикс, а со стороны — почасовку.
Если бы все сотрудники поголовно были бы честными адекватными людьми, готовыми добросовестно выполнять взятые на себя обязательства, то не было бы такого обилия следящего софта на рынке. К которому я и сам по началу отнёсся негативно. Но сейчас должен признать, что польза от него все-таки есть.
Двое молодчиков написали каждый по своему модулю методом слепого копипаста. В результате появилось два класса-близнеца для работы с базой. Метод Add был скопирован у третьих лиц, а поэтому не добавлял элементы, если обязательные поля были, внимание, заполнены: функцию валидации тоже криво откуда-то скопировали. Но Add всё равно никто не пользовался, а добавляли новые записи методом Edit. На мой вопрос «почему» ответ был «а не знаю, я откуда-то скопировал».
После того, как эти люди были устранены с проекта, я ещё порядком начитался кода, написанного «в лучших традициях», а потом не выдержал. D7 тогда ещё не было, поэтому сначала пришлось написать простенькую ORM, чтобы генератор админки вообще стал возможен.
Так что не уверен, надо ли быть каким-то специальным человеком, чтобы заметить, что король-то голый…