Archief - IT: gebakken lucht ?
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
DogFacedGod
Legacy Member
Bubba zei:
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
.Hetzelfde verhaal voor HR. Die zijn ook sterk om hun job in de vaagste termen ooit te omschrijven en vraagt de gewone mens zich ook af achteraf. "Wat doet die mens nu eigenlijk?" Dan vragen ze zich af waarom er zoveel wantrouwen is tegenover de HR.
zarathustra
Legacy Member
Er zijn natuurlijk ook een hoop vage zaken. Onze backup as a service ging ineens 'verdacht traag'. Heeft drie weken geduurd voor dat opgelost is. Daar hebben verschillende mensen aangewerkt, niemand die hele 3 weken natuurlijk. Dus wat heb je dan gedaan .. goh tests, patch notes gelezen, verschillende scenarios opzetten, etc etc
Maar leg dat maar eens uit in mensen taal.
Maar leg dat maar eens uit in mensen taal.
Anoniem13
Legacy Member
Is dat niet omdat het beide beroepen zijn waar mensen zich weinig bij kunnen voorstellen? Bij een huis kan je jou voorstellen dat er daar een elektricien, een loodgieter, een metselaar, een architect enz... aan te pas komt en dat is ook tastbaar. Bij een IT-er niet echt. HR lijkt me dan al gemakkelijker, daar zijn er niet zo veel verschillende rollen.DogFacedGod zei: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
Hetzelfde verhaal voor HR. Die zijn ook sterk om hun job in de vaagste termen ooit te omschrijven en vraagt de gewone mens zich ook af achteraf. "Wat doet die mens nu eigenlijk?" Dan vragen ze zich af waarom er zoveel wantrouwen is tegenover de HR.
Tailball
Legacy Member
:unsure: zei:
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.
KnightOfCydonia
Legacy Member
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.
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.
beryl
Legacy Member
Tailball zei:
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."
Five-seveN
Legacy Member
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.
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.
Pana
Legacy Member
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/skype-for-business-2015-protocol-workloads-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/13230/mediant-1000b-gateway-and-e-sbc-users-manual-ver-72.pdf
https://www.audiocodes.com/media/13244/gateway-and-sbc-cli-reference-guide-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..
Waarschijnlijk, maar tis een excuus om eens te venten :-D
- 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/skype-for-business-2015-protocol-workloads-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/13230/mediant-1000b-gateway-and-e-sbc-users-manual-ver-72.pdf
https://www.audiocodes.com/media/13244/gateway-and-sbc-cli-reference-guide-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..
Carrion zei::unsure : is gewoon elke IT'er van het forum tegelijk aan het trollen
Waarschijnlijk, maar tis een excuus om eens te venten :-D
Diatonico
Legacy Member
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.
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.
:unsure:
Legacy Member
DogFacedGod zei: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
Diatonico zei:
Merci, meest begrijpbare voorbeeld in deze thread
sandervdw
Legacy Member
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.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.