Drupal speciālista atalgojums ?

niklavs Thu, 04/12/2012 - 23:05

Čau, man te ir viens jautājums.
Kādas varētu būt atalgojums drupal speciālistam ar sekojošiem kritērijiem:
Satura izveide, bloku izveide un to izkārtojums. Spēj sadarboties ar dizaineri lai panāktu labākos rezultātus.

Būšu priecīgs par jebkādu info :)

Man grūti teikt par tavu kritēriju vērtējumu, bet vispārīgi intervāls droši vien būtu - no 200-1000 Ls. Galvenie aspekti: - kādas ir tavas kopetences un spējas, pieredze ar Drupal - kādas ir darba attiecības - freelancers, algots darbs (nodokļus maksā/nemaksā), mikro uzņēmums - uzņēmuma, kurā strādā - uz kādu tirgu strādā - LV/Eiropa/ASV?
Paldies par atbildi. Kā noprotu ar nelielu pieredzi drupal pārzinim varētu piedāvāt sākuma algu ap 3ls stundā ? Un kā ir ar tādiem cilvēkiem Latvijā , cik bieži viņi ir sastopami ? Mēs nedaudz sadarbojamies ar Indiju, bet kvalitāte mūs nevisai apmierina takā apsveram domu kaut ko sākt Latvijā!
Es piebilstu tā, ka jo zemāks atalgojums, jo tālāk cilvēks ir no Drupal, un, iespējams, var sīkus darbus darīt ar jebkuru CMS, jo tā pat viņam tā nav zināma. Tā pat viss ir jāmācās un jāapgūst. Savukārt tas, kurš jau ir patērējis laiku un iepazinis Drupal, jau būs dārgāks. Cik - atkarībā no apstākļiem un vienošanās. Bet ideja viena. Ja cilvēks pēc rakstura labs un apķērīgs, un ir vēlme viņu algot kā darbinieku, tad var apjaust no vietas, kur viņš dzīvo. Rīgā ir dārgāka dzīve, nekā citur. Tas, protams, ja iedziļinās viņa ādā. Savukārt, ja to pārvērš stundu likmē, tad te ir divi jautājumi: - tieši par kurām stundām tiek maksāts. Parasti Drupal prasa izpēti un izprašanu, un, vismaz no manas saskarsmes, klienti par to negrib maksāt. Tātad maksa ir par patieso darbu, nevis par izpēti (ja nav atrunāts savādāk). - ja tas ir freelance, tad vis ticamāk, ir arī citi darbi, kur kalendārās stundas/dienas nav vienādas ar faktisko patērēto laiku konkrētam projektam. (šis gan vairāk ietekmē kopējā projekta ilgumu) Bloku un satura izveidei īsti sakara ar Drupal nav. Tur drīzāk varētu būt vajadzība pēc cilvēka, kas pārzin HTML un CSS (atkarībā, protams, no risinājuma). Tas ir tā pat, kā kādam lūgt informāciju vadīt lapā. Bet ja ir saistība ar dizaineri - tad jautājums kādā līmenī. Ja lietas skar satura dokumenta izkārtojuma nianses - vienkārši. Ja lietas ir saistītas ar ādiņas korekcijām, utt., tad gan Drupal zināšanas vajadzētu, noderēs. Ja šis projekts ir saistīts ar Freelancing pielietošanu, tad te ir jārunā ar pašu cilvēku, kas to apņemas izpildīt. Man pašam personīgi riebjas tādi klienti, kuri saka - tur nekas nav jādara, un es par to maksāju tik un tik. Bet patiesībā darāmā ir daudz, un vēl klāt nāk Drupal. Tāpēc cena ir jānosaka izpildītājam, kur pasūtītājs var to pieņemt vai noliegt. Otrs - diskusija ar freelance palīdz saprast viņa darba stilu. Ir tādi, kas saka - 10Ls/h un iekļauj visās stundās tādas lietas, kā domāšanu, meklēšanu, risinājumu izveidi. Bet ir tādi, kas saka 40Ls/h, bet domāšana, meklēšana, risinājumi - uz viņa rēķina, kur samaksa tiek veikta par darba stundu, kad šie risinājumi faktiski tiek iviesti/pieskaņoti. Jo vairāk iet uz mēneša algu/garantētiem ieņēmumiem x periodā, jo stundu likme ir zemāka. Jo vairāk virziens ir uz ātru īslaicīgu risinājumu, jo stundas likme var būt stipri pat augstāka. Un citā brīdī arī pamatoti, jo cilvēkam ir jāiedziļinās, kas un kā ir jau izdarīts. Ir liekie darbi un laiks, kad jānoskaidro apstākļi, lai padarītu darbu. Indija - pats neesmu gan darbojies, bet tur, cik man pazīstami cilvēki ir minējuši, ir divi klupšanas akmeņi, kurus zinot, ir iespējams pietiekoši efektīvi strādāt. - neuzkāpt uz grābekļa - respektīvi, tiecoties pēc zemākas cenas, nepaņemt kantori, kas vienkārši "met"; - Indija dod precīzi to, ko tu prasi. Respektīvi - kā man kolēģis nokomentēja - strādā ātri, lēti, precīzi un labi, bet cieši ar pasūtījumā vai specifikācijā norādīto. Neko +/- pa labi vai kreisi, kā tas ir pierasts LV. Atslēgvārds - specifikācijas precizitāte!!! Šis jautājums mani pēdējā laikā dikti nomāc. Klienti pasūta lietas, zinot ko viņi grib, un uzreiz definējot cenu. Ja arī piekrīti šajā cenas kategorijā, saki, ka nekas cits netiks darīts, kā tikai tas, ko klients ir izvēlējies. Diemžēl, reālā dzīve ir cita, un bieži klients maina savas domas, par to nevēloties piemaksāt. Tādēļ domāju, ka cenas specifikācija no pasūtītāja puses ir nepareizs gājiens. Arī pasūtītājs sevi māna. Ceru, ka šīs domas noderēs.
Man vienmēr prieks lasīt Jāņa atbildes! Paldies par plašo izklāstu! Savā ziņā atslēgas vārds ir "specifikācija" projektam, vismaz gadījumā, ja plāno veikt "body shopping" jeb pārdot cilvēkresursus uz ārpasauli (skan nedaudz labāk! :D). Problēma tikai tajā, ka specifikācijas ar vien vairāk un vairāk izmirst. NAV iespējams realizēt projektu, kurš mērāms cilvēkmēnešos ar skaidri un detalizēti izklāstītu specifikāciju. Projekta virzībai un attīstībai jāseko līdzi un to ir jāveido līdz ar izstrādi. Vairs nedzīvojam laikos, kad 3-6 mēnešus uzrakstam specifikāciju, 3-6 mēnešus veicam izstrādi pēc šīs specifikācijas un beigās brīnumainā kārtā iegūtu produktu, kurš būtu aktuāls, strādājošs un derīgs biznesam. Tāds produkts būtu bijis aktuāls +/- vienu gadu atpakaļ, bet ne uz to brīdi, kad tas ir beidzot palaists. Ir labs raksts par to vai Drupal darbu var kvalitatīvi veikt no attāluma. http://mearra.com/blogs/vesa-palmu/can-you-offshore-drupal-work Pilnībā Vesas viedoklim es nepiekrītu, jo uzskatu, ka ir iespējams arī veikt kvalitatīvu eksportu, iesaistoties projekta būtībā, klienta biznesa vajadzību izprašanā un arī attālums šobrīd ir relatīvs, ja projekta izmaksās iekļauj pāris vizītes pie klienta un tas joprojām ir konkurētspējīgi, tad kāpēc lai to nerealizētu? Domāju tas ir pieejas jautājums, tāpat kā projekta realizācijai kā tādai. Ir arī piemeri pasaulē, kur tas strādā! Dcon London klausījos sesiju, kur stāstīja par The Economist izstrādi. http://london2011.drupal.org/conference/sessions/economist-informal-tec… Projektu realizēja vairākas komandas dažādos kontinentos un projekts ir veiksmīgs! Tākā lielā mērā panākums atkarīgs no pieredzes, to cik veiksmīgi tiek realizēta projekta vadība un kāda ir klienta iesaistīšanās projektā (klienta - izstrādātāja sadarbība/atbildība) u.c.
Jāatvainojas, ka off-topic, bet specifikāciju lieta mani pēdējā laikā dikti satrauc. No vienas puses saprotu, ka klients speceni neuzrakstīs. No otras puses - kamēr nav specenes, nevari izvērtēt laiku un pateikt ciparu. Tajā pat laikā uzrakstīt speceni, tas ir darbs, laiks, zināšanas, iedziļināšanās projektā, utt., par ko neviens (nu izņemot lielos projektus) faktiski negribēs maksāt. Kā būt? Klientu budžeti spiež, un spiež arī frīlanceri, kas ir gatavi paņemt projektu par jebkuru cenu, pat neapzinoties to, kas pēc tam vēl būs jādara. P.S. Apsveicu ar Normunda iegūšanu :)
:) Paldies par apsveikumu! Mums arī prieks par Normunda pievienošanos! :) Mēs ticam Agile un Scrum pieejai un pēc tām arī vadāmies. Ne vienmēr klientam tās ir izprotamas un viņš arī tās akceptē, bet daudz ko no tā viņi ir gatavi ļoti labprāt pieņemt, jo patiesībā tas ir tas ko viņi arī dara - negrib rakstīt specifikāciju un vēl mazāk grib pieturēties pie specifikācijas un saprotams, ka veic izmaiņas projekta izstrādes gaitā. Tas ko mēs daram: 1. Maksimāli mēģinam izglītot klientu par Scrum pieeju un klienta iesaistīšanos un atbildību projekta izstrādē. 2. Detalizētāka priekšizpēte. Jā klients par to visbiežāk arī nesamaksās, bet lētāk ir novērtēt darba apjomu, ko grasies veikt nekā pēc tam saprast ka esi pamatīgi "ieberzies" un ne pats laimīgs ne klients laimīgs, ne rezultāts sanāks. 3. Ja klients akceptē un izprot to visu, tad viņam jābūt arī izpratnei par to, ka tas ko tu esi līdz šim darījis ir darbs un ka tas arī ir jāiekļauj projekta budžetā. Protams ja tavs vērtējums nav derīgs tāpēc ka freelancers to izdarīs 5-10x lētāk, tad neko darīt. Jāļauj arī kļūdīties! ;) Piesaistot šo pie tēmas - ir sarežģīti šādu procesu pārdot kā pakalpojumu, ja neesi ciešā kontaktā ar klientu, kas ir viena no problēmām cilvēkresursu eksportam. Bet kā teicu - ticu ka tas ir pieejas jautājums.
Process ir svarīgs. Specifikācijas ir ūdenskrituma procesa sastāvdaļa. Ja šis process tiek ieviests pareizi, tas arī var būt ļoti sekmīgs. Cits jautājums ir, ka tas nav lēts process. Un tas nedraudzējas ar ātrām izmaiņām. Bet kā zināms, pasūtātājiem patīk veikt izmaiņas. Tad mēs nonākam pie Agile procesa. Tajā ir savi veidi kā aprakstīt un novērtēt vajadzības (stories, storypoints), savā ziņā arī tā ir specifikācija. Ja Agile tiek sekmīgi ieviests, tad to var veiksmīgi izmantot izmaiņu kontrolei. Agile ir labākais process priekš Drupal izstrādes, jo Drupal ir perfekts rīks, lai ātri dabūtu strādājošu demonstrējamu sistēmu, īsās iterācijās kas ir Agile stūrakmens. Kaut gan atsevišķām lietām (specifisku moduļu izstrādei) ir vajadzīgas formālākas specifikācijas (dokumentācija). Īsumā, ja abas puses saprotas un vienojas par spēles noteikumiem (un kāpēc tādi pastāv), tad viss būs labi. Tas ir mūsu pienākums, labi apgūt un īstenot piemērotāko procesu un apmācīt arī klientu kā tas darbojas un kādi ir viņa pienākumi.
Pateicos par Ernesta un Miķeļa komentāriem, bet runāšu kā man ir bieži klients teicis. Es no tā visa neko nesaprotu. Pasaki, cik man gala rezultātā tā lapa izmaksās! :)))) Visa teorija "nokrīt" :)
Iespējams atslēgas vārds ir tā izglītošana. Tajā droši vien var iegūldīt bezcerīgi daudz, bet noteikti k-kad tas arī atmaksājas. Ja klients nav gatavs izglītoties (iedziļināties problēmas būtībā un attiecīgi kopīgi atrast labāko risinājumu), tad: a) Tu vari vienkārši prasīt daudz naudas tādā veidā mazinot savu risku b) Tu vari uzņemties risku uz sevi un ticēt/cerēt - būs jau labi c) Tu vari teikt - sorry šoreiz mums nesanāks sadarboties [es neesmu gatavs uzņemties risku] d) Mēģināt rast balansu k-kur pa vidu starp augstāk minētajiem Tā ir atbilde uz 8# Jāņa komentāru :) kāds brīvā brīdī varētu piestilot lai atbildes uz komentāriem rādās smukāk/saprotamāk ;)
Lielākajai daļai Drupal projektu diez vai vispār vajag lauzīt galvu par speceni priekš izmaksu novērtēšanas. Pieredzējis drupal koderis galvā uzrēķinās kādi moduļi jau būs gatavi, ko vajadzēs hookot un kur var sanākt čakars. Kas attiecas uz oriģinālo jautājumu - nosauktie kritēriji diez vai atbilst Drupal specam. Tobiš, vai vajag keksi, kas var gatavas lietas salikt kopā un templeitus pabakstīt, vai arī runa iet par izstrādi, kur bāze ir drupal (formu api, hooki, pieredze ar cck/views iekšām). PHP koderus zinu daudz, tādus kas cērt drupal internāļus - maz.
Es piekrītu r21vo domu gājienam (par specifikāciju), taču to vairāk attiecinu uz pašu izstrādātāju. Tas tiesa. Taču kaut kā sevi kā izstrādātāju ir jānorobežo no lieka darba veikšanas, un ir atšķirība, vai video, piemēram, būs kā embedded/iframe no Youtube, vai jāiestrādā pašā Drupal ar visu upload, convert, streaming, utt. Pasūtītājs jau redzēs līdzīgu rezultātu abos gadījumos, bet no darba viedokļa - divi dažādi risinājumi. Subjektīvi ar specifikāciju es vairāk domāju tādu materiālu, kas precizētu šīs robežas un dotu iespēju pasūtītājam un izpildītājam tā teikt - nonākt pie kopsaucēja un abpusējas sapratnes. Citādi projekts ir pakļauts n-tajām pārstrādēm, kur pasūtītājs īsti negrib neko dzirdēt par $$$ :) Līdz ar ko zināmā mērā šī specifikācija tomēr ir vajadzīga, lai izvērtētu izmaksas. Es nedomāju par projektiem, kur pasūtītājam ir vai nu vienalga, vai viņš no tā vispār neko nesaprot, un būtu gatavs jebkuram risinājumam. Bet ja ir projekti, kur jāiekļauj specifiski dizaina izklājumi, utt., tad var nočakarēties arī uz sīkumiem.