Când îi spunem clientului că nu are nevoie de o aplicație custom

Ne sună o firmă care vrea „o aplicație internă”. De obicei descrierea începe cu un instrument existent care nu mai face față: un fișier de calcul cu douăzeci de foi, un grup de WhatsApp folosit ca sistem de comenzi, sau un program vechi la care nu mai există suport.

Prima noastră treabă nu e să estimăm. E să înțelegem dacă un produs de pe piață rezolvă problema mai repede și mai ieftin.

Ce ne face să recomandăm un instrument existent

Dacă procesul firmei arată la fel ca la sute de alte firme — facturare, programări simple, evidență de stoc standard — un abonament la un produs matur bate aproape sigur o aplicație scrisă de la zero. Nu doar la preț, ci la ce se întâmplă în anul doi: cine repară, cine adaugă, cine e disponibil când persoana care a scris codul nu mai lucrează cu tine.

Am pierdut proiecte fiind sinceri aici. E în regulă. Alternativa e să livrăm ceva care devine o povară.

Ce ne face să spunem da

Custom are sens când în proces există o regulă pe care niciun produs de pe piață nu o are. Un client care lucra cu comenzi pe bază de croială avea un mod propriu de a calcula consumul de material, cu excepții pe fiecare furnizor. Excelul lui funcționa, dar doar el îl înțelegea, iar firma nu putea crește peste el.

Al doilea caz: integrarea. Când datele trebuie să circule între două sisteme care nu vorbesc între ele și cineva le copiază manual zilnic, munca de integrare se plătește singură.

Cum pornim, ca să nu construim degeaba

Nu începem cu tot. Începem cu partea unde se pierde cel mai mult timp, o livrăm și o punem în folosință reală câteva săptămâni. Abia apoi decidem restul, cu ce am învățat din felul în care oamenii o folosesc efectiv.

Am făcut și greșeala inversă. La un proiect am acceptat o listă lungă de funcții stabilită în avans, pe care nimeni nu a mai folosit-o după livrare. Am refăcut o parte pe cheltuiala noastră. De atunci insistăm pe livrări mici, chiar când clientul preferă o singură predare mare.

Ce nu putem promite

Nu putem estima exact un proiect în care regulile nu sunt încă scrise nicăieri. Dăm interval, spunem ce l-ar face să crească și ținem clientul la curent săptămânal. Când cineva îți dă o cifră fixă pentru un proces pe care nu l-a văzut, cifra aceea are o marjă ascunsă înăuntru.

Dacă ai un proces care ține de o singură persoană sau de un fișier care nu mai face față, hai să ne uităm la el înainte să vorbim de buget.

Instrument existent sau aplicație pe măsură

Discuția asta o purtăm aproape la fiecare cerere de „aplicație internă”. Nu are un răspuns universal, dar are criterii.

Cum arată prima etapă, când zicem da

Nu începem cu design și nici cu baza de date. Începem cu o hartă a pașilor pe care îi face un om din firmă într-o zi obișnuită, scrisă împreună cu el, nu cu managerul. De acolo iese, aproape mereu, un pas care poate dispărea complet.

Cel mai util rezultat al unei ședințe de analiză e când clientul spune „stai, dar de ce facem asta?”. Am ieșit de câteva ori din ședință cu un proiect mai mic decât cel cerut.

Ce costă mai mult decât crede lumea

Nu partea vizibilă. Cazurile de excepție: ce se întâmplă când cineva anulează, când o comandă vine parțial, când doi oameni modifică același lucru în același timp. Astea consumă timpul, iar dacă le lăsăm pe final, aplicația pare gata și nu e.

Ce nu putem promite

Am și dat sfaturi greșite aici: la un client am recomandat un instrument existent care s-a dovedit prea rigid pentru procesul lui, iar după trei luni am refăcut partea aia pe măsură. Depinde mult de cât de bine cunoști procesul înainte, iar noi nu îl cunoaștem niciodată complet din prima ședință.

Nu putem spune de la început prețul final pentru un proiect pe care nu l-am descris complet, și nu promitem un termen fix înainte de analiză. Dacă cineva îți dă ambele lucruri într-un e-mail, fie a mai făcut exact același proiect, fie nu le va respecta.

Dacă ai un proces care te încurcă zilnic, hai să îl descriem împreună. Uneori concluzia e că nu ai nevoie de noi pentru el.