gangstahh schreef op woensdag 07 september 2016 @ 13:49:
[...]
Ik vraag ook alleen maar om advies, wat hier de kijk is op deze kwestie. In het verleden heb ik soortgelijke projecten gehad alleen had dit veel al met software te maken (implementatie van nieuwe functionaliteit). Dit project is nieuw voor mij, dit is volledig gericht op onderzoek dus zonder enige implementatie (alleen een advies, de implementatie is niet aan mij). De vestigingsleider zegt ook dat het bij de medewerkers ligt, de handelingen die ze uitvoeren. Het zijn steekjes die ze loslaten, maar waar is onduidelijk. Dat is aan mij
Wat je doet of deed is geheel irrelevant!
Of je nou iets implementeert, ontwikkeld, analyseert, verbeterd - je zult altijd in een onderzoek dezelfde stappen doorlopen.
Het verzamelen van informatie, methodes bekijken om je probleem aan te pakken, combineren tot een overwogen 1e keuze en dan gaan. Als je tegen iets aanloopt in negatieve zin ga je terug naar je plan en kijk je wat er anders moet op basis van je nieuwe gegevens (andere methodiek, invalshoek, wat dan ook) en doe je het opnieuw. Als je tegen iets aanloopt in positieve zin doe je een check/test om je gegevens te bevestigen en ga je met dat resultaat aan de slag om vertaling naar de praktijk op te zetten.
Er is een reden dat je meestal begint met een pre-verslag, een plan van aanpak, waarin je eigenlijk de methode opzet om je project aan te sturen (het project, waarin je vervolgens een methodiek kiest gericht op de opdracht cq onderzoeksvraag).
Dat kun je toepassen op de ontwikkeling/verbetering van software, het bouwen van machines, processtromen op een afdeling of zelfs je eigen huishoudboekje thuis. Inventariseren, analyseren, combineren, verwerken, conclusie. Elke keer weer.
Pak 'software programma' als dataverwerker en verander dat naar 'afdeling' als dataverwerker, verander vervolgens de input 'bestand x' (of informatie x) naar stakeholder 'persoon x' (of beslissing x).
Pak 'boodschappen' als kosten en verandert dat naar 'product' als kosten, waarbij afhankelijkheid en variabele post 'seizoensgroentes' verandert wordt in afhankelijkheid en variabele post 'metaal'. Context is binnen methodieken slechts een woordje om een status te verhelderen, maar dat verandert de manier hoe je een status ziet of verwerkt niet.
Op het meest basis niveau, is er geen verschil in processtromen. Die zien geen verschil tussen in welke sector je werkt of wat je doet. Zoals jij denkt in context ben je eigenlijk al bezig met verwerken (hoe doe ik dit) en sla je de eerste cruciale stappen over.
Mooi voorbeeld stip je gelijk aan, namelijk de input dat het bij de medewerkers ligt die steekjes laten vallen. Alsof, terug naar jouw software context, iemand je zegt dat je niet naar een bestand x hoeft te kijken bij het zoeken naar een probleem, want daar ligt het zowiezo niet aan. In die context krijg je waarschijnlijk gelijk kriebels, en staat dat bestand gelijk bovenaan je lijst van degene die het probleem veroorzaakt.
Is er dan al onderzoek geweest om management(-keuzes) uit te sluiten? Of inrichting van het bedrijf(sproces)? Of aan gebrek aan tijd (mankracht)? Of personeelsbeleid (aanname personeel, vergoedingen..)?
Allemaal zaken die bij de baas liggen, niet de werknemers zelf waar de vinger nu zo snel naar wijst.
Het lijkt een kleine opmerking, maar als je het uitrolt eentje waarmee ineens een significant deel per direct wordt uitgesloten. Je begint dan namelijk met het uitsluiten van enkele enorme factoren zonder onderbouwing. Natuurlijk kun je in een stage er niet zo diep op in gaan, nogmaals, punt wat ik vooral erin probeer te hameren is dat je beter even een paar stappen terug kunt doen. Begin eens met dat vooronderzoek te doen.
[
Voor 66% gewijzigd door
Xanaroth op 07-09-2016 14:37
]