Kõige parem on siseneda oma eriala kaudu, st kui olla logistik, siis hakata aretama logistikalahendusi. Kui on ka kogemus mõne ERP vms süsteemiga, siis võikski alustada selle progemisest. Need on oma "ühe vaate tasemel" suht lihtsad arendada.
Oled sa ikka kindel, et ERP süsteemiga millegagi segi ei aja?
Ma arendasin 3 aastat MS Axaptat / Dynamics AX-i ja see oli mu esimene arendajakoht (ca 2003). Mõned, praeguseks aegunud serdid on mul ka.
Tegelesin peamiselt finantside ja laoarvestusega. Asja teeb lihtsaks see, et kogu arhitektuur on juba paigas ja seda läbiproovitud parima praktika alusel. Jätka vaid samas stiilis ja kirjuta oma loogika vahele. Päris uute asjade lisamine on muidugi keerulisem, aga sinna saab areneda.
Selles suhtes ma pole nõus siin nendega, kes AI-d ja copiloti kiidavad - nendega tekitab sellist igavese juuniorarendaja vigast koodi. Nii palju kui mina olen proovinud, siis läheb rohkem aega genereeritud koodi remontimisele ja ühtlustamisele kui otsast peale ise kirjutades. Igavese juuniorarendaja kood on sarnane - "error reporting off" ja kopipaste selle järele, vahepeale paar muutujate ümbernimetamist.
Ülemused on rõõmsad, et päevaga saab kliendile midagi esitada, hiljem peab vanemarendaja seda kraami nädal aega helpima, ilma "kasulike tundideta".
Huvitav, et viimasel ajal ikka kõik tahavad alguses minna testijaks. Mina soovitaks ikka tehnilise toe osakonda minna. Seal kogud ikkagi kõige kiiremini ja kõige rohkem teadmisi ja arusaami kuidas asjad käivad. Sealt edasi siis otsustad kuhu poole minna - kas tehnilisele poolele või äri poolele. Küll aga 42 aastaselt ma isegi ei kujuta ette... nagu öeldud sai siin kellegi poolt siis konkureerid ikkagi turul kus sinul on vähe kauplemisruumi. Ja eks see entry-level tasu ilmselt ei ole sinu maitse järgi ka.
Kõik tehnilised positsioonid - noh, nad on tehnilised. Aga ega ka äri suunal on sul tehnilist taipu vaja. Tarkvaraarenduses ikka üldiselt keegi ei salli projektijuhte kes ei saa aru natukenegi asjadest. Pead ikka miskit 5a tööd tegema enne, et oleks austustväärt teadmised taga, Okei võibolla vähem kui oled õpihuviline. Tootejuht tarkvaras on ka selline väga laialivalguv mõiste. Enamustes firmades seda pole vaja - ja seal kus on on konkurents ikka väga tugev. Ja eks samuti - pead aru saama mis asi on teenuse disain ja millised lahendused sobivad millistele probleemidele.
Ma vabandan, et nii pessimistlik. Minu soovitus oleks jääda oma valdkonna juurde. Küll aga kui sa tead enda valdkonnas kohti mida saaks paremaks muuta tarkvaraga. Tee oma mingi firma mis tegeleb tarkvaraga ja lahendab mingit logistilist mure. Ole juht ja ole ettevõtja. Ja äkki saad juhtida it-ettevõtet.
Kõige parem on siseneda oma eriala kaudu, st kui olla logistik, siis hakata aretama logistikalahendusi. Kui on ka kogemus mõne ERP vms süsteemiga, siis võikski alustada selle progemisest. Need on oma "ühe vaate tasemel" suht lihtsad arendada.
Oled sa ikka kindel, et ERP süsteemiga millegagi segi ei aja?
Ma arendasin 3 aastat MS Axaptat / Dynamics AX-i ja see oli mu esimene arendajakoht (ca 2003). Mõned, praeguseks aegunud serdid on mul ka.
Tegelesin peamiselt finantside ja laoarvestusega. Asja teeb lihtsaks see, et kogu arhitektuur on juba paigas ja seda läbiproovitud parima praktika alusel. Jätka vaid samas stiilis ja kirjuta oma loogika vahele. Päris uute asjade lisamine on muidugi keerulisem, aga sinna saab areneda.
See oma äriloogika kirjutamine eeldab vähemalt teema hästi valdamist. Lisaks veel kohaliku finantsjuhi/raamatupidajate tahtmiste äraarvamist. See ei ole algaja alustamise koht. 20 aastat jooksul on ERP valgusaastate kaugusele arenenud. Lihtsad asjad on niikuinii juba tarkvarasse sisse kirjutatud. Keerulised asjad aga ongi väga keerulised.
"Olevipoeg" 20 aastat jooksul on ERP valgusaastate kaugusele arenenud. Lihtsad asjad on niikuinii juba tarkvarasse sisse kirjutatud. Keerulised asjad aga ongi väga keerulised.
Minu arusaamist mööda on ERPid arenenud arenemise enese pärast - või siis omaniku platvormide müügi edendamise huvides. Näiteks 20 aasta tagune Navision oli märkimisväärselt mõnusam keskkond kui praegune Business Central.
"Olevipoeg" 20 aastat jooksul on ERP valgusaastate kaugusele arenenud. Lihtsad asjad on niikuinii juba tarkvarasse sisse kirjutatud. Keerulised asjad aga ongi väga keerulised.
Minu arusaamist mööda on ERPid arenenud arenemise enese pärast - või siis omaniku platvormide müügi edendamise huvides. Näiteks 20 aasta tagune Navision oli märkimisväärselt mõnusam keskkond kui praegune Business Central.
Võimalik. Kuid keegi ei võta nooremarendajat palgale selleks, et ta enda või kliendi finantsjuhile hakkaks seletama, kuidas asjad tegelikult peaksid käima. See on üks kindlamaid viise hästi ruttu vallandatud saada.
"ussu" Palju see enteri leveli tasu on? Ma arvan, et mul pikk elu veel ees, miks mitte õppida ümber.
Ma läksin ERPi arendama 25% kliendile konkreetselt minu töö eest (st neto ilma analüütiku, pm jms tasudeta) arveldatud tundide eest mu palgafondi. Alampiiriks oli küll tolleaegne miinimumpalk, mis oli 3000 krooni, seda sain esimesel kuul. Teise kuu keskel tegin esimese serdi, mu tööd müüdi kliendile ja sain kuu lõpuks juba rohkem.
Kõige parem on siseneda oma eriala kaudu, st kui olla logistik, siis hakata aretama logistikalahendusi. Kui on ka kogemus mõne ERP vms süsteemiga, siis võikski alustada selle progemisest. Need on oma "ühe vaate tasemel" suht lihtsad arendada.
Oled sa ikka kindel, et ERP süsteemiga millegagi segi ei aja?
Ma arendasin 3 aastat MS Axaptat / Dynamics AX-i ja see oli mu esimene arendajakoht (ca 2003). Mõned, praeguseks aegunud serdid on mul ka.
Tegelesin peamiselt finantside ja laoarvestusega. Asja teeb lihtsaks see, et kogu arhitektuur on juba paigas ja seda läbiproovitud parima praktika alusel. Jätka vaid samas stiilis ja kirjuta oma loogika vahele. Päris uute asjade lisamine on muidugi keerulisem, aga sinna saab areneda.
See oma äriloogika kirjutamine eeldab vähemalt teema hästi valdamist. Lisaks veel kohaliku finantsjuhi/raamatupidajate tahtmiste äraarvamist. See ei ole algaja alustamise koht. 20 aastat jooksul on ERP valgusaastate kaugusele arenenud. Lihtsad asjad on niikuinii juba tarkvarasse sisse kirjutatud. Keerulised asjad aga ongi väga keerulised.
Kliendiga suhtlevad peamiselt vastavad inimesed, mitte arendajad, kes jagelevad ka kliendi esindajatega (sh ERP puhul mitte ainult raamatupidajatega). ERP pole tegelikult eriti kuhugi arenenud, nagu ka Marvin välja tõi - süsteemi loogika on jäänud tegelikult kuhugi 70.-80. piiri peale. Raamatupidamise alused on üldse vanast heast Veneetsia ajast :)
Arendused on sageli seotud kliendispetsiifiliste aruannetega,kliendispetsiifiliste dokumentidega, mingite kliendispetsiifiliste arvutustega, laomajanduse ja logistika eripäradega jne.
ERP puhul on veel hea asi, et ei pea tegelema eriti frontendiga, mis on algajatele ja muidu kehvema peakujuga inimestele sageli veidike raske :)
Arendused on sageli seotud kliendispetsiifiliste aruannetega,kliendispetsiifiliste dokumentidega, mingite kliendispetsiifiliste arvutustega, laomajanduse ja logistika eripäradega jne.
Sa teed praegu juba päris pikka rännakut üle oma kompetentsi piiri. Nii oli see tõesti 20 aasta eest. Tänapäeval on teemad natukese teised.
Ma võtsin ühe keerulise IT infraprojekti juhiks tööle IT taustata projektijuhi. Ja väga hea valik oli. Saab hästi hakkama aga teadvustab, et taustateadmised on puudulikud ning plaanib läbida sügisest CCNA kursuse. See mingi päris naljaasi kursus ei ole aga arvan, et ta saab ka seal hakkama.
Tean ka kahte inimest, kes on läbinud kood Jõhvi. See on päris hardcore meetod aru saamiseks, kas sulle arendamine sobib? Kui seal hakkama saad ja meeldib siis anna tuld ja paremad rabatakse sealt otse tööle. Ja kui sa ka arendajaks ei plaani hakata siis igal juhul on kasulik teada, kuidas see käib.
Arendused on sageli seotud kliendispetsiifiliste aruannetega,kliendispetsiifiliste dokumentidega, mingite kliendispetsiifiliste arvutustega, laomajanduse ja logistika eripäradega jne.
Sa teed praegu juba päris pikka rännakut üle oma kompetentsi piiri. Nii oli see tõesti 20 aasta eest. Tänapäeval on teemad natukese teised.
Pauks sisulist vastust - millega siis tegelevad nooremarendajad ERP süsteemide konsultatsioonifirmades praegu?
Vanemarendajad tegelesid tõepoolest ka muude teemadega, nagu teiste süsteemidega sidumine ja keerulisemad kohandused. Ma tegelesin tootmise-lao protsesside-planeerimise ja klientide finantseripäradega. Tunnistan, et see oli mõnda aega tagasi, aga nii palju kui ma praegu kokku olen puutunud, on asjade üldine sisu ja töökorraldus samaks jäänud.
Arendused on sageli seotud kliendispetsiifiliste aruannetega,kliendispetsiifiliste dokumentidega, mingite kliendispetsiifiliste arvutustega, laomajanduse ja logistika eripäradega jne.
Sa teed praegu juba päris pikka rännakut üle oma kompetentsi piiri. Nii oli see tõesti 20 aasta eest. Tänapäeval on teemad natukese teised.
Pauks sisulist vastust - millega siis tegelevad nooremarendajad ERP süsteemide konsultatsioonifirmades praegu?
Vanemarendajad tegelesid tõepoolest ka muude teemadega, nagu teiste süsteemidega sidumine ja keerulisemad kohandused. Ma tegelesin tootmise-lao protsesside-planeerimise ja klientide finantseripäradega. Tunnistan, et see oli mõnda aega tagasi, aga nii palju kui ma praegu kokku olen puutunud, on asjade üldine sisu ja töökorraldus samaks jäänud.
Ega nooremarendajatele väga palju tööd ei olegi. Sellist kerget spetsiifilist UI või trükise kujundust, et muudan teksti või tõstan hiirega kastikesi, on üsna väheks jäänud. Sellepärast võibki raske olla selles vallas jalga uksevahele saada, sest nõutakse spetsiifilisi oskusi nagu keerulisemate SQL päringute kirjutamist.
Arendused on sageli seotud kliendispetsiifiliste aruannetega,kliendispetsiifiliste dokumentidega, mingite kliendispetsiifiliste arvutustega, laomajanduse ja logistika eripäradega jne.
Sa teed praegu juba päris pikka rännakut üle oma kompetentsi piiri. Nii oli see tõesti 20 aasta eest. Tänapäeval on teemad natukese teised.
Pauks sisulist vastust - millega siis tegelevad nooremarendajad ERP süsteemide konsultatsioonifirmades praegu?
Vanemarendajad tegelesid tõepoolest ka muude teemadega, nagu teiste süsteemidega sidumine ja keerulisemad kohandused. Ma tegelesin tootmise-lao protsesside-planeerimise ja klientide finantseripäradega. Tunnistan, et see oli mõnda aega tagasi, aga nii palju kui ma praegu kokku olen puutunud, on asjade üldine sisu ja töökorraldus samaks jäänud.
Ega nooremarendajatele väga palju tööd ei olegi. Sellist kerget spetsiifilist UI või trükise kujundust, et muudan teksti või tõstan hiirega kastikesi, on üsna väheks jäänud. Sellepärast võibki raske olla selles vallas jalga uksevahele saada, sest nõutakse spetsiifilisi oskusi nagu keerulisemate SQL päringute kirjutamist.
Teksti muutmine ja kastikeste tõstmine süsteemis sees ei ole ERP puhul arendaja töö.
SQL päringud on lihtne, aga ka selleks on ERP enda teekides enamasti meetodid juba olemas. See vajadus tekib väga kliendispetsiifiliste arenduste puhul.
Normaalses firmas ongi nooremarendaja puhul ülesandeks tutvuda süsteemiga ja kesktasemele areneda. Pisikesi asju on alati teha.
Teksti muutmine ja kastikeste tõstmine süsteemis sees ei ole ERP puhul arendaja töö.
SQL päringud on lihtne, aga ka selleks on ERP enda teekides enamasti meetodid juba olemas. See vajadus tekib väga kliendispetsiifiliste arenduste puhul.
Jäänud ongi peamiselt kliendispetsiifilised arendused, sest kõik muu on ammu ära realiseeritud. Ja siis veel uued tehnoloogiad, mis pahatihti nõuavad eelkõige infoturbe väga head tundmist. Mis puutub SQLi, siis kõik ERP süsteemid on räigelt keelulise struktuuriga andmebaasidega (IIRC Navil oli 400+ tabelit kasutusel juba ca 10 aastat tagasi ) Valmispäringud on head ainult siis, kui tellijal pole vahet kui kaua see jookseb.
Normaalses firmas ongi nooremarendaja puhul ülesandeks tutvuda süsteemiga ja kesktasemele areneda. Pisikesi asju on alati teha.
Ma soovitaks nüüd vaadata millest teema alguse sai. Ta peab konkureerima 20-aastaste meeletu arenemispotentsiaali ja 40 aastaste 20-aastase kogemuse vastu.
Dynamic AX oli 1700 tabelit 20 a tagasi. Põhimõtteliselt oleme me üksteisega nõus.
42 aastaselt ja mingi muu valdkonna hea tundmisega on kõige soovitatam tee äritarkvarasse minna kuhugi hoopis vastava ala (noorem)konsultandiks või pm assistendiks, seal vaadata kuidas istub ja siis uurida analüüsi või arenduse suunda. Nii saab kasutatud see eelis, et olemasolevatel arendajatel pole sellist valdkonna kogemust.
Lisaks võib kaaluda ka startupi tegemist antud valdkonnas või siis liikuda kliendi juures valdkonnaga seotud tarkvara konsulteerimisse/kohendamisse.
Lisaks ma pole nõus, et 20 aastastel mingit meeletut potentsiaali oleks ainuüksi selle pärast, et nad noored on.
Kõrvalt näen, hoopis muus valdkonnas, et näiteks nullist pilliõpe käib just vanematel inimestel kiiremini ja väiksema pingutusega. Laste puhul lihtsalt unustatakse need aastad, mis nad sellesse panevad, ja väiksem hulk segavaid faktoreid.
Navi tabelite arv tulenes kolmest põhjusest: 1. ERPs on mõningane andmeliiasus hea praktika, sest andmemudeli äranormaliseerimine annab aruandluse jõudlusele paugu. 2. Rakendust litsentseeriti nn. graanulite kaudu, millest igaüks andis ligipääsu omadele tabelitele, vormidele, aruannetele ja koodiüksustele. Ja neid graanuleid oli palju, mistap oli palju ka tabeleid, millele eraldi pääsuõigusi anda. 3. Navisioni algses andmebaasimootoris olid realiseeritud funktsioonid (summaindeksväli), mille simuleerimiseks MS-SQL peal oli vaja luua suur hulk tehnoloogilisi lisatabeleid - ja jõudlus kannatas ikkagi. Tabelite rohkus ei olnud seega tingimata funktsionaalsusest tulenev. Olid ajad :).
"raulir" Lisaks ma pole nõus, et 20 aastastel mingit meeletut potentsiaali oleks ainuüksi selle pärast, et nad noored on.
Kõrvalt näen, hoopis muus valdkonnas, et näiteks nullist pilliõpe käib just vanematel inimestel kiiremini ja väiksema pingutusega. Laste puhul lihtsalt unustatakse need aastad, mis nad sellesse panevad, ja väiksem hulk segavaid faktoreid.
Rauliril on mingi uudne huvitav teooria, kus aju plastilisus ajas kasvab.
Muuseas, olles 20 aastat pilli mänginud, siis kui lapsena muusikaga kokku ei puutunud, on vanemas eas üsna lootusetu kuhugi eriti jõuda. Sõrmi võib igatpidi painutada, aga rütmitunnetus, kuulmine ja üldine musikaalsus arenevad suuresti nooremas eas ja kui see ajajärk vahele jääb, võib tehnilisi harjutusi söögi alla ja söögi peale teha, aga resultaat jääb kehvaks.
1. ERPs on mõningane andmeliiasus hea praktika, sest andmemudeli äranormaliseerimine annab aruandluse jõudlusele paugu.
Aruandlust tehakse reeglina Data Warehouse-tüüpi andmemudeliga baasi pealt, mis on absoluutselt midagi muud.
Aitäh mainimast, aga Ralph Kimballi "The Data Warehouse Toolkit" ja muud alusteosed on mul siiski möödunud sajandil läbitud materjal :). Väikestes ja keskmistes firmades ei olnud andmelaondus toona veel teemaks. Pole praegugi, aga aruanded võiks ikkagi mõistliku hooga valmis saada. Seega - kompromissid.