Koľko bude stáť budúca zmena?
Obsah
Lacnejšia ponuka nemusí znamenať lacnejší systém. Rozdiel sa často ukáže až o rok či dva, keď firma potrebuje pridať nový typ zákazníka, upraviť schvaľovanie, zmeniť cenník alebo prepojiť softvér s ďalšou službou. Vtedy sa ukáže, či bola pôvodná úspora skutočnou úsporou, alebo iba odloženým nákladom.
Pri firemnom softvéri sa preto neoplatí pýtať iba: „Koľko bude stáť jeho vytvorenie?“ Rovnako dôležitá je otázka: „Koľko bude stáť, keď toto o rok zmeníme?“
Cena, ktorú v ponuke nevidno #
Predstavme si dve ponuky na rovnaký interný systém. Prvá stojí 12 000 eur, druhá 16 000 eur. Ak porovnávame iba zoznam funkcií a výslednú sumu, prvá možnosť vyzerá jednoznačne lepšie.
Oba systémy môžu pri odovzdaní robiť presne to isté. Rozdiel však môže byť skrytý v ich vnútornej stavbe. V prvom riešení sú obchodné pravidlá roztrúsené vo formulároch, exportoch a rôznych častiach kódu. V druhom sú oddelené od zvyšku systému a každé má jasné miesto.
Po roku príde požiadavka na ďalší schvaľovací krok. V prvom systéme treba najskôr zistiť, čo všetko zmena ovplyvní. V druhom sa upraví izolovaná časť procesu. Funkčne rovnaké riešenia zrazu nemajú rovnaké náklady.
Počiatočná cena je dobre viditeľná, preto prirodzene dominuje rozhodovaniu. Cena budúcich zmien sa do ponuky zapisuje ťažšie. Napriek tomu môže počas života systému prevýšiť cenu jeho prvej verzie.
Malá požiadavka môže spustiť veľkú zmenu #
Používateľ môže požiadavku opísať jednou vetou: „Pridajme nový typ zákazníka.“ Pre softvér to však nemusí byť jedna zmena.
Čím viac miest musí programátor nájsť, pochopiť a upraviť, tým viac času zmena zaberie. Súčasne rastie pravdepodobnosť, že sa na niektoré miesto zabudne alebo že oprava naruší inú funkciu.
Cena zmeny preto nevychádza iba z množstva nového kódu. Tvorí ju aj hľadanie závislostí, overovanie dôsledkov, testovanie dotknutých častí, migrácia údajov, nasadenie a riešenie prípadných chýb. Zdanlivo malá úprava je drahá najmä vtedy, keď má veľký dosah zmeny.
Tri spôsoby dopravy a štvrtý problém #
Firma má objednávkový systém a tri možnosti dopravy: kuriéra, osobný odber a paletovú prepravu. Pri prvej verzii je najrýchlejšie napísať tri podmienky priamo tam, kde sú potrebné.
Postupne sa však rovnaký predpoklad objaví v cenotvorbe, fakturácii, notifikáciách, sklade aj exporte pre účtovníctvo. Každá časť systému počíta s tým, že možností sú presne tri.
O dva roky firma pridá výdajné boxy. Hlavná otázka už neznie:
Ako dlho trvá doprogramovať štvrtý spôsob dopravy?
Oveľa dôležitejšia je otázka:
Na koľkých miestach systém predpokladá, že existujú presne tri?
Ak má doprava vlastný model a ostatné časti systému pracujú s jeho spoločným rozhraním, nová možnosť sa dá pridať lokálne. Ak sú konkrétne druhy dopravy natvrdo zapísané na mnohých miestach, zmena sa rozleje cez celý systém.
Toto je praktický rozdiel medzi nízkou a vysokou cenou zmeny:
- Nízka cena: upravíme jedno pravidlo na jednom známom mieste.
- Vysoká cena: najskôr musíme zistiť, kde všade sa pravidlo nachádza a čo na ňom závisí.
Upraviteľnosť nie je iba vlastnosť kódu #
Čistý a zrozumiteľný kód pomáha, ale sám nestačí. Upraviteľnosť vzniká kombináciou viacerých rozhodnutí.
| Oblasť | Ako ovplyvňuje budúce zmeny |
|---|---|
| Dátový model | Určuje, či nové prípady možno pridať, alebo treba prestavať uložené údaje. |
| Rozdelenie na moduly | Rozhoduje, či zmena zostane v jednej časti, alebo sa rozšíri do celého systému. |
| Konfigurácia | Umožňuje meniť sadzby, limity či pravidlá bez zásahu do programu. |
| Rozhrania a integrácie | Oddeľujú vnútornú logiku od služieb, ktoré firma neovláda. |
| Automatizované testy | Rýchlejšie ukážu, či úprava nepoškodila existujúce správanie. |
| Dokumentácia | Skracuje čas potrebný na pochopenie rozhodnutí a závislostí. |
| Spôsob nasadenia | Určuje náročnosť a riziko doručenia zmeny používateľom. |
| Závislosť od dodávateľa | Ovplyvňuje, či systém dokáže bezpečne prevziať a rozvíjať aj niekto iný. |
Do výsledku vstupuje aj samotná firma. Ak nevie jednoznačne opísať svoje procesy, výnimky a zodpovednosti, ani technicky kvalitný systém sa nebude meniť lacno. Upraviteľnosť je vlastnosť celého riešenia — kódu, dát, prevádzky aj spôsobu rozhodovania.
Ani flexibilita nie je zadarmo #
Z toho nevyplýva, že všetko má byť od prvého dňa všeobecné a nastaviteľné. Príprava na každú predstaviteľnú budúcnosť vedie k väčšiemu množstvu kódu, zložitejšiemu ovládaniu a vyššej počiatočnej cene. Systém môže byť taký flexibilný, až sa mu prestane dať rozumieť.
Navyše sa môže ukázať, že draho vybudované možnosti nikto nikdy nevyužije. To je rovnaké plytvanie ako krátkozraké riešenie, ktoré treba pri prvej zmene prerobiť.
Rozumným cieľom teda nie je maximálna flexibilita. Cieľom je primeraná upraviteľnosť na miestach, kde je zmena pravdepodobná alebo by bola mimoriadne drahá.
Navrhovať treba na pravdepodobnú zmenu #
Budúcnosť sa nedá presne predpovedať, no nie všetky zmeny sú rovnako nečakané. Pri návrhu sa oplatí rozlišovať tri skupiny:
- Zmeny, o ktorých už vieme. Firma napríklad plánuje nový sklad, ďalší trh alebo druhú cenovú schému. Systém by ich nemal blokovať.
- Zmeny typické pre danú oblasť. Cenníky, sadzby, schvaľovacie kroky, používateľské roly a externé API sa bežne vyvíjajú. Tu má izolácia pravidiel a rozumná konfigurácia jasnú hodnotu.
- Čisto hypotetické možnosti. Ak pre ne neexistuje obchodný dôvod ani realistický scenár, nie je nutné platiť za ich podporu dnes.
Dobrá architektúra nie je veštenie. Je to schopnosť pomenovať, ktoré predpoklady sú stabilné, ktoré sa pravdepodobne zmenia a ktoré rozhodnutia by sa neskôr rušili veľmi ťažko.
Pri ďalšej ponuke sa opýtajte ešte jednu otázku #
Presnú cenu budúcej požiadavky nikto seriózne neurčí bez toho, aby poznal jej obsah. Dodávateľ však môže vysvetliť, ako systém obmedzuje dosah pravdepodobných zmien.
Pred objednaním alebo rozšírením firemného softvéru sa preto oplatí pýtať:
- Čo sa stane, keď pribudne ďalší typ produktu, skladu, zákazníka alebo dopravy?
- Ktoré obchodné pravidlá budú konfigurovateľné a ktoré budú súčasťou kódu?
- Sú pravidlá sústredené na jednom mieste alebo roztrúsené medzi viacerými modulmi?
- Čo bude potrebné zmeniť pri výmene externého systému alebo API?
- Ako sa overí, že úprava nepoškodila existujúce funkcie?
- Dokáže riešenie pochopiť a prevziať aj iný programátor?
- Ktoré dnešné rozhodnutia by bolo najdrahšie neskôr zmeniť?
Tieto otázky nenahradia technický návrh ani odhad. Pomôžu však odlíšiť systém, ktorý iba spĺňa dnešné zadanie, od systému, ktorý možno hospodárne rozvíjať.
Počiatočná cena zostáva dôležitá. Nemala by však zakryť skutočnosť, že firemný softvér nežije iba v deň odovzdania. Architektonické rozhodnutie je zároveň rozhodnutím o budúcej cene každej zmeny.