Айтівці, які працюють по 10, 20 і 30 годин на тиждень. Як їм це вдається?

Наш свіжий Портрет ІТ-спеціаліста показав, що чималій частці українських айтівців вдається працювати менш ніж 40 годин на тиждень. Ми розпитали кількох фахівців, що проводять за робочими завданнями 10–30 годин, як оптимізувати свій час і водночас ефективно працювати.

«На минулій роботі я працював 40 годин за ті ж гроші»

Денис, Senior Full Stack Developer. Працює 20–30 годин на тиждень

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

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

За аналогічні гроші на минулій роботі я працював всі 40 годин, деколи були неоплачувані овертайми, періодично мав парт-тайм. Зідзвони інколи займали 4–6 годин на день, з мінімальними перервами між ними.

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

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

«Стандартний робочий день для мене — з 8 до 11»

Віктор, Senior Front-end Developer. Працює 20 годин на тиждень

Я працюю від 15 до 30 годин на тиждень, в середньому 20 годин разом з мітингами. У такому режимі перебуваю від весни. Сиджу на позиції сеньйора, хоча давно її переріс. Через це завдання вдається виконувати швидше.

Свою нинішню роботу я взяв як додаткову понад рік тому. Йшов на позицію, нижчу від мого рівня свідомо, аби не витрачати на неї багато часу. Але від основної роботи довелося відмовитись, бо там були співробітники з росії. Тож додаткова робота стала основною, а позаяк бізнес і команду влаштовувала швидкість і якість виконуваних завдань, більше часу я працювати не став.

Хоча я і на попередніх роботах не надто напружувався. Раніше у мене виходило працювати не більш ніж 5–6 годин на день, крім періоду, коли я обіймав посаду ліда. Тоді протягом двох місяців довелося працювати 10–12 годин на день, доки не налаштував процеси в команді. А згодом повернувся до звичних 5–6 годин, тому й вирішив піти на додатковий проєкт.

Не можу сказати, що якісь завдання займають у мене особливо багато часу. А от що справді його пожирає — мітинги, де моя присутність не є обовʼязковою, але в яких я позначений як required. Вони додають 1–3 години робочого часу на тиждень.

☝️ Тож чому я працюю мало?

По-перше, я на комфортній позиції. Крім цього, намагаюсь працювати вранці, оскільки до обіду найбільш продуктивний. Одну й ту саму задачу о 8-й ранку і о 16-й я виконуватиму з різною швидкістю. Тому стандартний робочий день для мене — з 8 до 11. Ще годину-півтори на день займають мітинги. Так і виходить у середньому 20 годин на тиждень.

«У замовника мало задач, але дуже багато грошей»

Олексій, Software Engineer. Працює 10–20 годин на тиждень

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

Але річ не лише у цьому. Уже рік ринок акцій штормить, завдання з’являються дуже рідко — раз на кілька місяців. І зазвичай ці фічі прості, бо всі менеджери «на стрьомі» через нестабільний ринок. Повсякденні завдання — це підтримка, баг-фікси, невеликі доробки. Тож нині на проєкті кожен член команди має по дві задачі на тиждень.

До того ж так мало часу витрачати на проєкт я почав не одразу. Кодова база там нереально великого розміру. Коли я тільки прийшов, тривалий час перевіряв усі можливі шляхи використання мого коду. І це, мабуть, гарне зауваження — спочатку варто добре вивчити проєкт, як він працює і для кого, а потім вже писати код.

Раніше я працював на багатьох невеликих проєктах у маленьких компаніях. Часто в роботі одночасно були два-три проєкти, на які я витрачав в середньому 20 годин, відповідно 40–60 годин на тиждень. Але, ймовірно, так відбувалось через скупість замовників на маленьких проєктах.

«До розслабленої роботи я довго йшов через навчання та набуття досвіду»

Сергій, Release Train Engineer. Працює 15–20 годин на тиждень

Мені вдалось вийти на такий графік, бо я делегував обов’язки, автоматизував звітність, навчив колег планувати та адаптувати плани самостійно.

Доки я працював через аутсорсингові компанії, а тим паче в офісі, такого графіку було неможливо досягти. Був я у багатьох ролях, від розробника та бізнес-аналітика до Agile-коуча, програм-менеджера та директора департаменту.

Але 2020 року, після початку пандемії, я став незалежним консультантом, переважно на короткотермінових контрактах (2–3 місяці, часто з подовженням) безпосередньо на європейських та британських ентерпрайзів.

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

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

Командам я показую, як розбивати роботу на ітерації, використовувати техніки user story mapping або specification by example, проводити релізне планування. Зараз я в ролі Release Train Engineer, бо клієнт переходить на Scaled Agile Framework і запросив мене як консультанта.

Попереду ще проведення PI Planning, всіх ART sync events, сприяння підготовці до наступного PI Planning. Воно використовується для покращення розуміння командами своїх клієнтів та визначення пріоритетів у роботі.

Довідка

User story mapping (картування історій користувачів) — це візуальна вправа, яка допомагає менеджерам продуктів та командам розробників визначити, що саме потрібно створити та як поєднати, аби лишити у користувача найбільш приємні враження від продукту.

Specification by example (cпецифікація за прикладом) — це комплексний підхід до визначення вимог та бізнес-орієнтованих функціональних тестів для програмних продуктів, що ґрунтується на фіксації та ілюстрації вимог з використанням реалістичних прикладів замість абстрактних тверджень.

Спочатку треба 1–2 рази самостійно пройти все разом з командою, щоб прибрати страх перед новими практиками, потім навчити Scrum Masters та продакт-менеджерів, а далі вони можуть справлятись без мене — це найбільш «розвантажена» фаза роботи з певним замовником :)

«Чарівних пігулок» для розподілу часу та ефективної роботи я, на жаль, не маю — до розслабленої роботи з високим daily rate я довго йшов через навчання, набуття досвіду в різних компаніях та індустріях тощо.

Демонстрація досвіду формує довіру, а довіра дає змогу працювати на результат, а не по 40 годин на тиждень. Як у виші: спочатку працюєш на залікову книжку, а потім — вона на тебе.

«Мені вистачило трьох ситуацій, щоб перестати розтягувати робочий день»

Максим, Tech Lead. Працює 25–30 годин на тиждень

Я вважаю, що люди діляться на дві категорії: ті, що отримують задоволення від процесу, та ті, що отримують задоволення від результату.

Мене завжди дивувало, як люди працюють в офісі — відвідують безліч мітингів, де 30–40 хвилин обговорюють те, що можна було б сформулювати одним листом, чаюють на кухні, скролять годинами соцмережі.

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

Мені вистачило трьох ситуацій, щоб перестати розтягувати робочий день.

🛠️ Ремонт у квартирі. Коли вдома ремонт, то прямо посеред робочого дня часто доводиться пояснювати робітникам, що саме хочеш отримати в результаті. А ще — зриватися і їхати на пошуки матеріалів, яких бракує. Проєктні задачі при цьому мають бути виконані. Ті, хто пройшов через ремонт, ймовірно, зрозуміють, про що я. У той період я часто дороблював завдання вже вечорами або у вихідні.

👨‍💻 Рішення взяти додатковий проєкт — все завдяки коронавірусу і роботі вдома.

Про це все багато написано на DOU, не хочу повторюватися. Але головне — пам’ятати закон Паркінсона: «Робота завжди займатиме весь відведений на неї час».

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

👨‍👩‍👧 Сім’я і дитина. З появою дитини стає менше часу. А ще усвідомлюєш, що тебе можуть відволікти в будь-яку мить: дитині неважливо, які в тебе пріоритети. Якщо вона підійшла до тебе, то першочергове завдання — приділити їй хвилину уваги тут і зараз.

До речі, інколи я навіть спостерігаю, як люди без дітей все роблять без поспіху та розслаблено, наче смакуючи себе в моменті, у чомусь я їм заздрю :) Під час роботи я намагаюсь зосередитися і працювати якомога продуктивніше, доки є час. Я точно знаю, що не зможу допрацювати ввечері — у мене немає привілею овертаймів.

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

⏳ Ось кілька моїх правил для оптимізації часу.

• Жодних беззмістовних мітингів. Якщо вас кличуть на зустріч, де ви або просто мовчите, або не впливаєте на обговорення, або не маєте ініціативної чи принципової позиції з озвученого запитання — одразу кажіть, що у вас, на жаль, є тільки 10 хвилин. Якщо така ситуація всіх влаштовує, значить насправді ви на тому мітингу і не потрібні.
• Основну роботу краще виконати до обіду, коли ви ще свіжі та сповнені сил. За собою я помітив: що ближче кінець робочого дня, то довше я обдумую елементарні рішення.
• Ніхто і ніколи не має права змушувати вас працювати у позаробочий час або нав’язувати нереалістичні терміни виконання задач. Просто не беріть участь у цих аферах — це завжди вилазить боком всім, особливо якщо є натяки на регулярність.
• Кілька рутинних задач можна виконувати одночасно.
• Перфекціонізм поїдає енергію. Найкраще — ворог хорошого. Для мене, наприклад, найкраще працює ітеративна розробка. Тобто спочатку ми робимо драфт рішення, яке реалізує концепцію задачі, а потім рефакторимо і свій, і чужий код. Суть у тому, що ви вже розумієте обсяг змін і одразу дійдете правильного висновку, а не намагатиметесь будувати чисте рішення з нуля.
• Немає жодного сенсу бути топперформером — це нікому не потрібно. Замовники люблять передбачувані команди, які працюють у режимі марафону без вигорянь, а ваші колеги не захочуть червоніти на стендапах, коли ви розповідаєте, як переробили всю роботу, а вони весь день лише на мітингах сиділи.
• Працюйте в темпі команди. Краще заробляти репутацію якістю реалізації та складністю задач, а не їхньою кількістю. Якщо вам здається, що ви б давно позакривали всі великі завдання, «якби не ця повільна команда», то не нагнітайте атмосферу — візьміть собі ще один проєкт або ж спрямуйте сили на хобі, спорт тощо — і все стане на свої місця.

Не вигадуйте складнощів там, де їх немає. Замовнику байдуже, як ви реалізовуєте «Абстрактну фабрику», — головне, щоб ви легко підтримували код проєкту і всі його розуміли. Що зрозуміліше і чистіше все зроблено, то краще. Бо класична ситуація, коли людина нарешті усвідомлює, як працює полотно замудреного коду, але сил і бажання виконувати завдання поверх цього коду вже немає.

«Моя мета — працювати по дві години на день»

Антон, Python Developer. Працює 25–30 годин на тиждень

Я нині працюю в середньому п’ять годин на день, умовно з 11 до 17 години з перервою на обід. Бувають дні, коли треба більше напружитися і посидіти до ночі, особливо якщо просять щось швидко заделіверити. Але таке трапляється нечасто. Питань щодо перформансу мені не ставлять, тож обсяг виконуваних задач достатній.

На попередній роботі я почав практикувати «лінивий понеділок» — спеціально відпочивати та вкладати свій робочий тиждень у чотири дні. На теперішньому місці я поки що не відчуваю, що опанував стек достатньо, щоб відпочивати у понеділки.

Моя мета — працювати по дві години на день, але для її виконання потрібно пропрацювати на одному місці не менш ніж кілька років. Я ж, коли мені пропонують офер на +30-50% від зарплати, одразу йду на нове місце, відповідно доводиться опановувати новий стек та кодову базу.

Чи виконував би я більший обсяг задач, якби працював по вісім годин на день? Не факт. Тоді б я менше відпочивав і був би менш ефективним. А так вільний час я витрачаю на сім’ю, хобі та власний розвиток.

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

Загалом понад 40 годин на тиждень я навряд чи колись працював, бо навіть якщо на тижні і траплявся день, коли доводилося посидіти над завданням з 8 ранку до 12 ночі, то всі інші дні були легкими.

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