Software & outsourcing

[Verwijderd]

Ik open dit topic om een discussie te starten over de ervaringen met betrekking tot outsourcing van software trajecten. Ik stuur teams aan in het buitenland die continue voor ons zowel software trajecten als web trajecten uitvoeren. Het rendement wat ik beoog te halen is nog niet binnen bereik, maar er is meetbare verbetering. Echter, ik vind de verbetering niet snel genoeg gaan terwijl onze aandacht zich steeds meer verplaatst naar overspecificeren van deliverables, meer tijd besteden aan controle, meer tijd besteden aan code audits, etc. terwijl deze in geen verhouding staat tot de verbeteringen.

Wat ik zelf zie:

• Estimates die worden afgegeven zijn hoog, en vaak worse case scenario.
• De dag voor oplevering wordt er pas gecommuniceerd dat deadlines niet gehaald worden.
• De kwaliteit van het opgeleverde resultaat is slecht tot gemiddeld.
• In de tijd die wordt besteed aan het testen, vinden we zelf bij onze eigen test factor 5 meer issues in de programmateur.
• Testcases gebaseerd op usecases zijn onvolledig. Testresultaten tonen ons dat een scenario succesvol is afgerond, maar als we zelf
  
  testen blijkt dat niet zo te zijn.

Als we kijken naar estimates, dan pak ik als voorbeeld een relatief eenvoudige migratie van een website op een content management systeem welke ze zelf deels hebben ontwikkeld, en die naar een nieuwe release moet worden geconverteerd. Ik heb intern een 2nd opinion laten uitvoeren, die persoon komt op maximaal 32 uur werk, in het buitenland komen ze op minimaal 99 uur werk met een identieke set aan doelstellingen.

Wat ik mij dan afvraag, zijn onze eisen te hoog? Is het wel realistisch om estimates van eigen bodem te vergelijken met estimates uit het buitenland. De productiviteit in Nederland staat bekend als hoog, maar als we kijken naar het werk wat wordt gevraagd dan zijn onze eigen estimates verre van onrealistisch. Ik heb zelf redelijk wat mensen in mijn netwerk die ook te maken hebben met vergelijkbare situaties en ook teams in het buitenland aansturen. Een functiepuntanalyse, waarbij elk functiepunt op 7,5 uur blijkt uit te komen, gemeten volgens Nesma richtlijnen, blijkt in India op 47 uur per functiepunt uit te komen.

Als we kijken naar de communicatie, dan valt op dat ze absoluut heel vriendelijk zijn, maar zelf niet hun grenzen aangeven. We hebben geintroduceerd dat er op dagelijkse basis status rapportages worden geleverd. Deze rapportages vermelden de taken die zijn uitgevoerd op de dag, de originele estimates, de gespendeerde tijd, een time forecast voor de taak, en eventuele problemen en risico's die zijn opgetreden tijdens een taak. Op wekelijkse basis is er een summary, die duidelijk aangeeft wat de huidige status is van projecten.

Echter, uit zichzelf rapporteren ze de problemen en risico's veel te laat, dit hebben we meerdere keren aangegeven, en de volgende keer wordt verbetering beloofd, maar helaas.

Als er iets moet worden opgeleverd zijn er situaties voorgekomen dat ze een dag voor oplevering aangaven dat ze het niet gingen redden. Op zich geen probleem dat je een deadline niet haalt, maar een dag voor oplevering iets aangeven maakt schakelen heel lastig. Last minute kan je planningen gaan omgooien, omdat mensen zijn ingepland op code audits, acceptatie testing. Tevens kan je zo nooit tijdig een klant informeren bij projecten met een korte doorlooptijd. Ook hiervan worden de argumenten gegeven, en geeist dat dit niet meer moet voorkomen. Het resultaat is ook hier, helaas.

Als we vragen om hoe ze tot die estimates zijn gekomen, krijg je als antwoord dat het worse case estimates zijn en dat gedurende het project de daadwerkelijke waardes worden ingevuld. Het blijkt snel duidelijk te worden, dat bijna in 90% van de taken de worse case estimates overeen komen met actual time spend. Er is reeds voorgesteld om te gaan werken met fixed price constructies, maar het management wil hier niet aan omdat dit zou resulteren in andere problemen zoals geschuif met resources.

Als we kijken naar de kwaliteit, zien we dat in de output van source code her en der asp:placeholders worden geoutput, dat resultaten tussen browsers niet overeenkomen terwijl ze wel als doelstelling zijn opgenomen, en diverse zaken waarvan je direct kunt constateren dat het een kwestie is van gebrek aan commitment, niet controleren van je eigen werk, of het domweg releasen zonder verdere aandacht. Desondanks is de partij waar we zaken mee doen een Microsoft Gold Partner, met gecertificeerde ontwikkelaars.

Zijn er managers met vergelijkbare ervaringen, hoe liggen de randvoorwaarden, hoe wordt er gecommuniceerd, wat gebeurt er als deadlines niet worden gehaald, waarmee zet je druk en hoe behoud je zelf de controle. Moeten we genoegen nemen met de estimates, welke middelen pas je toe om estimates betrouwbaarder te krijgen.

Als ik om me heen informeer is het overal kommer en kwel, in India, in China, en Roemenie. Maar ik kan me er niet bij neerleggen dat dit niet op te lossen is.

[ Voor 4% gewijzigd door Verwijderd op 15-04-2006 18:40 ]

[JaQ]

Ik heb zelf een dik jaar lang een aantal teams in Oekraiene aangestuurd (20 man). Dit is een vestiging van het bedrijf waar ik werk, dus de verhoudingen liggen iets anders; ik was geen "klant", maar direct leidinggevende (op afstand). In mijn geval ging het om applicaties gegenereerd vanuit Oracle Designer en Java software (altijd web-enabled). Mijn verantwoordelijkheden strekten zich uit van aannamebeleid via projectleiding tot aan technische adviezen.

Ik herken een aantal van je frustraties. Na verloop van tijd ben ik er achter gekomen dat een aantal knelpunten de problemen veroorzaakten:

1. Taal; Het niveau van Engels lijkt soms beter dan het is, dit is beter geworden door een lerares Engels in dienst te nemen en iedereen verplicht engelse les te laten volgen. Er blijven echter altijd nuance verschillen. Deze ontstaan ook door de afstand, je legt nou eenmaal gemakkelijker iets uit aan iemand die recht tegenover je staat.

2. Cultuur: bevel is bevel, dat is de mensen daar tenminste aangeleerd. Weinig eigen inbreng en ideeen die de werkwijze kunnen verbeteren kon ik niet verwachten. Het heeft heel lang geduurd voordat ik het bij die gasten daar in de botte kop kreeg gestampt dat ik best tegen kritiek kan, het fijn vind als ik feedback kreeg etc. Dit merkte ik ook vooral in werkoverleggen (als ik daar was).

3. Omgeving: Dingen die voor mij de normaalste zaak van de wereld zijn (bijvoorbeeld: wat is een parkeervergunning, om maar eens wat te noemen), zijn daar compleet onbekend. Het uitleggen van dat soort zaken kost veel meer tijd dan ik had verwacht. In Nederland is het dood normaal dat een inkoopproces volledig wordt geautomatiseerd. Daar is dat een stuk minder normaal....

4. Druk: Nederlands presteren goed onder druk, hebben een hoge productiviteit en zijn practisch ingesteld. Ik heb gemerkt dat het daar iets anders werkt. Dat de tarieven van mensen daar heel anders liggen, zorgt er nog eens extra voor dat er een "manjana" (of hoe je dat ook spelt) cultuur is.

Zaken waar ik veel nadruk op heb gelegd zijn:

1. Teambuilding. Het is enorm belangrijk dat het off-shore team en de mensen in Nederland goed samenwerken.

2. Uitleg van "normale" zaken, zodra ik er tenminste achter kwam dat iets minder normaal was voor de mensen daar.

3. Procesomschrijving. Alles tot op de puntjes uitschrijven was het enige waardoor (a) de software deed wat het moest doen en (b) correcte testscenario's werden gemaakt.

Dit alles heeft er wel voor gezorgt dat ik na een dik jaar gestopt ben met het leidinggeven aan die teams. Programmeren in Word is niet mijn ambitie en helaas ging het werk wel meer en meer die kant op. Momenteel ben ik nog wel regelmatig betrokken bij de vestiging aldaar, maar dan niet meer als manager (wel als techneut).

[Verwijderd]

Ik herken een deel van je punten absoluut.

Als ik kijk naar taal, Engels is inderdaad heel slecht, zowel mondeling als schrift. Ik probeer op regelmatige basis telefonisch contact te houden, en het gaat moeizaam maar uiteindelijk komen we er wel. Ik zie dit niet direct als beperkend.

Ook de deliverables, daarbij zien we dat eigen initiatief niet echt aan de orde is. Je moet exact vertellen wat ze moeten maken, hoe ze dat moeten doen, waar ze op moeten letten, en wat waar hoort. Ik vind dat we teveel moeten specificeren, en dat sommige zaken die wij voor logisch aannemen, bijvoorbeeld consequent doorvoeren van een bepaalde look & feel niet geheel logisch zijn aan de andere kant.

Wat ik reeds heb doorgevoerd:
- Voor het testen is er een apart team opgezet. Dit voorkomt dat er over fouten wordt heengekeken.
- Bij grotere projecten is er altijd een ontwikkelaar van onze kant die mee ontwikkeld, zodat er continue zicht is op de vorderingen, en er bijsturing kan plaatsvinden.
- Van elke taak is bekend welke ontwikkelaar eraan werkt, en zodoende kan een specifieke ontwikkelaar worden bijgestuurd op gebieden waar deze minder kwaliteit oplevert.
- Zelf planningen opgesteld, die dienen te worden gebruikt als referentiekader.
- Gedeelde omgeving voor kennisuitwisseling tussen ontwikkelaars, en het creeren van technische discussies zodat er commitment wordt ontwikkeld.
- Deliverables zijn verder gespecificeerd, en moeten voor elke pagina geaccepteerd worden.
- Developers hebben direct contact met onze eigen developers via MSN Messenger.

Dit heeft tot verbeteringen geresulteerd, de doorlooptijd is momenteel met een +/- 40% gereduceerd, maar ik denk dat het nog beter kan. Echter, hoe maak je een partij duidelijker dat ze te hoge estimates leveren in vergelijking tot eigen estimates. Die manjana cultuur geloof ik best, maar dan hoor je niet in mijn teams. Er is ook geen enkel nut om projecten te rekken, want er ligt genoeg werk maar dat kan niet over jaren worden uitgesmeerd.

Wellicht dat het verstandig is om het in India ook eens te proberen, alleen ben ik nog zoekende naar een goede partner die gespecialiseerd is in web trajecten met een korte doorlooptijd.

[ Voor 14% gewijzigd door Verwijderd op 25-03-2006 22:29 ]

[alienfruit]

Als ik dit allemaal zo lees krijg je een beetje het "Goedkoop is duurkoop" gevoel, blijkbaar kost het aan julllie aardig wat tijd om de mensen in het buitenland aan te sturen? Als het jullie zoveel tijd kost is dan toch nog lonend om werk naar het buitenland te verhuizen? Natuurlijk als je meer 'westers' gerichte mensen hebt zou het vast een stuk beter gaan dan. Maar toch.

[Verwijderd]

Verwijderd schreef op zaterdag 25 maart 2006 @ 22:18:
Wellicht dat het verstandig is om het in India ook eens te proberen, alleen ben ik nog zoekende naar een goede partner die gespecialiseerd is in web trajecten met een korte doorlooptijd.

Ik moet bekennen dat ik geen jaren ervaring met outsourcing heb. Ik herken uit een aantal boeken, colleges en aan workshops/congressen wel deze problemen. Persoonlijk zou ik er voor kiezen om te investeren in een partner waar jullie nu al in geinvesteerd hebben. Probeer de processen beter te stroomlijnen.
Je kan beter investeren in een ploeg die al 40% reductie in de doorlooptijd heeft behaald, dan in een ander land iets nieuws op poten te zetten. Investeer in je huidige kennis met betrekking tot outsourcing. Mocht er genoeg werk op de plank liggen, dan zou ik inderdaad overwegen om andere partners te zoeken en dit ook te communiceren met de andere partijen. Op die manier creeer je denk ik een vorm van concurrentie; de partij moet harder werken om aantrekkelijk voor jullie te blijven.
Verdiep je in de lokale cultuur. Weet wat leeft onder de bevolking daar. Probeer daar achter te komen. Laat merken wat je verwacht van mensen en zoek het liefst een aantal specialisten met buitenland ervaring of aantoonbare werkervaring. Zelf een unit daar opzetten waarbij je de mensen zelf uitkiest, lijkt mij de beste oplossing op de langere termijn. De vraag is alleen wat de ROI zal zijn en of het uit kan voor jullie organisatie.

[Verwijderd]

alienfruit schreef op zaterdag 25 maart 2006 @ 22:39:
Als ik dit allemaal zo lees krijg je een beetje het "Goedkoop is duurkoop" gevoel, blijkbaar kost het aan julllie aardig wat tijd om de mensen in het buitenland aan te sturen? Als het jullie zoveel tijd kost is dan toch nog lonend om werk naar het buitenland te verhuizen? Natuurlijk als je meer 'westers' gerichte mensen hebt zou het vast een stuk beter gaan dan. Maar toch.

Je hebt zeker aanloopkosten, maar er is ook een aanzienlijk potentieel. Als ik iemand in Nederland 40 uur laat werken, kost me dat op basis van een facturabel uurtarief +/- EUR 4000. Als ik iemand in het buitenland 40 uur laat werken, kost me dat +/- EUR 500.

Het enige verschil is dan wel dat je extra tijd en effort moet investeren in deliverables, er is weinig ruimte voor een snelle babbel dus het moet goed in elkaar steken. We hebben hier ook behoorlijk wat verbeteringen op aangebracht in samenwerking met project managers in het buitenland.

Je kunt niet alles outsourcen, maar er zijn taken waarvan je vooraf goed kunt uitschrijven wat je wilt, dit ook kunt visualizeren, geen prototypes mogelijk zijn en die veel marge kunnen opleveren. Bijvoorbeeld het bakken van web templates.

Daar komt nog bij dat er meer voordelen zitten. Ik heb altijd de beschikking over resources zonder risico. Als je dit vergelijkt met ontwikkelaars van eigen bodem, dan scheelt dat in kosten voor werkplekken, kosten voor opleidingen en certificering, geen verantwoordelijkheden inzake ziekteverzuim, etc. een werkgever betaald voor een werknemer als we kijken naar premies en belastingen een aanzienlijk bedrag per maand.

Het is dus een kwestie om zo snel mogelijk die marges te gaan benutten. Als ik een project kan verkopen voor 20k, en het kost een maand aan manuren om dit te realiseren dan heb je een flinke marge in de pocket. Dan praten we over een enkel project. Het is daarbij ook van belang om te werken aan een zo onafhankelijk mogelijke partner zodat de eigen kosten in verhouding staan met de besparingen.

Je moet inderdaad heel veel geduld opbrengen, initieel heel veel tijd steken in het managen en vastleggen van processen, maar ik ben er van overtuigd dat als dit eenmaal efficient verloopt je echt snel de vruchten gaat plukken van die investeringen.

[appies]

En die techneuten die hier worden opgeleid? Die mogen kijken hoe één of enkele mensen grof geld verdienen. Nee, ben er absoluut niet voor... het is voor de korte termijn veel geld verdienen. Mocht het hier slecht gaan dan hebben 'de snelle rijke' inmiddels voldoende geld om te vluchten. Het is meer een kwestie van moderne slavernij.

[Verwijderd]

Verwijderd schreef op zondag 26 maart 2006 @ 03:27:

Een van de punten die je continue blijft doen is resultaat meten, evalueren, bekijken wat er kan veranderen en wat de effecten daarvan kunnen zijn op zowel de korte als lange termijn.

Echter je bereikt op een bepaald punt een punt van omslag, waar je processen kunt blijven stroomlijnen, maar waarbij het rendement afneemt in vergelijking met de effort die je er zelf insteekt. Dat er 40% verbetering is gehaald kan betekenen dat we de minder complexe punten hebben kunnen aanpakken, de quick wins. Die ervaring hebben we inmiddels opgedaan, en kunnen we gebruiken voor de toekomst.

Er zijn echter andere aspecten die je niet makkelijk met deliverables of persoonlijke aandacht kunt aanpakken. De werking van een organisatie, de ervaring van de mensen, hoe kennis wordt gedeeld, de motivatie van mensen in hun werk, etc.

Als je keer op keer aangeeft, jongens communiceer, en het wordt niet gedaan dan blijft er weinig over dan de project manager te vervangen, of wat scherpere mails te sturen om ze op hun verantwoordelijkheden aan te spreken. Dat kun je niet doen zonder terugslag, een relatie komt daarbij ook onder druk te staan.

Keer op keer vragen om strakkere estimates, ook hierin kun je blijven sturen, maar als ze keer op keer hoog blijven houdt het verhaal een keer op en moet je wellicht kijken naar een club die wel dezelfde werkzaamheden in minder tijd kunnen uitvoeren.

Waar ik echter vooral benieuwd naar ben is of er mensen zijn op dit forum die ook dagelijks teams aansturen, en op welke manier zij omgaan met hoge estimatesm, en op welke manier bij hun partijen getest wordt en wat de kwaliteiten zijn van die tests. Ik denk zelf dat het gebrek aan fixed price constructies voor mij een belemmerende factor is, er is op die manier te weinig druk om binnen tijd & budget te presteren. Echter, de fixed price constructies kunnen ook resulteren in nog hogere estimates om safe te blijven.

[ Voor 8% gewijzigd door Verwijderd op 26-03-2006 14:41 ]

[Verwijderd]

appies schreef op zondag 26 maart 2006 @ 14:14:
En die techneuten die hier worden opgeleid? Die mogen kijken hoe één of enkele mensen grof geld verdienen. Nee, ben er absoluut niet voor... het is voor de korte termijn veel geld verdienen. Mocht het hier slecht gaan dan hebben 'de snelle rijke' inmiddels voldoende geld om te vluchten. Het is meer een kwestie van moderne slavernij.

Die techneuten zijn niet makkelijk te vinden, vacatures worden maar moeizaam ingevuld. Verder zijn er maar weinig techneuten die het leuk vinden om dag in dag uit templates te bakken, de uitdaging is er dan snel vanaf.

Wat we dus zelf doen, is het relatief eenvoudigere werk neerleggen in het buitenland. Ontwikkeling van web templates, ontwikkeling van modules op een basis van een .net content management omgeving, etc.

Het uitdagende werk blijft inhouse, verdere ontwikkeling van het content management systeem, uitwerkingen van technische documentatie, en er blijft meer tijd en budget over voor zaken die normaliter niet de aandacht krijgen die ze nodig hebben zoals regressie tests, r&d in nieuwe technieken of functionaliteit, het bespreken van functionaliteit ipv adhoc doorvoeren, etc.

Er zijn hier geen verliezers.

[Verwijderd]

Gordijnstok, ik snap dan niet helemaal hoe jullie op dit moment te werk gaan. De partij in het buitenland geeft een worst case estimate, en die blijkt eigenlijk altijd real estimate te zijn? Ze halen deadlines niet zonder dat er sancties op staan?
Bij al mijn freelance activiteiten wordt duidelijk afgesproken wie het haasje is wanneer een project niet op tijd af komt. Projecten geschieden op basis van een schatting, waar niet meer dan 10% van afgeweken kan en mag worden. Wanneer ik 100 uur schat, en ik blijk op 120 uit te komen, dan is dat *mijn* probleem. Ik heb het idee dat jullie de partij in het buitenland gewoon blijven uitbetalen voor alle uren die bovenop hun eigen planning komen.
Op zo'n manier geef je een fout signaal af. Overschreiden van deadlines wordt op die manier niet als een probleem ervaren; er wordt toch wel betaald. Wanneer ze direct in hun eigen zak voelen dat lummelen geld kost, zullen ze eerder geneigd zijn harder te werken. Op het moment dat je ziet dat de planningen gewoon omhoog geschroefd worden, dan is het misschien tijd om andere partijen te zoeken.
Ik kan haast niet geloven dat het een mentaliteitsprobleem is van een gehele bevolking. Zou het niet zo kunnen zijn dat ze wat beter opgevoed moeten worden, met als belangrijkste punt; overschreiden van deadlines is jullie probleem (met een marge van xx%).
Projecten gaan altijd fout wanneer er een geldkraan is die op commando opengedraaid wordt, zonder budgetten goed te beheersen. Wat zou een reden zijn voor de partij in het buitenland om harder te werken? Omdat jullie het keer op keer lief vragen?

[Verwijderd]

Er staan zeker sancties op, namelijk dat de rekening niet wordt betaald. Verder zijn ze geheel financieel afhankelijk van ons, als wij de rekening niet betalen hebben zij geen brood op de plank.

Bij eerdere projecten waar we constateerden dat deadlines niet zijn gehaald, is het meerwerk niet op onze kosten uitgevoerd maar hebben ze zelf moeten bloeden. Echter de actual time spend daalde niet.

Ik wil ook naar een situatie toe dat bij de start van het project duidelijker wordt dat ze financieel het haasje zijn als targets niet worden gehaald, alleen ligt een dergelijke beslissing politiek gevoelig omdat er meerdere parameters bij betrokken zijn, zoals een simpel voorbeeld; het verplaatsen van resources van andere projecten met minder impact zodat je daarmee kosten drukt. Het verhaal van fixed price tarifes is dus redelijk complex, maar is zeker iets waar ik naartoe wil.

De huidige situatie is dat ze in dienst zijn. Ik wil van die situatie af, ik heb niets aan werknemers wanneer er eerst werk moet worden voorbereid, verder zorgt het voor nare situaties zoals eigen initiatief buiten het voorgelegde takenpakket om. Dit is dus ook een van de zaken die na evaluaties naar voren komen.

Daar ligt echter niet de basis van hoge estimates. Zelfs als ze zelf de rekening zelf betalen zie je geen verbetering. Een fixed price tarife is maar een heel klein radertje in het geheel. Overigens heeft het laatste project, wat redelijk complex was wel flinke verbeteringen getoond.

Echter is het de vraag, of we hier in Nederland nu niet bevooroordeeld zijn op het gebied van efficiency en productiviteit. Overal waar je kijkt, van Frankrijk tot zelfs in de VS, is onze productiviteit velen malen hoger. Dat zijn dat culture verschillen die je moet respecteren, en niet moet willen omvormen naar je eigen verwachtingspatroon.

[ Voor 15% gewijzigd door Verwijderd op 15-04-2006 19:13 ]

[reddog33hummer]

Als je in de testfase fouten vind kost je dat 20 keer zoveel als wanneer je dat tijdens de requirements fase vind. Voor de implementatie <-> testfase is die verhouding 5 a 10. Wordt er op school geleerd.

Als je dat dus gaat vergelijken betekend dus dat die werknemer in roemenie dus 10 keer zo duur wordt als hij normaal kost. Dus in feite zou het lood om oud ijzer moeten zijn (loon verhouding) wanneer dit binnen 1 bedrijf speeld. Ik denk dat je gewoon betere afspraken moet gaan maken en mogelijk zelfs naar boeteclausules over moet gaan (zoals in de bouw).

[Verwijderd]

De school theorie gaat niet altijd op in de praktijk. Een van de redenen waarom agile methodieken zijn geintroduceerd.

[MSalters]

Klopt. Bij Lucent is het in de praktijk gemeten, en daar werd * 100 gevonden. Dat was de reden voor de introductie van CMM daar.

[Verwijderd]

Je zou eigenlijk verwachten dat er ondertussen wel coherente projectmanagement methodieken zijn ontstaan met betrekking tot het managen van offshore dev-teams, aangezien het begrip outsourcing niet echt nieuw is. Ik zou zelf niet weten waar je die kennis zou kunnen zoeken, maar er zullen zich toch al wel enkele goeroe's op deze mondiale kwestie hebben gestort?

[Verwijderd]

Er zijn voldoende project management methodieken beschikbaar, echter daarmee dek je de lading niet. Je kunt plannen, buffers gebruiken, dagelijkse status rapportages krijgen, meten welke resources veel of weinig rendement opleveren, maar uiteindelijk is het een team dat de grootste invloed heeft op een eindresultaat.

Ik pik nu een paar ergenissen eruit:

- Hoge estimates, dit kun je plannen maar ze zijn niet gewenst. Dit los je niet op met methodieken, maar met ervaring, kennis van de teamleden, en het wegnemen van factoren die resulteren in hoge estimates.

- Slecht of totaal niet testen, dit kun je niet plannen. We hebben mensen daar zitten die dedicated testen. Als blijkt dat ze in twee dagen, 50 bugs vinden, en wij in twee dagen al op 400 bugs zitten dan heeft dat niets te maken met methodieken, maar met commitment. Opleveren van ongeteste software is not done, echter het gebeurt wel ondanks dat we op papier hebben staan dat het testfases heeft doorstaan. Sterker nog, we eisen bij elk project een excel sheet met testcases en de resultaten daarvan tonen "success" terwijl eigen tests overduidelijk aantonen dat het nooit getest kan zijn.

- Slechte communicatie, dit kun je ook niet plannen. Als je zelfs 4 uur voor oplevering informeert naar de stand van zaken is alles koek en ei, op schema, geen problemen, etc. Vervolgens 10 minuten voor oplevering krijg je te horen dat deadlines niet gehaald worden.

Dit zijn allemaal zaken die je alleen met harde actie door je management moet laten oppakken, en daarom wordt communicatie bij ons ook altijd cc'd aan het management zodat ze direct op de hoogte zijn van situaties. De enige manier om dergelijke zaken te verbeteren is door ze financiele sancties te geven.

[ Voor 10% gewijzigd door Verwijderd op 15-04-2006 19:12 ]

[Verwijderd]

Verwijderd schreef op zondag 02 april 2006 @ 13:53:
- Slecht of totaal niet testen, dit kun je niet plannen. We hebben mensen daar zitten die dedicated testen. Als blijkt dat ze in twee dagen, 50 bugs vinden, en wij in twee dagen al op 400 bugs zitten dan heeft dat niets te maken met methodieken, maar met commitment.

De laatste keer dat ik in het "Oosten" was (nog wel iets verder, nl. Moskou), viel het mij vooral op dat veel werknemers daar veel meer extrensiek gemotiveerd zijn dan hier in Nederland. Dus daar heb je sowieso al een factor die de incongruentie in commitment verklaart. Een andere factor die meespeelt is dat zij natuurlijk veel minder direct met de klant te maken hebben; je ziet in andere werkvelden ook dat dergelijke indirecte werkrelaties een negatief effect hebben op onder meer verantwoordelijkheidsgevoel.

Opleveren van ongeteste software is not done, echter het gebeurt wel ondanks dat we op papier hebben staan dat het testfases heeft doorstaan. Sterker nog, ik eis bij elk project een excel sheet met testcases en de resultaten daarvan tonen "success" terwijl eigen tests overduidelijk aantonen dat het nooit getest kan zijn.

Hoe reageren ze wanneer je ze met dergelijke bevindingen confronteert?

- Slechte communicatie, dit kun je ook niet plannen. Als je zelfs 4 uur voor oplevering informeert naar de stand van zaken is alles koek en ei, op schema, geen problemen, etc. Vervolgens 10 minuten voor oplevering krijg je te horen dat deadlines niet gehaald worden.

Je geeft zelf al aan dat je dit soort situaties probeert te voorkomen door de voortgang inzichtelijker te maken met behulp van statusreports. Wellicht kun je hier nog verder in gaan en tevens negatieve reinforcement toepassen.

Dit zijn allemaal zaken die je alleen met harde actie door je management moet laten oppakken, en daarom wordt communicatie bij ons ook altijd cc'd aan het management zodat ze direct op de hoogte zijn van situaties. De enige manier om dergelijke zaken te verbeteren is door ze financiele sancties te geven.

Exact.

[ Voor 7% gewijzigd door Verwijderd op 02-04-2006 16:50 ]

[Verwijderd]

Even een update, en ik zag dat ik nog niet op bovenstaande post had gereageerd. De situatie is geescaleerd vanuit het management nadat ze zelf een project hebben laten uitvoeren waarvan ze zelf schrokken van het resultaat en de communicatie. We gaan flinke wijzigingen doorvoeren, dwz oa. dat projecten in het vervolg via fixed price constructies gaan.

We zijn alleen nog aan het kijken op welke manier we acceptatiecriteria gaan opstellen. Je hebt een gedeelte wat meetbaar is en wat niet meetbaar is. We willen liever ook niet meteen een ISO 9126 erop loslaten. De fixed price constructie heeft een nadeel, en dat is dat je niet zomaar kunt zeggen "pas dit op je eigen kosten aan".

Wat je kunt meten zijn zaken als:
- Werkt wel / werkt niet
- Aantal issues die daadwerkelijk als bug geclassificeerd zijn

Maar als team willen we ook een bepaalde code kwaliteit zien. Dat kun je niet meten, en we zijn nog aan het bekijken hoe we dat in contractvorm kunnen krijgen. Je kunt iemand niet op zijn vingers tikken als je zelf niet kunt aangeven wat je verwacht. Code kwaliteit is subjectief.

Verwijderd schreef op zondag 02 april 2006 @ 16:47:
je ziet in andere werkvelden ook dat dergelijke indirecte werkrelaties een negatief effect hebben op onder meer verantwoordelijkheidsgevoel.

Dat hou je denk ik altijd, het is daarom belangrijk om ze onderdeel uit te laten maken van iets. Op het moment dat je samenwerkt aan projecten met een interne software engineer als supervisor kun je goed dat gevoel sturen.

Hoe reageren ze wanneer je ze met dergelijke bevindingen confronteert?

Heel beleefd, maar vaak mondt het uit in discussie over wat we moeten veranderen aan processen om het de volgende keer beter aan te pakken.

Dit is een van de onderdelen die heeft gezorgd voor escalatie. Telkens kwam men met "Misschien moeten jullie dit aanpassen". Als we echter kijken naar de deliverables, dan staat het in jip en janneke taal goed beschreven, met screenshots, etc. echter het eindresultaat lijkt er in geen verte op.

[ Voor 37% gewijzigd door Verwijderd op 15-04-2006 19:11 ]