Je více funkcionality lépe? V čem si zadavatelé webů zadělávají na problémy už na začátku? A proč je dobré určit si své „nefunkční“ požadavky?
Na vývoj webů a aplikací nám zpravidla chodí 2 typy poptávek:
- Chtějí hodně funkcionality za nízkou cenu. Rezervační systém, platební brána, e-shop, …
- Už se spálili a hledají spolehlivého dodavatele. Zjistili, že webová aplikace není jen o funkcionalitě.
První skupina zadavatelů specifikuje jen své FUNKČNÍ požadavky, které přitom mnohdy vůbec nepotřebují (o tom ale jindy, jen předešlu vhodnou metodiku MoSCoW).
Na co však zapomínají, jsou NEFUNČKNÍ požadavky. Bez nich se snadno spálí a už třeba po roce musí celou investici do webu zahodit a najít si schopnějšího dodavatele. Tomu by dokázali předejít, pokud by si rozmysleli, zda chtějí od aplikace:
Obvyklé nefunkční požadavky
- Fungovala správně a spolehlivě, zejména pokud se v ní jakkoli počítají peníze.
- Ptejte se, jak se bude aplikace testovat (unit testy, integrační testy), jak automatizovaný je deployment, jak častý monitoring a dostatečně robustní architektura aplikace.
- Ptejte se, jak se bude aplikace testovat (unit testy, integrační testy), jak automatizovaný je deployment, jak častý monitoring a dostatečně robustní architektura aplikace.
- Rozhraní se jednoduše používalo a skvěle zobrazovalo na různých zařízeních od starších telefonů až po obří monitory.
- Prohlédněte si předchozí reference, pobavte se o návrhu a testování uživatelských rozhraní.
- Prohlédněte si předchozí reference, pobavte se o návrhu a testování uživatelských rozhraní.
- Běžela rychle i v zátěži, s velkými daty a s pomalým připojením.
- Dnes již PHP a relační databáze stačí na 99 % projektů, ale nevhodným návrhem databáze a implementací jde téměř zabít, takže chtějte seniorního vývojáře minimálně na startu projektu. Na frontendu se rychlosti načítání v prohlížeči dá optimalizovat v podstatě do nekonečna, čili tu nemusíte na začátku tak hrotit.
- Dnes již PHP a relační databáze stačí na 99 % projektů, ale nevhodným návrhem databáze a implementací jde téměř zabít, takže chtějte seniorního vývojáře minimálně na startu projektu. Na frontendu se rychlosti načítání v prohlížeči dá optimalizovat v podstatě do nekonečna, čili tu nemusíte na začátku tak hrotit.
- Byla zabezpečená a odolná jak proti napadení, tak proti spamům.
- Chtějte vědět, jak se budou chránit veřejné formuláře proti spamům (jde to i bez opisování obrázku) a jak se bude pracovat s uživatelskými účty a hesly. Moderní frameworky v zabezpečení pomáhají, ale špatným návrhem byste mohli na veřejnost odhalit třeba ID nebo e-maily uživatelských účtů.
- Chtějte vědět, jak se budou chránit veřejné formuláře proti spamům (jde to i bez opisování obrázku) a jak se bude pracovat s uživatelskými účty a hesly. Moderní frameworky v zabezpečení pomáhají, ale špatným návrhem byste mohli na veřejnost odhalit třeba ID nebo e-maily uživatelských účtů.
- Umožňovala snadné rozšiřování o další funkcionalitu.
- Novou funkcionalitu nikdy nechtějte na tvrdo zadrátovat do aplikace, protože dříve nebo později dojde k její změně. Naopak modulární architektura sníží závislost mezi jednotlivými částmi aplikace.
- Novou funkcionalitu nikdy nechtějte na tvrdo zadrátovat do aplikace, protože dříve nebo později dojde k její změně. Naopak modulární architektura sníží závislost mezi jednotlivými částmi aplikace.
- Mohla být nezávisle provozována, abyste při ukončení spolupráce s původním dodavatelem nepřišli o dlouho budovaný systém.
- Budete mít dostatečná licenční oprávnění pro provoz a rozvoj aplikace? Dostanete přístup ke zdrojovým kódům? Bude mít aplikace readme (návod na spuštění)?
Určitě ne každý webový projekt potřebuje tyto nefunkční požadavky hrotit. Pokud je potřeba jen spíchnout malou aplikaci typu „proof of concept“ může se vyvíjet opravdu rychle. Když třeba pro start-up tvoříme MVP (Minimum Viable Product), také nemá smysl hned řešit škálovatelnost.
Pokud ale zadavatel chce na chystaném webu nebo aplikaci stavět byznys, měl by si dobře promyslet i své nefunkční požadavky.
Přeji úspěšné zadávání! 🙂
