Preluarea de proiecte software poate reprezenta un proces destul de complicat și costisitor în cazul în care acesta nu este făcut cum trebuie de la început, astfel să se desfășoare pas cu pas și fără întrerupere.
În următorul articol se va detalia acest proces, cu analogie pe preluarea unui proiect de aplicație mobilă, dar în mare se aplică în cazul oricărui proiect software.

Transferul în siguranță al proiectului către altă echipă

Deseori, în industria software se întâmplă ca lucrurile să nu mai fie conform așteptărilor. De la creșterea tarifelor dezvoltatorilor în neconcordanță cu calitatea serviciilor oferite, la depășirea termenelor de livrare pentru modulele critice ale aplicației mobile sau proiectului.

Alte motive pot fi reprezentate de neînțelegerea proiectului tău de către echipa de dezvoltare. Pur și simplu, la final de zi îți dai seama că oamenii cărora le-ai explicat cu atâta pasiune despre funcționalitățile pe care vrei să le aduci proiectului tău par să le trateze superficial sau să nu le înțeleagă complet.

Motivele pot fi mai multe și mai diverse, dar cel mai important este să înțelegi greșelile din trecut și să înveți din ele, astfel vei putea să previi mare parte din ele în viitor, cu noua echipă. Alegerea unei noi echipe de dezvoltare aplicații mobile sau dezvoltare software este doar o parte a provocării. Cealaltă parte majoră este pregătirea planului de tranziție al proiectului tău.

Pregătirea planului de tranziție al aplicației mobile

Trebuie să iei în serios planul de tranziție. Este posibil să nu fi o persoană tehnică, așa că nu te sfii să întrebi noul tău furnizor software despre necesitățile lor în preluarea proiectului. Cel puțin, noi, cei de la Brainic suntem pregătiți să te ajutăm în acest proces și să te întrebăm toate detaliile necesare tranziției.

Încearcă să îți înțelegi cât mai mult proiectul

Indiferent că noul tău furnizor o să îți analizeze proiectul, este important să fie înțeles de tine, măcar la nivel macro. În continuare îți prezentăm câteva întrebări la care ar trebui să ai răspunsul:

În ce tehnologii este construit produsul tău?

Cum în ziua de astăzi există multe tehnologii și kit-uri de dezvoltare, este important să știi care sunt cele corespondente aplicației tale. Pentru o aplicație mobilă, se pot folosi spre exemplu: Java sau Kotlin pentru aplicații native; Flutter, React Native, Ionic Framework pentru aplicații hibride cross-platform. Pentru partea de back-end se pot folosi NodeJS, Laravel/Lumen, Django, ș.a.

Unde îți găzduiești aplicația?

Fiecare companie de găzduire în parte are procedurile ei specifice. De la tehnologii cloud serverless la tehnologii on-premise, este important să știm motivul deciziei.

Aplicația ta folosește integrări cu terți?

Majoritatea aplicațiilor folosesc integrări cu terți cum ar fi Stripe sau Braintree pentru plăți cu cardul, Firebase pentru notificări push, Amazon (AWS) pentru stocare de fișiere. Aplicația ta ce furnizori folosește?

Pentru ce platforme este gândită aplicația?

Este una pentru desktop, web sau una mobilă? Trebuie să funcționeze pe Android sau iOS? Ori ambele? Este nativă, cross-platform (hibridă) sau Aplicație Web Progresivă (PWA).

Cum s-a desfășurat până acum procesul de dezvoltare?

Majoritatea companiilor specializate pe dezvoltarea software folosesc un proces iterativ, bazat pe metodologia Agile. Aici este important de știut cum a fost organizat până acum pentru a evita greșelile furnizorului de la care se face migrarea, dar și pentru a îmbunătăți modul de lucru.

Pregătirea proiectului pentru preluare de către noua echipă

Transferul unui proiect cu bug-uri, probleme și cod scris rapid, fără să fie testat ar reprezenta o problemă pentru noul furnizor, luând timp adițional, ce se reflectă în costuri suplimentare pentru tine. Aplicația ar trebui transferată fără probleme majore sau cod vechi și nedocumentat.

Necesitățile cele mai des întâlnite în preluarea de aplicații sunt:

Specificațiile proiectului, indiferent de stadiul în care sunt lucrările. Acest lucru oferă noii echipe o perspectivă cât mai completă asupra proiectului și asupra procesului de dezvoltare. Ce trebuia să se obțină și ce s-a obținut.
Schița arhitecturii aplicației (descrierea tuturor modulelor și corelațiile acestora).
Documentația dezvoltării include de obicei codul sursă documentat, descrierea algoritmilor cheie și structura bazei de date aplicată, descrierea claselor și a modulelor aplicației, ghiduri de implementare.
Partea de design: schițe, grafică, materiale de marketing. Asigură-te că formatele fișierelor îndeplinesc cerințele noii echipe.
Ghiduri: implementare, configurarea și instalarea sistemului, instrucțiuni de operare, depanare, schimbare de date, sistem de urmărire a erorilor, credențiale de administrator etc.
Fișiere cu pachete de configurare (.txt, .json) care acoperă listele de pachete de instalat înainte de a seta mediul de dezvoltare.
Date de acces la repository-uri, gestiunea sarcinilor, sisteme de urmărire a sarcinilor și management de proiect.

Stabilirea unor proceduri de comun acord influențează modul de desfășurare al noii colaborări. Se va stabili un meeting de stabilire a procedurilor de management în care se vor stabili aspecte precum comunicarea și metodologiile utilizate anterior.
Nu în ultimul rând, se iau în calcul dimensiunea echipei, rolurile lor și uneltele de urmărire a sarcinilor.

Procedura de tranziție va dura ceva timp, iar implicarea ambelor părți este importantă spre a ajunge la rularea proiectului în aceleași condiții în care funcționa la echipa precedentă.

Procesul de predare se referă la transferul atât a unui sistem software, cât și a cunoștințelor, experienței și responsabilităților necesare pentru gestionarea și întreținerea sistemului pe durata ciclului de viață al unui produs. Noua echipă ar trebui să primească informații complete despre proiect pentru a înțelege în mod clar produsul în sine și provocările acestuia. O astfel de cunoaștere completă și o înțelegere perfectă sunt esențiale pentru un parteneriat bazat pe consultanță, responsabilitate și motivație.

Domeniile-cheie care ar trebui discutate:

1. Introducere generală în ideea produsului

Împărtășirea obiectivelor produsului, conceptul modelului de afaceri, valoarea adăugată a produsului, cunoștințele strategice ale utilizatorilor (nevoile, așteptările, pain points), caracteristicile de bază, tipurile de utilizatori, contextul de utilizare al produsului și soluții competitive.

2. Starea proiectului – listă „Terminat”, „În desfășurare” vs. „De făcut”

Inventarierea activității echipei anterioare, în ce etapă de dezvoltare este acum, la ce lucruri nu s-au lucrat; și care este perspectiva viitoare de lucru și prioritățile următoare.

3. Provocări

Inventariază ce provocări ai întâmpinat până acum pe tot parcursul procesului de dezvoltare software; ce a funcționat bine și ce nu; evaluează împreună cu echipa de dezvoltare care sunt obstacolele care pot sta în calea tranziției și dezvoltării ulterioare, precum și modul de prevenire a acestora.

Permiteți noului partener să efectueze o revizuire a codului (code review)

Nimeni nu vrea să își cumpere un cal troian. Acesta este motivul pentru care unul dintre elementele indispensabile în procesul de predare a software-ului este un audit al codului, care este o condiție necesară pentru măsurarea „datoriei tehnice”, precum și pentru evaluarea stării generale de sănătate a aplicației și a capacității noii echipe de a o gestiona.

Aceasta este o analiză de sus-jos a codului sursă care are loc indiferent dacă există o documentație a unei aplicații sau nu. Este natural ca într-un cod de lungă durată să poată exista unele probleme. Cu toate acestea, problema apare atunci când scara și severitatea lor sunt mari. Acest lucru poate face ca implementarea unor noi funcționalități să devină costisitoare și să nu permită o eventuală rescriere (refactorizare) a codului.

Și aici intervine revizuirea codului care favorizează un feedback obiectiv, evaluarea riscurilor și un plan de salvare, dacă este nevoie.

La Brainic testăm aplicația pentru securitatea, performanța și calitatea codului, apoi rezumăm toate problemele, inclusiv descrierea lor, precum și acțiunile de remediere, cu prioritizarea acestora, pentru a vă da un nivel de gravitate. Câteva dintre întrebările adresate în timpul auditului de cod:

Se respectă standardele de codare?
Care este acoperirea unit testului? (Unit testele facilitează dezvoltarea suplimentară și detectarea erorilor)
Codul este sigur și rezistent la breșe de securitate?
Există date sensibile stocate în cod?

Și totuși, s-ar putea să mai apară surprize pe parcurs

O strategie de predare este foarte importantă, dar asta nu înseamnă că lucrurile or să meargă perfect. Mai jos sunt descrise câteva scenarii posibile:

Tranziția în condiții bune este o raritate când vine vorba de preluarea proiectului de la creatorii săi inițiali. Aici, va trebui să joci un rol de mediator între cele două echipe spre a facilita tranziția proiectului cu cât mai puține impedimente. Va dura ceva timp și este posibil să te treacă puțin prin aspectul tehnic al proiectului, dar uneori poate fi singura soluție. S-ar putea și ca o mică remunerație să ajute uneori ca echipa inițială să se implice mai activ la predare.
Este posibil ca în sistemele foștilor colaboratori să fi rămas copii ale proiectului și informații confidențiale. Aici un NDA mai strașnic cu aceștia îți pot păstra o minimă siguranță a datelor și informațiilor confidențiale.
Întreruperea dezvoltării produsului ar putea fi rezultatul unei echipe de dezvoltare descurajate care lasă resurse de dezvoltare insuficiente pentru un proiect după ce ai anunțat tranziția sa. Singurul lucru care se poate face este să grăbești tranziția pentru a reduce la minimum impactul asupra produsului. Recompensa financiară pentru cooperare ar trebui să contribuie și la această problemă.

Începe totul cu un nou contract pe oră – T&M (Time & Materials)

Începe cu elementele de bază ale tranziției serviciilor IT. Pentru a găsi un partener tehnologic mai bun, tu și potențialul contractant ar trebui să vă aflați pe aceeași pagină în legătură cu planurile și așteptările dvs. Oricum l-ai numi – fie un plan strategic sau o schimbare de curs – ar trebui să definești toate etapele proiectului și funcționalitatea de bază într-un contract orar.

Atenția acordată detaliilor afișate în timpul negocierii indică direct proporțional calitatea serviciilor prestate. Confirmă dacă pozițiile tale financiare coincid și fixează-le în contract. Stabiliți canale de comunicare eficiente privind diferențele de fus orar, limbajul, instrumentele de comunicare și o persoană de contact responsabilă.

Asemenea aspecte de actualitate precum proprietatea intelectuală trebuie, de asemenea, discutate în stadiul contractului pentru a evita eventualele neclarități ulterioare. De regulă, produsele software dezvoltate de terți sunt considerate lucrări pentru închiriere și, astfel, proprietatea intelectuală aparține exclusiv proprietarului produsului. Cu toate acestea, acest punct ar trebui specificat explicit într-un contract.

De îndată ce aceste aspecte se finalizează, poți începe să pregătești terenul pentru transmiterea proiectului.

Ai un proiect de aplicație mobilă pe care ai vrea să îl muți de la actualul furnizor? În plus te regăsești în metodologia Brainic, iar aceasta sună natural și firesc pentru tine?