PHP un Laravel: ko šī izvēle nozīmē uzņēmumam, kas pasūta sistēmu

Piedāvājumā rakstītais „PHP 8.4, Laravel 13“ nav tehniska detaļa: šīs divas rindas nosaka, cik ilgi sistēma saņems drošības labojumus, kas tajā maksās papildus un cik dārga būs nodošana citam izstrādātājam.

Piedāvājums pienāk piektdienas pēcpusdienā, un tā tehniskajā daļā ir divas rindas, kuras sanāksmē neviens neizlasa skaļi: „PHP 8.4“ un „Laravel 13“. Cena ir saprotama, termiņš ir saprotams, un šīs divas rindas izskatās pēc piegādātāja iekšējās virtuves — apmēram tikpat svarīgas kā tas, ar kuru urbi tiks izurbts caurums sienā, un tāpēc tās parasti pārlaiž kā tehnisku detaļu, par kuru atbild kāds cits. Paraksts tomēr nāk zem visa dokumenta, un tieši šīs divas rindas nosaka, cik ilgi sistēma vispār saņems drošības labojumus, kas tajā izrakstīs ikmēneša rēķinu papildus izstrādes cenai un cik dārga pēc trim gadiem būs tās nodošana kādam citam.

Šis raksts nav par to, vai PHP ir laba valoda un vai Laravel ir labs ietvars, jo uz šo jautājumu izstrādātāji atbild savā starpā un pircējam no tās sarunas nav nekāda praktiska labuma. Tas ir par četrām lietām, kuras pircējs var pārbaudīt pats un bez tehniskām zināšanām: atbalsta kalendāru, licenci, darba tirgu un nodošanas nosacījumiem. Visas četras ir publiskas, trīs no tām ir vai nu datumi, vai naudas summas, ceturtā ir tas, ko par tirgu var un nevar zināt, un neviena no tām nav atkarīga no tā, cik pārliecinoši piedāvājums ir uzrakstīts — tāpēc tās der pārbaudīt tieši tajā nedēļā, kamēr par cenu vēl var runāt.

Kas ir valoda, kas ir ietvars, un kāpēc tā nav viena izvēle

PHP ir programmēšanas valoda, kurā uzrakstīta sistēmas servera puse — tā daļa, kas strādā pie piegādātāja vai Jūsu mitinātāja un ko lietotājs nekad neredz. Laravel savukārt ir ietvars, tas ir, PHP valodā jau uzrakstīta koda bāze, kura atrisina to, kas atkārtojas gandrīz katrā projektā: lietotāju pieteikšanos, datubāzes vaicājumus, rindas, failu glabāšanu, e-pastu sūtīšanu. Piedāvājumā tie stāv blakus kā viena izvēle, taču tie ir divi atsevišķi produkti, kurus uztur divas dažādas komandas ar diviem dažādiem atbalsta kalendāriem, un tieši tāpēc tos ir vērts izlasīt atsevišķi.

Cik izplatīta ir valoda, izrādās grūtāk pateikt, nekā gaidītu. W3Techs, kas regulāri skenē vairāk nekā divdesmit miljonus vietņu, šā gada augustā raksta, ka PHP izmanto 70,2% no visām vietnēm, kuru servera puses programmēšanas valodu šis rīks zina. Pēdējais nosacījums ir tas, kas parasti pazūd, kad skaitli pārraksta prezentācijā: runa nav par 70% no visām pasaules vietnēm, bet par 70% no tām, kuras šis konkrētais rīks vispār spēj atpazīt, turklāt daļu no atpazīšanas tas pats apraksta kā izsecinātu netieši — ja lapa ir WordPress, tad tā ir PHP.

Pircējam noderīgāks ir cits skaitlis no tās pašas lapas. Starp vietnēm, kurām W3Techs nosaka arī PHP versiju, 63,3% strādā uz astotās, 28,7% uz septītās un 7,9% joprojām uz piektās, lai gan septītā versija zaudēja pat drošības labojumus jau pirms četriem gadiem. Tas nozīmē, ka aptuveni trešdaļa no izmērāmā PHP interneta šodien darbojas uz koda, kuram vairs neviens netaisa ielāpus, un tas nav noticis tāpēc, ka valoda būtu slikta vai ka kāds būtu izdarījis kļūdu izstrādē. Tas ir noticis tāpēc, ka neviens nav pasūtījis un apmaksājis versijas maiņu, un šī ir tieši tā riska daļa, kuru pircējs var gan ieraudzīt, gan vadīt.

PHP atbalsta kalendārs ir pirmais dokuments, ko vērts atvērt

PHP izstrādātāju grupas noteikums ir īss un publisks: katrs versiju zars saņem pilnu atbalstu divus gadus no pirmā stabilā laidiena, pēc tam vēl divus gadus tikai kritiskus drošības labojumus, un pēc četriem gadiem tas vairs netiek uzturēts vispār. Šajā noteikumā ir viena detaļa, kuru pārstāsti gandrīz vienmēr nogriež: patiesie beigu datumi tabulā ir pieskaņoti gada pēdējai dienai, nevis laidiena gadadienai novembrī, tāpēc „divi gadi no izlaišanas“ un tas, kas rakstīts php.net tabulā, atšķiras par mēnesi vai diviem.

Praktiski tas nozīmē sekojošo. Versija 8.2 šobrīd ir tikai drošības režīmā, un tās atbalsts beidzas jau šā gada beigās, tātad pēc apmēram četriem mēnešiem. Versija 8.3 pilno atbalstu zaudēja pērnā gada beigās un drošības labojumus saņems līdz 2027. gada beigām, tātad vēl apmēram sešpadsmit mēnešus. Versija 8.4 pilnajā atbalstā nostrādā šo gadu līdz galam un pēc tam vēl divus gadus paliek drošības režīmā, savukārt jaunākā 8.5, kas iznāca pagājušā gada novembrī, pilnu atbalstu saņem vēl visu nākamo gadu un drošības labojumus līdz 2029. gada beigām.

Versijas 8.1 atbalsts beidzās pērnā gada pēdējā dienā, un tieši šis gadījums ir vērts uzmanības, ja Jums jau ir sistēma, nevis piedāvājums. Ja piegādātājs pirms trim gadiem uzrakstīja to uz 8.1 un kopš tā laika neviens neko nav mainījis, tad tā šodien strādā uz zara, kuram drošības ielāpi vairs nenāk, un par to nebrīdina ne serveris, ne pārlūks, ne pati sistēma. Lapa atveras tieši tāpat kā vakar, klienti neko nepamana, un vienīgā vieta, kur to var ieraudzīt, ir šī pati publiskā tabula, kuru atvērt aizņem mazāk laika nekā izlasīt piedāvājuma titullapu.

Laravel kalendārs ir īsāks nekā PHP kalendārs

Laravel savu politiku formulē vēl īsāk: kļūdu labojumi astoņpadsmit mēnešus, drošības labojumi divus gadus, un jauna galvenā versija katru gadu aptuveni pirmajā ceturksnī. Ilgtermiņa atbalsta laidiena, ko nozarē sauc par LTS, šodien vairs nav — vecajās versijās tāds tiešām bija, taču šā gada tabulā tādas ailes nav vispār, tāpēc piedāvājums, kurā rakstīts „LTS Laravel“, apraksta kaut ko, ko šobrīd neviens nepārdod. Tas ir īsāks solījums, nekā daudzi pircēji sagaida no ietvara, uz kura tiks būvēta sistēma nākamajiem pieciem gadiem.

Skaitļos, pēc pašas Laravel dokumentācijas, kārtība ir šāda. Laravel 13 iznāca šā gada martā, kļūdu labojumus saņems līdz nākamā gada trešajam ceturksnim, bet drošības labojumus — līdz 2028. gada 17. martam. Laravel 12 kļūdu labojumu logs aizvērās šā gada augusta vidū, tas ir, septiņpadsmit dienas pirms šo rindu rakstīšanas, un tā drošības labojumi beigsies nākamā gada februārī. Laravel 11 drošības atbalsts beidzās šā gada pavasarī, tātad sistēma, kas šodien strādā uz vienpadsmitās versijas, jau strādā bez ielāpiem, lai cik labi tā izskatītos no ārpuses.

Pievērsiet uzmanību tam, ka Laravel 13 kļūdu labojumu beigas ir norādītas kā ceturksnis, nevis kā konkrēts datums. Tā ir pašu Laravel formulējuma neprecizitāte, un tā nav problēma, kamēr to pārraksta tieši tā, kā tur stāv; problēma sākas brīdī, kad piegādātājs vai pircējs noapaļo to līdz konkrētai dienai un pēc tam plāno budžetu pēc skaitļa, kura avotā nav. Vēl viena robeža, kas jāzina, pirms tiek izvēlēta versija: Laravel 13 prasa vismaz PHP 8.3, tāpēc sistēmu uz trīspadsmitās versijas nevar atstāt uz 8.2 pat tad, ja pati 8.2 vēl kādu laiku saņemtu drošības labojumus.

Ko abi kalendāri kopā nozīmē sistēmai, kuru pasūtāt šodien

Ja sistēma tiek nodota uz Laravel 13 kopā ar PHP 8.4 vai 8.5, tad pirmais datums, kurā kaut kam obligāti jākustas, ir 2028. gada marts, kad beidzas Laravel drošības labojumi, un tas ir aptuveni astoņpadsmit ar pusi mēneši no šodienas. PHP šajā salikumā nav ierobežojums, jo abi šie zari drošības labojumus saņem ilgāk nekā ietvars, tāpēc pirmais, kas noveco, ir Laravel, nevis valoda. Tas ir arī vienīgais godīgais veids, kā atbildēt uz jautājumu „cik ilgi šī sistēma nostāvēs bez papildu ieguldījuma“ — nevis ar sajūtu, bet ar agrāko no diviem publiskiem datumiem.

Ja tā pati sistēma tiek nodota uz Laravel 13, bet PHP 8.3, tad kārtība apgriežas otrādi un pirmais termiņš pienāk apmēram sešpadsmit mēnešos, kad beidzas šī PHP zara drošības labojumi. Ja piegādātājs raksta uz Laravel 12, kas esošam projektam joprojām ir pilnīgi normāla izvēle, tad drošības labojumi beidzas nākamā gada februārī, un jaunas sistēmas dzīve sākas ar sešiem mēnešiem līdz pirmajai obligātajai versijas maiņai. Starpība starp pirmo un trešo variantu ir gads, ko var nopelnīt vienā sarunā pirms līguma, un ko pēc paraksta vairs nopirkt nevar.

Divas kļūdas šajā rēķinā ir tik izplatītas, ka tās ir vērts nosaukt atsevišķi. Pirmā ir sajaukt pilno atbalstu ar drošības atbalstu, tāpēc dzirdot, ka „PHP 8.4 atbalsts beidzas gada beigās“, ir vērts pajautāt, kurš no diviem logiem ir domāts: beidzas parasto kļūdu labošana, bet drošības labojumi nāk vēl divus gadus. Otrā ir noticēt pašu Laravel teikumam, ka pāreja uz jaunu galveno versiju parasti aizņemot dienu vai mazāk; tas ir izstrādātāju formulēts mērķis, nevis izmērīts vidējais, un līgumā to kā termiņu ierakstīt nevar.

Licence maksā nulli, un tas ir patiesība tikai par valodu un ietvaru

Laravel ietvars tiek izplatīts ar MIT licenci, kas ir viena no vienkāršākajām atvērtā pirmkoda licencēm un ļauj kodu izmantot, mainīt un pārdot tālāk, prasot vien saglabāt autortiesību paziņojumu. Ar PHP ir nedaudz sarežģītāk, un šī sarežģītība tieši šobrīd ir aktuāla, jo licence mainās: versijas līdz 8.5 ieskaitot iznāk ar PHP licences 3.01 redakciju, bet sākot no 8.6 pāriet uz ceturto redakciju, kuru php.net pats apraksta kā „Modified BSD“ licenci un kura praktiski sakrīt ar BSD-3-Clause. Nevienā no šiem variantiem maksa nav paredzēta.

Tas nozīmē, ka par pašu valodu un pašu ietvaru uzņēmums nemaksā ne par lietotāju, ne par procesora kodolu, ne par gadu, un šī nulle nav akcija, kas kādreiz beigsies. Salīdzinājumam der modelis, ko izmanto Microsoft SQL Server: tur licencē vai nu pēc kodoliem, vai pēc servera kopā ar klientu piekļuves licencēm, standarta izdevums ir ierobežots ar mazāko no četrām procesoru ligzdām vai divdesmit četriem kodoliem, bet bezmaksas Express izdevums — ar vienu ligzdu vai četriem kodoliem. Precīzas summas šeit nerakstām, jo cenrādis mainās un tas ir jālasa pie Microsoft; pircējam salīdzināms ir modelis, nevis skaitlis — viens produkts rēķina pēc dzelzs apjoma, otrs nerēķina vispār.

Iepirkumā tam ir divas sekas, kuras der ierakstīt uzreiz. Pirmā ir patīkama: nav licenču audita, nav gada pārrēķina par lietotājiem, kuri pa gadu ir pieauguši, un nav situācijas, kurā programmatūras piegādātājs pēc trim gadiem atnāk ar rēķinu par pārsniegtu limitu. Otrā ir tā, kuru mēdz aizmirst: atvērtais pirmkods noņem atkarību no ietvara īpašnieka, bet nenoņem atkarību vispār. Atkarība pāriet uz citām vietām — uz aģentūru, kura vienīgā zina, kā projekts ir salikts, uz maksas produktiem, kuri stāv līdzās kodam, uz pamestu pakotni, kuru neviens vairs neuztur, un uz galveno versiju, kurai beidzies atbalsts. Šīs četras vietas ir tās, kuras pircējam ir jāpārbauda, jo licences rindiņa par tām neko nepasaka.

Kur Laravel tomēr sāk maksāt: produkti, kas nav ietvars

Tā pati komanda, kas uztur Laravel, pārdod arī vairākus produktus, un piedāvājumā tie mēdz stāvēt vienā rindā ar ietvaru, it kā būtu tā sastāvdaļa. Laravel savā mājaslapā šīs divas lietas nodala pats: pakotnes — Horizon, Telescope, Pulse, Scout, Sanctum, Octane un citas — ir MIT licencētas un bez maksas, savukārt produkti ir Cloud, Forge, Nightwatch, Vapor un Nova, un tie maksā naudu katru mēnesi vai katru gadu. Envoyer joprojām tiek pārdots atsevišķi. Neviens no šiem produktiem nav vajadzīgs, lai Laravel sistēma strādātu, un tieši tāpēc to klātbūtne piedāvājumā ir izvēle, nevis nepieciešamība.

Cenas šā gada augustā izskatījās šādi. Forge, ar kuru pārvalda serverus, maksā 12, 19 vai 39 ASV dolārus mēnesī atkarībā no plāna. Nova, kas ir administrācijas panelis, maksā 99 dolārus vienreiz par vienu projektu kopā ar gada atjauninājumiem un 79 dolārus gadā par atjauninājumu turpināšanu, bet neierobežotā licence maksā attiecīgi 299 un 249 dolārus, turklāt tā sedz Jūsu pašu projektus, nevis Jūsu klientu projektus. Nightwatch, kas savāc sistēmas notikumus, sākas ar bezmaksas plānu un kāpj līdz 20, 60 un 300 dolāriem mēnesī, pieskaitot piemaksu par notikumiem virs iekļautā limita. Laravel Cloud sākas ar 5 dolāriem mēnesī plus patēriņš, un Envoyer maksā no 10 līdz 50 dolāriem mēnesī.

Jautājums pircējam nav, vai šie produkti ir labi, jo parasti tie ir labi un ietaupa izstrādātājam vairākas dienas mēnesī. Jautājums ir, kuri no tiem ir iekļauti nosauktajā cenā, uz kura konta tie ir reģistrēti un kas ar tiem notiek, ja Jūs pēc diviem gadiem mainīsiet piegādātāju. Abonements, kurš stāv uz aģentūras konta un līgumā nav pieminēts, ir tieši tā atkarība, ko MIT licence nenoņem, jo MIT runā par kodu, nevis par kontu, kurā tas tiek izvietots un uzraudzīts.

Kas notiek, ja izstrādātājs pazūd

„Kodu var pārņemt jebkurš Laravel izstrādātājs“ ir teikums, kas ir juridiski patiess un praktiski nepilnīgs, un mēs to esam rakstījuši arī paši. MIT licence tiešām ļauj citam uzņēmumam ar šo kodu strādāt, neprasot atļauju ne mums, ne Laravel komandai. Vai jaunais izstrādātājs būs noderīgs jau pirmajā nedēļā, izlemj četras pavisam citas lietas, un visas četras var pārbaudīt, pirms līgums vispār ir parakstīts.

Pirmā ir galvenā versija. Nodošana no Laravel 11 uz jaunu komandu nav nodošana, bet versijas maiņas projekts, jo drošības atbalsts tur jau ir beidzies un pirmais darbs būs nevis jauna funkcionalitāte, bet nokavētās versijas maiņa līdz atbalstītam laidienam. Otrā ir attālums no ietvara noklusētās struktūras: Laravel dokumentācija pieņem noteiktu mapju un klašu izkārtojumu, un jo tālāk projekts no tā ir aizgājis, jo dārgāka ir iepazīšanās. Skaitļa šeit nav un nevienā avotā tāda nav, ir tikai virziens; toties pircējs var pilnīgi konkrēti pajautāt, kas projektā ir uzrakstīts pretēji noklusējumam un kāda vajadzība to prasīja.

Trešā ir atkarības, tas ir, svešās pakotnes, uz kurām sistēma paļaujas. Composer, kas Laravel pasaulē tās pārvalda, glabā failu ar precīzām versijām, un tas ir vērtīgs tieši tāpēc, ka jauns izstrādātājs var uzstādīt tieši to pašu, ko redzēja iepriekšējais, nevis to, kas šodien ir jaunākais. Ko šis fails negarantē, ir divas lietas: ka pakotne joprojām būs pieejama lejupielādei, un ka tajā kopš tā laika nav atrasta ievainojamība. Komanda composer audit abas parāda vienā izsaukumā, un tā ir īsākā jautājuma forma, kādu vispār var uzdot par svešu koda bāzi.

Ceturtā ir pamesta pakotne, un šeit vārdi maldina. Packagist, Composer publiskais katalogs, atzīmē, ka uzturētāji ir apstājušies, taču tas nenozīmē, ka pakotne pazūd vai pārstāj strādāt: swiftmailer joprojām tiek izsniegts, tam ir 449 miljoni reģistrētu uzstādīšanu, pēdējais laidiens ir no 2021. gada, un vienlaikus tam ir trīs zināmas ievainojamības. Mūsu pašu šīs vietnes koda bāzē, kas ir Laravel 13 kopā ar Filament administrācijas paneli, ir 109 ražošanas pakotnes un neviena pamesta — tas ir mūsu skaitlis par mūsu projektu, nevis nozares vidējais, jo publicēta nozares vidējā nav nekur.

Cik liels ir darba tirgus, un kāpēc precīzu skaitli neviens nepateiks

Uz jautājumu, vai Latvijā ir viegli atrast cilvēku, kas sistēmu pārņem, godīgā atbilde ir, ka publiska statistika par PHP vai Laravel izstrādātājiem Latvijā nepastāv. Ir netieši dati, un tie ir vērtīgi tieši tik, cik precīzi tos apraksta. JetBrains pērnā gada PHP aptaujā starp 1720 cilvēkiem, kuriem PHP ir galvenā valoda, 64% strādā ar Laravel, 25% ar WordPress un 23% ar Symfony; lauka darbs notika pavasarī, aptauja ir novirzīta par labu JetBrains rīku lietotājiem, ko uzņēmums atzīst pats, un lielākās respondentu grupas nāk no Japānas, ASV, Krievijas, Ķīnas un Francijas, nevis no Baltijas.

Eiropas līmenī Eurostat šā gada maijā ziņo, ka pērn Eiropas Savienībā strādāja 10,45 miljoni informācijas un komunikācijas tehnoloģiju speciālistu, kas ir 5,0% no visiem nodarbinātajiem un par 2,6% vairāk nekā gadu iepriekš. Par Latviju tā paša avota agrākajā apkopojumā ir cits skaitlis, kurš pircējam ir noderīgāks par kopējo pieaugumu: 2023. gadā tikai 4,48% Latvijas uzņēmumu meklēja vai mēģināja pieņemt darbā šādus speciālistus, un tas bija zemākais rādītājs visā Savienībā, savukārt starp tiem Eiropas uzņēmumiem, kuri meklēja, 57,5% vakanci aizpildīt nespēja.

Šie skaitļi ir par nozares speciālistiem kopumā, nevis par PHP, un tos nedrīkst pārrakstīt kā apgalvojumu par Laravel darba tirgu Latvijā — ne mums, ne piegādātājam, kurš tos citē Jūsu piedāvājumā. Mēs paši savā pakalpojumu lapā esam rakstījuši, ka izstrādātājus, kuri darbu pārņem, atrast ir viegli; gatavojot šo rakstu, avotu šim apgalvojumam neatradām, tāpēc šeit to neatkārtojam. Pircējam praktiskā secība tāpat ir cita: nevis ticēt tirgus lielumam, bet panākt, lai koda bāze būtu tāda, kurā jauns cilvēks ienāk lēti neatkarīgi no tā, cik tādu cilvēku ir.

Kur mēs paši velkam robežu piedāvājumā

Mēs rakstām uz Laravel kopš 2013. gada, kad iznāca tā ceturtā versija, un tas praktiski nozīmē, ka esam vairākas reizes gājuši cauri tieši tam, par ko šis raksts brīdina — galvenās versijas maiņai, kas nav vienas dienas darbs un ko nevar izdarīt starp citiem uzdevumiem. Mūsu Laravel sistēmu izstrādes lapā ir cena un termiņi, un tā ir atsevišķa saruna; šajā rakstā ir tikai tas, ko piedāvājumā var pārbaudīt neatkarīgi no tā, kurš to ir uzrakstījis un cik labi tas ir uzrakstīts.

Ko mēs neapgalvojam, ir tas, ka jebkurš izstrādātājs pārņem jebkuru koda bāzi vienlīdz viegli, jo iepriekšējā sadaļa saka pretējo. Ko mēs apgalvojam, ir konkrētāk un pārbaudāmāk: repozitorijs ir klienta no pirmās dienas, tajā ir gan atkarību fails, gan dokumentācija, gan izvietošanas konfigurācija, un nodošanas brīdī versija ir tā, kura tobrīd vēl saņem drošības labojumus. Ja Jums šķiet, ka izvēle patiesībā ir starp gatavu produktu un pasūtījuma sistēmu, tad tā ir cita saruna, kuru esam uzrakstījuši atsevišķi, un ja jautājums ir tieši par interneta veikalu, tad WooCommerce un Laravel salīdzinājums atbild precīzāk nekā šis raksts.

Praktiski nodošanas komplektā ietilpst repozitorijs ar visu vēsturi, atkarību fails ar precīzām versijām, README ar palaišanas soļiem, izvietošanas konfigurācija un piekļuves visiem kontiem, kuros sistēma darbojas. Tas ir tas, ko var apsolīt un pārbaudīt. Ko apsolīt nevar, ir tirgus: cik cilvēku Latvijā šo darbu paņems un par kādu cenu, nav mūsu rokās un nav nevienā publiskā statistikā, tāpēc mēs šo jautājumu neatbildam ar pārliecinošu skaitli. Vienīgais, kas šeit patiešām strādā pircēja labā, ir tas, ka koda bāze ir parasta, versija ir atbalstīta un dokumentācija ir uzrakstīta tobrīd, nevis atlikta uz nodošanas nedēļu.

Ko pajautāt, pirms parakstāt

Pirmais jautājums ir par datumiem: kura Laravel galvenā versija un kurš PHP zars būs sistēmā tieši nodošanas dienā, un kad beidzas to drošības labojumi. Atbilde ir divi datumi, tos abus var pārbaudīt divās publiskās lapās piecās minūtēs, un tie ir jāieraksta vai nu līgumā, vai vismaz sarakstē. Ja piegādātājs nosauc versiju, kuras atbalsts beidzas ātrāk nekā garantijas termiņš, tas nav aizliegts un dažreiz ir pat pamatoti, bet tad tas ir jāzina abām pusēm, un cenā ir jābūt saprotamam, kurš maksās par pāreju.

Otrais jautājums ir par abonementiem: kuri maksas produkti — Forge, Cloud, Nova, Nightwatch, Vapor vai Envoyer — sistēmas darbībai ir vajadzīgi, cik tie kopā maksā mēnesī un uz kura konta tie stāv. Trešais ir par repozitoriju: no kuras dienas tas ir Jūsu, vai tajā ir atkarību fails un vai automātiskajā pārbaudē ir iekļauta composer audit komanda. Ceturtais ir naudas jautājums, kuru parasti atliek uz vēlāku laiku un pēc tam pārsteigumā atrod budžetā: kurš maksās par galvenās versijas maiņu pēc pusotra gada un vai tā ietilpst uzturēšanas līgumā vai būs jauns pasūtījums.

Neviens no šiem četriem jautājumiem neprasa, lai Jūs saprastu kodu, un neviens no tiem nav uztverams kā neuzticēšanās piegādātājam. Tie visi ir par to, kas notiks pēc tam, kad projekts būs pabeigts un rēķins samaksāts, un labs piegādātājs uz tiem atbild uzreiz, jo pats šos datumus zina no galvas. Ja atbilde uz kādu no tiem aizņem nedēļu vai pārvēršas par paskaidrojumu, kāpēc jautājums nav svarīgs, tad tā jau ir atbilde.

Šie četri jautājumi neaizstāj tehnisko izvērtējumu un neatbild uz to, vai piedāvātā arhitektūra ir laba, bet tie novērš lielāko daļu no nepatīkamajiem pārsteigumiem, kuri parasti pienāk otrajā vai trešajā gadā, kad sākotnējais entuziasms ir beidzies un sistēma vienkārši strādā. Ja Jums ir piedāvājums rokās un neesat pārliecināts, ko tajā rakstītās versijas nozīmē Jūsu termiņiem un budžetam, uzrakstiet mums — atbildi uz šiem četriem jautājumiem var sagatavot, neatverot kodu.