Sustainable pace
Передбачуваний робочий темп, який можна підтримувати без системного overtime та приховування реальної capacity.
Як працювати на спокійному проєкті та з нав’язаними оцінками →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Перевірити культуру проєкту на співбесіді
Підготуйте п’ять питань про estimation, scope changes, overtime, carry-over і incident recovery.
Для кожного питання визначте healthy signal і red flag.
Не використовуйте загальне питання про work-life balance без прикладу реальної ситуації.
Таблиця з питанням, healthy signal і red flag.
Сформулювати відповідь на нав’язаний estimate
Опишіть available capacity і підтверджені unknowns.
Сформулюйте, що безпечно завершити до deadline.
Запропонуйте явний вибір: зменшити scope, змінити deadline або прийняти перелічені quality risks.
Одне коротке повідомлення без звинувачень і без обіцянки прихованого overtime.
Ознаки спокійного проєкту
[Дивитися з 00:00](https://www.youtube.com/watch?v=reaHS8_pZbU&t=0s). У великій компанії частіше вже сформовані processes, розподіл відповідальності й розуміння, що постійний overtime шкодить людям і результату. Але розмір сам по собі нічого не гарантує: work-life balance треба перевіряти конкретними питаннями на співбесіді. Корисно запитати, хто оцінює work, чи бере участь команда, як змінюється scope після estimate, що відбувається при невиконанні sprint commitment і чи оплачуються понаднормові години. Регулярний overtime зазвичай вказує на проблему з prioritization, scope changes або estimation, а не на недостатню відданість інженера. Власні estimates радять робити з резервом на невідомі залежності, перевірку та recovery після помилок.
Спочатку відпочинок, потім кар’єрне рішення
Компанія — не сім’я, але здоровий менеджмент має пам’ятати, що працює з людьми. Не варто компенсувати проблеми проєкту постійним overtime. Якщо є виснаження, перший крок — зменшити scope, використати відпустку, повернути хобі й час із близькими. Sabbatical доречний, коли є фінансова подушка та реальна можливість його взяти. Матеріальний стан важливий, але його треба співвідносити з ціною для психологічного здоров’я; рішення не варто зводити лише до максимальної зарплати.
Що робити, коли задачі оцінили без команди
[Дивитися з 14:25](https://www.youtube.com/watch?v=reaHS8_pZbU&t=865s). Якщо estimate нав’язано ззовні, команда не повинна регулярно рятувати його unpaid overtime: тоді management бачить лише формально виконаний plan і не отримує evidence, що estimation process зламаний. Потрібно фіксувати фактичний effort, невідомі залежності, скорочений testing scope та carry-over, а на retrospective вимагати участі виконавців в оцінюванні. Сильніша позиція виникає, коли кілька інженерів незалежно описують ту саму проблему фактами. Спочатку питання піднімають із tech lead/engineering lead, потім — на retro або з manager, якщо прямий канал не працює. Повідомлення має бути не «ми не хочемо встигати», а «за такого scope й available capacity безпечний результат потребує X; до deadline можемо завершити Y, решту переносимо або свідомо приймаємо перелічені ризики». У відео також звучить ідея зробити недооцінку видимою через накопичення нестабільних tests і technical debt. Навмисно ламати quality gate не варто: це створює product risk і послаблює аргументацію команди. Правильний еквівалент — не приховувати незавершену роботу, явно документувати deferred checks/debt, не позначати неперевірене як done і вимагати product decision про scope, deadline або quality.