Page 4 of 8 First 12345678 Last
  1. #46

    Registered
    11/09/16
    Location
    Paaseiland
    Posts
    2,790
    iTrader
    1 (100%)
    Mentioned
    0 Post(s)
    Reputation
    27/336
    Quote Originally Posted by :unsure: View Post
    This quote is hidden because you are ignoring this member. Show
    en nog altijd niemand die een concreet voorbeeld geeft
    ik weet ook wel dat IT belangrijk is, ik vraag me gewoon af wat het gros van de IT'ers letterlijk doet op een doorsnee dag, en er is hier letterlijk niemand die mij een duidelijk antwoord kan geven precies.


    wat doet een front-end developer bijvoorbeeld? Programmeert die een bepaald knopje in op een bepaalde applicatie? Zoja: hoe doet hij dit? Gaat die te werk in excel, C++,... of geeft hij gewoon instructies door naar Indiërs die het voor hem doen waarna hij controleert dat het werkt? Wat bereikt hij met dat knopje en waarom zou hij dat uberhaupt programmeren?

    Of hoe zorg je ervoor dat allerlei programma's voor een groot deel van uw bedrijf upgedatet worden zodat de end-users er niets van merken?



    Allez mannekes, zo moeilijk is het toch niet om een beetje uitleg of concrete voorbeelden te geven over hoe je effectief te werk gaat?
    Zeg, ik ga u echt nie in detail een hele codestructuur uitleggen he. Ge snapt het toch niet en dat is gewoon niet mogelijk om dat hier uit te typen. Lees u wat boeken over talen of methodologieen. Of kijk op stackoverflow.

    Daarbuiten moet ge ook maar eens kijken naar Agile en Scrum principes. Of deployment strategieen. Of continuous integration. Of source control. Code reviews, commits en pullrequests? Of ...

    Ja er worden vaak veel en complexe termen gehanteerd. Maar dat is toch normaal vakjargon?
    Een chirurg gebruikt ook woorden die ik niet ken en heel specifiek in zijn wereld wel gekend zijn.
    Heck, als ik werkwoorden hoor die een chefkok gebruikt, duizelt het ook al.
    Vraag eens wat die 2 mensen heel de dag doen?
    Een antwoord als 'patienten opensnijden' of 'eten koken', zult ge terugkrijgen, maar weet ge dan iets van hoe die hun dag doen?
    Exact hetzelfde met iedere specialisatie in de IT.

    Sommigen zeggen hier dat het hautain is, maar ik vind het dan weer denigrerend hoe de vraag gesteld wordt. Alsof alles te minimaliseren valt in 3 regels tekst.
    Kan een geoloog dat wel beantwoorden dan? Of reageert die ook hautain?

    Ik werk met studenten en stagairs die mij wel begrijpen als ik vaktermen gebruik. Wij spreken dezelfde jargon.
    Als ge het in zo enkele posts ineens allemaal zou begrijpen waart ofwel gij een genie ofwel ik mn job kwijt.
    Last edited by Tailball; 15-04-2019 at 22:51.
    1 members found this post helpful.   Reply With Quote Reply With Quote

  2. #47

    Registered
    27/12/15
    Posts
    882
    iTrader
    0
    Mentioned
    2 Post(s)
    Reputation
    25/163
    Quote Originally Posted by Profitable View Post
    This quote is hidden because you are ignoring this member. Show
    Als ik aan jobs moet denken die gebakken lucht zijn, dan komt er wel iets anders in mijn gedachten dan IT hoor. *kuch* politiekers *kuch*
    Grappig dat je eerst erkent dat het voor leken moeilijk is het nut van een job te begrijpen is, maar dan wel vuil naar politici gooit.
    no votes   Reply With Quote Reply With Quote

  3. #48
    KnightOfCydonia's Avatar
    Registered
    29/11/06
    Location
    Zuid-Limburg
    Posts
    6,704
    iTrader
    5 (100%)
    Mentioned
    11 Post(s)
    Reputation
    43/1549
    Het probleem met politici is niet dat ze géén enkel nut hebben. Dat beweren zou inderdaad onzinnig zijn. Het probleem met politici in België is dat we er véél te véél van hebben.
    Een bedrijf die meer werknemers heeft dan het nodig heeft, zonder dat die extra werknemers extra meerwaarde creëren, loopt het risico verlies te gaan maken en failliet te gaan...
    Bij de overheid, die in dit land uit 6 regeringen/parlementen bestaat, geldt die logica natuurlijk niet, maar onze staatsschuld is natuurlijk wél navenant.

    Ik kan me overigens ook gerust inbeelden dat in sommige bedrijven de IT-dienst niet altijd even nuttig is. Soms is dat maar goed ook, als de netwerkbeheerder(s) van een groot bedrijf weinig werk hebben buiten wat minor issues die er altijd wel zijn, omdat alles goed draait, zal het bedrijf net wél blij zijn. Het houdt die netwerkbeheerders dan uiteindelijk in dienst voor wanneer het toch moest mislopen, om problemen zo snel mogelijk opgelost te hebben.

    Dat gezegd zijnde, hoewel ik de schijnbare vooroordelen van de threadstarter niet deel, zou ik op professioneel vlak wel graag eens van iemand horen die actief is in de sector hoe de gemiddelde werkdag/werkweek van een back-end developer eruit ziet (Java/.NET/etc.), mag eventueel ook in PM.
    no votes   Reply With Quote Reply With Quote

  4. #49
    beryl's Avatar
    Registered
    11/11/03
    Location
    Brussel
    Posts
    4,195
    iTrader
    0
    Mentioned
    9 Post(s)
    Reputation
    44/629
    Quote Originally Posted by Tailball View Post
    This quote is hidden because you are ignoring this member. Show
    Zeg, ik ga u echt nie in detail een hele codestructuur uitleggen he. Ge snapt het toch niet en dat is gewoon niet mogelijk om dat hier uit te typen. Lees u wat boeken over talen of methodologieen. Of kijk op stackoverflow.

    Daarbuiten moet ge ook maar eens kijken naar Agile en Scrum principes. Of deployment strategieen. Of continuous integration. Of source control. Code reviews, commits en pullrequests? Of ...

    Ja er worden vaak veel en complexe termen gehanteerd. Maar dat is toch normaal vakjargon?
    Een chirurg gebruikt ook woorden die ik niet ken en heel specifiek in zijn wereld wel gekend zijn.
    Heck, als ik werkwoorden hoor die een chefkok gebruikt, duizelt het ook al.
    Vraag eens wat die 2 mensen heel de dag doen?
    Een antwoord als 'patienten opensnijden' of 'eten koken', zult ge terugkrijgen, maar weet ge dan iets van hoe die hun dag doen?
    Exact hetzelfde met iedere specialisatie in de IT.

    Sommigen zeggen hier dat het hautain is, maar ik vind het dan weer denigrerend hoe de vraag gesteld wordt. Alsof alles te minimaliseren valt in 3 regels tekst.
    Kan een geoloog dat wel beantwoorden dan? Of reageert die ook hautain?

    Ik werk met studenten en stagairs die mij wel begrijpen als ik vaktermen gebruik. Wij spreken dezelfde jargon.
    Als ge het in zo enkele posts ineens allemaal zou begrijpen waart ofwel gij een genie ofwel ik mn job kwijt.
    Aan de andere kant, een kok of een chirurg kunnen dat ook wel concreet uitleggen als ze met een leek bezig praten. Vakjargon is handig omdat het vaak communicatie tussen mensen die de woorden snappen vereenvoudigt, maar er is toch niet echt een reden waarom je geen uitleg zonder vakjargon zou kunnen geven?

    Om het met een quote van Einstein te zeggen: "If you can't explain it simply, you don't understand it well enough."
    1 members found this post helpful.   Reply With Quote Reply With Quote

  5. #50

    Registered
    19/02/12
    Posts
    5,378
    iTrader
    0
    Mentioned
    16 Post(s)
    Reputation
    35/789
    Concreet voorbeeld van iets zeer simpel.

    Een klant heeft een aantal printers staan met een weegbrug, en wil dat wanneer een vrachtwagen gewogen wordt, automatisch het gewicht afgeprint wordt en de leverancier deze weegbonnen op een website kan zien. Een lijst van alle IT-ers die nodig zijn, en dit zijn vaak verschillende mensen:

    De IT-er van de weegbrug leverancier, die meestal een kaske aan de balie zetten waarop je het gewicht kan aflezen op de LED display.
    De IT-er die een communicatie-design opstelt, waarbij hij een bepaalde convertor kiest van serieel signaal (seriele kabel) naar ethernet (netwerkkabel).
    De IT-er die deze convertor correct kan verbinden met het bedrijfsnetwerk, welk IP adres, welke switch, welke soort kabel, welke afstand...
    De IT-er die in dit netwerk een nieuwe server installeert, type Windows OS, met alle beveiligingsupdates, licenties, enzovoort.
    De IT-er die een applicatie schrijft (NET of whatever) die op deze server kan draaien, en die in staat is via ethernet protocol met die weegbrug display te communiceren om data uit te lezen.
    De IT-er die onderzoekt via welk protocol die printers dienen aangestuurd te worden, en deze code verwerkt in het NET programma
    De IT-er die een Cloud-gebasseerde databank aanmaakt dewelke toegankelijk is door dit NET programma
    De IT-er die de zaken geprint door dit NET programma kan opslaan in een deze databank in de cloud
    De IT-er die de databank in de cloud toegankelijk maakt via een rapporterings website die draait in de cloud

    En die mensen moeten allemaal gecoordineerd worden, deze coordinators noemen zichzelf vaak ook IT-er terwijl ze er eigenlijk technisch niet veel van kennen.
    Last edited by Five-seveN; 15-04-2019 at 23:31.
    no votes   Reply With Quote Reply With Quote

  6. #51
    Pana's Avatar
    Registered
    05/11/02
    Location
    Kempen
    Posts
    5,569
    iTrader
    6 (100%)
    Mentioned
    1 Post(s)
    Reputation
    4/96
    Als UC / Skype For Business engineer:

    - Deze shit analyseren om routing/manipulatie/packetheader errors uit te zoeken:



    - RFC's lezen en leren om protocols door en door te kennen (https://www.ietf.org/rfc/rfc3261.txt \o/)
    - Front end & back end infrastructuur opzetten voor Skype For Business + AD en DNS prep (Zie https://guybachar.net/2015/04/14/sky...kloads-poster/ voor de workloads)
    - Session Border Controllers configureren en interop met telefooncentrales verzorgen. In de praktijk? Neem even volgende documenten door:
    https://www.audiocodes.com/media/132...ual-ver-72.pdf
    https://www.audiocodes.com/media/132...ide-ver-72.pdf
    - Call routing / manupulaties voor klantensites in het buitenland aanmaken
    - Contactcenters opbouwen en callflows ontwerpen
    - End to end QoS configs doen
    - Call quality issues troubleshooten (dit kan gaan van codec mismatches tussen backend en SBC, SBC en provider, tot netwerktraces en wifi analyses)
    - Bikkeren met de klant dat de call drops toch echt het gevolg zijn van het netwerk
    - Exchange configs voor unified messaging (voicemail, conv./call history, missed calls) opzetten
    - Hybride oplossingen tussen on-prem Skype for Business infra en O365/azure AD opzetten
    - Bugs uitzoeken in 3rd party oplossingen ism met de klant en de leverancier
    - In het verlengde daarvan: eindeloze test opstellingen maken om alles mogelijke scenario's af te gaan.
    - Nieuwe producten van leveranciers valideren
    - Veel avondwerk, want telefonie en zeker contaccenters zijn altijd kritisch.
    - etc..
    - etc..

    Quote Originally Posted by Carrion View Post
    This quote is hidden because you are ignoring this member. Show
    :unsure : is gewoon elke IT'er van het forum tegelijk aan het trollen
    Waarschijnlijk, maar tis een excuus om eens te venten :-D
    Last edited by Pana; 16-04-2019 at 00:10.
    9lives stopt er mee, maar het feestje gaat door op beyondgaming.be!
    no votes   Reply With Quote Reply With Quote

  7. #52
    Carrion's Avatar
    Registered
    23/11/08
    Location
    Tessenderlo
    Posts
    22,572
    iTrader
    71 (100%)
    Mentioned
    26 Post(s)
    Reputation
    87/2948
    :unsure : is gewoon elke IT'er van het forum tegelijk aan het trollen
    9lives stopt op 31/01 -> BeyondGaming neemt de fakkel over
    https://www.9lives.be/forum/algemene...12-2020-a.html
    no votes   Reply With Quote Reply With Quote

  8. #53

    Registered
    27/12/15
    Posts
    882
    iTrader
    0
    Mentioned
    2 Post(s)
    Reputation
    25/163
    Toch even on-topic reageren:

    Zelf ben ik functioneel analist.

    Wablieft?

    Kort door de bocht: als er een software-oplossing komt voor een probleem dat business heeft, dan is het mijn verantwoordelijkheid om ervoor te zorgen dat 1) alle eisen en wensen van de klant gekend zijn, 2) dat dit vertaald wordt naar een haalbaar technisch ontwerp.

    Nee, het is niet zo simpel als de klant vragen "wat wil je?" en dat opschrijven.

    Een aantal zaken die leken vaak onderschatten:

    Veel mensen begrijpen IT niet. Veel zaken zijn moeilijk uit te leggen aan iemand die er weinig verstand van heeft, en dus moet je vooral vertrouwen opbouwen bij de klant/business zodat ze niet bij elke stap alles in vraag stellen en zo alles nog trager maken.

    Software is een enorm complex gegeven. Verander 1 iets, en dit heeft impact op 127 andere plaatsen. De computer doet gewoon letterlijk wat je van hem vraagt. Die heeft geen 'gezond boerenverstand' of context. Dus je moet alles letterlijk stap voor stap uitwerken, en zorgen dat je aan alle mogelijk situaties en toestanden gedacht hebt. Continu de vraag stellen "hoe kan dit verkeerd gaan?" En gegarandeerd dat je programmeur een aantal gevallen vergeet. Gebruikers zijn HEEL goed in manieren vinden om alles te doen fout lopen.

    Stel je voor dat je iemand moet uitleggen hoe hij wortelen in schijfjes moet snijden. Je zegt "houdt de wortel vast met je linkerhand, neem het mes met het scherpe deel naar beneden in je rechter, hak met het mes naar beneden, verschuif het dan 0.5cm naar links en blijf dit doen tot er geen wortel meer onder het mes is". De persoon doet niets, je was vergeten uit te leggen hoe hij het mes uit het messenblok moet halen. Ok, je voegt instructies toe en probeert opnieuw. Nu kan hij niet snijden want hij hield het mes in de verkeerde richting vast. Je past weer aan. Nu hakt die zijn vingers af, je was vergeten te zeggen dat hij z'n andere vingers OOK moest opschuiven. Enzoverder. Maar dan 100x gedetailleerder.

    Komt daarbij dat een computer miljarden instructies per seconde verwerkt dus er zijn altijd mogelijkheden en toestanden waar zelfs een expert niet direct aan kan denken. Om den duur is het zo complex dat niemand in het team de applicatie volledig begrijpt. Onze developers moeten veel tijd steken in het begrijpen van code die jaren geleden geschreven werd (en die niet gedocumenteerd werd, want ja, dat kost geld he). Die problemen kunnen aangepakt worden met: 1) een robuuste architectuur die zorgt dat de software onderhoudbaar is, uitbreidbaar is, en die veel voorkomende problemen vermijdt,... en 2) uitgebreid testen ( regressietesten = testen dat, na een aanpassing, alle vorige functionaliteit nog werkt zoals het moet).

    En dan hebben we het nog maar over 1 systeem. Meestal moet je gaan communiceren met andere systemen, die wellicht op andere manieren werken en door andere mensen onderhouden worden. Die andere systemen zijn vaak een 'black box' -- je weet niet hoe ze vanbinnen werken. Je ziet dat de complexiteit exponentieel toeneemt.

    De klant wil vaak aan zo laag mogelijke kost en/of zo snel mogelijk zijn software hebben. Zie ook bovenstaande punten: de klant wil lagere kosten, zegt dan maar "doe die architectuur, dat testen en dat documenteren maar minder uitgebreid dan". Hij begrijpt immers niet wat het nut er van is. Gevolg? Onderhoud en uitbreiding worden een pak duurder. Komt de klant achteraf natuurlijk zagen en klagen en de kosten op ons verhalen. "Tja, je wilde het goedkoper en we hebben gewaarschuwd voor de gevolgen." Dat wil die natuurlijk niet horen...

    Mensen zijn enorm slecht in weten wat ze willen. De klant zit vaak zo diep in zijn probleem, dat hij de grondoorzaak niet meer ziet. Bovendien gaat de mens vaak al een oplossing zoeken voor zijn probleem, en jou dan vragen die oplossing te realiseren. Hij staat er niet bij stil dat zijn echte probleem misschien een betere oplossing heeft.

    Mensen zijn enorm slecht in communiceren wat ze willen. Ze hebben een rode cirkel in hun hoofd, ze beschrijven het als een blauwe icosaëder uit katoen, en na een lange workshop blijkt dat ze een strandbal in de kleuren van de regenboog willen. Als analist moet ik de business van mijn klant heel goed kennen, alsook de personen in kwestie, om te kunnen anticiperen op hun noden en om te weten hoe ik alles scherp kan krijgen. En dan nog is het vaak een hele klus om bepaalde zaken duidelijk te krijgen.

    De klant is zich vaak niet bewust van alle gevolgen van hun keuzes en/of alle speciale situaties die enorm veel complexiteit introduceren. Had ik maar een euro voor elke keer ik dit gesprek had - klant: "ik wil x en y. dat moet toch vlug klaar zijn?", ik: "heb je al gedacht aan speciale situaties a, b en c? wat doen we met [afhankelijk systeem] y? vergeet niet dat je dan ook q en r gaat moeten voorzien. Oh, en weet je nog dat je wilde dat functionaliteit z goedkoop en snel moest gemaakt worden? dat gaan we moeten herschrijven", klant: "... eum... ja, daar had ik niet aan gedacht... moet dat echt allemaal?"

    Als functioneel analist ben je de haas als er iets mis loopt. Sommige programmeurs doen gewoon letterlijk wat er in je analyse staat (vooral Indiërs), dus werkelijk elk dwaas dom gevalletje moet je in je analyse zetten. "Amai, moet ik die 150 pagina's lezen voor een paar domme veranderingen?" "Tja, vorige keer was de klant kwaad dat wachtwoorden niet verborgen werden in het inlogscherm... Je schoof het in mijn schoenen omdat dit niet letterlijk in de analyse stond dat wachtwoorden als ***** moeten weergegeven worden."

    De klant zal ook op jou schieten als er iets niet is zoals het er in zijn hoofd uitzag. Ook al heeft hij nooit uitgelegd hoe het er in zijn hoofd uitzag. Daarom hebben we dus documenten van 500 pagina's waarin elke scheet in detail beschreven wordt zodat je achteraf geen peperdure veranderingen kan komen eisen.

    Ik kan zo even doorgaan... TL;DR: computers zijn de autisten der autisten, complexe structuren worden exponentieel complexer, en mensen zijn heel slecht in communiceren. Als ik m'n job niet goed doe, dan kan het miljoenen euro's kosten omdat software/systemen mogelijk volledig herwerkt moeten worden als ik de requirements niet correct capteer.
    Last edited by Diatonico; 15-04-2019 at 23:59.
    6 members found this post helpful.   Reply With Quote Reply With Quote

  9. #54
    |nfected's Avatar
    Registered
    05/11/03
    Location
    City of London
    Posts
    7,263
    iTrader
    9 (100%)
    Mentioned
    0 Post(s)
    Reputation
    3/62
    Waarom reageert iemand daar serieus op? Het is niet aan unsure om te begrijpen wat een IT'er doet. Als de business de benefits ziet en de ROI klopt, meer moet je niet hebben.

    Hij blijkt dan ook nog eens gat achterlijk te zijn ook.

    Sent from my LYA-L09 using Tapatalk
    1 members found this post helpful.   Reply With Quote Reply With Quote

  10. #55
    Affinity's Avatar
    Registered
    18/05/09
    Location
    Rarara
    Posts
    12,945
    iTrader
    4 (100%)
    Mentioned
    0 Post(s)
    Reputation
    5/63
    Quote Originally Posted by Pana View Post
    This quote is hidden because you are ignoring this member. Show
    - Bikkeren met de klant dat de call drops toch echt het gevolg zijn van het netwerk
    Vooral daar zijn de VOIP leveranciers wel sterk in heb ik al willen merken.
    no votes   Reply With Quote Reply With Quote

  11. #56
    :unsure:'s Avatar
    Registered
    05/11/14
    Location
    Leuven
    Posts
    3,402
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    19/68
    Quote Originally Posted by DogFacedGod View Post
    This quote is hidden because you are ignoring this member. Show
    Is het grote probleem wat IT voor velen onaantrekkelijk maakt. Er wordt een soort barrière opgemaakt door al die techtalk. En als er iemand uitleg vraagt, is er de hautaine of verongelukte reactie en zitten ze op hetzelfde moment te klagen dat er geen respect is voor hen .
    Dit dus
    Ik probeer gewoon wat bij te leren over andere functies

    Quote Originally Posted by Diatonico View Post
    This quote is hidden because you are ignoring this member. Show
    Toch even on-topic reageren:

    Zelf ben ik functioneel analist.

    Wablieft?
    Merci, meest begrijpbare voorbeeld in deze thread
    no votes   Reply With Quote Reply With Quote

  12. #57

    Registered
    25/11/11
    Location
    Heist-op-den-Berg
    Posts
    20,821
    iTrader
    4 (100%)
    Mentioned
    48 Post(s)
    Reputation
    58/814
    Mijn job bestaat erin om een platform op te bouwen zodat de managers van de luchthaven analyses kunnen doen op de verkopen in de winkels en hier op bijsturen om de winst te optimaliseren. Andere collega's houden zich dan weer bezig met het beschikbaar maken van de operationele data van de luchthaven om de efficiëntie omhoog te krijgen.
    no votes   Reply With Quote Reply With Quote

  13. #58
    Bubba's Avatar
    Registered
    13/03/06
    Location
    Lommel
    Posts
    14,620
    iTrader
    4 (100%)
    Mentioned
    1 Post(s)
    Reputation
    12/169
    Quote Originally Posted by :unsure: View Post
    This quote is hidden because you are ignoring this member. Show
    Dit dus
    Ik probeer gewoon wat bij te leren over andere functies
    Als je start met te stellen dat IT'ers weinig of niks bijbrengen dan probeer je niet "gewoon wat bij te leren over andere functies".
    1 members found this post helpful.   Reply With Quote Reply With Quote

  14. #59
    kay-gell's Avatar
    Registered
    26/01/09
    Location
    Limburg
    Posts
    19,124
    iTrader
    37 (100%)
    Mentioned
    38 Post(s)
    Reputation
    5/1689
    Sorry he maar ne job die ge in 2 letters kunt omschrijven kunt ge niet serieus nemen.
    #red9lives
    Niet opgeven mannen
    no votes   Reply With Quote Reply With Quote

  15. #60
    Pana's Avatar
    Registered
    05/11/02
    Location
    Kempen
    Posts
    5,569
    iTrader
    6 (100%)
    Mentioned
    1 Post(s)
    Reputation
    4/96
    Quote Originally Posted by Affinity View Post
    This quote is hidden because you are ignoring this member. Show
    Vooral daar zijn de VOIP leveranciers wel sterk in heb ik al willen merken.
    Gelukkig vrij eenvoudig te bewijzen en meestal hebben we ook wel gelijk als we zulke stellingen maken.
    9lives stopt er mee, maar het feestje gaat door op beyondgaming.be!
    no votes   Reply With Quote Reply With Quote

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in

Log in