Susținut de Doctor SEO- din 2018 pe piața de SEO din România
Aproape toate proiectele care ies scump au aceeași poveste: s-a pornit de la o listă de funcționalități, s-a construit câteva luni, iar la prima folosire reală s-a văzut că fluxul nu funcționează. Discovery-ul mută descoperirea asta cu trei luni mai devreme, când costă o gumă de șters.
E singura etapă care se plătește și când te face să spui nu. Dacă la final concluzia e că nu ai nevoie de proiect, ai plătit câteva zile de analiză în loc de câteva luni de dezvoltare.
Prototip, cu observațiile pe el
săptămâna doiaici pierdem jumătate din oameni
pasul ăsta poate să dispară
e nevoie de un ecran, nu de trei
Observațiile astea costă o gumă de șters acum. După ce s-a construit, costă o lună de refăcut - și de obicei nu se mai reface, se trăiește cu ele.
Nu e timp de gândit, e timp de vorbit și de desenat. Dacă cineva îți propune discovery de trei luni, întreabă-l ce livrează în fiecare săptămână.
Documentul trebuie să funcționeze și fără noi. Ăsta e testul lui: dacă nu poate fi dus la altă firmă și folosit ca să ceri o ofertă, înseamnă că e o broșură de vânzare, nu un rezultat.
De ce se plătește o etapă fără cod, cât durează, ce primești la final și ce se întâmplă dacă răspunsul e nu.
Ai o întrebare care nu e aici? Sună la 0756 823 823
Pentru că partea scumpă a unui proiect nu e scrisul, e rescrisul. Discovery-ul costă o fracțiune dintr-un proiect și, în cel mai prost caz, îți arată că nu ai nevoie de el. În cel mai bun, elimină lunile în care se construiește ceva ce nimeni nu folosește. E singura etapă care se plătește și când te face să spui nu.
Între două și patru săptămâni pentru majoritatea proiectelor. Nu e timp de gândire, e timp de vorbit cu oamenii care fac treaba, de desenat fluxurile așa cum sunt și de testat un prototip pe câțiva utilizatori reali. Dacă cineva îți propune discovery de trei luni, întreabă ce livrează în fiecare săptămână.
Fluxurile desenate, un prototip pe care se poate da click, lista de funcționalități împărțită pe etape, riscurile identificate și o estimare de buget pe fiecare etapă. Documentul e scris ca să poți cere oferte cu el de la orice firmă, nu doar de la noi. Asta e și testul lui: dacă nu poate fi folosit în altă parte, nu e bun.
Depinde ce conține. Dacă e o listă de funcționalități, aproape sigur da - pentru că lista spune ce vrei, nu de ce, și fără de ce nu se poate prioritiza nimic. Dacă are fluxurile, deciziile și motivele în ea, ne uităm peste el și trecem direct la construit. Nu refacem muncă bine făcută.
Oamenii care fac treaba zilnic, nu doar cei care semnează. Cea mai utilă oră de discovery e cu omul din depozit sau cu cel de la telefon, pentru că el știe unde se împotmolește procesul. Din partea conducerii avem nevoie de o discuție despre obiective și de o decizie la final, nu de prezență la fiecare ședință.
Amândouă, dar în ordinea asta. Întâi structura și fluxurile, testate pe un prototip simplu - acolo se rezolvă problemele care costă. Abia apoi designul propriu-zis, care se face repede când structura e deja validată. Invers se lucrează des și iese scump: se aprobă niște ecrane frumoase și abia la construit se descoperă că fluxul nu funcționează.
Ne oprim, și e un rezultat bun. Am ajuns de câteva ori la concluzia că problema se rezolva cu o schimbare de proces și un instrument existent, nu cu software nou. Clientul a plătit câteva zile de analiză în loc de câteva luni de dezvoltare. Discovery-ul nu e un preambul obligatoriu la un contract mare.
Nu e un formular de contact. Sunt exact lucrurile care schimbă o estimare - restul se discută la telefon, nu se completează în căsuțe.