Sprendimai

IT konsultacijos ir sistemų projektavimas

Procesų analizė, reikalavimai ir architektūra prieš rašant pirmą kodo eilutę. Rezultatas yra dokumentas, su kuriuo galite eiti į pirkimą ar pas bet kurį kūrėją.

Aptarti poreikį Kaip dirbame

IT konsultacijos ir sistemų projektavimas - tai darbas, kuris vyksta prieš programavimą: išsiaiškinama, kaip procesas veikia šiandien, surašoma, ką sistema turi daryti, ir suprojektuojama, iš kokių dalių ji susideda. Rezultatas yra reikalavimų specifikacija ir architektūros sprendimas, pagal kuriuos sistemą gali sukurti bet kuris kūrėjas.

Kada verta pradėti nuo analizės

Yra keturios situacijos, kuriose analizė atsiperka anksčiau nei kūrimas.

Prieš pirkimą. Reikia paskelbti konkursą ar gauti kelis pasiūlymus, bet nėra dokumento, pagal kurį tiekėjai skaičiuotų tą patį.
Kai pasiūlymai nesulyginami. Trys tiekėjai atsiuntė tris skirtingas kainas ir tris skirtingas apimtis, o palyginti nėra pagal ką.
Kai projektas jau strigo. Sistema kuriama, bet apimtis auga kas mėnesį, nes iš pradžių nebuvo susitarta, kur ji baigiasi.
Kai neaišku, ar iš viso reikia sistemos. Procesas skauda, bet neaišku, ar problema yra įrankyje, ar pačiame procese.

Ką gaunate

Analizė baigiasi ne prezentacija, o rinkiniu dokumentų, kuriuos galima perduoti trečiai šaliai. Apimtis derinama pagal poreikį, bet standartinis rinkinys yra toks.

Procesų žemėlapis. Kaip darbas vyksta šiandien: kas ką daro, kur duomenys pereina iš rankų į rankas ir kuriose vietose jie perrašomi antrą kartą.
Funkcinių reikalavimų sąrašas. Ką sistema turi daryti, surašyta atskirais punktais, kuriuos galima priimti arba atmesti po vieną, o vėliau pagal juos testuoti rezultatą.
Nefunkciniai reikalavimai. Naudotojų skaičius, duomenų apimtys, prieigos teisės, saugumo ir prieinamumo reikalavimai, atsarginės kopijos. Dažniausiai pamirštama dalis, kuri vėliau lemia kainą.
Architektūros sprendimas. Iš kokių dalių sistema susideda, kur laikomi duomenys, kaip dalys kalbasi tarpusavyje ir kodėl pasirinktas būtent toks sudėliojimas.
Integracijų sąrašas. Su kokiomis esamomis sistemomis reikia jungtis, kokiu būdu ir kokie duomenys kuria kryptimi keliauja.
Techninė specifikacija. Dokumentas pirkimui arba pasiūlymų rinkimui, parašytas reikalavimais, o ne technologijų vardais.
Apimties ir etapų planas. Kas daroma pirmoje versijoje, kas atidedama, ir kokia to eiliškumo priežastis.

Kaip vyksta

Pokalbis apie kontekstą. Vienas susitikimas, kuriame išsiaiškiname, kas skauda ir kokį sprendimą jau svarstote. Po jo pateikiame analizės apimtį ir sąmatą.

Procesų interviu. Kalbamės su tais, kurie darbą atlieka kasdien. Ne su vienu atstovu, o su keliais iš skirtingų grandžių, nes tą patį procesą jie dažniausiai aprašo skirtingai, ir tie skirtumai yra svarbiausia informacija.

Esamų sistemų peržiūra. Žiūrime, kas jau veikia: apskaitą, skaičiuokles, el. parduotuvę, sandėlio programą. Dalis reikalavimų atkrenta, kai paaiškėja, kad funkcija jau egzistuoja ir tereikia integracijos.

Reikalavimų surašymas ir derinimas. Sąrašas peržiūrimas kartu su jumis ir dalijamas į tai, kas būtina pirmoje versijoje, ir tai, kas gali palaukti. Šis pokalbis dažniausiai ir nulemia projekto kainą.

Architektūra ir specifikacija. Suprojektuojame sistemos sandarą ir parengiame dokumentą. Pristatome jį gyvai, kad liktų aišku ne tik kas parašyta, bet ir kodėl.

Dokumentas rašomas jums, ne mums

Specifikacija būtų nenaudinga, jei ją suprastų tik jos autorius. Todėl reikalavimai rašomi funkcijomis ir rezultatais, o ne technologijų pavadinimais. Jei sprendimą lemia jūsų esama aplinka, pavyzdžiui apskaitos programa ar viešojo sektoriaus reikalavimai, tai įvardijama kaip apribojimas su paaiškinimu, o ne kaip mūsų pasirinkimas.

Praktiškai tai reiškia, kad su parengta specifikacija galite kreiptis į kelis kūrėjus ir gauti sulyginamus pasiūlymus. Jei paskui sistemą kuriame mes, atlikta analizė įskaitoma į kūrimo apimtį.

Viešojo sektoriaus pirkimams

Viešojo sektoriaus projektuose analizė turi baigtis dokumentu, kuris atlaiko pirkimo procedūrą. Techninė specifikacija rengiama funkciniais reikalavimais ir rezultato apibūdinimu, be nuorodų į konkrečius gaminius, prekės ženklus ar patentus, kurie sudarytų sąlygas vienam tiekėjui.

Prie to prisideda reikalavimai, kurių privatūs pirkėjai paprastai neturi: prieinamumas pagal WCAG 2.1 AA, asmens duomenų tvarkymo reikalavimai ir dokumentų saugojimo terminai. Juos surašome kartu su funkcijomis, o ne paliekame tiekėjo nuožiūrai.

Ko ši paslauga neapima

Nekonsultuojame dėl serverių administravimo, darbo vietų priežiūros ar kompiuterių tinklo, nors Lietuvoje šie darbai irgi vadinami IT konsultacijomis. Mūsų sritis yra programinė įranga: procesai, duomenys, reikalavimai ir sistemų sandara.

Jei reikia įvertinti veikiančią svetainę, o ne suprojektuoti naują sistemą, tam yra atskiras nemokamas svetainės auditas.

Projektas su specifikacija ir be jos

Tas pats projektas, du skirtingi startai.

Kas vyksta	Be specifikacijos	Su specifikacija
Pasiūlymų palyginimas	Trys kainos už tris skirtingas apimtis	Tos pačios apimties kainos
Apimties augimas	Paaiškėja kūrimo metu	Sutarta prieš pradedant
Atsakomybė už spragas	Ginčas, ar tai buvo užsakyme	Punktas arba yra sąraše, arba ne
Tiekėjo keitimas	Naujas kūrėjas pradeda nuo nulio	Perduodamas dokumentas
Testavimas	Tikrinama pagal nuojautą	Tikrinama pagal reikalavimus
Biudžeto tikslumas	Vertinimas iš patirties	Skaičiavimas iš apimties
Viešasis pirkimas	Rizika dėl pretenzijų	Funkciniai reikalavimai be prekės ženklų

DUK

Dažniausiai užduodami klausimai

Kuo IT konsultacijos skiriasi nuo sistemos kūrimo?

Konsultacijų rezultatas yra dokumentai, o ne veikianti programa: procesų žemėlapis, reikalavimų sąrašas, architektūros sprendimas ir techninė specifikacija. Su jais galima skelbti pirkimą, lyginti tiekėjų pasiūlymus arba pradėti kūrimą. Kūrimas yra atskiras etapas, kuris po analizės gali ir neprasidėti.

Ar galiu specifikaciją atiduoti kitam kūrėjui?

Taip. Specifikacija priklauso jums ir rašoma taip, kad ją suprastų bet kuris kūrėjas. Joje neminimos technologijos, kurios susietų jus su vienu tiekėju, nebent tokį apribojimą turite patys, pavyzdžiui esamą apskaitos sistemą ar viešojo sektoriaus reikalavimą.

Kiek trunka analizė ir nuo ko priklauso trukmė?

Vieno proceso analizė paprastai trunka 2-3 savaites, kelių susijusių procesų su integracijomis - 4-6 savaites. Trukmę lemia ne sistemos dydis, o kiek žmonių dalyvauja procese ir kiek skirtingai jie tą patį darbą aprašo.

Ką reikia paruošti prieš pirmą susitikimą?

Nieko rašyti nereikia. Užtenka žinoti, kas procese dalyvauja ir kokiomis programomis šiandien naudojatės. Naudinga, jei galėsite parodyti realius dokumentus: skaičiuoklę, kurioje viskas laikoma, arba sąrašą, kurį kas savaitę tenka perrašyti ranka.

Kas dalyvauja iš įmonės pusės?

Kalbame su tais, kurie procesą vykdo kasdien, ne tik su vadovais. Dažniausiai tai 3-6 žmonės iš skirtingų grandžių. Sprendimus dėl apimties priima užsakovo atstovas, bet reikalavimai renkami iš tų, kurie sistema naudosis.

Ar rengiate technines specifikacijas viešiesiems pirkimams?

Taip. Specifikacija rašoma funkciniais reikalavimais ir rezultatais, o ne konkrečiais gaminiais ar prekės ženklais, kaip reikalauja Viešųjų pirkimų įstatymas. Tai leidžia išlaikyti konkurenciją tarp tiekėjų ir nesukelti pretenzijų dėl diskriminavimo.

Ar galite įvertinti gautus tiekėjų pasiūlymus?

Taip. Turint reikalavimų sąrašą, pasiūlymus galima lyginti pagal tą pačią skalę: ką kiekvienas tiekėjas dengia, ko nedengia ir kur kaina apima ne tą apimtį. Be bendro sąrašo trys pasiūlymai paprastai būna trys skirtingi projektai.

O jeigu analizė parodys, kad naujos sistemos nereikia?

Toks rezultatas irgi yra rezultatas. Dalis problemų sprendžiama esamos sistemos nustatymais, viena integracija arba proceso pakeitimu be programavimo. Tai pasakome, nes tai pigiau nei pusės metų projektas, kuris tos pačios problemos neišsprendžia.

Ar analizė kainuoja atskirai, jei paskui sistemą kuriate jūs?

Analizė yra atskiras etapas su savo apimtimi ir sąmata. Jei po jos pereinama prie kūrimo, atlikta analizė į kūrimo apimtį įskaitoma, nes projektavimo darbo nereikia kartoti.