Айтівці, які працюють по 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 хвилин обговорюють те, що можна було б сформулювати одним листом, чаюють на кухні, скролять годинами соцмережі.

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

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

Похожие статьи:
Старший віцепрезидент GlobalLogic Андрій Яворський в інтервʼю для Економічної правди розповів про те, які виклики мають українські...
Меня зовут Антон, я менеджер проектов, и это моя первая статья на DOU. Готов предположить, что она будет полезна...
На правах рекламы Большое разнообразие линеек телевизоров на российском рынке в настоящее время затрудняет...
Український шеф-кухар і ресторатор Євген Клопотенко шукає IT-компанію, яка могла би реалізувати проєкт...
[У рубриці «Як я працюю» ми запрошуємо гостя відповісти на бліц-питання про організацію свого...
Яндекс.Метрика