Strakke deadlines en werkcultuur: is dit een red flag?

[Verwijderd]

Ik heb recent een sollicitatiegesprek gehad waarbij werd benadrukt dat het behalen van een story binnen de tijd nauwlettend in de gaten wordt gehouden. Bij tijdsoverschrijding gaan er direct 'alarmbellen' af. In mijn huidige functie is dit totaal anders: er is veel ruimte om meer tijd aan een feature te besteden omdat er vertrouwen is dat je het beste product levert. Daarbij hoef ik niets door te factureren aan klanten, wat het werk minder strak maakt.

Het nieuwe bedrijf heeft zowel interne als externe klanten, dus ik begrijp dat er voor externe klanten meer druk ligt op tijdigheid. Maar het lijkt erop dat deze cultuur ook geldt voor interne projecten en tooling.

Nu vraag ik me af: is dit een red flag en moet ik dit bedrijf vermijden? Of ben ik misschien een verwende ontwikkelaar die moet leren om niet altijd te optimaliseren en gewoon te leveren? Ik ben heel erg benieuwd naar jullie kijk hierop!

[CH4OS]

Hoe moeten wij bepalen of dit een red flag is? Ga erover in gesprek, loop eventueel een dagje met iemand op de afdeling waar je zou komen te werken mee om een beeld te krijgen van hoe men werkt en vraag dan dus ook hoe "strak" dit is voor het bedrijf, wat de consequenties e.d. bijvoorbeeld kunnen zijn. Wij kennen het bedrijf niet, kennen de werksfeer er ook niet, dus kunnen wij dit niet bepalen voor je. Wij moeten immers uitgaan van de informatie die je hier deelt.

[ Voor 7% gewijzigd door CH4OS op 23-09-2024 13:25 ]

[Bossie]

Het hoeft naar mijn inziens niet meteen een red flag te zien.

Afspraak is afspraak immers zeker icm externe partijen.

De vraag is voornamelijk hoe dit intern gemanaged word.

[F_J_K]

Ik zou vragen naar wie beslist over de deadline (heeft die verstand van zaken). En mag de kwaliteit lijden als de deadline niet wordt gehaald, of mag je op eigen gezag extra collega's toevoegen (9 mensen kunnen in 1 maand een kind baren)?

[jeroen3]

Alarmbellen in de zin van "je bent niet snel genoeg" of "er is onjuist ingeschat"?

[Coloir De]

nvm

[ Voor 99% gewijzigd door Coloir De op 23-09-2024 13:36 ]

[GarBaGe]

Om wat voor functie gaat dit?
In Software Engineering is Agile / Scrum uitgevonden omdat gebleken is (bij waterval) dat het schatten / voorspellen van de complexiteit eigenlijk niet te doen is.
Het idee van Scrum is dan ook om kleine stukjes werk te doen, omdat deze beter geschat kunnen worden (story points).
Zit je ernaast met een schatting, dan heb je dit maximaal aan het einde van de sprint in de gaten.
Zolang iemand een goede verklaring heeft waarom de schatting ernaast zat (bijvoorbeeld lijk in de kast), moet dit naar mijn idee geen probleem zijn.
Effectief kan je dus NOOIT harde afspraken maken, omdat je nooit 100% gegarandeerd iets kan afleveren.
Als een product owner of project manager dit dan toch doet, is dit zijn verantwoordelijkheid, niet die van de team leden.

[SiErRa]

Verwijderd schreef op maandag 23 september 2024 @ 13:19:
het behalen van een story binnen de tijd nauwlettend in de gaten wordt gehouden. Bij tijdsoverschrijding gaan er direct 'alarmbellen' af.

Bedoel je binnen de sprint, of bedoel je dat ze van een sprint eigenlijk een strokenplanning maken en storypoints verhalen in uren? Dat laatste is wel een red-flag. Maar wat nog belangrijker is wat er daarna gebeurd. Want software bouwen is nou eenmaal complex, is schatten is moeilijk.

Een wat positiever kijk erop, is dat ze bedoelen dat ze tijdens de standup goed in de gaten houden of meer junior ontwikkelaars niet vast lopen met waar ze mee bezig zijn. Maar dat is uit de context die je schetst niet gelijk op te maken.

[naitsoezn]

Dat er iemand een seintje krijgt als een planning niet gehaald wordt lijkt mij persoonlijk niet zo raar, maar wat er vervolgens daarna gebeurt is veel belangrijker. Sturen op 'doen wat je belooft' is imho geen rare cultuur, mits je de ruimte krijgt om (binnen grenzen) je eigen beloftes te doen, om het maar even zo te zeggen.

Als jij de consequenties moet ondergaan van het niet nakomen van andermans beloftes, dan zou ik nog eens drie keer nadenken of ik daar zou willen werken, maar als jij zelf wordt afgerekend op je eigen planning, dan lijkt me dat niet per se een ongezonde cultuur. Even kort door de bocht. Andersom geredeneerd (en wederom kort door de bocht): Aanrommelen totdat je zelf tevreden bent (naar eigen inzicht) lijkt me niet echt een productieve werkomgeving en zou ik zelf eerder als red flag bestempelen.

[ Voor 15% gewijzigd door naitsoezn op 23-09-2024 13:39 ]

[pennywiser]

Ik vind dit soort opmerkingen vooraf altijd bijzonder meh, en in die zin vind ik het vaak veelzeggend. Er zal zeker een reden voor zijn, maar getuige je huidige werk kan het ook anders. Voor mij was het een rode vlag, maar ik kan alleen voor mezelf spreken.

[pennywiser]

Bossie schreef op maandag 23 september 2024 @ 13:25:
De vraag is voornamelijk hoe dit intern gemanaged word.

Zo kan je het zeker ook bekijken. Echter geeft zo'n opmerking wmb ook al gelijk best een indruk van hoe er gemanaged wordt.

[_eLMo_]

Klinkt als consultancy / detachering / project bedrijf. Als een klant betaald per uur op een project, dan zit daar monitoring op ja.

[bonzz.netninja]

Het is iig een vlag die je even moet navragen. Als het behalen van je inschatting belangrijker is dan gewoon goed werk leveren en/of werkplezier, dan zou ik er geen zin in hebben.

Feit dat ze dit meteen benoemen zegt wel wat. Hebben ze dezelfde stelligheid over zaken die werkplezier of ontwikkeling aangaan?

[GarBaGe]

naitsoezn schreef op maandag 23 september 2024 @ 13:37:
Dat er iemand een seintje krijgt als een planning niet gehaald wordt lijkt mij persoonlijk niet zo raar, maar wat er vervolgens daarna gebeurt is veel belangrijker. Sturen op 'doen wat je belooft' is imho geen rare cultuur, mits je de ruimte krijgt om (binnen grenzen) je eigen beloftes te doen, om het maar even zo te zeggen.

Als jij de consequenties moet ondergaan van het niet nakomen van andermans beloftes, dan zou ik nog eens drie keer nadenken of ik daar zou willen werken, maar als jij zelf wordt afgerekend op je eigen planning, dan lijkt me dat niet per se een ongezonde cultuur. Even kort door de bocht. Andersom geredeneerd (en wederom kort door de bocht): Aanrommelen totdat je zelf tevreden bent (naar eigen inzicht) lijkt me niet echt een productieve werkomgeving en zou ik zelf eerder als red flag bestempelen.

Een story is onderdeel van een (Scrum) sprint.
Een sprint is geen planning, het is een verwachting.
Een sprint "beloof" je niet te halen, het team probeert via een sprint aan te geven wat waarschijnlijk realistisch is om te halen.
Software engineering is een hele complexe materie en daarmee heel moeilijk te plannen.

Afgerekend worden op een story of sprint is een "red flag".
Scrum is altijd een team-effort, dus nooit iets waar je individueel op afgerekend kan worden.

Als een organisatie dit forceert, zie je vanzelf dat teams extreem voorzichtig worden en hele lage story points per sprint gaan doen in een poging om te garanderen dat ze dat halen.
Hiermee haal je het hel concept van Agile onderuit.

[naitsoezn]

GarBaGe schreef op maandag 23 september 2024 @ 14:08:
[...]

Afgerekend worden op een story of sprint is een "red flag".
Scrum is altijd een team-effort, dus nooit iets waar je individueel op afgerekend kan worden.

"Afgerekend worden op" is iets wat er in dit topic bijverzonnen wordt. De oorspronkelijke TS benoemt "alarmbellen gaan af". Dat is imho iets heel anders en lijkt mij persoonlijk niet meer dan normaal. Als je de planning niet haalt verwachting niet waarmaakt, dan is je planning verwachting niet uitgekomen. Goed om even te bekijken waar dat door komt, nietwaar? Kun je alleen maar van leren

offtopic:
Volgens mij heb jij geen idee of ik wel of niet bekend ben met stories en (scrum) sprints. Nergens voor nodig om net te doen alsof ik dat niet zou weten.

[Croga]

naitsoezn schreef op maandag 23 september 2024 @ 14:12:
[...]

"Afgerekend worden op" is iets wat er in dit topic bijverzonnen wordt. De oorspronkelijke TS benoemt "alarmbellen gaan af". Dat is imho iets heel anders en lijkt mij persoonlijk niet meer dan normaal. Als je de planning niet haalt verwachting niet waarmaakt, dan is je planning verwachting niet uitgekomen. Goed om even te bekijken waar dat door komt, nietwaar? Kun je alleen maar van leren

offtopic:
Volgens mij heb jij geen idee of ik wel of niet bekend ben met stories en (scrum) sprints. Nergens voor nodig om net te doen alsof ik dat niet zou weten.

In software land is iedere minuut die je spendeert aan betere schattingen proberen te krijgen pure waste. Waar het vandaan komt dat de verwachting niet waargemaakt wordt is al lang bekend: Software development valt in Cynefin in het complexe domein en is daarmee intrinsiek onschatbaar. De verwachting is niet uitgekomen omdat we dit dingetje nog nooit gedaan hebben en dus niet weten wat er allemaal bij komt kijken. Dat weet je pas als je het aan het doen bent.

Om een voorbeeld te noemen: Ik zit in de datawereld en we ontsluiten dagelijks SQL bronnen naar datawarehouses. Simpel toch? Oracle bron ontsluiten zal dus ook geen issue zijn. Kost een dag.
2 weken later zijn we er eindelijk achter waarom de Oracle data niet binnen wil komen. De combinatie van een specifieke versie van Microsoft Fabric met deze specifieke versie van Oracle zorgt er voor dat decimale velden niet gelezen kunnen worden omdat Oracle metadata niet mee stuurt die Fabric wel vereist.
Moeten we dan tijd steken in dat uit te zoeken? Nee. De volgende keer is er namelijk een andere versie van Oracle en een andere versie van Fabric en is het redelijk aan te nemen dat er daarmee ook andere uitdagingen zullen zijn. Of niet en dan lukt het wel binnen een dag.

Software developmen inschatten is natte vinger werk en kan best 10 keer zoveel tijd of 1/10e van de tijd kosten. Zo simpel is het nou eenmaal.

Afgerekend worden op het wel of niet halen van planningen in software development is een gigantische red flag. Dat weten we al tientallen jaren en toch blijven sommigen er in geloven dat planningen heilig zijn. Er is een woord voor steeds hetzelfde doen en toch een andere uitkomst verwachten. Maar dat is exact wat er hier gebeurt.

[ Voor 7% gewijzigd door Croga op 23-09-2024 14:22 ]

[Sethro]

GarBaGe schreef op maandag 23 september 2024 @ 13:35:
Om wat voor functie gaat dit?
In Software Engineering is Agile / Scrum uitgevonden omdat gebleken is (bij waterval) dat het schatten / voorspellen van de complexiteit eigenlijk niet te doen is.
Het idee van Scrum is dan ook om kleine stukjes werk te doen, omdat deze beter geschat kunnen worden (story points).
Zit je ernaast met een schatting, dan heb je dit maximaal aan het einde van de sprint in de gaten.
Zolang iemand een goede verklaring heeft waarom de schatting ernaast zat (bijvoorbeeld lijk in de kast), moet dit naar mijn idee geen probleem zijn.
Effectief kan je dus NOOIT harde afspraken maken, omdat je nooit 100% gegarandeerd iets kan afleveren.
Als een product owner of project manager dit dan toch doet, is dit zijn verantwoordelijkheid, niet die van de team leden.

Op zich eens maar team moet wel voldoende voortgang maken en dus voldoende story points per sprint opleveren. Dat er tijdens een sprint misschien punten bijkomen of stories worden omgewisseld dan is dat iets voor de PO om uit te leggen.

Iets meer monitoring zorgt meestal ook voor meer duidelijkheid wat meestal lekkerder werkt. Maar als je nu een 9-3u mentaliteit hebt en de halve dag bij de koffie rondhangt dan zal zoiets wel wennen zijn.

[ Voor 9% gewijzigd door Sethro op 23-09-2024 14:31 ]

[Verwijderd]

Ik snap dat men meer context wilt, maar bij een eerste gesprek kan je niet alles mee pakken helaas. Hoe 'erg' het is dus is in het echt is moeilijk in te schatten. Behalve dat er wel gezegd werd dat men verwacht dat als je een inschatting maakt dit kan waarmaken en als dit niet lukt 'alarmbellen' gaan rinkelen. Dat inderdaad ook een gevolg is dat PO de scope moet inperken, maar in hoeverre je hier op wordt afgerekend is mij ook onduidelijk. Deze twee opmerkingen brachten mij echter een beetje een nare nasmaak; wellicht terecht of niet. Wellicht inderdaad in een vervolg gesprek dit verder aankaarten met een medewerker om hun ervaring hierover te krijgen.

Mijn persoonlijke ervaring is ook dat dit extreem contentieus en ik heb menig week versleten aan iets wat 2 story points waren en soms een kwartier aan iets wat 8 is.

[theHoff]

Lijkt me in eerste instantie het "probleem" van je scrum master en vooral je PO toch?

[Sethro]

theHoff schreef op maandag 23 september 2024 @ 14:31:
Lijkt me in eerste instantie het "probleem" van je scrum master en vooral je PO toch?

Dat zullen wel de personen zijn die de alarmbellen doen afgaan. Ik denk dat er hiermee wordt bedoeld dat er voldoende productie wordt gedraaid. M.a.w. voldoende punten per dag / week / sprint.

[theHoff]

Sethro schreef op maandag 23 september 2024 @ 14:33:
[...]


Dat zullen wel de personen zijn die de alarmbellen doet afgaan. Ik denk dat er hiermee wordt bedoeld dat er voldoende productie wordt gedraaid. M.a.w. voldoende punten per dag / week / sprint.

Als er een beetje netjes Agile gewerkt wordt dan bepaalt het team (in principe) zelf hoeveel werk er uit de sprint komt. Komt er niet uit de sprint wat vooraf gepland is dan moet er volgende sprint minder ambitieus gepland worden. Over het algemeen is het dan aan de PO en eventueel scrum master om te zorgen dat de planningen een beetje kloppen.
Blijkt er te weinig toegevoegde waarde uit de sprints te komen (ook, of juist vooral, vergeleken met andere teams) dan is het wat mij betreft logisch en goed dat er dan alarmbellen afgaan. Vaak is dat een indicatie dat er iets in het team aan de hand is. Problemen in samenwerking, op persoonlijk vlak, onduidelijke requirements, slechte tooling etc etc.
Alarmbellen hoeven niet perse iets slechts te zijn. Het kan ook een trigger zijn voor extra ondersteuning, extra ruimte voor opleidingen, teambuilding sessies, ruimte voor betere tooling etc.

[Sissors]

Croga schreef op maandag 23 september 2024 @ 14:20:
[...]

In software land is iedere minuut die je spendeert aan betere schattingen proberen te krijgen pure waste. Waar het vandaan komt dat de verwachting niet waargemaakt wordt is al lang bekend: Software development valt in Cynefin in het complexe domein en is daarmee intrinsiek onschatbaar. De verwachting is niet uitgekomen omdat we dit dingetje nog nooit gedaan hebben en dus niet weten wat er allemaal bij komt kijken. Dat weet je pas als je het aan het doen bent.

Om een voorbeeld te noemen: Ik zit in de datawereld en we ontsluiten dagelijks SQL bronnen naar datawarehouses. Simpel toch? Oracle bron ontsluiten zal dus ook geen issue zijn. Kost een dag.
2 weken later zijn we er eindelijk achter waarom de Oracle data niet binnen wil komen. De combinatie van een specifieke versie van Microsoft Fabric met deze specifieke versie van Oracle zorgt er voor dat decimale velden niet gelezen kunnen worden omdat Oracle metadata niet mee stuurt die Fabric wel vereist.
Moeten we dan tijd steken in dat uit te zoeken? Nee. De volgende keer is er namelijk een andere versie van Oracle en een andere versie van Fabric en is het redelijk aan te nemen dat er daarmee ook andere uitdagingen zullen zijn. Of niet en dan lukt het wel binnen een dag.

Software developmen inschatten is natte vinger werk en kan best 10 keer zoveel tijd of 1/10e van de tijd kosten. Zo simpel is het nou eenmaal.

Afgerekend worden op het wel of niet halen van planningen in software development is een gigantische red flag. Dat weten we al tientallen jaren en toch blijven sommigen er in geloven dat planningen heilig zijn. Er is een woord voor steeds hetzelfde doen en toch een andere uitkomst verwachten. Maar dat is exact wat er hier gebeurt.

Nu werk ik zelf in hardware ontwikkeling, maar daar heb je vergelijkbare zaken natuurlijk. En natuurlijk, het kan zomaar zijn dat een subtaak toch tegen viel en een stuk langer duurde dan verwacht. En een andere viel mee. Maar onder de streep moet je toch gewoon planningen en deadlines hebben? Als ik jullie bedrijf vraag om te zorgen dat mijn bedrijf automatisch de data kan verwerken van een derde partij, dan komen jullie toch ook niet aan met: "Prima, hier tekenen graag. En dan heb je het over twee maanden beschikbaar. Of twee jaar. Misschien nog wat langer. Dat kan je eigenlijk niet plannen."

[Basekid]

Mwah vind het wel normaal dat je elkaar scherp houdt met dat stories binnen de afgesproken sprint af zijn. Werk vaak genoeg met teams samen waar het allemaal beetje half-half loopt en dan merk je dat afstemmen met elkaar niet echt te doen is...

[Eddos]

Verwijderd schreef op maandag 23 september 2024 @ 14:31:
Ik snap dat men meer context wilt, maar bij een eerste gesprek kan je niet alles mee pakken helaas. Hoe 'erg' het is dus is in het echt is moeilijk in te schatten. Behalve dat er wel gezegd werd dat men verwacht dat als je een inschatting maakt dit kan waarmaken en als dit niet lukt 'alarmbellen' gaan rinkelen. Dat inderdaad ook een gevolg is dat PO de scope moet inperken, maar in hoeverre je hier op wordt afgerekend is mij ook onduidelijk. Deze twee opmerkingen brachten mij echter een beetje een nare nasmaak; wellicht terecht of niet. Wellicht inderdaad in een vervolg gesprek dit verder aankaarten met een medewerker om hun ervaring hierover te krijgen.

Mijn persoonlijke ervaring is ook dat dit extreem contentieus en ik heb menig week versleten aan iets wat 2 story points waren en soms een kwartier aan iets wat 8 is.

Tja. Het heet niets voor niets een schatting van story points. Ik vind het zelf fijn (als PO/BA) om te werken met betrouwbare schattingen. Ik zou er gewoon op door vragen. Als wij bij de retro's constateerden dat de inschatting ver van de realiteit lagen, keken we altijd wel waar dat aan lag.

[eric.1]

Verwijderd schreef op maandag 23 september 2024 @ 14:31:
Behalve dat er wel gezegd werd dat men verwacht dat als je een inschatting maakt dit kan waarmaken en als dit niet lukt 'alarmbellen' gaan rinkelen.

Ik vind dit toch een rare manier om dit te verwoorden vanuit hun kant eerlijk gezegd.

Tuurlijk, idealiter kan je een inschatting waarmaken. Echter heet het een inschatting voor een reden; het is geen garantie en niemand kan dit garanderen.

Daarnaast is het vooraf correct (tm) inschatten van tijd wel echt iets waar je wat ervaring voor nodig hebt, ook ervaring binnen het bedrijf waar je werkt. Hoe gaan ze je helpen om die inschatting correct te maken? Hoe gaan ze je helpen om je in te werken zodat je op een degelijke tempo je werk kan doen, en hoe lang krijg je hiervoor? ...

Al in het eerste gesprek met 'alarmbellen' gooien, is raar. Ik snap je twijfels wel.

[Ernemmer]

Ik denk dat je jezelf eigenlijk even moet afvragen of je wel onder tijdsdruk wilt werken en dingen afleveren die je zelf niet perfect vind.

Persoonlijk maak ik liever mooie dingen in wat meer tijd dan dingen onder tijdsdruk de deur uit doen waar ik niet tevreden over ben.

[olafmol]

Ik denk dat je dit niet hier moet vragen, maar bij het bedrijf in kwestie.

[CH4OS]

Ernemmer schreef op maandag 23 september 2024 @ 14:46:
Ik denk dat je jezelf eigenlijk even moet afvragen of je wel onder tijdsdruk wilt werken en dingen afleveren die je zelf niet perfect vind.

Persoonlijk maak ik liever mooie dingen in wat meer tijd dan dingen onder tijdsdruk de deur uit doen waar ik niet tevreden over ben.

Ik denk dat de soep niet zo heet gegeten wordt als het wordt opgediend. Maar om daar achter te komen kan dat op maar 1 manier: bedrijf in kwestie bevragen.

[WernerL]

Ik neem aan dat dit een software development baan is? In dat geval is dat imho wel een red-flag ja. Inschattingen zijn altijd fout, en wanneer je werknemers continue onder tijdsdruk zet dan gaan developers vooral de focus leggen op het afkrijgen van een story en gaat de kwaliteit omlaag. Het wordt snel in elkaar geprutst om het maar op tijd af te krijgen. Laat dit lang genoeg doorgaan en je eindigt met een ongelofelijke bagger code-base waarin het steeds moeilijker wordt om aanpassingen in te maken.

Ik zou verder zoeken.

[ Voor 0% gewijzigd door WernerL op 24-09-2024 09:31 . Reden: Typo ]

[djmuggs]

F_J_K schreef op maandag 23 september 2024 @ 13:30:
Ik zou vragen naar wie beslist over de deadline (heeft die verstand van zaken). En mag de kwaliteit lijden als de deadline niet wordt gehaald, of mag je op eigen gezag extra collega's toevoegen (9 mensen kunnen in 1 maand een kind baren)?

Ik denk dat je dan 18 mensen nodig hebt, want op een hoop plekken duurt een sprint 2 weken.

[fonsoy]

Als jij zelf de inschatting mag bepalen, dan zou ik het geen enkel probleem vinden.
Mijn vorige werkgever was behoorlijk strak op de deadlines. Soms kreeg ik weleens wat over van een collega, maar wat ik altijd deed was eerst de inschatting controleren. Als die onhaalbaar was begon ik er niet aan, omdat je dan namelijk altijd verliest in de discussie later.
Na wat getouwtrek kon ik dan eigenlijk altijd een nieuwe inschatting maken.

[ Voor 12% gewijzigd door fonsoy op 23-09-2024 21:04 ]

[SPee]

En dit bedrijf lijkt hier ook zo in te zitten.
Dan is het de vraag of je wilt werken bij een bedrijf waar je regelmatig discussies zult hebben over de geplande uren. Wil je dat aangaan?
Misschien dat het meevalt, maar daar moet je wat meer over het bedrijf, de cultuur en de collega's weten.
Bij vriendelijke, relaxte mensen zou ik dit als een min-punt meewegen. Maar bij een strakke, zakelijke omgeving dit wel als een grote rode vlag klassificeren.

[Polonium]

Ik zou dit wel degelijk zien als een red flag.

Voornamelijk ook omdat het zelden aan de developer is om een tijdsinschatting te maken. De mensen die de inschatting maken doen zelf niet het werk, en ervaren niet de problemen die bij ogenschijnlijk kleine issues zich voor kunnen doen.
En al zou je wel zelf de inschatting mogen/moeten maken: er ligt toch een bepaalde druk op je om geen ruime inschattingen te maken, al was het maar omdat ze vast ook vergelijkingen zullen trekken met andere developers.

Bovendien zijn refactorings en cleanups in zo'n bedrijfscultuur vaak minder aan de orde, denk ik.

Tijdsinschattingen zijn vaak sowieso een farce: je kan hooguit zeggen of een issue naar verwachting klein, middelgroot, of groot is. Zelfs een resolutie van x aantal dagen is een beetje onzinnig naar mijn idee, tenzij je de taken echt heel klein maakt.

Besef ook even dat werkgeluk o.a. sterk voortkomt uit (oprechte) collegiale waardering, autonomie en het niveau van je collega's.
Dit klinkt niet als een bedrijf dat die zaken als prioriteit ziet.

[ Voor 10% gewijzigd door Polonium op 24-09-2024 02:06 ]

[Polonium]

WernerL schreef op maandag 23 september 2024 @ 18:36:
Ik neem aan dat dit een software development baan is? In dat geval is dat imho wel een red-flag ja. Inschattingen zijn altijd fout, en wanneer je werknemers continue onder tijdsdruk zet dan gaan developers vooral de focus leggen op het afkrijgen van een story en gaat de kwaliteit omlaag. Het wordt snel in elkaar geprutst om het maar op tijd af te krijgen. Laat dit lang genoeg doorgaan en je eindigt met een ongelijke bagger code-base waarin het steeds moeilijker wordt om aanpassingen in te maken.

Ik zou verder zoeken.

100% eens.

De enige rem op deze ontsporing door tijdsdruk zou nog een degelijk review proces kunnen zijn, door seniors.

Maar dan neem je als sollicitant een grote gok.

[Douweegbertje]

Verwijderd schreef op maandag 23 september 2024 @ 14:31:
Ik snap dat men meer context wilt, maar bij een eerste gesprek kan je niet alles mee pakken helaas. Hoe 'erg' het is dus is in het echt is moeilijk in te schatten. Behalve dat er wel gezegd werd dat men verwacht dat als je een inschatting maakt dit kan waarmaken en als dit niet lukt 'alarmbellen' gaan rinkelen. Dat inderdaad ook een gevolg is dat PO de scope moet inperken, maar in hoeverre je hier op wordt afgerekend is mij ook onduidelijk. Deze twee opmerkingen brachten mij echter een beetje een nare nasmaak; wellicht terecht of niet. Wellicht inderdaad in een vervolg gesprek dit verder aankaarten met een medewerker om hun ervaring hierover te krijgen.

Mijn persoonlijke ervaring is ook dat dit extreem contentieus en ik heb menig week versleten aan iets wat 2 story points waren en soms een kwartier aan iets wat 8 is.

Ik snap je vraag wel en ik zou direct al afhaken omdat het mij persoonlijk niet ligt. Het feit dat het probleem eigenlijk direct al bij jou wordt neergelegd is dan uiteindelijk mijn grootste probleem. Zeker in een sollicitatiegesprek. Ik had liever gehoord hoe ze zorgen, als bedrijf/proces/cultuur, dat er geen alarmbelletjes in eerste instantie afgaan. Een gesprek kan twee kanten op gaan hé. Dus in plaats van dat geneuzel, zou het veel toffer zijn om te horen hoe jij in staat wordt gezet om je werk fatsoenlijk te doen.

Je bent nog niet eens begonnen en je hebt eigenlijk al stress van zo'n kudt opmerking.

Maar goed, ieder zijn ding. Er zijn ook mensen die structuur en waarschijnlijk een stuk micromanagement wel waarderen of zelfs nodig hebben. Dus wat dat betreft is het altijd heel persoonlijk, maar absoluut een gif rode vlag van mij

[Croga]

Sissors schreef op maandag 23 september 2024 @ 14:39:
Nu werk ik zelf in hardware ontwikkeling, maar daar heb je vergelijkbare zaken natuurlijk. En natuurlijk, het kan zomaar zijn dat een subtaak toch tegen viel en een stuk langer duurde dan verwacht. En een andere viel mee. Maar onder de streep moet je toch gewoon planningen en deadlines hebben? Als ik jullie bedrijf vraag om te zorgen dat mijn bedrijf automatisch de data kan verwerken van een derde partij, dan komen jullie toch ook niet aan met: "Prima, hier tekenen graag. En dan heb je het over twee maanden beschikbaar. Of twee jaar. Misschien nog wat langer. Dat kan je eigenlijk niet plannen."

Dat zijn dan ook geen interessante opdrachten. Een opdracht is interessant als het over een langdurige verbintenis gaat en de scope variabel is. Software ontwikkeling is als het laten maken van een schilderij; je vertrouwd elkaar er op dat je het beste met elkaar voor hebt en je weet dat hetgene waar voor gecontracteerd is, het belangrijkste is wat er moet gebeuren.

Ofwel: Als die data verwerkt moet worden dan is het dus niet belangrijk hoe lang het duurt aangezien die data verwerken gewoon geld oplevert. En dus gaan we aan de slag in de wetenschap dat;
- Dit moet gebeuren
- We het vertrouwen hebben dat iedereen zijn best doet om te zorgen dat dit zo goed mogelijk en zo snel mogelijk gebeurt

Als aan die twee voorwaarden voldaan wordt dan weten we dat het goed zal komen.

Maar ik begrijp dat de meeste mensen in bedrijven niet snappen dat het zo werkt. Er wordt nog veel te veel gekeken om mensen af te rekenen op zaken waar ze helemaal geen controle over hebben. De meest stompzinnige instelling die er bij bedrijven te zien is.

Je moet je helemaal niet afvragen waarom iets niet op tijd af is. Je moet je eerst eens afvragen: Wat maakt het uit dat iets langer (of korter) duurt? Hoe zou de wereld anders zijn geweest als men een hogere schatting had af gegeven?
Schattingen in software land zijn verworden tot liegen bij devies. Niemand weet hoe lang iets duurt maar iedereen wordt gedwongen toch een getalletje af te geven. We liegen allemaal glashard tegen elkaar omdat er iemand ooit bedacht heeft dat leugens belangrijker zijn dan gewoon je werk doen.

[Yucon]

Ik zou wel benieuwd zijn naar hun inschattingsmethodieken. Sommige soorten software ontwikkeling laten zich beter inschatten dan andere, en wie weet hebben ze veel moeite in de perfectionering van de schattingen gestoken. In het standpunt lees ik ook wel een beetje 'beloven wat je doet'. Dat hoeft niet perse verkeerd te zijn en heeft ook positieve aspecten. Ook voor de werknemer.

[Falcon]

Ik vraag mij af hoe “ready” het werk bij dit bedrijf is?

Ook het sturen met alarmbellen op storypoints is niet gezond en ook niet het idee er achter bij Scrum.

[Wilke]

Als er nog een vervolg gesprek is zou ik er zeker op doorvragen. Er gaan alarmbellen af. Ok, en wat gebeurt er dan? Wat zijn vervolg-acties?

Mij klinkt het absoluut als een rode vlag, overigens.

Klinkt als: er gaan alarmbellen af, met als gevolg, bij de developer verhaal halen "waarom heb je de schatting niet gehaald". Hierboven heeft iemand al goed beschreven waarom dit weinig zinvol is.

[Sissors]

Croga schreef op dinsdag 24 september 2024 @ 06:16:
[...]

Dat zijn dan ook geen interessante opdrachten. Een opdracht is interessant als het over een langdurige verbintenis gaat en de scope variabel is. Software ontwikkeling is als het laten maken van een schilderij; je vertrouwd elkaar er op dat je het beste met elkaar voor hebt en je weet dat hetgene waar voor gecontracteerd is, het belangrijkste is wat er moet gebeuren.

Ofwel: Als die data verwerkt moet worden dan is het dus niet belangrijk hoe lang het duurt aangezien die data verwerken gewoon geld oplevert.

Maar dit spreekt jezelf toch tegen? Het levert geld op voor dat bedrijf, en dus willen ze weten wanneer het werkt. Anders gaan ze wel naar de concurrent als jullie er 3x zo lang over doen om het in elkaar te krijgen. Een klant van jullie wil een product hebben dat werkt, daar betalen ze voor.

Maar ik begrijp dat de meeste mensen in bedrijven niet snappen dat het zo werkt. Er wordt nog veel te veel gekeken om mensen af te rekenen op zaken waar ze helemaal geen controle over hebben. De meest stompzinnige instelling die er bij bedrijven te zien is.

Nofi, maar het klinkt meer alsof software mensen denken dat het bij hun allemaal anders is dan bij andere groepen die dingen moeten ontwerpen. Natuurlijk kan je geen 100% gegarandeerde deadlines geven. Maar als je iets verkoopt aan een ander bedrijf, willen ze wel ruwweg weten wanneer ze het kunnen verwachten. Misschien als je aan de overheid verkoopt als grote consultancy firma kan je wegkomen met eeuwig durende vertragingen en kosten overschrijdingen, maar anders niet.

Je moet je eerst eens afvragen: Wat maakt het uit dat iets langer (of korter) duurt? Hoe zou de wereld anders zijn geweest als men een hogere schatting had af gegeven?

Nou het bedrijf had een hoop geld meer / minder gehad? Als Nvidia een nieuwe GPU uitbrengt, dan kunnen ze toch ook niet aankomen met: "Tja de drivers voor dit ding is software, en je kan niet weten hoe lang dat duurt om te maken. Dus misschien werkt dit stukje silicium over een paar maanden. Misschien duurt het nog een paar jaar. Wat maakt het eigenlijk uit of hij wel of niet werkt?"

[RagingPenguin]

Sissors schreef op dinsdag 24 september 2024 @ 08:44:
Nofi, maar het klinkt meer alsof software mensen denken dat het bij hun allemaal anders is dan bij andere groepen die dingen moeten ontwerpen. Natuurlijk kan je geen 100% gegarandeerde deadlines geven. Maar als je iets verkoopt aan een ander bedrijf, willen ze wel ruwweg weten wanneer ze het kunnen verwachten. Misschien als je aan de overheid verkoopt als grote consultancy firma kan je wegkomen met eeuwig durende vertragingen en kosten overschrijdingen, maar anders niet.

Nofi, maar je doet nu wel net alsof mensen die software maken niet weten hoe software gemaakt word. Hoe dit in andere engineering disciplines gaat weet ik ook niet, maar ik ga ze niet vertellen dat ze het fout doen omdat wij het hier anders doen. Er zijn hier en daar nog wat clubjes die fixed-scope-fixed-fee doen met waterfall development, maar de overgrote meerderheid van software bedrijven is daar al een hele tijd vanaf gestapt. Misschien is dit anders dan in andere disciplines, misschien ook niet, maar dat maakt an sich natuurlijk ook niks uit.

[desmond]

Op welke twee componenten ligt de nadruk bij die organisatie? En voel je je daar oke bij?

[Croga]

Sissors schreef op dinsdag 24 september 2024 @ 08:44:
Maar dit spreekt jezelf toch tegen? Het levert geld op voor dat bedrijf, en dus willen ze weten wanneer het werkt. Anders gaan ze wel naar de concurrent als jullie er 3x zo lang over doen om het in elkaar te krijgen. Een klant van jullie wil een product hebben dat werkt, daar betalen ze voor.

Die concurrent heeft net zo goed geen flauw idee hoe lang ie er over gaat doen. Dat bedoel ik met vertrouwen.

Nofi, maar het klinkt meer alsof software mensen denken dat het bij hun allemaal anders is dan bij andere groepen die dingen moeten ontwerpen. Natuurlijk kan je geen 100% gegarandeerde deadlines geven. Maar als je iets verkoopt aan een ander bedrijf, willen ze wel ruwweg weten wanneer ze het kunnen verwachten. Misschien als je aan de overheid verkoopt als grote consultancy firma kan je wegkomen met eeuwig durende vertragingen en kosten overschrijdingen, maar anders niet.

Dat ze dat willen weten is omdat hen verteld is dat alles voorspelbaar is. En dus blijven we in die leugen geloven, ondanks het feit dat 70 jaar software ontwikkeling ons geleerd heeft dat het níet voorspelbaar is. We lossen dit op door geïnflateerde cijfers in onze leugens te stoppen. Beter inschatten kan namelijk niet.

Nou het bedrijf had een hoop geld meer / minder gehad? Als Nvidia een nieuwe GPU uitbrengt, dan kunnen ze toch ook niet aankomen met: "Tja de drivers voor dit ding is software, en je kan niet weten hoe lang dat duurt om te maken. Dus misschien werkt dit stukje silicium over een paar maanden. Misschien duurt het nog een paar jaar. Wat maakt het eigenlijk uit of hij wel of niet werkt?"

En toch is dat exact wat er gebeurt. Waarom denk je dat de meeste hardware een paar maanden na release pas de echte performance laat zien? Exact dit: We brengen het uit met een minimale driver en optimalisatie is onvoorspelbaar..... Waarom denk je dat het regelmatig gebeurt dat er bij release een enorme berg hardware beschikbaar is? Of dat de release van de hardware uitgesteld wordt?

Ja, op grote projecten zal iedere tegenvaller gebalanceerd worden door een meevaller. En toch heeft ieder fixed price project 25%-50% aan onzekerheidsmarge ingebouwd zitten, simpelweg omdat een creatief proces niet in te schatten is. Al 70 jaar zeggen we "Een software project is altijd duurder en later dan geschat". En met alle inspanning om die schattingen beter te maken is die zin nooit verdwenen.
Een wijs man heeft ooit iets gezegd over "Hetzelfde blijven doen en andere resultaten verwachten" en toch blijven we software projecten inschatten en hopen dat die schattingen enige waarde hebben ondanks dat ze dat de afgelopen 70 jaar nog *NOOIT* gehad hebben.

[Sissors]

Maar het is toch prima om met ruime marge in te schatten. Dat doen wij ook in hardware. En zelfs die is niet altijd correct. Maar laten we niet het doen alsof een Nvidia weg kan komen met jarenlang geen drivers hebben voor hun hardware omdat je dat nou eenmaal niet kan voorspellen, en hardware blijkbaar wel.

[Qwerty-273]

Verwijderd schreef op maandag 23 september 2024 @ 13:19:
Of ben ik misschien een verwende ontwikkelaar die moet leren om niet altijd te optimaliseren en gewoon te leveren?

In veel gevallen is dat stuk optimalisatie niet echt nodig. Of wel handig voor de langere termijn maar niet om een bepaalde functionaliteit op te leveren op een bepaalde datum. Misschien is er ook in het gesprek wat naast elkaar gecommuniceerd met onduidelijkheid op dat punt. Praat men vanuit een oude situatie met een project dat pas op het einde een milestone oplevert en tijdens het project eigenlijk geen enkele opleveringen waren (vaak uitloop zonder dat je dit ziet in rapportages want die kijken niet in detail), en dat men sinds kort de teugels strakker aantrekt via Agile met sprints en korte meetbare opleveringen? Of werkt men al heel lang agile en wordt er nu heel strak opgekeken door management? Als iets uitloopt kan het natuurlijk ook zijn dat je iets te breed hebt gespecificeerd waardoor je in de sprint periode gewoon te weinig tijd hebt.

[RagingPenguin]

Sissors schreef op dinsdag 24 september 2024 @ 10:54:
Maar het is toch prima om met ruime marge in te schatten. Dat doen wij ook in hardware. En zelfs die is niet altijd correct. Maar laten we niet het doen alsof een Nvidia weg kan komen met jarenlang geen drivers hebben voor hun hardware omdat je dat nou eenmaal niet kan voorspellen, en hardware blijkbaar wel.

Nvidia is een productbedrijf, die ontwikkelen intern iets, als het af is gaat het op de markt, en dan kunnen klanten het wel of niet kopen. Een product kopen is een hele andere (en veel simpelere) klantrelatie dan een project uitbesteden. Maar productbedrijven hebben we in software ook, en dat werkt ook enigszins hetzelfde. De versie die volgend jaar uitkomt bevat wat we binnen nu en volgend jaar ontwikkelen, en alles wat niet past zit er gewoon niet in. Zowel wij als Nvidia doen geen beloftes over toekomstige producten.

[CVTTPD2DQ]

Croga schreef op maandag 23 september 2024 @ 14:20:
Software development valt in Cynefin in het complexe domein en is daarmee intrinsiek onschatbaar. De verwachting is niet uitgekomen omdat we dit dingetje nog nooit gedaan hebben en dus niet weten wat er allemaal bij komt kijken. Dat weet je pas als je het aan het doen bent.

Dit klopt helemaal. Maar dan moeten we ook eerlijk zijn over de oorzaak ervan: het is het proces van software-ontwikkeling zelf dat voortdurend de piketpaaltjes verzet.

Volgens mij is het vijftig jaar geleden dat men over "software engineering" is gaan spreken, wat op zichzelf al een reactie was op het onvermogen van software ontwikkelaars om "gewoon" software te bouwen. We kunnen niet blijven doen alsof het een nieuw veld is waarbij we elke dag aan een soort experimentele kernreactor moeten werken.

[RagingPenguin]

CVTTPD2DQ schreef op dinsdag 24 september 2024 @ 17:25:
[...]


Dit klopt helemaal. Maar dan moeten we ook eerlijk zijn over de oorzaak ervan: het is het proces van software-ontwikkeling zelf dat voortdurend de piketpaaltjes verzet.

Maar dat is juist wenselijk? Ik heb het idee dat sommige niet-software-developers denken dat enkel budget en deadlines agile zijn, maar requirements zijn dat ook. Je stuurt een project op een samenspel tussen die drie, als enkel de eerste twee 'agile' zijn dan heb je gewoon een waterfall project.

"impervious to a reductionist, take-it-apart-and-see-how-it-works approach, because your very actions change the situation in unpredictable ways"

Volgens mij is het vijftig jaar geleden dat men over "software engineering" is gaan spreken, wat op zichzelf al een reactie was op het onvermogen van software ontwikkelaars om "gewoon" software te bouwen. We kunnen niet blijven doen alsof het een nieuw veld is waarbij we elke dag aan een soort experimentele kernreactor moeten werken.

Het zou natuurlijk kunnen dat alle software engineers onbekwaam zijn, maar we zouden dat soort neerbuigende generalisaties natuurlijk ook gewoon achterwege kunnen laten.

[Sito]

Voor mij zou dat direct een enorme red flag zijn. Software ontwikkeling is een team-effort en je zou er nooit individueel op afgerekend mogen worden.

Als je dat namelijk doet als bedrijf creëer je een werkomgeving waarin niemand elkaar helpt, kennis deelt of kwaliteit levert. Men gaat dan voor de snelste oplossing, omdat ze er anders op afgerekend kunnen worden.

Natuurlijk moet je ook niet doorslaan naar de andere kant. Het is de kunst om als team de juiste balans te vinden tussen features opleveren en kwaliteit leveren zodat je oplossing onderhoudbaar, testbaar, betrouwbaar etc. is. Maar daar komt ie weer: team!

[CVTTPD2DQ]

RagingPenguin schreef op dinsdag 24 september 2024 @ 18:11:
Maar dat is juist wenselijk? Ik heb het idee dat sommige niet-software-developers denken dat enkel budget en deadlines agile zijn, maar requirements zijn dat ook. Je stuurt een project op een samenspel tussen die drie, als enkel de eerste twee 'agile' zijn dan heb je gewoon een waterfall project.

Een andere verschuivende doelpaal is de technologie zelf. Continue veranderingen zorgen ervoor dat ontwikkelaars vrijwel voortdurend "nieuwe" dingen moeten leren en doen om zaken te bereiken die echt niet zo fundamenteel anders zijn dan wat ze 10 of 20 jaar geleden deden.

Daar komt binnenkort de doelpaal van wetgeving bij; de Cyber Resilience Act is een van de eerste duidelijke poging om minimale veiligheidseisen aan software (zoals die ook al bestaan voor hardware, of voedsel, of bijna alle andere producten) in de wet te verankeren.

In een sector die kostenbeheersing nastreeft zou je verwachten dat sterk gestuurd wordt op risicobeheersing en conservatief inzetten van technologie, zodat de voorspelbaarheid wordt verbeterd. Zo werkt de bouwsector, bijvoorbeeld. Praat met een aannemer over een aanbouw, en hij zal een offerte maken op basis van materialen die hij door en door kent. Wil je je aanbouw uitgevoerd in bubbledeck kalkhennep, dan wordt het uurtje factuurtje. Toch zijn we in de IT, onder het mom van "innovatie", sterk geneigd tot het tweede soort aanpak.

Het kenmerkende aan de IT-sector is een sterke verwachting van winsten (financieel, of op gebied van productiviteit), wat tot een overvloed aan investering heeft geleid. Hier in Nederland, maar ook in andere landen, nog aangejaagd door fiscale voordelen. Daar hoort een managementvorm bij die iedere vorm van aansprakelijkheid ontkent.

RagingPenguin schreef op dinsdag 24 september 2024 @ 18:11:
Het zou natuurlijk kunnen dat alle software engineers onbekwaam zijn, maar we zouden dat soort neerbuigende generalisaties natuurlijk ook gewoon achterwege kunnen laten.

Een beetje neerbuigendheid is wat mij betreft meer op z'n plaats dan de innovatiemystiek die het veld al decennia onterecht omringt.

[RagingPenguin]

CVTTPD2DQ schreef op dinsdag 24 september 2024 @ 20:56:
[...]

Daar komt binnenkort de doelpaal van wetgeving bij; de Cyber Resilience Act is een van de eerste duidelijke poging om minimale veiligheidseisen aan software (zoals die ook al bestaan voor hardware, of voedsel, of bijna alle andere producten) in de wet te verankeren.

Wat niks te maken heeft hoe je een project managed.

In een sector die kostenbeheersing nastreeft zou je verwachten dat sterk gestuurd wordt op risicobeheersing en conservatief inzetten van technologie, zodat de voorspelbaarheid wordt verbeterd.

Waarom?

Wat is überhaupt o zo belangrijk voor "voorspelbaarheid" dat alles anders moet? Je maakt technische keuzes om daadwerkelijke problemen op te lossen en waarde te creëren voor eindgebruikers, niet om het leven van de projectmanager makkelijker te maken. Tenzij die ook de rekening betaald is dat de verkeerde prioriteit.

Zo werkt de bouwsector, bijvoorbeeld. Praat met een aannemer over een aanbouw, en hij zal een offerte maken op basis van materialen die hij door en door kent. Wil je je aanbouw uitgevoerd in bubbledeck kalkhennep, dan wordt het uurtje factuurtje. Toch zijn we in de IT, onder het mom van "innovatie", sterk geneigd tot het tweede soort aanpak.

Een appels en peren vergelijking vanuit een kinderlijk simpel begrip van de wereld. De bouw werkt niet met fixed-fee-fixed-scope voor projecten in dezelfde prijs range als maatwerksoftware, ze hebben meer dan genoeg innovatie gehad in de afgelopen decennia, en als er een sector is die zowel record winsten schrijft als omver valt bij de eerste zucht van een recessie dan is het de bouw wel.

Het kenmerkende aan de IT-sector is een sterke verwachting van winsten (financieel, of op gebied van productiviteit), wat tot een overvloed aan investering heeft geleid. Hier in Nederland, maar ook in andere landen, nog aangejaagd door fiscale voordelen. Daar hoort een managementvorm bij die iedere vorm van aansprakelijkheid ontkent.

Het grote durfkapitaal is niet iets wat we veel zien software dienstverlening, daarvoor zijn de (potentiële) winsten en marges lang niet groot genoeg. Uren verkopen schaalt slecht, ongeacht hoeveel mensen je aanneemt blijft je winstmarge hetzelfde percentage tussen inkoop en verkoop. Het oneindige geld is er voornamelijk voor de digitale platform economie met bijna oneindig schaalbare winstmarges.

Een beetje neerbuigendheid is wat mij betreft meer op z'n plaats dan de innovatiemystiek die het veld al decennia onterecht omringt.

A ja, het "iedereen is gek en ik weet het allemaal beter".

[Bossie]

Croga schreef op dinsdag 24 september 2024 @ 10:34:

Ja, op grote projecten zal iedere tegenvaller gebalanceerd worden door een meevaller. En toch heeft ieder fixed price project 25%-50% aan onzekerheidsmarge ingebouwd zitten, simpelweg omdat een creatief proces niet in te schatten is. Al 70 jaar zeggen we "Een software project is altijd duurder en later dan geschat". En met alle inspanning om die schattingen beter te maken is die zin nooit verdwenen.
Een wijs man heeft ooit iets gezegd over "Hetzelfde blijven doen en andere resultaten verwachten" en toch blijven we software projecten inschatten en hopen dat die schattingen enige waarde hebben ondanks dat ze dat de afgelopen 70 jaar nog *NOOIT* gehad hebben.

Blijven we simpelweg niet estimates maken omdat er simpelweg ook kosten/budgetten mee gemoeid gaan?
Het is echt niet voor de software engineers zelf dat dit gedaan word, maar stakeholders moeten ook gemanaged geworden.

Ik zal het binnenkort eens proberen om een paar development requests te beantwoorden met: sorry, maar software development is een creatief process en deze niet in te schatten. We zien wel hoelang het duurt

[RagingPenguin]

Bossie schreef op dinsdag 24 september 2024 @ 22:49:
[...]


Blijven we simpelweg niet estimates maken omdat er simpelweg ook kosten/budgetten mee gemoeid gaan?
Het is echt niet voor de software engineers zelf dat dit gedaan word, maar stakeholders moeten ook gemanaged geworden.

Ik zal het binnenkort eens proberen om een paar development requests te beantwoorden met: sorry, maar software development is een creatief process en deze niet in te schatten. We zien wel hoelang het duurt

Het ding met stakeholders is dat ze vaak veel en heel nauwkeurige informatie willen waar ze vervolgens niks mee doen. Voor het grotere plaatje kan je vaak gerust hele grove schattingen geven, bijvoorbeeld voor features <1, 2 of 4 sprints en voor projecten in hele miljoenen aan budget. Vroeg in je proces al gaan inschatten dat A 8 punten is en B 13 punten etc om tot een prijs te komen van 3451 punten is in mijn ervaringen nergens goed voor en geeft enkel een verkeerd beeld af.

Wat in mijn ervaring ook vooral belangrijk is met schattingen is hoe en wat je communiceert, mensen zijn heel snel geneigd om nummers direct als absolute waardes met oneindige precisie te interpreten. Om te "doen wat je belooft" moet uitkijken dat je geen beloftes doet die niet waar kunt maken (of niet van weet of je ze kan waarmaken), dat je het met de beste intenties hebt belooft zorgt er niet voor dat je het ook sneller af hebt.

En tja, shareholder managen is soms ook 'nee' verkopen. Niemand heeft iets aan ja-knikkers die eigenlijk nee-denkers zijn.

[Bossie]

RagingPenguin schreef op dinsdag 24 september 2024 @ 23:19:
[...]


Het ding met stakeholders is dat ze vaak veel en heel nauwkeurige informatie willen waar ze vervolgens niks mee doen. Voor het grotere plaatje kan je vaak gerust hele grove schattingen geven, bijvoorbeeld voor features <1, 2 of 4 sprints en voor projecten in hele miljoenen aan budget. Vroeg in je proces al gaan inschatten dat A 8 punten is en B 13 punten etc om tot een prijs te komen van 3451 punten is in mijn ervaringen nergens goed voor en geeft enkel een verkeerd beeld af.

Wat in mijn ervaring ook vooral belangrijk is met schattingen is hoe en wat je communiceert, mensen zijn heel snel geneigd om nummers direct als absolute waardes met oneindige precisie te interpreten. Om te "doen wat je belooft" moet uitkijken dat je geen beloftes doet die niet waar kunt maken (of niet van weet of je ze kan waarmaken), dat je het met de beste intenties hebt belooft zorgt er niet voor dat je het ook sneller af hebt.

En tja, shareholder managen is soms ook 'nee' verkopen. Niemand heeft iets aan ja-knikkers die eigenlijk nee-denkers zijn.

Helemaal mee eens, ik reageer echter ook niet op jouw posts