Pentru sisteme
care există deja.
Indiferent cine le-a făcut. Cele mai multe firme nu au nevoie de un sistem nou, ci de un răspuns limpede la întrebarea ce se strică prima dată în cel pe care îl au — și cât costă să nu se strice.
02 — Ce construim
O părere din afară, sau cineva care să ducă lucrarea mai departe.
De la o evaluare de două săptămâni până la întreținerea continuă a unui sistem aflat în producție.
- Analiză de arhitectură
- O evaluare scrisă a sistemului: ce cedează primul, de ce, ce costă prevenirea și în ce ordine merită făcută. Documentul rămâne al vostru și poate fi dat oricui, inclusiv altei firme.
- A doua opinie
- Ați primit o ofertă de rescriere sau un plan tehnic și nu aveți cu cine să-l verificați. Îl citim și spunem dacă se justifică, ce lipsește din el și ce întrebări merită puse înainte de semnătură.
- Modernizarea sistemelor vechi
- Un drum etapizat de ieșire dintr-un sistem îmbătrânit, în care fiecare etapă lasă firma funcțională. Bucată cu bucată, nu oprire de trei luni și o lansare în care speră toată lumea.
- Mentenanță
- Lucru continuu pe un sistem aflat în funcțiune: actualizări de securitate, reparații, schimbări mici, cu timp de răspuns stabilit și raportare lunară.
- Preluarea unui sistem rămas fără echipă
- Când oamenii care l-au construit nu mai sunt. Se începe cu punerea lui în funcțiune de la zero pe o mașină nouă — proba cea mai sinceră a stării în care se află — și cu documentația care lipsește.
Cu ce lucrămAnaliză · modernizare etapizată · mentenanță · preluare · a doua opinie
03 — Când are sens
Semnele că aici e problema.
- Singurul om care înțelegea sistemul a plecat din firmă.
- Fiecare modificare mică sparge altceva, așa că se modifică tot mai rar.
- Ați primit o ofertă de rescriere de la zero și nu aveți cum să judecați dacă e justificată.
- Sistemul funcționează, dar rulează pe versiuni pe care nu le mai actualizează nimeni.
- Nimeni nu poate spune cu certitudine ce se întâmplă dacă serverul acela cedează mâine.
04 — Cum lucrăm
Cum arată lucrarea, concret.
Rezultatul e un document, nu o ședință
Dintr-o analiză rămâneți cu un text scris, cu constatări și cu ordinea în care merită atacate. Se poate citi de conducere, de contabilitate și de următoarea echipă tehnică, fără să fi fost cineva în discuție.
Înlocuire pe bucăți, nu rescriere totală
Sistemul vechi rămâne în funcțiune, iar părțile trec pe rând la cel nou, în spatele aceleiași interfețe. E mai lent pe hârtie și mult mai sigur în realitate: se poate opri oricând, fără să se piardă tot.
Spunem și când nu e nimic de făcut
Uneori concluzia e că sistemul e în regulă și că problema stă în altă parte — într-un proces, nu în cod. O spunem, chiar dacă asta încheie discuția despre un proiect mare.
Fără nume de clienți, în nicio direcție
Ce aflăm despre sistemele voastre rămâne la noi, iar ce am aflat despre ale altora nu ajunge la voi. De aceea nu veți găsi studii de caz cu nume pe site-ul acesta.
05 — Întrebări frecvente
Ce ne întreabă lumea despre partea asta.
Ce conține o analiză de arhitectură?
Un document scris: cum e construit sistemul astăzi, ce riscuri are și în ce ordine se rezolvă, cu o estimare pentru fiecare. Se citește codul, baza de date și felul în care se publică, și se discută cu oamenii care îl folosesc zilnic — de acolo ies de obicei cele mai clare constatări.
Recomandați rescrierea de la zero?
Rar, și niciodată ca primă variantă. O rescriere completă înseamnă luni în care firma plătește pentru ceva ce are deja, plus riscul ca sistemul nou să nu acopere situații pe care cel vechi le trata de ani de zile, fără să le fi scris nimeni undeva. Aproape întotdeauna e mai bine să se înlocuiască pe bucăți.
Puteți lucra alături de echipa noastră internă?
Da, și e situația cea mai frecventă la lucrările de modernizare. Echipa internă cunoaște domeniul și istoria deciziilor, noi aducem timpul și partea tehnică pe care nu o acoperă. Scopul e ca la final echipa să poată continua singură, nu să depindă de noi.
Preluați mentenanța unui sistem pe care nu l-ați construit voi?
Da. Începem printr-o etapă de preluare: punerea sistemului în funcțiune de la zero, scrierea documentației care lipsește și o listă a riscurilor imediate. Abia după aceea începe mentenanța propriu-zisă, ca să nu promitem un timp de răspuns pentru un sistem pe care încă nu îl cunoaștem.
06 — Celelalte capabilități
Rareori vine una singură.
Cele patru se sprijină una pe alta: o aplicație are nevoie de un backend, backend-ul de un loc în care să ruleze, iar ce rulează deja de cineva care să îl țină în funcțiune. Luăm tot lanțul sau doar veriga care lipsește.
07 — Pasul următor
Aveți un sistem
de care nu mai e sigur nimeni?
Îl citim și vă spunem în scris cum stă — inclusiv dacă răspunsul e că nu trebuie atins.