Kad izmirs ziloņsistēmas?
Kā ievieš ziloņsistēmas?
Ziloņsistēma ir tāda sistēma, kuras pirmkods nav brīvi pieejams visiem. 1 Ziloņsistēmas veido, balstoties uz cilvēku izdomātu pieņēmumu, ka tās var atļauties tikai bagātie un varenie, ka tās ir vērtīgs un rets resurss kā urāns un platīns, kas visiem nekad nepietiks. Ziloņsistēmas tāpat kā kurpes un auto ar laiku nolietojas. Līdz ar to, visos veidos ir jāierobežo ziloņsistēmu neautorizēta izplatīšana un lietošana. Tāpēc ziloņsistēmu nevar brīvi demonstrēt internetā, vai ierakstīt kompaktdiskā un izdalīt bez maksas apmācības seminārā.
Ziloņsistēmas veido gadiem. To izstrādē piedalās daudz (dažkārt desmiti un simti) cilvēku. Tā kā ziloņsistēmas ir dārgas, lēmumu par pieejamiem naudas līdzekļiem nosaka uzņēmuma vai institūcijas vadība, konsultējoties ar finansistiem, nevis lietotājiem. Nav tā, ka potenciālo lietotāju vēlmes ignorē, tomēr konkursa vai izsoles nolikuma veidu un saturu nosaka projekta summa, nevis viņu prasības. Nolikumu bieži vien veido ārēja konsultāciju firma, kura to apaudzē ar obligāto "figņu", lai tas izskatās "svarīgāk". Projekta dokumentācijā tiek saražotas pirmās simts lapas.
Pasūtītājs izsludina konkursu, un projektā iesaistās izpildītāji. No izpildītāja puses vispirms piedalās mārketinga/klientu jeb žargonā sakot — "projektu izsišanas" daļa. Parasti tie nav cilvēki ar dziļām tehnoloģijas zināšanām, toties tie prot stāstīt, rakstīt un "pārdot ideju". Mārketinga daļa, balstoties uz savām iestrādēm, konkursa nolikumu un IT produktu aprakstiem (parasti tieši šādā kartībā) sagatavo piedāvājumu. Konkursa piedāvājumā ir vismaz rindkopa teksta uz katru konkursa nolikuma rindkopu, jo savādāk ir grūti pārliecināt pasūtītāju, ka ir dotas pietiekami respektējamas atbildes uz nolikuma obligāto "figņu". Rezultātā labs piedāvājums parasti ir vismaz 2× apjomīgāks par nolikumu, bet nereti vēl daudz apjomīgāks. Projektā tiek saražoti nākamie simti (vai tūkstoši) lapu.
Diemžēl, bieži vien pieteikuma galvenā vērtība nav vis klientu daļas sniegums, bet gan pasūtītāja un izpildītāja vadošo darbinieku pazīšanās, kuri golfa laukumā vai pie alus kausa vienojas par abpusēji izdevīgiem noteikumiem.
Kad konkurss ir vinnēts, projektā iesaistās sistēmu analītiķi, kam ir lielākas zināšanas informācijas tehnoloģijās, un kas mārketinga cilvēku pārdoto ideju cenšas "piezemēt" līdz praktiski īstenojamām. Šajā projekta fāzē izpildītāja pārstāvji tiekas ar sistēmas lietotājiem, bet, tā kā ziloņsistēmu lietotāju ir ļoti daudz, faktiski analītiķi tiekas ar īpaši atlasītiem lietotāju pārstāvjiem — parasti dažādiem vadošajiem darbiniekiem. Līdz ar to, prasības nosaka nevis demokrātiski, bet gan no augšas. "Pārstāvji" kā svarīgākās ziloņsistēmas īpašības nosaka nevis ērtu datu ievadi un apstrādi, bet gan padoto veiktā pārraudzību un kontroli (prasti izsakoties — "kontrolēšanas un čakarēšanas iespējas").
Galvenais analītiķu uzdevums ir izstrādāt sistēmas izstrādes dokumentāciju, kā "realizēt" piedāvājumā garantētās iespējas, tai pat laikā neapsolot neko lieku, neiespējamu vai pārāk dārgu. Atkarībā no tā, cik daudz "figņas" ir pieprasīts, analītiķi var izstrādāt sistēmas koncepciju, dažādas prasību specifikācijas un sistēmas projektējumus. Tā kā piedāvājums tika veidots saskaņā ar "figņu", kas bija konkursa nolikumā, arī šie dokumenti satur visu sākotnējo un atvasināto "figņu". Projektā tiek saražoti nākamie simti (tūkstoši) lapu.
Šo dokumentu izstrādes process notiek lēni un mokoši, jo pasūtītājam nākas pieņemt daudzus "svarīgus un tālejošus" lēmumus. Pasūtītājs baidās dokumentus apstiprināt, domājot, ka parakstītie papīri nosaka to, ko viņš projekta beigās saņems kā ziloņsistēmu. Patiesībā šie papīri var noderēt lai tiesātos ar piegādātāju un atgūtu naudu, bet pat tiesa nevar noteikt to, kas būs ziloņsistēmā.
Viss augšminētais process atgādina bērnu spēli "klusie telefoni", kur katrs nākamais dalībnieks nodot nākamajam sākotnējo informāciju, to pārfrāzējot, restrukturizējot, agregējot un visādi citādi sagrozot, jo prastu "kopēšanu un ievietošanu" uzskata par sliktu toni.
Kad projekta izstrādes dokumentācija ir apstiprināta, projektā izstrādē iesaistās 2.-4. kursa datorzinātņu studenti, kas no darba brīvajos brīžos studē. Viņi nav redzējuši ne lietotājus, ne "projekta izsitējus". Tomēr (ja vien viņi nevelta pārāk daudz laika mācībām), viņi zina projektējuma autoru (vai autorus). Viņi urbjas cauri izstrādes dokumentācijai, un tad, kad to nesaprot, lasa arī konkursa piedāvājumu un nolikumu, lai atrastu pēdas, no kurienes ir nācis tas vai cits stulbums. Kad arī tas nelīdz, viņi ar saviem "stulbajiem jautājumiem" "traucē" sistēmanalītiķus, kas tobrīd jau strādā pie cita projekta dokumentācijas. Šajā projekta posmā ir svarīgi izdomāt, kura sistēmas daļa vai modulis ir atbildīga par projektējumā ielikto "figņu". Tā kā pilnībā visu "realizēt" nav iespējams, projekts nonāk 20/80 fāzē, kur ar 20% darba iegūti 80% funkcionalitātes, ko jaunie mācekļi raksturo, ar "gandrīz viss jau ir paveikts". Ja ziloņsistēma ir veidota uz gatavas sistēmas bāzes, 20/80 fāze iestājas, gad sistēmā ir veikta elementāra pielāgošana.
Kad sākas sistēmas testēšana, pakāpeniska ieviešana, pārbaude klienta infrastruktūrā u.tml., sistēmu beidzot ierauga potenciālie lietotāji. Parādās neparedzētas problēmas. Daudz kas no tā, kas studentam strādāja, klientam nestrādā. Protams, viņi nav apmierināti ar rezultātu, un pieprasa neskaitāmas izmaiņas. Pasūtītājs ar izpildītāju cīnās par juridiskām un finansiālām finesēm, lai vienotos, kā šīs izmaiņas veikt. Ja ziloņsistēmu ir nepieciešams integrēt ar kādu citu, tad projekta attīstības tempi samazinās tik reizes, cik grūti citam izpildītājam veicas ar integrējamās ziloņsistēmas izstrādi un uzturēšanu.
Ja līdz šim brīdim izstrādātājam ir paveicies nodot iepriekšējos projekta posmus, tad šajā bīdi iestājas apsīkums, jo izpildītājam beidzas "vieglās naudas" periods. Pat, ja par prasītajām izmaiņām maksā naudu, parasti tā neatsver patiesās izmaksas, jo pasūtītājs pieprasa attiecīgi labot veselu ziloņsistēmas dokumentācijas kaskādi — koncepciju, prasības, projektējumu, dizainu, lietotāju un administratoru instrukcijas. Šī projekta fāze parasti beidzas tajā brīdī, kad viena vai otra puse ir nokautēta. Parasti pasūtītāja vai izpildītāja pusē nomainās projekta pārvaldnieks, un tā pēctecis ir vai nu pielaidīgāks, vai (teorētiski iespējams) piebeidz otru pusi ar dažiem iznīcinošiem sitieniem.
Ziloņsistēmas lietotāji iegūst nevis tādu sistēmu, kādu bija vēlējušies, bet gan tādu, kādu izstrādātājs varēja atļauties izstrādāt, pirms projekts nonāca finansiālās grūtībās. Laikam ejot, ziloņsistēma kļūst arvien neatbilstošāka lietotāju prasībām, jo visu nepieciešamo izmaiņu veikšanu izstrādātājs nevar atļauties.
Ja ziloņsistēma ir veidota uz gatava produkta bāzes, pēc kāda gada pasūtītājs atklāj, ka viņam ir jāmaksā par licencēm, jo projekta izmaksās iekļautais licences termiņš ir beidzies. Jo vairāk ir jāmaksā par ziloņsistēmas licencēm, jo mazāk pasūtītājs ir gatavs maksāt par uzturēšanu un izmaiņu veikšanu.
Kā ievieš atvērtā koda sistēmas?
Atvērtā koda sistēmas veidojas tā, kā evolucionē daba. Daba (vai Dievs, kā kuram labpatīk), atšķirībā no cilvēka, nekad nav piedzīvojusi resursu trūkumu. Tā nav ierobežota, ne telpā ne laikā. Dabai nepiemīt morāle. Viss, kas strādā, ir labs. Nav aizliegta zagšana, kopēšana, plaģiātisms. Zivis nevaino delfīnus par nelicenzētu pleznu izmantošanu. Dinozauri neapsūdz rāpuļus par olu patenta pārkāpumiem, bet putni nesauc uz tiesu sikspārņus par spārna autortiesību pārkāpšanu. Diemžēl, vairums cilvēku nav pamanījuši, ka šie paši dabas, nevis cilvēku izdomātie, likumi ir spēkā arī programmatūrai. Programmatūras izstrādē zagšana, kopēšana un plaģiātisms ir tikpat dabīga, kā dzīvajā dabā. Tāpat kā dabai "neko nemaksā" izveidot jaunu sugas pārstāvi, arī programmatūrai neko nemaksā izveidot kopiju. Atvērtā koda sistēmas ir tikpat pieejamas kā ogleklis, ūdeņradis un skābeklis dabai. Un tāpat, kā ogleklis nenolietojas dabas apritē, tāpat nenolietojas atvērtā koda programmas. Tieši otrādi — tāpat kā suga kļūst spēcīgāka vairojoties atsevišķiem īpatņiem, tā programmatūra kļūst vērtīgāka, palielinoties tās lietotāju skaitam. Atvērtā koda sistēmas "izstrādājas pašas no sevis", kad kāds no pielāgotājiem izrēķina, ka papildinājumu atdošana "kopējā katlā" ir lētāka, kā nepārtraukta izmaiņu iekļaušana koplietošanas versijā.
Atvērtā koda programmas ievieš daži domubiedri, kas pārbagātajā atvērtā koda pasaulē ir atraduši kaut ko sev piemērotu. Tā varētu būt Alfresco satura pārvaldība, SugarCRM klientu pārvaldība, OpenBravo resursu pārvaldības sistēma, bet, iespējams jebkura cita http://freshmeat.net vai http://sourceforge.net atrodama sistēma. Viņi šīs sistēmas ir apskatījuši bez maksas internetā, un kādā pēcpusdienā viņi to ir uzstādījuši uz sava (iespējams — virtuāla) datora. Viņiem nav nepieciešams ne jurists, lai izvēlētos licenču nosacījumus, ne grāmatvedis, lai saskaitītu licenču summas, ne astronoms, lai noteiktu, kad iestāsies licenču (vai izmēģinājumu versijas) beigu termiņš.
Jau nākamajā dienā viņi par šīs sistēmas pieejamību paziņo uzņēmuma lietotājiem. Lietotāji var darboties ar sistēmu, apskatīt tās iespējas un novērtēt tās atbilstību. Ļoti iespējams, ka uzņēmuma entuziasti ir uzstādījuši divas vai pat vairākas līdzīgas sistēmas, un lietotāji tās var salīdzināt savā starpā.
Un parasti to iegūst, nesmērējot nevienu papīra lapu.
Divu nedēļu laikā lietotāji ir apzinājuši atvērtā koda sistēmas izmaiņu apjomu. Parasti tā ir saskarnes un dokumentācijas latviskošana, pielāgošana atbilstoši Latvijas likumdošanai, kā arī integrācija ar kādu esošo sistēmu. Nenoliedzami, arī atvērtā koda sistēmai ir nepieciešama lietotāju rokasgrāmatas un uzturēšanas instrukcijas, tomēr to dokumentāciju veido, vadoties no darbojošās sistēmas, nevis no "figņas" kaskādes, ko ievazā ziloņsistēmu projektos.
Parasti šajā brīdī uzņēmums saprot, ka visu nepieciešamo viņš nevarēs veikt sev vēlamajos termiņos, tāpēc sistēmas pielāgošanā uzaicina ārēju izstrādātāju.
Lai arī atvērtā koda sistēma negarantē godīgu konkursa veikšanu, tā garantē mazākas izmaksas un līdz ar to, mazāku korupcijas risku (par sīkām drupačām taču nav vērts slēgt kompromisu ar sirdsapziņu).
Atvērtā koda sistēmas projekts sākas tur, kur beidzas ziloņsistēmas projekts — ar pielāgošanu atbilstoši faktisko lietotāju, nevis "figņas" prasībām. Protams, arī atvērtā koda projekti ir neveiksmīgi. Iespējams, ka neveiksmīgo projektu attiecība pret veiksmīgajiem ir tāda pati, ka ziloņsistēmu projektiem. Tomēr ir viena būtiska atšķirība:
Šī pieeja ir pazīstama ar teicienu "izgāzies agri un bieži" ("Fail early, fail often"). Tā kā atvērtā koda projekti sākas uzreiz ar sistēmas pārbaudi un pielāgošanu, tad neveiksmes gadījumā (nepietiek resursu, nav zināšanu, izvēlēts neatbilstošs risinājums), tos pārtrauc ar minimāliem zaudējumiem. Ziloņsistēmu projekti var vilkties gadiem, pirms vadība saprot, ka projekts ir neveiksmīgs. 2
Atvērtā koda sistēmas nodrošina vienlīdzīgas iespējas dažādiem piegādātājiem. Tas ļauj ieviest vienotus standartus un sadarbības modeļus, bet neveido monopolu. Atvērtā koda sistēmai nav jāmaksā par sistēmas lietošanu, tāpēc pasūtītājam ar izstrādātāju/uzturētāju ir daudz vieglāk vienoties par izmaiņu ieviešanu un uzturēšanu. Pasūtītājs var izvēlēties dažādus sistēmas uzturētājus, jo atšķirībā no ziloņsistēmas, tajā nav slepeno bitu, kurus pārzina tikai izredzētie. Tajā skaitā pasūtītājs var izvēlēties uzturēt sistēmu pats saviem spēkiem, jo viņam pašam ir tādas pašas iespējas, kā sistēmas piegādātājam.
Ja atvērtā koda sistēma tik daudzās jomās ir labāka par ziloņsistēmu, kāpēc visi tās neizmanto? Kāpēc pirms 100 miljoniem gadu valdīja dinozauri nevis zīdītāji? Kad parādījās pirmie zīdītāji, tiem nebija pietiekamu priekšrocību, lai nomāktu dinozaurus. Bet kad 65 miljonus gadu atpakaļ globālā temperatūra samazinājās, dinozauri izmira, un viņu vietu ieņēma zīdītāji.
Pasaules finansiālā krīze un ekonomikas lejupslīde ir "IT leduslaikmets". Šis ir laiks, kad ziloņsistēmas mirst, bet atvērtā koda zīdītāji strauji vairojas.
Created by Valdis Vītoliņš on 2009-05-19 16:42
Last modified by Valdis Vītoliņš on 2021-04-13 14:26