Full åpenhet, når bedriftens primære produkt er programvare, vet du litt om programvareutvikling. I dette innlegget vil jeg avsløre min åpenbaring om hvordan programvareutviklingsprosessen kan brukes på alle andre aspekter av virksomheten din (og livet ditt) – uansett bransje, uansett stilling, uansett avdeling. [Spoiler alert: det er en bok du må lese – «The Phoenix Project» – i fremtiden din!]
Vi valgte « The Phoenix Project » til vår interne bokklubb. Jeg startet ikke med å skrive en anmeldelse, men denne atypiske forretningsboken er for god som et aha-øyeblikk til å holde for oss selv. Selv om jeg ikke er en utvikler (jeg jobber med noen flinke), lærte jeg hvordan de nærmer seg arbeidet sitt og om kule verktøy som [ Kanban ] for visualisering og administrasjon av arbeidsflyt. Verktøy som kan og vil fungere for alle!
«Føniksprosjektet: En roman om IT, DevOps og å hjelpe bedriften din med å vinne»
Av Gene Kim, Kevin Behr og George Spafford
Se for deg en fiktiv roman om en gruppe svært forskjellige individer som slår seg sammen for å erobre en drage og redde en landsby. I denne historien er «krigerne» forretningsfolk, landsbyen er en sviktende produksjonsbedrift (vertikalt integrert med e-handels- og detaljhandelskomponenter), og dragen representerer problemene bedriften står overfor, spesielt alle de utallige utfordringene innen IT-drift (som vi finner ut er sammenkoblet med alle andre avdelinger!).
Ethvert selskap – eller enhver person – som jobber med, i, for eller rundt «DevOps» bør lese denne humoristiske, men ofte skremmende romanen. Når vi koker ned vårt nåværende forretningsmiljø, og mer spesifikt den globale arbeidsstyrken, betyr det at denne boken er for ALLE.
Nesten alle bedrifter, bokstavelig talt, kjører på – og drives av – DevOps. Det er kjernen i organisasjonens nervesystem. Med mindre du er et barn som driver en kontantbasert limonadestand i hagen.
Hva er DevOps?
I IT-termer er DevOps en blanding av utvikling (Dev) og drift (Ops). Dagens programvarekultur er ikke lenger «silobasert», men slår disse fagfolkene sammen til ett team som jobber gjennom hele applikasjonens livssyklus, fra utvikling og testing til distribusjon, drift og kvalitetssikring. Erfaring lærer oss at det å jobbe i en silo hvor som helst, dvs. å ikke dele informasjon/kunnskap med andre, skaper flere problemer enn det løser.
Historien om «Phoenix-prosjektet» og hvorfor DevOps er viktig
DevOps er vår tids «produksjonsrevolusjon». Ved å bruke det falske teknologiselskapet Parts Unlimited (PU) illustrerer forfatterne hvordan mange bedriftsmiljøer vanligvis opererer (dysfunksjonelle!), og hvordan enhver endring, eller mangel på sådan, kan være transformerende, og DevOps er kjernen. Programvare er en integrert del av enhver bedrift, på alle nivåer. Historien gir god innsikt fra alle perspektiver, og den er ikke bare for tekniske typer.
Vår PU-historie (ordspill ment) starter med en katastrofe som venter på å skje. En IT-direktør på mellomnivå (Bill), hvis sjefer på mystisk vis har «sluttet», blir forfremmet til visepresident for IT-drift, en stilling han verken begjærer eller ønsker å akseptere. Hans oppdrag (tenk på «Mission: Impossible») – tildelt direkte av den først sjarmerende administrerende direktøren – er å gjenopprette kritisk forretningsdrift og holde selskapet unna forsidenyhetene ... alt dette midt i et årelangt, overdimensjonert nytt produkt, Project Phoenix, og selskapets offentlige økonomiske tillit som vakler.
Bills brev virker dømt til å mislykkes; Project Phoenix er PUs «ride-or-die». Det er bedriftspolitikk som svirrer rundt prosjektet, og markedsføringssjef (og administrerende direktørs tilsynelatende arving) Sarah er den primære antagonisten, med en uhyggelig evne til å skylde på andre for sine feil, i hvert fall ifølge IT.
Så oppstår det første problemet ... lønnssystemene er FUBAR (Fouled Up Beyond All Recognition). Bills ordre er klar: redd selskapet fra seg selv.
Frakoblingen
Vårt fiktive team starter med alle kjennetegnene til folk som verken stoler på eller tar hensyn til lagkameratene sine. Mangel på kommunikasjon er den minste – og til syvende og sist kjernen – av bekymringene deres. I stedet for å slå seg sammen for å løse problemer, skylder de på hverandre og trekker upassende konklusjoner om hverandre. Personligheter står i veien for profesjonalitet. Nedlatenhet og bedriftsteater florerer.
Uenigheten mellom avdelingene er åpenbar. Forfatterne gir oss en smakebit på hva IT-driftsmedarbeiderne tenker om resten av selskapet:
- Markedsføringsfolk er «kunst- eller musikkstudenter, ikke folk med bakgrunn i teknologistrategi».
- Selgere lover kundene det umulige og forventer at IT-avdelingen bare skal finne ut av det og levere; de er upålitelige: «Du vet ordtaket, ikke sant? Måten du kan se at en leverandør lyver på, er når leppene deres beveger seg.»
- Visepresidenter gir i utgangspunktet PowerPoint-presentasjoner – til hverandre – hele dagen lang.
- Utviklere «kaster gass på bålet»; krasjer alltid systemer; sjekker dem mentalt ut eller er på ferie; ødelegger ofte ting, forsvinner deretter og lar IT-drift rydde opp i rotet
- Informasjonssikkerhet i rommet er den beste måten å sørge for at noe IKKE blir gjort
En ansatt mener at det populære britiske TV-programmet «The IT Crowd» (en av favorittene mine!) nøyaktig gjenspeiler IT Operations' lodd i livet. IT-teamet – som oversetter CIO til «Karrieren er over» i stedet for Chief Information Officer – mener at forfremmelse ikke nødvendigvis er en god ting. Å holde hodet lavt hjelper deg med å unngå byråkrati i bedriften. Det fikk meg til å tenke på «flyterne» i noen reality-TV-programmer.
Etter hvert som PU-historien utfolder seg, øker mistanken, og det dukker opp konspirasjonsteorier om hvordan konkurrentene stadig får overtaket på dem. Er løse lepper på frifot?
Og det blir verre. Skriftlige spesifikasjoner blir ikke skrevet. Til tross for selskapets høyteknologiske markedsføringsbehov, blir ikke IT/drift konsultert i det hele tatt, og markedsføring outsourcer ofte IT-kjøp, noe som omgår avdelingen fullstendig.
Overleveringer, spesielt mellom utvikling og IT-drift, håndteres aldri godt. Det er de uforanderlige RUNDT-TØY-prosjektene: IT-oppgraderinger og vedlikehold som stadig blir utsatt fordi uforutsette nødsituasjoner og andre prioriteringer etterlater dem. Det er stammekrig.
Vurderingen – Systemet er ødelagt
Bill tar forfremmelsen sin – og alle brannene som skal slukkes – med ro. Hans ledelse ved å gå rundt med stil (og stille de vanskelige spørsmålene) hjelper ham med å sette selskapets problemer i et «stort bilde»-perspektiv slik de angår selve virksomheten.
Han vet at driften egentlig ikke burde fungere som brannmannskaper, og selv om PU, som et stort selskap, har flere folk tilgjengelig for å bekjempe de vanvittig tempofulle daglige «brannøvelsene» enn mindre selskaper, forblir problemene de samme. Alt er merket som haster. Men hvis alt haster, kan noe behandles raskt?
Prosesser, prosedyrer og systemer for endringshåndtering er på plass, men følges sjelden. Mangel på skikkelig «alle i samme rom»-planlegging er normen. Nødvendige testmiljøer finnes ikke, angivelig på grunn av manglende budsjett. Vilkårlige datoer for driftsetting i produksjon settes uten fullstendig hensyn til hva som faktisk må skje før utrulling.
Støtte kommer ikke fra toppen av selskapets kommandokjede. Oppdatert utstyr og opplæring er dårlig tilgjengelig luksus. Selskapet flyr i bunn og grunn i blinde. Det finnes ingen situasjonsforståelse. Venstrehånden vet ikke hva høyrehånden gjør.
Å være proaktiv er en ettertanke. Åpenhet er desperat nødvendig.
Prosjektleveransen er drevet av vilkårlige – men alltid hastende – uventede datoer, på grunn av eksterne forpliktelser gjort av toppledelsen uten fullstendig forståelse av interne problemer. Utviklingsavdelingen må da ta vanvittige og uakseptable snarveier for å levere. Produktet vil nesten helt sikkert være ubrukelig, og de som roper etter det vil bli alvorlig skuffet. Kundeopplevelsen vil være så dårlig at de blir drevet til konkurrenter. IT-driften må gjøre hva de kan for å få det til å fungere – og skjule hva som skjer bak kulissene.
Teamet kjemper for å ikke la det perfekte være det godes fiende. Imidlertid vil konsekvensene for virksomheten være ødeleggende; bedriften opererer ikke på bedriftsnivå.
Den nylig utgitte Phoenix-programvaren eksploderer.
Enkeltstående feilpunkt – hvem er din Brent?
Så har vi det «enkelte feilpunktet» – den ene uunnværlige ansatte som er midt i ethvert viktig prosjekt og blir dratt i en million forskjellige retninger. Tilsynelatende kan ingenting skje uten deres involvering. Han/hun kan ikke erstattes eller kopieres. I «The Phoenix Project» heter han Brent.
Produksjon kan ikke styres uten en sentralisert liste over prosjekter: PU kjenner ikke sine prioriteringer og forpliktelser knyttet til etterspørsel, status for pågående arbeid og ressurstilgjengelighet. IT-drift er midt i enhver arbeidsflyt, noe som skaper en flaskehals i pågående arbeid, prosjektleveranser, avbrudd og samsvar.
På PU har det blitt ansett som bortkastet tid å bruke på prioriteringsplanlegging. De følger ikke den generelle regelen om at hvis noe blir forsinket (i hast), så må noe annet forsinks. De har ikke funnet ut hvordan de kan redusere mengden arbeid med reparasjoner slik at inntektsskapende prosjektarbeid kan bli gjort.
Hvordan takle bedriftens eneste feilpunkt? Boken starter med å forklare begrensningsteorien.
Hva er begrensningsteorien?
Begrensningsteorien (TOC) er et ledelseskonsept der bare noen få begrensninger (det ene bemanningsfeilpunktet, eller flaskehalsen, som i en produksjonslinje) er alt som hindrer deg i å nå målene dine. Hvis du fokuserer, kan du identifisere hva begrensningen er og omgå den. Tenk på idiomet «en kjede er ikke sterkere enn det svakeste leddet».
Men hvis du gjør en forbedring et annet sted, enten foran eller etter flaskehalsen, eksisterer den begrensningen fortsatt. I vårt produksjonsscenario hoper arbeidet seg opp i frontenden, og varer i arbeid (WIP) sulter ut i bakenden av flaskehalsen.
Å administrere prosesser i DevOps er ikke så ulikt produksjon, fabrikkdrift og omvendt. Alle avdelinger kan lære av hverandre. De samme verktøyene og teknikkene kan brukes til å dokumentere prosesser, identifisere sløsing med tid og/eller materialer, og forbedre hele systemet.
Et av PUs styremedlemmer var veileder for Bill. Rollen hans ga nyttig fokus for oppgaven ved å skissere de fire arbeidstypene og de tre måtene.
Forstå de tre måtene
De tre måtene beskriver verdiene og filosofiene som danner grunnlaget for prosesser, prosedyrer og praksis i alle systemer. Målet for enhver bedrift, enhver avdeling og hver enkelt ansatt er å virkelig forstå – og sette pris på – systemet for å forbedre arbeidet sitt og levere bedre produkter og tjenester:
- Systemtenkning – Kontroller begrensninger og fremskynd arbeidsflyten, arbeid fra venstre til høyre ( lever raskere resultater )
- Forsterk tilbakemelding – Forkort tilbakemeldingssløyfen, arbeid fra høyre til venstre ( lever bedre kvalitet )
- Eksperimenterings- og læringskultur – Omfavn og oppmuntre til testing for raskere å anvende lærdommer fra feil ( redusere risiko og levere kontinuerlig forbedring )
Forstå de fire arbeidstypene
Å dele opp det vi gjør og tilordne målinger til hver type arbeid hjelper oss med å bedre identifisere flaskehalser, dvs. begrensninger:
- Forretningsprosjekter – Arbeid med direkte oversikt til bunnlinjen, for eksempel nye produkter og nye funksjoner
- Interne IT-/driftsprosjekter – Arbeid som kreves for å støtte forretningsprosjekter som FoU (forskning og utvikling), ny arkitektur, infrastruktur eller ingeniørfag
- Endringer – Modifikasjoner i planlagt arbeid med «interne prosjekter» som støtter «forretningsprosjekter»
- Uplanlagt arbeid – feil, mangler, omarbeid, krisehåndtering osv. som reduserer inntektsbringende «forretningsprosjekter»
Konklusjonen er tydeligvis at interne prosjekter som utføres godt har en positiv effekt på forretningsprosjekter og også reduserer mengden uplanlagt arbeid.
Uten å røpe slutten på boken (Prosjekt Enhjørning!), la oss bare si at spenningene eskalerer til territorium som ingen bedriftseier eller ansatt, leder eller andre ønsker å utforske.
Løsningen er innen rekkevidde
- Automatiser tilbakevendende prosesser så mye som mulig, kontroller og dokumenter arbeidet (spesielt endringer), og gjennomgå, gjennomgå, gjennomgå
- Identifiser problemer tidligere, del opp arbeidet i mer håndterbare deler, ta kontakt med alle interessenter for å sjekke resultater, gjør endringer etter behov og lever leveranser raskere.
- Standardiser for bedre, mer repeterbare, mer nøyaktige og raskere resultater
- Kommunisere
«Føniksprosjektet» fikk meg til å se på mange ting på en ny måte. For eksempel er alt et system. En bedrift, et produksjonsanlegg, en bys transportplan, til og med familien din eller din egen kropp. Løsningene for å håndtere alle disse «systemene» er uhyggelig like. Jeg kan ikke oppfordre alle nok: les boken.
Takeaway
- Å kjenne kundene dine på et mer intimt nivå kan være det mest verdifulle et selskap kan gjøre.
- Byråkrati er en naturlig del av enhver bedrift. Når bedriften vokser, trengs det nye sikkerhetstiltak for å sikre at kommunikasjonen er sømløs. Hvis bedriften din er liten og folk blir utskiftet, oppstår også disse kommunikasjonsproblemene på bedriftsnivå.
- Endringsledelse krever disiplin – det er smertefullt å utvikle, men det er mye verre hvis det IKKE eksisterer. «Du kan ikke oppnå det strategiske før du mestrer det taktiske.»
- Hvis noen spør hvordan du fikset noe, er det ingenting verre enn å si «Jeg vet ikke». Dokumenter! Neste gang det skjer, har vi svaret. Kunnskap er makt. Kunnskap som ikke deles er verdiløs, og enda verre – den skaper kaos.
- Hvis én avdeling når en milepælsleveranse, men en annen gruppe i bedriften blir negativt påvirket, ikke hold en «kegger» og send en e-post. Det er bare dårlig form. Du likte det sannsynligvis ikke da hele femteklassen – bortsett fra deg – ble invitert til den kule guttens bursdagsfest. Og hvis du var den kule gutten, skam deg. Husk at ingen er en øy. Det handler om å vinne eller svømme sammen. Vent med festen til alle kan feire sammen.
- Hvis du har nyheter å dele, så del dem. Kanskje den nye endringsprosessen som er innført nettopp reddet deg fra katastrofe – spre nyhetene! Forsterk hvordan noe fungerer. Utmerkelser, klapp på ryggen og takk tar kort tid og gir store gevinster i form av moral og entusiasme. «En unse forebygging er verdt et halvt kilo kurering», men problemet med forebygging er at folk sjelden vet om det. Kommuniser seirene!
- Hvis alle kan forstå hvordan jobben deres setter bedriftens nøkkelindikatorer (KPI-er) i fare, dvs. mål på den generelle forretningsytelsen, i stedet for å bli demoralisert, desto mer sannsynlig er det at de vil føle seg myndiggjort og ta bedre forretnings-/arbeidsbeslutninger.
- Problemer oppstår alltid. Ikke trekk forhastede konklusjoner. Ikke gå halvveis av og gjør problemet verre. Ikke legg skylden på andre, skyv ansvaret over andre og spill skyldspillet. Sørg for at prosesser er på plass. Jobb med prosessen. Vær proaktivt en del av løsningen og forbedre prosessen etter behov.
- Bli kjent med – og forstå – hverandre , både personlig og profesjonelt. Det bygger respekt, tillit og bedre arbeidsforhold. Når jeg blir kjent med noen, spesielt noen jeg jobber med (eller er på intervju for å ansette!), er mitt nye favorittspørsmål: «Hva skiller en god dag på jobb fra en dårlig dag for deg?»
Konklusjon
På vårt siste bokklubbmøte lo kollegene mine da hver av oss syntes å identifisere oss med en eller flere av karakterene, atferdstrekkene og/eller handlingene. Så reiste vi oss, børstet støvet av etterspillet og snakket om vår egen interne fremgang i arbeidet med mer struktur, bedre prosesser og å være mer åpne for endringer for å levere bedre produkter og tjenester til kundene våre.
xTuple verdsetter innovasjon og vår bedriftsomfattende sammenkobling, og vi deler ulike perspektiver – internt med ansatte og eksternt med kunder og det bredere teknologimiljøet.
Stopp galskapen og kommuniser. Skap en definert bærekraftig prosess som alle er enige om. Definisjoner er viktige. Forståelse er viktig. Fortsett å finjustere prosessen til den fungerer. Det kan gjøres.
