Projektu izstrādes stils Jānis Rubļevskis (koko) / 24.10.2006. 07:00 / #Datori / 7 komentāri

Kamēr dzeru kafiju, izdomāju ilgi kultivēto sāpi izteikt arī jums, mani mīļie, mazie draudziņi!

Stāsts būtībā nebūs par maniem tiešajiem pienākumiem. Stāsts būs par to, ka biežāk tiešie pienākumi aprobežojas tikai ar kādiem 30% no kopējā darba apjoma, kas noved pie nesaprašanās daudzu iesaistīto pušu starpā. Bet nu par visu pēc kārtas.

Programmatūras izstrādes procesam jābūt rūpīgi noteiktam un sadalītam dažādās pakāpēs, izmantojot dažādus programmatūras izstrādes modeļus, piemēram, visvienkāršāko, taču laika gaitā par ļoti labu atzīto Ūdenskrituma modeli. Var jau izmantot arī citus modeļus. Pamatā modeļa izvēle ir atkarīga no firmā pieņemtajiem standartiem un izstrādājamā produkta tipa, kā arī termiņiem.

Konkrētajā gadījumā pieņemsim, ka mums ir visai abstrakts projekts - uzstaisīt programmiņu, kas lietotāja datnes novieto uz servera un ļauj arī tās atgūt atpakaļ, izmantojot autorizēšanos.

Tālāk stāstīšu pa posmiem, vienlaicīgi pastāstot no viedokļa, kā būtu labi un kā ir patiesībā.

1) Pirmais posms mazam projektam varētu būt tikšanās ar pasūtītāju. To darītu marketinga menedžeris vai kaut kas tamlīdzīgs. Noskaidrotu aptuvenos pasūtītāja priekšstatus, pastāstītu aptuveno situāciju vispār tirgū un uzzinātu visus par un pret un vai vispār sadarbosimies. Šis posms daudz maz vienmēr ir bijis līmenī - vienmēr var atrast klientu, kam kaut ko vajag un kas ir gatavs maksāt.

2) Otrais posms - detalizētas specifikācijas izveidošana. Šajā posmā tad beidzot vajadzētu iestaistīt sistēmas analītiķi. Mazās firmās pirmo posmu, sistēmas analītiķa darbu un projekta vadītāja darbu varētu pat apvienot šī viena persona, kurai tad par to visu būtu arī visvairāk jāmaksā. Šajā [otrajā] posmā analītiķim neskaitāmas reizes jātiekās ar klientu, jāpiedāvā savi risinājumi, jāuzklausa klienta viedoklis un jāanalizē. Pēc kārtējās analīzes atkal tikšanās ar klientu un atkal analīze. Kad klients pilnībā ir apmierināts ar šo analīzi un neskaitāmām lapām specifikācijas, kas ietver gan procesu aprakstus, gan ievaddatus, gan izvaddatus, gan sistēmas funkcionālās, gan nefunkcionālās prasības, tad abpusēji tiek parakstīts, ka pēc šīs specifikācijas tiek veidota programma.

Diemžēl mūsu apstākļos lielākoties mazajos uzņēmumos ar klientu sākotnējā stadijā satiekās tikai 2 vai 3 reizes, lai noskaidrotu, ka vajag projektu, lai iedotu tāmi un, lai parakstītu līgumu par šī unikālā projekta izstrādi.

3) Trešajā posmā analītiķim jāsadarbojas ar dizaineri, kas pēc specifikācijas izstrādā dizainu. Pēc skiču izstrādes dizaineris kopā ar analītiķi atkal satiekās ar pasūtītāju un viņi tur meņģējas tik ilgi, kamēr visi ir apmierināti.

Mūsdienās vispirms top dizains un dizains arī nereti top izmantots kā specifikācija (tiesa gan te jau ir tā problēma, ka bildītē nav rakstīts, ka konkrētie dati var saturēt tikai 100 simbolus vai tamlīdzīgi).

4) Posms - analītiķis tagad dodās pie programmētāja, iedod detalizētu specifikāciju, iedod saskarni un saskarnes aprakstu (labākajā gadījumā pie attiecīgām tehnoloģijām tiek iedota jau arī izveidota saskarne, kuru vienkārši jāapšuj ar kodu).

Kas ir mums? Mums vienkārši tiek iedots dizains un pateikts - tev jāuztaisa datu apmaiņas sistēma. Var sūtīt failus un var dabūt failus. Cilvēkam ir jāielogojas. Te tev būs dizains. Un tev vajag, lai dati glabājas uz linux, bet pieeja no Windows.

5) Piektajā posmā ir pabeigta sistēma. Tā ir arī praktiski notestēta un tiek dota izvērtēšanai. Pēc attiecīgas vienošanās, ja specifikācijā tas neko radikālu nemaina, tiek ieviestas arī nelielas izmaiņas. Un atkal saskarsme starp pasūtītāju un uzņēmumu ir analītiķis. Pēc tā seko dokumentu parakstīšana un īsā laikā viss ir uzbliezts uz URRĀ.

Rezumē: Nevis programmētāji mums ir deficīts. Deficīts ir tieši sistēmas analītiķi, jo sistēmas izstrādē 2/3 daļas aizņem analīze, un tikai 1/3 programmēšana. Realitāte ir tāda, ka programmētājam jākļūst par analītiķi. Programmētājam nereti arī jākļūst par dizaineri. Un lielākās problēmas ir tādas, ka programmētājs nav radīts tam, lai runātu ar klientu, kas beigās noved pie gatava produkta 10 un vairāk reizes.

Tagad ar to pašu piemēru mēģināšu to visu paskaidrot:

Pirmajā [kā vajadzētu būt] gadījumā: pie programmas atrādīšanas, tā ir gandrīz gatava un tur radikālas izmaiņas nevar tik ieviestas.

Otrajā gadījumā: pirmā atrādīšanas reize. Atnāk pasūtītājs. Rādam programmu, kur cilvēks var ierakstīt paroli un nosūtīt uz serveri datus. Tā pat var dabūt atpakaļ. Tomēr pasūtītāju tas neapmierina. Tā jau sanāk, ka visi tiek pie visu datiem. Vajag, lai būtu katram lietotājam sava mapīte, kas nozīmē, ka mums nebūs viena parole, bet būs daudz lietotāju ar daudzām parolēm, kas nozīmē, ka strādāsim vēl kādu laiku.

Nākamā reize - o - kruta - ir lietotāji, bet saglabājas viss vienā mapē. Mums tak baigi jāmeklē - jāparedz iespēja pievienot un dzēst mapes, jāparedz iespēja kārtot pēc datumiem utt... Un atkal notiek pārstrāde...

Beigās sanāk tā, ka neatmaksājas programmētājam to visu darīt n-tās reizes. Viņam tas projekts piebesīs un nekad pasūtītājs nebūs apmierināts. Lētāk ir nolīgt sistēmas analītiķi un nemocīt nabaga programmētāju ar darbiem, kas nebūt nav jādara viņam

P.S. Tas viss tikai no manas personīgās pieredzes un gūtās izglītības. Ja kaut kas nepatīk, tad, lūdzu, argumentēti izsakiet savu viedokli komentāros.

Komentāri:

Nu pasāpini mani - tu jau gribi:

* Visi lauki (izņemot tavu lapu) aizpildāmi obligāti!
E-pasts publiski netiks parādīts.
Zinot vairākumu, komentāros tagi netiek atrādīti kā tagi. Linki automātiski pārveidosies par spiežamiem (cerams).
Bloga īpašnieks patur tiesības ļaunus komentārus dzēst vai pārveidot cilvēkiem patīkamākā formā, bet tajā pašā laikā neatbild par komentāru saturu.