Безпечний перехід ІТ-проєкту від одного підрядника до іншого

• Ключові аспекти, які слід врахувати в плані переходу проєкту
  • Бізнесовий аспект (Швидкість переходу та повнота інформації)
  • Безпека (Доступ та конфіденційність)
  • Технічний аспект (Необхідна документація)
  • Фінанси (Будьте готові до непередбачуваних витрат)
  • Людський фактор (Зустрічі та оцінки)
• Після завершення плану переходу проєкту що йде далі?
• Технічний аудит
• Наш досвід переходу між постачальниками ІТ-послуг
• Останнє зауваження щодо переходу ІТ-проєкту

Робота над великим проєктом із розробки програмного забезпечення може тривати роками, і за цей час багато чого може змінитися. Часто виникає потреба змінити постачальника послуг ще до завершення розробки. Однак створення плану передачі проєкту від одного постачальника до іншого — це зовсім не проста справа. Існує чимало важливих аспектів, які слід врахувати. Приєднуйтесь до нас, і ми розглянемо їх у цій статті.

Як компанія, що спеціалізується на розробці кастомного програмного забезпечення, у SECL Group ми настільки часто успішно виконували передачу ІТ-проєктів, що це стало однією з наших нових сфер експертизи. За нашим досвідом, рішення змінити підрядника зазвичай приймається тоді, коли проєкт розробляється вже кілька років — як правило, у випадках, коли поточній команді бракує якості або ресурсів для підтримки чи подальшої розробки проєкту. Проте існують ризики, і якщо передача проєкту буде виконана неправильно, новій команді може знадобитися дуже багато часу (і коштів), щоб фактично розпочати роботу над ним.

У цій статті ми торкнемося критичних аспектів передачі ІТ-проєкту. Хоча дехто може подумати, що перехід проєкту стосується лише технічних аспектів, на нашу думку, бізнес-фактори та фактори безпеки іноді є навіть більш важливими. Тому давайте спочатку поговоримо про них детальніше. Ми також обговоримо, як детальний план переходу на нового постачальника може зменшити більшість ризиків, пов’язаних з цим процесом.

Ключові аспекти, які слід врахувати в плані переходу проєкту

Бізнесовий аспект (Швидкість переходу та повнота інформації)

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

У SECL Group ми неодноразово опинялися в ситуації, коли не отримували жодної інформації про проєкт і були змушені вивчати все з нуля. В одному з крайніх випадків наша команда отримала проєкт, який навмисно було змінено таким чином, щоб ми не змогли одразу розпочати роботу. Ми пишаємося тим, що навіть у такій ситуації змогли розібратися й почати роботу у прийнятні терміни. Як ми кажемо: “Немає нічого неможливого — питання лише в тому, скільки це займе часу”.

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

Ці показники свідчитимуть про те, що передача вашого проєкту пройшла ефективно:

• Швидка передача інформації від однієї команди до іншої.
• У нового виконавця майже немає труднощів чи неясностей перед безпосереднім стартом роботи над проєктом.
• Нова команда розробників швидко запускає проєкт і робить подальшу розробку ефективною.
• Можлива безперервна робота над проєктом.

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

Безпека (Доступ та конфіденційність)

Після завершення передачі програмного забезпечення ваш колишній підрядник не повинен мати жодного доступу до вашого проєкту й не повинен зберігати жодні матеріали на своїх пристроях. Ви навіть можете передбачити штрафи за порушення цих умов у своїй угоді про нерозголошення (NDA). Водночас майте на увазі, що не існує абсолютно надійного способу перевірити, чи всі працівники дійсно видалили файли й доступи до вашого проєкту, — саме тут можуть виникати ризики, пов’язані з безпекою.

У SECL Group ми одного разу стикнулися з подібною ситуацією. До нас звернулася місцева медіакомпанія з проханням оновити дизайн їхнього сайту, зберігши при цьому технічну основу. Наша команда мала перенести проєкт зі старого сервера на більш потужний, оскільки сайт працював повільно. Спочатку завдання здавалося відносно простим, і ми розпочали з перенесення сайту на нові сервери. Однак відразу після завершення перенесення сайт перестав працювати.

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

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

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

Технічний аспект (Необхідна документація)

Передача документації проєкту — найважливіша частина будь-якого плану передачі ІТ-проєкту. Завдяки добре підготовленій документації ваша команда матиме відповіді на всі питання щодо специфіки вашого проєкту. Вони зможуть легко та швидко заглибитися в деталі проєкту.

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

• Опис технічного стеку (усі мови програмування, фреймворки та бібліотеки)
• Вихідний код
• Архітектура програмного забезпечення
• Документація з розгортання проєкту
• Документація про середовище розробки (додаткове програмне забезпечення на сервері)
• Документація з API та інтеграцій (за наявності)
• Дизайн-гайди та мокапи
• Плани й специфікації тестування
• Інформація про API

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

Фінанси (Будьте готові до непередбачуваних витрат)

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

Людський фактор (Зустрічі та оцінки)

Незалежно від того, скільки уваги ви приділяєте технічним аспектам передачі проєкту, саме вони не визначають успіх повністю. Усі ми люди, і комунікація в ІТ має вирішальне значення. Для початку можна організувати зустріч між обома командами, щоб вони могли обговорити особливості проєкту, зокрема так званий «технічний борг». Ми розуміємо, що обговорювати його з новим підрядником може бути неприємно, але це може суттєво допомогти новій команді.

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

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

• Сесії запитань і відповідей
• Демо-презентації
• Індивідуальні зустрічі

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

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

Після завершення плану переходу проєкту що йде далі?

Після завершення переходу ІТ-проєкту ми рекомендуємо розпочати технічний аудит для виявлення проблемних ділянок у вашому проєкті. Кожен проєкт завжди має речі, які потребують вдосконалення, але є деякі критичні аспекти, про які ви можете не знати, поки не проведете технічний аудит вашого проєкту.

Технічний аудит

Для зацікавлених сторін, пов’язаних із цілями проєкту, технічний аудит надає незалежну оцінку поточного стану; а для нової команди розробників — це чудова можливість ознайомитися з особливостями проєкту. Для більшості проєктів технічний аудит займає від 40 до 100 годин, але для великих проєктів або таких, що мають нестандартні особливості, може знадобитися більше часу. Хоча під час аудиту неможливо охопити весь код проєкту, він дозволяє новому підряднику краще зрозуміти загальну картину.

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

При зміні підрядника вам також потрібно звернути увагу на будь-які помилки у вашому коді. Буває дуже важко з’ясувати, чи вони виникли внаслідок роботи старої, чи нової команди. Аудит виявить вразливості у вашому проєкті, що може допомогти вам визначити першопричину помилок. Наприклад, ви можете дізнатися, що юніт-тести відсутні або їх недостатньо. Щоб уникнути помилок у майбутньому, вам доведеться покрити проєкт тестами або повідомити клієнта про потенційні проблеми. Ретельний шаблон плану може допомогти запобігти багатьом проблемам для вашого проєкту в майбутньому.

Наш досвід переходу між постачальниками ІТ-послуг

Працюючи в індустрії розробки програмного забезпечення майже 20 років, ми в SECL Group бачили безліч різних ситуацій під час переходу проєктів від одного постачальника до іншого. У кожному випадку ми виявляли недоліки та потенційні можливості для покращення, а також помічали, що власники продуктів часто втрачають багато часу та грошей на цей процес.

Наша компанія спеціалізується на веброзробці, і ми пройшли через десятки передач проєктів. Ми були як командою, яка приймає проєкт, так і тією, від якої проєкт передається. Серед іншого, ми передавали масштабні проєкти, зокрема ті, що були розроблені нами для Kia, Danone та PepsiCo.

Зазвичай це траплялося у випадках, коли клієнт був незадоволений поточним підрядником. Часто йшлося про відсутність документації або низьку якість коду. У таких ситуаціях ми починали з глибокого аудиту та виправлення помилок попередніх команд.

Останнє зауваження щодо переходу ІТ-проєкту

Якщо ви лише розглядаєте можливість передачі інформації від одного ІТ-підрядника до іншого у межах вашого проєкту й не знаєте, з чого почати — звертайтесь до нас. Особливо якщо ви не маєте технічної підготовки. Можете бути впевнені — ми допоможемо розібратись у деталях вашого проєкту. Просто забронюйте першу безкоштовну консультацію — і разом ми створимо ідеальний план переходу програмного забезпечення.