01 · Відновлення IT-проєкту
Проєкт втратив темп. Вендор не відповідає. Бюджет тане без видимого прогресу. Перш ніж звільняти команду, переписувати з нуля чи списувати витрати — структурне відновлення з ясним планом, що далі.
↓ Розгорніть секцію, щоб дізнатися більше
Чому мені можна довіряти
Діючий CEO AI-стартапу TreximAI · 8 років BA у IT — AI-продукти, логістика, фінтех, B2B SaaS
Усі кейси на сайті — це ілюстративні патерни з 8 років роботи у IT. Опублікованих клієнтів поки немає.
Кожна починається як інша проблема, а закінчується схожим запитом: треба, щоб хтось чесно прочитав ситуацію і запропонував робочий план.
Дзвінки переносяться. Оновлення приходять рідше. Slack-канал, де раніше була робота, поступово затих. Можливо, команда перевантажена; можливо, проєкт став для них непріоритетним; можливо, ключовий розробник пішов. У будь-якому разі — реакція повільніша, ніж потрібно, а витрати йдуть. Перше завдання — чесно зрозуміти, чи можна налагодити стосунки, чи краще завершити їх чисто.
Старт був на $40K. Зараз — $80K, а оригінальний список фіч ще не закритий. Кожен запит на зміни приходить з новим "це потребуватиме ще два тижні". Ви не впевнені, чи це чесне re-scope, чи проєкт просто розтягують. Перше завдання — розділити справжні зміни обсягу від накачки, переписати угоду на прозорих умовах, і відновити прогрес за milestones.
Люди залучені. Стендапи відбуваються. Sprint review показує рух. Але реальний ship зупинився — і ніхто всередині команди не може це назвати. Перше завдання — прочитати ситуацію поза внутрішньою політикою: процес, scope, технічні припущення — і знайти справжній блокер без шкоди для відносин.
Робота йде поетапно. Кожна фаза закінчується конкретним рішенням, яке ви можете прийняти на основі реальних даних.
Читаю кодову базу, контракт з вендором, історію комунікацій, інтерв'юю команду. Виявляю, що насправді не працює, а що — лише симптом. На виході: одно-сторінковий план відновлення, який можна показати кофаундерам, інвесторам чи раді.
Або переписуємо угоду з вендором на прозорих умовах, або чисто закриваємо співпрацю. Відновлюємо щотижневий ритм delivery. Триажуємо технічний борг — що виправляємо, з чим живемо, що плануємо на потім. На виході: predictable ship і зупинена фінансова втрата.
Один з двох сценаріїв. Або проєкт стабільний з існуючою командою — я виходжу, залишаючи документацію і ясний наступний крок. Або переходимо до перевіреної команди з мережі — зі структурованим handover. У будь-якому разі проєкт працює без мене у кімнаті.
Кінцева цінність — не у плані самому по собі, а у тому, до чого він приводить:
Нова команда вирішує задачу "хто буде писати код". Відновлення вирішує задачу "що саме треба робити і чому проєкт зараз не йде". Часто перший крок виявляє, що команда не є проблемою — проблема у scope, угоді чи процесі. У такому випадку нова команда лише повторить ту ж ситуацію через 3 місяці.
Це чесна відповідь, і я скажу її прямо. Тоді робота фокусується на: чітке закриття поточних угод з мінімальними втратами; рятування того, що можна зберегти (дані, частина коду, ринкові висновки); і план, що робити з бюджетом, який залишився. Краще прийняти це рішення на 5-му тижні, ніж витратити ще 4 місяці на те, що не злетить.
Перший продуктивний ефект — на кінець фази 1 (тиждень 2): ви матимете план і чесну картину. Реальна стабілізація delivery — фаза 2 (тижні 3-8), залежно від глибини проблеми. Якщо проєкт у дуже глибокій кризі — буде довше; чесний прогноз обговорюємо після діагностики.