Я и в windows его не представляю :-) kwrite всегда со мной, недавно удалось успешно пересобрать свежи gwenview и dolphin на венду — радости нет предела!
Ну никто не говорил, что неграмотность вчерашних выпускников — это какая-то неразрешимая проблема. В одном только этом треде сколько вариантов набросали. С этой проблемой вполне посильное справиться, и справляемся. Речь о том, что "розовые сопли" о том, что джунам не доплачивают — не обоснованы. Напротив, многие получают от компаний больше, чем они того достойны.
Кто ж спорит, решается. Работодателем, не ВУЗами, вот в чем беда. Нередко ещё и преодолевая высоченное ЧСВ новоприбывшего. На фоне чего рассуждения о низкой стартовой зарплате выглядят ещё более дикими.
Меня как-то даже возмутила точка зрения, что зарплаты в РФ "несправедливые" для джунов, 100к это психологический порог, и зелёные новички достойны большего. Не надо мешать в кучу разработчиков разных уровней! Редкий джун в нашей стране умеет вообще хоть что-нибудь. Те, кто только вышел из института, часто приходят не то что без портфолио и своих проектов, а реально не написав ни одной строчки кода! Это в лучшем случае бесплатная стажировка, о какой зарплате вообще речь?! И даже когда его научили необходимому минимуму — все равно маловероятно, что он сможет выполнять какую-либо полезную работу, на которой работодатель сможет извлечь прибыль. И на этом этапе ЗП ему платится не за принесенную пользу, а чтобы не отбить желание учиться / не помереть с голоду. Посчитать время, которое на джунов вынуждены тратить мидлы и сеньёры, чтобы проконтролировать их работу и чему-то научить — так они ещё пол года будут отрабатывать потраченное на них время. Минимум.
Итого, моё мнение из личного опыта в сфере php-разработки: джуны совсем нулевые, часто их запросы сильно не соответствуют имеющимся знаниям, зарплаты джунов нереально завышены, особенно в Москве и Питере. Кто по-честнее, понимают свой слабый уровень и всеми силами стараются его поднять, очень скоро выходя из категории "джун". Но многие "яжпрограммисты" изначально настроены сидеть на шее за счёт хайпа на рынке, технической неграмотности работодателей и рекрутёров, заведомой мертворождённости стартапов.
Уж чего точно не надо делать, так это повышать стартовые зарплаты для ждунов. Хорошие деньги даются за реальные знания и умения, и молодые специалисты особенно должны это чувствовать, чтобы был стимул расти и впоследствии на высоте держать свой уровень. Сегодня же многим платят просто "за красивые глаза".
И правда как из параллельного мира. У нас ребят, которые не только код писать могут, но и с клиентом пообщаться, и ТЗ критически рассмотреть, и что-то дельное по проекту/работе в целом предложить — да с руками рвут, даже в рамках одной компании у менеджеров грызня за таких ребят! Ведь они фигачат как боги, при чем сразу по всем фронтам! И тут уже приходится следить, чтобы их не перегружали работой, и в какой-то мере да, действительно искусственно ограничивать круг задач, которые им могут поставить решать.
Но это чисто организационные моменты. Никакого клейма нет, боже упаси! И если, например, у "простого менеджера" вдруг обнаруживается технический бэкграунд, то это же колоссальный рост его авторитета в команде + компетентности в глазах клиентов.
В общем, да, согласен, возможно автора и правда кто-то обидел.
Помимо форматирования ещё и содержимое кириллицы в ответе выводится как есть. Какое-нибудь \u041F\u0440\u0438\u0432\u0435\u0442 не особо читабельно, даже если его отформатировать.
С ios придется заморачиваться, даже в случае кроссплатформенных решений. Даже если представить, что приложение написано на базе cordova и идеально работает на всех платформах, для android правила сборки для деплоя одни, для ios — другие. Люди, работавшие для android, считают, что деплой в ios адово сложен — и наоборот...
На деле же сложное кроссплатформенное приложение в некоторых случаях ведёт себя по-разному на разных платформах, так что требуются фиксы в коде под отдельные платформы. Плюс, в случае cordova, хорошо бы точно понимать список необходимых нативных функций, посмотреть, какими плагинами они поддерживаются, в каком объёме р всеми ли нужными платформами. Чтобы не было неприятных сюрпризов в самый разгар разработки, когда отступать уже поздно.
В общем, да, заморачиваться придётся в любом случае. Так что совет начать с мобильной версии сайта / адаптивного дизайна очень правильный, поддерживаю!
Вот потому, наверное, Тошиба и закрылась, ибо качественные долговечные устройства по низкой цене и без кричащей агрессивной рекламы. Вообще, как правило, хорошие устройства находятся где-то за пределами всеобщей известности и продавцы с наименьшей вероятностью будут их впаривать.
Пишет владелец модели Тошибы 2011 года, непрерывно юзающий это устройство ~25 часов в неделю и до сих пор довольный, как слон. Вот только закупился запчастями ещё на 5 лет вперед, на случай снятия их с производства.
Передача задач и проста, и сложна — нужно проверять, кто свободен на данный момент, лично обращаясь к разработчикам и менеджерам проектов. Мне пока не удалось придумать ничего эффективнее обычного диалога, хоть чутьё и подсказывает, что должна быть какая-то возможность сделать это проще и прозрачнее.
Тоже страдаем у себя в компании, перебиваясь чатиками да заметками… Треккер типа редмайна — слишком неповоротлив для контроля оперативной обстановки, какая-нибудь диаграмма ганта — протестировал кучу решений, почти везде за основу берется «прокет», на коротый распределяется «ресурс», и дальше предполагается, что этот «ресурс» так и остается на проекте.
В реальности же, когда приходит дедушка факап, ресурсы безжалостно перетасовываются между проектами, картина за неделю может сильно поменяться. В этом плане было бы удобнее иметь другой вариант «ганта»: когда в основе у нас лежит разработчик, а к нему уже цепляются проекты, с указанием, с какой по какую даты в каком объёме он каждым из них занимается. Но пока подходящего решения такого типа не нашли. Откопали ganttic.com, но это ж, блин, космический корабль, поддерживать его в актуальном состоянии — всё равно что второй редмайн вести.
Если есть идеи/прозрения/советы по этому вопросу — был бы весьма благодарен.
Эмм, зачем уделять столько внимания скриншотам чужого экрана, а тем более заставлять всех следить за всеми? Если результат есть, в сроки укладываемся, сотрудник на связи в оговоренное время и оперативно решает вопросы, то и смотреть за человеком не за чем. А уж тем более запускать такую систему «доносов».
Программист должен спокойно работать и ни на что постороннее не отвлекаться. Сотрудник должен работать не потому, что за ним кто-то следит, а потому что ему четко видна связь между выполненной работой и полученными деньгами.
Выше я два раза отмечал, что сотрудник получает фикс. Прочтите внимательнее, на ваш вопрос я уже отвечал.
Что касается почасовки: она таки целесообразна в некоторых случаях. В целом мы спокойно относимся к тому, что человек работает в своём графике — иначе и быть не может, Россия раскинулась на 11 часовых поясов, а еще есть Украина… глупо заставлять всех работать в одно время. Но график сотрудника должен быть предсказуем. Если же с этим проблемы, то мы согласны предложить почасовую оплату при условии выработки N часов в неделю.
Вообще не берусь судить, как в других сферах, а в web-разработке время-деньги, поэтому его просто нельзя не учитывать.
Судя по нашей статистике — нет, не многие. За полтора года именно из-за «слежки» с нами отказалось работать человека 3-5.
Ну и вообще шпионом называть такой софт некорректно. Шпион — это когда он включается и что-то собирает без твоего ведома. А тут совсем другой случай: пока сотрудник сам программу не запустит, тем самым обозначив, что он «пришёл на работу» — никакой слежки не начнётся. Ну, я конкретно про хабстафф говорю, не сочтите за рекламу: мы его «поведение» детально тестировали.
Перед тем, как остановиться на конкретном решении, мы протестировали его на себе. И только потом стали требовать от остальных сотрудников.
Конечно, оно доставляет некоторые неудобства тем, кому часто приходится переключаться между задачами и проектами — в основном это тимлиды/руководитель офиса. То тут кодревью, то там джуну помогал, то здесь менеджера консультировал… но это неудобство обусловлено не слежкой как таковой, а тем, что сложно уследить, когда ты перестал заниматься одной задачей, и начал заниматься другой. Но частое переключение между задачами для программиста на любой позиции — в целом не норм, так что с этим явлением надо в принципе бороться.
Что касается конкретно меня — нет, я давно уже не запускал этот софт. Во-первых, было бы странно следить за самим собой. Прибыль компании — мой хлеб, если компания будет в убытке, то лично мне есть будет нечего, поэтому сценарий «солдат спит — служба идёт» как-то не работает :-) Во-вторых, со временем на непосредственное участие в разработке на каком-либо одном проекте стало оставаться всё меньше и меньше времени. Разве что «пожар тушить», а тут уже не до бюрократии (относится ко всем). Ну а когда пол дня проводишь на встрече с клиентом, то компьютер тут уже вообще ни при чем, хотя иногда беру его с собой.
Какой неожиданный вывод. К сожалению, «честность и адекватность» — качества, которые никак нельзя проверить на этапе собеседования. Это можно подтвердить только много… месячным, если не многолетним сотрудничеством с человеком. «Пусть он в связке в одной с тобой — там поймешь, кто такой».
Тут может всплыть вопрос о том, так ли необходимо требовать от проверенных сотрудников включение хабстаффа — ведь с ними уже всё ясно, в них можно быть уверенными. Думаю, хуже от этого точно не будет:
Мы потому в них и уверены, потому что в рабочее время они работают. А значит и им самим включить хабстафф не западло — всё равно на скриншотах мы увидим код наших проектов да знакомые чаты.
Это мотивирует как-то классифицировать свой труд, а не делать абстрактную «работу». Поясню. В хабстафф можно указывать, над каким конкретно таском в редмайне идёт работа в данный момент, сколько на него ушло времени. И эта информация важна уже не столько в плане контроля сотрудников, сколько для расчета с клиентами.
Всё в жизни меняется, и сотруднику может, например, перестать быть интересным с нами работать. Это нормально. Хорошо, если он прямо и открыто это скажет. Но бывали и случаи, когда добросовестный в прошлом сотрудник переставал выполнять свои обязанности, концентрируясь на личных делах, вроде поиска другой работы. Солдат спит, служба идёт, фиксированный оклад на карточку капает — ну не прелесть ли?
Вообще на случай любого факапа никогда не помешает иметь дополнительную «телеметрию», чтобы лучше провести «разбор полётов»
В команде из 5-7 хорошо знакомых человек и 1,5 проектами ещё можно все спорные вопросы разрулить «вручную». Когда же число разработчиков переваливает за 40, а число проектов близится к сотне, то анализ git log и проникновенные беседы с каждым разработчиком с целью выяснить причины инцидента могут занять катастрофически много времени. Наличие «фотографии рабочего дня» позволяет решать некоторые спорные ситуации за минуты, вместо многочасовых разборок.
Я, к примеру, ещё могу разобрать ситуацию, анализируя логи git, разгребая код на dev-площадках и т.п. А вот мои партнеры или менеджеры — уже не очень, т.к. не все обладают достаточными техническими знаниями на бэкенде. Но им тоже может понадобиться это делать, например как сейчас, когда я в отпуске. На случай «разбора полётов» человеком, не сильно разбирающимся в технических деталях, наличие данных о полноценном рабочем дне от такого треккера позволяет оградить разработчика от беспочвенных наездов.
Расскажу-ка я и о своём «болоте», в котором работаю руководителем отдела разработки.
У нас в DigitalWand распределенная команда разработчиков, почти все работают за личными компами. Но ещё на этапе собеседования я предупреждаю, что нужно будет поставить HubStaff на комп, который будет скринить экран и следить за активностью мышки-клавы. Те, кто на это не соглашаются, или соглашаются, но игнорируют это правило, с нами не работают.
Теперь о том, как мы используем имеющиеся данные.
Хороший начальник контролирует результат. Плохой — процесс.
Полностью согласен с данным утверждением. В нормальной ситуации мы контролируем именно результат, который показывает сотрудник: соблюдение сроков выполнения задачи, качество кода продукта и степень удовлетворённости клиента. Если тут всё хорошо или почти хорошо, то нет смысла тратить своё время и лезть изучать скриншоты с чужого экрана. В этом плане нам действительно абсолютно без разницы, чем занимается сотрудник во время рабочего дня. В тему про «нескучные видео»: за одним сотрудником было замечено, что он такое смотрел, но, тем не менее, за свой испытательный срок неплохо прокачался, показал отличный результат, так что всем в общем-то пофиг.
Однако бывают и грустные истории. Если сотрудник превращается в генератор факапов, то, конечно, можно начать «рубить головы» вслепую, но куда лучше было бы сначала разобраться. Как разобраться? Посмотреть на процесс! Если мы видим, что рабочий день сотрудника состоит из решения его личных проблем или «нескучного видео», то причина его неуспеваемости очевидна. Пока что мой опыт показывает, что увещевательные беседы с такими людьми не приносят результата, поэтому сейчас мы максимально быстро с ними расстаёмся.
Если же я вижу, что в целом человек занимался задачей, но по какой-то причине у него не получилось — начинаем искать причину. Пережатые сроки? Нечеткие требования? Слишком сложная задача? Не было помощи от тимлида? Не было информации от менеджера? И т.п.
В целом, на этом роль «слежения за сотрудниками» оканчивается. Время, отработанное в Hubstaff, не используется при вычислении KPI, равно как и скриншоты с экрана. Время от времени некоторые сотрудники в панике мне пишут: «Лёх, я забыл включить Hubstaff, что мне делать, как исправить, пол дня отметилось, что я не работал!.. Меня теперь покарают??..». «Забить, и не забыть включить в следующий раз» — единственный адекватный ответ.
Выше я писал, что встречаются люди, которые резко негативно относятся к «слежке», либо же на словах соглажаются с «правилами игры», на деле не собираясь их выполнять. Я порядком нагулялся по таким граблям, и лично для себя сделал вывод, что с такими удалёнщиками лучше сразу не связываться, или не тратить время на «второй шанс». Как правило, с ними все равно ничего не выходило, даже если они потом включали HubStaff, качество работы оставалось низким. Оно и логично: если человеку есть что скрывать в рабочее время, скорее всего он собирается заниматься чем-то ещё. К примеру, подхалтуривать, получая у вас фикс, а со стороны — почасовку.
Если бы все сотрудники поголовно были бы честными адекватными людьми, готовыми добросовестно выполнять взятые на себя обязательства, то не было бы такого обилия следящего софта на рынке. К которому я и сам по началу отнёсся негативно. Но сейчас должен признать, что польза от него все-таки есть.
Так я о том и пишу, что если серьёзная травма — то скорее всего «анастезия» получится сама собой, без какой-либо предварительной практики, у сколь угодно не подготовленного к этому человека. В остальных случаях уже становится меньше физиологии, больше психологии.
Ну травмы, как правило, достаточно внезапны, и это не просто с неприятные ощущения, а с серьёзные повреждения. Не знаю, с чем именно это связано: с избытком ли сигналов к мозгу, или с тем, что локальные болевые рецепторы сами повреждены, или с уровнем адреналина — а только боль в этом случае может начаться очень не сразу, первое время действительно не будешь понимать, что произошло. Зато потом…
Это так и выросло из «негативной обратной связи». Навсегда запомню этот день: 2013 год, обычный летний день, и ни что не предвещало беды, как вдруг…
Двое молодчиков написали каждый по своему модулю методом слепого копипаста. В результате появилось два класса-близнеца для работы с базой. Метод Add был скопирован у третьих лиц, а поэтому не добавлял элементы, если обязательные поля были, внимание, заполнены: функцию валидации тоже криво откуда-то скопировали. Но Add всё равно никто не пользовался, а добавляли новые записи методом Edit. На мой вопрос «почему» ответ был «а не знаю, я откуда-то скопировал».
После того, как эти люди были устранены с проекта, я ещё порядком начитался кода, написанного «в лучших традициях», а потом не выдержал. D7 тогда ещё не было, поэтому сначала пришлось написать простенькую ORM, чтобы генератор админки вообще стал возможен.
Так что не уверен, надо ли быть каким-то специальным человеком, чтобы заметить, что король-то голый…
Я и в windows его не представляю :-) kwrite всегда со мной, недавно удалось успешно пересобрать свежи gwenview и dolphin на венду — радости нет предела!
Ну никто не говорил, что неграмотность вчерашних выпускников — это какая-то неразрешимая проблема. В одном только этом треде сколько вариантов набросали. С этой проблемой вполне посильное справиться, и справляемся. Речь о том, что "розовые сопли" о том, что джунам не доплачивают — не обоснованы. Напротив, многие получают от компаний больше, чем они того достойны.
Кто ж спорит, решается. Работодателем, не ВУЗами, вот в чем беда. Нередко ещё и преодолевая высоченное ЧСВ новоприбывшего. На фоне чего рассуждения о низкой стартовой зарплате выглядят ещё более дикими.
Меня как-то даже возмутила точка зрения, что зарплаты в РФ "несправедливые" для джунов, 100к это психологический порог, и зелёные новички достойны большего. Не надо мешать в кучу разработчиков разных уровней! Редкий джун в нашей стране умеет вообще хоть что-нибудь. Те, кто только вышел из института, часто приходят не то что без портфолио и своих проектов, а реально не написав ни одной строчки кода! Это в лучшем случае бесплатная стажировка, о какой зарплате вообще речь?! И даже когда его научили необходимому минимуму — все равно маловероятно, что он сможет выполнять какую-либо полезную работу, на которой работодатель сможет извлечь прибыль. И на этом этапе ЗП ему платится не за принесенную пользу, а чтобы не отбить желание учиться / не помереть с голоду. Посчитать время, которое на джунов вынуждены тратить мидлы и сеньёры, чтобы проконтролировать их работу и чему-то научить — так они ещё пол года будут отрабатывать потраченное на них время. Минимум.
Итого, моё мнение из личного опыта в сфере php-разработки: джуны совсем нулевые, часто их запросы сильно не соответствуют имеющимся знаниям, зарплаты джунов нереально завышены, особенно в Москве и Питере. Кто по-честнее, понимают свой слабый уровень и всеми силами стараются его поднять, очень скоро выходя из категории "джун". Но многие "яжпрограммисты" изначально настроены сидеть на шее за счёт хайпа на рынке, технической неграмотности работодателей и рекрутёров, заведомой мертворождённости стартапов.
Уж чего точно не надо делать, так это повышать стартовые зарплаты для ждунов. Хорошие деньги даются за реальные знания и умения, и молодые специалисты особенно должны это чувствовать, чтобы был стимул расти и впоследствии на высоте держать свой уровень. Сегодня же многим платят просто "за красивые глаза".
И правда как из параллельного мира. У нас ребят, которые не только код писать могут, но и с клиентом пообщаться, и ТЗ критически рассмотреть, и что-то дельное по проекту/работе в целом предложить — да с руками рвут, даже в рамках одной компании у менеджеров грызня за таких ребят! Ведь они фигачат как боги, при чем сразу по всем фронтам! И тут уже приходится следить, чтобы их не перегружали работой, и в какой-то мере да, действительно искусственно ограничивать круг задач, которые им могут поставить решать.
Но это чисто организационные моменты. Никакого клейма нет, боже упаси! И если, например, у "простого менеджера" вдруг обнаруживается технический бэкграунд, то это же колоссальный рост его авторитета в команде + компетентности в глазах клиентов.
В общем, да, согласен, возможно автора и правда кто-то обидел.
Что хуже, она сырая удручающе долго...
С ios придется заморачиваться, даже в случае кроссплатформенных решений. Даже если представить, что приложение написано на базе cordova и идеально работает на всех платформах, для android правила сборки для деплоя одни, для ios — другие. Люди, работавшие для android, считают, что деплой в ios адово сложен — и наоборот...
На деле же сложное кроссплатформенное приложение в некоторых случаях ведёт себя по-разному на разных платформах, так что требуются фиксы в коде под отдельные платформы. Плюс, в случае cordova, хорошо бы точно понимать список необходимых нативных функций, посмотреть, какими плагинами они поддерживаются, в каком объёме р всеми ли нужными платформами. Чтобы не было неприятных сюрпризов в самый разгар разработки, когда отступать уже поздно.
В общем, да, заморачиваться придётся в любом случае. Так что совет начать с мобильной версии сайта / адаптивного дизайна очень правильный, поддерживаю!
Пишет владелец модели Тошибы 2011 года, непрерывно юзающий это устройство ~25 часов в неделю и до сих пор довольный, как слон. Вот только закупился запчастями ещё на 5 лет вперед, на случай снятия их с производства.
Тоже страдаем у себя в компании, перебиваясь чатиками да заметками… Треккер типа редмайна — слишком неповоротлив для контроля оперативной обстановки, какая-нибудь диаграмма ганта — протестировал кучу решений, почти везде за основу берется «прокет», на коротый распределяется «ресурс», и дальше предполагается, что этот «ресурс» так и остается на проекте.
В реальности же, когда приходит дедушка факап, ресурсы безжалостно перетасовываются между проектами, картина за неделю может сильно поменяться. В этом плане было бы удобнее иметь другой вариант «ганта»: когда в основе у нас лежит разработчик, а к нему уже цепляются проекты, с указанием, с какой по какую даты в каком объёме он каждым из них занимается. Но пока подходящего решения такого типа не нашли. Откопали ganttic.com, но это ж, блин, космический корабль, поддерживать его в актуальном состоянии — всё равно что второй редмайн вести.
Если есть идеи/прозрения/советы по этому вопросу — был бы весьма благодарен.
Программист должен спокойно работать и ни на что постороннее не отвлекаться. Сотрудник должен работать не потому, что за ним кто-то следит, а потому что ему четко видна связь между выполненной работой и полученными деньгами.
Что касается почасовки: она таки целесообразна в некоторых случаях. В целом мы спокойно относимся к тому, что человек работает в своём графике — иначе и быть не может, Россия раскинулась на 11 часовых поясов, а еще есть Украина… глупо заставлять всех работать в одно время. Но график сотрудника должен быть предсказуем. Если же с этим проблемы, то мы согласны предложить почасовую оплату при условии выработки N часов в неделю.
Вообще не берусь судить, как в других сферах, а в web-разработке время-деньги, поэтому его просто нельзя не учитывать.
Ну и вообще шпионом называть такой софт некорректно. Шпион — это когда он включается и что-то собирает без твоего ведома. А тут совсем другой случай: пока сотрудник сам программу не запустит, тем самым обозначив, что он «пришёл на работу» — никакой слежки не начнётся. Ну, я конкретно про хабстафф говорю, не сочтите за рекламу: мы его «поведение» детально тестировали.
Конечно, оно доставляет некоторые неудобства тем, кому часто приходится переключаться между задачами и проектами — в основном это тимлиды/руководитель офиса. То тут кодревью, то там джуну помогал, то здесь менеджера консультировал… но это неудобство обусловлено не слежкой как таковой, а тем, что сложно уследить, когда ты перестал заниматься одной задачей, и начал заниматься другой. Но частое переключение между задачами для программиста на любой позиции — в целом не норм, так что с этим явлением надо в принципе бороться.
Что касается конкретно меня — нет, я давно уже не запускал этот софт. Во-первых, было бы странно следить за самим собой. Прибыль компании — мой хлеб, если компания будет в убытке, то лично мне есть будет нечего, поэтому сценарий «солдат спит — служба идёт» как-то не работает :-) Во-вторых, со временем на непосредственное участие в разработке на каком-либо одном проекте стало оставаться всё меньше и меньше времени. Разве что «пожар тушить», а тут уже не до бюрократии (относится ко всем). Ну а когда пол дня проводишь на встрече с клиентом, то компьютер тут уже вообще ни при чем, хотя иногда беру его с собой.
Тут может всплыть вопрос о том, так ли необходимо требовать от проверенных сотрудников включение хабстаффа — ведь с ними уже всё ясно, в них можно быть уверенными. Думаю, хуже от этого точно не будет:
У нас в DigitalWand распределенная команда разработчиков, почти все работают за личными компами. Но ещё на этапе собеседования я предупреждаю, что нужно будет поставить HubStaff на комп, который будет скринить экран и следить за активностью мышки-клавы. Те, кто на это не соглашаются, или соглашаются, но игнорируют это правило, с нами не работают.
Теперь о том, как мы используем имеющиеся данные.
Полностью согласен с данным утверждением. В нормальной ситуации мы контролируем именно результат, который показывает сотрудник: соблюдение сроков выполнения задачи, качество кода продукта и степень удовлетворённости клиента. Если тут всё хорошо или почти хорошо, то нет смысла тратить своё время и лезть изучать скриншоты с чужого экрана. В этом плане нам действительно абсолютно без разницы, чем занимается сотрудник во время рабочего дня. В тему про «нескучные видео»: за одним сотрудником было замечено, что он такое смотрел, но, тем не менее, за свой испытательный срок неплохо прокачался, показал отличный результат, так что всем в общем-то пофиг.
Однако бывают и грустные истории. Если сотрудник превращается в генератор факапов, то, конечно, можно начать «рубить головы» вслепую, но куда лучше было бы сначала разобраться. Как разобраться? Посмотреть на процесс! Если мы видим, что рабочий день сотрудника состоит из решения его личных проблем или «нескучного видео», то причина его неуспеваемости очевидна. Пока что мой опыт показывает, что увещевательные беседы с такими людьми не приносят результата, поэтому сейчас мы максимально быстро с ними расстаёмся.
Если же я вижу, что в целом человек занимался задачей, но по какой-то причине у него не получилось — начинаем искать причину. Пережатые сроки? Нечеткие требования? Слишком сложная задача? Не было помощи от тимлида? Не было информации от менеджера? И т.п.
В целом, на этом роль «слежения за сотрудниками» оканчивается. Время, отработанное в Hubstaff, не используется при вычислении KPI, равно как и скриншоты с экрана. Время от времени некоторые сотрудники в панике мне пишут: «Лёх, я забыл включить Hubstaff, что мне делать, как исправить, пол дня отметилось, что я не работал!.. Меня теперь покарают??..». «Забить, и не забыть включить в следующий раз» — единственный адекватный ответ.
Выше я писал, что встречаются люди, которые резко негативно относятся к «слежке», либо же на словах соглажаются с «правилами игры», на деле не собираясь их выполнять. Я порядком нагулялся по таким граблям, и лично для себя сделал вывод, что с такими удалёнщиками лучше сразу не связываться, или не тратить время на «второй шанс». Как правило, с ними все равно ничего не выходило, даже если они потом включали HubStaff, качество работы оставалось низким. Оно и логично: если человеку есть что скрывать в рабочее время, скорее всего он собирается заниматься чем-то ещё. К примеру, подхалтуривать, получая у вас фикс, а со стороны — почасовку.
Если бы все сотрудники поголовно были бы честными адекватными людьми, готовыми добросовестно выполнять взятые на себя обязательства, то не было бы такого обилия следящего софта на рынке. К которому я и сам по началу отнёсся негативно. Но сейчас должен признать, что польза от него все-таки есть.
Двое молодчиков написали каждый по своему модулю методом слепого копипаста. В результате появилось два класса-близнеца для работы с базой. Метод Add был скопирован у третьих лиц, а поэтому не добавлял элементы, если обязательные поля были, внимание, заполнены: функцию валидации тоже криво откуда-то скопировали. Но Add всё равно никто не пользовался, а добавляли новые записи методом Edit. На мой вопрос «почему» ответ был «а не знаю, я откуда-то скопировал».
После того, как эти люди были устранены с проекта, я ещё порядком начитался кода, написанного «в лучших традициях», а потом не выдержал. D7 тогда ещё не было, поэтому сначала пришлось написать простенькую ORM, чтобы генератор админки вообще стал возможен.
Так что не уверен, надо ли быть каким-то специальным человеком, чтобы заметить, что король-то голый…