Разработване на софтуер с надеждно изпълнение на проектите

Да. Не е необходимо проектът да започва от нулата, за да бъде поет от нов екип.

Обикновено работата започва с технически преглед на съществуващия код, инфраструктурата, използваните зависимости, структурата на базата данни и начина на публикуване на нови версии. Така може да се установи кои части са стабилни, къде има натрупан технически дълг и дали съществуват рискове, свързани с липса на документация или специфични решения в архитектурата.

След това разработката може да продължи поетапно. Работещите части се запазват, а проблемните се подобряват тогава, когато има реална причина това да бъде направено. Цялостно пренаписване има смисъл само когато поддръжката и развитието на съществуващата система биха били по-скъпи или по-рискови от изграждането на ново решение.

Това е нормална част от много софтуерни проекти. Нови идеи и нужди често възникват след преглед на прототип, готова функционалност или обратна връзка от реални потребители.

Всяка по-съществена промяна се разглежда според влиянието ѝ върху обхвата на проекта, сроковете, зависимостите и вече разработените функционалности. Малките корекции могат да бъдат включени в текущата работа, докато по-големите промени обикновено се планират за следващ или отделно договорен етап на разработка.

Така продуктът може да се развива според реалните нужди, без новите идеи постепенно да доведат до неясен обхват, непредвидени разходи и постоянно отлагане на завършването.

Да. Външният екип може да допълва вътрешния, вместо да го заменя.

Отговорностите могат да бъдат разделени според конкретни модули, технологии или натоварване. Например вътрешният екип може да продължи да развива основната система, докато външният поеме нов API, интеграция с друга платформа, отделен frontend модул, инфраструктурна задача или по-сложна функционалност.

Важно е още в началото да бъдат уточнени техническите граници между екипите, правилата за работа с хранилищата, процесът за преглед на кода и отговорността за отделните компоненти. Това намалява риска различни екипи да решават един и същ проблем по несъвместим начин.

В много случаи това е не само възможно, но и по-разумният подход.

По-старите приложения често съдържат натрупана през годините бизнес логика, която продължава да има стойност, дори когато част от използваните технологии вече са трудни за поддръжка. Пълното пренаписване на такава система може да създаде повече риск, отколкото постепенното ѝ обновяване.

Модернизацията може да се извършва поетапно - например чрез подмяна на неподдържани зависимости, разделяне на силно свързани компоненти, добавяне на API, оптимизиране на базата данни, контейнеризация на отделни услуги или обновяване само на потребителския интерфейс.

Решението зависи не толкова от възрастта на приложението, колкото от неговата архитектура, техническото му състояние и възможността промените да бъдат правени безопасно.

Първата стъпка е да се установи как системата реално работи, а не да се разчита единствено на документация, която може да е непълна или остаряла.

Преди интеграцията да стане важна зависимост за новия продукт, се проверяват наличните API интерфейси, форматите на данните, начините за удостоверяване, ограниченията при заявките и поведението на системата при грешки или прекъсвания.

Когато директната връзка със старата система е твърде ограничена или ненадеждна, може да бъде разработен междинен слой, който да поеме комуникацията с нея. Така нейните технически ограничения не се пренасят върху архитектурата на цялото ново приложение.

Този подход е особено полезен при интеграции със стари ERP, CRM, счетоводни, складови или специализирани бизнес системи.

Клиентът трябва да запази контрол върху проекта и да не бъде зависим от конкретен разработчик или доставчик само защото важни технически ресурси се намират извън неговия достъп.

Хранилищата със сорс код, cloud средите, домейните, системите за публикуване и останалите ключови услуги могат да бъдат създадени директно в акаунти и организации, контролирани от клиента, или да бъдат прехвърлени при предаването на проекта.

Достъпите, конфигурациите и важната техническа информация също трябва да бъдат организирани така, че друг оторизиран екип да може да продължи поддръжката и разработката без ненужни затруднения.

Софтуерът и услугите на външни доставчици остават под съответните им лицензионни условия, а собствеността върху разработения по проекта код и останалите материали се определя според договорените условия.

Кодът, достъпът до инфраструктурата и документацията трябва да позволяват на друг оторизиран екип да поеме работата.