Vad är bäst? Att vara generalist eller specialist?

Läs vår gästbloggarens reflektioner kring vad som är bäst: att vara generalist eller specialist.

Under det senaste decenniet har det funnits en tendens att ständigt öka ansvarsområdet för både utvecklare och testare. De tidigare strikta gränserna mellan exempelvis utveckling, testning och drift tycks ha blivit mer och mer diffusa. Men är det bra eller dåligt? Och hur ska man tänka om arbetsgivaren lägger mer och mer olika uppgifter på ens bord? Läs vår gästbloggares reflektioner kring vad som är bäst: att vara generalist eller specialist.

Jag hade just ett samtal med en nära vän till mig angående problematiken att QA har så många olika arbetsuppgifter. Ofta kan det vara uppgifter som ligger helt eller delvis utanför deras ansvarsområde, såsom vissa delar av release management eller systemkonfiguration.

Det fick mig att inse att det funnits en tendens att successivt öka omfattningen av både utvecklare och testares ansvarsområde under det senaste decenniet. Tidigare fanns det ganska strikta gränser mellan exempelvis utveckling, testning och drift, men de har nu blivit mer och mer diffusa.

Jag tror att detta främst beror på den agila trenden, som betonar tvärfunktionella team, och som därmed kan ta på sig produktägarskap från början till slut. Och ur ett affärsperspektiv är det helt klart ett mycket mycket effektivare sätt att arbeta på: att besluta om något inom ett team tar betydligt mindre tid än om man måste springa runt i fyra olika team för att komma överens om vad som ska göras (och försöka klämma in det i deras schema).

Men denna nya vardag kräver också att medarbetarna måste ha en bredare kompetens. För två decennier sedan kunde till exempel en QA nöja sig med att ha ett teknikintresse och kunskap om hur man klickar på knappar, oftast räckte det för en junior testare – som med de förkunskaperna ändå kunde göra jobbet bra. Nu är kraven betydligt högre; man måste kunna programmera, skapa testplaner, och arbeta med en oändliga mängder olika verktyg. Samma sak gäller för utvecklare, som ofta måste förstå hur man utvecklar, testar, lanserar, övervakar – bland mycket annat.

Men hur kan man tänka? Jag skulle rekommendera ingenjörer att göra tre saker:

1. Bredda din kompetens

Även om det kan kännas sorgligt så är vi tyvärr förbi den tid när man kunde nöja sig med att lära sig en sak och inte bry sig om något annat. Istället måste du hela tiden ta till dig nya framväxande tekniker och trender. Det innebär inte att du alltid behöver vara först på bollen, men det är viktigt att lära sig saker som har blivit populära (vet du till exempel inte hur Git fungerar vid det här laget skulle jag rynka pannan). Detta är särskilt viktigt med tanke på att allting ständigt förändras. Till exempel skrev jag förr backend i ColdFusion. Hade stannat där hade jag målat in mig ordentligt i ett hörn vid det här laget.

2. Var specialist på minst en sak åt gången

Ni kanske tycker att den motsäger föregående punkt. Så är det dock inte. Att kunna lite om mycket är till hjälp när du ska välja och lära dig ett specifikt område på djupet. Men det är också bra att kunna ett specifikt område bättre än andra – det öppnar många dörrar. Att vara en duktig generalist är i sig värdefullt – men att både vara generalist och ha en viss specialisering är en grym kombo.

3. Gör inga slarviga jobb

När ett ansvarsområde växer finns det en tendens att göra minsta möjliga ansträngning inom sekundära områden, och prioritera det primära. Vi har alla varit där: "Låt oss stänga den här 'ticketen' för att få den ur vägen". Och det är helt okej, om området inte är kritiskt, men problemen uppstår när man gör ett halvdant jobb inom ett viktigt område. Till exepempel om någon skulle be dig gå och konfigurera ett system du inte är bekant med. Du läser en halv sida dokumentation och googlar tre kommandon. Boom. Du är klar. Detta blir sällan bra, inte minst i det långa loppet. Oftast får du äta upp det vid ett senare tillfälle och får börja googla igen. Det viktiga här är att skilja mellan kritiska arbetsuppgifter och mindre viktiga. Så om du får en viktig uppgift där din kunskap och tidsramen för att förstå uppgiften inte är tillräcklig – då är det dags att prata med din chef. Prata igenom uppgifterna utifrån prioriteringar och risker: förklara riskerna med att göra det snabbt och utan tillräckligt kunskap, och hur stor påverkan detta kommer att ha på andra saker på din to-do där du har större kunskap.  Då är jag övertygad om att ni kommer komma fram till en bra tågordning tillsammans

Sammanfattningsvis

Var en generalist med viss specialisering och prata med din chef om du ser att det finns en obalans mellan tidsramar, kunskap och arbetsuppgifter. Det kommer ge dig möjlighet att hantera bredare ansvarsområden – och med största sannolikhet också betala sig i lönekuvertet. 

Gästbloggare: Victor Ronin