Кейс: підрядник зсуває строк на два тижні

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

У Klasna ланцюжок оплати має три ланки. У підрядника лишилося 10 робочих днів задач (C3 4, C4 2, C5 2, C6 2; C1 і C2 готові). Після його релізу платіжний провайдер перевіряє нову продуктову лінію 5 робочих днів. Потім Danylo проводить наскрізний тест зі справжніми тестовими покупками — 2 робочі дні. Заняття стартують у понеділок, 1 лютого, тож ланцюжок має бути готовий до п’ятниці, 29 січня: 15 робочих днів від понеділка, 11 січня, враховуючи сьогодні.

Додай ланки: 10 + 5 + 2 = 17 робочих днів проти 15. Реліз 22 січня, провайдер до 29 січня, тест до вівторка, 2 лютого: два робочі дні запізнення. Початковий план мав реліз 8 січня й 8 днів буфера; цього буфера більше немає. Бери дні, що лишилися, зі списку задач, а не планові дні чи заявлені відсотки.

Зароблений прогрес — легка перевірка того, скільки запланованої роботи справді зроблено: для кожної задачі її планові дні × її відсоток готовності, підсумовані й порівняні із загальним планом. Він показує, наскільки просунулася робота в одиницях самого плану, і це корисніше за відчуття «майже готово».

Для шести задач підрядника в Klasna: C1 5 днів на 100 % = 5, C2 3 на 100 % = 3, C3 6 на 50 % = 3, C4 2 на 0 % = 0, C5 4 на 50 % = 2, C6 5 на 60 % = 3. Разом 16 із 25 планових днів зароблено: 64 %.

А тепер підступ. Зароблений прогрес дивиться назад; прогноз має дивитися вперед. C3 «готова на 50 %» при 6 днях, але її нова оцінка — 4 дні, а не 3: задача виросла. Тож переплан бере дні, що лишилися (10), а не 25 − 16 = 9. Коли зароблене й оцінка залишку розходяться, перемагає оцінка залишку від того, хто робить роботу, а сама різниця — привід для запитання.

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

У Klasna «простий вихід» Danylo — другий розробник підрядника: десять днів роботи, двоє людей, п’ять днів, реліз 15-го. Власна оцінка підрядника — 20 січня. Новенький три дні вивчає код, а задачу оплати не поділиш між двома. Зекономлено два дні замість семи — за 48 000 грн, по 6 000 грн на день щонайменше вісім днів. Із 52 000 грн під стелею лишається 4 000, а ланцюжок готовий 29 січня з нульовим буфером.

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

Коли дата не зсувається, а гроші майже скінчилися, гнеться обсяг: спершу випускаєш must, решту — після відкриття. Роботу робить колонка пріоритету; питання лише в тому, які із задач, що лишилися, справді потрібні для відкриття.

У Klasna C3 оплата (4 дні) і C4 квитанції (2 дні) — must: 6 днів. C5 синхронізація календаря репетиторів — should, C6 розстрочка — could. Якщо підрядник спершу випустить must, реліз буде в понеділок, 18 січня. Провайдер перевіряє 19–25 січня, Danylo тестує 26–27 січня, і ланцюжок готовий у середу, 27 січня. Із 15 робочих днів лишається 15 − 6 − 5 − 2 = 2 дні буфера, без додаткових витрат. Підрядник доробляє C5 і C6, поки провайдер перевіряє, і вони виходять після відкриття.

У скорочення теж є ціна, тож назви її: без синхронізації календаря Roman близько двох тижнів вручну бронює вечірні слоти репетиторів. Незручно, але не фатально, і ця ціна платиться зусиллями, а не датою відкриття.

Напівготова функція сильно тягне: «ми вже заплатили за більшу частину». Але вже витрачені дні — витрачене (sunk): однакове за будь-якого варіанта, тож вирішувати не може. Питання лише в тому, чи варта решта ціни того, що вона дає зараз.

У Klasna розстрочка (C6, пункт could) готова на 60 %: три з п’яти днів, уже оплачені. Ще два дні — і родини зможуть платити двома частинами з першого дня. Дивись лише вперед: ще два дні зараз проти буфера рівно у два дні перед перевіркою провайдера, яка ще може не пройти (R01 у реєстрі). Повернення C6 у перший реліз зсуває його на 20 січня, і ланцюжок готовий 29 січня з нульовим буфером.

Відкласти — не викинути. Розстрочка вийде в лютому, після відкриття; родини роками платять за пакети одним платежем, тож це приємний додаток, а не причина відкриватися пізніше. Три оплачені дні теж не втрачено: вони лишаться у функції, коли вона вийде.

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

У Klasna відкриття 15 лютого з повним обсягом дає 8 робочих днів буфера й нічого не коштує зараз. Натомість кожна родина втрачає два тижні сезону іспитів — саме через нього дату й зафіксували, — а перевірка результату на 120 учнях 28 лютого отримує два тижні продажів замість чотирьох. Безпечний графік, який пропускає мету проєкту, не безпечний.

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

Варіанти в переплані йдуть не до однієї людини. Їх сортує правило змін із початку модуля: нижче домовленого порогу вирішує лід і повідомляє в статусі; вище порогу або коли зсувається фіксована межа, вирішує спонсор письмово, протягом двох робочих днів, а рішення записують у журнал.

У Klasna поріг ліда — до двох днів буфера й 10 000 грн із резерву; дата, стеля бюджету, список «не входить» і критерії успіху належать Leo. Тож випустити C5 і C6 після відкриття вирішує лід: це не змінює жодного критерію успіху, нічого не коштує й зберігає буфер. Заплатити 48 000 грн за другого розробника — набагато вище порогу в 10 000 грн і майже спустошує резерв: рішення Leo. Перенести відкриття на 15 лютого — зсув фіксованої межі: рішення Leo.

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

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

Для варіанта A в Klasna, з двома днями буфера перед перевіркою, яка може не пройти, добра пара така: «Якщо обов’язкових задач немає на тестовому сайті до понеділка, 18 січня, або провайдер не схвалив до 25 січня, я того самого дня повертаюся до тебе з B чи C». Кожна дата лишає дні, щоб діяти. Запасний план використовує вже оцінені варіанти, тож нікому не треба вигадувати їх під тиском.

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

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