Kaip dirbame kartu: skaidrus web projektų valdymas nuo idėjos iki paleidimo

Viena dažniausių problemų dirbant su web kūrimo komandomis – projektas tampa juoda dėže. Klientas nemato, kas vyksta viduje, negauna atnaujinimų, o galutinis rezultatas kartais neatitinka lūkesčių. Sweetnet dirba kitaip. Šiame straipsnyje atidarome savo proceso 'gaubtą' ir parodome, kaip atrodo bendradarbiavimas iš vidaus.

Projekto pradžia: susitikimas, kuriame iš tikrųjų klausome

Kiekvienas projektas prasideda nuo atramininio susitikimo – kick-off call. Tai ne formalumas. Tai struktūruotas pokalbis, kuriame išsiaiškiname ne tik tai, ko klientas nori, bet ir kodėl jis to nori, kam tai skirta ir kaip atrodys sėkmė.

• ✓Verslo tikslai – ką svetainė ar sistema turi pasiekti per 6–12 mėnesių?
• ✓Tikslinė auditorija – kas naudos produktą, kokie jų poreikiai ir skausmo taškai?
• ✓Techniniai reikalavimai – integracijos, platformos, našumo lūkesčiai
• ✓Dizaino kryptis – brendingas, tone of voice, vizualinės nuorodos
• ✓Sėkmės kriterijai – konkreti metrika, pagal kurią vertinsime rezultatą
• ✓Terminai ir prioritetai – kas privalo būti pirma, kas gali palaukti

Po kick-off susitikimo klientas per 48 valandas gauna projekto santrauką el. paštu – ką aptarėme, ką supratome, kokie kiti žingsniai. Tai eliminuoja nesusipratimus nuo pat pradžių.

📋 Notion: vienas tiesos šaltinis visam projektui

Kiekvienam klientui sukuriame atskirą Notion darbo erdvę – bendrą talpyklą, kurioje gyvena visas projektas. Čia klientas bet kuriuo metu gali pamatyti projekto būklę, užduočių sąrašą, dokumentaciją ir sprendimų istoriją.

• ✓Projekto roadmap – vizualus planas su terminais ir etapais
• ✓Reikalavimų dokumentas – kas buvo aptarta ir sutarta, su versijų istorija
• ✓Dizaino sprendimai – kodėl pasirinkome vieną ar kitą variantą
• ✓Testavimo protokolai – kas testuota, kokiais įrenginiais, kokie rezultatai
• ✓Paleidimo kontrolinis sąrašas – kiekvienas žingsnis prieš go-live
• ✓Atsakymų į DUK bazė – dažniausi klausimai ir atsakymai

Notion naudojame ir kaip meeting notes saugyklą – po kiekvieno susitikimo užrašai su sprendimais ir veiksmų punktais pasiekiami toje pačioje erdvėje. Niekas nepasimeta el. laiškų siūluose.

✅ Asana: kiekviena užduotis turi savininką ir terminą

Projektų valdymui naudojame Asana – įrankį, kuriame kiekviena užduotis yra konkreti, priskirta konkrečiam žmogui ir turi konkretų terminą. Jokių 'apytiksliai', jokių 'kai suspėsime'.

• ✓Board view – kanban stiliaus lenta: Backlog → In Progress → Review → Done
• ✓Timeline view – Gantt diagrama viso projekto terminams matyti
• ✓Priklausomybės – užduotis B negali prasidėti, kol nebaigta užduotis A
• ✓Automatiški priminimai – komanda gauna pranešimus prieš terminus
• ✓Klientų prieiga – klientas gali matyti užduočių statusus ir komentuoti
• ✓Integracijos su Slack ir GitHub – automatiški atnaujinimai be rankinio darbo

Alternatyvos Asana: Linear (labiau orientuotas į inžinerines komandas, greitas ir šiuolaikiškas), Jira (geriau didelėms komandoms su sudėtingais procesais), ClickUp (visko viename sprendimas su daugiau lankstumo). Mes pirmenybę teikiame Asana dėl aiškumo ir paprastumo klientams.

🔀 GitHub: kodo bendradarbiavimas su pilna istorija

Visas kodas gyvena GitHub privačioje repozitorijoje. Tai ne tik saugykla – tai bendradarbiavimo platforma, kurioje kiekvienas pakeitimas yra dokumentuotas, peržiūrėtas ir atsekamas.

• ✓Feature branches – kiekviena nauja funkcija kuriama atskiroje šakoje, ne tiesiai main
• ✓Pull request peržiūros – prieš suliejant kodą, kitas kūrėjas peržiūri ir aprobuoja
• ✓Automatinis testavimas – CI/CD pipeline paleidžia testus kiekvienam PR automatiškai
• ✓Commit pranešimai – kiekvienas commit aprašo, ką ir kodėl pakeitė
• ✓GitHub Issues – klaidos ir patobulinimų prašymai sekami toje pačioje vietoje
• ✓GitHub Actions – automatinis deploy į staging arba produkciją po patvirtinto PR

Klientas gali gauti prieigą prie repozitorijos ir matyti realų kūrimo procesą – kiek commit'ų per dieną, kokie pakeitimai, kokia kodo kokybė. Tai tikras skaidrumas, ne tik žodžiai.

💬 Komunikacija: reguliari, struktūruota, greita

Kommunikacija yra projekto stuburas. Mūsų komunikacijos ritmas atrodo taip:

• ✓Savaitinis statusų susitikimas (30 min) – kas padaryta, kas vyksta, kas blokuoja
• ✓Etapų peržiūros (sprint review) – demonstracija to, kas sukurta per paskutines 2 savaites
• ✓Slack kanalas – greiti klausimai ir atsakymai per darbo valandas (atsakome per 2–4 val.)
• ✓El. paštas – oficiali komunikacija, sprendimai ir susitarimai
• ✓Loom vaizdo įrašai – kai lengviau parodyti nei aprašyti tekstu
• ✓Figma komentarai – dizaino peržiūros tiesiai ant maketo, ne el. laiškais

🔀 Kodo peržiūros: kokybė užtikrinama prieš produkciją

Kiekvienas kodo pakeitimas praeina per peržiūros procesą. Tai ne biurokratija – tai draudimas nuo klaidų, kurios kainuoja brangiau ištaisyti vėliau.

• ✓Automatiniai testai – unit testai, integracijos testai, end-to-end testai
• ✓Kodo kokybės tikrinimas – ESLint, Prettier, TypeScript tikrinimas
• ✓Saugumo skenavimas – automatinis pažeidžiamumų ieškojimas priklausomybėse
• ✓Našumo testai – Lighthouse balas tikrinamas kiekvienam naujam deploy
• ✓Rankinis kodo review – kitas kūrėjas peržiūri logiką ir architektūrą
• ✓Staging aplinka – klientas patvirtina prieš įdiegiant į produkciją

🔔 Pranešimai realiuoju laiku: žinote viską svarbų

Klientas gauna automatinį pranešimą kiekvienam svarbiam projekto įvykiui – nereikia klausti, kas vyksta.

• ✓Naujas deploy į staging – 'Jūsų nauja funkcija paruošta peržiūrai – [nuoroda]'
• ✓Sėkmingas paleidimas į produkciją – su pakeitimų santrauka
• ✓Kritinė klaida sistemoje – nedelsiant, su veiksmų planu
• ✓Artėjantis terminas – priminimas prieš 48 valandas
• ✓Savaitinė ataskaita – kas padaryta, kas planuojama kitą savaitę

Kaip atrodo tipiškas projekto etapas (sprintas)?

Dirbame dviejų savaičių sprintais – tai reiškia, kad kas dvi savaites klientas gauna veikiančią, demonstruojamą produkto dalį. Tai ne dokumentai, ne mockupai – realus kodas, kurį galima liesti.

1. 1Sprint planavimas (pirmadienį) – aptariame, ką darysime per dvi savaites, visos užduotys į Asana
2. 2Kasdieninė komandos sinchronizacija (15 min) – kas dirba ties kuo, ar kas nors blokuoja
3. 3Vidurio sprint check-in su klientu – greitas statusas, ar einame tinkama kryptimi
4. 4Kodo peržiūros – vyksta nuolatos per sprintą
5. 5Sprint review (paskutinį penktadienį) – demonstracija klientui, grįžtamasis ryšys
6. 6Retrospektyva – komanda aptaria, kas veikė gerai ir kas turėtų keistis

Projekto pabaiga: perdavimas, kurį suprantate

Baigus projektą, klientas gauna ne tik veikiančią svetainę. Jis gauna visą reikalingą informaciją, kad galėtų savarankiškai valdyti savo produktą arba dirbti su bet kuria kita komanda ateityje.

• ✓Pilna techninė dokumentacija – architektūra, API aprašymas, aplinkos kintamieji
• ✓Administratoriaus vadovas – kaip atnaujinti turinį, pridėti produktus, keisti nustatymus
• ✓Prieigos perdavimas – domenai, hostingas, el. paštas, analitika – viskas perduodama klientui
• ✓Garantinis palaikymo periodas – 30 dienų klaidų taisymas po paleidimo be papildomo mokesčio
• ✓Mokymų sesija – vaizdo skambutis, kuriame parodome, kaip naudotis sistema