«Зобов’язували повідомляти, навіть якщо йдеш у туалет». Айтівці розповідають про контроль з боку роботодавців

Ми запитали айтівців, наскільки їх контролюють роботодавці або менеджери. У відповідях вони згадали про використання тайм-трекерів, звіти, часті зідзвони, мікроменеджмент і вимоги бути на зв’язку 24/7. Багато фахівців зауважили про відсутність контролю взагалі або про звичні мітинги для відстеження статусу завдань.

Більше про досвід айтівців — у матеріалі.

Тайм-трекери для відстежування продуктивності

Найчастіше айтівці зауважували про використання тайм-трекерів для контролю за роботою.

«На новому місці контролюють робочий день за Time Doctor. Це жахливий трекер, який робить скриншоти екрана, нагадує про себе постійно як у ввімкненому, так і ВИМКНЕНОМУ режимі. Я не вірю, що можна вісім годин на день бути продуктивним, потрібно провітрювати голову, щоб бути зосередженим і виконувати свою роботу добре. Але в такому разі перерви по 10–15 хвилин можуть з’їсти годину робочого часу, а ще обід. В результаті робочий день вийде не 8, а 9–10 годин (Junior PPC Specialist).

«Наразі працював у двох компаніях на ремоуті. У першій був тайм-трекер, постійний контроль з питаннями, що роблю, що виконав, і щоденним звітуванням. Якщо відійшов більше ніж на 10 хвилин, то виникали питання. І це призводило до того, що я третину часу думав, а чи не здається, що я мало працюю.

У теперішній компанії немає контролю за часом, все розраховано на те, що я працюю у міру своїх можливостей. Спочатку мені було дивно, як це піти на ланч й не відмітитися у двох чатах та у тайм-трекері... А зараз я бачу, як люди час від часу зникають на пів години з онлайну, і це нікого не бентежить. Тож краще у своєму режимі думати про задачі й роботу, ніж створювати видимість зайнятості, обманюючи себе й компанію» (QA Engineer).

«Трекінг, шпигуни на компʼютерах, запис екранів і набору клавіатур» (PHP Dev).

«Сисадмін встановлювала софт на ноути, щоб переглядати дії на робочому місці, інколи робились скриншоти, це було помітно. Також треба було вмикати власний інтернет на телефоні, щоб листуватись з кимось, бо трафік теж переглядався. Менджер з безпеки, колишній працівник СБУ, постійно всіх підслуховував і викликав на нараду до кабінету, якщо хтось спілкувався з колишніми колегами, які покинули компанію і були з керівництвом в ненайкращих відносинах» (інженер пусконалагоджувальних робіт).

«Трекер часу, перевірка чатів з клієнтами» (UI/UX designer).

«Я працюю з трекером часу. По-перше, менеджер завжди перевіряє, щоб зафіксований час відповідав роботі: переглядає залишені репорти, коли там записано небагато, а по часу займає декілька годин, завжди виникають питання «чому не розписано?». По-друге, все має бути заповнено в кінці кожного дня. Тобто якщо працював у середу і не затрекав час одразу, то в четвер вранці чекай повідомлення: «А чому ти не зробив це? Ти що, вчора не працював?» (QA Engineer).

«Тільки трекер, який потім ніхто не перевіряє навіть» (Middle Node.js/React Native Developer).

«На минулому місці у мене був трекер, який скринив монітор і активність клавіатури. На новому місці я щодня роблю звіт за виконаними завданнями. Загалом повна довіра. Такий підхід набагато краще зберігає час і продуктивність, ніж трекінг роботи» (Middle AQA).

Мікроменеджмент, звіти та часті мітинги

«Останні два місяці я відчуваю контроль і мікроменеджмент дуже сильно. Щодня по два-три рази мене смикає менеджер в Teams з питаннями: „А той тікет глянеш? А це питання колеги вирішиш? А це в пріоритет поставиш?“ (Коли я писав цей рядок, менеджер подзвонив, після того як робочий день вже закінчився). Для статистики: у мене найбільше серед команди закритих завдань.

Напевно, через дзвінків 50-60 менеджер зрозумів, що я просто фізично не можу опрацьовувати 10 тікетів на день при нормі 30 на місяць. У середньому менеджер надсилав мені близько десятка тікетів щоденно.

Був один робочий день, коли у мене не працював Microsoft Dynamics for Outlook плагін, я попросив нашу сек’юріті перевстановити (бо сам не маю прав на робочому ноуті), і процес зайняв дві з половиною години. Мене змусили залишитись після закінчення робочого дня і допрацювати ще трохи. Change management, дідько... Я вже активно розглядаю пропозиції, що надходять у LinkedIn, вчора відіслав рекрутеру резюме вперше за понад два з половиною роки роботи в компанії» (Senior Application Engineer).

«Раніше я працював у „галері“. Наді мною буквально щодня стояли і дивилися все, що роблю. Навіть якщо я мав відійти від компа, то зобов’язаний був повідомити про це. Вибачте за відвертість, але навіть про те, що йду в туалет. У нинішній компанії кардинально інший підхід. Спочатку пояснюють роботу, яку треба виконати, і задають естімейти. Виконання не контролюють, лише раз у кілька днів можуть спитати, чи немає проблем/питань. Можна сказати, контролю немає і роботу довіряють, знаючи, що я її виконаю вчасно» (Middle Java Developer).

«На 99% контролює, гіперконтроль у дрібницях. Надто прискіпливий менеджмент, що ламає всю взаємодію та пріоритети команди» (QA Manager).

«Щоденно в кінці дня пишу звіт у довільній формі щодо проробленої роботи. Контроль не „тотальний“, але потрібно завжди бути онлайн і швидко відповідати на повідомлення або термінові завдання» (Junior QA).

«Не маю трекерів чи погодинної звітності, проте маю забагато звітних мітингів всередині команди. Три й більше на тиждень по годині» (Market Research Analyst).

Традиційні дейлі-мітинги та жодного надмірного контролю

Більшість ІТ-спеціалістів зазначили, що роботодавці та менеджери їх ніяк надмірно не контролюють і довіряють команді. Здебільшого фахівців збирають на дейлі-мітинги для уточнення статусу виконання завдань або звертаються тоді, коли з’являються помилки.

«Контролю нема, є довіра та співпраця як з боку принципал лідів у юніті, так і на проєктах» (Lead Manual QA).

«Роботодавець не контролює взагалі. Він навіть не знає, напевне, хто чим займається» (Senior Manual QA).

«Майже не контролює. Головне відвідувати мітинги, вчасно закривати завдання» (Junior Python Developer).

«Контроль, звичайно, є, але він не тисне, переважно реалізовується через дейлі-статуси, періодично можуть бути додаткові уточнення щодо мого прогресу роботи над певними задачами» (Senior Software Developer).

«Не контролює напряму, для цього використовують Kanban-дошку та дейлі, але це мінімальний контроль» (Middle QA).

«Окрім daily standup meetings, контроль зводиться до повідомлення „how it’s going?“ декілька разів на тиждень» (Senior Java Dev).

«Щодня маємо скрам-кол, на якому звітуємо за попередній день і говоримо, що будемо робити сьогодні. Маємо абсолютну свободу дій протягом дня і плануємо його так, як нам потрібно» (Middle Front-end Developer).

«Клієнт стежить за бордою з тасками, у саме виконання ніколи не заглиблюється, якщо нема багів, а їх нема майже ніколи. Пишу йому, що буду робити кожен день, в особисті повідомлення, а він корегує за потреби. Це тому, що немає дейліків. Менеджер раз на місяць питає, як справи, раз на тиждень я пишу доволі детальний статус роботи (Middle QA Manual).

«Дають по шапці, якщо щось впустили й це пішло в реліз (особливо неприємненько, якщо пропустили функціональні тестувальники, а по шапці дають нам)» (Middle performance analyst).

«Мало, тільки дейлі-дзвінки зі статусами» (Senior Front-end Developer).

«Є стендапи і всяке таке. Але реально, поки робота робиться, ніхто нічого не контролює. Ми всі дорослі люди, хочемо зробити так, щоб продукт працював, ми всі професіонали, які не будуть робити фігню і спитають думку колег, коли є підозра, що щось трохи не туди рухається. Гарний менеджер — непомітний» (Not only Java SW Engineer).

«Раз на тиждень на зідзвоні кожен розповідає про прогрес і плани на наступний тиждень. Загалом жодного контролю, окрім постановки задач, термінів, немає. Зазвичай це визначення пріоритету — він або є, або його нема. Якщо пріоритет є — стараєшся закінчити якнайшвидше. Якщо нема — працюєш, як комфортно, аби зрештою виконати завдання. Те, що особливого контролю немає, мотивує виконувати пріоритетні завдання в найкоротший термін за власним бажанням. Тобто людина сама себе мотивує працювати більше, коли треба, і не потребує збоку менеджера, який стоїть над душею» (Senior Ruby on Rails Developer).

«Щоденні daily-мітинги та короткий підсумок тижневої роботи у вигляді занесення в систему ключових справ/задач/мітингів/інцидентів із приблизними часовими затратами» (Senior PHP Developer).

«Працюємо в офісі, де й так видно, хто чим займається. Раз на тиждень є мітинг QA за участю СТО і Prg lead, де розказуємо більш розгорнуто, що було зроблено за тиждень. Також є Jira, стрім з неї виводиться на телевізор в кухні, тож видно активність роботи команди. Оце й весь контроль :)» (QAE).


А вас контролюють менеджери, які інструменти для цього використовують — розкажіть у коментарях.

Все про українське ІТ в Телеграмі — підписуйтеся на канал редакції DOU

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному1
LinkedIn



35 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Тайм-трекери не враховують дві речі:

1) Що програміст __думає__ над задачею, і добряче подумати важливіше, ніж шалено клікати по клавіатурі. Думати можна на кухні з кавою, на вулиці з сигареткою якщо людина курить і т.п. Також, в офісні часи, на кухні можна було порадитись з колегами. А з точки зору тайм трекера — все, що робиться не за комп‘ютером — то не робота.

2) Що якісні перерви в роботі приводять до більш якісної роботи. Наприклад, якщо людина раз в 2 години відходить від компа на 15 хвилин і дивиться в вікно, або не знаю... віджимається від підлоги — це допомагає їй/йому продуктивно далі працювати, а не просто сидіти тупити за компом. А з точки зору тайм-трекера оці «перериви» — це марнотратство священного робочого часу (3 рази по 15 хвилин це майже мінус година), бо він вимірює час, а не результат.

Проблема з трекерами та нескінченними звітами в тому, що вони використовуються не за призначенням.
Тоді як вони корисні для контролю KPI менеджменту, а не підлеглих працівників. Вони дають зворотній зв’язок про ефективність/неефективність, професіоналізм (чи його відсутність), успіх чи провал управлінців, а не виконавців.

тайм-трекер — абсолютное зло, аксиома

Трекер — это норм инструмент, если его правильно использовать. Например — если видно, что сотрудник быстро решает поставленные задачи — можно предложить ему более сложные, с повышением. Фишка в том, что более сложные — это не про аутсорс/аутстафф. Это про рост специалистов внутри продукта, что у нас малодоступно, так же как и работа в штате, а не по контракту.

Швидкість як критерій якості — це гарно... для кур’єра з доставки.

нет «правильно использовать», если суть работы не завязана напрямую на время и однотипные монотонные действия, которые надо в это время уместить.
попытка трекать сложные задачи и оценивать через затраченное время — типичный квадратно-гнездовой подход, за неимением мозгов на другой.

Трекать и анализировать какие научные работы были изучены командой во время R&D? Да нет, бред какой-то.

работаю без трекеров более того без таймшитов более того без контроля когда «пришел\ушел»
фантастика

трекінг то є суцільне демотивуюче зло, але самий треш це колега-шпигун, який сидить позаду тебе, періодично знімає твій екран і скидаю фото тимліду в слак. И це не жарт 😫😫

Раз в тиждень логаю час, щодня дейліки — розказую встигаю чи ні і чому. Ніхто не питає "коли буде готово".невелика британська продуктова контора. З трекером принципово не працював би

Я в чатах забиваю на повідомлення, про те що я пішов пити каву і що вже попив каву. Зробив роботу і все. І ніхто не пікає.

все в одном месте:
— строгая привязка к пк, в дейтайм работать можно было исключительно сидя за пк, при том что были рабочие макбуки, ввелось из-за того что кто-то один раз зафакапил ответить в мессенджере на сообщение
— микроменеджемент, собирались метрики из расчета как и кого можно было «догрузить», чтобы не дай бог ты не «простаивал», а если вдруг захотел прибавки к зп, то вот тут на метриках ты не очень себя показываешь
— влезание в личные дела, если они пересекались с рабочими интересами
— на ночные шифты\окнолы надо было обязательно ездить ночью в офис, чтобы была уверенность, что ты точно работаешь
— пдп и прочие таски для развития пушились и проверялись сильно ранее до обговоренного срока, потому что кто-то кому-то пообещал

Так в офісі на нічних шифтах теж можна спати 😸 стільці ставиш в рядок і спиш

Якось працював у досить великому міжнародному проекті, де вперше познайомився із Time tracking. Не дуже приємна річ, яка жорстко контролювалася менеджерами.
Одного розробника з Індії звільнили через те, що в нього занадто мало було кліків мишкою.

В тайм-трекере самом по себе ничего плохого нет. Проблемы в извращенных формах контроля — я их называю «календарным тетрисом», когда PM использует время как единственный инструмент планирования, забывая контролировать скоуп и приоритеты. В команде должно быть понимание, что 8 часов по тайм-трекеру — это уже овертайм (честный 8-часовой рабочий день — это где-то 7 часов по трекеру), а эстимейты — это не кровные клятвы, а оценка сложности задачи. Есть хороший принцип «fixed time, variable scope». При правильном использовании тайм-трекер не вызывает стресса в команде.

Тайм трекер сам посебе рабство. Он и есть извращенный способ контроля. Если разработчик ненавидит свою работу и его нужно гонять тайм трекером, значит руководство наняло не того

Ода мікроменеджменту від менеджерів початківців. Що цікаво, усі через це проходили, я бігав по столах як те робили до мене іньщі тімліди :) Не те щоб контролювати виконання не треба, але для цього існують іньщі методи. Почати треба з того щоб ставити завдання і делегувати його. Той самий Scrum допоможе, скажімо planing poker для з’ясування чи розуміють задачу, backlog grooming, попросити видати архітектуру тощо. Тайм трекер як і ньщі методи мікроменеджменту це приблизно те саме, що і вимірювати продуктивність кількістю написаних операторів. Можна в милі та поті працювати по 12 годин в день, аж мозолі на пальцях клавіатурою натерти, але у підсумку робити і не те і не так, та отримати в кращому випадку нульовий результат, бо як переробляти доведеться — то вже і негативний результат.

йоптя. не думав, що таке взагалі буває

В одній з перших компаній десь через півроку після того, як я туди влаштувався, ввели трекер зі скріншотами екрану, підрахунком активності. І це навіть не на робочому ноуті. Я спочатку не розумів, навіщо — це маленька компанія, до 10 працівників, якщо хтось відлинюватиме від роботи, буде і так помітно.
А через пару місяців звільнили єдиного бекенд-розробника. Він пішов, гучно хлопнувши дверима і нашкодивши на хостингу на пару тисяч доларів.
Власне, як зʼясувалося, трекер ввели саме через нього. Задачі по бекенду висіли тижнями, і по факту, той товариш був типовим «зайчиком», який працював ще в парі місць, а тут майже нічого не робив.
Єдине, що я досі не розумію, це чому одного недостатнього перформансу людини було недостатньо для звільнення, і власник вирішив ввести трекер для всієї команди. А після звільнення «зайчика» трекер не відмінили. Власне, через той трекер я ще через пару місяців звільнився, бо замучився дьоргати мишку.

бо замучився дьоргати мишку

я спочатку не розумів той жартик навіщо кодерам годинник з стрілками, а потім як зрозумів!

Був сумний досвід в моєму житті коли працював в конторі де при вході стояв сканер карток і трекали робочий час по карткам. Перекури теж трекали. Але оскільки контора займалась виключно г@вн@кодом то і трекер був зроблений як кусок лайна.
За один вечір був написаний бот який відправляв потрібні запити в трекер і життя налагодилось)
П.С. З контори звалив за першої ліпшої нагоди.

«Мало, тільки дейлі дзвінки зі статусами»

А колись у старі добрі часи щоденні звіти були дисциплінарним засобом для роздовбаїв.

Легше не наймати роздовбаїв і не потрібно зі звітами довбатись)))

В одній прекрасній компанії, коли йдеш на лікарняний, ейчари намагались дізнатись, а чим саме ти захворів

Після прийняття оферу дізнався, що на проєкті є трекер, звісно одразу повідомив рекрутера, що відмовляюсь працювати з трекером, але виявилось що то звичайне логування часу як в Jira, без встановлення на машину.

логувати в жирі це ок, логи часу допомагають в ретроспективі і в майбутніх естимаціях

Якщо потім ДІЙСНО роблять естімації, ретро та імпруви.

Кожного ранку треба було писати в чатік «good morning», щоб інші люди розуміли, що ти працюєш. Бачиш, статуси в слеку від балди просто придумали. Після дейліка, на якому говорили про результат роботи за вчора і плани роботи на сьогодні, це все саме треба було написати в текстовому варіанті. Коли ти йшов на обід, треба було писати про це, а також про статуси поточних задач, які виконав. Коли повертався з обіду — також написати про це. Коли закінчував робочий день — написати про це і написати статуси за весь робочий день.

Ну і для чого в таких конторах працювати? Перший тривожний дзвіночок — пакуємо речі і переходимо в іншу контору. Терпіти таке хіба допустимо для трейні перші 6 місяців, щоб десь закріпитися, і то...

Я взагалі після подібних статей і статей на прекрасному.айті приходжу до висновку, що наш народ не сильно відрізняється від кацапів. Бо для наших теж працює ісконно руснявий принцип:
«Нас е**т, а мы крепчаем»

А хто сказав, що я там ще працюю? 😅

А, ну якщо втекли після першого дзвіночка, то без питань) Просто зазвичай терплять місяцями, а то й роками, якщо почитати такі статєйки)

Спочатку, насправді, все було добре. Після випробувального пішло не в ту сторону. Зміни на горизонті не планувалися, тому.. Та і особистий час та здоров’я дорожче за ті нерви, які були чи не кожного дня.

Підписатись на коментарі