Custom CMS checklista: 25 zahteva pre slanja development ponude

Pre slanja upita za custom CMS development, najvažnije je da definišete šta sistem treba da omogući, ko će ga koristiti i sa kojim drugim servisima mora da radi. Nije neophodno da unapred imate tehničko rešenje, ali je važno da jasno opišete poslovna pravila, prioritete i poznata ograničenja.

Ova custom CMS checklista služi kao radni brief za prikupljanje ponuda. Ne predstavlja specifikaciju koda niti zamenjuje discovery fazu. Što je više odgovora konkretno, to će ponude biti uporedivije, a broj pretpostavki u proceni manji. Ako tek procenjujete da li vam je potreban custom CMS ili drugačija arhitektura, ova pitanja mogu poslužiti kao osnova za razgovor.

1. Cilj, obim i prioriteti

1. Poslovni cilj sistema. Napišite šta CMS treba da poboljša: upravljanje katalogom, objavu sadržaja, rad više redakcija, administraciju korisnika ili povezivanje sa postojećim sistemima.
2. Tipovi sadržaja. Nabrojte sve entitete koji se uređuju, na primer proizvode, lokacije, članke, autore, kategorije, FAQ zapise ili dokumente.
3. Obavezna i opciona polja. Za svaki tip sadržaja odvojite podatke bez kojih zapis ne može da bude objavljen od podataka koji su korisni, ali nisu neophodni.
4. Prioriteti po fazama. Razdvojite minimum potreban za prvu verziju od funkcija koje mogu da budu deo kasnije faze. To olakšava poređenje obima i trade-offa.
5. Primeri ključnih scenarija. Opišite nekoliko konkretnih tokova: „editor kreira zapis, reviewer ga proverava, administrator objavljuje“ ili „uvoz podataka pokreće ažuriranje povezanih stranica“.

2. Model podataka i struktura sadržaja

6. Veze između entiteta. Navedite da li jedan autor pripada većem broju tekstova, da li proizvod ima više kategorija ili da li lokacija ima povezane usluge. Ovo utiče na model podataka i način uređivanja.
7. Varijante i ponovljivi blokovi. Definišite da li urednik dodaje neograničen broj stavki, galerija, tabela, specifikacija ili sekcija na jednoj stranici.
8. Taksonomija i filteri. Zapišite koje kategorije, oznake i atributi postoje i po kojim kriterijumima korisnik treba da filtrira sadržaj. Za velike kataloge korisno je unapred opisati strukturu kroz vodič Custom CMS za veliki katalog ili direktorijum: model podataka i filteri.
9. Pravila validacije. Navedite ograničenja za obavezna polja, formate datuma, jedinstvene identifikatore, dužinu teksta, fajlove i dozvoljene vrednosti.
10. Postojeći podaci i migracija. Priložite format izvora podataka, procenjeni obim, duplikate, nedostajuća polja i pravila po kojima se stari zapisi mapiraju na novi model.

3. Urednički rad i dozvole

11. Broj i tipovi korisnika. Navedite ko će raditi u administraciji: autori sadržaja, urednici, recenzenti, administratori, partneri ili drugi ograničeni korisnici.
12. Dozvole po sadržaju. Razjasnite da li neko može da vidi, kreira, menja, odobri ili obriše samo određene tipove zapisa, brendove, jezike ili organizacione jedinice. Za detaljniju pripremu pogledajte tekst Uloge i dozvole u CMS-u: kako organizovati editor, reviewer i administrator pristup.
13. Statusi i workflow. Navedite potrebna stanja, na primer draft, review, approved, scheduled, published i archived, kao i ko može da pokrene prelaz između njih.
14. Zakazivanje i verzije. Proverite da li su potrebni buduća objava, vraćanje starije verzije, istorija izmena, pregled razlika i automatsko čuvanje nacrta. Specifične zahteve možete razraditi kroz editorial workflow vodič za custom CMS.
15. Više jezika i tržišta. Definišite da li prevodi imaju odvojene statuse, da li je jedan jezik primarni i šta se dešava kada prevod ne postoji ili se izvorni tekst promeni.

4. Frontend, SEO i distribucija

16. Predviđeni tipovi stranica. Pošaljite listu šablona i komponenti koje treba podržati: listing, detalj, pretraga, landing stranica, autor, kategorija ili dokument.
17. URL pravila. Opišite strukturu URL-ova, slugove, promenu slugova, preusmeravanja i ponašanje pri arhiviranju sadržaja. Nemojte pretpostaviti da će CMS sam rešiti istoriju URL-ova.
18. SEO polja i kontrola indeksiranja. Navedite potrebu za title i description poljima, canonical adresama, Open Graph podacima, robots direktivama, XML sitemapama i kontrolom vidljivosti pojedinačnih zapisa. Za tehničke detalje o robots.txt pravilima pogledajte Google dokumentaciju o robots.txt.
19. Pretraga i filtriranje. Definišite da li se pretražuju samo naslovi ili i telo sadržaja, kako se tretiraju sinonimi, pravopisne varijante, prazni rezultati i kombinovanje filtera.
20. Pristupačnost i responsivnost. Navedite zahtev za rad na mobilnim uređajima, tastaturom, čitačima ekrana i jasnim fokus stanjima. WCAG 2.2 može poslužiti kao referentni okvir, ali konkretan nivo usklađenosti treba dogovoriti u briefu.

5. Integracije, bezbednost i održavanje

21. Integracije i vlasništvo nad podacima. Nabrojte CRM, ERP, newsletter, plaćanje, analitiku, pretragu, SSO ili druge servise. Za svaku integraciju navedite smer razmene podataka, učestalost i očekivano ponašanje kada servis nije dostupan.
22. Uvoz i izvoz. Precizirajte formate, ručni ili automatski uvoz, mapiranje kolona, log grešaka i da li korisnik može da izveze podatke bez developerske intervencije.
23. Bezbednosni zahtevi. Navedite MFA ako je potrebna, politiku lozinki, ograničenje pokušaja prijave, audit log, upravljanje sesijama, backup i procedure za oporavak. Kao tehnički kontrolni okvir može se koristiti OWASP ASVS, uz prilagođavanje stvarnom riziku projekta.
24. Hosting, okruženja i monitoring. Razjasnite gde se sistem hostuje, da li postoje development, staging i production okruženja, ko upravlja deploymentom i koje greške ili prekidi treba da generišu upozorenje.
25. Održavanje i predaja. U ponudi tražite opis dokumentacije, pristupa repozitorijumu i hostingu, procedure za backup, podršku nakon isporuke, obuku korisnika i odgovornost za nadogradnje zavisnosti.

Kako da checklistu pretvorite u dobar brief

Ne morate imati odgovor na svako pitanje pre prvog razgovora. Umesto nagađanja, označite stavke kao obavezno, poželjno ili otvoreno pitanje. Dodajte linkove ka postojećem sajtu, primerima sadržaja, tabelama, API dokumentaciji i skicama ekrana. Ako je projekat prvenstveno sadržajni, obavezno priložite jedan realan primer zapisa, a ne samo opis polja.

Za svaku nejasnoću zatražite od ponuđača da navede pretpostavku, posledicu po obim i alternativu. Tako ne poredite samo ukupne iznose, već i to šta zaista dobijate u prvoj fazi. Ako se ispostavi da vam nije potreban potpuno prilagođen sistem, isti brief može pomoći i pri proceni šireg projekta izrade sajta.

Sledeći korak je da checklistu pretvorite u dokument od nekoliko strana sa prioritetima, primerima podataka i listom integracija. Takav brief je dovoljno konkretan za početnu procenu, ali ostavlja prostor da se kroz discovery potvrde arhitektura, rizici i plan isporuke.