Like a movie trailer, but for books. Watch, listen, or read along, then go as deep as you want.
Great lessons shouldn't depend on spare time, money, or how you learn. Free in 8 languages, for everyone.
Ljudbokssammanfattning av StoryShots
En enda ingenjör kunde ensam avgöra om hela företaget skulle överleva.
De flesta IT-avdelningar tror att deras problem är för lite personal eller för lite tid.
Det stämmer nästan aldrig.
Det är den centrala insikten i The Phoenix Project: En roman om IT, DevOps och att hjälpa ditt företag att vinna, av Gene Kim, Kevin Behr och George Spafford.
Bill Palmer befordras rakt in i en kris med nittio dagar på sig att rädda ett projekt på fallrepet, och upptäcker att fienden hela tiden varit osynlig.
De flesta chefer behandlar IT som en svart låda.
Häll in pengar och deadlines, hoppas på att något användbart kommer ut.
Det tänket är bakvänt.
IT-arbete rör sig genom stationer, köer och överlämningar precis som en bildel rör sig genom ett löpande band.
Parts Unlimited hade aldrig ritat upp den kartan, så arbete hopade sig osynligt mellan team medan alla skyllde på varandra.
Just nu ligger förmodligen något i din egen inkorg och väntar på en överlämning som ingen bevakar.
Varje obevakad kö är en lagerbrand som bara väntar på en tändsticka.
När Bill börjar se IT som ett produktionssystem istället för en svart låda inser han att han har lett kaos, inte flöde.
Att kartlägga golvet räcker dock inte, för nästa fråga är vilket arbete som faktiskt förstör det.
Bills mentor Erik tvingar honom att sortera varje uppgift i fyra fack: affärsprojekt, interna IT-projekt, förändringar och oplanerat arbete.
De tre första går att schemalägga.
Den fjärde dyker bara upp, objuden.
Här kommer den obekväma delen: oplanerat arbete konkurrerar inte med planerat arbete, det förstör det.
Varje brandkårsutryckning äter upp timmar som lovats till något annat, vilket är varför deadlines glider även när alla jobbar övertid.
Boken beskriver hur planerat arbete antänds med glödande raseri i samma sekund som oplanerat arbete träffar systemet.
Du har känt det här.
Dagen äts upp av akutärenden, och det riktiga projektet rör sig inte en millimeter.
Att kategorisera arbetet visar var skadan uppstår.
Det visar ännu inte hur man stoppar blödningen, och den frågan blir akut i samma stund Bill upptäcker var alla fyra typer av arbete faktiskt krockar.
Allt krockar hos Brent.
Han är den ledande ingenjören som är den enda som förstår hur de urgamla, odokumenterade systemen faktiskt fungerar, och han dras in i varje driftstopp och varje driftsättning eftersom han är den ende som kan lösa det snabbt.
Att anställa fler ingenjörer hjälper inte.
De ställer sig bara i kö och väntar på Brent.
Varje förbättring som görs någon annanstans än vid den verkliga flaskhalsen är en illusion.
Den meningen kastar om allt Bill trott sig veta.
Den väcker också en större fråga som berättelsen knappt hunnit röra vid: om att skydda en enda person räcker för att rädda företaget, vad händer den dagen den verkliga flaskhalsen inte är en person alls, utan hela driftsättningskedjan?
Om det här förändrade hur du ser på brandkårsutryckningar på jobbet, skicka den här sammanfattningen till någon som just nu drunknar i sitt eget oplanerade arbete.
Den här sammanfattningen av The Phoenix Project kopplar ihop tre idéer till ett resonemang: se IT som ett synligt produktionssystem, namnge de fyra typerna av arbete som äter upp din kalender, och skydda den verkliga flaskhalsen innan du sätter in fler händer.
Gene Kims roman går mycket längre och går igenom hela De Tre Vägarna, Kanban-tavlor i praktiken, och Begränsningsteorin tillämpad steg för steg mot en säkerhetskris som nästan spårar ur hela räddningsaktionen.
Alla som leder ett team som drunknar i ärenden, driftstopp och omöjliga deadlines behöver den här historien.
Vi håller just nu på att sätta ihop den fullständiga sammanfattningen av The Phoenix Project, med infografik och animerad video.
Följ boken i StoryShots-appen för att få den så fort den är klar.
