Sådan bliver du en god teknologechef.

Gode ​​ledere placerer bare gode systemer for folk at følge.

Billedkreditter: Pexels.com

Fra begyndelsen har jeg indset, at jeg kommer hjem næsten hver dag (hvilket ofte er den næste dag) og gør følgende:

· Sig noget i retning af "Phew, en anden fanden dag."

· Grib en dåse kølet øl (mærke betyder ikke noget, jo mere kølet, jo bedre).

· Tilbage til arbjedet.

Og dette har fortsat som urværk de sidste 12 plus år, gennem mine rejser som teknologechef.

Ledelsesguru Henry Mintzberg observerede en gang med rette,

”Den store myte er manageren som orkesterdirigent. Det er denne idé om at stå på en piedestal, og du vinker din stafettpude og regnskab kommer ind, og du vinker den et andet sted og markedsfører klokkeslæt med regnskab, og de lyder alle meget strålende. ”

Med enkle ord vil livet aldrig blive, som du tror, ​​det vil gøre. Hvad som helst; processer, mennesker, tekniske fejl vil altid have evnen til at forvandle dit liv til et levende mareridt.

Derfor er det vigtigste, du kan gøre som manager, at fortsætte med at lære og improvisere hver eneste dag.

Og den gode nyhed er, at jeg under min rejse var heldig nok til at samle nogle uvurderlige klumper af visdom, som hjalp mig med at udvikle mig til en bedre, mere praktisk teknologechef.

Og her er nogle af de perler, der er et must i enhver teknologileders arsenal.

Opret en gentagelig, pålidelig og elastisk proces til frigivelse af software.

Jerry Moran spikede det, da han sagde.

”Perfektion har at gøre med slutproduktet, men ekspertise har at gøre med processen.”

På mange måder er software og katedraler stort set de samme - først bygger vi dem, så beder vi.

Men skal det altid være sådan?

Effektiv software bør aldrig være afhængig af det lune og fancy hos den ene ”whiz kid” -udvikler, du har. I stedet skal det være kulminationen på en velsmurt proces, der kan gentages, pålidelig og modstandsdygtig over for enhver ændring overhovedet.

I sidste ende skal frigivelse af software være børns leg. Det skal være let, fordi du har testet hver eneste del af frigørelsesprocessen hundreder af gange. Det skal være så let som at trykke på en knap. Denne finesse kan kun komme ved at håndhæve en proces på plads, som religiøst følges af hver eneste person i teamet.

Som manager er dit job ikke et "vagthund", der overvåger udviklerne rasende. Dit job ligner mere en "hyrde", der sikrer, at alle "får" (læs software, hardware og mennesker) er tilpasset en proces, der sikrer, at kunden får maksimal forretningsværdi gennem din ansøgning.

Automatiser alt muligt

Eliyahu Goldratt sagde engang.

”Automation er god, så længe du ved nøjagtigt, hvor du skal placere maskinen.”

Mennesker er tilbøjelige til fejl. Det er en kendsgerning om livet. På den anden side er der en masse ting, en maskine ikke kan gøre. Nøglen er at finde den rigtige balance.

Der er nogle ting, som er umulige at automatisere. Undersøgelsestest afhænger af erfarne testere. Tilsvarende kræver demonstrationer af arbejdssoftware til brugerfællesskab menneskelig indgriben og godkendelse.

Men når det er sagt, er listen over ting, der ikke kan automatiseres, meget mindre, end folk tror. Acceptantest kan automatiseres. Databaseopgraderinger kan automatiseres. Selv netværks- og firewall-konfigurationer kan automatiseres. Nøglen er at automatisere så meget som muligt.

Det punkt, der skal bemærkes her, er, at den første regel for enhver teknologi, der anvendes i en virksomhed, er, at automatisering, der anvendes til en effektiv operation, vil forstærke effektiviteten.

Det andet er, at automatisering, der anvendes til en ineffektiv operation, vil forstørre ineffektiviteten. Så automatiser ikke ineffektive processer. Det besejrer selve formålet.

Hold alt i versionskontrol

Dexter Palmer ramte det smell på neglen, da han observerede.

”Tinget om erindringer var ikke, at mange af dem uundgåeligt falmede, men den gentagne gentagelse af dem, du huskede, brændte dem ind i skinnende, smukke løgner.”

Og disse "skinnende, smukke løgne" er den virkelige årsag til de fleste af hjertets forbrændinger, konflikter og skyldspil, vi møder i vores projekt, når ting ikke kan bevises med sikkerhed.

Alt hvad du har brug for at bygge, implementere, teste og frigive skal holdes under en form for versionlagring. Dette inkluderer kravdokumenter, test scripts, test cases, biblioteker, værktøjskæder og så videre.

Alle disse ting skal være versionskontrolleret og skal kunne identificeres i forhold til enhver given build. Overlad det ikke til menneskelige erindringer. Minderne er notorisk dårlige, selv til det bedste for mennesker.

Versionsstyrede artefakter giver dig ikke kun bedre kontrol, men giver dig også en fantastisk backup-mulighed for at "vende tilbage", hvis ting går galt. Det giver også en god guide til selvhjælp til enhver ny person, der tilslutter sig teamet.

Udfør den hårdeste aktivitet ofte.

Jeff Humble har med rette sagt.

”Hvis det gør ondt, skal du gøre det oftere og bringe smerten frem”

Måske kan denne ovenstående udsagn ikke undervurderes og er et af de vigtigste principper for succesfuld softwarelevering.

Hvis integration er en smertefuld fase af dit projekt, skal du gøre det oftere i små bits og lindre smerten. Hvis test er et smertefuldt trin i dit projekt, skal du ikke gøre det i slutningen; i stedet skal du gøre det kontinuerligt lige fra dag 1 af dit projekt.

Hvis applikationsdokumentation er noget, der "hates" i hele dit projekt, skal du gøre det, så snart en ny funktion er integreret i dit projekt. Opret dokumentation som en integreret del til "afslutning" på funktionen.

Hele denne tilgang kræver disciplin og en seriøs indsats for at opnå effektivitet. Gradvist arbejde for at nærme sig idealet; selv små trin vil give store fordele og fungere som en katalysator i retning af det endelige mål om at ”afslutte” smerten for altid.

Kvalitet er alt

Steve Jobs observerede med rette, da han sagde.

”Vær en målestok for kvalitet. Nogle mennesker er ikke vant til et miljø, hvor ekspertise forventes. ”

Der er ikke noget, der kaldes "kvalitetsfase" i dit projekt. Kvalitet kan aldrig være en ulykke. Det er altid resultatet af intelligent indsats og fanatisk proaktivitet. Det er alles ansvar.

“Build Quality in”, det berømte motto, der gives af Edward Deming, bør være det styrende princip for hver eneste person, der arbejder i projektet. Jo tidligere du fanger defekter, jo billigere er de at rette op, og jo mindre er muligheden for, at de kan ende på kundens bord.

I det tidligere punkt talte jeg om ”at bringe smerten frem”. Det næste trin er at fikse smerten straks, så snart du ser den.

Som manager er det dit primære ansvar at indprente den ikke-omsættelige kultur inden for teamet med ”rettelse af mangler”, så snart de findes. Som Henry Ford med rette har sagt.

”Kvalitet betyder at gøre det rigtigt, når ingen kigger efter.”

Alle er ansvarlige for det endelige resultat.

Audrey Hepburn gør et godt punkt, når hun siger.

”Jeg tror ikke på kollektiv skyld, men tror på kollektivt ansvar.”

”Enhedstestingen blev ikke udført korrekt. Udvikleren goofed op. Hvad kan jeg gøre?

”Testeren fangede ikke dette scenarie. Ikke mit problem"

”Virksomheden skulle have identificeret dette scenario, før de loggede ud. Nu skal de leve med det ”

Lyder velkendt?

Alle vil spise kagen, men ingen ønsker at rense rodet efter at have spist. Hvis dit projekt har sådanne holdninger, er det en opskrift på katastrofe, også før det er afsluttet.

I en ideel verden skal alle i en organisation tilpasses dens mål, og folk arbejder sammen og hjælper hinanden med at opfylde dem. Virkeligheden er dog yderst bitter.

Så mange projekter har tilfælde, hvor udviklere kaster deres arbejde over væggen til testerne. Testerne kaster arbejde over væggen til operationer og så videre.

Og når noget går galt, bruger folk lige så meget tid på at beskylde hinanden, som de reparerer de mangler, der uundgåeligt skyldes en sådan dæmpet tilgang.

Det er lederens ansvar at sikre, at alle er involverede lige fra projektets start. Opret stærke kommunikationskanaler og opmuntre til diskussioner inden for teams.

Når barrierer er nede, vil kommunikationen ske kontinuerligt, men det er en inkrementel proces, der tager tid at etablere og være effektiv i sidste ende.

Bringer det hele sammen

Så som du kan se, er gode teknologiledere nødt til at jonglere med et utal af opgaver, teams og prioriteter.

De skal være effektive kommunikatorer og teknisk dygtige, så de kan interagere med udviklingsholdet og også tale tydeligt med kunder og interessenter. De skal være tænkere i store billeder, alt sammen mens kundens forventninger afbalanceres med forretningsbehov og budget.

Og sidst, men ikke mindst, er de nødt til at være tilpasningsdygtige; Alt er i konstant forandring; markedet, teknologi, kundepræferencer. Hvis du ikke følger med, får du ikke succes i længe.

Som Denis Waitley med rette har opsummeret.

”Forvent det bedste, planlæg det værste og forbered dig på at blive overrasket.”
Om forfatteren-:
Ravi Rajan er en global it-programleder baseret fra Mumbai, Indien. Han er også en ivrig blogger, Haiku poesi skribent, arkæolog entusiast og historie gal. Opret forbindelse med Ravi på LinkedIn, Medium og Twitter.

Denne historie er offentliggjort i The Startup, Medium's største iværksætterpublikation efterfulgt af +439.678 personer.

Abonner for at modtage vores tophistorier her.