Jump to content
php.lv forumi

Līgums


aika

Recommended Posts

  • 4 years later...

Pacelšu šo tēmu..

Vai ir  kādi online tūļi, ar kuriem modelēt tehnisko uzdevumu, proti, kur “mijiedarbojās” izpildītājs ar pasūtītāju. Es to esmu iedomājies tā, ka ir pa punktiem sarakstīti apakš uzdevumi, kuram klāt ieliktas bildes, apraksts, termiņš  utt…, kura, klāt izpildītājs ar [pasūtītāju raksta komentārus izpildes gaitā, precizējumus, utt. Bet nevis vienkārši darbu deleģēšana, bet tāda striktāka, konkrēta apakš uzdevuma izpildes fiksācija, kas būtu kā gandrīz kā līgums.

Cik pagūglēju, nekas prātīgs nelēca ārā, tik vien todo softi. Droši vien ka tādi ir un kaudzēm. Jeb visi tehniskie uzdevumi tiek uz papīra rakstīti?

 

Paldies. 

Link to comment
Share on other sites

Parasti tas notiek tā, ka puses vienojas par darba organizēšanu.

 

Nepastāv tāds mehānisms, kā "kaut kāda sistēma, kurā ievadītie uzdevumi kļūst par tādu kā līgumu". Darbs tiek paveikts tad, ja to dara, un to, lai tas tiktu izdarīts, nodrošina vienošanās un savstarpējā komunikācija. Ja vienošanās būs abām pusēm izdevīga, darbi tiks darīti, norunas tiks pildītas. Ja ar šo nesokas, tad problēma ir citur, nevis tajā, lai sistēmā būtu uzraksts, ka "katrs darba uzdevums ir tāds kā līgums".

 

Man nojauta liek domāt, ka risinājums būtu darbu organizēšanu uzticēt kādam citam. Izskatās pēc diezgan mazas pieredzes. Ātri saiesiet konfliktā.

Link to comment
Share on other sites

Parasti tas notiek tā, ka puses vienojas par darba organizēšanu.

 

Un kā tad Tu piedāvā vienoties? Uz akmens plāksnēm ķīļrakstā?

 

Nepastāv tāds mehānisms, kā "kaut kāda sistēma, kurā ievadītie uzdevumi kļūst par tādu kā līgumu". 

 

Super Quality Grade A Bullshit 916Aur

Link to comment
Share on other sites

Tu kas, diletants, vai?

 

Parasti līgumā ir atrunātas kontaktpersonas vai piebilde, ka darbu organizēšanai izmanto kaut kādu sistēmu. Tālāk jau katrs gadījums ir individuāls. Ja lieta tiešām nopietna, tad var vienoties par darba uzdevumiem, kas tiek noformēti rakstveidā un ir kā līguma pielikumi. Jira un tamlīdzīgie kā iniciators un kad vienojas par darāmo - top pielikums, puses paraksta, utt.

 

Īsi sakot, kā parasti. Ja jau strādāji terasē ar skatu uz Daugavu, tur tādām lietām bija jābūt ikdienai, ne?

 

Taču šāda apjoma projektiem budžeti ir tādi, ka šos jautājumus risina dedicated jurists. Ja tas jābaksta forumā, tur kaut kas īsti nav. Visdrīzāk - projekta nozīmīgums ir pārvērtēts vismaz 10, ja ne 100x. Tomēr diezgan pamatīgs "management overhead" un ja projekts ir <100k, tad kaut kas nav līdz galam saprasts.

Edited by Mr.Key
Link to comment
Share on other sites

nebiju  īsti domājis par tik strikti juridiskām lietām, vairāk tieši, lai abas puses konkrēti saprastu, kas tiek pasūtīts un kas tiek un tiks izdarīts. vienkārši meklēju kādu ērtu rīku, ar kuru fiksēt uzdevumu, lai pie tā var pieturēties, lai beigās nesanāk, ka pasūtītājs sāk- es to biju iedomājies savādā, man kaut kādas fīčās liekas pašsaprotamas un tās ir visās sistēmās utt.  procesa laikā,piemēram kaut kādam uzdevumam parādās jauna informācija, un manupāt, ar kādu no rīkiem, šo info smuki varētu vienkārsi sakārtot pie konkrētā uzdevuma, vai izstrādes posma... Proti, jebkurā posmā, abām pusē, ir maksimāla indormācija, kas tiks izstrādāts konkrētā posmā (cik nu maksimāli tas ir iespējams). 

 

vienā vārdā sakot, rīks, kurā ērti apkopo prasību informāciju, kas tiek izrunāta, pa ēpastiem sarakstīta, bet uz oficiāla papīra neuzlikta, un fiksēta darbu izpilde..., kaut vai, kamēr abas puses neapstiprina pirmā posma izpildi elektroniskā sistēmā, pie nākamā posma nemaz neķerās klāt. Bieži vien pasūtītājs izmet vispārīgas frāzes, ko vēlas redzēt, un saka, taisiet pēc saviem ieskatiem Kad uztaisīts, var sanākt, ka rezutāts nav īsti pa prātam, un tad sāk izvairīties, ka tieši to viņš nav teicis, lai taisa.... Es domāju, kad pasūtītājs redzēs, ka sistēmā pie kāda no uzdevumiem ir jāpieveino ir shēmas, skices utt, uz kuriem balstoties var kaut ko izstrādāt, pasūtītājs arī nopietnāk pieies uzdevumu definēšanai un abas puses būs ieguvējas, kas ir viens no galvenajiem mērķiem!
Link to comment
Share on other sites

Parasta uzdevumu parvaldiba, JIRA, Redmine. Janodala tik iekšējie izstrades uzdevumi un menedžmenta uzdevumi. Par katru feature kuru taisa, apraksts no izstrādātāja un apstiprinājums no klienta uzdevumu sistēmā (vai otrādi). Ja klients sāk mainīt iepriekš izrunātas un apstiprinātas lietas, tad tas viss iet pa maksu.  

 

Rezultātā visi redz kas ir apstiprināts, kas ir izstrādāts, kas nav vel izstrādāts, kas ir "in progress" etc. 

Edited by Blitz
Link to comment
Share on other sites

Alnis, tas viss ir skaidrs, bet Tev nav skaidrs, ka projektā pietrūkst sakarīga projektu vadītāja. Tu esi iedomājies, ka izmetīsi šo posmu un aizvietosi ar sistēmiņu, kas nesīs automātiskus panākumus. Nebūs! Gaidi ziepes un nepatikšanas.

 

Projekta vadītāja uzdevums ir vadīt komunikāciju ar klietnu, lai viņš saprot, kas tiks izdarīts, kas netiks, utml. Klasika - programmētājs ieurbies darbos, neatliek laika veselīgai komunikācijai, klients sāk nervozēt, programmētājs nemāk izskaidrot, cik daudz darba izdarīts, utml.

 

Gadās, ka gala rezultātā projektu pārņem citi, atnāk sakarīgs projektu vadītājs, klients priecīgs, tas nekas, ka viss maksā daudz dārgāk, toties process notiek. Tāpēc arī minēju, ka nevajag tēlot, ka esi iemeties lielbudžeta projektā un kaisīt pērles cūkām. Ak jā, vēl arī tas, ka jo maksātspējīgāks klients, jo vairāk tolerē ar realitāti un mazāk sagaida, ka projekts par <10k (vai pat 1k) būs shopify vai ebay līmenī.

 

Ne līgums, ne sistēma šo problēmu neatrisinās.

 

No pieredzes daudzos projektos, ar dažādiem klientiem, dažādos uzņēmumos - uzdevumu sistēma pati par sevi nenodrošina darbu izpildi. To nodrošina projekta vadība, kas seko līdzi, kas reizēm izskatās, ka vispār dara nevajadzīgas lietas, bet beigās izrādās, ka tās ir pat ļoti vajadzīgas. Projekta vadības daļa tāmē ir 10-20%. Katrā projektā pret to ir atšķirīga attieksme - ja vienā klienta pusē ar uzdevumu sistēmu strādās 3 cilvēki un rakstīs komentārus, citā projektā var gadīties, ka sistēmu lietos paši programmētāji sava darba organizēšanai, jo klients negribēs/nevarēs "lieku čakaru".

Edited by Mr.Key
Link to comment
Share on other sites

Kā jau Blitz minēja - pamēģini Jira, Redmine, Gitlab (teorētiski arī Github).

 

Pašam jāsaprot kādu rīku izvēlēties, proti, vai tas vairāk ir domāts (vairāk iespēju) tieši programmētājiem (faktiskie uzdevumi / bug reporti / koda repozitorijs / testi utt) vai kā reiz tiem pašiem projektu vadītājiem (sarakste ar klientu / kalendāra ieraksti utt).

 

 

Manuprāt Mr.Key nedaudz pārspilē projektu (pus)vadītāju lomu. Protams ir ērtāk, ja ar klientu iet runāties cilvēks (inviduāla pieeja galu galā) kuram ir komunikācijas dotības, taču tas nenozīmē, ka arī programmētājam tādas nevar būt un tad nav būtiski, kurš ir fiksējis uzdevumu.

 

 uzdevumu sistēma pati par sevi nenodrošina darbu izpildi. To nodrošina projekta vadība

Uz šo var skatīties dažādi - kā tad vadība pat par sevi to nodrošina? Vai tas domāts kā garantijas attiecībā pret klientu?

Jo nu produkta izstrādi jau tāpat veic programmētājs (u.c. faktiskā darba veicēji). Ja tas ir domāts kā skubināšana (vai ar pātagu), tad savādāk/bēdīgāk..

 

 

Klasika - programmētājs ieurbies darbos, neatliek laika veselīgai komunikācijai, klients sāk nervozēt, programmētājs nemāk izskaidrot, cik daudz darba izdarīts, 

Šādas sistēmas kā reiz (ja klientam arī ir piekļuve) vienkāršo komunikāciju - vai nu darbs ir pabeigts vai nav .. un nav vajadzības kādam braukt un taisnoties vai solīt, ka rīt no rīta viss nu tiešām noteikti būs (protams, reizēm iedzert (kafiju) ar klientu var būt noderīgi).

 

Pēc būtības jau lielākā daļa atvertā koda (un arī komerciālas) programmatūras strādā ar šādiem rīkiem / principiem, Tikai klients šajā gadījumā lielākoties ir "anonīms" lietotājs, kas piesaka savu "feature requestu" vai "bugu" un tad atkarībā no dažādiem kritērijiem tas tiek vai netiek izpildīts.

 

Neredzu arī iemeslu kāpēc tas nestrādātu attiecībā uz fiksētiem klientiem - klients vai projekta izstrādes puse saraksta visus veicamos darbus un prasības, kurus abas puses apstiprina / tās tiek pieškirtas konkrētiem darba veicējiem / klients un vadītāji vienmēr var kontrolēt kāds ir progress utt.

 

Advancētākas sistēmas kā Jira var veikt arī analīzi par patērēto laiku (ja tas ir būtiski) / salīdzināt to koda versiju kontrolēs sistēmas faktiskajām izmaiņām utt.

Liela daļa šo sistēmu nodrošina arī dažādu e-pastu / čatu u.c. integrāciju. Tāpat arī nekas neliedz šādās projekta/koda vadības sistēmās reģistrēt arī lietas, kas tieši neattiecas uz programmēšanu/kodēšanu, proti, sapulces / sarunu transkriptus utt.

Link to comment
Share on other sites

Roze, es pieķēros pie šī punkta "Bet nevis vienkārši darbu deleģēšana, bet tāda striktāka, konkrēta apakš uzdevuma izpildes fiksācija, kas būtu kā gandrīz kā līgums." Ar to sapratu, ka problēma ir pušu neizpratne par to, kas skaitās pabeigts vai nepabeigts, jo manuprāt, darbu deleģēšanas sistēmas piedāvā workflowus, kas atbilst projekta vadības vajadzībām. Ja nebija zināms par JIRA vai Redmine, tas arī automātiski rada jautājumus par to, kāda pieredze tad ir vispār? Kas vēl cits nav zināms? Visu, protams, var atrast un saprast, un laikam ejot, pierast. Šeit kaut kā cauri spīd tas, ka nevis programmētāji organizē savu darbu un projekta vadītāji netraucēti komunicē ar klientu caur saviem kanāliem, bet ka ir kaut kāda neskaidrība vispār. Lielākā plāksnē.

 

Par projekta vadītāja lomu - piekrītu, ka to var uzņemties arī programmētājs, taču nevajag novērtēt šo lomu arī par zemu. Ar to, ka nodrošina darbu izpildi, es domāju, ka ir nepieciešams vidutājs, kurš menedžē klienta ekspektācijas un neitralizē programmētāju pārliecību, piemēram, neļaujot sasolīt par daudz vai ierēķinot rezerves, kā arī krīzes gadījumā kaut vai vienkārši nomenedžēt overtaimu vai atgādināt par prioritātēm. Nē, es nedomāju skubināšanu un steidzināšanu, kaut gan arī tas reizēm var būt nepieciešams.

 

Es neesmu pārliecināts, ka programmētāji paši var sevi vadīt, vismaz ne attiecībā pret gala klientu. Ja tā ir tehniska komanda, kas darbojas lielāka projekta ietvaros kā struktūrvienība vai apakšuzņēmējs, tad jā. Bet jautājums, vai šī komanda nav jau kāda iepriekšēja projekta rezultāts, kas izgājis organizētu apmācību un treniņus. Atkal sanāk atgriezties pie tā paša - katra situācija ir savādāka.

 

Atvērtā koda projekti ir mazliet cits stāsts kā klienta projekts, kur klients no savas puses rēķinās ar sagaidāmu rezultātu un lielāku problēmu gadījumā sarunās iesaistās juristi vai vienkārši tiek stiepti norēķini. Tāpat, projekts, kur tehniskā nodaļa sēž uz algas un pilda citas nodaļas pasūtījumus, un kritiskais jautājums ir nevis par biznesa modeļa noturēšanu, bet par to, kā mazāk krist uz nerviem, ir cits stāsts.

 

Par pirmspēdējo un pēdējo rindkopu - iemeslu var būt ļoti daudz. Liek domāt, ka darbojies vidē, kur jau esi atfiltrēs no daudziem iespējamiem ekscesiem. Piemēram, ne visiem ir zināms vai pat saprotams, ka sapulces varētu protokolēt, utt. Vai zini, kāda ir sajūta, redzot neizpratnes pilnu lūgumu nesūtīt "kaut kādus protokolus"? :) Vai zini, kāda ir sajūta, kad esi 3 reizes pateicis, kas "tas nebūs", un tad saņemt jautājumu, vai tas jau ir uztaisīts? Es ar šādām lietām esmu saskāries kā programmētājs un redzējis, kā to risina projekta vadītāji, un patīkamāk to ir risināt komandā ar labu projekta vadītāju. Tāpēc arī šeit izsakos, lai aicinātu padomāt. Var jau būt, ka visur viss jau ir sakārtots, visi domā vienādi un atliek tikai uzinstalēt sistēmiņu, lai viss ietu pa sviestu.

 

Par tūļiem - bez minētajiem, tāpat projekta vadītāji izmanto Excel un epastu, Google Docs... anything, that works. Šajā gadījumā vērtīgi būtu palasīt grāmatiņas "Informācijas sistēmu projektu vadība", kur aprakstīts darba uzdevumu organizēšanas process (kad studēju, tādas noteikti bija), parunāties ar juristu (starp citu, nemaz nav dārgi un arī pašiem pašapziņa uzlabosies). Visdrīzāk, rezultātā līgums vai pielikums, kurā aprakstīta darba uzdevumu vadības plūsma, norāde uz sistēmas adresi, pieņemšanas - nodošanas kārtība. Piemēram, līgumos atrunā kontaktpersonas un e-pastus - tā nav informācija uzziņai, tā ir informācija par to, ka konkrētā kontaktpersona nevar pateikt "es neko nezinu", ja ir informēta par darbu norisi.

Edited by Mr.Key
Link to comment
Share on other sites

Meh, kur 2 latvieši tur 3 viedokļi. 

 

Realitātē, projektu organizācija ir atkarīga ne tikai no katra kantora, bet arī katra klienta un katra projekta. Ir 101 dažāds veids, kā tas viss tiek organizēts, un kā tiek risināta komunikācija starp klientu un izstrādātāju, un tas kā, tas tiek organizēts ir atkarīgs no klienta, projekta veida, izmēra, budžeta, utt. utjp. 

 

Lielais vairums LV mazo-vidējo projektu tiek organizēti 2 posmos - pamatprodukta izstrāde un pēc produkta apkalpošana. Pamatprodukta izstrāde parasti tiek organizēta saskaņā ar prasību specifikācijām. Prasību specifikācijas pievieno līgumam un tas ir izejas punkts, no kura izstrādātājs vadās lai sāktu vispār plānot kas un kā tiks organizēts, gan no resources management, gan no tehniskā viedokļa. Atkarībā no projekta izmēra, šīs specifikācijas var būt no pāris lapiņām līdz N mapēm ar dažādu funkciju specifikācijām, kas pamatā tiek pievienota līgumam - for the sake of having them there. Pamatprasības specifikācijās raksta lai noteiktu projekta izejas cenu. Būtu labi dzīvot paradīzē, kur visi klienti piekristu maksāt un strādāt pēc agile, taču realitāte ir tāda, ka tā tomēr nenotiek. Katra atkāpe no sākotnējās specifikācijas ir izmaiņa arī cenā un termiņos, vienā vai otrā virzienā.

 

Visa izstrāde pamata ir viens liels ball play - pakasi man muguru, un es pakasīšu Tev. 

 

JIRA utml. var izmantot lai uzdevumus reģistrētu - obviously. Manis augstāk minētā paša sistēma kas ražoja šīs specifikācijas patiesībā bija custom integrācija ar JIRA, kas izeksportēja backlogu, sākot no epikiem, beidzot ar subtaskiem, skaistā PDF ko var pēc tam pielikt līgumam - manuprāt, bezjēdzīgi, bet ja klients pieprasa or bust, tad ko darīt. Tādā pašā veidā ražojās arī tāmes, un izmaiņas ari tika organizētas tieši tā pat. Lielākiem projektiem klients pats varēja JIRA redzēt visu notiekošo, signoff uz epikiem un taskiem. Ik nedēļu or divas plānošanas mītiņi ar klientu lai saskaņotu prioritātes utml - pec vajadzības. 

 

Parasti instrumentus kā OP prasīja meklē vientuļie frīlanceri vai ļoti mazi kantorīši, kuriem trūkst vai nu pieredzes vai resursu lai to nomenedžētu. Būtu baigi forši, ja visi varētu algot projektu vadītājus, product ownerus, scrum menedžerus utt. utjp. Bet ņemot vēra, ka visā Baltijā ir varbūt 10-20 tāda izmēra kantori, kas to var arī atļauties, es šaubos vai OP un citi interesenti iekrīt šajā kategorijā. 

 

Ar galvu domāt vajag, Mr. Key, nevis pieņēmumiem. 

Link to comment
Share on other sites

ok,Mr.Key, tad kādus tūļus izmanto projektu vadītāji?

Depends. Sākot no visādiem Trello, Jive Producteev (ir labs maziem uzņēmumiem/frīlanceriem), JIRA. Ir kas strādā Basecamp, populāri ir arī Wrike un Redbooth. Trello, Producteev, Jira un Redbooth esmu pats lietojis.

 

Personīgi iesaku JIRA, ja var atļauties, vai Producteev ja nevar. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...