Elaborez o aplicatie web pentru un client, scriu documentatie cum sa o folosesti si sa o administrezi si peste ceva timp clientul imi trimite mesaj ca un modul nu functioneaza. Eu incerc sa-mi aduc aminte ce features i-am facut si cum functioneaza totul, pierd ~ 1-3 ore pana dau de capat si inteleg ca doar a fost o eroare umana din partea lor. Nu a citit atent documentatia.
Eu vad o problema aici. Dau la o parte proiectele la care lucrez, analizez problema fostului client si inteleg ca aici nu este o problema tehnica ci o neatentie din partea lor. Deci dupa cum intelegeti sunt in pierdere. Acesti clienti nici macar nu doresc sa achite un abonament lunar pentru mentenanta pe care l-am propus.
Voi cum procedati in asa cazuri? Taxati pentru orele pierdute in zadar pentru ca cineva nu a fost atent? Deserviti clientii ca sa va arati ca sunteti buni cu speranta ca te va recomanda altor potentiali clienti?
nu e chiar o regula universala (adica depinde de client, de contract, etc),
dar ar trebui sa consideri macar urmatoarele aspecte:
cum se raporteaza un bug (ex: in scis intr-un anume loc, cu descriere a contextului, a modului in care s-a ajuns la el, eventual capturi de ecran, video, etc) - asta ajuta la identificare rapida.
ce fel de garantie oferi si pt cat timp (cat timp te angajezi sa repari buguri? - probleme pot sa apara si peste x ani cand o parte dintre tehnologii / librarii / os / versiuni de orice nu or sa mai fie intretinute sau compatibile cu ce ai scris acolo - nu prea poti oferi lifetime warranty pt software
ce fel de buguri acoperi (care afecteaza functionalitatea pricipala, care afecteaza aspectul, etc) si in ce mod (ex: timp de raspuns, timp de rezolvare, etc)
ce se intampla daca se raporteaza eronat (eventual clientul plateste sau daca refuza pierde garantia)
cum s-a facut testarea (daca a testat real si daca a semnat pt asta) si predarea
astea sunt niste costuri pe care ar trebui sa le consideri la evaluarea initiala (pentru a evita pierderi) si modul in care le gestionezi / negociezi depinde si de tine si de client / proiect.
important e sa fie clar pt toata lumea de la inceput cum se intampla lucrurile astea
pentru ca asteptarile diferite si lipsa de cmunicare sunt cauze semnificative de esec
Dezvoltarea de software nu e one man job si nu vei rezista mult daca faci asta.
Documentatia e degeaba (adica e util pentru tine), n-ai facut aplicatia bine. Oamenii mereu gasesc moduri de a abuza in cel mai creativ mod ceva ce ai facut si dupa se mira de ce nu merge ceva.
poate nu esti in target.
repet, daca prin documentatie intelegem manual de utilizare… te contrazic.
am suficient de multi clienti care citest, foloses si apreciaza manualul (inca de pe vremea cand il faceam cu capturi de ecran in pdf sau video captura de ecran in timp ce “povestesc” liber cum se fac anumite chestii).
pana la urma vb de operatori care fac asta pt job si e important sa nu greseasca datele din aplicatie sau sa nu genereze costuri suplimentare pentru angajatorul lor prin raportarea de buguri inexistente.
daca mai adaugi si o sesiune de training la livrare… lucrurile chiar merg bine apoi
Daca iti trebuie manual sa folosesti aplicatia, ceva e in neregula
Depinde mult daca e un client care o sa-ti mai dea de lucru, daca ai avut recomandari de la el, etc. Eu cu mai toti clientii am avut o relatie de prietenie sa zic. (Inafara de ala de la Travelplanner). Caz in care meritau orele alea pierdute.
E de datoria celui care a cerut aplicatia sa si-o documenteze si sa isi faca un proces de training, un video de prezentare, tu o sa il faci mereu din perspectiva ta, iar tu nu esti utilizatorul si nici nu iti trece prin cap la ce se gandeste angajatul cand vede aplicatia ta.
E de datoria clientului sa isi foloseasca aplicatia corect, ceea ce poti face tu si ce am mai facut e sa adaugi feature-uri antiprost contra-cost si sa le vinzi cu ocazia asta destul de scump.
Am vazut situatii in care dintr-un feature din asta anti-prost s-a rescris toata aplicatia de la 0 pe bani frumosi.
mie mi se pare ca e datoria producatorului sa ii faca si manualul de utilizare (evident, contra cost).
in practica, depinde de negociere / buget / contract.
pai esti developerul si ar trebui sa prevezi ce ii trece prin cap
asta da, dar tot trebuie sa plece de la cum prezinti tu aplicatia pe care o livrezi
Total gresit. Orice lucru procurat vine cu un manual de utilizare.
Clientul va face training angajatilor dupa ce primeste manualul de utilizare.
Pune-te in locul clientului (un om de afaceri care nu prea are treaba cu IT), comanzi o aplicatie, iti este livrata si apoi nu prea intelegi cum functioneaza lucrurile.
Aici e problema, intre omul de afaceri si aplicatie trebuie obligatoriu sa existe un product owner altfel o sa dai de atatia oameni batuti la cap incat ajungi sa intrebi ce sa faci ca sa nu te mai intrebe gratis cum sa isi foloseasca aplicatia. (bine nu garanteaza nimic nici ca product ownerului aluia ii pasa de afacerist)
La o companie mica manualul ala de utilizare e pentru tine nu pentru ei, daca nu vrei sa fii deranjat fa-ti un contract cu costuri de mentenanta si suport la ora din care rezolvi gratuit defectele reale. (o perioada desigur)
Se uita la manual si dupa putin timp o sa te sune sa vada care-i solutia daca pot.
Eventual exista solutii moderne precum un chat bot, iti faci ceva canal prin care trimiti la documentatie dupa cuvinte cheie.
