Det kan vara svårt att veta när det är dags att sluta på ett jobb. Här kommer IDG News till undsättning med sju tecken att hålla ögonen på för utvecklare.

1. Systemet du jobbar med kallas legacy

Om man jobbar med ett ”legacysystem” så är det dags att putsa upp sitt cv, vidareutbilda sig och lära sig nya saker. Arbetsgivaren, speciellt ekonomerna, funderar på hur de kan ersätta systemet och på många företag är man dumma nog att även göra sig med folket som jobbat med det, för att kunna anställa någon som kan det nya systemet.

Visst finns det gott om folk som fått bra och långa karriärer genom att jobba med vidareutveckling av äldre system. Men det kan bli tufft om man inte lärt sig något nytt på 20 år och plötsligt måste hitta ett nytt jobb. Ibland är det bättre att ta flera små risker än att riskera det värsta av allt: Att bli irrelevant.

Läs också: Agil transformation är enkelt – man behöver bara ändra på allt i företaget


2. Du blir inte inbjuden till möten som du brukade gå på

Oberoende av om anledningen är personlig, yrkesmässig eller teknisk så är uteblivna inbjudningar till möten vanligtvis ett tecken på att man är på väg ut. Leta rätt på den stora rektangeln på väggen och gå igenom den.

3. Osakliga chefer

Många typer av diskriminering är lätta att känna igen, men det finns typer som är svårare att upptäcka. Ett exempel är att man får skäll för saker som går oförmärkt förbi för ens kollegor. En annan att belöningarna är mindre än för andra. Eller att ens utvärderingar oförklarligt svänger från att vara positiva till negativa, utan att man gör något annorlunda.

Även om man själv slipper råka ut för det här, så är det läge att fråga sig om man verkligen vill jobba på ett ställe där sådant här pågår.

4. Inga kvalitetsstandarder

Det finns företag där det krävs ett ”business case” för att få skriva en enhetstest. På andra företag är den enda feedbacken man får efter att ha klarat av en leverans skäll för de buggar som, otroligt nog, hittas. Stick därifrån!

5. Toppstyrd design

Visst ska det finnas arkitekter och programmerarna ska inte bestämma affärskraven helt själva. Men om en chef kommer in och slår fast ett krav och alla säger att det inte kommer att fungera när chefen gått, men ändå sätter i gång att jobba för att uppfylla kravet, så är det dags att dra. I alla fall om du vill slippa undermåliga applikationer och misslyckade projekt.

En variant på det här är att nya krav formuleras slumpmässigt kort tid innan leverans. Efter att utvecklarna jobbat hårt, ofta natten innan leverans, visar det sig otroligt nog ofta att de nya kraven inte implementerats på bra sätt. Att man kallar ett sådant här sätt att jobba ”agilt” är ingen anledning att acceptera det.

Läs också: Konsultbolagen skriker efter folk – här är kompetenserna som är hetast

6. Byråkratiskt införande av agila arbetssätt

Du kanske har sett någon schematisk beskrivning av en agil process som påminner om ett dåligt designat tunnelbanenät? Faktum är att någon troligtvis trott att det var den bästa tänkbara beskrivningen av en agil process för mjukvaruutveckling.

Tänk dig antalet sidor med processdokumentation som blir resultatet. Det finns gott om företag som fortsätter tänka vattenfall när de inför agil terminologi. När det blir dags att verkligen få något gjort så struntar man i agila arbetssätt. Om du vill bygga mjukvaror som faktiskt fungerar så bör du inte jobba på ett sådant företag.

7. Upprepade misslyckanden

Om mjukvaran som ditt team levererar ständigt är undermålig, vilket kanske framför allt interna team kan komma undan med, och man vägrar att ändra hur man arbetar så kanske det är dags för dig att använda dina fötter och byta team.