Главный страх компаний, которые вернулись в офис, когда это стало возможным, - потеря контроля над командой. Высоковата получается цена ошибки, если разработчик с его-то зарплатой сидит и ничего не делает.
Но реалии таковы, что удаленка стала must have для найма. И как тогда контролировать? Что выбрать, чтобы наблюдать за сотрудниками - системы трекинга времени, средства трансляции рабочего стола?
А если мы скажем, что ничего? Не надо тратить ресурсы на лишний контроль. И деньги сэкономите, и людям поможете раскрыться.
Под катом рассказываем, как это у нас работает уже более 5 лет.
Начнем с того, как делать не надо
Мы наблюдаем за коллегами по цеху, спрашиваем наших разработчиков о том, с чем им приходилось сталкиваться в своей практике на предыдущих проектах. Складывается ощущение, что чем серьезнее “закручивают гайки” в той или иной организации, тем легче при желании обойти внутренние правила, поскольку появляется ложная иллюзия контроля и на другие стороны разработки уже просто никто не смотрит.
Вот ТОП-6 бессмысленных идей о контроле команд:
Бессмысленно снимать скриншоты рабочего стола. Беспокоитесь, что на экране разработчика должна быть открыта IDEA без каких-либо дополнительных окон с фильмами? А что ему мешает открыть IDEA, заставить мышку периодически дергаться и включить себе фильм на личном ноутбуке рядом? Отследить, что он ничего не делает, будет сложнее.
Нет смысла использовать секундомер для очень детальной оценки рабочего времени, потраченного на каждую задачу. Количество потраченных секунд ничего не говорит о качестве решения и объеме выполненной работы. Иногда сложнейшую задачу можно сделать за 2 часа, а простой баг искать неделю. А с точки зрения командной работы в принципе важно не сколько человек потратил на решение, а уложился ли он в заданное время (собственную оценку или срок, поставленный на планировании). А еще решил ли он задачу качественно, чтобы она не вернулась ему обратно на доделку. Можно ведь сделать двухчасовую задачу за час так, что она вернется после тестирования еще на час (и это уже 2 часа плюс ресурсы QA и сдвиг планов).
Нельзя измерять трудозатраты разработчика строками кода. 2 строчки кода могут “стоить” 5 минут времени или недели работы, в зависимости от сложности задачи. А сложность в этой метрике не заложена вообще.
Не стоит измерять качество кода количеством “прилетевших” багов без учета характера этих багов. Иногда метрики количества багов на фичу или соотношения времени исправления багов и времени реализации фичи показывают правду о качестве кода. Но что делать в ситуации, когда баг прилетает из-за изменения требований (разработали все по старым требованиям, а тестировали по новым)? Кому в минус надо записать этот баг? И кто должен тратить ресурсы на разбор каждого бага, чтобы честно посчитать метрику?
Не полезно вычитать время коротких перекуров из длительности рабочего дня. Периодические перерывы необходимы. Нельзя 8 часов просидеть на рабочем месте, не вставая. Есть режим труда и отдыха. На длинной дистанции (от 10 лет стажа и более) производительность будет лучше у человека со здоровыми привычками. А многие еще и думают над задачей во время этого короткого променада. Но если заставить специалистов точно рассчитывать время перекуров и “перечаев”, отрабатывая его в конце рабочего дня, можно пошатнуть их мотивацию. А она для проекта намного важнее. Да, человек отработает в итоге эти 25 минут, накопившиеся за день, но потеряет ощущение свободной работы в удовольствие.
Не стоит загружать разработчиков лишними метриками, повлиять на которые они не могут. Даже банальное соотношение времени на реализацию фичи и времени, потраченного на исправление багов в ней, может и не характеризовать его код. Как мы отметили выше, надо разбираться в сути ошибки - быть может, там доступ к базе “сломался” во время тестирования? Если каждый раз человек будет бояться за свою судьбу на проекте из-за колебания этих метрик, комфортной работы не выйдет.
Лишние метрики, точный учет времени и прочие элементы контроля требуют поддержания определенных рабочих процессов. К примеру, если есть аналитика с точностью до секунды, кто-то и зачем-то должен ее использовать? А если есть по 100 фоток рабочего стола каждого специалиста за день, кому-то придется их смотреть. Так что все эти идеи не только создают ложное ощущение контроля над ситуацией, но и пожирают ресурсы, которые могли бы пойти на развитие проекта.
Мы так не работаем.
Контроль без контроля
Наш подход - оставить атмосферу максимально свободной, контролируя и подстраховывая проект незаметно. Это не значит, что контроля нет. Но он реализован на другом уровне и вписан в работу так, что нам не приходится тратить дополнительные ресурсы на обслуживание самой системы контроля. И все это опирается на профессионализм команд, подробную документацию на проектах и четкие требования - иными словами, нормальное разграничение полномочий, где люди с разными ролями не должны лезть в соседнюю область и могут положиться на решения друг друга.
Контроль на уровне мерж-реквеста
Мерж-реквест - лучший показатель эффективности работы специалиста. Но применять к нему какие-то универсальные метрики нельзя. Гораздо проще опираться на профессионализм тимлида.
В нашей практике проектные задачи максимально декомпозируются и раздаются желательно по одной в руки. Да, бывает когда в работе находятся две задачи. Но посмотрите в глаза правде - в какой-то один момент времени человек все равно размышляет над чем-то одним. Он не может левой рукой писать код по одной задаче, а правой - по другой. В итоге все равно приходим к практике “каждому по задаче”.
Когда тимлид хорошо знает код и команду, он с первого взгляда видит, сколько примерно займет решение той или иной задачи у конкретного человека. За задачу берется узкий специалист в этом вопросе, который сейчас на пике своей производительности? Или может ее дали новичку, который хорошо знает стек, но ему придется разбираться в проекте? Оценки в первом и во втором случае могут различаться в два раза, но это всегда более-менее понятная величина.
А изучение мерж-реквеста дает почву для размышлений о том, соответствует ли потраченное конкретным человеком время тем изменениям, которые он внес. Если работы на час, а задачу делали два дня - это повод поговорить. В остальных случаях все должно идти своим чередом. Разработка - сложная и творческая задача. Не надо напрягать лишним контролем тех, кто ей занимается.
Контроль на уровне человека
Это еще один уровень, за который ответственен тимлид.
Чтобы видеть в специалисте ответственное или, наоборот, безответственное отношение к работе, не надо быть психологом. Если человек сам оценивает, что сделает задачу за 2 часа, а потом каждый день на протяжении недели говорит “будет сегодня вечером”, - значит происходит что-то не то. Тимлид или вышестоящие менеджеры отлично замечают такие “звоночки” и идут смотреть статистику в Jira еще до того, как это стало критично для проекта. А дальше такие вопросы решаются в индивидуальном порядке.
Контроль на уровне команды
А на этом уровне контроля в нем фактически участвует вся команда.
У нас проекты никогда не пилит один человек. Но в то же время у нас нет команд по 100+ человек, где легко “спрятаться”. На каждый новый проект выходит команда из небольшого (минимально необходимого) количества людей с разными ролями - аналитики, фронт, бэк, тестирование, тимлид, менеджер проекта, владелец продукта и т.п. У каждого есть свой сегмент ответственности.
Предположим, один из них решил “залечь на дно” и ничего не делать. Это мгновенно отразится на проекте. Если свой выход пропустили аналитики - вся команда не знает чем заняться… Застрянет бэкенд - фронтенд это заметит, QA будет нечего тестировать - весь график проекта поползет, ведь результат, как бы это банально не звучало, зависит от каждого.
Если что-то пойдет не так, на дейли это будет заметно уже на следующий день - остальные участники команды поймут, что очередной этап не готов - следующему подхватывать нечего.
Контроль на уровне клиента
У нас есть не только собственный проект, но и совместные разработки с заказчиками. На таких проектах добавляется еще один уровень контроля - сбор обратной связи от клиента. Проектный менеджер с нашей стороны регулярно общается с клиентом, получая оценки работы команды и конкретных специалистов. Кстати, там же обсуждается, куда каждый из специалистов может вырасти в рамках проекта.
А зачем тогда тайм-шиты?
Все просто - это финансовая отчетность. Мы заполняем тайм-шиты для удобства финансовых консультантов. Глобально они больше никому не нужны.
Иногда данные из тайм-шитов используются для решения побочных задач. Но это не общая практика. Например, у нас была мысль сравнивать время, зафиксированное в этой отчетности, и оценку на планировании задачи, чтобы вывести некий “коэффициент ошибки” (и использовать в будущем планировании). Но проекты разные и люди в них участвуют разные - найти универсальный коэффициент будет сложно.
Также при заполнении тайм-шитов мы иногда пробуем списывать время, потраченное на митинги, на специальные задачи в Jira. Но в основном этим занимаются тимлиды и вышестоящие менеджеры, анализируя свой день. И обычно это их личная инициатива, которая не вводится в масштабах команды. Рядовому разработчику с 1-2 короткими созвонами в день нет смысла вводить такие сложности. Работая над одной задачей единовременно, он и созванивается либо по этой задаче, либо чтобы решить какие-то “корпоративные” вопросы (собеседование, например).
Как разбирать промахи, не закручивая гайки
Ошибок не совершает только тот, кто ничего не делает. У любого может временно просесть производительность из-за каких-то личных обстоятельств или профессионального выгорания. Главное не тиранить человека, особенно в этот момент, ведь он и так на нервах. Лишний контроль и тем более выливание негатива только создает большую напряженность.
Если разработчик ошибается, тимлид его подстраховывает, стараясь, чтобы факап минимально отразился на проекте, а потом уже разбирается, что произошло. Обычно достаточно убедиться, что человек знает о проблеме, и оставить его в покое, чтобы он сам разобрался. В отдельных случаях, например когда первый раз ошибается разработчик, который совсем недавно в команде, тимлид может подключиться параллельно, чтобы подстраховать проект. Но если про разработчика известно, что он всегда сам отлично справляется, тимлид может в этом и не участвовать. Главное, чтобы в среднем работа шла хорошо - чтобы после ошибок или падения производительности человек восполнял пробелы.
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы вVK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
Комментарии (41)
cybran24
02.10.2021 02:25+6Самое идиотское — это трекеры времени и списки задач. Когда меня попросили поставить тайм-трекер, я всерьез задумался об уходе из компании. Списки задач для домохозяек ещё терпимо, но трекеры свидетельствуют об общем низком уровне сотрудников компании, раз приходится таким идиотским способом за ними следить. Самый лучший подход — это статистика аккаунта в системе контроля версий, по которой видно вклад каждого отдельного участника на разных временных интервалах. Другое дело, что менеджмент не всегда знает о существовании системы контроля версий, не говоря уже о том, что утруждает себя зарегистрироваться в ней и отслеживать статистику коммитов и прочее. Наболело...
andreyverbin
02.10.2021 02:54-13Трекеры везде и всегда нужны чтобы знать, сколько вам денег заплатить. Или вам за строки кода больше нравится получать?
Racheengel
02.10.2021 11:10+6Не надо никакого трекера, кроме багтрекера. Где все задачи, баги и бэклоги на обозрении всех участников. И каждый видит, чем заняты другие товарищи.
И зарплату платим за выполненную качественную работу, а не за KPI. Хотя, лучший KPI это отсутствие жалоб со стороны заказчика :)
А ленивых должен тимлид ненавязчиво контролировать и вовремя подгружать. А ещё раз в неделю полезно короткий митинг, где обсуждается прогресс, прошлое и будущее.
Что касается строк кода, часто самое лучшее решение - это уменьшение их числа. Less Code, Less Bugs. Как то так.
andreyverbin
04.10.2021 19:07Багтрекер это хорошо, но не отвечает на вопрос сколько денег вам заплатить. Если у вас фикс. зп то все ясно. Но зп не очень хорошо сочетается с полностью удаленной работой и свободным графиком. Часть проблем я обозначил в комментарии ниже.
RomeoGolf
02.10.2021 18:23+1А вам за попо-часы больше нравится платить?
Тайм-трекеры — это вялый аналог электронной проходной: вот человек пришел на работу, вот человек ушел, что делал — не очень важно, важно, что «восьмерку» отсидел. Что имеем на самом деле:
— иллюзию контроля, особенно при некомпетентности в области работы подчиненного (в часах-то мы все компетентны)
— возможность воздействия на подчиненного угрозой наказания за нарушение временных рамок (даже на 1 минуту, которая реально не влияет ваааабстче ни на что)
— почесывание синдрома вахтера
— постепенно прорастающее желание подчиненного уйти туда, где такого безобразия нет. И человек сбежит даже при прочих равных — зарплата, интересность задач и все такое — при первой возможности. Особенно с учетом того, что такой контроль имеет склонность к росту: сперва тайм-трекер, потом клавиатурный сканер, потом скриншоты с экрана, потом запись с вебки…andreyverbin
04.10.2021 18:52+1>А вам за попо-часы больше нравится платить?
Я бы с удовольствием платил за результат, но с этим есть сложности. А попо-часы это простая штука, она мне не нравится, но ничего лучше в remote-first окружении не придумано. Описал пару проблем тут.
RomeoGolf
04.10.2021 19:04+1Фишка в том, что платя за попо-часы, вы будете платить только за попо-часы. Разработчик будет уверен, что если вас интересует именно эта метрика — то других вам и не надо. Получите такую же имитацию работы, какую имеете имитацию контроля.
Тут ведь как — количественно оценить творческий труд невозможно в принципе. Поэт может выдать 16 строк в полгода — и это будет нетленка. Может выдавать по полторы сотни в день — и сразу в топку. А объективных критериев оценки не существует. Если вы набираете команду добросовестных исполнителей и в состоянии наблюдать, что дело делается и задача выполняется в соответствии с задуманным — издеваться над людьми просто не нужно. Добросовестные люди всегда замечают, что им не верят и отвечают взаимностью. Если набрали имитаторов деятельности — подобные KPI бесполезны, это все равно обходится, и скрепки в клавиатуре, и демонстрация фейкового видео/скриншотинга…
Короче — ни одну проблему таймтрекер не решает, зато создает новые.
cybran24
03.10.2021 18:13Трекеры везде и всегда нужны
Вы уверены? Прям таки вижу как удаленные разработчики Amazon или Google «сидят под трекерами» без доли смущения.
Трекеры унижают достоинство трудящихся, я считаю их использование неэтичным.
Лично я не стану работать на идиотов, которые считают допустимым использовать тайм-трекеры для подсчёта зарплаты сотрудников. Я получаю деньги за свои профессиональные навыки и знания, применение которых и так включает время, затраченное на разработку продукта.
Не надо оправдывать жлобов, которые хотят получить продукт при минимальных вложениях. Как правило, у них работает низкоквалифицированный персонал.
andreyverbin
04.10.2021 18:40+1>Вы уверены? Прям таки вижу как удаленные разработчики Amazon или Google «сидят под трекерами» без доли смущения.
А я очень даже вижу. И организации, которые изначально remote-first тоже. Например GitLab - https://about.gitlab.com/handbook/support/support-ops/workflows/gitlab_time_tracking.html
Причина #1 - из 100 удалённых работников 5-20 будут работать на 2х или 3х работах. Либо вы будете всех тимлидов учить этих товарищей вычислять, либо автоматизируете процесс.
Причина #2 - удаленная работа это часто ещё и свободный график. Платить зп в таком случае уже невозможно. В моей компании я вижу, что большая часть людей легко меняет 30-50% зп на свободное время. То есть даже 50% зп позволяют им спокойно жить и они лучше получать меньше денег, но получат больше времени.
cybran24
04.10.2021 19:25Ну, кто-то работает на двух или трёх работах, а я на одной. Нахрена мне тайм-трекер? То, что гитлаб и много кто ещё используют тайм-трекеры, не означает, что их приветствуют все разработчики, и тем более, что они эффективней показателей системы контроля версий. Честно говоря, в моих глазах этот факт не красит гитлаб, который сам по себе является системой контроля версий.
Если менеджменту чхать на разработчиков, то да, тайм-трекеры — это круто, а для меня, как для разработчика, тайм-трекеры — идиотская система отслеживания сотрудников жлобским руководством.
andreyverbin
04.10.2021 20:41Если менеджменту чхать на разработчиков, то да, тайм-трекеры — это круто, а для меня, как для разработчика, тайм-трекеры — идиотская система отслеживания сотрудников жлобским руководством.
Я выше писал, почему используют трекеры. Не вижу связи с жлобством. Трекеры не от хорошей жизни использую . Если у вас есть идеи получше - озвучьте. Показатели системы контроля версий как-то не понятно как использовать. Кто-то багу чинит и за месяц одну строку меняет и его увольняют/депремируют на основании показателей контроля версий. Нанять армию тимлидов, которые будут оценивать ценность строчек когда тоже не рабочая идея.
cybran24
04.10.2021 21:49Показатели системы контроля версий как-то не понятно как использовать. Кто-то багу чинит и за месяц одну строку меняет и его увольняют/депремируют на основании показателей контроля версий.
Почему непонятно? Зачем увольнять? Неужели сложно оценить, что человек одной строчкой исправил баг? А если этот баг критический, то это только повышает ценность сотрудника несмотря на время, затраченное на исправление бага.
Если такого разработчика увольняют, то, опять же, вопрос к адекватности руководства.
andreyverbin
06.10.2021 22:05+1Неужели сложно оценить, что человек одной строчкой исправил баг?
кто оценит? когда? как? почему он правильно оценит? а что если оцениватель в отпуске, болеет, уволился? как все это превратить в деньги, выплачиваемые сотруднику? как избежать сговоров и иных злоупотреблений? что делать если оцениваемый не согласен с оценкой, как будем разруливать конфликт и кто будет за это отвечать?
Вместо всего этого - оплата за попо-часы или фикс.
cybran24
06.10.2021 23:29+1Что это за руководство, если у него возникают такие вопросы, — школьники стартаперы? Или человек, который исправил баг, единственный, кто разбирается в том, что он делает в компании?
Все ваши вопросы — это жалкая попытка оправдать тупые тайм-трекеры, несмотря на то, что вас заминусовали еще в начале дискуссии. Вам уже привели вполне вменяемые доводы против, а вы уперто стоите на своем. Боюсь, что, с этой точки зрения, вам уже никакие доводы не помогут. Поэтому, не вижу смысла вести с вами дальнейшую дискуссию.
Желаю вам расти над собой, углублять свои знания — без них невозможно контролировать и выстраивать бизнес-процессы. Может быть тогда, вы поймёте, что тайм-трекеры хороши исключительно для вас как оправдание ваших слабостей в тех или иных аспектах менеджмента, но не для квалифицированных разработчиков, которые, убегут от тайм-трекеров при первой же возможности.
tommyangelo27
04.10.2021 20:131. По сслыке ничего не написано о том, что Гитлаб платит за затреканные часы. Более того, там прямо написано «We in no way plan to ever utilize this to determine „how much a person is working“»
2. Платите за затреканные 8 часов? Будете получать 4 нормальных рабочих часа, а затреканные 8.
Это всё пишу как человек, который 8 лет работает в фирмах с трекерами.andreyverbin
04.10.2021 20:35Угадайте, что с вами случится в gitlab если вы пару месяцев будете трекать по 4-6 часов в день максимум.
tommyangelo27
04.10.2021 21:00Так я буду трекать по 8 (уже написал, что занимаюсь этим последние 8 лет).
Тут есть нюанс. Одни фирмы берут таймшит работника и на основании него выставляют счёт клиенту. Тут будет спрос за каждые 15 затреканных минут, потому, что клиент потребует объяснений куда пошли часы.
Другие фирмы, чаще продуктовые (подозреваю, что гитлаб в их числе) берут таймшит и на его основании:
— смотрят кто чем занимался;
— прикидывают трудоёмкость задач;
— примерно планируют кому сколько назначать задач в следующем спринте.
andreyverbin
06.10.2021 22:27Ничего я не понимаю... какая отрицательная мотивация, мотивация делать/не делать что именно? Я просто плачу за попо-часы потому, что это просто и всем понятно в среде, где каждый сам выбирает сколько ему работать.
Что касается производительности, то я оставил попытки ее измерять или выражать каким-то числом. Это слишком дорого, с точки зрения процесса сбора и анализа данных. Остается только качественная оценка - Петя работает быстрее/лучше Васи по мнению Коли. На такой штуке далеко не уедешь в деле определения размера оплаты труда. Остаются попо-часы и фикс.
andreyverbin
04.10.2021 18:58Каким образом учёт рабочего времени связан с экономией на вашей зп?
cybran24
03.10.2021 23:06А как соотносятся повышение показателей своего труда и накрутка своей стастики через бессмысленные коммиты?
Есть вполне конкретные критерии оценки качества кода, по которым и нужно оценивать показатели труда отдельных членов команды. Что с ними делать потом — другой вопрос — это зависит практик компании. Можно не увольнять, а предоставить им ментора, например, но я бы уволил за сам факт накрутки.
Если хочешь повысить свои показатели — делай это честным трудом, а не имитацией и обманом, а лучше не лезь туда, где ты некомпетентен.
Более того, адекватный менеджмент не наймет таких людей в свою команду.
andreyverbin
04.10.2021 19:12>Есть вполне конкретные критерии оценки качества кода, по которым и нужно оценивать показатели труда отдельных членов команды.
Интересно узнать какие? Думаю в индустрии половина проблем из-за субъективности оценки качества кода.
cybran24
04.10.2021 20:06Скорость исполнения, тесты, документирование, шаблоны проектирования, дизайн классов. Неужели трудно отличить код человека с опытом от кода некомпетентного сотрудника, вчерашнего выпускника, индуса?
Подозреваю, что менеджеру — трудно. Поэтому проще тайм-трекеры. Вот только не нужно оправдывать некомпетентность менеджеров и руководителей использованием тайм-трекеров.
andreyverbin
04.10.2021 20:54Менеджер некомпетентен потому что не является архитектором ПО? Он же менеджер… а архитекторам есть чем заняться кроме чтения кода каждого сотрудника. А тесты производительности писать кто будет, равно как проверять насколько хорошо написаны тесты на новую функцию?
Дело не в «проще», то, что вы предлагаете не осуществимо на практике.
cybran24
04.10.2021 21:58Почему не осуществимо? А для чего существует code review? Для чего придумали merge request?
cybran24
06.10.2021 09:05Все мои комментарии написаны как оппозиция к тайм-трекенгу в пользу системы контроля версий в контексте обсуждаемой статьи. Если вы в них не видите определенной позиции, то я могу лишь посочувствовать вашим аналитическим способностям.
cybran24
05.10.2021 16:51Серьезно? Спасибо что просветили. Вы лучше это объясните заминусованному товарищу выше.
anonymous
00.00.0000 00:00
Luchnik22
02.10.2021 13:49Статистика аккаунта в системе контроля не самый лучший способ, потому что порой в команде может тормозить задача на уровнях до получения её разработчиком, также в компании бывают QA, дизайнеры, аналитики, тим. лиды, архитекторы, которые вовсе не делают коммитов, и к тому же люди начнут накручивать статистику в этой системе контроля версий (уже было).
Мне кажется, лучше чтобы люди оценивали людей, то есть работа каждого специалиста оценивается командой, в которой он находится. А бизнес уже дальше оценивает успехи команды по поставленным ей целям.
У меня в практике было два случая:
1. Команду полностью устраивал дизайнер, а его уволили по метрике (ревью дизайна редко проходил), в итоге команда почти встала, дизайнера не могли найти месяца два, к слову сейчас этот чувак дизайн директор.
2. Команда сначала пыталась помочь члену (возвращала обратную связь, придумывала план, входило в положение), а потом через некоторое время отказалась от работы с ним (его не уволили - перевели в другую команду), после чего в команде нашли замену, а чувак принял во внимание весь опыт и уже в другой команде показывал хороший перформанс.
Mike-M
02.10.2021 16:04лучше чтобы люди оценивали людей
Да, но возникает риск предвзятой оценки, например если недостаточно адекватному коллеге не нравится цвет ваших глаз, прическа,…
Оценка на базе автоматизированных количественных метрик тоже не идеальна.
Поэтому у нас на performance review оценка была интегрированная: по данным системы баг-трекинга и по мнению тим-лида.
Правда, и она, несмотря на многочисленные модификации, так и не смогла стать объективно оценивающей.
В результате, для себя решил: KPI не интересует, интересует только гарантированный оклад.
cybran24
03.10.2021 21:27Я не понимаю, почему меня должно волновать субъективное мнение команды тогда, как мою работу можно оценить по коммитам? А если задача застревает на отдельных звеньях команды, то причем тут я? Нет коммитов — не было задач.
люди начнут накручивать статистику в этой системе контроля версий
Вы всерьез полагаете, что такие прецеденты трудно заметить? Наоборот, это хорошо покажет недобросовестных сотрудников, от которых нужно избавиться сразу.
Я бы не хотел зависить от мнения условного дизайнера, который ничего не понимает в специфике моей работы. И, честно говоря, я сильно сомневаюсь в способности людей давать адекватную, непредвзятую оценку.
anonymous
00.00.0000 00:00Mike-M
02.10.2021 15:52Самый лучший подход — это статистика аккаунта в системе контроля версий
Поддержу и добавлю: то же касается метрики качества продукта.
До сих пор в вакансиях QA вижу: «Написание отчетов о тестировании». Зачем? Современные системы способны автоматически, в считанные секунды предоставить любой отчет.cybran24
03.10.2021 23:44Это ещё цветочки, я как-то обсуждал тестирование с одним менеджером, и он думал, что тестирование — это открыть в браузере dev-версию веб приложения, потыкать на кнопки и всё, можно в прод)
HellWalk
02.10.2021 15:04+1Руководитель или понимает, что делают его подчиненные, на сколько это сложно и т.д. (т.е. он сам решал подобные задачи), или не понимает - и в последнем случае идут все эти "трекеры времени" и прочее, что лишь уменьшает желание работать, да и понижает лояльность в целом.
В общем, бесполезно непрофессионализм менеджмента закрывать каким-то там софтром или метриками.
Ну и не стоит забывать, что руководитель бессознательно набирает людей своего уровня. Соответственно у руководителя-раздолбая будет один круг сотрудников, у руководителя-профессионала - другой. А когда раздолбай и лентяй пытается сделать так, чтобы вокруг него все впахивали - это заканчивается комичными ситуациями, когда подчиненные понимают, что начальник «не шарит» (и не хочет тратить время, чтобы вникать и разбираться) - и начинают ездить ему по ушам.
Mike-M
02.10.2021 16:07Периодические перерывы необходимы. Нельзя 8 часов просидеть на рабочем месте, не вставая.
Кроме того, для сотрудников, непрерывно работающих на ПК, это запрещено нормами охраны труда.
onets
Лет 10 назад был удаленным тех лидом. Никакой слежки за экраном не было. Два базовых способа:
Задач разбиваются на более менее понятные по срокам. Даже чисто по прошлому опыту и ощущениям. Раздаются программистам. И тут начинается веселье. Есть ленивцы, есть среднячки и есть вкалыватели. По ним и так все видно. Среднячки - их больше всего, просто работают, не быстро и не медленно. Ленивцы - они постоянно опаздывают, регулярно случаются какие-то проблемы. От них надо избавляться. Список проблем у них нескончаемый (то кошка заболела, то бабушка умерла, то дом сгорел, и все это в течении недели). Вкалыватели - чувствуешь что человек очень плотно работает. Список задач в очереди уменьшается буквально на глазах. Если дать сложную - посидит подольше, чем обычно, но все равно выдаст решение. Ну и как везде бывают исключения. Например сениор ближе к ленивцу. Но задачи раскапывает глубоко. Т.е.грубо говоря - дал аутентификацию, он пошел читать RFC. Или работает он быстро, но искусственно затормаживает. Или есть вкалыватель, который кодит чушь на выброс.
Как отмечено в статье - команда. Да, все идут со скоростью самого слабого звена.