Van developer naar analist: voordelen, nadelen, eisen?

[PomPomPom]

Loopbaanadvies gevraagd :

Ik ben software developer (Java) maar ik overweeg om te gaan solliciteren op functies als
Informatie analist en/of functioneel ontwerper.

Om verschilldende redenen: het lijkt me leuk, de keren dat ik dicht bij de eindgebruiker zat als developer kwam het het eindproduct ten goede. Als developer heb ik wel eens iets gemaakt wat na oplevering niet meer relevant bleek te zijn (en bedankt business analist). Ik wil ook graag meer met mensen werken, dat motiveert.

Ik heb eigenlijk twee vragen, aan de mensen die zo'n overstap eerder gemaakt hebben:
* Wat zijn de voor- en nadelen van zo'n stap?
* Wat moet ik doen om zo'n overstap te maken, om met een CV als developer een kans te hebben bij vacatures als hierboven genoemd. Zijn er bv cursussen of certificaten die aangeraden worden?

[Tsurany]

Heb je al gekeken naar een dev rol bij een bedrijf dat Agile werkt? Dan zit je constant in overleg met de stakeholders en kan je zelf kiezen of je wat meer design/analyse werk op pakt of juist meer dev werk.

[wiemelen]

Je kan ook overwegen om uit te kijken naar een soort devops functie.
Klassieke onderscheid tussen informatie analist, functioneel ontwerper en developer komt minder en minder voor in mijn ervaring.
Ik ben zelf developer, maar voer ook taken uit die traditioneel bij een informatie analist , functioneel ontwerper en tester liggen. De ene sprint wat meer developen, de andere meer analyseren. Houdt je werk afwisselend en zeker je developer kennis geeft je net dat beetje meer technisch inzicht.

[_eLMo_]

Houd je van de hele dag documenten met specificaties schrijven (na meetings / klantcontact?

[PomPomPom]

_eLMo_ schreef op donderdag 21 januari 2021 @ 23:35:
Houd je van de hele dag documenten met specificaties schrijven (na meetings / klantcontact?

Tsurany schreef op donderdag 21 januari 2021 @ 23:33:
Heb je al gekeken naar een dev rol bij een bedrijf dat Agile werkt? Dan zit je constant in overleg met de stakeholders en kan je zelf kiezen of je wat meer design/analyse werk op pakt of juist meer dev werk.

Het is wel een goed punt dat bij bedrijven waar aparte business analists rondlopen de requirements documenten hele boekwerken worden, terwijl je juist (waar mogelijk) een korte functionele omschrijving zou willen hebben.
Het is ook een beetje ingegeven doordat ik denk dat ik het beter kan.

Zo Agile als Tsurany beschrijft zou mij zeker passen maar ik ben het nog niet tegenegekomen...

[_eLMo_]

Vooral bij kleinere bedrijven/teams zul je een bredere rol op je kunnen nemen is mijn ervaring. Ik heb in de afgelopen 10 jaar alleen maar agile gewerkt. Een project waar men aan komt met een lang document met requirements is niet aan mij besteed.
Wat niet betekent dat dat in sommige gevallen niet bittere noodzaak is (militair / embedded / finance vaak), maar ik vind het gewoon niet leuk werken, dat is een ander slag mensen.
Ik zou gewoon op zoek gaan naar een functie met meer klant contact.

Een van de redenen waarom ik wissel tussen backends (technisch uitdagender) en mobile (leuker / meer klantcontact / tastbaar product in je handen).

[PomPomPom]

wiemelen schreef op donderdag 21 januari 2021 @ 23:34:
Je kan ook overwegen om uit te kijken naar een soort devops functie.
Klassieke onderscheid tussen informatie analist, functioneel ontwerper en developer komt minder en minder voor in mijn ervaring.
Ik ben zelf developer, maar voer ook taken uit die traditioneel bij een informatie analist , functioneel ontwerper en tester liggen. De ene sprint wat meer developen, de andere meer analyseren. Houdt je werk afwisselend en zeker je developer kennis geeft je net dat beetje meer technisch inzicht.

Ik heb altijd devops gezien als een soort van systeem beheer: als de software klaar is dan mag de sysadmin de deployment doen naar tst of acc of prod. En daarvoor natuurlijk, zorgen dat CI/CD staat etc.

[Tsurany]

PomPomPom schreef op vrijdag 22 januari 2021 @ 10:42:
[...]


[...]


Het is wel een goed punt dat bij bedrijven waar aparte business analists rondlopen de requirements documenten hele boekwerken worden, terwijl je juist (waar mogelijk) een korte functionele omschrijving zou willen hebben.
Het is ook een beetje ingegeven doordat ik denk dat ik het beter kan.

Zo Agile als Tsurany beschrijft zou mij zeker passen maar ik ben het nog niet tegenegekomen...

Toch werken heel veel bedrijven, groot en klein, met die agile methode. Volgens mij zijn bijvoorbeeld alle grote banken al overgestapt, weliswaar met wisselend succes, en veel andere bedrijven met eigen IT afdelingen hebben agile al omarmd.
Zoek simpelweg naar "vacature java ontwikkelaar agile" en je komt genoeg tegen.

Misschien zit ik er naast maar op basis van dit topic heb ik het idee dat je jaren lang bent blijven hangen in een functie zonder jezelf te ontwikkelen en op de hoogte te blijven van wat er gebeurd in je vakgebied.

PomPomPom schreef op vrijdag 22 januari 2021 @ 11:22:
[...]


Ik heb altijd devops gezien als een soort van systeem beheer: als de software klaar is dan mag de sysadmin de deployment doen naar tst of acc of prod. En daarvoor natuurlijk, zorgen dat CI/CD staat etc.

DevOps is in principe een samensmelting van development en operations in een enkel team. You build it, you run it. En wat je doorgaans ziet is dat deze ontwikkeling ook samen gaat met het omarmen van agile en business en IT dichter tegen elkaar aan zetten. Al hoeft dat natuurlijk niet, je kan agile developen zonder DevOps en je kan DevOps uitvoeren zonder agile te developen.

[Hydra]

PomPomPom schreef op vrijdag 22 januari 2021 @ 11:22:
Ik heb altijd devops gezien als een soort van systeem beheer: als de software klaar is dan mag de sysadmin de deployment doen naar tst of acc of prod. En daarvoor natuurlijk, zorgen dat CI/CD staat etc.

DevOps betekent gewoon dat je de beide rollen Dev en Ops in een team hebt. Dit afgezet tegenover de 'oude' manier waarbij systeembeheer in een aparte groep zat, en er een hoop over schuttingen gegooid werd, met het vingerwijzen als resultaat. En dit idee geldt natuurlijk niet alleen voor Dev en Ops, het is ook goed om bijv. Business Analysts onderdeel te laten zijn van het team. Dus toen was er nog een tijdje de term BusDevOps maar toen ook security erbij kwam en men moest gaan kiezen tussen SecDevOps, BusDevOps of toch SecBusDevOps is dat een beetje losgelaten.

De term DevOps wordt helaas nogal eens misbruikt als functietitel, maar da's vooral een rooie vlag dat bedrijven het niet snappen.

Hoe dan ook, veel agile bedrijven (denk Bol, ING, ABN, etc.) hebben business analysts geintegreerd zitten in de teams en dat werkt in mijn ervaring erg goed. Ik vind het als dev fijn als we iemand hebben die exact weet wat de business nodig heeft, zodat ik kan focussen op hoe we de dingen de ze nodig hebben gaan maken.

[wiemelen]

PomPomPom schreef op vrijdag 22 januari 2021 @ 11:22:
[...]
Ik heb altijd devops gezien als een soort van systeem beheer: als de software klaar is dan mag de sysadmin de deployment doen naar tst of acc of prod. En daarvoor natuurlijk, zorgen dat CI/CD staat etc.

Bij nalezen van mijn post zag ik dat ik niet heel duidelijk was
Binnen mijn bedrijf werken we via SAFE (Scaled Agile Framework).
Ik noem het altijd de "iets meer uitgebreide versie van Agile" toegepast op verschillende teams binnen een value stream. Binnen een team streven we er daarnaast ook naar om ieder individu zo breed mogelijk inzetbaar te maken. Dit zowel qua kennis in de diepte en breedte, alsook qua softskills en takenpakket.
Al valt dat in praktijk natuurlijk nooit zo mooi uit als de theorie pretendeert
Maar het geeft je wel de mogelijkheid om meer afwisseling te krijgen.
I.p.v. 100% programmeur zoals 20 jaar geleden, programmeer ik nu nog gemiddeld max 40% van mijn tijd. De rest ben ik met allerlei andere dingen bezig.

[Nvidiot]

Je zou ook eens kunnen kijken naar een functie als product owner. Daarmee ben je de brug tussen de klant en de ontwikkelaars. Op die manier houd je nog binding met de techniek, maar kun je ook meer sturen op wat er gemaakt wordt en beter de context begrijpen waarom iets gebouwd wordt.

[Charles Nasi]

Uit persoonlijke ervaring bij deze werkgever waar de twee vacatures van gelinkt zijn: Snelheid en doorzettingsvermogen is bij deze overheidsdienst zeer traag. Tevens is mijn partner analist. Bij een direct vergelijkbare overheidsdienst. Ze doet alles, behalve wat bij haar functie als analist hoort. Ik heb de indruk gekregen dat overheidsfuncties vaak volstaan met 'buzzwords', dan daadwerkelijk op inhoudsniveau: namen worden dus op invulling misbruikt.

Verder: Fantastische stap, maar de werkgever bepaald wel heel veel in deze...

[Tsurany]

Nvidiot schreef op vrijdag 22 januari 2021 @ 15:48:
Je zou ook eens kunnen kijken naar een functie als product owner. Daarmee ben je de brug tussen de klant en de ontwikkelaars. Op die manier houd je nog binding met de techniek, maar kun je ook meer sturen op wat er gemaakt wordt en beter de context begrijpen waarom iets gebouwd wordt.

Ik zou die functie niet snel aanraden in dit geval. Je moet daar toch wel bepaalde commerciële en politieke vaardigheden voor hebben.

[ongewoongewoon]

Ik werk als medior developer bij een webdev bedrijf waar 30+ m/v werken, en ik werk eigenljik best veel met mensen. Teamleden, Projectmanagers, Management, en een breed spectrum aan contactpersonen aan de kant van de klanten. Weet je zeker dat je binnen je vakgebied niet een baan kan vinden waar je iets meer sociaal contact maakt?

[jobr]

PomPomPom schreef op donderdag 21 januari 2021 @ 23:20:

Ik ben software developer (Java) maar ik overweeg om te gaan solliciteren op functies als
Informatie analist en/of functioneel ontwerper.

Realiseer je dat dit soort functies bij Agile / DevOps organisaties (komen er steeds meer) steeds meer verdwijnen. Alles wordt steeds meer door het team zelf gedaan. En het team bestaat meestal uit Ontwikkelaars. Misschien nog aangevuld door een business analist, soms nog een tester. Men verwacht dat iedereen dit soort rollen kan gaan vervullen (T-shape). Of dit reëel is, is een andere discussie.
Ook de functie beheerder zie je verdwijnen.

Wat dat betreft ben je in het voordeel als ontwikkelaar en ben dus ook in de gelegenheid om andere rollen te vervullen.
Dus misschien eens buurten bij zo'n organisatie.

[thof]

jobr schreef op vrijdag 22 januari 2021 @ 20:29:
[...]


Realiseer je dat dit soort functies bij Agile / DevOps organisaties (komen er steeds meer) steeds meer verdwijnen. Alles wordt steeds meer door het team zelf gedaan. En het team bestaat meestal uit Ontwikkelaars. Misschien nog aangevuld door een business analist, soms nog een tester. Men verwacht dat iedereen dit soort rollen kan gaan vervullen (T-shape). Of dit reëel is, is een andere discussie.
Ook de functie beheerder zie je verdwijnen.

Wat dat betreft ben je in het voordeel als ontwikkelaar en ben dus ook in de gelegenheid om andere rollen te vervullen.
Dus misschien eens buurten bij zo'n organisatie.

Ik wil dit inderdaad nog even schrijven. De banen van de meeste analisten staan redelijk op de tocht. De trend is toch wel dat je DevOps-teams krijgt waarbij het team zelf de analist-rol vervuld. Allemaal T-shape, eigenlijk net zo als dat de beheerder-rol compleet verdwenen is.

Dus het advies is inderdaad, kijk of je in zo'n team terecht kan komen. Dan ga je iets minder ontwikkelen en pak jij iets meer de analist taken op ;-)