Proč nepřidávat další vlastnosti?

Pokud máte funkční aplikaci a uživatelé jsou s ní spokojeni, tak všechny požadavky na nové vlastnosti zamítejte a nové vlastnosti nepřidávejte. Proč?

Protože aplikace by měla obsahovat jen ty vlastnosti, které jsou opravdu potřeba. Zaměřte se spíš na to, aby vám ty stávající vlastnosti fungovaly naprosto perfektně a obsluha vaší aplikace byla co nejjednodušší a nejintuitivnější. Jestliže musí uživatel absolvovat školení nebo číst nějaký manuál, aby vůbec mohl začít s vaší aplikací pracovat, znamená to, že někde je něco špatně. Proboha, opravte to a co nejdříve! Copak vy sami nějaký manuál někdy čtete?

U každého požadavku na novou vlastnost si položte otázku, zda je daná vlastnost opravdu potřebná. Pomůže vůbec někomu? Komu? Jedná se o natolik významného zákazníka, že se kvůli němu vyplatí danou vlastnost implementovat? Kolik procent uživatelů tuto úžasnou novou vlastnost opravdu potřebuje, resp. kolik procent z nich ji skutečně využije? Troufám si tvrdit, že i zde platí pravidlo 80/20. Na všechny požadavky na přidání nových vlastností proto odpovídejte důrazně ne.

Když se požadavek na přidání dané vlastnosti pořád vrací, je to jen důvod k zamyšlení, zda danou vlastnost implementovat či nikoliv. Uvědomte si, že všichni mají spoustu nápadů, jaká vlastnost by se mohla ještě přidat, uživatelé, analytici, vývojáři, manažeři. Implementujte proto jen ty opravdu klíčové vlastnosti. Nezapomínejte na to, proč uživatelé vaši aplikaci používají. Především proto, že dělá přesně to, co má a je jednoduché ji používat.

Určitým překvapením je, že v některých případech jsou to přímo vývojáři, kteří sami přidávají do jimi vyvíjeného SW produktu vlastnosti, které nejenže nejsou uvedeny v SRS (Software Requirements Specification), ale které dokonce po nich ani nikdo nepožadoval. V zahraniční literatuře se tento fenomén nazývá gold plating.

Vývojář zcela fascinován novou technologií, frameworkem, vývojovým prostředím přidává další a další funkce jen proto, že si myslí, že se to uživateli bude určitě hodit a přidané vlastnosti ocení. Často je to ale jen záminka k tomu, jak si vyzkoušet, co všechno ta nová verze umí. Vývojář by si měl uvědomit, že není business analytikem a že je placen od toho, aby vyvíjel podle specifikace a ne, aby suploval funkci business analytika. Vývojář by měl napnout veškeré své úsilí především k tomu, aby jím vytvořený kód byl plně funkční a řádně otestován. Místo přidávání nových vlastní by se měl věnovat jeho optimalizaci.

Další skupinou, která se snaží prosadit přidání nových vlastností, jsou produktoví manažeři. Považují se za experty na daný produkt a jsou pevně přesvědčeni, že oni sami nejlépe vědí, co uživatelé jejich produktu potřebují. Neuvědomují si, že na SW produkt je třeba se dívat jako na jakýkoliv jiný produkt a průzkum trhu a analýza potřeb je neméně důležitá. Jaksi zapomínají, že SW stejně jako jakýkoliv jiný produkt prochází určitými fázemi. I u produktu tohoto typu musíme rozlišovat fázi zavedení, růstu, zrání a nasycení. Je zřejmé, že SDLC (Software Development Life Cycle) by se měl odvíjet od PLC (Product Life Cycle).

Závěr: Když něco funguje a funguje to dobře, nehrabejte na to.

Štítky: requirements engineering, Vývoj SW

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.