[Algemeen] Developer vs klant(interactie) *afgesplitst*

[Solopher]

Dit bericht is afgesplitst vanuit topic De Devschuur Coffee Corner - Iteratie 2

Dit is echt een RAMP! Een collega is papa geworden en is dus al enkele dagen afwezig, nu mag ik zijn "spoedjes" op gaan lossen. Probleem is dat dit ongeveer de grootste zeik klant is die we hebben, maar ik kan moeilijk vanuit zijn mailbox gaan reageren, heb natuurlijk geen zin om de rest van de week ook met "spoedjes" bezig te moeten. Even kijken hoe we dit gaan oplossen.

[ Voor 10% gewijzigd door BtM909 op 07-11-2012 17:51 ]

[Erwin537]

Solopher schreef op woensdag 07 november 2012 @ 10:10:
Dit is echt een RAMP! Een collega is papa geworden en is dus al enkele dagen afwezig, nu mag ik zijn "spoedjes" op gaan lossen. Probleem is dat dit ongeveer de grootste zeik klant is die we hebben, maar ik kan moeilijk vanuit zijn mailbox gaan reageren, heb natuurlijk geen zin om de rest van de week ook met "spoedjes" bezig te moeten. Even kijken hoe we dit gaan oplossen.

Stuur een zogenaamd 'automatisch gegenereerd' bericht terug met de melding dat de developer niet aanwezig is vanwege bovenstaande reden (of door 'omstandigheden') en meld dat de spoedjes nu voor zover mogelijk door een/de andere developer worden behandeld?

[Kayr]

Erwin537 schreef op woensdag 07 november 2012 @ 10:15:
[...]

Stuur een zogenaamd 'automatisch gegenereerd' bericht terug met de melding dat de developer niet aanwezig is vanwege bovenstaande reden (of door 'omstandigheden') en meld dat de spoedjes nu voor zover mogelijk door een/de andere developer worden behandeld?

Spoed, spoed, alleen als ik moet scheiten is er spoed Voor de rest, maak maar een ticket of CR aan

[GateKeaper]

Erwin537 schreef op woensdag 07 november 2012 @ 10:15:
[...]

Stuur een zogenaamd 'automatisch gegenereerd' bericht terug met de melding...

Of je stuurt niet 'zogenaamd automatisch' een bericht. Maar stuurt de klant/opdrachtgever gewoon een mail (namens jezelf, vanuit je eigen email) waarin je uitlegt dat de werknemer die dit project draagt, zojuist vader is geworden en daardoor tijdelijk niet aanwezig is op kantoor. En dat jij je uiterste best doet om je in het probleem te verdiepen en kijkt wat je voor de klant kan doen.

Waarom moeilijk doen, als 't makkelijk en eerlijk kan.

[Erwin537]

GateKeaper schreef op woensdag 07 november 2012 @ 10:23:
[...]


Of je stuurt niet 'zogenaamd automatisch' een bericht. Maar stuurt de klant/opdrachtgever gewoon een mail (namens jezelf, vanuit je eigen email) waarin je uitlegt dat de werknemer die dit project draagt, zojuist vader is geworden en daardoor tijdelijk niet aanwezig is op kantoor. En dat jij je uiterste best doet om je in het probleem te verdiepen en kijkt wat je voor de klant kan doen.

Waarom moeilijk doen, als 't makkelijk en eerlijk kan.

Daar zou ik zelf ook voor kiezen, maar Solopher zei dat hij niet de hele week spoedjes wil krijgen. Als hij vanuit zijn eigen mail stuurt heb je hier toch al meer kans op (denk ik).

[Hydra]

Erwin537 schreef op woensdag 07 november 2012 @ 10:26:
Daar zou ik zelf ook voor kiezen, maar Solopher zei dat hij niet de hele week spoedjes wil krijgen. Als hij vanuit zijn eigen mail stuurt heb je hier toch al meer kans op (denk ik).

Je hebt klanten en het lijkt me dat je die zo goed mogelijk gaat helpen toch? Ik vind het een rare instelling dat je niet "de hele week spoedjes" wil hebben. Kennelijk is er iets aan de hand en heeft die klant hulp nodig?

Ik snap die "hadden we maar geen klanten" instelling van veel developers niet, en ik erger me er ook aan. Zonder die klanten had je geen baan (irritatiepuntje met sommige mensen hier op kantoor).

[Firesphere]

Hydra schreef op woensdag 07 november 2012 @ 10:29:
[...]


Je hebt klanten en het lijkt me dat je die zo goed mogelijk gaat helpen toch? Ik vind het een rare instelling dat je niet "de hele week spoedjes" wil hebben. Kennelijk is er iets aan de hand en heeft die klant hulp nodig?

Ik snap die "hadden we maar geen klanten" instelling van veel developers niet, en ik erger me er ook aan. Zonder die klanten had je geen baan (irritatiepuntje met sommige mensen hier op kantoor).

Ik heb geen "hadden we maar geen klanten" instelling...

Wel heb ik een instelling van "Zeikklanten krijgen minder snel hun zin en ben ik liever kwijt dan rijk", maargoed, vaak leveren zeikklanten wel het meeste geld in het laatje voor de zaak.

Developers willen eigenlijk gewoon hun ding doen, en niets, echt niets, met klanten te maken hebben. Daar hebben we hier gelukkig een oplossing voor. De Technisch Directeur, die doet 99% van het klantencontact, en weet de vraag van de klant redelijk goed over te brengen zonder dat wij ons hier direct irriteren aan de klant.

[Erwin537]

Hydra schreef op woensdag 07 november 2012 @ 10:29:
[...]


Je hebt klanten en het lijkt me dat je die zo goed mogelijk gaat helpen toch? Ik vind het een rare instelling dat je niet "de hele week spoedjes" wil hebben. Kennelijk is er iets aan de hand en heeft die klant hulp nodig?

Ik snap die "hadden we maar geen klanten" instelling van veel developers niet, en ik erger me er ook aan. Zonder die klanten had je geen baan (irritatiepuntje met sommige mensen hier op kantoor).

Uiteraard, dat ben ik ook met je eens. Zelf ben ik nog 'maar' student, maar van verhalen weet ik uiteraard ook dat er vervelende klanten zijn die alles gisteren af wilden hebben en daarom alles maar als spoed aangeven. De klant moet natuurlijk goed geholpen worden, maar er zijn meer klanten dan alleen die ene die alles met spoed wil hebben.
Dit begreep ik althans uit zijn verhaal.

[GateKeaper]

Erwin537 schreef op woensdag 07 november 2012 @ 10:26:
[...]
Daar zou ik zelf ook voor kiezen, maar Solopher zei dat hij niet de hele week spoedjes wil krijgen. Als hij vanuit zijn eigen mail stuurt heb je hier toch al meer kans op (denk ik).

Wat Hydra zegt, maar je vertelt de klant natuurlijk ook dat je doet wat je kan doen. Maar jij hebt ook je eigen projecten, en probeert daarbij nog eens het werk van je collega over te nemen bij hoge prioriteit dingen. De klant begrijpt dan echt wel dat je niet alles klaar kan krijgen die week. De hele week spoedjes hoeft niet, je hebt immers ook je eigen werk.

Ik zie 't probleem dus niet echt.. Maarjah, that's me.

[Solopher]

Even terug komend op mijn punt:
De klant zelf is geen zeikklant alleen ze hebben daar iemand op de afdeling marketing zitten die wel ontzettend kan zeiken ;-).

Ik heb mijn eigen projecten hier, ik vind het niet erg om iets voor een ander project te doen. Maar laatst moest er zogenaamd ook iets snel online voor deze betreffende klant, wat vervolgens twee weken werd opgeschoven waarvoor ik dus voor niets twee vrije avonden heb opgeofferd. Dit speelt in een beetje in mijn achterhoofd, ik wil dit een beetje voorkomen.

@PrisonerOfPain
Gefeliciteerd!

[ Voor 3% gewijzigd door Solopher op 07-11-2012 10:51 ]

[Hydra]

Firesphere schreef op woensdag 07 november 2012 @ 10:33:
Ik heb geen "hadden we maar geen klanten" instelling...

Wel heb ik een instelling van "Zeikklanten krijgen minder snel hun zin en ben ik liever kwijt dan rijk", maargoed, vaak leveren zeikklanten wel het meeste geld in het laatje voor de zaak.

Developers willen eigenlijk gewoon hun ding doen, en niets, echt niets, met klanten te maken hebben. Daar hebben we hier gelukkig een oplossing voor. De Technisch Directeur, die doet 99% van het klantencontact, en weet de vraag van de klant redelijk goed over te brengen zonder dat wij ons hier direct irriteren aan de klant.

I spreek hier vanuit frustratie met mijn eigen bedrijf maar; ik vind je een slechte softwareengineer als je pertinent geen klantcontact wil. Sorry. Dit is precies waar dat vooroordeel over contactgestoorde computernerds vandaan komt. Je bouwt software voor een klant. Als je als developer nooit contact hebt met die klant, nooit samen met die klant achter jouw website gaat zitten en kijkt hoe die klant het gebruikt, dan kan je gewoon geen goeie software maken.

Jouw situatie is een beetje als die hier: developers wordt enorm de hand boven het hoofd gehouden als het aankomt op het werken met 'lastige' klanten. Als een 'lastige' klant een ticket instuurt en het uren duurt voor hij antwoord krijgt, is dat okay omdat het een lastige klant is. Wtf?

De reden dat die klanten 'lastig' zijn geworden is meestal gewoon dat er al flinke irritaties ontstaan over software die gewoon niet lekker werkt. Dit komt omdat die software gebouwd wordt door developers die moeite hebben het zich inleven in een gebruiker met een IQ dat 30 punten lager ligt, en die bovendien gewoon geen zin hebben in het 'saaie' UI werk maar vooral coole algorithmen willen bouwen.

Erwin537 schreef op woensdag 07 november 2012 @ 10:33:
Uiteraard, dat ben ik ook met je eens. Zelf ben ik nog 'maar' student, maar van verhalen weet ik uiteraard ook dat er vervelende klanten zijn die alles gisteren af wilden hebben en daarom alles maar als spoed aangeven. De klant moet natuurlijk goed geholpen worden, maar er zijn meer klanten dan alleen die ene die alles met spoed wil hebben.
Dit begreep ik althans uit zijn verhaal.

Daar heb je projectmanagers voor. Dat is mijn rol in de projecten die ik begeleid: ik ben het aanspreekpunt voor een klant en ik ben van oorsprong een techneut dus ik kan zijn wensen vertalen naar redelijk hapklaar werk voor de developers. Als je klanten direct je developers aansturen in wat er gebouwd moet worden gaat er volgens mij ook iets fout, het is mijn taak om de klant te informeren over de planning, wanneer het opgeleverd gaat worden en wat de kosten zijn (bugfixen is gratis maar voor wijzigingen wordt gewoon gefactureerd). Als je niemand hebt die die rol op zich neemt moet je als developer daar ook om vragen. Een manager is er niet alleen om je urenstaten af te tekenen.

GateKeaper schreef op woensdag 07 november 2012 @ 10:35:
Wat Hydra zegt, maar je vertelt de klant natuurlijk ook dat je doet wat je kan doen. Maar jij hebt ook je eigen projecten, en probeert daarbij nog eens het werk van je collega over te nemen bij hoge prioriteit dingen. De klant begrijpt dan echt wel dat je niet alles klaar kan krijgen die week. De hele week spoedjes hoeft niet, je hebt immers ook je eigen werk.

Ik zie 't probleem dus niet echt.. Maarjah, that's me.

Ik heb op dit moment ook gewoon teveel werk (een andere consultant is op vakantie voor 4 weken en heeft helaas een stuk meer werk achtergelaten dan hij aanvankelijk aangaf) maar dat kan ik ook gewoon afstemmen met die klanten. Die hebben ook gewoon planningen waarin geschoven wordt dus als ik aangeef dat iets de komende week niet gaat lukken dan kijken we of we daar iets kunnen regelen en zo niet dan ga ik intern kijken wat mogelijk is. Het belangrijkste is dat je gewoon goed contact hebt met een klant, er af en toe langsgaat om ze persoonlijk te kennen, en niet alles via mailtjes oplost. Klantcontact en de goodwill die je daarmee verzameld is extreem belangrijk.

[Woy]

@Hydra: Ik ben het grotendeels met je eens, maar de meeste developers horen niet extreem veel contact met de klant te hebben, verder dan het halen van de informatie die ze nodig hebben om hun opdracht te voltooien. Natuurlijk kan er wel wat meer informeel contact zijn om dingen over en weer te verduidelijken. Maar als een klant de developers direct aan gaat sturen qua prioriteit en/of werkwijze gaat er wel iets mis binnen de organisatie.

[GateKeaper]

Haha, Hydra is toe aan vakantie?

Ben het volledig met je eens hoor. Maar ik kan het me ook wel voorstellen dat bepaalde werknemers geen behoefte hebben aan klantcontact. Daarom zijn ze uitvoerend werknemer geworden/gebleven, en hebben ze geen behoefte om ooit projectleider of manager te worden.

Ze zitten hier ook op de werkvloer, 62/63 jaar, hun jaartjes tot pensioen aan het aftellen, maar nog steeds de uitvoerende taak zonder klantcontact. En tjah, die mensen heb je nu eenmaal ook nodig. Ze hoeven absoluut niet beschermd te worden door een "firewall" voor hun telefoon te zetten die alle externe calls blokkeert, maar begrip voor hun behoeften mag er ook wel zijn. Hier worden ze dan ook gewoon beloond met de titel: "..... specialist".

[Firesphere]

Hydra schreef op woensdag 07 november 2012 @ 10:52:
[...]


I spreek hier vanuit frustratie met mijn eigen bedrijf maar; ik vind je een slechte softwareengineer als je pertinent geen klantcontact wil. Sorry. Dit is precies waar dat vooroordeel over contactgestoorde computernerds vandaan komt. Je bouwt software voor een klant. Als je als developer nooit contact hebt met die klant, nooit samen met die klant achter jouw website gaat zitten en kijkt hoe die klant het gebruikt, dan kan je gewoon geen goeie software maken.

Jouw situatie is een beetje als die hier: developers wordt enorm de hand boven het hoofd gehouden als het aankomt op het werken met 'lastige' klanten. Als een 'lastige' klant een ticket instuurt en het uren duurt voor hij antwoord krijgt, is dat okay omdat het een lastige klant is. Wtf?

De reden dat die klanten 'lastig' zijn geworden is meestal gewoon dat er al flinke irritaties ontstaan over software die gewoon niet lekker werkt. Dit komt omdat die software gebouwd wordt door developers die moeite hebben het zich inleven in een gebruiker met een IQ dat 30 punten lager ligt, en die bovendien gewoon geen zin hebben in het 'saaie' UI werk maar vooral coole algorithmen willen bouwen.

Klanten die om elk puntje van de UI (die knop moet 2 punten naar rechts) een ticket inschieten, daar wordt ik inderdaad gefrustreerd van, maar dat zijn dan ook precies die zaken waar ik persoonlijk van denk "sjah, ehh, dat komt wel een keertje".

Als een klant echt serieuze problemen heeft, dan worden het al snel zeikklanten, want ze gaan, volgens mij vanzelf, op alle slakken zout leggen, puur omdat een aantal echte issues bestaan, gaan ze ineens ook al die kleine, pietluttige, er niet toe doende puntjes zien.
Die pietluttige "doet er niet toe" punten, jep, die schuif ik aan de kant, eerst de echte problemen maar eens oplossen.

Tot slot heb je klanten die niet weten wat ze willen. En dat zijn de echt vervelende klanten. Die willen dingen die totaal niet van belang zijn, hun hele eigen concept omver schoppen (van een directeur die zegt "er moet een reclamebalk in", terwijl in de specificaties staat "Geen reclame in de app") tot zelfs compleet zinloze dingen vragen.
Of zelfs dingen die in de huidige applicatie technisch gezien bijna onmogelijk zijn, dat het ze duidelijk is gemaakt, maar ze willen het toch. En ow ja, het mag niets kosten.

Er is niets mis met developers een beetje in bescherming nemen tegen de klanten. Maar ik ben het met je eens dat developers ook wel wat meer met de klant moeten praten. Hoewel een developer vaak wat directer is en zal wat eerder de hakken in het zand zetten om te zeggen "kan niet wil ik niet".

Daar moet ik wel bij zeggen, dat sommige klanten gewoon stront in de oren hebben. Ze nemen niets aan van je adviezen, je meedenken of het zoeken naar een oplossing voor hun wens, ze drijven hun zin door en daar heb je't mee te doen.

[Solopher]

Ik vind het helemaal niet erg om contact te hebben met klanten, in sommige gevallen heb ik zelfs liever, als je bijvoorbeeld een mailtje krijgt met daarin een hele lap tekst waar je uiteindelijk niets concreet uit kunt halen.
Dan kan een kort telefoontje een hoop opheldering geven.

[Woy]

Firesphere schreef op woensdag 07 november 2012 @ 11:05:
[...]
Klanten die om elk puntje van de UI (die knop moet 2 punten naar rechts) een ticket inschieten, daar wordt ik inderdaad gefrustreerd van, maar dat zijn dan ook precies die zaken waar ik persoonlijk van denk "sjah, ehh, dat komt wel een keertje".

Het ligt natuurlijk een beetje aan hoe de afspraken zijn met de klant, maar in principe worden bij ons eerst alle tickets gefilterd/beoordeeld voordat er een ontwikkelaar mee aan de slag gaat. En dat gaat dan natuurlijk voor dat soort minor tickets gewoon met een hele bups tegelijk. Voor belangrijkere tickets/defects wordt daar natuurlijk wat meer vaart mee gemaakt zodat er zo spoedig mogelijk aan gewerkt kan worden. Maar het lijkt me niet ideaal als alle tickets van de klant zomaar opgepakt worden. Dan heb je nogal eens de kans dat er weer andere dingen mis gaan, of dat het later toch weer ongedaan gemaakt moet worden.

[GateKeaper]

Firesphere schreef op woensdag 07 november 2012 @ 11:05:
[...]

Klanten die om elk puntje van de UI (die knop moet 2 punten naar rechts) een ticket inschieten, daar wordt ik inderdaad gefrustreerd van, maar dat zijn dan ook precies die zaken waar ik persoonlijk van denk "sjah, ehh, dat komt wel een keertje".

Ja maar.. dat heb je echt overal. Ik kom zelf uit de bouwkunde, en ook daar heb je het. Daar heb je het zelfs nog erger, wensen van je baas (de architect) die gewoon simpelweg niet mogelijk zijn. Hij heeft "briljante" ideeën en werkt die uit met een stift op een stuk papier (zie het als klant/vormgever). Als dit technisch niet mogelijk blijkt, tjah.. dan is het de taak van de technische man (developer?) om dat aan hem uit te leggen. Als dit een vraag/wens van de klant was, dan zal je waarschijnlijk toch echt mee moeten naar de volgende vergadering, want de klant, maar ook de architect, heeft niet altijd voldoende technische kennis om het probleem te zien. Punt blijft, hun zien gewoon het visuele, en zien echt niet wat er allemaal wel niet achter zit.

Het is dan ook erg gevaarlijk om bij je proof of concept de grafische interface al oplever klaar te laten zien.

Als een klant echt serieuze problemen heeft, dan worden het al snel zeikklanten, want ze gaan, volgens mij vanzelf, op alle slakken zout leggen, puur omdat een aantal echte issues bestaan, gaan ze ineens ook al die kleine, pietluttige, er niet toe doende puntjes zien.
Die pietluttige "doet er niet toe" punten, jep, die schuif ik aan de kant, eerst de echte problemen maar eens oplossen.

Overal hetzelfde, als jij in een restaurant zit, dik betaald, maar de vloer is smerig, dan zit je ook minder prettig. Ga je vervolgens naar de wc, en die is ook te ranzig voor woorden. Dan ga je de bediening ook al snel slecht vinden en uiteindelijk ga je met een ontevreden gevoel naar huis en wil je liever niet eens meer betalen. Hoe goed de maaltijd zelf ook was. Zorg daarom dat de belangrijkste dingen inderdaad werken, dan komen die "2px issues" zoals je zelf zegt later wel. Is het een beta? Laat dit dan ook duidelijk aan de klant weten, dan "zeurt" hij ook minder snel. Je wilt krijgen waarvoor je betaald, en het liefst net een beetje meer

Tot slot heb je klanten die niet weten wat ze willen. En dat zijn de echt vervelende klanten. Die willen dingen die totaal niet van belang zijn, hun hele eigen concept omver schoppen (van een directeur die zegt "er moet een reclamebalk in", terwijl in de specificaties staat "Geen reclame in de app") tot zelfs compleet zinloze dingen vragen.
Of zelfs dingen die in de huidige applicatie technisch gezien bijna onmogelijk zijn, dat het ze duidelijk is gemaakt, maar ze willen het toch. En ow ja, het mag niets kosten.

Het is dan ook "jouw" taak (die van de opdrachtnemer) om de vraag van de klant duidelijk te krijgen. Klanten weten dit heel vaak niet, daarom komen ze bij een bedrijf met ervaring. Het is niet alleen de taak om het product te maken, maar ook de taak om het product te maken zoals de klant het wil zien. En niet zoals de klant denkt dat het moet zijn.

De vraag aan de klant zou dan ook niet moeten zijn: "Wat moeten wij maken?". Maar "Wat willen jullie ermee doen?". Wat doet de klant, en voor wat voor activiteiten wil hij het gaan gebruiken. Aan opdrachtnemer de taak om een idee uit te werken, en met de klant te bespreken.

[armageddon_2k1]

Over de klantdiscussie...

Nou ben ik dus helemaal geen professionele developer en ontwikkel ik vrijwel niet voor mijn werk. Ik vind het hobbymatig erg interessant allemaal en voor mijn werk doe ik soms wat Arduino werk of wat Python werk. (Of zoals nu enorme data-mining met terabytes aan mishandelde data). Dit doe ik allemaal bij een grote electronicaboer in het oosten die medische apparatuur maakt.

Vorig jaar werkte ik echter bij Avent (de jonge papa's hier zullen het wel kennen) als productontwikkelaar en als ik daar 1 ding geleerd heb is dat iedereen van het project-team betrokken moet zijn bij de wensen van de klant en direct klantcontact moet hebben om uberhaubt te begrijpen waar je mee bezig bent. Ook bij ons verafschuwden sommigen klantcontact en dat waren ook meteen de mensen die de meest 'kort-door-de-bocht' meningen met betrekking tot de producten hadden en puur dachten vanuit hun eigen leefwereld. Als ik zie wat voor nutteloze discussies dat op heeft geleverd ben ik er stellig van overtuigt dat iedereen in een projectteam tenminste een paar keer contact moet hebben gehad met de klant waar je het voor doet. Ook al maak je een algoritme of, in mijn geval een product-feature, waar de klant he-le-maal niks van gaat merken aan de oppervlakte helpt het wel om mee te denken als te klant en kom je wellicht op ideeen voor andere collegas waar je normaal nooit opgekomen zou zijn.

[.oisyn]

Hydra schreef op woensdag 07 november 2012 @ 10:52:
[...]


I spreek hier vanuit frustratie met mijn eigen bedrijf maar; ik vind je een slechte softwareengineer als je pertinent geen klantcontact wil.

Je verhaal is echter nogal eenzijdig. Niet iedere software engineer zit in de dienstverlening, en niet iedere klant is een leek op het gebied van development. Als je al überhaupt te maken hebt met een klant in die hoedanigheid die zijn eisen bij jou neerlegt. En ik kan me best voorstellen dat developers die te maken hebben met "vervelende klanten" best eens wat anders willen, want het hoeft namelijk helemaal niet per se op die manier. Je moet dan uiteraard wel op zoek naar een andere werkgever, in sectoren die een stuk kleiner zijn dan de reguliere Nederlandse IT branch. En dan moet je denken aan bedrijven die gewoon direct hun software verkopen op de markt, of R&D.

[Hydra]

Woy schreef op woensdag 07 november 2012 @ 10:58:
@Hydra: Ik ben het grotendeels met je eens, maar de meeste developers horen niet extreem veel contact met de klant te hebben, verder dan het halen van de informatie die ze nodig hebben om hun opdracht te voltooien. Natuurlijk kan er wel wat meer informeel contact zijn om dingen over en weer te verduidelijken. Maar als een klant de developers direct aan gaat sturen qua prioriteit en/of werkwijze gaat er wel iets mis binnen de organisatie.

Dat zeg ik zelf ook letterlijk.

GateKeaper schreef op woensdag 07 november 2012 @ 11:03:
Haha, Hydra is toe aan vakantie?

Nee, ik ben toe aan een andere beroepsgroep. Beetje klaar met de IT. En dat heeft voor een deel ook te maken met de instelling van veel developers.

Ben het volledig met je eens hoor. Maar ik kan het me ook wel voorstellen dat bepaalde werknemers geen behoefte hebben aan klantcontact. Daarom zijn ze uitvoerend werknemer geworden/gebleven, en hebben ze geen behoefte om ooit projectleider of manager te worden.

En daar gaat het dus mis. Als gewone werknemer heb je ook contact met klanten. Ik snap niet dat in de IT wereld "klantcontact" automatisch zou betekenen dat je een managementrol hebt. Elke software engineering opleiding legt ook een sterke focus op het vertalen van klantwensen naar software. Hoe kan je dat doen als je geen contact met klanten hebt?

Ze zitten hier ook op de werkvloer, 62/63 jaar, hun jaartjes tot pensioen aan het aftellen, maar nog steeds de uitvoerende taak zonder klantcontact. En tjah, die mensen heb je nu eenmaal ook nodig. Ze hoeven absoluut niet beschermd te worden door een "firewall" voor hun telefoon te zetten die alle externe calls blokkeert, maar begrip voor hun behoeften mag er ook wel zijn. Hier worden ze dan ook gewoon beloond met de titel: "..... specialist".

Ik vind het verschrikkelijk dat dat soort toestanden in de IT normaal geacht worden. M.i. zijn zulke types vrijwel nutteloos. Ze weten misschien een hoop over hun vakgebied maar als je dit niet toe kan passen op klantproblemen zie ik niet hoe je nut hebt voor je bedrijf.

Firesphere schreef op woensdag 07 november 2012 @ 11:05:
Klanten die om elk puntje van de UI (die knop moet 2 punten naar rechts) een ticket inschieten, daar wordt ik inderdaad gefrustreerd van, maar dat zijn dan ook precies die zaken waar ik persoonlijk van denk "sjah, ehh, dat komt wel een keertje".

Dan heeft je bedrijf gewoon een verkeerde werkwijze. Je stemt eerst een design af, daar ga je mee aan de slag. Dan is er nog X tijd voor bevindingen. Als klanten gaan emmeren over 2 puntjes naar rechts oh nee toch naar links dan heeft je bedrijf gefaald in het in kaart brengen van klantwensen.

Als een klant echt serieuze problemen heeft, dan worden het al snel zeikklanten, want ze gaan, volgens mij vanzelf, op alle slakken zout leggen, puur omdat een aantal echte issues bestaan, gaan ze ineens ook al die kleine, pietluttige, er niet toe doende puntjes zien.
Die pietluttige "doet er niet toe" punten, jep, die schuif ik aan de kant, eerst de echte problemen maar eens oplossen.

Ik vind je instelling verkeerd. Als er serieuze problemen zijn en klanten gefrustreerd raken dan is het HET moment om een stukje harder te gaan lopen om ze weer om te toveren in tevreden klanten. De reden dat die irritaties over en weer ontstaan komt ook omdat je ze nooit ziet. Ik heb in mijn projecten minimaal elke 2 weken een meeting gewoon om die klant te zien, ze het idee geven dat we hun problemen aan kunnen horen en om gewoon efficient te kunnen communiceren over issues. E-mail is extreem inefficient en bovendien mis je het nonverbale component.

Tot slot heb je klanten die niet weten wat ze willen. En dat zijn de echt vervelende klanten. Die willen dingen die totaal niet van belang zijn, hun hele eigen concept omver schoppen (van een directeur die zegt "er moet een reclamebalk in", terwijl in de specificaties staat "Geen reclame in de app") tot zelfs compleet zinloze dingen vragen.
Of zelfs dingen die in de huidige applicatie technisch gezien bijna onmogelijk zijn, dat het ze duidelijk is gemaakt, maar ze willen het toch. En ow ja, het mag niets kosten.

Je hebt gewoon het verkeerde beroep gekozen, sorry. Je moet bij een universiteit software gaan bouwen als onderzoek.

Natuurlijk weten klanten niet precies wat ze willen, dat is je job als software engineer om de workflow in kaart te brengen en die te vertalen naar software. Als ze dan iets willen wat tegen hun workflow ingaat, dan kun je ze dat uitleggen. Willen ze het dan nog; prima, klant is koning. Als ze later toch functionaliteit X erbij willen, prima, dat kost zoveel meer tijd en dus X meer geld.

Er is niets mis met developers een beetje in bescherming nemen tegen de klanten. Maar ik ben het met je eens dat developers ook wel wat meer met de klant moeten praten. Hoewel een developer vaak wat directer is en zal wat eerder de hakken in het zand zetten om te zeggen "kan niet wil ik niet".

Daar moet ik wel bij zeggen, dat sommige klanten gewoon stront in de oren hebben. Ze nemen niets aan van je adviezen, je meedenken of het zoeken naar een oplossing voor hun wens, ze drijven hun zin door en daar heb je't mee te doen.

Grappig. Die ervaring heb ik dus helemaal niet, maar misschien moet je eens wat vaker met ze om tafel gaan zitten in plaats van kortaf mailtjes te sturen.

.oisyn schreef op woensdag 07 november 2012 @ 11:27:
Je verhaal is echter nogal eenzijdig. Niet iedere software engineer zit in de dienstverlening, en niet iedere klant is een leek op het gebied van development. Als je al überhaupt te maken hebt met een klant in die hoedanigheid die zijn eisen bij jou neerlegt. En ik kan me best voorstellen dat developers die te maken hebben met "vervelende klanten" best eens wat anders willen, want het hoeft namelijk helemaal niet per se op die manier. Je moet dan uiteraard wel op zoek naar een andere werkgever, in sectoren die een stuk kleiner zijn dan de reguliere Nederlandse IT branch. En dan moet je denken aan bedrijven die gewoon direct hun software verkopen op de markt, of R&D.

Vandaar dat ik bij Firesphere aangaf dat als hij geen software wil bouwen voor gebruikers hij maar bij een universiteit onderzoek moet gaan doen ofzo. Het gros van de software die gebouwd wordt is gewoon redelijk standaard website / frontoffice spul dat gewoon door eindgebruikers gebruikt wordt. Als je als developer je niet kunt verplaatsen in hun workflow dan lever je gewoon slechte software op.

Het werk wat jij doet is gewoon een uitzondering op de regel (en stiekem het werk dat de meeste developers graag willen doen). Als iemand jouw baan wil hebben moet 'ie naar een soortgelijke baan solliciteren. Je moet niet een baan aannemen waar je gewoon software voor 'domme' gebruikers bouwt en je dan gaan zitten ergeren aan die gebruikers.

[ Voor 11% gewijzigd door Hydra op 07-11-2012 11:37 ]

[creator1988]

Hydra schreef op woensdag 07 november 2012 @ 11:33:
Vandaar dat ik bij Firesphere aangaf dat als hij geen software wil bouwen voor gebruikers hij maar bij een universiteit onderzoek moet gaan doen ofzo. Het gros van de software die gebouwd wordt is gewoon redelijk standaard website / frontoffice spul dat gewoon door eindgebruikers gebruikt wordt. Als je als developer je niet kunt verplaatsen in hun workflow dan lever je gewoon slechte software op.

Het werk wat jij doet is gewoon een uitzondering op de regel (en stiekem het werk dat de meeste developers graag willen doen). Als iemand jouw baan wil hebben moet 'ie naar een soortgelijke baan solliciteren. Je moet niet een baan aannemen waar je gewoon software voor 'domme' gebruikers bouwt en je dan gaan zitten ergeren aan die gebruikers.

Ga dan lekker in een productorganisatie zitten, iedereen weet waar hij het voor doet, motivatie ligt hoger, en je zit voor meerdere jaren in dezelfde codebase (kan ook tegen je gaan werken )

[Firesphere]

Hydra schreef op woensdag 07 november 2012 @ 11:33:
Dan heeft je bedrijf gewoon een verkeerde werkwijze. Je stemt eerst een design af, daar ga je mee aan de slag. Dan is er nog X tijd voor bevindingen. Als klanten gaan emmeren over 2 puntjes naar rechts oh nee toch naar links dan heeft je bedrijf gefaald in het in kaart brengen van klantwensen.


[...]


Ik vind je instelling verkeerd. Als er serieuze problemen zijn en klanten gefrustreerd raken dan is het HET moment om een stukje harder te gaan lopen om ze weer om te toveren in tevreden klanten. De reden dat die irritaties over en weer ontstaan komt ook omdat je ze nooit ziet. Ik heb in mijn projecten minimaal elke 2 weken een meeting gewoon om die klant te zien, ze het idee geven dat we hun problemen aan kunnen horen en om gewoon efficient te kunnen communiceren over issues. E-mail is extreem inefficient en bovendien mis je het nonverbale component.


[...]


Je hebt gewoon het verkeerde beroep gekozen, sorry. Je moet bij een universiteit software gaan bouwen als onderzoek.

Natuurlijk weten klanten niet precies wat ze willen, dat is je job als software engineer om de workflow in kaart te brengen en die te vertalen naar software. Als ze dan iets willen wat tegen hun workflow ingaat, dan kun je ze dat uitleggen. Willen ze het dan nog; prima, klant is koning. Als ze later toch functionaliteit X erbij willen, prima, dat kost zoveel meer tijd en dus X meer geld.


[...]


Grappig. Die ervaring heb ik dus helemaal niet, maar misschien moet je eens wat vaker met ze om tafel gaan zitten in plaats van kortaf mailtjes te sturen.

Je begrijpt mij denk ik een beetje verkeerd
Als klanten komen met van die pietluttige zaken, omdat ze beginnen op te vallen vanwege een echte issue, dan zorg ik eerst dat de echte issues verholpen worden, daarna gaan we van die non-issues verhelpen.

Verder bemoei ik me meestal weinig met de afstemming van design etc. maar het gebeurd gewoon vaak dat zodra binnen de opdrachtgever iemand anders zich met het project gaat bemoeien, er herspecificaties komen. Dat is een gevolg van hoe het bij de klant intern werkt. Meestal wordt dan ook wel teruggegeven dat dat niet de specificaties zijn.

En ja, research-software maken hier op de IT lijkt mij echt super, maarja, daar hebben ze AIO's voor meestal
Ik beschrijf slechts mijn ervaringen met klanten (en dan vooral klanten die hun eigen interne organisatie niet goed op orde hebben) en mijn ervaring met andere devs. We hebben ook genoeg klanten die zeggen "Hier, kruiwagen met geld, specificaties, succes" en als er dan iets mis is terug komen en een heldere ticket in schieten en niet gaan miepen, maar rustig de resultaten afwachten.

En kortaf-mailtjes stuur ik zelden. Sowieso ben ik geen voorstander van e-mail als primair communicatiemiddel, maar veel mensen zien het toch als een ideaal communicatiemiddel.
Ook dingen als skype o.i.d. ben ik geen voorstander van. Telefoon of persoonlijk werkt veel beter. Dan kun je ook rustig dingen bespreken.
En klanten die absoluut niet willen luisteren, ja, daar doe je gewoon niets aan. Is lastig, maar dat moet dan maar. Maar "niet voor eindgebruikers willen werken" heb ik nooit gezegd he

Eindgebruikers zijn alleen sneller "lastig", dan een hoop techneuten die lekker techneutendingen kunnen doen en zich geen zorgen hoeven te maken over wie de software moet gaan gebruiken.

[ Voor 3% gewijzigd door Firesphere op 07-11-2012 11:51 ]

[Hydra]

Firesphere schreef op woensdag 07 november 2012 @ 11:48:
Je begrijpt mij denk ik een beetje verkeerd
Als klanten komen met van die pietluttige zaken, omdat ze beginnen op te vallen vanwege een echte issue, dan zorg ik eerst dat de echte issues verholpen worden, daarna gaan we van die non-issues verhelpen.

Ik ga af op wat ik hier lees en mijn vooroordelen wat betreft developers die hier meestal klagen over "lastige klanten" he

Verder bemoei ik me meestal weinig met de afstemming van design etc. maar het gebeurd gewoon vaak dat zodra binnen de opdrachtgever iemand anders zich met het project gaat bemoeien, er herspecificaties komen. Dat is een gevolg van hoe het bij de klant intern werkt. Meestal wordt dan ook wel teruggegeven dat dat niet de specificaties zijn.

Nouja, je zegt noot "nee" tegen een klant. Ik zeg altijd "ja dat kan, ik ga voor je uitzoeken hoeveel tijd dat kost en dan maak ik een SoW voor je"

En kortaf-mailtjes stuur ik zelden. Sowieso ben ik geen voorstander van e-mail als primair communicatiemiddel, maar veel mensen zien het toch als een ideaal communicatiemiddel.
Ook dingen als skype o.i.d. ben ik geen voorstander van. Telefoon of persoonlijk werkt veel beter. Dan kun je ook rustig dingen bespreken.

Ik bedoel ook niet dat jij dat doet hoor, maar het is gewoon mijn ervaring. Ik zie gewoon regelmatig mailtjes en tickets langskomen (als een klant er niet uitkomt gaan ze mij in-CCen) waarvan ik vind dat die developer dat gewoon telefonisch op moet lossen. Ander voordeel van een telefoon is dat een klant je later niet om de oren kan slaan met beloftes die in een mailtje staan

Eindgebruikers zijn alleen sneller "lastig", dan een hoop techneuten die lekker techneutendingen kunnen doen en zich geen zorgen hoeven te maken over wie de software moet gaan gebruiken.

Ik val een beetje over de term "lastig". Een klant heeft wensen en die wensen kan een klant over het algemeen niet vertalen naar een duidelijk design. Dat is ook ons werk, niet dat van hem. Maar veel ITers hebben nogal eens die neiging die verantwoordelijkheid bij een klant te leggen. Je hebt een mond waarmee je vragen kunt stellen. Gebruik die. Ik accepteer het ook gewoon niet dat ik later hoor dat iets niet duidelijk is.

[Firesphere]

Hydra schreef op woensdag 07 november 2012 @ 11:55:
[...]
Ik ga af op wat ik hier lees en mijn vooroordelen wat betreft developers die hier meestal klagen over "lastige klanten" he
[...]
Nouja, je zegt noot "nee" tegen een klant. Ik zeg altijd "ja dat kan, ik ga voor je uitzoeken hoeveel tijd dat kost en dan maak ik een SoW voor je"
[...]
Ik bedoel ook niet dat jij dat doet hoor, maar het is gewoon mijn ervaring. Ik zie gewoon regelmatig mailtjes en tickets langskomen (als een klant er niet uitkomt gaan ze mij in-CCen) waarvan ik vind dat die developer dat gewoon telefonisch op moet lossen. Ander voordeel van een telefoon is dat een klant je later niet om de oren kan slaan met beloftes die in een mailtje staan
[...]
Ik val een beetje over de term "lastig". Een klant heeft wensen en die wensen kan een klant over het algemeen niet vertalen naar een duidelijk design. Dat is ook ons werk, niet dat van hem. Maar veel ITers hebben nogal eens die neiging die verantwoordelijkheid bij een klant te leggen. Je hebt een mond waarmee je vragen kunt stellen. Gebruik die. Ik accepteer het ook gewoon niet dat ik later hoor dat iets niet duidelijk is.

Ik snap het "lastige klant" punt wel, maar de klant betaald mij, dus dan heb ik te doen met klanten die gaan lopen pietlutten. Niet altijd leuk, maar wel mijn werk.

Op zich is er niets mis met soms even je beklag doen over "lastige" klanten, maar ik ben het met je eens, als je niets met klanten te maken wilt hebben, zit je in't verkeerde vak.

Zoals ik zei, research-software schrijven op de UT lijkt mij fantastisch, maar ik zit ook prima op m'n plek waar ik nu zit. En soms wat frustraties over klanten of projectmanagers die nog niet 100% tevreden zijn, tja, ik geef toe, soms kan ik daar niet goed tegen.
Grotendeels omdat ik me inderdaad niet altijd even goed kan inleven in het vak van usability.

Als klanten mij in de CC hebben gezet, heeft de projectmanager niet bij mij duidelijk heeft weten te krijgen wat het probleem van de klant is.
De projectmanager vindt het alleen niet zo leuk als ik vrijwillig de klant opbel... Omdat ik meestal dingen afspreek die niet in de specificaties van de offerte staan (Maar die ik wel leuk vind om te maken )

[jbdeiman]

Developers hier laten we geen (of zo min mogelijk) klantcontact doen. Daar zijn de consultants voor, of ik wordt zelf ingevlogen (niet letterlijk, ik moet dan op komen draven en zelf zien dat ik daar kom ) omdat het mijn "taak" is om de bariere die in taalgebruik tussen de klant en de ontwikkelaar (technisch t.o.v. functioneel) te slechten. (wij maken software voor de zorgsector)
Een echte ontwikkelaar "denkt in code"

Natuurlijk een beetje een overdreven uitspraak maar het klopt hier wel aardig. Vaak wordt er dan meer in problemen dan in mogelijkheden gedacht, of er wordt compleet langs elkaar heen gedacht. Zelf ken ik bij onze klanten de werkwijzen en denkwijzen ondertussen vrij aardig. Ook het ontwikkelwerk is me niet vreemd (ik werk ook mee in het ontwikkelteam, maar dan meer codereviewen en testen schrijven), waardoor ik de beperkingen van het systeem ken/ begrijp, maar ook de wens van de klant snap. Het is een leuke uitdaging om tussen 2 compleet verschillende werelden te schakelen, maar soms ook wel frustrerend.

Een lastige klant of niet maakt eigenlijk niet uit, vragen moeten toch beantwoord worden en er moeten afspraken over gemaakt worden. Aangeven dat een wens gezien is maar dat de prioriteit heel laag is, omdat het een heel minimaal iets is (paar pixels opschuiven) doet een klant vaak al beseffen dat andere zaken (terecht) voor gaan. Klanten worden naar mijn idee pas lastig als je ze zelf negeert/ vergeet of op een voor hun onbegrijpelijke manier antwoord geeft. (stukje ervaring met onze klanten)
Wanneer 2 keer in de maand een (klein) puntje wordt ingeschoten (wat klantenservice in ons geval simpel kan uitleggen/ herstellen, of in een aantal gevallen de klant zelf), 3 maanden lang maar elke keer een vergelijkbaar iets, moet er worden ingegrepen, omdat er blijkbaar iets mis is. De fout komt steeds in meer of mindere mate weer terug, op zich niets voor een ontwikkelaar maar de constatering dat er iets niet goed is in de applicatie moet dan bij klantenservice worden gedaan. Een ontwikkelaar lost dat op en klantenservice voert de communicatie.

[CodeCaster]

Hydra schreef op woensdag 07 november 2012 @ 11:33:
En daar gaat het dus mis. Als gewone werknemer heb je ook contact met klanten. Ik snap niet dat in de IT wereld "klantcontact" automatisch zou betekenen dat je een managementrol hebt. Elke software engineering opleiding legt ook een sterke focus op het vertalen van klantwensen naar software. Hoe kan je dat doen als je geen contact met klanten hebt?
[...]
Ik vind het verschrikkelijk dat dat soort toestanden in de IT normaal geacht worden. M.i. zijn zulke types vrijwel nutteloos. Ze weten misschien een hoop over hun vakgebied maar als je dit niet toe kan passen op klantproblemen zie ik niet hoe je nut hebt voor je bedrijf.

Waarom zou een developer dat moeten doen? Ik vind zelf die tussenrol juist heerlijk, èn specs uit klanten trekken èn ontwerpen èn bouwen, wat dat betreft kun je in het MKB prima terecht. Er zijn echter ook legio organisaties, en ik dacht dat juist jij daar wel bekend mee zou zijn, waar developers "code monkeys" zijn die een stapel specs op hun bureau krijgen en dan lekker gaan zitten tikken. Die hoeven dus die hele klant nooit te zien.

Er is natuurlijk ook een verschil tussen klantcontact om een project op touw te zetten en te voltooien en klantcontact omdat software die zou moeten werken niet werkt. Richting het 'einde' van een project kunnen die twee elkaar gaan overlappen, en dan kun je, excusez le mot, toch echt met lastige klanten te maken krijgen. Eindgebruikers die van de specs niets afweten, maar zich toch gaan zitten bemoeien met functionaliteit en die wensen dan direct aan de developer doorsturen. Feit is dat die eindgebruiker vaak alleen in zijn straatje denkt, en dus niet nadenkt over eventuele gevolgen van die verandering.

Ik zou dit alleen geen lastige klant noemen, maar het gewoon gooien op slechte communicatie. De verantwoordelijkheden duidelijker in kaart brengen en handhaven (wie volgt wiens opdrachten op, wie is waarvoor verantwoordelijk?) scheelt daar al snel.

Verder heb je uiteraard nog het supportverhaal. Als een developer een mailtje krijg met een gescand geprint screenshot van een foutmelding in een Word-document en de bijgaande, veelzeggende tekst "hij doet het niet", wordt die vaak niet blij. Dat zou een tussenliggende eerste lijn moeten oplossen, zodat de developer direct weet wat precies het probleem is en waar 'ie kan beginnen te debuggen.

Helaas ben ik momenteel niet fortuinlijk genoeg om een dergelijke tussenlaag te hebben, en ontvang dus nogal eens dergelijke mailtjes. Ik vind het dan wel weer fijn om die klant te bellen en te vragen wat ze nou precies aan het doen zijn, maar ik kan begrijpen dat niet iedere developer daar trek in heeft.

[BtM909]

Ik ga me niet bemoeien met de discussie verder, maar moest hier ff op reageren?

Hydra schreef op woensdag 07 november 2012 @ 11:55:
[...]

Nouja, je zegt noot "nee" tegen een klant. Ik zeg altijd "ja dat kan, ik ga voor je uitzoeken hoeveel tijd dat kost en dan maak ik een SoW voor je"

/vooroordeel:
Oh dus jij bent diegene die altijd de puinhoop wat klanten willen gewoon laat maken zonder echt na te denken wat de klant echt wilt bereiken en of dat zo efficiënt / effectief is? Alles voor de billable uren

[bat266]

BtM909 schreef op woensdag 07 november 2012 @ 12:33:
Ik ga me niet bemoeien met de discussie verder, maar moest hier ff op reageren?

[...]

/vooroordeel:
Oh dus jij bent diegene die altijd de puinhoop wat klanten willen gewoon laat maken zonder echt na te denken wat de klant echt wilt bereiken en of dat zo efficiënt / effectief is? Alles voor de billable uren

Nu is er iemand bezig om zichzelf werk te verschaffen is het weer niet goed

[Hydra]

CodeCaster schreef op woensdag 07 november 2012 @ 12:16:
Waarom zou een developer dat moeten doen? Ik vind zelf die tussenrol juist heerlijk, èn specs uit klanten trekken èn ontwerpen èn bouwen, wat dat betreft kun je in het MKB prima terecht. Er zijn echter ook legio organisaties, en ik dacht dat juist jij daar wel bekend mee zou zijn, waar developers "code monkeys" zijn die een stapel specs op hun bureau krijgen en dan lekker gaan zitten tikken. Die hoeven dus die hele klant nooit te zien.

Nou, waarom denk je dat zoveel van dergelijke grote projecten kwa kosten helemaal uit de klauwen lopen? Sowieso zijn projecten van een dergelijke omvang gedoemd om uit de hand te lopen, maar dat komt voor een groot deel ook door de disconnect tussen development en de klant. Een developer heeft meestal geen domeinkennis in dergelijke systemen en doet een hoop werk gebaseerd op aannames. Dergelijke projecten zouden veel soepeler lopen als een (lead)developer vaak contact met de eindgebruiker zou hebben. Die strikte hierarchie in dergelope projecten heeft een bepaald nut, maar ook grote nadelen.

Er is natuurlijk ook een verschil tussen klantcontact om een project op touw te zetten en te voltooien en klantcontact omdat software die zou moeten werken niet werkt. Richting het 'einde' van een project kunnen die twee elkaar gaan overlappen, en dan kun je, excusez le mot, toch echt met lastige klanten te maken krijgen. Eindgebruikers die van de specs niets afweten, maar zich toch gaan zitten bemoeien met functionaliteit en die wensen dan direct aan de developer doorsturen. Feit is dat die eindgebruiker vaak alleen in zijn straatje denkt, en dus niet nadenkt over eventuele gevolgen van die verandering.

Dat is ook de taak van de projectmanager. Als er bij een klant intern politiek geneuzel is, moet je dat ook niet door een developer laten oplossen. Ik begrijp ook niet helemaal hoe mijn "een developer moet klantcontact hebben" opeens uitgelegd wordt als "een developt moet al het klantcontact doen", dat zeg ik toch helemaal niet?

Als projectmanager is dat politieke geneuzel mijn taak, prima ook want ik vind dat juist gewoon leuk. Als ej als developer gewoon je werk wil doen wil je niet tussen 2 vechtende honden zitten. Maar dit neemt niet weg dat je zonder domeinkennis gewoon geen goeie software kunt bouwen. Dan bouw je op basis van aannames en die zijn gewoon erg vaak fout.

Ik zou dit alleen geen lastige klant noemen, maar het gewoon gooien op slechte communicatie. De verantwoordelijkheden duidelijker in kaart brengen en handhaven (wie volgt wiens opdrachten op, wie is waarvoor verantwoordelijk?) scheelt daar al snel.

Verder heb je uiteraard nog het supportverhaal. Als een developer een mailtje krijg met een gescand geprint screenshot van een foutmelding in een Word-document en de bijgaande, veelzeggende tekst "hij doet het niet", wordt die vaak niet blij. Dat zou een tussenliggende eerste lijn moeten oplossen, zodat de developer direct weet wat precies het probleem is en waar 'ie kan beginnen te debuggen.

Niet mee eens. Je kunt dan als developer gewoon ff de telefoon pakken en vragen het zaakje wat te verduidelijken. Ik krijg dus regelmatig dat soort mailtjes en ik bel dan gewoon om aan te geven dat ik het probleem niet snap. Als je dat 'lastig' vindt zit je m.i. in het verkeerde vak.

Helaas ben ik momenteel niet fortuinlijk genoeg om een dergelijke tussenlaag te hebben, en ontvang dus nogal eens dergelijke mailtjes. Ik vind het dan wel weer fijn om die klant te bellen en te vragen wat ze nou precies aan het doen zijn, maar ik kan begrijpen dat niet iedere developer daar trek in heeft.

Ja, en die developer vind ik een slechte developer Dan ben je wat mij betreft een code-producent maar een developer / software engineer heeft ook communicatieve skills in z'n pakket, en niet alleen Java skills.

[Waster]

Nou ben ik net begonnen als developer en ik had de illusie dat klantcontact een vanzelfsprekendheid was. Nou ben ik helemaal afgeschermd met klanten door managers, functioneel ontwerpers, testers, consultants, grafisch en interactie ontwerpers etc. Alsof ik zelf geen prioriteiten kan stellen, een plan kan maken, functionele eisen vertalen naar implementatie etc. Nee, hier zijn een paar honderd requirements, paar honderd pagina's functioneel ontwerp die ik moet doorwerken en ga aan het werk. Ow ja, er kunnen fouten inzitten en dingen in staan die onuitvoerbaar zijn.

Ik begrijp niet waarom de klant en de ontwikkelaars twee gescheiden werelden moeten zijn die overbrugd moet worden door consultants, managers en functioneel ontwerpers. Eigenlijk betekent dit dat die tussenlaag niets meer dan een tolk is voor de sociaal onhandige codekloppers.

[Firesphere]

Hydra schreef op woensdag 07 november 2012 @ 12:52:
[...]

Nou, waarom denk je dat zoveel van dergelijke grote projecten kwa kosten helemaal uit de klauwen lopen? Sowieso zijn projecten van een dergelijke omvang gedoemd om uit de hand te lopen, maar dat komt voor een groot deel ook door de disconnect tussen development en de klant. Een developer heeft meestal geen domeinkennis in dergelijke systemen en doet een hoop werk gebaseerd op aannames. Dergelijke projecten zouden veel soepeler lopen als een (lead)developer vaak contact met de eindgebruiker zou hebben. Die strikte hierarchie in dergelope projecten heeft een bepaald nut, maar ook grote nadelen.

Check, vooral grote projecten waar de developer totaal geen connectie heeft met de klant, zie je uit de klauwen lopen.
En niet zo'n klein beetje ook. Dat gaat soms bijna het 4-voudige van het budget kosten.
Het probleem is echter, de juiste middenweg vinden. Ik, als developer, wil niet constant met de klant aan de lijn hangen, of wat ik net heb gemaakt wel voldoet aan zijn wens. Iets wat bij grote projecten vaak wel het geval is. Elk puntje moet 5x afgetikt worden, anders ben je de sjaak.

[...]

Dat is ook de taak van de projectmanager. Als er bij een klant intern politiek geneuzel is, moet je dat ook niet door een developer laten oplossen. Ik begrijp ook niet helemaal hoe mijn "een developer moet klantcontact hebben" opeens uitgelegd wordt als "een developt moet al het klantcontact doen", dat zeg ik toch helemaal niet?

Als projectmanager is dat politieke geneuzel mijn taak, prima ook want ik vind dat juist gewoon leuk. Als ej als developer gewoon je werk wil doen wil je niet tussen 2 vechtende honden zitten. Maar dit neemt niet weg dat je zonder domeinkennis gewoon geen goeie software kunt bouwen. Dan bouw je op basis van aannames en die zijn gewoon erg vaak fout.

En dat laat ik dan ook met heel veel plezier aan jou over

[...]

Niet mee eens. Je kunt dan als developer gewoon ff de telefoon pakken en vragen het zaakje wat te verduidelijken. Ik krijg dus regelmatig dat soort mailtjes en ik bel dan gewoon om aan te geven dat ik het probleem niet snap. Als je dat 'lastig' vindt zit je m.i. in het verkeerde vak.

[...]

Ja, en die developer vind ik een slechte developer Dan ben je wat mij betreft een code-producent maar een developer / software engineer heeft ook communicatieve skills in z'n pakket, en niet alleen Java skills.

De communicatie tussen dev en klant is altijd lastig, omdat de denkmethode vaak haaks op elkaar staat. Als dev moet je zeker meer kunnen dan je Java (wat ik trouwens al heel lang niet meer heb gedaan) skills. Maar ik zie ook te vaak dat de communicatieve skills van een dev te ver worden uitgemolken. Dat de dev bijna het hele project runt, terwijl de projectmanager, die eigenlijk dat politieke geneuzel moet doen, uit z'n neus zit te vreten, om't even zwart-wit te zeggen.

Persoonlijk ben ik niet slecht qua communicatie, maar wel vrij hard, rechtdoor. Geen geneuzel. Sommige klanten waarderen dat, anderen mag ik niet bij in de buurt komen

[TheNephilim]

Firesphere schreef op woensdag 07 november 2012 @ 13:07:
Het probleem is echter, de juiste middenweg vinden. Ik, als developer, wil niet constant met de klant aan de lijn hangen, of wat ik net heb gemaakt wel voldoet aan zijn wens.

Dit is denk ik vaak het probleem. Zelf werk ik liever aaneengesloten aan een project. Eisen/wensen -> Ontwerp -> Feedback -> Maken. Kort gezegd hoor, maar daar komt het op neer. Als je dan steeds kleine dingen tussendoor krijgt schiet het gewoon niet op. Liever samenvatten in één plan en traject vanaf Ontwerp -> .. weer opnieuw doorlopen.

Nu heb ik hier vrijwel altijd te maken met kleine websites, maar ik praat niet altijd direct met de klant. Tenzij het om specifieke oplossingen gaat. Dan overleg ik alleen met de klant of ga samen met de ontwerper naar de klant om dingen af te stemmen.

Dat laatste vind ik prima. Je kunt punten tackelen voordat ze in het ontwerp terecht komen. Het wil ook voorkomen dat ik met de klant niks te maken heb. Ik krijg een ontwerp binnen en maak er een Wordpress theme van. Dan is alleen de feeling van de ontwerper belangrijk voor wat ik als webdeveloper doe.

Kortom; zelfs in mijn simpele werk zou ik best wat meer communicatie willen. Echter laat het budget van de klant dat niet altijd toe.

[CodeCaster]

Hydra schreef op woensdag 07 november 2012 @ 12:52:
[...]
Nou, waarom denk je dat zoveel van dergelijke grote projecten kwa kosten helemaal uit de klauwen lopen? Sowieso zijn projecten van een dergelijke omvang gedoemd om uit de hand te lopen, maar dat komt voor een groot deel ook door de disconnect tussen development en de klant. Een developer heeft meestal geen domeinkennis in dergelijke systemen en doet een hoop werk gebaseerd op aannames. Dergelijke projecten zouden veel soepeler lopen als een (lead)developer vaak contact met de eindgebruiker zou hebben. Die strikte hierarchie in dergelope projecten heeft een bepaald nut, maar ook grote nadelen.
[...]
Als projectmanager is dat politieke geneuzel mijn taak, prima ook want ik vind dat juist gewoon leuk. Als ej als developer gewoon je werk wil doen wil je niet tussen 2 vechtende honden zitten. Maar dit neemt niet weg dat je zonder domeinkennis gewoon geen goeie software kunt bouwen. Dan bouw je op basis van aannames en die zijn gewoon erg vaak fout.

Eens.

Dat is ook de taak van de projectmanager. Als er bij een klant intern politiek geneuzel is, moet je dat ook niet door een developer laten oplossen. Ik begrijp ook niet helemaal hoe mijn "een developer moet klantcontact hebben" opeens uitgelegd wordt als "een developt moet al het klantcontact doen", dat zeg ik toch helemaal niet?

Ik bedoel alleen aan te geven dat ik kan begrijpen dat het kan dat sommige developers niet blij worden van álle klantcontact.

Niet mee eens. Je kunt dan als developer gewoon ff de telefoon pakken en vragen het zaakje wat te verduidelijken. Ik krijg dus regelmatig dat soort mailtjes en ik bel dan gewoon om aan te geven dat ik het probleem niet snap. Als je dat 'lastig' vindt zit je m.i. in het verkeerde vak.

Uiteraard is dit afhankelijk van wat je opdrachtgever en -nemer gewend zijn, maar ik vind dat zeker het inschieten van nieuwe issues / change requests afgevangen hoort te worden en niet direct op het bord van een developer hoort te komen. Zeker als die developer ondertussen allang op een nieuw project zit of als het gedeelte waarover een issue gemeld wordt helemaal niet zijn business is. Dan moet die developer dus moeite gaan doen om te achterhalen wat het probleem is (terwijl het niet zíjn probleem is) en doorspelen naar de juiste persoon; dat schreeuwt gewoon om een eerste lijn die dat soort zaken afvangt, de benodigde informatie uit de klant trekt, en zo nodig een nieuw work item inschiet voor de juiste afdeling.

Ja, en die developer vind ik een slechte developer Dan ben je wat mij betreft een code-producent maar een developer / software engineer heeft ook communicatieve skills in z'n pakket, en niet alleen Java skills.

Lang niet alle software is moeilijk en behoeft veel domeinkennis. Die mensen zitten in die tak wat mij betreft prima op hun plek, omdat ze goed zijn in wat ze doen: kant-en-klare eisen vertalen in code.

[SPee]

Hydra schreef op woensdag 07 november 2012 @ 12:52:

[...]
Niet mee eens. Je kunt dan als developer gewoon ff de telefoon pakken en vragen het zaakje wat te verduidelijken. Ik krijg dus regelmatig dat soort mailtjes en ik bel dan gewoon om aan te geven dat ik het probleem niet snap. Als je dat 'lastig' vindt zit je m.i. in het verkeerde vak.

[...]
Ja, en die developer vind ik een slechte developer Dan ben je wat mij betreft een code-producent maar een developer / software engineer heeft ook communicatieve skills in z'n pakket, en niet alleen Java skills.

Het is een goede uitlaatklep om soms je te verzuchten over een "lastige" klant.
En wat is het hier

Tussen het onduidelijke mailtje en een belletje naar de klant zit bij mij ook vaak een "zucht".
Dus iemand als een slechte developer neerzetten over iets wat hij hier typt vindt ik te ver gaan. Er zijn veel verschillende manieren hoe een bedrijf te werk gaat. Bij sommige bedrijven zo min mogelijk of geen klantcontact voor de ontwikkelaars, bij andere bedrijven doen ze bijna alles.

En als je als ontwikkelaar met de klant meedenkt, maar deze bij zijn eigen (kleine) probleem blijft, dan "zucht" *rant*.

[Patriot]

De echt lastige klant vind ik altijd juist de klant die zich gaat bemoeien met jóuw domein. De directrice van het bedrijf waar ik iets voor maakte had blijkbaar een vriendje die van zichzelf vond dat hij wel goed was met de UX. Maar dan ook nog opmerkingen maken in de lijn van: "Je moet dingen wat minder consistent maken, dan raken mensen handelingen gewend en gaan ze dingen op de automatische piloot doen. Dan maken ze meer fouten".

Bovendien was het project af, en wilden ze terwijl ze al hadden betaald dat we alles voor niks zouden aanpassen. We hebben ze na "de menu's moeten steeds in willekeurige volgorde geplaatst worden zodat mensen gestimuleerd worden te kijken wat ze doen" lachend de deur gewezen en ze een ereplaatsje gegeven op de zwarte lijst.

[.oisyn]

SPee schreef op woensdag 07 november 2012 @ 13:40:
En wat is het hier

Nou iig niet de Devschuur Coffee Corner

[Firesphere]

Het is best grappig om het verschil te zien tussen Duitse klanten en Nederlandse klanten.
Duitsers bakenen ALLES af. Ze hebben tot op elk detail (dat ze kunnen bedenken) hun vraag afgebakend. En alles wat op het pad komt, MOET eerst besproken worden voor je uberhaupt verder mag met het project.
Desnoods betalen ze "de uren tot nu toe" en breken ze het project af als het dreigt buiten budget te gaan (is wel een extreme situatie).

De Nederlandse werkwijze is veel meer "We zien wel waar het schip strandt". Dit verschil in werkwijze is voor mij persoonlijk als developer, heel groot. Puur vanuit mijn positie als "Code klop aapje", heb ik liever een Duitse opdracht. Die zijn zo strak afgebakend, dat ik het schema voor mezelf al klaar heb bij het lezen van de definitieve offerte.
Een Nederlandse opdracht, zie ik een hele hoop "hindernissen", die totaal niet besproken zijn in de offerte.
Simpel voorbeeld, Nederland:
Onze klanten moeten op onze producten kunnen zoeken.
-Retourvraag: Hoe?
Ja, eh, laat ze maar iets intypen ofzo?
-Retourvraag: Dus, fuzzy search (exclusief het jargon natuurlijk)
Kost dat?
-Meer
Nee, dan niet.
Een Duitse klant wilde:
Klanten kunnen via 2 of 3 dropdowns hun merk, type en kleur kiezen. Daarmee hebben we alles afgebakend en krijgen we geen lege resultaten.

De Nederlandse optie, heeft ondertussen opgeleverd dat er al 3x de vraag is gekomen waarom een bepaalde zoekterm die erg lijkt op 1 van de producten, maar het net niet is, zo vaak voorkwam, maar dat het product nooit werd gevonden.
Of we dat "even" wilden fixen, is toch service?
Nee dus, hebben jullie toentertijd zelf voor gekozen. Wil je't fixen, dan moet er betaald worden.

Van de Duitse klant is gekomen:
Kunnen jullie toevoegen, dat iemand wel kan typen, maar verplicht wordt uit de realtime resultaten op wat de klant heeft getypt, een keuze te maken en zo verder te zoeken.

De Duitse klant merkt iets op, en besluit om een UITBREIDING te vragen. Nederlandse klanten hebben vaak de neiging om alles wat klein lijkt, te scharen onder "service toch?", zelfs als ze zelf hebben aangegeven de voorgestelde feature NIET te willen.

[PatrickH89]

Firesphere schreef op woensdag 07 november 2012 @ 18:40:
Onze klanten moeten op onze producten kunnen zoeken.
-Retourvraag: Hoe?
Ja, eh, laat ze maar iets intypen ofzo?
-Retourvraag: Dus, fuzzy search (exclusief het jargon natuurlijk)
Kost dat?
-Meer
Nee, dan niet.

Ik vind dat niet 'Nederlands', ik vind dat gewoon het slecht afbakenen van een project. Een situatie als deze schept altijd verkeerde verwachtingen bij één van beide partijen en is dan ook nergens goed voor.

[D-Raven]

Firesphere schreef op woensdag 07 november 2012 @ 18:40:
Het is best grappig om het verschil te zien tussen Duitse klanten en Nederlandse klanten.
Duitsers bakenen ALLES af. Ze hebben tot op elk detail (dat ze kunnen bedenken) hun vraag afgebakend. En alles wat op het pad komt, MOET eerst besproken worden voor je uberhaupt verder mag met het project.
Desnoods betalen ze "de uren tot nu toe" en breken ze het project af als het dreigt buiten budget te gaan (is wel een extreme situatie).
....
[en de rest]...

Dit is wel heel herkenbaar

Ikzelf zit een op een positie waarbij ik vanaf het begin van het process erbij betrokken wordt. Ik ben dus bij de besprekingen over de functionele eisen, ik doe mede de implementatie en krijg tickets binnen als er nieuwe dingen moeten komen, of bugs gefixed moeten worden.

In mijn ervaring is juist dat eerste contact cruciaal voor het verdere verloop van het project. Wees duidelijk! Vertel precies hoe het project in elkaar steekt kwa project management vorm, zorg dat precies duidelijk is waar welke verantwoordelijkheden liggen en zorg dat je een goede afbakening hebt kwa functionele specs.

Vind het ook altijd wel grappig als er dan gezegd wordt dat als er achteraf iets bij moet komen wat niet in de originele specs staan, gewoon gefactureerd wordt, het regelmatig voorkomt dat ze toch nog even de tijd willen hebben om hun documenten te controleren..

Kortom: Communicatie is wellicht het meest belangrijke in ICT projecten.

[ Voor 35% gewijzigd door D-Raven op 07-11-2012 19:26 ]

[Firesphere]

PatrickH89 schreef op woensdag 07 november 2012 @ 19:23:
[...]


Ik vind dat niet 'Nederlands', ik vind dat gewoon het slecht afbakenen van een project. Een situatie als deze schept altijd verkeerde verwachtingen bij één van beide partijen en is dan ook nergens goed voor.

Ik merk dit verschil toch vaak wel tussen Nederlanders en Duitsers hoor.

En door de heldere retourvraag, waar op geantwoordt is "dan niet", is er dus, met enige moeite, vastgesteld dat het dus NIET gedaan moet worden.
Achteraf verwachten dat't als "service", in plaats van zoals de meeste Duitsers het zien "extra werk", alsnog gemaakt moet worden, daar gaat't me om niet de vraag-wedervraag situatie zelf

[ Voor 4% gewijzigd door Firesphere op 07-11-2012 19:31 ]

[Gomez12]

Firesphere schreef op woensdag 07 november 2012 @ 18:40:
Het is best grappig om het verschil te zien tussen Duitse klanten en Nederlandse klanten. klanten en sommige developers
...
Onze klanten moeten op onze producten kunnen zoeken.
-Retourvraag: Hoe?
Ja, eh, laat ze maar iets intypen ofzo?
-Retourvraag: Dus, fuzzy search (exclusief het jargon natuurlijk)
Kost dat?
-Meer
Nee, dan niet.
...
De Nederlandse optie, heeft ondertussen opgeleverd dat er al 3x de vraag is gekomen waarom een bepaalde zoekterm die erg lijkt op 1 van de producten, maar het net niet is, zo vaak voorkwam, maar dat het product nooit werd gevonden.
Of we dat "even" wilden fixen, is toch service?
Nee dus, hebben jullie toentertijd zelf voor gekozen. Wil je't fixen, dan moet er betaald worden.

Hoezo heeft de klant daarvoor gekozen?
Ik bedoel aan de antwoorden te zien is de klant geen expert, en de ingehuurde experts die hebben maar op eigen houtje wat verzonnen.
Dat de klant geen fuzzy search wil hebben zegt nog niet dat de klant bijv ook geen synoniemen in de zoekindex wil hebben of ... of ...

Als ik het hele vraag-antwoord spelletje vanuit de klant bekijk dan wil die gewoon dat zijn producten gevonden kunnen worden en de developer ziet maar 2 keuzes en niet wat de klant wil.

En dit soort geintjes zorgt er imho juist voor dat een developer wel contact met de klant moet hebben ipv dat de devver zich een aantal sprints opsluit om daarna vol trots een zoek-ding te laten zien wat 100% geintegreerd is en totaal niet doet wat de klant wil.

Zonder overleg is dit het begin van zeikende klanten, want die krijgt een factuur voor x uur werk terwijl hij dit totaal niet in gedachten had en de devver zegt enkel maar : Ze wilden geen fuzzy search dus is het dit brakke ding geworden

[ Voor 15% gewijzigd door Gomez12 op 07-11-2012 20:47 ]

[Firesphere]

Gomez12 schreef op woensdag 07 november 2012 @ 20:42:
[...]

Hoezo heeft de klant daarvoor gekozen?
Ik bedoel aan de antwoorden te zien is de klant geen expert, en de ingehuurde experts die hebben maar op eigen houtje wat verzonnen.
Dat de klant geen fuzzy search wil hebben zegt nog niet dat de klant bijv ook geen synoniemen in de zoekindex wil hebben of ... of ...

Als ik het hele vraag-antwoord spelletje vanuit de klant bekijk dan wil die gewoon dat zijn producten gevonden kunnen worden en de developer ziet maar 2 keuzes en niet wat de klant wil.

En dit soort geintjes zorgt er imho juist voor dat een developer wel contact met de klant moet hebben ipv dat de devver zich een aantal sprints opsluit om daarna vol trots een zoek-ding te laten zien wat 100% geintegreerd is en totaal niet doet wat de klant wil.

Zonder overleg is dit het begin van zeikende klanten, want die krijgt een factuur voor x uur werk terwijl hij dit totaal niet in gedachten had en de devver zegt enkel maar : Ze wilden geen fuzzy search dus is het dit brakke ding geworden

Wij hebben toch expliciet de klant gevraagd of hij fuzzy-search wilde en dat dat, hoewel dat meer kost, het een verstandige investering is.

Ik zeg al expres "jargon taal" over de fuzzy search. Natuurlijk is dat niet zo aan de klant voorgelegd. Wat aan de klant was voorgelegd zal iets zijn in de trant van:
Wilt u dat er ook op gelijkende woorden dezelfde resultaten getoond worden, zodat bijvoorbeeld "breok" ook "broek" vindt? Dit is wel verstandig, om typfouten toch op deze manier af te vangen en meer verkeer naar uw producten te brengen via de zoekfunctie.
-De vraag daar op was "kost dat meer?"
Waarop het antwoord was:
"Ja, dit zal meer kosten, namelijk bedrag X, maar, het is wel de kosten waard {uitleg waarom hier}"

Deze vraag-wedervraag, heeft de klant doen besluiten om NIET een fuzzy-search, maar gewoon hard op de door hem ingevulde zoekwoorden te implementeren.

Toen de klant er later achter kwam dat bepaalde typo-zoekwoorden toch wel erg vaak voorkwamen, vond de betreffende klant dat wij hem de "service" moesten bieden, om gratis de fuzzy-search te bouwen. Dit prefereerde hij dus zelfs boven het zelf invullen van vaak voorkomende typfouten in het CMS (Die optie zit er al wel direct in, uit "service")

Ik merk dat mijn taalgebruik zelfs hier voor verwarring zorgen

*
Ok, teruglezend zie ik dat hoe ik mijn punt probeerde duidelijk te maken inderdaad voor wat verwarring kan zorgen. Ik hoop het hiermee te hebben opgelost?

[ Voor 4% gewijzigd door Firesphere op 07-11-2012 21:00 ]

[pedorus]

Tsja, als je zoiets ziet aankomen moet je natuurlijk vervolgens geen brakke producten verkopen natuurlijk Maar het klinkt meer dat er een gebrek is aan een doorlopend contract waar je het onder kan schuiven. Liever kun je reageren met bedankt voor de suggestie, we zetten het op de lijst, en op een gegeven moment heb je het. Reageert de klant dan met dat hij het snel(ler) wil hebben, dan kun je het alsnog over prijzen gaan hebben natuurlijk

Solopher schreef op woensdag 07 november 2012 @ 10:10:
Dit is echt een RAMP! Een collega is papa geworden en is dus al enkele dagen afwezig, nu mag ik zijn "spoedjes" op gaan lossen. Probleem is dat dit ongeveer de grootste zeik klant is die we hebben, maar ik kan moeilijk vanuit zijn mailbox gaan reageren, heb natuurlijk geen zin om de rest van de week ook met "spoedjes" bezig te moeten. Even kijken hoe we dit gaan oplossen.

Lastige klus, lijkt me leuk om te doen

[Firesphere]

pedorus schreef op woensdag 07 november 2012 @ 21:11:
Tsja, als je zoiets ziet aankomen moet je natuurlijk vervolgens geen brakke producten verkopen natuurlijk Maar het klinkt meer dat er een gebrek is aan een doorlopend contract waar je het onder kan schuiven. Liever kun je reageren met bedankt voor de suggestie, we zetten het op de lijst, en op een gegeven moment heb je het. Reageert de klant dan met dat hij het snel(ler) wil hebben, dan kun je het alsnog over prijzen gaan hebben natuurlijk

Dat is ook precies waarom we het hebben voorgesteld. We zagen het al van verre aankomen.

Als de klant het dan niet wil "want duurder", en ook geen service-contract wil, dan houdt het bij mij in elk geval op hoor. Als de klant nee zegt, en later "ja, maar ik wil het onder service" en ondertussen GEEN service-contract heeft, is't snel bekeken: "Gaat niet gebeuren zonder budget".

Wat ik probeerde aan te geven, was vooral het verschil in hoe Duitsers alles afbakenen, terwijl Nederlanders de neiging hebben om het maar te laten gaan, en we zien wel (overdreven gezegd).

Voor een developer is de "Duitse methode" veel fijner, want die bakent alles dus af. Nooit een "zal ik A of B doen", omdat A al is besloten.
Er zijn genoeg Nederlandse bedrijven die dat ook zo doen hoor, maar ik merk dat het in Duitsland de norm is om alles af te bakenen, in Nederland is het dat nog niet.

[Gomez12]

Firesphere schreef op woensdag 07 november 2012 @ 21:30:
[...]
Voor een developer is de "Duitse methode" veel fijner, want die bakent alles dus af. Nooit een "zal ik A of B doen", omdat A al is besloten.
Er zijn genoeg Nederlandse bedrijven die dat ook zo doen hoor, maar ik merk dat het in Duitsland de norm is om alles af te bakenen, in Nederland is het dat nog niet.

Maar in Duitsland is er dan blijkbaar geen leek als klant, terwijl die er in NL wel zijn.

En eigenlijk wil jij dan geen klant-wensen vervullen maar simpele code-monkey zijn. Is niets mis mee, maar in NL heb je als code monkey wel een verduiveld goede project manager nodig. Want de klant kan nog steeds de specs niet zelf opzetten, en als de project manager de klant-wensen dan niet 100% goed kan overbrengen dan krijg je dus zeikende klanten.

[Firesphere]

Gomez12 schreef op woensdag 07 november 2012 @ 21:36:
[...]

Maar in Duitsland is er dan blijkbaar geen leek als klant, terwijl die er in NL wel zijn.

En eigenlijk wil jij dan geen klant-wensen vervullen maar simpele code-monkey zijn. Is niets mis mee, maar in NL heb je als code monkey wel een verduiveld goede project manager nodig. Want de klant kan nog steeds de specs niet zelf opzetten, en als de project manager de klant-wensen dan niet 100% goed kan overbrengen dan krijg je dus zeikende klanten.

Nee, dat is niet wat ik zeg.
Wat ik zeg is, dat de Duitse methode, voor een core developer veel makkelijker werken is. Niet dat ik dat liever heb, niet dat ik graag mijn terrein afgebakend zie, alleen dat het helder afbakenen voor een developer makkelijker/fijner werken is.
Ik zeg bovenstaande, vanuit "een pure developer zijn". Niet vanuit wie ik ben.
Als persoon (ja, ik ben meer dan een dev), heb ik totaal geen problemen met klantcontacten en heb ik er ook regelmatig best wel plezier in. Zoals ik ook al eerder heb aangegeven trouwens.

Ik kan mij prima verplaatsen in een dev. Minder goed in een klant. Maar wat ik beschrijf is zoals ik al eerder aangaf, voor een core dev veel fijner.

[Grijze Vos]

Bij ons praten programmeurs niet vaak met de klanten. De project leads af en toe, en de architect soms.
Onze requirement engineer / PM verzamelt de requirements. Dan gaat de designer mocks en/of designs maken van de te implementeren functionaliteit. Dat wordt samengevoegd met de requirements.

Daarna worden er html prototypes gemaakt, en daarna pas implementeren we. Ik werk hier nu pas een half jaar,maar ik kan je zeggen, het is verrekte fijn om niet telkens met klanten te moeten zitten. Vorige functie was ik de lead programmer van het hele bedrijf (5 programmeurs onder me), maar dat was zo time consuming..