Trebuie sa sari de un anumit nivel ca sa ai clienti care platesc manuale de utilizare. Pun pariu ca l-ai facut pe timpul tau, sau l-ai inclus in quote fara sa il itemizezi separat.
Felicitari daca ai ajuns la aplicatii atat de complexe de sa nu poata fi folosite fara manual. Nu cred ca am citit vreodata manualul la vreo aplicatie.
PS: imi cer scuze pentru offtopic, n-are treaba cu ce ai intrebat tu.
Cel mai fair le poti spune “ma uit, dar daca depaseste jumate de ora va facturez timpul, ii dau drumul?”
As pute sa-l numesc un bonus pentru client. Dar cred ca voi revizuii acest subiect.
Te cred, developerii au intuitie dar crede-ma, am avut clienti care nu prea stiu sa foloseasca calculatorul, dar sa mai cunoasca cum sa foloseasca aplicatia fara un manual )
Imi cer si eu scuze daca crezi ca am facut off-topic, m-am legat de manual fiindca l-ai mentionat ca motivul pentru care s-a nascut un defect pe care trebuia sa il investighezi.
Filozofia mea e sa ajut mereu pe cineva daca pot ajuta fara sa ma impacteze pe mine. Ma cunosc foarte bine si daca cineva imi cere ajutorul frecvent si nu da nimic o sa ajung chiar si in subconstiinta sa il pun deoparte, sa il ajut doar cand deja e inevitabil, sa ma sustrag cumva. Cred ca e valabil cam la toti, daca nu iti impui sa ceri ceva pentru efortul tau o sa ii tot pui deoparte cand iti mai cer ajutorul pana cand o sa fie dureros pentru toti.
uite un scenariu nu chiar imposibil:
site banal de prezentare care se actualizeaza o data la an de catre client.
masura banala de securitate - schimbare url login.
gazduire la furnizor, fara acces in cpanel.
la predare se face training, totul ok.
dupa un an… trebuie update si taskul pica in spatele noului coleg care abia a aterizat acolo (deci nu are nici amintiri si nici notite de la training).
fara manual… cum incepe?
nu e mai simplu sa inregistrezi in juma de ora cateva lucruri cu microfon si captura de ecran si sa ii spui “manual de utilizare” si toata lumea e fericita?
Am inteles, dar care sunt pasii care sunt asa importanti incat merita documentati ? Poate initial cui i-ai facut pagina are 10 site-uri in wordpress, eu rational ma gandesc ca nu ma intereseaza ce va fi peste un an daca nu se cere explicit ceva sa fie actualizabil de alt utilizator, peste un an uita omul unde si-a salvat documentatia, uita parola si tot la mine apeleaza.
Daca clientul cere documentatie, normal ca ii dam o documentatie generala. Dar e imposibil sa acoperi totul si pui atentie pe cum ai face tu lucrurile (in special cand n-ai feature-uri definite cu utilizatorul/designerul), dar nu inseamna ca ceva nu se poate face si altfel si tu sa ai un bug care nu era cerinta/functionalitate in acel caz.
Există operații pe care nu le faci constant și este posibil să existe anumite quirks sau edge-case-uri pe care nu le poți include în UI. Un exemplu este nota din screenshot-ul de mai sus.
Treaba cu „dacă ai nevoie de help e clar că e UI prost” este o memă luată în serios de prea mulți.
Uite un exemplu de care m-am lovit chiar azi: este o funcționalitate într-un sistem care nu este documentată. Nicăieri. A trebuit să sap în cod să văd că poți folosi un webhook pe un anumit endpoint, cu anumiți parametri șamd.
Tot ce vroiam sa zic e ca faptul ca utilizatorul n-a citit documentatia nu e exceptia, e probabil regula si ca trebuie identificat ce se poate face ca din UI aplicatia sa fie utilizata corect (chiar contra cost) sau implementat ceva suport platit. Daca e o aplicatie pentru un utilizator avansat documentatia probabil ca nu va include totul ca e greu de scris documentatie buna, iar daca include totul stii cine il si citeste, la companii mari ai 1-2 oameni care iti verifica fiecare cuvant scris si se sta zile pana gaseste cuvantul potrivit ca sa nu induca utilizatorul in eroare.
In utimele randuri la subiect, se intelege ca clientii/utilizatorii nu vor sa plateasca pentru mentenanta. Solutia simpla e ca depanarea costa mult mai mult fara mentenanta si e gratuita doar daca se identifica un defect care nu a aparut dintr-un mod de utilizare diferit de cel original.
Este utila e mereu cu asterisk, documentatia te poate induce in eroare, cateodata grav daca nu e actualizata. (le umpleam frigiderul zilnic la cei de la Google cat lucram la Google Sheets, aveau documentatie cat incape, trebuia sa filtrezi ce mai era in vigoare si ce nu) In special la ceva ce e in dezvoltare continua. E mai bine ca nimic, dar cel mai bine e sa iti arate cineva ce si cum trebuie sa fie facut.
La standarde, daca vine vorba de programare si documentatie, aproape toate standardele mai complexe si usor profitabile au intentionat erori/lipsuri. E.g. formate video/3D etc. ca sa nu le poti implementa bine asa usor fara consultanta.
inteleg ca avem pareri diferite pe subiectul asta si sunt de acord ca e normal sa fie asa (unanimitatea nu prea e naturala).
totusi,
eu si cand construiam cate un site de prezentare aveam cateva notite / plan despre ce urmeaza sa implementez.
deci ma gandesc ca ai ceva de genul… o diagrama de entitati, o harta de pagini, un workflow, roluri pentru utilizatori, etc.
daca ai un admin si un editor ca roluri din partea clientuilui… incepi de acolo.
te uiti in workflow pt ele si de acolo scoti actiunile pe care le pot face in sistem.
si apoi le faci efectiv si inregistrezi: unde si cum se autentifica un editor, unde, ce si cum modifica diferitele lucruri pe care le are de modificat, unde si cum isi reseteaza parola, etc.
apoi repeti pentru admin care probabil in plus poate adauga, modifica si elimina editori, poate trimite mesaje / notificari / newsletter, etc…
ocazie cu care iti pregatesti si trainigul de predare (in care faci acelasi lucru + raspuns la intrebari).
ma gandesc ca daca a fost buget pentru implementat lucrurile alea… cat sa mai fie necesar in plus pentru a le face o proba inregistrata?
da, daca vorbim de manual formal cu jurist si analiza de riscuri si liabilities ne ducem in alte costuri (dar si la alti clienti).
reset password as an app feature?
in concluzie si incheiere (subtopicului cu manualul)
eu recomand un minim manual de utilizare pentru a elimina din acele ore de support nedorit (nici de client pt ca nu vrea sa il plateasca si nici de furnizor pt ca sunt costuri pe care nu le recupereaza).
nu e singurul sau principalul punct in rezolvarea problemei expuse, dar sunt suficient de convins ca ajuta mult.
evident, pentru clientii care doresc si platesc… se pot propune abonamente diverse care sa acopere costurile astea.
Eu incerc sa explic ca documentatia pe care o faci tu in acest fel nu e documentatie pentru utilizator, ai crede ca e, dar sunt detalii importante care conteaza pentru utilizator, dar nu si pentru tine. Nu e ok sa te gandesti ca nu le mai oferi suport fiindca ai pus ceva in documentatie. Exceptie cand faci ceva pentru alti programatori, dar nu ceva cu utilizatori care sunt diferiti si de client.
La o aplicatie de contabilitate/stocuri/facturare etc. e si mai complicat, fara un canal direct/un forum e mort clientul.
nici nu am spus asta.
doar ca nu il pot oferi gratuit.
si pentru ca imi doresc clienti multumiti (sau macar sa nu fie furiosi pe mine)… le dau macar o referinta despre cum sa il foloseasca (mai ales cand nu doresc sa plateasca support).
in experienta mea… tipul asta de manual a ajutat / salvat mult.
e perfect? sigur ca nu.
e mai bun decat nimic? sigur ca da.
ajuta in problema expusa aici? eu chiar cred ca da.
Am lucrat la un proiect in care eu faceam web + back end, iar in urma mea venea o echipa pentru mobil. Daca nu scriam documentatia trebuia sa stau cu ei pe cap sa faca si ei ce faceam eu pe web.
In plus, chiar imi placea. Ma scotea din rutina sau prevenea progresul fata de dezvoltarea pentru mobil.
