Informācijas sistēmu izstrādes līgumi – Agile līgumi fiksētas cenas iepirkumos (apraksts)

Pamata principi, ko cenšos ielikt fiksētās cenas (tas ir Latvijas standarta iepirkumu veids) līgumos par IT sistēmu izstrādi. Pēdējā gadā, liekas, ka šie principi parādās arī iepirkumos, ko organizē citi, tāpēc liekas, ka prakse var būt noderīga arī citiem. Protams – metode strādā tikai tad, ja Klienta pusē ir spēcīgs projekta vadītājs.

1. Izstrādātājam tiek dotas NE VAIRĀK kā 30 dienas, lai izveidotu vidi, veiktu analīzi un uzzīmētu arhitektūru nākamajai sistēmai.
2. Pēc pirmā mēneša līgumam tiek pievienots pielikums, kas satur pilnu sarakstu ar lietām, kas projekta ietvaros tiks izdarītas.
3. Visi darbi tiek sadalīti 1 MĒNESI garos gabalos, katra mēneša beigās saņemot GATAVU, NOTESTĒTU un apskatītu sistēmas daļu.
4. Samaksa par darbu ir 40% par piegādāto gabalu (iterāciju) un 60% aiziet uz projekta beigām.
5. Tiesības lauzt līgumu 1 mēneša laikā un soda nauda ir 50% no neizdarītā apjoma. Tas nozīmē, ka ja uz darbu izpildi piesakās Izstrādātājs, kas nav spējīgs ātri uzsākt strādāt, viņš piemaksā 10% par to, ka nesaprata to, ko dara.
6. Projekta beigās vienmēr plānojam 2-3 mēnešus garu periodu sistēmas pārtaisīšanai, lai viss strādātu labi (kopējais refactoring).
7. Neviens projekts nedrīkst būt garāks par 10-12 mēnešiem kopā. Ja tas liekas garāks, to ir jādala vairākos pilnīgi neatkarīgos projektos katram ar savu dzīves ciklu.

Pieeja ir laba, jo ļauj ātri ieraudzīt virzienu, kurā plāno iet Izstrādātājs un savlaicīgi koriģēt, ja kaut kas ir pilnīgi nepareizi. Izstrādātājam savukārt tā dod iespēju “fiksēt”  kādu daļu no sistēmas salīdzinoši ātri, līdz ar to viņam nav risku, ka beigās nododamā sistēma neatbilst vajadzībām. Klientam tas dot garantiju, ka beigās būs vismaz kaut kas, līdz ar to samazinās vēlme prasīt visas iespējamās lietas jebkuram dzīves gadījumam, tātad samazinās nevajadzīgās sistēmas prasības.  Parasti rezultāts izdodas daudz labāks nekā, ja projekts tiktu būvēts plānojot visu no sākuma, jo tās iterācijas, kas ir nodotas, parasti ir ļoti skaidri redzamas un Pasūtītājs var precizēt savas vajadzības redzot kaut ko gatavu un strādājošu. Parasti tas palīdz ļoti.

Nākamajā postā pievienoju tipisku līguma līgumu, kas ir izveidojusies strādājot ar dažādiem izstrādātājiem.