Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Опишіть available capacity і підтверджені unknowns.
Сформулюйте, що безпечно завершити до deadline.
Запропонуйте явний вибір: зменшити scope, змінити deadline або прийняти перелічені quality risks.
Одне коротке повідомлення без звинувачень і без обіцянки прихованого overtime.
Не маскувати недооцінку — не означає навмисно ламати tests або quality gates. Фіксуйте deferred checks, carry-over і risk, не позначайте неперевірене як done та вимагайте явного рішення про scope, deadline або quality.
Як працювати на спокійному проєкті та з нав’язаними оцінками →[Дивитися з 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.
Орієнтир для завершення домашніх робіт — кінець або середина березня залежно від фактичного темпу групи. Термін може коригуватися, якщо окрема практика стабільно потребує більше часу, ніж очікувалося.