Технічний аудит
Ми перевіряємо архітектуру, якість коду, безпеку, інфраструктуру, розгортання й документацію. У письмовому звіті ризики впорядковані за впливом на бізнес, тож ви знаєте, що виправляти першим.
Порятунок і модернізація ПЗ
Порятунок проєктів, які стало важко змінювати
Попередній підрядник пішов, релізи постійно зсуваються або кожна дрібна зміна ламає щось інше. Ми проводимо аудит коду, виправляємо те, що ставить під загрозу клієнтів, і плануємо модернізацію етапами, які можна закласти в бюджет.
- Технічний аудит перед будь-яким рішенням про переписування
- Спершу критичні виправлення, потім модернізація етапами
- Та сама команда може залишитися на дорожню карту
- 01 Технічна оцінка
- 02 Критичні ризики
- 03 Стабілізація
- 04 Дорожня карта модернізації
- 05 Подальша розробка продукту
Більшість передач проєкту йдуть не так у перший же місяць
Нова команда отримує код, переглядає кілька файлів і починає випускати виправлення. За кілька тижнів перестає запускатися запланована задача або ламається інтеграція клієнта, бо ніхто не знав про її існування.
Ми працюємо у зворотному порядку. Спершу описуємо, що продукт робить у продакшні: сервіси, дані, фонові задачі й інтеграції, від яких залежать клієнти. Потім виправляємо збої, які коштують вам грошей чи довіри. Масштабніша модернізація йде після цього, частинами, кожну з яких ви погоджуєте окремо.
Що входить у порятунок проєкту
Зазвичай етапи йдуть саме в такому порядку, і кожен корисний сам по собі.
Стабілізація
Спершу виправляємо падіння, проблеми з даними й зламані інтеграції. Потім додаємо моніторинг і безпечний процес релізів, щоб ті самі збої не поверталися.
Модернізація
Замінюємо застарілі фреймворки, розплутуємо модулі, які ніхто не наважується змінювати, і переносимо інфраструктуру на таку, яку можна обслуговувати й оплачувати передбачувано. Продукт увесь час залишається доступним.
Довгострокова підтримка
Коли продукт стабільний, ті самі інженери можуть взятися за дорожню карту. Ви зберігаєте контекст, зібраний під час аудиту, замість того щоб платити новій команді за його повторне вивчення.
Як іде порятунок проєкту, етап за етапом
Кожен етап завершується результатом, який ви можете переглянути, перш ніж погодити наступний.
- 01
Доступи й дослідження
Доступ на читання до коду, хостингу й задач, а також розмови з людьми, які користуються продуктом і підтримують його.
Результат Карта системи та її залежностей
- 02
Технічний аудит
Архітектура, безпека, продуктивність, тести й розгортання — з огляду на те, як продуктом користуються сьогодні.
Результат Звіт про ризики, впорядкований за впливом на бізнес
- 03
Стабілізація
Спершу виправляємо критичні баги, прогалини в безпеці й нестабільні релізи. Додаємо моніторинг там, де його не було.
Результат Релізи без сюрпризів
- 04
Дорожня карта модернізації
Залишити, рефакторити чи замінити — вирішуємо для кожного модуля окремо, з оцінкою трудомісткості.
Результат Поетапний план, який можна закласти в бюджет
- 05
Подальша розробка
Нові функції на кодовій базі, яка здатна їх витримати, від команди, що вже її знає.
Результат Передбачуваний ритм релізів
Поетапний порятунок чи повне переписування?
Іноді переписати все — правильне рішення. Але частіше це найдорожчий спосіб заново зʼясувати, що робила стара система.
| Питання | Повне переписування | Поетапний порятунок |
|---|---|---|
| Коли клієнти бачать користь | Після того як нова система наздожене стару за функціями | З першого стабілізаційного релізу |
| Ризик для чинних клієнтів | Високий під час переходу | Обмежений одним модулем за раз |
| Граничні випадки | Часто губляться, а потім виявляються в продакшні | Зберігаються, бо поточну поведінку описано заздалегідь |
| Бюджет | Велике зобовʼязання наперед | Погоджується етап за етапом |
| Коли це доречно | Базова платформа більше не підтримується | Продукт працює, але змінювати його складно й дорого |
Часті запитання
Чи можете ви підхопити продукт, створений іншою командою?
Так, і саме так зазвичай починаються такі проєкти. Перш ніж щось змінювати, ми отримуємо доступ на читання й проводимо технічний аудит архітектури, коду, інфраструктури, документації та процесу поставки.
Що робити, якщо попередній підрядник не завершив проєкт?
Ми визначаємо, що можна безпечно залишити, що блокує запуск, і найкоротшу послідовність робіт, яка доведе продукт до клієнтів.
Чи доведеться переписувати продукт?
Зазвичай ні. Аудит показує, які частини можуть залишитися, які потребують рефакторингу, а які доведеться замінити. Більшість продуктів модернізують модуль за модулем, і вони весь час лишаються доступними.
Чи можна почати лише з технічного аудиту?
Так. Для успадкованого чи нестабільного ПЗ аудит зазвичай і є правильним першим кроком. Ви отримуєте впорядкований список ризиків і план — хоч би хто потім виконував роботу.
Що потрібно від нас, щоб почати?
Доступ на читання до репозиторіїв і хостингу, наявна документація і час із людьми, які знають, де продукт болить.
Join.To.It суттєво підняли рівень якості сайту й розвʼязали багато проблем попередньої версії, яку робив інший підрядник. Вони дуже чуйні й проактивно користуються інструментами для керування проєктом, зокрема Trello, Bitbucket, Slack і Skype. Ми також щодня проводимо стендапи, тож нічого не губиться.