Tim Lister - medförfattare till böcker

• "Mänskliga faktorn. Framgångsrika projekt och team" (originalboken heter "Peopleware")
• "Waltzing with the Bears: Managing Risk in Software Projects"
• "Adrenalin-galen och zombifierad av mönster. Beteendemönster för projektteam"

Alla dessa böcker är klassiker inom sitt område och skrevs tillsammans med kollegor i Atlantic Systems Guild. I Ryssland är hans kollegor mest kända - Tom DeMarco и Peter Hruschka, som också skrev många kända verk.

Tim har 40 års erfarenhet av mjukvaruutveckling; 1975 (ingen av dem som skrev detta habrapost föddes i år), var Tim redan vice vd för Yourdon Inc. Han ägnar nu sin tid åt att konsultera, undervisa och skriva, med enstaka besök på med rapporter konferenser runt om i världen.

Vi gjorde en intervju med Tim Lister speciellt för Habr. Han kommer att öppna DevOops 2019-konferensen, och vi har många frågor, om böcker och mer. Intervjun genomförs av Mikhail Druzhinin och Oleg Chirukhin från konferensens programkommitté.

Michael: Kan du säga några ord om vad du gör nu?

Tim: Jag är chef för Atlantic Systems Guild. Vi är sex av oss i Guilden, vi kallar oss rektorer. Tre i USA och tre i Europa - det är därför Guilden kallas Atlantic. Vi har varit tillsammans i så många år att man bara inte kan räkna dem. Vi har alla våra specialiteter. Jag har arbetat med kunder under det senaste decenniet eller mer. Mina projekt omfattar inte bara ledning utan även kravställning, projektplanering och utvärdering. Det verkar som att projekt som börjar dåligt oftast slutar dåligt. Därför är det värt att se till att alla aktiviteter verkligen är genomtänkta och samordnade, att idéerna från skaparna kombineras. Det är värt att tänka på vad du gör och varför. Vilka strategier man ska använda för att få projektet att slutföras.

Jag har handlett klienter på olika sätt i många år. Ett intressant exempel är ett företag som tillverkar robotar för knä- och höftoperationer. Kirurgen opererar inte helt självständigt utan använder en robot. Säkerheten här, ärligt talat, är viktig. Men när man försöker diskutera krav med människor som är fokuserade på att lösa problem... Det kommer att låta konstigt, men i USA finns det FDA (Federal Drug Administration), som licensierar produkter som dessa robotar. Innan du säljer något och använder det på levande människor måste du skaffa en licens. Ett av villkoren är att visa dina krav, vilka testerna är, hur du testade dem, vilka testresultaten är. Om du ändrar kraven måste du gå igenom hela den här enorma testprocessen om och om igen. Våra kunder lyckades inkludera visuell design av applikationer i sina krav. De hade skärmdumpar direkt som en del av kraven. Vi måste dra ut dem och förklara att för det mesta vet alla dessa program ingenting om knän och höfter, alla dessa saker med kameran, etc. Vi behöver skriva om kravdokumenten så att de aldrig ändras, såvida inte några riktigt viktiga underliggande förutsättningar ändras. Om visuell design inte är i kraven kommer uppdateringen av produkten att gå mycket snabbare. Vårt jobb är att hitta de element som handlar om operationer i knä, höfter, rygg, dra ut dem i separata dokument och säga att dessa kommer att vara de grundläggande kraven. Låt oss ställa en isolerad grupp krav om knäoperationer. Detta kommer att göra det möjligt för oss att bygga en mer stabil uppsättning krav. Vi kommer att prata om hela produktlinjen, och inte om specifika robotar.

Mycket arbete gjordes, men de kom ändå till platser där de tidigare tillbringade veckor och månader av upprepade tester utan mening eller behov, eftersom deras krav beskrivna på papper inte överensstämde med de verkliga krav som systemen byggdes för. FDA sa till dem varje gång: dina krav har förändrats, nu måste du kontrollera allt från grunden. Kompletta omkontroller av hela produkten dödade företaget.

Så det finns så underbara uppgifter när du befinner dig i början av något intressant, och de allra första åtgärderna sätter spelets ytterligare regler. Om du ser till att denna tidiga aktivitet börjar fungera bra ur både ledningsmässig och teknisk synvinkel, finns det en chans att du kommer att få ett jättebra projekt. Men om den här delen har gått av stapeln och blivit fel någonstans, om du inte kan hitta de grundläggande överenskommelserna... nej, det är inte så att ditt projekt nödvändigtvis kommer att misslyckas. Men du kommer inte längre att kunna säga: "Vi gjorde det bra, vi gjorde allting riktigt effektivt." Det här är de saker jag gör när jag kommunicerar med kunder.

Michael: Dvs man drar igång projekt, gör någon form av kickoff och kollar att rälsen är på väg åt rätt håll?

Tim: Vi har också idéer om hur vi ska lägga alla pusselbitarna: vilka färdigheter vi behöver, när exakt de behövs, hur kärnan i laget ser ut och andra sådana grundläggande saker. Behöver vi heltidsanställda eller kan vi anställa någon på deltid? Planering, ledning. Frågor som: Vad är viktigast för just detta projekt? Hur uppnår man detta? Vad vet vi om den här produkten eller projektet, vilka är riskerna och var det okända finns, hur ska vi hantera allt detta? Naturligtvis, i det här ögonblicket börjar någon ropa "Vad sägs om smidig?!" Okej, ni är alla flexibla, men vad så? Hur ser projektet ut exakt, hur ska ni ta ut det på ett sätt som passar projektet? Du kan inte bara säga att "vårt tillvägagångssätt sträcker sig till vad som helst, vi är ett Scrum-team!" Det här är nonsens och nonsens. Vart ska du gå härnäst, varför ska det fungera, var är poängen? Jag lär mina kunder att tänka på alla dessa frågor.

19 år av smidig

Michael: I Agile försöker folk ofta att inte definiera något i förväg, utan att fatta beslut så sent som möjligt och säga: vi är för stora, jag tänker inte på den övergripande arkitekturen. Jag tänker inte på en massa andra saker, istället ska jag leverera något som fungerar till kunden just nu.

Tim: Jag tror att agila metoder, börjar med Agile manifest 2001 öppnade branschens ögon. Men å andra sidan är ingenting perfekt. Jag är helt för iterativ utveckling. Iteration är mycket vettigt i de flesta projekt. Men frågan du behöver tänka på är: när produkten väl är ute och används, hur länge håller den? Är detta en produkt som håller i sex månader innan den ersätts av något annat? Eller är detta en produkt som kommer att fungera i många, många år? Naturligtvis kommer jag inte att nämna namn, men... I New York och dess finansiella samhälle är de mest grundläggande systemen väldigt gamla. Det här är otroligt. Du tittar på dem och tänker, om du bara kunde gå tillbaka i tiden, till 1994, och berätta för utvecklarna: "Jag kom från framtiden, från 2019. Utveckla bara detta system så länge du behöver. Gör det utbyggbart, tänk på arkitekturen. Det kommer sedan att förbättras i mer än tjugofem år. Om du skjuter upp utvecklingen lite längre, i det stora hela kommer ingen att märka det!” När du ska uppskatta saker på lång sikt måste du överväga hur mycket det kommer att kosta totalt. Ibland är väldesignad arkitektur verkligen värt det, och ibland inte. Vi måste se oss omkring och fråga oss själva: är vi i rätt situation för ett sådant beslut?

Så en idé som "Vi är för agila, kunden kommer själv att berätta vad han vill få" - det är supernaivt. Kunder vet inte ens vad de vill ha, och ännu mer så att de inte vet vad de kan få. Vissa människor kommer att börja anföra historiska exempel som argument, jag har redan sett detta. Men tekniskt avancerade brukar inte säga så. De säger: "Det är 2019, det här är möjligheterna vi har, och vi kan helt förändra hur vi ser på dessa saker!" Istället för att efterlikna befintliga lösningar, göra dem lite snyggare och mer kammade, behöver du ibland gå ut och säga: "Låt oss helt och hållet återuppfinna det vi försöker göra här!"

Och jag tror inte att de flesta kunder kan tänka på problemet på det sättet. De ser bara det de redan har, det är allt. Därefter kommer de med förfrågningar som "låt oss göra det här lite enklare", eller vad de brukar säga. Men vi är inga servitörer eller servitriser, så vi kan ta en beställning hur dum den än blir och sedan baka den i köket. Vi är deras guider. Vi måste öppna deras ögon och säga: hej, vi har nya möjligheter här! Inser du att vi verkligen kan förändra hur den här delen av din verksamhet görs? Ett av problemen med Agile är att det tar bort medvetenheten om vad som är en möjlighet, vad som är ett problem, vad behöver vi ens göra, vilka tillgängliga tekniker som är bäst lämpade för just den här situationen.

Jag kanske är överdrivet skeptisk här: det händer många underbara saker i det agila samhället. Men jag har ett problem med att istället för att definiera ett projekt så börjar folk räta upp handen. Jag skulle fråga här - vad gör vi, hur ska vi göra det? Och på något magiskt sätt visar det sig alltid att klienten borde veta bättre än någon annan. Men klienten vet bäst bara när han väljer från saker som redan byggts av någon. Om jag vill köpa en bil och jag vet storleken på min familjebudget, kommer jag snabbt att välja en bil som passar min livsstil. Här vet jag allt bättre än någon annan! Men observera att någon redan har tillverkat bilarna. Jag har ingen aning om hur man uppfinner en ny bil, jag är ingen expert. När vi skapar anpassade eller specialprodukter måste kundens röst beaktas, men detta är inte längre den enda rösten.

Oleg: Du nämnde Agile Manifesto. Behöver vi på något sätt uppdatera eller revidera det med hänsyn till den moderna förståelsen av problemet?

Tim: Jag skulle inte röra honom. Jag tycker att det är ett fantastiskt historiskt dokument. Jag menar, han är vad han är. Han fyller 19 år, han är gammal, men på sin tid gjorde han revolution. Vad han gjorde bra var att han utlöste en reaktion och folk började viska om honom. Du arbetade med största sannolikhet inte ännu i branschen 2001, men då arbetade alla enligt processer. Software Engineering Institute, fem nivåer av mjukvarukompletthetsmodellen (CMMI). Jag vet inte om sådana legender från den djupa antiken säger dig något, men då var det ett genombrott. Till en början trodde man att om processerna var rätt inställda så skulle problemen försvinna av sig själva. Och så kommer Manifestet och säger: "Nej, nej, nej - vi kommer att baseras på människor, inte processer." Vi är mästare på mjukvaruutveckling. Vi förstår att den ideala processen är en hägring, den händer inte. Det finns för mycket egenart i projekt, tanken på en enda perfekt process för alla projekt är inte meningsfull. Problemen är för komplexa för att hävda att det bara finns en lösning på allt (hej, nirvana).

Jag antar inte att se in i framtiden, men jag kommer att säga att folk nu har börjat tänka mer på projekt. Jag tycker att Agile Manifesto är väldigt bra på att hoppa ut och säga, "Hej! Du är på ett fartyg, och du själv kör det här fartyget. Du måste fatta ett beslut - vi kommer inte att föreslå ett universellt recept för alla situationer. Du är besättningen på fartyget, och om du är tillräckligt bra kan du hitta en väg till målet. Det fanns andra skepp före dig, och det kommer att finnas andra skepp efter dig, men ändå, på sätt och vis, är din resa unik." Något sådant! Det är ett sätt att tänka. För mig är det inget nytt under solen, folk har seglat förut och kommer att segla igen, men för dig är detta din huvudresa, och jag kommer inte att berätta för dig exakt vad som kommer att hända dig. Du måste ha förmågan att samordna arbete i ett team, och om du verkligen har det kommer allt att lösa sig och du kommer dit du ville.

Människor: 30 år senare

Oleg: Var Peopleware en revolution likaväl som Manifestet?

Tim: Peopleware... Tom och jag skrev den här boken, men vi trodde inte att det skulle hända så här. På något sätt resonerade det med många människors idéer. Detta var den första boken som sa: mjukvaruutveckling är en mycket mänskligt intensiv aktivitet. Trots vår tekniska natur är vi också en gemenskap av människor som bygger något stort, till och med enormt, mycket komplext. Ingen kan skapa sådana saker ensam, eller hur? Så idén om "team" blev väldigt viktig. Och inte bara ur ledningssynpunkt, utan också för tekniska människor som gick samman för att lösa riktigt komplexa djupa problem med en massa okända. För mig personligen har detta varit ett enormt test av intelligens under hela min karriär. Och här måste du kunna säga: ja, det här problemet är mer än jag kan hantera på egen hand, men tillsammans kan vi hitta en elegant lösning som vi kan vara stolta över. Och jag tror att det var den här idén som fick mest resonans. Tanken att vi arbetar en del av tiden på egen hand, en del av tiden som en del av en grupp, och ofta fattas beslutet av gruppen. Gruppproblemlösning har snabbt blivit en viktig del av komplexa projekt.

Trots att Tim har hållit ett enormt antal föredrag är väldigt få av dem upplagda på YouTube. Du kan titta på rapporten "The Return of Peopleware" från 2007. Kvaliteten lämnar naturligtvis mycket övrigt att önska.

Michael: Har något förändrats under de senaste 30 åren sedan boken publicerades?

Tim: Du kan se på detta från många olika vinklar. Sociologiskt sett... en gång i tiden, i enklare tider, satt du och ditt team på samma kontor. Ni kunde vara nära varje dag, dricka kaffe tillsammans och diskutera arbete. Det som verkligen har förändrats är att team nu kan fördelas geografiskt, i olika länder och tidszoner, men ändå arbetar de med samma problem, och detta lägger till ett helt nytt lager av komplexitet. Det här kan låta gammaldags, men det finns inget som öga mot öga kommunikation där ni är alla tillsammans, arbetar tillsammans och ni kan gå fram till en kollega och säga, titta vad jag upptäckte, hur gillar ni det här? Konversationer ansikte mot ansikte ger ett snabbt sätt att övergå till informell kommunikation, och jag tror att smidiga entusiaster också borde gilla det. Och jag är också orolig för i verkligheten har världen visat sig vara väldigt liten, och nu är det hela täckt med distribuerade team, och det hela är väldigt komplext.

Vi bor alla i DevOps

Michael: Även ur konferensens programkommittés synvinkel har vi människor i Kalifornien, i New York, Europa, Ryssland... det finns ingen i Singapore än. Skillnaden i geografi är ganska stor, och folk börjar sprida sig ännu mer. Om vi ​​pratar om utveckling, kan du berätta mer om devops och att bryta ner barriärer mellan team? Det finns ett koncept att alla sitter i sina bunkrar, och nu kollapsar bunkrarna, vad tycker du om denna analogi?

Tim: Det förefaller mig att i ljuset av de senaste tekniska genombrotten är devops av stor betydelse. Tidigare hade man team av utvecklare och administratörer, de jobbade, jobbade, jobbade och någon gång dök det upp en grej som man kunde komma till admins med och rulla ut för produktion. Och här började samtalet om bunkern, för administratörerna är typ allierade, åtminstone inte fiender, men man pratade med dem först när allt var redo att gå till produktion. Gick du till dem med något och sa: titta vilken applikation vi har, men skulle du kunna rulla ut den här applikationen? Och nu har hela konceptet med leverans förändrats till det bättre. Jag menar, det fanns den här idén att du snabbt kunde driva igenom förändringar. Vi kan uppdatera produkter i farten. Jag ler alltid när Firefox på min bärbara dator dyker upp och säger, hej, vi har uppdaterat din Firefox i bakgrunden, och så fort du har en minut, skulle du vilja klicka här så ger vi dig den senaste versionen. Och jag tänkte "Åh ja, älskling!" Medan jag sov arbetade de på att leverera en ny version till mig direkt på min dator. Det här är underbart, otroligt.

Men här är svårigheten: du har den här funktionen med att uppdatera programvaran, men att integrera människor är mycket svårare. Det jag vill uttrycka på DevOops keynote är att vi nu har många fler spelare än vi någonsin haft. Om du bara tänker på alla inblandade i bara ett lag... Du tänkte på det som ett team, och det är mycket mer än bara ett team av programmerare. Det här är testare, projektledare och ett gäng andra människor. Och alla har sin egen syn på världen. Produktchefer är helt annorlunda än projektledare. Administratörer har sina egna uppgifter. Det blir ett ganska svårt problem att samordna alla deltagare för att fortsätta vara medveten om vad som händer och inte bli galen. Det är nödvändigt att separera gruppens uppgifter och uppgifter som gäller alla. Detta är en mycket svår uppgift. Å andra sidan tycker jag att det hela är mycket bättre än det var för många år sedan. Det är precis den vägen som människor växer och lär sig att bete sig på rätt sätt. När man gör integration förstår man att det inte ska ske någon underjordisk utveckling, så att mjukvaran i allra sista stund inte kryper ut som en jack-in-the-box: typ, titta vad vi gjorde här! Tanken är att du ska kunna göra integration och utveckling, och i slutet ska du rulla ut på ett snyggt och iterativt sätt. Allt detta betyder mycket för mig. Detta gör det möjligt att skapa mer värde för användarna av systemet och för din kund.

Michael: Hela idén med devops är att leverera meningsfull utveckling så tidigt som möjligt. Jag ser att världen har börjat ta fart mer och mer. Hur anpassar man sig till sådana accelerationer? För tio år sedan fanns inte detta!

Tim: Alla vill förstås ha mer och mer funktionalitet. Du behöver inte röra på dig, bara lägga på mer. Ibland måste du till och med sakta ner för nästa stegvisa uppdatering för att få med dig något användbart - och det är helt normalt.

Tanken att du behöver springa, springa, springa är inte den bästa. Det är osannolikt att någon vill leva sitt liv så. Jag skulle vilja att rytmen i leveranserna sätter projektets egen rytm. Om du bara producerar en ström av små, relativt meningslösa saker, blir allt meningslöst. Istället för att tanklöst försöka släppa saker så tidigt som möjligt, är det strategi som är värt att diskutera med de ledande utvecklarna och produkt- och projektledare. Är detta ens vettigt?

Mönster och antimönster

Oleg: Man brukar prata om mönster och antimönster, och detta är skillnaden mellan projekts liv och död. Och nu kommer devops in i våra liv. Har den några egna mönster och antimönster som kan döda projektet på plats?

Tim: Mönster och antimönster händer hela tiden. Något att prata om. Tja, det finns det här vi kallar "blanka saker". Folk gillar verkligen ny teknik. De fascineras helt enkelt av glansen av allt som ser coolt och stiligt ut, och de slutar ställa frågor: är det ens nödvändigt? Vad ska vi uppnå? Är det här tillförlitligt, är det någon mening? Jag ser ofta människor, så att säga, i framkant av tekniken. De hypnotiseras av vad som händer i världen. Men om man tittar närmare på vilka användbara saker de gör så finns det ofta helt enkelt inget användbart!

Vi diskuterade just med våra kamrater att det här året är ett jubileumsår, femtio år sedan människor landade på månen. Detta var 1969. Tekniken som hjälpte människor att ta sig dit är inte ens 1969 års teknik, utan snarare 1960 eller 62, eftersom NASA bara ville använda det som hade goda bevis på tillförlitlighet. Och så ser du på det och förstår - ja, och de var sanna! Nu, nej, nej, men man får problem med tekniken helt enkelt för att allt pressas för hårt, säljs från alla sprickor. Folk ropar från överallt: "Titta, vilken grej, det här är det nyaste, det vackraste i världen, passar absolut alla!" Tja, det är det... vanligtvis visar sig allt detta bara vara ett lockbete, och sedan måste allt slängas. Kanske beror det på att jag redan är en gammal man och ser på sådana saker med stor skepsis, när folk springer ut och säger att de har hittat det enda, mest korrekta sättet att skapa de bästa teknologierna. I detta ögonblick vaknar en röst inom mig som säger: "Vilken röra!"

Michael: Ja, hur ofta har vi hört talas om nästa silverkula?

Tim: Precis, och det här är det vanliga förloppet! Till exempel... det verkar som att detta redan har blivit ett skämt runt om i världen, men här pratar man ofta om blockchain-teknik. Och de är faktiskt vettiga i vissa situationer! När du verkligen behöver tillförlitliga bevis på händelser, att systemet fungerar och att ingen lurade oss, när du har säkerhetsproblem och allt det där blandat – blockchain är vettigt. Men när de säger att Blockchain nu kommer att svepa över världen och sopa bort allt i dess väg? Dröm mer! Detta är en mycket dyr och komplex teknik. Tekniskt komplext och tidskrävande. Inklusive rent algoritmiskt, varje gång du behöver räkna om matematiken, med de minsta förändringar... och detta är en utmärkt idé - men bara för vissa fall. Hela mitt liv och karriär har handlat om detta: intressanta idéer i mycket specifika situationer. Det är mycket viktigt att förstå exakt hur din situation är.

Michael: Ja, den huvudsakliga "frågan om livet, universum och allt": är denna teknik eller tillvägagångssätt lämplig för din situation eller inte?

Tim: Denna fråga kan redan diskuteras med teknikgruppen. Kanske till och med ta in någon konsult. Ta en titt på projektet och förstå – kommer vi nu att göra något rätt och användbart, bättre än tidigare? Kanske passar det, kanske inte. Men viktigast av allt, ta inte ett sådant beslut som standard, helt enkelt för att någon sa: "Vi behöver desperat en blockchain! Jag läste precis om honom i en tidning på planet!” Allvarligt? Det är inte ens roligt.

Den mytomspunna "devops-ingenjören"

Oleg: Nu implementerar alla devops. Någon läser om devops på Internet, och i morgon dyker ytterligare en ledig tjänst upp på en rekryteringssajt. "devops ingenjör". Här skulle jag vilja uppmärksamma er: tror du att denna term, "devops ingenjör", har rätt till liv? Det finns en åsikt att devops är en kultur, och något stämmer inte med här.

Tim: Så så. Låt dem sedan omedelbart ge en förklaring av denna term. Något som gör det unikt. Tills de bevisar att det finns någon unik kombination av kompetens bakom en ledig tjänst som denna, kommer jag inte att köpa den! Jag menar, ja, vi har en jobbtitel, "devops ingenjör", en intressant titel, ja, vad händer härnäst? Arbetstitlar är generellt sett en väldigt intressant sak. Låt oss säga "utvecklare" - vad är det egentligen? Olika organisationer betyder helt olika saker. I vissa företag skriver högkvalitativa programmerare tester som är mer vettiga än tester skrivna av speciella professionella testare i andra företag. Så vad är de nu programmerare eller testare?

Ja, vi har jobbtitlar, men om du ställer frågor tillräckligt länge visar det sig så småningom att vi alla är problemlösare. Vi är lösningssökande, och vissa har en del teknisk kompetens och en del har olika. Om du bor i en miljö där DevOps har penetrerat, är du engagerad i integrationen av utveckling och administration, och denna aktivitet har ett ganska viktigt syfte. Men om man får frågan om vad exakt man gör och vad man är ansvarig för, visar det sig att folk har gjort alla dessa saker sedan urminnes tider. "Jag är ansvarig för arkitekturen", "Jag är ansvarig för databaserna" och så vidare, vad du än ser - allt detta var innan "devops".

När någon säger till mig sin jobbtitel lyssnar jag inte så mycket. Det är bättre att låta honom berätta vad han faktiskt är ansvarig för, det gör att vi kan förstå problemet mycket bättre. Mitt favoritexempel är när en person påstår sig vara en "projektledare". Vad? Det betyder ingenting, jag vet fortfarande inte vad du gör. En projektledare kan vara en utvecklare, ledare för ett team på fyra personer, skriva kod, utföra arbete, som har blivit en teamleader, som människor själva känner igen sinsemellan som en ledare. Och dessutom kan en projektledare vara en chef som leder sexhundra personer i ett projekt, hanterar andra chefer, ansvarar för att upprätta scheman och planera budgetar, det är allt. Det är två helt olika världar! Men deras jobbtitel låter likadant.

Låt oss vända på det här lite annorlunda. Vad är du egentligen bra på, har mycket erfarenhet, har du talang för? Vad kommer du att ta ansvar för för att du tror att du klarar uppgiften? Och här kommer någon genast att börja förneka: nej, nej, nej, jag har ingen lust att ta itu med projektresurser alls, det är inte min sak, jag är en teknisk snubbe och jag förstår användbarhet och användargränssnitt, jag vet inte vill överhuvudtaget hantera arméer av människor, låt mig bättre gå till jobbet.

Och förresten, jag är en stor förespråkare för ett tillvägagångssätt där den här typen av uppdelning av kompetens fungerar bra. Där tekniker kan växa sina karriärer så långt de vill. Men jag ser fortfarande organisationer där tekniker klagar: jag måste gå in i projektledning eftersom det är det enda sättet i det här företaget. Ibland leder detta till fruktansvärda resultat. De bästa teknikerna är inte alls bra chefer, och de bästa cheferna kan inte hantera teknik. Låt oss vara ärliga om detta.

Jag ser en stor efterfrågan på detta nu. Om du är en tekniker kan ditt företag hjälpa dig, men oavsett behöver du verkligen hitta din egen karriärväg eftersom tekniken hela tiden förändras och du måste uppfinna dig själv tillsammans med den! På bara tjugo år kan tekniken förändras minst fem gånger. Teknik är en konstig sak...

"Experter på allt"

Michael: Hur kan människor hantera en sådan hastighet av tekniska förändringar? Deras komplexitet växer, deras antal växer, den totala mängden kommunikation mellan människor växer också, och det visar sig att du inte kan bli en "expert på allt".

Tim: Höger! Om du arbetar inom teknik, ja, du måste definitivt välja något specifikt och fördjupa dig i det. En del teknik som din organisation tycker är användbar (och kanske faktiskt kommer att vara användbar). Och om du inte längre är intresserad av det - jag hade aldrig trott att jag skulle säga det här - ja, du kanske borde flytta till någon annan organisation där tekniken är mer intressant eller bekvämare att studera.

Men generellt sett har du rätt. Teknikerna växer åt alla håll på en gång; ingen kan säga "Jag är en experttekniker på all teknik som finns." Å andra sidan finns det svampmänniskor som bokstavligen tar till sig teknisk kunskap och är galna i det. Jag har sett ett par sådana människor, de bokstavligen andas och lever det, det är användbart och intressant att prata med dem. De studerar inte bara vad som händer inom organisationen, utan i allmänhet pratar de om det, de är också riktigt coola teknologer, de är väldigt medvetna och målmedvetna. De försöker bara hålla sig på toppen av vågen, oavsett vad deras huvudsakliga jobb är, eftersom deras passion är teknikens rörelse, främjandet av tekniken. Om du plötsligt träffar en sådan person ska du gå på lunch med honom och diskutera olika häftiga saker under lunchen. Jag tror att varje organisation behöver åtminstone ett par sådana personer.

Risker och osäkerhet

Michael: Ärade ingenjörer, ja. Låt oss beröra riskhantering medan vi har tid. Vi inledde den här intervjun med en diskussion om medicinsk programvara, där fel kan leda till svåra konsekvenser. Sedan pratade vi om Lunar Program, där kostnaden för ett fel är miljontals dollar, och möjligen flera människoliv. Men nu ser jag den motsatta rörelsen i branschen, folk tänker inte på risker, försöker inte förutsäga dem, observerar dem inte ens.

Oleg: Rör dig snabbt och slå sönder saker!

Michael: Ja, gå snabbt, bryt saker, fler och fler saker, tills du dör av något. Ur din synvinkel, hur bör den genomsnittliga utvecklaren närma sig att lära sig riskhantering nu?

Tim: Låt oss här dra en gräns mellan två saker: risker och osäkerhet. Det här är olika saker. Osäkerhet uppstår när du inte har tillräckligt med data vid en given tidpunkt för att komma fram till ett definitivt svar. Till exempel, i ett mycket tidigt skede av ett projekt, om någon frågar dig "när kommer du att avsluta arbetet", om du är en ganska ärlig person, kommer du att säga: "Jag har ingen aning." Du vet bara inte, och det är okej. Du har ännu inte studerat problemen och är inte bekant med laget, du känner inte till deras färdigheter och så vidare. Detta är osäkerhet.

Risker uppstår när potentiella problem redan kan identifieras. Sånt här kan hända, sannolikheten är större än noll, men mindre än hundra procent, någonstans däremellan. På grund av det kan allt hända, från förseningar och onödigt arbete, men till och med till ett ödesdigert resultat för projektet. Resultatet, när ni säger - killar, låt oss fälla ihop våra paraplyer och lämna stranden, vi kommer aldrig att avsluta det, det är över, punkt. Vi gjorde antagandet att det här skulle fungera, men det fungerar inte alls, det är dags att sluta. Det här är situationerna.

Ofta är problem lättast att lösa när de redan har dykt upp, när problemet uppstår just nu. Men när ett problem är precis framför dig, gör du inte riskhantering – du löser problem, krishantering. Om du är en ledande utvecklare eller chef måste du undra vad som kan hända som skulle leda till förseningar, bortkastad tid, onödiga kostnader eller kollaps av hela projektet? Vad kommer få oss att stanna och börja om? När alla dessa saker fungerar, vad ska vi göra med dem? Det finns ett enkelt svar som är giltigt i de flesta situationer: fly inte från risker, arbeta på dem. Se hur du kan lösa en riskfylld situation, reducera den till ingenting, förvandla den från ett problem till något annat. Istället för att säga: ja, vi kommer att lösa problem när de uppstår.

Osäkerhet och risk ska stå i främsta rummet i allt du sysslar med. Du kan ta en projektplan, titta på vissa kritiska risker i förväg och säga: vi måste ta itu med det här nu, för om något av det här går fel kommer inget annat att spela någon roll. Du bör inte oroa dig för skönheten i duken på bordet om det är oklart om du kan laga middag. Först måste du identifiera alla risker med att förbereda en utsökt middag, ta itu med dem och först sedan tänka på alla andra saker som inte utgör ett verkligt hot.

Återigen, vad gör ditt projekt unikt? Låt oss se vad som kan få vårt projekt att gå av stapeln. Vad kan vi göra för att minimera sannolikheten för att detta händer? Vanligtvis kan du inte bara neutralisera dem till 100 % och deklarera med gott samvete: "Det är det, det här är inte längre ett problem, risken har löst sig!" För mig är detta ett tecken på vuxens beteende. Det här är skillnaden mellan ett barn och en vuxen - barn tror att de är odödliga, att inget kan gå fel, allt kommer att bli bra! Samtidigt tittar vuxna på hur treåriga barn hoppar på lekplatsen, följer rörelserna med blicken och säger till sig själva: "ooh-ooh, ooh-ooh." Jag står i närheten och gör mig redo att fånga när barnet faller.

Å andra sidan är anledningen till att jag gillar den här verksamheten så mycket för att den är riskabel. Vi gör saker, och de sakerna är riskfyllda. De kräver en vuxen inställning. Entusiasm ensam kommer inte att lösa dina problem!

Vuxeningenjörstänkande

Michael: Exemplet med barn är bra. Om jag är en vanlig ingenjör, då är jag glad över att vara barn. Men hur går man mot ett mer vuxet tänkande?

Tim: En av idéerna som fungerar lika bra med antingen en nybörjare eller en etablerad utvecklare är begreppet sammanhang. Vad vi gör, vad vi ska uppnå. Vad är egentligen viktigt i det här projektet? Det spelar ingen roll vem du är i det här projektet, om du är praktikant eller chefsarkitekt, alla behöver sammanhang. Vi måste få alla att tänka i större skala än sitt eget arbete. "Jag gör min pjäs, och så länge min pjäs fungerar är jag glad." Nej och åter nej. Det är alltid värt (utan att vara oförskämd!) att påminna människor om det sammanhang där de arbetar. Vad vi alla försöker uppnå tillsammans. Idéer om att du kan vara ett barn så länge allt är bra med din del av projektet - snälla, gör inte det. Om vi ​​överhuvudtaget korsar mållinjen kommer vi bara att korsa den tillsammans. Du är inte ensam, vi är alla tillsammans. Om alla personer i projektet, både gamla och unga, började prata om vad som är viktigt för projektet, varför företaget investerar pengar i det vi alla försöker uppnå... de flesta av dem kommer att må mycket bättre eftersom de kommer att se hur deras arbete korrelerar med alla andras arbete. Å ena sidan förstår jag stycket som jag personligen är ansvarig för. Men för att avsluta jobbet behöver vi alla andra människor också. Och om du verkligen tror att du är klar har vi alltid arbete att göra i projektet!

Oleg: Relativt sett, om du arbetar enligt Kanban, när du träffar flaskhalsen av vissa tester, kan du sluta med det du gjorde där (till exempel programmering) och gå och hjälpa testarna.

Tim: Exakt. Jag tror att de bästa teknikerna, om man tittar noga på dem, är de typ sina egna chefer. Hur kan jag formulera detta...

Oleg: Ditt liv är ditt projekt, som du hanterar.

Tim: Exakt! Jag menar, du tar ansvar, du förstår frågan, och du kommer i kontakt med människor när du ser att dina beslut kan påverka deras arbete, sådana saker. Det handlar inte om att bara sitta vid skrivbordet, göra sitt jobb och inte ens inse vad som händer runt omkring dig. Nej nej nej. Förresten, en av de bästa sakerna med Agile är att de föreslog korta spurter, för på så sätt kan alla deltagares tillstånd tydligt observeras, de kan se allt tillsammans. Vi pratar om varandra varje dag.

Hur man kommer in i riskhantering

Oleg: Finns det någon formell kunskapsstruktur inom detta område? Jag är till exempel Java-utvecklare och vill förstå riskhantering utan att bli en riktig projektledare av utbildning. Jag kommer förmodligen att läsa McConnells "Hur mycket kostar ett mjukvaruprojekt" först, och vad sedan? Vilka är de första stegen?

Tim: Det första är att börja kommunicera med människor i projektet. Detta ger en omedelbar förbättring av kulturen för kommunikation med kollegor. Vi måste börja med att öppna allt som standard, istället för att dölja det. Säg: det här är sakerna som stör mig, det här är sakerna som håller mig vaken på nätterna, jag vaknade på natten idag och var som: herregud, jag måste tänka på det här! Ser andra samma sak? Bör vi som grupp reagera på dessa potentiella problem? Du måste kunna stödja en diskussion om dessa ämnen. Det finns ingen förberedd formel som vi arbetar efter. Det handlar inte om att göra hamburgare, det handlar om människor. "Made a cheeseburger, sell a cheeseburger" är inte alls vår grej, och det är därför jag älskar det här jobbet så mycket. Jag gillar när allt som managers brukade göra nu blir lagets egendom.

Oleg: Du har pratat i böcker och intervjuer om hur människor oroar sig mer för lycka än om siffror på en graf. Å andra sidan, när du säger till teamet: vi flyttar till devops, och nu måste programmeraren ständigt kommunicera, detta kan vara långt utanför hans komfortzon. Och i detta ögonblick kan han, låt oss säga, vara djupt olycklig. Vad ska man göra i den här situationen?

Tim: Jag är inte säker på exakt vad jag ska göra. Om en utvecklare är för isolerad ser de inte varför arbetet utförs i första hand, de tittar bara på sin del av arbetet, och de behöver komma in i vad jag kallar "sammanhang". Han måste ta reda på hur allt hänger ihop. Och naturligtvis menar jag inte formella presentationer eller något liknande. Jag talar om att du behöver kommunicera med kollegor om arbetet som helhet, och inte bara om den del av det som du ansvarar för. Det är här ni kan börja diskutera idéer, gemensamma överenskommelser för att få ert arbete att passa ihop och hur man tillsammans kan tackla ett gemensamt problem.

För att hjälpa dem att anpassa sig vill de ofta skicka tekniker på utbildning och de diskuterar träning. En vän till mig tycker om att säga att träning är för hundar. Det finns träning för människor. En av de bästa sakerna med att lära sig som utvecklare är att interagera med dina kamrater. Om någon är riktigt bra på något bör du se dem arbeta eller prata med dem om deras arbete eller något. Någon konventionell Kent Beck pratade ständigt om extrem programmering. Det är roligt eftersom XP är en så enkel idé, men det orsakar så många problem. För vissa är att göra XP som att tvingas ta av sig naken inför vänner. De får se vad jag gör! De är mina kollegor, de kommer inte bara att se, utan också förstå! Fruktansvärd! Vissa människor börjar bli allvarligt nervösa. Men när du inser att detta är det ultimata sättet att lära dig förändras allt. Du arbetar nära människor, och vissa människor förstår ämnet mycket bättre än du.

Michael: Men allt detta tvingar dig att kliva ur din komfortzon. Som ingenjör måste du komma ur din komfortzon och kommunicera. Som problemlösare måste du hela tiden försätta dig själv i en svag position och fundera på vad som kan gå fel. Denna typ av arbete är till sin natur utformad för att vara en olägenhet. Du försätter dig medvetet i stressiga situationer. Vanligtvis flyr folk ifrån dem, folk gillar att vara glada barn.

Tim: Vad som kan göras kan du komma ut och öppet säga: ”Allt är okej, jag klarar det! Jag är inte den enda som känner mig obekväm. Låt oss diskutera olika obekväma saker, alla tillsammans, som ett team!" Det här är våra vanliga problem, vi måste ta itu med dem, vet du? Jag tror att idiosynkratiska geniutvecklare är som mammutar, de försvann. Och deras betydelse är mycket begränsad. Om du inte kan kommunicera kan du inte delta bra. Därför är det bara att prata. Var ärlig och öppen. Jag är väldigt ledsen att detta är obehagligt för någon. Kan du föreställa dig att det för många år sedan gjordes en studie enligt vilken den största rädslan i USA inte är döden, men gissa vad? Rädsla för att tala inför publik! Det betyder att det någonstans finns människor som hellre dör än att säga en komplimang högt. Och jag tror att det räcker för dig att ha några grundläggande färdigheter, beroende på vad du gör. Talförmåga, skrivförmåga - men bara så mycket som verkligen behövs i ditt arbete. Om du arbetar som analytiker, men inte kan läsa, skriva eller tala, så har du tyvärr inget att göra i mina projekt!

Priset för kommunikation

Oleg: Är det inte dyrare att anställa sådana utåtriktade medarbetare av olika anledningar? De chattar trots allt hela tiden istället för att jobba!

Tim: Jag menade kärnan i laget, och inte bara alla. Om du har någon som är riktigt cool på att ställa in databaser, älskar att ställa in databaser och kommer att fortsätta ställa in dina databaser för resten av sitt liv och det är det, coolt, fortsätt så. Men jag pratar om människor som vill bo i själva projektet. Kärnan i teamet, som syftar till att utveckla projektet. Dessa människor behöver verkligen ständigt kommunicera med varandra. Och speciellt i början av projektet, när man diskuterar risker, sätt att nå globala mål och liknande.

Michael: Detta gäller alla som är involverade i projektet, oavsett specialisering, kompetens eller arbetssätt. Ni är alla intresserade av projektets framgång.

Tim: Ja, du känner att du är tillräckligt fördjupad i projektet, att din uppgift är att hjälpa projektet att bli verklighet. Oavsett om du är programmerare, analytiker, gränssnittsdesigner, vem som helst. Det är anledningen till att jag kommer till jobbet varje morgon och det här är vad vi gör. Vi är ansvariga för alla dessa människor, oavsett deras kompetens. Det här är en grupp människor som har vuxenkonversationer.

Oleg: Faktum är att, på tal om pratglada anställda, försökte jag simulera invändningar från människor, särskilt chefer, som uppmanas att byta till devops, mot denna helt nya vision av världen. Och du som konsulter borde vara medveten om dessa invändningar mycket bättre än jag som utvecklare! Dela vad som oroar chefer mest?

Tim: Chefer? Hm. Oftast är chefer pressade av problem, inför behovet av att akut släppa något och göra en leverans och liknande. De tittar på hur vi hela tiden diskuterar och bråkar om något, och de ser det så här: samtal, samtal, samtal... Vilka andra samtal? Fortsätt jobba nu! För att prata känns inte som jobb för dem. Du skriver inte kod, testar inte programvara, verkar inte göra någonting - varför inte skicka dig att göra något? När allt kommer omkring är leverans redan om en månad!

Michael: Skriv lite kod!

Tim: Det verkar för mig att de inte är oroliga för arbetet, utan för bristen på synlighet av framstegen. För att det ska verka som om vi närmar oss framgång måste de se oss trycka på knappar på tangentbordet. Hela dagen från morgon till kväll. Detta är problem nummer ett.

Oleg: Misha, du tänker på något.

Michael: Förlåt, jag tappade tankarna och fick en flashback. Allt detta påminde mig om ett intressant rally som hände igår... Det var för många rallyn igår... Och allt låter väldigt bekant!

Livet utan löner

Tim: Förresten, det är inte alls nödvändigt att organisera "rallyn" för kommunikation. Jag menar, de mest användbara diskussionerna mellan utvecklare sker när de bara pratar med varandra. Man går in på morgonen med en kopp kaffe, och där är fem personer samlade och rasande diskuterar något tekniskt. För mig, om jag är chef för det här projektet, är det bättre att bara le och gå någonstans om mitt företag, låta dem diskutera det. De är redan involverade så mycket som möjligt. Detta är ett gott tecken.

Oleg: Förresten, i din bok har du ett gäng anteckningar om vad som är bra och vad som är dåligt. Använder du någon av dem själv? Relativt sett har du nu ett företag, och ett som är strukturerat på ett mycket oortodoxt sätt...

Tim: Oortodox, men den här enheten passar oss perfekt. Vi har känt varandra länge. Vi litar på varandra, vi litade mycket på varandra innan vi blev partners. Och till exempel har vi inga löner alls. Vi jobbar bara, och om jag till exempel tjänade pengar på mina kunder, så gick alla pengarna till mig. Därefter betalar vi medlemsavgifter till organisationen och det räcker för att stödja företaget självt. Dessutom är vi alla specialiserade på olika saker. Jag jobbar till exempel med revisorer, fyller i skattedeklarationer, gör alla möjliga administrativa saker för företaget och ingen betalar mig för det. James och Tom arbetar på vår hemsida och ingen betalar dem heller. Så länge du betalar din avgift kommer ingen att tänka på att berätta för dig vad du behöver göra. Till exempel arbetar Tom nu mycket mindre än han en gång gjorde. Nu har han andra intressen; vissa saker gör han inte för guilden. Men så länge han betalar sina avgifter kommer ingen att komma fram till honom och säga: "Hej, Tom, gå till jobbet!" Det är väldigt lätt att ha att göra med kollegor när det inte finns några pengar mellan er. Och nu är vår relation en av grundidéerna i förhållande till olika specialiteter. Det fungerar och det fungerar väldigt bra.

Bästa råd

Michael: För att återgå till "bästa råd", är det något du berättar för dina kunder om och om igen? Det finns en idé om 80/20, och vissa råd upprepas förmodligen oftare.

Tim: Jag trodde en gång att om man skrev en bok som Waltzing with Bears skulle det förändra historiens gång och folk skulle sluta, men... Ja, se, företag låtsas ofta att allt är bra med dem. Så fort något dåligt händer är det en chock och en överraskning för dem. "Titta, vi testade systemet, och det klarar inga systemtester, och det här är ytterligare tre månader av oplanerat arbete, hur kunde detta hända? Vem visste? Vad kan gå fel? Seriöst, tror du på detta?

Jag försöker förklara att du inte ska bli för arg över den nuvarande situationen. Vi måste prata ut det, verkligen förstå vad som kunde ha gått fel och hur vi kan förhindra att sådana saker händer i framtiden. Om ett problem uppstår, hur ska vi bekämpa det, hur ska vi begränsa det?

För mig ser allt detta skrämmande ut. Människor hanterar komplexa, irriterande problem och fortsätter att låtsas att om de bara håller tummarna och hoppas på det bästa så kommer det "bästa" att hända. Nej, det fungerar inte så.

Öva riskhantering!

Michael: Hur många organisationer ägnar du sig åt riskhantering enligt din åsikt?

Tim: Det som gör mig upprörd är att folk helt enkelt skriver ner risker, tittar på listan och går till jobbet. Att identifiera risker för dem är faktiskt riskhantering. Men för mig låter detta som en anledning att fråga: okej, det finns en lista, vad exakt kommer du att ändra? Du måste ändra dina standardsekvenser av åtgärder med hänsyn till dessa risker. Om det finns någon svårare del av arbetet måste du ta itu med det och först då gå vidare till något enklare. I de första spurterna, börja lösa komplexa problem. Detta ser redan ut som riskhantering. Men vanligtvis kan folk inte säga vad de ändrade efter att ha sammanställt en lista över risker.

Michael: Och ändå, hur många av dessa företag är involverade i riskhantering, fem procent?

Tim: Tyvärr hatar jag att säga detta, men det här är en mycket obetydlig del. Men mer än fem, eftersom det finns riktigt stora projekt, och de kan helt enkelt inte existera om de inte gör åtminstone något. Låt oss bara säga att jag blir väldigt förvånad om det är minst 25%. Små projekt brukar svara på sådana frågor så här: om problemet påverkar oss, då löser vi det. Sedan hamnar de framgångsrikt i problem och ägnar sig åt problemhantering och krishantering. När du försöker lösa ett problem och problemet inte är löst, välkommen till krishantering.

Ja, jag hör ofta, "vi kommer att lösa problem när de uppstår." Visst kommer vi att göra det? Kommer vi verkligen att bestämma oss?

Oleg: Du kan göra det naivt och helt enkelt skriva in viktiga invarianter i projektstadgan, och om invarianterna går sönder är det bara att starta om projektet. Det visar sig mycket piembucky.

Michael: Ja, det hände mig att när risker utlöstes så omdefinierades projektet helt enkelt. Trevligt, bingo, problemet löst, oroa dig inte längre!

Tim: Låt oss trycka på återställningsknappen! Nej, det fungerar inte så.

Keynote på DevOops 2019

Michael: Vi kommer till den sista frågan i denna intervju. Du kommer till nästa DevOops med en keynote, kan du lyfta på hemlighetsgardinen för vad du ska berätta?

Tim: Just nu skriver sex av dem på en bok om arbetskultur, organisationers outtalade regler. Kultur bestäms av organisationens kärnvärden. Oftast märker inte folk detta, men efter att ha jobbat med konsult i många år är vi vana att märka det. Du kommer in i ett företag, och bokstavligen inom några minuter börjar du känna vad som händer. Vi kallar detta "smak". Ibland är den här doften riktigt bra, och ibland är den, ja, oj. Saker och ting är väldigt olika för olika organisationer.

Michael: Jag har också jobbat med konsultverksamhet i flera år och förstår väl vad du pratar om.

Tim: Egentligen är en av de saker som är värda att prata om vid keynoten att allt inte bestäms av företaget. Du och ditt team, som en gemenskap, har din egen lagkultur. Detta kan vara hela företaget, eller en separat avdelning, ett separat team. Men innan du sa, här är vad vi tror, ​​här är vad som är viktigt... Du kan inte förändra en kultur innan värderingarna och övertygelserna bakom specifika handlingar har förståtts. Beteende är lätt att observera, men att söka efter övertygelser är svårt. DevOps är bara ett bra exempel på hur saker och ting blir mer och mer komplexa. Interaktioner blir bara mer komplexa, de blir inte alls renare eller tydligare, så du bör tänka på vad du tror på och vad alla omkring dig är tysta om.

Om du vill uppnå snabba resultat, här är ett bra ämne för dig: har du sett företag där ingen säger "jag vet inte"? Det finns platser där du bokstavligen torterar en person tills han erkänner att han inte vet något. Alla vet allt, alla är otroligt lärda. Du närmar dig vilken person som helst och han måste omedelbart svara på frågan. Istället för att säga "Jag vet inte." Hurra, de anställde ett gäng lärda! Och i vissa kulturer är det i allmänhet mycket farligt att säga "jag vet inte", det kan uppfattas som ett tecken på svaghet. Det finns också organisationer där, tvärtom, alla kan säga "jag vet inte." Där är det helt lagligt, och om någon börjar skräpa som svar på en fråga är det helt normalt att svara: "Du vet inte vad du pratar om, eller hur?" och förvandla det hela till ett skämt.

Helst skulle du vilja ha ett jobb där du kan vara ständigt lycklig. Det kommer inte att bli lätt, inte varje dag är solig och trevlig, ibland måste man jobba hårt, men när man börjar göra inventering kommer det att visa sig: wow, det här är en riktigt underbar plats, jag mår bra av att jobba här, både känslomässigt och intellektuellt. Och det finns företag dit du går som konsult och omedelbart inser att du inte kunde stå ut i tre månader och skulle fly i fasa. Det är detta jag vill prata om i rapporten.

Tim Lister kommer med en keynote "Karaktärer, gemenskap och kultur: Viktiga faktorer för välstånd"till DevOops 2019-konferensen, som äger rum den 29-30 oktober 2019 i St. Petersburg. Du kan köpa biljetter på den officiella webbplatsen. Vi väntar på dig på DevOops!

Källa: will.com