Monday, December 15, 2008
Thursday, November 6, 2008
Tips för att lyckas bättre med acceptanstestning:
Vanligt är att skriva acceptanstester efter utvecklingsaktiveteten. Men att identifera vad som skall testas, vilka acceptanskriteria som skall vara uppfyllda efter utvecklingen redan har utförts ter sig rätt märkligt vid närmare analys. Då är ju produkten redan skapad.
Att istället identifera acceptanskriteria - vilka kriterier som skall vara uppfyllda för att en del av en produkt skall anses fungerande, och accepteras, av kund före en viss del av en produkt (t.ex en viss funktion i ett informationssystem) byggs ter sig aningen mer effektivt. Det blir färre överraskningar på slutet.
Detta är inga nyheter. Detta arbetssätt har länge använts inom produktutveckling inom industrin, som att bygga flygplan exempelvis. Identifiera först vilka test som skall passera - bygg sedan ett inkrement som gör att testet passerar.
Genom att synkronisera identifieringen av acceptanstest med kravutredning effektiviseras arbetet och onödiga fel undviks som beror på fördröjning mellan kravanalys och analys av testkriteria. Dokumentation blir mer korrekt och lättare att underhålla och överblicka.
Genom att kombinera kompetens hos traditionella kravutredare med kompetens hos traditionella QA-avdelningar kan en organisation få ett kraftfullt verktyg att uttrycka krav. Detta är också till stor hjälp för utvecklarna som när de utvecklar en viss funktion redan vet vad som kommer testas och alltså vet vad som förväntas av en särskild funktion som skall byggas.
Att därtill lägga iterativ (kontinuerlig) uppdatering av krav/test-specifikationer med hjälp av tidig feedback från utvecklingsteamet (genom kontinuerliga leveranser), tidig feedback från kund (genom att denne tidigt ser vad som utvecklats) och i en ideal situation, tidig feedback från användare, tas acceptanstestningen och värdet av produktutvecklingen ytterligare ett steg framåt.
Att istället identifera acceptanskriteria - vilka kriterier som skall vara uppfyllda för att en del av en produkt skall anses fungerande, och accepteras, av kund före en viss del av en produkt (t.ex en viss funktion i ett informationssystem) byggs ter sig aningen mer effektivt. Det blir färre överraskningar på slutet.
Detta är inga nyheter. Detta arbetssätt har länge använts inom produktutveckling inom industrin, som att bygga flygplan exempelvis. Identifiera först vilka test som skall passera - bygg sedan ett inkrement som gör att testet passerar.
Genom att synkronisera identifieringen av acceptanstest med kravutredning effektiviseras arbetet och onödiga fel undviks som beror på fördröjning mellan kravanalys och analys av testkriteria. Dokumentation blir mer korrekt och lättare att underhålla och överblicka.
Genom att kombinera kompetens hos traditionella kravutredare med kompetens hos traditionella QA-avdelningar kan en organisation få ett kraftfullt verktyg att uttrycka krav. Detta är också till stor hjälp för utvecklarna som när de utvecklar en viss funktion redan vet vad som kommer testas och alltså vet vad som förväntas av en särskild funktion som skall byggas.
Att därtill lägga iterativ (kontinuerlig) uppdatering av krav/test-specifikationer med hjälp av tidig feedback från utvecklingsteamet (genom kontinuerliga leveranser), tidig feedback från kund (genom att denne tidigt ser vad som utvecklats) och i en ideal situation, tidig feedback från användare, tas acceptanstestningen och värdet av produktutvecklingen ytterligare ett steg framåt.
Thursday, February 7, 2008
Kom-ihåg-lista för teknisk utveckling
Jag säger inte att jag lever så här fullt ut alltid hela tiden, men steg för steg kommer jag närmare
Sammanfattning: Minska den tekniska risken och skulden! Det låter tråkigt för kund i första läget, men oj vad det lönar sig när det finns på plats - och löpande förbättras, eller snarare - vad tydligt dyrt det blir när det inte görs.
Försök baka in tekniska förbättringar i funktionalitet som utvecklas för att också visa att "det händer något" för användaren.
- Ta itu med driftsättningsfrågor genast. Oavsett hur lite funktionalitet du har utvecklat. Se till att komma i land med en testmiljö som liknar den slutliga produktionsmiljön. Se sen till att snarast gå vidare till driftsmiljö, kanske utan att publicera någon officiell ingång till denna. Varför? Det inträffar alltid problem vid driftsättning av nya miljöer. Bättre ta itu med dessa genast innan verksamheten hamnar i "panikläge" för att komma i drift med redan utvecklad funktionalitet.
- Prioritera utbyte av gamla versioner av system, den tekniska skulden växer och blir alltför svår att underhålla med tiden.
- Prioritera gedigna testmiljöer. Det är jobbigt att återskapa produktionsmiljö i lokal testmiljö, men ta tjuren vid hornen, och buggar hittas och kan rättas innan det är dags för produktionsdrift. Ju tidigare det går att testa, desto bättre.
Sammanfattning: Minska den tekniska risken och skulden! Det låter tråkigt för kund i första läget, men oj vad det lönar sig när det finns på plats - och löpande förbättras, eller snarare - vad tydligt dyrt det blir när det inte görs.
Försök baka in tekniska förbättringar i funktionalitet som utvecklas för att också visa att "det händer något" för användaren.
Wednesday, November 21, 2007
Användbarhet som det lilla extra...
Användbarhet har inom systemutveckling länge betraktats som "det där lilla extra" som man kan ägna sig åt på slutet om det finns pengar kvar. DÅ ska vi göra ett trevligare användargränssnitt, DÅ ska vi bemöta användares feedback, DÅ ska vi titta på vad användarna egentligen vill ha..
Ungefär så har också testning av system betraktats under lång tid, fram till ungefär nu, då fler och fler utvecklare och systemägare börjar betrakta automattestning som en naturlig del av produktens utveckling som sker samtidigt med produktens design och produktionskod.
Att testning börjar få sin naturliga plats i det dagliga utvecklingsarbetet beror på att fler inser värdet av detta, att det på sikt kostar mindre att bygga ett testat system från början.
När skall användbarhet börja betraktas på detta sätt? Som en naturlig och kostnadsbesparande del av systemets tillväxt?
Forskning visar att användarorientering är den faktor som har störst vikt för en produkts framgång och livstid. Företag som satsar på kundorientering och som ägnar all sin kraft åt att bygga det kunderna verkligen vill ha och behöver är de som också har längst livskraft och blir mest framgångsrika.
Varför är det då så att utveckling av ett systems användbarhet fortfarande betraktas som "det lilla extra"? Varför betraktas användbarhetsexperter som något man gärna vill ha men inte har råd med? Hur kan man inte ha RÅD med den största framgångsfaktorn för ett datorsystem undrar jag? Att det sen finns användbarhetsutvecklare och interaktionsdesigners av olika kompetensgrad är naturligtvis lika självklart som att det finns olika kompetenta och erfarna programmerare, projektledare och beställare. Har man russinen i kakan har man större framgångspotential.
Och när man väl lyckats få resurser för en användbarhetsexpert, varför betraktas dennes resultat och dennes förslag ofta som något man gör om man får tid?
Min åsikt är att användbarhet skall ingå i det dagliga arbetet på samma sätt som testning och annan feedback. Om vi idag får feedback från driftsavdelningen att systemet står stilla, sätts alla resurser in för att lösa problemet och starta systemet igen. Om vi idag får feedback från användare att funktionen eller användargränssnittet är obegripligt, läggs feedbacken på hög att prioriteras vid senare tillfälle. Det bör vara samma "stop-the-line"-princip när användare har en ohållbar arbetssituation som när leveransen inte går att installera.
Och naturligvis finns det skillnader på en ohållbar arbetssituation och en ideal arbetssituation vilket produktutvecklare tillsammans med sin teammedlem användbarhetsutvecklaren får hitta ambitionen och gränserna för. Problemet är att all slags användbarhetsanpassning betraktas som det ideala och att det är alltför sällan som något betraktas som ohållbart idag, av andra än - användaren.
Användbarhetsutveckling ÄR systemutveckling.
Ungefär så har också testning av system betraktats under lång tid, fram till ungefär nu, då fler och fler utvecklare och systemägare börjar betrakta automattestning som en naturlig del av produktens utveckling som sker samtidigt med produktens design och produktionskod.
Att testning börjar få sin naturliga plats i det dagliga utvecklingsarbetet beror på att fler inser värdet av detta, att det på sikt kostar mindre att bygga ett testat system från början.
När skall användbarhet börja betraktas på detta sätt? Som en naturlig och kostnadsbesparande del av systemets tillväxt?
Forskning visar att användarorientering är den faktor som har störst vikt för en produkts framgång och livstid. Företag som satsar på kundorientering och som ägnar all sin kraft åt att bygga det kunderna verkligen vill ha och behöver är de som också har längst livskraft och blir mest framgångsrika.
Varför är det då så att utveckling av ett systems användbarhet fortfarande betraktas som "det lilla extra"? Varför betraktas användbarhetsexperter som något man gärna vill ha men inte har råd med? Hur kan man inte ha RÅD med den största framgångsfaktorn för ett datorsystem undrar jag? Att det sen finns användbarhetsutvecklare och interaktionsdesigners av olika kompetensgrad är naturligtvis lika självklart som att det finns olika kompetenta och erfarna programmerare, projektledare och beställare. Har man russinen i kakan har man större framgångspotential.
Och när man väl lyckats få resurser för en användbarhetsexpert, varför betraktas dennes resultat och dennes förslag ofta som något man gör om man får tid?
Min åsikt är att användbarhet skall ingå i det dagliga arbetet på samma sätt som testning och annan feedback. Om vi idag får feedback från driftsavdelningen att systemet står stilla, sätts alla resurser in för att lösa problemet och starta systemet igen. Om vi idag får feedback från användare att funktionen eller användargränssnittet är obegripligt, läggs feedbacken på hög att prioriteras vid senare tillfälle. Det bör vara samma "stop-the-line"-princip när användare har en ohållbar arbetssituation som när leveransen inte går att installera.
Och naturligvis finns det skillnader på en ohållbar arbetssituation och en ideal arbetssituation vilket produktutvecklare tillsammans med sin teammedlem användbarhetsutvecklaren får hitta ambitionen och gränserna för. Problemet är att all slags användbarhetsanpassning betraktas som det ideala och att det är alltför sällan som något betraktas som ohållbart idag, av andra än - användaren.
Användbarhetsutveckling ÄR systemutveckling.
Thursday, November 15, 2007
Produktägare - i Scrum och agil systemutveckling
Eftersom jag inte hittat någon svensk beskrivning av rollen som Produktägare och alla inte är anglofiler kommer här en sammanfattning av den utmanande och engagerande rollen. Baserat på info från bl.a:
www.scrumalliance.org
Kent Beck - Extreme Programming, Embracing change.
Kent Beck - User stories applied
och egen erfarenhet.
Produktägaren hjälper teamet att vid behov lyfta ut funktionalitet ur en iteration eller skala ner åtagandet. Denna person kan komma från olika discipliner och kan naturligtvis använda sig av omgivande kompetenser och kundrepresentanter för att fatta beslut eller för att förstå innebörden av olika vägval och prioriteringar.
Produktägaren skall uppmuntra att systemet växer på ett sådant sätt att det möter speciella behov hos kunderna och marknaden.
Produktägaren ansvarar för ROI och att den funktionalitet som byggs motsvarar ett faktiskt och aktuellt behov hos verksamheten. Inom disciplinen Lean utökas denna roll till att ofta vara både initiativtagare, marknadsförare och del av teknisk utveckling av produkten, detta brukar kallas Produkt-champion.
Produktägaren är inte ensam
Produktägare är en ansvarsfylld roll som innefattar att försöka tillgodose och prioritera mångas intressen. Därför är det vanligt att produktägare omger sig med ett representativt kundteam och användbarhetsexperter där så möjligt. En användbarhetsexpert kan vara ett ovärderligt stöd i att förstå och tillvarata användares verkliga behov, vilket brukar vara nyckeln till en produkts framgång.
Utvecklingsteamet är också ett viktigt stöd till produktägaren genom att vara de som förklarar konskekvenser av olika vägval och prioriteringar, och att komma med förslag, idéer och ifrågasättanden och ständigt hjälpa produktägarens arbete framåt.
ScrumMaster/Projektledare är också ett stöd till produktägaren som beskrivs nedan.
Vad gör projektledaren då?
En projektledare som verkar i ett agilt utvecklingsprojekt har som huvudsaklig uppgift att undanröja hinder för teamet, att vara ett stöd för produktägaren att kommunicera med omvärlden och resten av organisationen, att stimulera och verka för metodförbättring och teamstärkande aktiviteter.
Projektledaren ansvarar för att synkronisera planering med verkligheten och kommunicera detta med intressenter. Projektledare underlättar kommunikation från kunder, användare, sponsorer, ledning mm till teamet och också kommunikationen internt i teamet, den som sker mellan produktägare och utvecklare exempelvis.
Inom Scrum kallas detta ScrumMaster för att rollen inte skall förväxlas med den traditionellt beskrivna projektledarrollen.
Vad som skett är ett skifte av vissa uppgifter till produktägaren, såsom vad som faktiskt skall utvecklas. Vissa uppgifter som traditionellt utförts av projektledare, som detaljplanering av aktiviteter har skiftats till utvecklingsteamet som gör detta under iterationsplaneringar. Inom agil systemutveckling har den kontrollerande uppgiften hos projektledaren ersatts med ofta och regelbundna demonstrationer av den utvecklade produkten, som hålls av utvecklingsteamet själva.
Produktägaren som kund
Produktägaren kan vara ensam kundrepresentant eller ta hjälp av flera kundrepresentanter genom exempelvis ett utvalt kundteam som kan innehålla testare, riktiga användare (inklusive drifts- och supportpersonal) och användbarhetsexperter.
Som kund finns uppgiften att skriva "user stories" (korta funktionsbeskrivningar) som sedan utvecklingsteamet kommer använda i sina planeringsmöten. Det finns flera anledningar till att kunden och inte utvecklarna skriver dessa.
Den ena är att user stories skall skriva på kundens och verksamhetens språk, inte på teknikernas språk. Det gör att kundteamet förstår vad som skall prioriteras och att produktägare och team kan förstå det verkliga värdet och syftet med en user story.
För det andra faller det sig naturligt att produktägaren och kundteamet som de primära visionärerna för produkten är de bästa att uttrycka produktens beteende.
För att skriva bra user stories behövs övning och erfarenhet. ScrumMaster och utvecklingsteam eller andra personer som har tidigare erfarenhet av detta kan assistera produktägare och kundteam för detta.
Det är också kunden som tillsammans med utvecklare skall formulera acceptanstester. För det är kunden som vet vad det förväntade resultatet av en user story är, vilka test som skall passeras för att den utvecklade funktionen skall anses som klar (för denna gång). Utvecklaren hjälper kunden att specificera och implementera testet.
Utmaningar för produktägaren
Att vara produktägare är en ansvarsfull roll. Några utmaningar som kan finnas är:
www.scrumalliance.org
Kent Beck - Extreme Programming, Embracing change.
Kent Beck - User stories applied
och egen erfarenhet.
Produktägare
I Scrum och agil systemutveckling generellt, utses alltid en person som har yttersta ansvaret att representera kundens intressen, produktägaren. Denne utför sitt ansvar genom att identifiera och prioritera "user stories" (funktioner) inför varje inkrement av funktionalitet som skall byggas (iteration) . Produktägaren svarar på frågor från utvecklingsteamet under iterationen om vad som skall byggas och hjälper teamet att anskaffa nödvändig information från verksamheten . Produktägaren svarar inför verksamheten på frågor om systemets funktionalitet och prioritering.
Produktägaren hjälper teamet att vid behov lyfta ut funktionalitet ur en iteration eller skala ner åtagandet. Denna person kan komma från olika discipliner och kan naturligtvis använda sig av omgivande kompetenser och kundrepresentanter för att fatta beslut eller för att förstå innebörden av olika vägval och prioriteringar.
Produktägaren skall uppmuntra att systemet växer på ett sådant sätt att det möter speciella behov hos kunderna och marknaden.
Produktägaren ansvarar för ROI och att den funktionalitet som byggs motsvarar ett faktiskt och aktuellt behov hos verksamheten. Inom disciplinen Lean utökas denna roll till att ofta vara både initiativtagare, marknadsförare och del av teknisk utveckling av produkten, detta brukar kallas Produkt-champion.
Produktägaren är inte ensam
Produktägare är en ansvarsfylld roll som innefattar att försöka tillgodose och prioritera mångas intressen. Därför är det vanligt att produktägare omger sig med ett representativt kundteam och användbarhetsexperter där så möjligt. En användbarhetsexpert kan vara ett ovärderligt stöd i att förstå och tillvarata användares verkliga behov, vilket brukar vara nyckeln till en produkts framgång.
Utvecklingsteamet är också ett viktigt stöd till produktägaren genom att vara de som förklarar konskekvenser av olika vägval och prioriteringar, och att komma med förslag, idéer och ifrågasättanden och ständigt hjälpa produktägarens arbete framåt.
ScrumMaster/Projektledare är också ett stöd till produktägaren som beskrivs nedan.
Vad gör projektledaren då?
En projektledare som verkar i ett agilt utvecklingsprojekt har som huvudsaklig uppgift att undanröja hinder för teamet, att vara ett stöd för produktägaren att kommunicera med omvärlden och resten av organisationen, att stimulera och verka för metodförbättring och teamstärkande aktiviteter.
Projektledaren ansvarar för att synkronisera planering med verkligheten och kommunicera detta med intressenter. Projektledare underlättar kommunikation från kunder, användare, sponsorer, ledning mm till teamet och också kommunikationen internt i teamet, den som sker mellan produktägare och utvecklare exempelvis.
Inom Scrum kallas detta ScrumMaster för att rollen inte skall förväxlas med den traditionellt beskrivna projektledarrollen.
Vad som skett är ett skifte av vissa uppgifter till produktägaren, såsom vad som faktiskt skall utvecklas. Vissa uppgifter som traditionellt utförts av projektledare, som detaljplanering av aktiviteter har skiftats till utvecklingsteamet som gör detta under iterationsplaneringar. Inom agil systemutveckling har den kontrollerande uppgiften hos projektledaren ersatts med ofta och regelbundna demonstrationer av den utvecklade produkten, som hålls av utvecklingsteamet själva.
Produktägaren som kund
Produktägaren kan vara ensam kundrepresentant eller ta hjälp av flera kundrepresentanter genom exempelvis ett utvalt kundteam som kan innehålla testare, riktiga användare (inklusive drifts- och supportpersonal) och användbarhetsexperter.
Som kund finns uppgiften att skriva "user stories" (korta funktionsbeskrivningar) som sedan utvecklingsteamet kommer använda i sina planeringsmöten. Det finns flera anledningar till att kunden och inte utvecklarna skriver dessa.
Den ena är att user stories skall skriva på kundens och verksamhetens språk, inte på teknikernas språk. Det gör att kundteamet förstår vad som skall prioriteras och att produktägare och team kan förstå det verkliga värdet och syftet med en user story.
För det andra faller det sig naturligt att produktägaren och kundteamet som de primära visionärerna för produkten är de bästa att uttrycka produktens beteende.
För att skriva bra user stories behövs övning och erfarenhet. ScrumMaster och utvecklingsteam eller andra personer som har tidigare erfarenhet av detta kan assistera produktägare och kundteam för detta.
Det är också kunden som tillsammans med utvecklare skall formulera acceptanstester. För det är kunden som vet vad det förväntade resultatet av en user story är, vilka test som skall passeras för att den utvecklade funktionen skall anses som klar (för denna gång). Utvecklaren hjälper kunden att specificera och implementera testet.
Utmaningar för produktägaren
Att vara produktägare är en ansvarsfull roll. Några utmaningar som kan finnas är:
- Motstå frestelsen att lägga till mer viktigt arbete under iterationen
- Att vara inställd på att göra svåra och hårda prioriteringar under iterationsplaneringen
- Balansera avnämares olika och ibland motstridiga intressen
Tuesday, May 1, 2007
Ingen blir en ScrumMaster genom certifikation
Den lättrörliga utvecklingsmetoden Scrum vinner popularitet och det certifieras ScrumMasters till höger och vänster tycker jag mig se. Jag vet fler certifierade ScrumMasters som aldrig arbetat som projektledare än projektledare som är certifierade ScrumMasters.
Med det vill jag säga att det går inte att gå på denna certifikation för att avgöra om en person är en lämplig ScrumMaster eller ej, som om det vore något nytt. Det behövs upprepas.
Sen är förhoppningsvis certifieringskursen givande för aktiva projektledare, men det är huvudsakligen genom andra källor man lär sig bli en bra ScrumMaster tror jag. Deltagande av mer erfarna personer i samma projekt, dvs mentorer, är den bästa källan enligt min uppfattning.
Med det vill jag säga att det går inte att gå på denna certifikation för att avgöra om en person är en lämplig ScrumMaster eller ej, som om det vore något nytt. Det behövs upprepas.
Sen är förhoppningsvis certifieringskursen givande för aktiva projektledare, men det är huvudsakligen genom andra källor man lär sig bli en bra ScrumMaster tror jag. Deltagande av mer erfarna personer i samma projekt, dvs mentorer, är den bästa källan enligt min uppfattning.
Sunday, April 15, 2007
Det gör ont för en ScrumMaster att inte vara Produktägare
Traditionellt har (den tekniska) projektledaren haft ett övergripande ansvar för att att kraven förmedlas till utvecklare så att rätt funktionalitet utvecklas. Projektledaren har sedan levererat en lösning till kunden, som alltför ofta fått funktionalitet som sedan inte används.
Med lättrörliga (agila) metoder såsom Scrum, XP (Extreme Programming) skjuts det ansvaret till kunden - den som faktiskt skall ha systemet. Det är kunden (i Scrum "produktägaren") som skall ansvara för den löpande kravställningen och att rätt värde levereras i dagligt samarbete med utvecklarna.
Det är detta jag anser som det mest tilltalande i de "nya" metodikerna. Det är självklart att det är kunden som bör ansvara för sin egen funktionalitet. Teknikerna, inklusive projektledaren, skall hjälpa kunden med den tekniska lösningen och med hjälp att formulera krav och förstå vad dessa innebär i omfattning.
Det låter ju enkelt och självklart. I praktiken har det dock visat sig svårt både för
mig som projektledare/ ScrumMaster och för kunden/produktägaren att till fullo förstå innebörden av omfördelningen av ansvar.
Det gör ont för en ScrumMaster att inte längre vara den som utvecklarna vänder sig till för svar på frågor om vad krav betyder. I längden gör det naturligtvis inte ont längre, ScrumMastern får istället tid till annat mer betydelsefulla uppgifter - för en projektledare, än att stå till svars för funktionalitet som inte används av verksamheten. Som ScrumMaster sitter jag ju inte på den verksamhetskunskap som krävs för att kunna definiera dess behov (!)
Ont gör det ändå, det är en omställning och all förändring är förknippad med ångest, som min käre kollega Mats Nyberg brukar säga. Även min egen förändring är subtilt ångestfylld trots att det är jag själv som är min egen förändrings ivrigaste aktivist.
Det är en omställning som tar ifrån mig de uppgifter jag är van att ha, och som vi vet är vanor svåra att bryta, och särskilt dåliga sådana!
Jag är tacksam för att kunden börjar ta sitt ansvar för sin egen funktionalitet, med hjälp av mig, det är den enda riktiga vägen att gå. Men det är först efter lärandet inträffat som lusten finns där på riktigt.
Med lättrörliga (agila) metoder såsom Scrum, XP (Extreme Programming) skjuts det ansvaret till kunden - den som faktiskt skall ha systemet. Det är kunden (i Scrum "produktägaren") som skall ansvara för den löpande kravställningen och att rätt värde levereras i dagligt samarbete med utvecklarna.
Det är detta jag anser som det mest tilltalande i de "nya" metodikerna. Det är självklart att det är kunden som bör ansvara för sin egen funktionalitet. Teknikerna, inklusive projektledaren, skall hjälpa kunden med den tekniska lösningen och med hjälp att formulera krav och förstå vad dessa innebär i omfattning.
Det låter ju enkelt och självklart. I praktiken har det dock visat sig svårt både för
mig som projektledare/ ScrumMaster och för kunden/produktägaren att till fullo förstå innebörden av omfördelningen av ansvar.
Det gör ont för en ScrumMaster att inte längre vara den som utvecklarna vänder sig till för svar på frågor om vad krav betyder. I längden gör det naturligtvis inte ont längre, ScrumMastern får istället tid till annat mer betydelsefulla uppgifter - för en projektledare, än att stå till svars för funktionalitet som inte används av verksamheten. Som ScrumMaster sitter jag ju inte på den verksamhetskunskap som krävs för att kunna definiera dess behov (!)
Ont gör det ändå, det är en omställning och all förändring är förknippad med ångest, som min käre kollega Mats Nyberg brukar säga. Även min egen förändring är subtilt ångestfylld trots att det är jag själv som är min egen förändrings ivrigaste aktivist.
Det är en omställning som tar ifrån mig de uppgifter jag är van att ha, och som vi vet är vanor svåra att bryta, och särskilt dåliga sådana!
Jag är tacksam för att kunden börjar ta sitt ansvar för sin egen funktionalitet, med hjälp av mig, det är den enda riktiga vägen att gå. Men det är först efter lärandet inträffat som lusten finns där på riktigt.
Subscribe to:
Posts (Atom)
