Tim Lister - co-auteur van boeken
- "Menselijke factor. Succesvolle projecten en teams" (het originele boek heet "Peopleware")
- "Walzen met de beren: risico's beheren in softwareprojecten"
- “Adrenaline-gek en zombified door patronen. Gedragspatronen van projectteams"
Al deze boeken zijn klassiekers in hun vakgebied en zijn samen met collega’s geschreven . In Rusland zijn zijn collega's het meest bekend: и , die ook veel beroemde werken schreef.
Tim heeft 40 jaar ervaring in softwareontwikkeling; in 1975 (niemand van degenen die deze habrapost hebben geschreven is dit jaar geboren) was Tim al uitvoerend vice-president van Yourdon Inc. Hij besteedt nu zijn tijd aan advies, lesgeven en schrijven, met af en toe een bezoek aan conferenties over de hele wereld.
Speciaal voor Habr hebben we een interview gedaan met Tim Lister. Hij opent de DevOops 2019-conferentie en we hebben veel vragen, over boeken en meer. Het interview wordt afgenomen door Mikhail Druzhinin en Oleg Chirukhin van de programmacommissie van de conferentie.
Michaël: Kun je iets zeggen over wat je nu doet?
Tim: Ik ben het hoofd van de Atlantic Systems Guild. We zijn met z'n zessen in het Gilde, we noemen onszelf opdrachtgevers. Drie in de VS en drie in Europa - daarom heet de Guild Atlantic. We zijn al zoveel jaren samen dat je ze gewoon niet kunt tellen. We hebben allemaal onze specialiteiten. Ik heb de afgelopen tien jaar of langer met klanten gewerkt. Mijn projecten omvatten niet alleen management, maar ook het stellen van eisen, projectplanning en evaluatie. Het lijkt erop dat projecten die slecht beginnen meestal slecht eindigen. Daarom is het de moeite waard om ervoor te zorgen dat alle activiteiten echt goed doordacht en gecoördineerd zijn, dat de ideeën van de makers worden gecombineerd. Het is de moeite waard om na te denken over wat je doet en waarom. Welke strategieën u moet gebruiken om het project tot een goed einde te brengen.
Ik begeleid al jaren cliënten op verschillende manieren. Een interessant voorbeeld is een bedrijf dat robots maakt voor knie- en heupoperaties. De chirurg opereert niet geheel zelfstandig, maar maakt gebruik van een robot. Veiligheid is hier eerlijk gezegd belangrijk. Maar als je eisen probeert te bespreken met mensen die gefocust zijn op het oplossen van problemen... Het zal vreemd klinken, maar in de VS is er (Federal Drug Administration), die licenties verleent voor producten zoals deze robots. Voordat je iets verkoopt en het op levende mensen gebruikt, moet je een licentie verkrijgen. Eén van de voorwaarden is dat u kunt laten zien wat uw wensen zijn, wat de tests zijn, hoe u ze heeft getest, wat de testresultaten zijn. Als je de vereisten verandert, moet je dit hele enorme testproces keer op keer doorlopen. Onze klanten zijn erin geslaagd om het visuele ontwerp van applicaties in hun eisen op te nemen. Ze hadden screenshots rechtstreeks als onderdeel van de vereisten. We moeten ze eruit halen en uitleggen dat al deze programma's voor het grootste deel niets weten over knieën en heupen, al deze dingen met de camera, enz. We moeten de vereistendocumenten herschrijven, zodat ze nooit veranderen, tenzij een aantal echt belangrijke onderliggende omstandigheden veranderen. Als visueel ontwerp niet aan de eisen voldoet, zal het updaten van het product veel sneller gaan. Het is onze taak om die elementen te vinden die te maken hebben met operaties aan de knie, heupen en rug, deze in afzonderlijke documenten op te nemen en te zeggen dat dit de fundamentele vereisten zullen zijn. Laten we een geïsoleerde groep eisen stellen over knieoperaties. Hierdoor kunnen we een stabieler eisenpakket opbouwen. We zullen het hebben over de hele productlijn, en niet over specifieke robots.
Er werd veel werk verzet, maar ze kwamen nog steeds op plaatsen waar ze voorheen weken en maanden aan herhaalde tests doorbrachten zonder betekenis of noodzaak, omdat hun op papier beschreven eisen niet samenvielen met de werkelijke eisen waarvoor de systemen waren gebouwd. De FDA vertelde hen elke keer: uw eisen zijn veranderd, nu moet u alles helemaal opnieuw controleren. Volledige hercontroles van het hele product waren de dood van de onderneming.
Er zijn dus zulke prachtige taken als je aan het begin van iets interessants staat, en de allereerste acties bepalen de verdere regels van het spel. Als je ervoor zorgt dat deze vroege activiteit zowel vanuit bestuurlijk als technisch oogpunt goed begint te werken, bestaat de kans dat je met een geweldig project eindigt. Maar als dit onderdeel ontspoord is en ergens fout is gegaan, als je de fundamentele overeenkomsten niet kunt vinden... nee, het is niet zo dat je project noodzakelijkerwijs zal mislukken. Maar je kunt niet meer zeggen: “We hebben het geweldig gedaan, we hebben alles heel effectief gedaan.” Dit zijn de dingen die ik doe als ik met klanten communiceer.
Michaël: Dat wil zeggen: je lanceert projecten, doet een soort aftrap en controleert of de rails de goede kant op gaan?
Tim: We hebben ook ideeën over hoe we alle stukjes van de puzzel in elkaar kunnen zetten: welke vaardigheden we nodig hebben, wanneer ze precies nodig zijn, hoe de kern van het team eruit ziet en andere soortgelijke fundamentele zaken. Hebben we fulltime medewerkers nodig of kunnen we iemand parttime inhuren? Planning, beheer. Vragen als: Wat is het belangrijkste voor dit specifieke project? Hoe dit te bereiken? Wat weten we over dit product of project, wat zijn de risico’s en waar zitten de onbekenden, hoe gaan we hiermee om? Natuurlijk begint er op dit moment iemand te roepen: “Hoe zit het met agile?!” Oké, jullie zijn allemaal flexibel, maar wat dan nog? Hoe ziet het project er precies uit, hoe ga je het uitwerken op een manier die bij het project past? Je kunt niet zomaar zeggen: “onze aanpak strekt zich uit tot alles, we zijn een Scrum-team!” Dit is onzin en onzin. Waar ga je nu heen, waarom zou het werken, waar is het punt? Ik leer mijn cliënten over al deze vragen na te denken.
19 jaar behendig
Michaël: Bij Agile proberen mensen vaak niets vooraf te definiëren, maar zo laat mogelijk beslissingen te nemen, waarbij ze zeggen: we zijn te groot, ik zal niet nadenken over de algehele architectuur. Ik zal niet aan een heleboel andere dingen denken; in plaats daarvan lever ik iets dat op dit moment aan de klant werkt.
Tim: Ik denk dat agile methodieken, te beginnen met in 2001, opende de ogen van de industrie. Maar aan de andere kant is niets perfect. Ik ben helemaal voor iteratieve ontwikkeling. Iteratie is in de meeste projecten zinvol. Maar de vraag waar u over moet nadenken is: als het product eenmaal op de markt is en in gebruik is, hoe lang gaat het dan mee? Is dit een product dat zes maanden meegaat voordat het door iets anders wordt vervangen? Of is dit een product dat vele, vele jaren zal werken? Natuurlijk zal ik geen namen noemen, maar... In New York en zijn financiële gemeenschap zijn de meest fundamentele systemen erg oud. Dit is geweldig. Je kijkt ernaar en denkt: als je maar terug in de tijd kon gaan, naar 1994, en tegen de ontwikkelaars zei: “Ik kwam uit de toekomst, uit 2019. Ontwikkel dit systeem gewoon zo lang als u nodig heeft. Maak het uitbreidbaar, denk na over de architectuur. Vervolgens wordt het gedurende ruim vijfentwintig jaar verbeterd. Als je de ontwikkeling nog wat langer uitstelt, zal in het grote geheel niemand het merken!” Wanneer u zaken op de lange termijn inschat, moet u overwegen hoeveel het in totaal gaat kosten. Soms is goed ontworpen architectuur echt de moeite waard, en soms ook niet. We moeten om ons heen kijken en ons afvragen: bevinden we ons in de juiste situatie voor een dergelijke beslissing?
Dus een idee als “Wij zijn voor agile, de klant zal ons zelf vertellen wat hij wil krijgen” is super naïef. Klanten weten niet eens wat ze willen, en nog meer, ze weten niet wat ze kunnen krijgen. Sommige mensen zullen historische voorbeelden als argumenten gaan aanhalen, ik heb dit al gezien. Maar technisch geavanceerde mensen zeggen dat meestal niet. Ze zeggen: “Het is 2019, dit zijn de kansen die we hebben, en we kunnen de manier waarop we naar deze dingen kijken volledig veranderen!” In plaats van bestaande oplossingen na te bootsen, ze een beetje mooier en meer uitgekamd te maken, moet je soms naar buiten treden en zeggen: "Laten we volledig opnieuw uitvinden wat we hier proberen te doen!"
En ik denk niet dat de meeste klanten op die manier over het probleem kunnen nadenken. Ze zien alleen wat ze al hebben, dat is alles. Waarna ze komen met verzoeken als “laten we dit een beetje eenvoudiger maken”, of wat ze gewoonlijk zeggen. Maar wij zijn geen obers of serveersters, dus we kunnen een bestelling, hoe dom deze ook blijkt, opnemen en deze vervolgens in de keuken bakken. Wij zijn hun gidsen. We moeten hun ogen openen en zeggen: hé, we hebben hier nieuwe kansen! Realiseert u zich dat we de manier waarop dit deel van uw bedrijf wordt gedaan echt kunnen veranderen? Een van de problemen met Agile is dat het het bewustzijn wegneemt van wat een kans is, wat een probleem is, wat we überhaupt moeten doen, welke beschikbare technologieën het meest geschikt zijn voor deze specifieke situatie.
Misschien ben ik hier te sceptisch: er gebeuren veel prachtige dingen in de agile gemeenschap. Maar ik heb een probleem met het feit dat mensen, in plaats van een project te definiëren, hun handen in de lucht steken. Ik zou hier willen vragen: wat zijn we aan het doen, hoe gaan we het doen? En op de een of andere manier blijkt op magische wijze altijd dat de cliënt het beter zou moeten weten dan wie dan ook. Maar de klant weet het het beste als hij kiest uit dingen die al door iemand zijn gebouwd. Als ik een auto wil kopen en ik weet hoe groot mijn gezinsbudget is, dan kies ik snel een auto die bij mijn levensstijl past. Hier weet ik alles beter dan wie dan ook! Maar houd er rekening mee dat iemand de auto's al heeft gemaakt. Ik heb geen idee hoe ik een nieuwe auto moet uitvinden, ik ben geen expert. Wanneer we op maat gemaakte of speciale producten maken, moet rekening worden gehouden met de stem van de klant, maar dit is niet langer de enige stem.
Oleg: U noemde het Agile Manifesto. Moeten we het op de een of andere manier bijwerken of herzien, rekening houdend met het moderne begrip van de kwestie?
Tim: Ik zou hem niet aanraken. Ik vind het een geweldig historisch document. Ik bedoel, hij is wat hij is. Hij wordt 19 jaar oud, hij is oud, maar in zijn tijd heeft hij een revolutie teweeggebracht. Wat hij goed deed, was dat hij een reactie teweegbracht en dat mensen over hem begonnen te fluisteren. Hoogstwaarschijnlijk werkte je in 2001 nog niet in de branche, maar toen werkte iedereen volgens processen. Software Engineering Institute, vijf niveaus van het softwarevolledigheidsmodel (CMMI). Ik weet niet of zulke legendes uit de verre oudheid je iets vertellen, maar het was een doorbraak. Aanvankelijk geloofden mensen dat als de processen correct waren ingericht, de problemen vanzelf zouden verdwijnen. En dan komt het Manifest langs en zegt: “Nee, nee, nee – we zullen gebaseerd zijn op mensen, niet op processen.” Wij zijn meesters in softwareontwikkeling. Wij begrijpen dat het ideale proces een luchtspiegeling is; het gebeurt niet. Er zit te veel eigenzinnigheid in projecten, het idee van één perfect proces voor alle projecten slaat nergens op. De problemen zijn te complex om te beweren dat er maar één oplossing voor alles is (hallo, nirvana).
Ik heb niet de pretentie in de toekomst te kijken, maar ik wil wel zeggen dat mensen nu meer over projecten zijn gaan nadenken. Ik denk dat het Agile Manifesto er heel goed uit springt en zegt: “Hé! U bevindt zich op een schip en u bestuurt dit schip zelf. U zult een beslissing moeten nemen - we zullen niet voor alle situaties een universeel recept voorstellen. Jij bent de bemanning van het schip en als je goed genoeg bent, kun je een weg naar het doel vinden. Er waren andere schepen voor je, en er zullen nog meer schepen na je zijn, maar toch is je reis in zekere zin uniek. Zoiets! Het is een manier van denken. Voor mij is er niets nieuws onder de zon, mensen hebben al eerder gevaren en zullen weer zeilen, maar voor jou is dit je belangrijkste reis, en ik zal je niet vertellen wat er precies met je gaat gebeuren. Je moet over de vaardigheden beschikken om in teamverband te werken, en als je die echt hebt, komt alles goed en kom je waar je wilde.
Peopleware: 30 jaar later
Oleg: Was Peopleware zowel een revolutie als het Manifest?
Tim: Peopleware... Tom en ik hebben dit boek geschreven, maar we hadden niet verwacht dat het zo zou gebeuren. Op de een of andere manier resoneerde het met de ideeën van veel mensen. Dit was het eerste boek dat zei: softwareontwikkeling is een zeer mensintensieve activiteit. Ondanks onze technische aard zijn we ook een gemeenschap van mensen die aan iets groots, zelfs enorms, heel complex bouwen. Niemand kan zulke dingen alleen creëren, toch? Het idee van "team" werd dus erg belangrijk. En niet alleen vanuit managementoogpunt, maar ook voor technische mensen die samenkwamen om echt complexe, diepgaande problemen op te lossen met een heleboel onbekende factoren. Voor mij persoonlijk is dit gedurende mijn hele carrière een enorme intelligentietest geweest. En hier moet je kunnen zeggen: ja, dit probleem is groter dan ik alleen aankan, maar samen kunnen we een elegante oplossing vinden waar we trots op kunnen zijn. En ik denk dat dit idee het meeste weerklank vond. Het idee dat we een deel van de tijd alleen werken, een deel van de tijd als onderdeel van een groep, en vaak wordt de beslissing door de groep genomen. Het oplossen van groepsproblemen is snel een belangrijk kenmerk van complexe projecten geworden.
Ondanks het feit dat Tim een groot aantal lezingen heeft gegeven, worden er maar heel weinig op YouTube geplaatst. Kijk maar eens naar het rapport ‘The Return of Peopleware’ uit 2007. De kwaliteit laat uiteraard veel te wensen over.
Michaël: Is er iets veranderd in de afgelopen dertig jaar sinds de publicatie van het boek?
Tim: Je kunt dit vanuit veel verschillende invalshoeken bekijken. Sociologisch gezien... Er was eens, in eenvoudiger tijden, jij en je team in hetzelfde kantoor. Je kunt elke dag dichtbij zijn, samen koffie drinken en het werk bespreken. Wat echt veranderd is, is dat teams nu geografisch verspreid kunnen zijn, in verschillende landen en tijdzones, maar nog steeds aan hetzelfde probleem werken, en dit voegt een geheel nieuwe laag van complexiteit toe. Dit klinkt misschien ouderwets, maar er gaat niets boven face-to-face communicatie waarbij je allemaal samen bent, samenwerkt, en je naar een collega kunt lopen en zeggen: kijk eens wat ik heb ontdekt, hoe vind je dit? Persoonlijke gesprekken bieden een snelle manier om over te stappen naar informele communicatie, en ik denk dat agile-enthousiastelingen dit ook leuk zouden moeten vinden. En ik maak me ook zorgen omdat de wereld in werkelijkheid heel klein is gebleken, en nu allemaal bedekt is met gedistribueerde teams, en het allemaal erg complex is.
We leven allemaal in DevOps
Michaël: Zelfs vanuit het standpunt van de programmacommissie van de conferentie hebben we mensen in Californië, in New York, Europa, Rusland... er is nog niemand in Singapore. Het verschil in geografie is behoorlijk groot, en mensen beginnen zich nog verder te verspreiden. Als we het over ontwikkeling hebben, kun je ons dan meer vertellen over devops en het slechten van barrières tussen teams? Er is een concept dat iedereen in zijn bunkers zit, en nu de bunkers instorten. Wat vind jij van deze analogie?
Tim: Het lijkt mij dat in het licht van de recente technologische doorbraken devops van groot belang is. Vroeger had je teams van ontwikkelaars en beheerders, ze werkten, werkten, werkten, en op een gegeven moment verscheen er iets waarmee je naar de beheerders kon komen en het voor productie kon uitrollen. En hier begon het gesprek over de bunker, omdat de beheerders een soort bondgenoten zijn, tenminste geen vijanden, maar je sprak pas met ze toen alles klaar was om naar productie te gaan. Ben je met iets naar ze toe gegaan en heb je gezegd: kijk eens wat voor een applicatie wij hebben, maar kun jij deze applicatie ook uitrollen? En nu is het hele concept van bezorging ten goede veranderd. Ik bedoel, er was het idee dat je veranderingen snel kon doorvoeren. We kunnen producten direct updaten. Ik glimlach altijd als Firefox op mijn laptop verschijnt en zegt: 'Hé, we hebben je Firefox op de achtergrond bijgewerkt, en zodra je even de tijd hebt, zou je hier willen klikken, dan geven we je de nieuwste release. En ik dacht: "Oh ja, schat!" Terwijl ik sliep, waren ze bezig om mij een nieuwe release rechtstreeks op mijn computer te bezorgen. Dit is geweldig, ongelooflijk.
Maar hier is het probleem: je hebt deze functie bij het updaten van de software, maar het integreren van mensen is veel moeilijker. Wat ik wil zeggen tijdens de keynote van DevOops is dat we nu veel meer spelers hebben dan ooit tevoren. Als je alleen maar denkt aan alle betrokkenen in slechts één team…. Je zag het als een team, en het is veel meer dan alleen een team programmeurs. Dit zijn testers, projectmanagers en een heleboel andere mensen. En iedereen heeft zijn eigen kijk op de wereld. Productmanagers zijn compleet anders dan projectmanagers. Beheerders hebben hun eigen taken. Het wordt een nogal moeilijk probleem om alle deelnemers te coördineren om op de hoogte te blijven van wat er gebeurt en niet gek te worden. Het is noodzakelijk om de taken van de groep te scheiden van taken die voor iedereen gelden. Dit is een zeer moeilijke taak. Aan de andere kant denk ik dat het allemaal veel beter is dan vele jaren geleden. Dit is precies de weg waarop mensen groeien en zich correct leren gedragen. Als je aan integratie doet, begrijp je dat er geen ondergrondse ontwikkeling mag plaatsvinden, zodat de software er op het allerlaatste moment niet als een jack-in-the-box uit kruipt: kijk eens wat we hier hebben gedaan! Het idee is dat je integratie en ontwikkeling kunt doen, en dat je uiteindelijk op een nette en iteratieve manier uitrolt. Dit alles betekent veel voor mij. Hierdoor is het mogelijk om meer waarde te creëren voor de gebruikers van het systeem en voor uw klant.
Michaël: Het hele idee van devops is om zo vroeg mogelijk betekenisvolle ontwikkelingen te realiseren. Ik zie dat de wereld steeds sneller gaat draaien. Hoe kun je je aanpassen aan dergelijke versnellingen? Tien jaar geleden bestond dit nog niet!
Tim: Iedereen wil natuurlijk steeds meer functionaliteit. U hoeft niet te bewegen, u kunt gewoon meer stapelen. Soms moet je zelfs langzamer gaan werken voor de volgende incrementele update om iets nuttigs te brengen - en dat is volkomen normaal.
Het idee dat je moet rennen, rennen, rennen is niet het beste. Het is onwaarschijnlijk dat iemand zo wil leven. Ik wil graag dat het ritme van de leveringen het eigen ritme van het project bepaalt. Als je alleen maar een stroom kleine, relatief betekenisloze dingen produceert, levert het allemaal geen betekenis op. In plaats van gedachteloos te proberen dingen zo vroeg mogelijk vrij te geven, is strategie de moeite waard om met de hoofdontwikkelaars en product- en projectmanagers te bespreken. Heeft dit überhaupt zin?
Patronen en antipatronen
Oleg: Meestal praat je over patronen en antipatronen, en dit is het verschil tussen het leven en de dood van projecten. En nu stormt devops ons leven binnen. Heeft het zijn eigen patronen en antipatronen die het project ter plekke kunnen vernietigen?
Tim: Patronen en antipatronen komen voortdurend voor. Iets om over te praten. Nou, er is iets dat we 'glanzende dingen' noemen. Mensen houden echt heel erg van nieuwe technologie. Ze zijn simpelweg gefascineerd door de glans van alles wat er cool en stijlvol uitziet, en ze houden op met het stellen van vragen: is het wel nodig? Wat gaan we bereiken? Is dit ding betrouwbaar, heeft het enige zin? Ik zie vaak mensen, om zo te zeggen, op het snijvlak van de technologie. Ze zijn gehypnotiseerd door wat er in de wereld gebeurt. Maar als je beter kijkt naar wat voor nuttige dingen ze doen, is er vaak gewoon niets nuttigs!
We hadden het er net met onze kameraden over dat dit jaar een jubileumjaar is, vijftig jaar geleden dat er mensen op de maan landden. Dit was in 1969. De technologie die mensen hielp dit doel te bereiken, is niet eens de technologie van 1969, maar eerder die van 1960 of 62, omdat NASA alleen datgene wilde gebruiken dat een goed bewijs van betrouwbaarheid had. En dus kijk je ernaar en begrijp je - ja, en ze waren waar! Nee, nee, maar je krijgt problemen met de technologie, simpelweg omdat alles te hard wordt gepusht, uit alle hoeken en gaten wordt verkocht. Overal roepen mensen: “Kijk, wat een ding, dit is het nieuwste, het mooiste ter wereld, geschikt voor absoluut iedereen!” Nou, dat is het... meestal blijkt dit allemaal slechts een lokaas te zijn, en dan moet het allemaal worden weggegooid. Misschien komt het allemaal omdat ik al een oude man ben en met veel scepsis naar zulke dingen kijk, terwijl mensen wegrennen en zeggen dat ze de enige, meest correcte manier hebben gevonden om de beste technologieën te creëren. Op dit moment wordt er een stem in mij wakker die zegt: “Wat een puinhoop!”
Michaël: Hoe vaak hebben we eigenlijk niet gehoord van de volgende ‘silver bullet’?
Tim: Precies, en dit is de gebruikelijke gang van zaken! Het lijkt er bijvoorbeeld op dat dit over de hele wereld al een grap is geworden, maar hier praten mensen vaak over blockchain-technologie. En in bepaalde situaties zijn ze zelfs zinvol! Als je echt betrouwbaar bewijs nodig hebt van gebeurtenissen, dat het systeem werkt en dat niemand ons heeft bedrogen, als je beveiligingsproblemen hebt en al die dingen door elkaar - blockchain is logisch. Maar als ze zeggen dat Blockchain nu de hele wereld zal overspoelen en alles op zijn pad zal wegvagen? Droom meer! Dit is een zeer dure en complexe technologie. Technisch complex en tijdrovend. Ook puur algoritmisch, elke keer dat je de wiskunde moet herberekenen, met de kleinste veranderingen... en dit is een geweldig idee - maar alleen voor bepaalde gevallen. Mijn hele leven en carrière staan in het teken hiervan: interessante ideeën in zeer specifieke situaties. Het is erg belangrijk om precies te begrijpen wat uw situatie is.
Michaël: Ja, de belangrijkste “vraag van het leven, het universum en alles”: is deze technologie of aanpak geschikt voor jouw situatie of niet?
Tim: Deze vraag kan al besproken worden met de technologiegroep. Misschien zelfs een adviseur inschakelen. Kijk eens naar het project en begrijp: zullen we nu iets goeds en nuttigs doen, beter dan voorheen? Misschien past het wel, misschien ook niet. Maar het allerbelangrijkste: neem zo’n beslissing niet standaard, simpelweg omdat iemand eruit flapte: “We hebben dringend een blockchain nodig! Ik heb net over hem gelezen in een tijdschrift in het vliegtuig!” Ernstig? Het is niet eens grappig.
De mythische ‘devops engineer’
Oleg: Nu implementeert iedereen devops. Iemand leest op internet over devops en morgen verschijnt er weer een vacature op een rekruteringssite. "devops engineer". Hier zou ik uw aandacht willen vestigen: denkt u dat deze term, ‘devops engineer’, recht op leven heeft? Er is een mening dat devops een cultuur is, en hier klopt iets niet.
Tim: Middelmatig. Laat ze dan meteen wat uitleg geven over deze term. Iets om het uniek te maken. Zolang ze niet bewijzen dat er een unieke combinatie van vaardigheden achter een vacature als deze zit, zal ik hem niet kopen! Ik bedoel, we hebben een functietitel: 'devops engineer', een interessante titel, ja, wat nu? Functietitels zijn over het algemeen heel interessant. Laten we zeggen ‘ontwikkelaar’ – wat is dat eigenlijk? Verschillende organisaties betekenen totaal verschillende dingen. In sommige bedrijven schrijven hoogwaardige programmeurs tests die logischer zijn dan tests die zijn geschreven door speciale professionele testers in andere bedrijven. Dus wat, zijn het nu programmeurs of testers?
Ja, we hebben functietitels, maar als je maar lang genoeg vragen stelt, blijkt uiteindelijk dat we allemaal probleemoplossers zijn. Wij zijn oplossingszoekers, en sommigen hebben enkele technische vaardigheden en sommigen hebben andere vaardigheden. Als je in een omgeving leeft waarin DevOps is doorgedrongen, ben je bezig met de integratie van ontwikkeling en beheer, en deze activiteit heeft een vrij belangrijk doel. Maar als je wordt gevraagd wat je precies doet en waar je verantwoordelijk voor bent, blijkt dat mensen al deze dingen al sinds mensenheugenis doen. “Ik ben verantwoordelijk voor de architectuur”, “Ik ben verantwoordelijk voor de databases” enzovoort, wat dan ook, zie je - dit alles was vóór “devops”.
Als iemand mij zijn functietitel vertelt, luister ik niet echt veel. Het is beter om hem te laten vertellen waar hij eigenlijk verantwoordelijk voor is. Hierdoor kunnen we de kwestie veel beter begrijpen. Mijn favoriete voorbeeld is wanneer iemand beweert een ‘projectmanager’ te zijn. Wat? Het betekent niets, ik weet nog steeds niet wat je doet. Een projectmanager kan een ontwikkelaar zijn, de leider van een team van vier personen, code schrijven, werk doen, die teamleider is geworden, die mensen onderling herkennen als leider. En een projectmanager kan ook een manager zijn die zeshonderd mensen op een project aanstuurt, andere managers aanstuurt, verantwoordelijk is voor het opstellen van planningen en het plannen van budgetten, meer niet. Dit zijn twee totaal verschillende werelden! Maar hun functietitel klinkt hetzelfde.
Laten we het een beetje anders omdraaien. Waar ben je echt goed in, heb je veel ervaring, heb je talent voor? Waar neem je de verantwoordelijkheid voor omdat je denkt dat je de taak aankunt? En hier zal iemand onmiddellijk beginnen te ontkennen: nee, nee, nee, ik heb helemaal geen zin om met projectbronnen om te gaan, het zijn niet mijn zaken, ik ben een technische kerel en ik begrijp bruikbaarheid en gebruikersinterfaces, dat doe ik niet Als ik überhaupt legers mensen wil beheren, kan ik beter aan het werk gaan.
En trouwens, ik ben een groot voorstander van een aanpak waarbij dit soort scheiding van vaardigheden prima werkt. Waar technici hun carrière zo ver kunnen laten groeien als ze willen. Toch zie ik nog steeds organisaties waar techneuten klagen: ik zal projectmanagement moeten gaan doen, want dat is de enige weg in dit bedrijf. Soms leidt dit tot verschrikkelijke uitkomsten. De beste techneuten zijn helemaal geen goede managers, en de beste managers kunnen niet met technologie omgaan. Laten we hier eerlijk over zijn.
Ik zie daar nu veel vraag naar. Als je een techneut bent, kan je bedrijf je helpen, maar hoe dan ook, je moet echt je eigen carrièrepad vinden, omdat de technologie blijft veranderen en je jezelf daarmee opnieuw moet uitvinden! In slechts twintig jaar kunnen technologieën minstens vijf keer veranderen. Technologie is een raar iets...
"Deskundigen op alles"
Michaël: Hoe kunnen mensen omgaan met de snelheid van de technologische veranderingen? Hun complexiteit groeit, hun aantal groeit, de totale hoeveelheid communicatie tussen mensen groeit ook, en het blijkt dat je geen ‘expert in alles’ kunt worden.
Tim: Rechts! Als je in de techniek werkt, moet je zeker iets specifieks kiezen en je erin verdiepen. Een technologie die uw organisatie nuttig vindt (en misschien ook daadwerkelijk nuttig zal zijn). En als je er niet langer in geïnteresseerd bent - ik had nooit geloofd dat ik dit zou zeggen - nou, misschien moet je dan naar een andere organisatie verhuizen waar de technologie interessanter of handiger is om te studeren.
Maar over het algemeen heb je gelijk. Technologieën groeien in alle richtingen tegelijk; niemand kan zeggen: “Ik ben een deskundige technoloog in alle bestaande technologieën.” Aan de andere kant zijn er sponsmensen die technologische kennis letterlijk in zich opnemen en er gek op zijn. Ik heb een paar van zulke mensen gezien, ze ademen en leven het letterlijk, het is nuttig en interessant om met ze te praten. Ze bestuderen niet alleen wat er binnen de organisatie gebeurt, maar praten er over het algemeen over, het zijn ook hele coole technologen, ze zijn heel bewust en doelgericht. Ze proberen gewoon op de top van de golf te blijven, ongeacht wat hun hoofdtaak is, omdat hun passie de beweging van technologie is, de promotie van technologie. Als je zo iemand plotseling tegenkomt, moet je met hem gaan lunchen en tijdens de lunch verschillende leuke dingen bespreken. Ik denk dat elke organisatie minstens een paar van zulke mensen nodig heeft.
Risico's en onzekerheid
Michaël: Geëerde ingenieurs, ja. Laten we het hebben over risicobeheer nu we tijd hebben. We begonnen dit interview met een bespreking van medische software, waarbij fouten tot ernstige gevolgen kunnen leiden. Toen spraken we over het Lunar Programma, waarbij de kosten van een fout miljoenen dollars bedragen, en mogelijk meerdere mensenlevens. Maar nu zie ik de tegenovergestelde beweging in de sector: mensen denken niet na over risico's, proberen ze niet te voorspellen, observeren ze niet eens.
Oleg: Beweeg snel en breek dingen!
Michaël: Ja, wees snel, breek dingen, steeds meer dingen, totdat je ergens aan sterft. Hoe moet de gemiddelde ontwikkelaar vanuit jouw standpunt nu het leerrisicobeheer benaderen?
Tim: Laten we hier een grens trekken tussen twee dingen: risico's en onzekerheid. Dit zijn verschillende dingen. Onzekerheid ontstaat wanneer u op een bepaald moment niet over voldoende gegevens beschikt om tot een definitief antwoord te komen. Als iemand u bijvoorbeeld in de allereerste fase van een project vraagt ‘wanneer bent u klaar met het werk’, zult u, als u een tamelijk eerlijk persoon bent, zeggen: ‘Ik heb geen idee.’ Je weet het gewoon niet, en dat is oké. Je hebt de problemen nog niet bestudeerd en bent niet bekend met het team, je kent hun vaardigheden niet, enzovoort. Dit is onzekerheid.
Risico’s ontstaan wanneer potentiële problemen al kunnen worden geïdentificeerd. Dit soort dingen kunnen gebeuren, de waarschijnlijkheid is groter dan nul, maar minder dan honderd procent, ergens daar tussenin. Hierdoor kan van alles gebeuren, van vertragingen en onnodig werk tot zelfs een fatale afloop voor het project. De uitkomst, als je zegt: jongens, laten we onze parasols opvouwen en het strand verlaten, dan zullen we het nooit afmaken, het is allemaal voorbij, punt uit. We gingen ervan uit dat dit ding zou werken, maar het werkt helemaal niet, het is tijd om te stoppen. Dit zijn de situaties.
Vaak zijn problemen het gemakkelijkst op te lossen als ze al zijn ontstaan, als het probleem zich nu voordoet. Maar als er zich een probleem voordoet, ben je niet bezig met risicomanagement, maar met probleemoplossing en crisismanagement. Als u een hoofdontwikkelaar of manager bent, vraagt u zich vast af wat er kan gebeuren dat zou leiden tot vertragingen, tijdverspilling, onnodige kosten of de ineenstorting van het hele project? Wat zal ons doen stoppen en opnieuw beginnen? Als al deze dingen werken, wat gaan we er dan mee doen? Er is een eenvoudig antwoord dat voor de meeste situaties geldt: loop niet weg voor risico’s, maar werk eraan. Kijk hoe je een risicovolle situatie kunt oplossen, tot niets kunt terugbrengen, van een probleem in iets anders kunt veranderen. In plaats van te zeggen: nou ja, we zullen problemen oplossen zodra ze zich voordoen.
Onzekerheid en risico moeten voorop staan in alles waarmee u te maken krijgt. Je kunt een projectplan maken, bepaalde kritische risico's van tevoren bekijken en zeggen: we moeten dit nu aanpakken, want als dit allemaal misgaat, doet niets anders er toe. U hoeft zich geen zorgen te maken over de schoonheid van het tafelkleed op tafel als het onduidelijk is of u het avondeten kunt bereiden. Eerst moet je alle risico's van het bereiden van een heerlijk diner identificeren, ermee omgaan en pas dan nadenken over alle andere dingen die geen echte bedreiging vormen.
Nogmaals, wat maakt uw project uniek? Laten we eens kijken wat ervoor kan zorgen dat ons project ontspoort. Wat kunnen we doen om de kans dat dit gebeurt zo klein mogelijk te maken? Meestal kun je ze niet zomaar 100% neutraliseren en met een zuiver geweten verklaren: “Dat is het, dit is niet langer een probleem, het risico is opgelost!” Voor mij is dit een teken van volwassen gedrag. Dit is het verschil tussen een kind en een volwassene: kinderen denken dat ze onsterfelijk zijn, dat er niets mis kan gaan, alles komt goed! Tegelijkertijd kijken volwassenen hoe driejarige kinderen op de speelplaats springen, de bewegingen met hun ogen volgen en tegen zichzelf zeggen: "ooh-ooh, ooh-ooh." Ik sta vlakbij en maak me klaar om op te vangen als het kind valt.
Aan de andere kant is de reden waarom ik dit vak zo leuk vind, omdat het riskant is. We doen dingen, en die dingen zijn riskant. Ze vereisen een volwassen aanpak. Enthousiasme alleen lost je problemen niet op!
Volwassen technisch denken
Michaël: Het voorbeeld met kinderen is goed. Als ik een gewone ingenieur ben, dan ben ik blij een kind te zijn. Maar hoe bereik je een meer volwassen denken?
Tim: Een van de ideeën die zowel bij een beginnende als bij een gevestigde ontwikkelaar even goed werkt, is het concept van context. Wat we doen, wat we gaan bereiken. Wat is echt belangrijk in dit project? Het maakt niet uit wie je bent in dit project, of je nu stagiair bent of hoofdarchitect, iedereen heeft context nodig. We moeten iedereen zover krijgen dat hij op grotere schaal nadenkt dan zijn eigen werkstuk. “Ik maak mijn stuk, en zolang mijn stuk werkt, ben ik gelukkig.” Nee en nog eens nee. Het is altijd de moeite waard (zonder onbeleefd te zijn!) om mensen te herinneren aan de context waarin ze werken. Wat we allemaal samen proberen te bereiken. Ideeën dat je een kind kunt zijn zolang alles in orde is met jouw deel van het project - doe dat alsjeblieft niet. Als we überhaupt over de finish komen, zullen we die alleen samen oversteken. Je bent niet alleen, we zijn allemaal samen. Als alle mensen in het project, zowel oud als jong, begonnen te praten over wat precies belangrijk is voor het project, waarom het bedrijf geld investeert in wat we allemaal proberen te bereiken... zullen de meesten van hen zich veel beter voelen omdat ze zullen zien hoe hun werk correleert met het werk van alle anderen. Aan de ene kant begrijp ik het stuk waarvoor ik persoonlijk verantwoordelijk ben. Maar om de klus te klaren hebben we ook alle andere mensen nodig. En als je echt denkt dat je klaar bent, hebben we altijd nog werk te doen in het project!
Oleg: Relatief gesproken, als je volgens Kanban werkt, kun je, als je op een knelpunt stuit bij een test, stoppen met wat je daar deed (bijvoorbeeld programmeren) en de testers gaan helpen.
Tim: Precies. Ik denk dat de beste techneuten, als je ze goed bekijkt, een soort van hun eigen managers zijn. Hoe kan ik dit formuleren...
Oleg: Je leven is jouw project, dat jij beheert.
Tim: Precies! Ik bedoel, je neemt verantwoordelijkheid, je begrijpt de kwestie, en je komt in contact met mensen als je ziet dat jouw beslissingen hun werk kunnen beïnvloeden, dat soort dingen. Het gaat er niet om dat je alleen maar aan je bureau zit, je werk doet en niet eens beseft wat er om je heen gebeurt. Nee nee nee. Eén van de leukste dingen van Agile is trouwens dat ze korte sprints voorstelden, omdat zo de stand van zaken van alle deelnemers duidelijk waarneembaar is, ze kunnen het allemaal samen zien. Wij praten elke dag over elkaar.
Hoe u in risicobeheer terechtkomt
Oleg: Bestaat er een formele kennisstructuur op dit gebied? Ik ben bijvoorbeeld Java-ontwikkelaar en wil risicomanagement begrijpen zonder van opleiding een echte projectmanager te worden. Ik zal waarschijnlijk eerst McConnell's "Hoeveel kost een softwareproject kosten" lezen, en wat dan? Wat zijn de eerste stappen?
Tim: De eerste is om te beginnen met communiceren met mensen in het project. Dit zorgt voor een directe verbetering van de communicatiecultuur met collega’s. We moeten beginnen door alles standaard te openen, in plaats van het te verbergen. Zeg: dit zijn de dingen die mij storen, dit zijn de dingen die mij 's nachts wakker houden, ik werd vandaag 's nachts wakker en dacht: mijn God, ik moet hierover nadenken! Zien anderen hetzelfde? Moeten we als groep reageren op deze potentiële problemen? Je moet een discussie over deze onderwerpen kunnen ondersteunen. Er bestaat geen vooraf opgestelde formule waarmee wij werken. Het gaat niet om het maken van hamburgers, het draait allemaal om mensen. “Een cheeseburger maken, een cheeseburger verkopen” is helemaal niet ons ding, en daarom hou ik zo van dit werk. Ik vind het leuk als alles wat managers vroeger deden, nu eigendom wordt van het team.
Oleg: Je hebt in boeken en interviews gesproken over hoe mensen meer om geluk geven dan om cijfers in een grafiek. Aan de andere kant, als je tegen het team zegt: we gaan over op devops, en nu moet de programmeur voortdurend communiceren, kan dit ver buiten zijn comfortzone liggen. En op dit moment kan hij, laten we zeggen, diep ongelukkig zijn. Wat te doen in deze situatie?
Tim: Ik weet niet precies wat ik moet doen. Als een ontwikkelaar te geïsoleerd is, zien ze überhaupt niet waarom het werk wordt gedaan, ze kijken alleen naar hun deel van het werk en moeten zich verdiepen in wat ik 'context' noem. Hij moet uitzoeken hoe alles met elkaar verbonden is. En dan bedoel ik natuurlijk niet formele presentaties of iets dergelijks. Ik heb het over het feit dat je met collega's moet communiceren over het werk als geheel, en niet alleen over het deel ervan waarvoor je verantwoordelijk bent. Hier kunt u beginnen met het bespreken van ideeën, gemeenschappelijke afspraken om uw werk goed op elkaar af te stemmen en hoe u samen een gemeenschappelijk probleem kunt aanpakken.
Om hen te helpen zich aan te passen, willen ze vaak techneuten naar training sturen en bespreken ze trainingen. Een vriend van mij zegt graag dat training voor honden is. Er zijn trainingen voor mensen. Een van de beste dingen aan leren als ontwikkelaar is de interactie met je collega's. Als iemand ergens heel goed in is, moet je hem aan het werk zien of met hem praten over zijn werk of zoiets. Een conventionele Kent Beck had het voortdurend over extreme programmering. Het is grappig omdat XP zo'n eenvoudig idee is, maar het veroorzaakt zoveel problemen. Voor sommigen is XP doen hetzelfde als gedwongen worden zich uit te kleden in het bijzijn van vrienden. Ze zullen zien wat ik doe! Het zijn mijn collega's, ze zullen het niet alleen zien, maar ook begrijpen! Vreselijk! Sommige mensen beginnen ernstig nerveus te worden. Maar als je beseft dat dit de ultieme manier is om te leren, verandert alles. Je werkt nauw samen met mensen, en sommige mensen begrijpen het onderwerp veel beter dan jij.
Michaël: Maar dit alles dwingt je om uit je comfortzone te stappen. Als ingenieur moet je uit je comfortzone komen en communiceren. Als probleemoplosser moet je jezelf voortdurend in een zwakke positie plaatsen en nadenken over wat er mis kan gaan. Dit soort werk is inherent bedoeld om hinderlijk te zijn. Je plaatst jezelf bewust in stressvolle situaties. Meestal rennen mensen voor hen weg, mensen houden ervan gelukkige kinderen te zijn.
Tim: Wat kan er gedaan worden, je kunt naar buiten komen en openlijk zeggen: “Alles is in orde, ik kan het aan! Ik ben niet de enige die zich ongemakkelijk voelt. Laten we als team verschillende ongemakkelijke dingen bespreken!” Dit zijn onze gemeenschappelijke problemen, we moeten ze aanpakken, weet je? Ik denk dat eigenzinnige geniale ontwikkelaars als mammoeten zijn: ze zijn verdwenen. En hun betekenis is zeer beperkt. Als je niet kunt communiceren, kun je niet goed meedoen. Spreek daarom gewoon. Wees eerlijk en open. Het spijt mij zeer dat dit voor iemand onaangenaam is. Kun je je voorstellen dat er vele jaren geleden een onderzoek was waaruit bleek dat de grootste angst in de Verenigde Staten niet de dood is, maar raad eens? Angst voor spreken in het openbaar! Dit betekent dat er ergens mensen zijn die liever doodgaan dan hardop een compliment uitspreken. En ik denk dat het voldoende is dat je over een aantal basisvaardigheden beschikt, afhankelijk van wat je doet. Spreekvaardigheid, schrijfvaardigheid – maar alleen zoveel als echt nodig is in je werk. Als je als analist werkt, maar niet kunt lezen, schrijven of spreken, dan heb je helaas niets te doen in mijn projecten!
De prijs van communicatie
Oleg: Is het in dienst nemen van zulke uitgaande medewerkers om verschillende redenen niet duurder? Ze zijn tenslotte voortdurend aan het chatten in plaats van aan het werk!
Tim: Ik bedoelde de kern van het team, en niet alleen iedereen. Als je iemand hebt die echt cool is in het tunen van databases, dol is op het tunen van databases, en de rest van zijn leven doorgaat met het tunen van je databases, en dat is het, cool, ga zo door. Maar ik heb het over mensen die in het project zelf willen wonen. De kern van het team, gericht op de ontwikkeling van het project. Deze mensen moeten echt voortdurend met elkaar communiceren. En vooral aan het begin van het project, wanneer je risico's bespreekt, manieren om mondiale doelen te bereiken en dergelijke.
Michaël: Dit geldt voor iedereen die betrokken is bij het project, ongeacht specialisatie, vaardigheden of manier van werken. Jullie zijn allemaal geïnteresseerd in het succes van het project.
Tim: Ja, je hebt het gevoel dat je voldoende in het project bent ondergedompeld, dat het jouw taak is om het project te helpen verwezenlijken. Of u nu een programmeur, analist, interface-ontwerper of wie dan ook bent. Dit is de reden dat ik elke ochtend naar mijn werk kom en dit is wat we doen. Wij zijn verantwoordelijk voor al deze mensen, ongeacht hun vaardigheden. Dit is een groep mensen die gesprekken met volwassenen voeren.
Oleg: Als we het over spraakzame werknemers hebben, heb ik geprobeerd de bezwaren van mensen, vooral managers, die gevraagd worden om over te stappen naar devops, tegen deze geheel nieuwe visie op de wereld te simuleren. En jij als adviseur zou je veel beter bewust moeten zijn van deze bezwaren dan ik als ontwikkelaar! Deel wat managers het meest zorgen baart?
Tim: Managers? Hm. Meestal staan managers onder druk van problemen, worden ze geconfronteerd met de noodzaak om dringend iets vrij te geven en iets af te leveren, en dergelijke. Ze kijken hoe we voortdurend over iets discussiëren en discussiëren, en ze zien het zo: gesprekken, gesprekken, gesprekken... Welke andere gesprekken? Ga weer aan het werk! Want praten voelt voor hen niet als werk. Je schrijft geen code, test geen software, lijkt niets te doen - waarom stuur je je niet om iets te doen? De levering is immers al over een maand!
Michaël: Ga wat code schrijven!
Tim: Het lijkt mij dat ze zich geen zorgen maken over het werk, maar over het gebrek aan zichtbaarheid van de vooruitgang. Om het te laten lijken alsof we dichter bij succes komen, moeten ze ons op knoppen op het toetsenbord zien drukken. De hele dag van 's ochtends tot 's avonds. Dit is probleem nummer één.
Oleg: Misha, je denkt aan iets.
Michaël: Sorry, ik was in gedachten verzonken en kreeg een flashback. Dit alles deed me denken aan een interessante rally die gisteren plaatsvond... Er waren gisteren te veel rally's... En het klinkt allemaal heel bekend!
Leven zonder salarissen
Tim: Het is overigens helemaal niet nodig om ‘bijeenkomsten’ voor communicatie te organiseren. Ik bedoel, de nuttigste discussies tussen ontwikkelaars vinden plaats als ze gewoon met elkaar praten. Je komt 's ochtends binnen met een kop koffie en er staan vijf mensen bij elkaar die verwoed iets technisch bespreken. Als ik de manager van dit project ben, is het voor mij beter om gewoon te glimlachen en ergens over mijn bedrijf te praten en ze erover te laten praten. Zij worden al zoveel mogelijk betrokken. Dit is een goed teken.
Oleg: Trouwens, in je boek heb je een heleboel aantekeningen over wat goed en wat slecht is. Gebruik je er zelf één? Relatief gezien heb je nu een bedrijf, en wel een dat op een zeer onorthodoxe manier is gestructureerd...
Tim: Onorthodox, maar dit apparaat past perfect bij ons. Wij kennen elkaar al heel lang. We vertrouwen elkaar, we vertrouwden elkaar veel voordat we partners werden. En we hebben bijvoorbeeld helemaal geen salarissen. We werken gewoon, en als ik bijvoorbeeld geld verdiende van mijn klanten, ging al het geld naar mij. Daarna betalen we lidmaatschapsgelden aan de organisatie, en dit is genoeg om het bedrijf zelf te ondersteunen. Bovendien zijn we allemaal gespecialiseerd in verschillende dingen. Ik werk bijvoorbeeld samen met accountants, vul belastingaangiften in, doe allerlei administratieve zaken voor het bedrijf en niemand betaalt mij ervoor. James en Tom werken op onze website en niemand betaalt ze ook. Zolang u uw contributie betaalt, zal niemand eraan denken u te vertellen wat u moet doen. Tom werkt nu bijvoorbeeld veel minder dan hij ooit deed. Nu heeft hij andere interesses; hij doet sommige dingen niet voor het Gilde. Maar zolang hij zijn contributie betaalt, zal niemand naar hem toe komen en zeggen: "Hé, Tom, ga aan het werk!" Het is heel gemakkelijk om met collega's om te gaan als er geen geld tussen jullie is. En nu is onze relatie een van de fundamentele ideeën met betrekking tot verschillende specialiteiten. Het werkt en het werkt heel goed.
Beste advies
Michaël: Om terug te komen op ‘het beste advies’: is er iets dat u uw klanten keer op keer vertelt? Er is een idee over 80/20, en sommige adviezen worden waarschijnlijk vaker herhaald.
Tim: Ik dacht ooit dat als je een boek als Waltzing with Bears zou schrijven, het de loop van de geschiedenis zou veranderen en dat mensen zouden stoppen, maar... Kijk, bedrijven doen vaak alsof alles goed met ze gaat. Zodra er iets ergs gebeurt, is dat voor hen een schok en een verrassing. “Kijk, we hebben het systeem getest en het doorstaat geen enkele systeemtest, en dit is nog eens drie maanden ongepland werk, hoe heeft dit kunnen gebeuren? Wie weet? Wat kan er fout gaan? Serieus, geloof je dit?
Ik probeer uit te leggen dat je niet te boos moet worden over de huidige situatie. We moeten het uitpraten, echt begrijpen wat er mis had kunnen gaan en hoe we kunnen voorkomen dat dergelijke dingen in de toekomst gebeuren. Als er zich toch een probleem voordoet, hoe gaan we dat dan bestrijden, hoe gaan we het onder controle houden?
Voor mij lijkt dit allemaal beangstigend. Mensen hebben te maken met complexe, lastige problemen en blijven doen alsof als ze maar hun vingers kruisen en hopen op het beste, het ‘beste’ ook daadwerkelijk zal gebeuren. Nee, zo werkt het niet.
Oefen risicomanagement!
Michaël: Hoeveel organisaties houden zich volgens u bezig met risicomanagement?
Tim: Wat mij woedend maakt, is dat mensen simpelweg de risico's opschrijven, naar de resulterende lijst kijken en aan het werk gaan. In feite is het identificeren van risico's voor hen risicobeheer. Maar voor mij klinkt dit als een reden om te vragen: oké, er is een lijst, wat ga je precies veranderen? U moet uw standaardvolgorde van acties wijzigen, rekening houdend met deze risico's. Als er een bepaald moeilijk deel van het werk is, moet je dat aanpakken en pas dan verdergaan met iets eenvoudigers. Begin in de eerste sprints met het oplossen van complexe problemen. Dit lijkt al op risicomanagement. Maar meestal kunnen mensen niet zeggen wat ze hebben veranderd nadat ze een lijst met risico's hebben samengesteld.
Michaël: En toch: hoeveel van deze bedrijven houden zich bezig met risicobeheer, vijf procent?
Tim: Helaas zeg ik dit niet graag, maar dit is een heel onbelangrijk onderdeel. Maar meer dan vijf, omdat er echt grote projecten zijn, en die kunnen simpelweg niet bestaan als ze niet op zijn minst iets doen. Laten we zeggen dat het mij zeer zal verbazen als het minimaal 25% is. Kleine projecten beantwoorden dergelijke vragen meestal op deze manier: als het probleem ons treft, dan zullen we het oplossen. Vervolgens brengen ze zichzelf met succes in de problemen en houden zich bezig met probleembeheer en crisisbeheersing. Wanneer u een probleem probeert op te lossen en het probleem is niet opgelost, welkom bij crisismanagement.
Ja, ik hoor vaak: “we zullen problemen oplossen zodra ze zich voordoen.” Dat zullen we zeker doen? Gaan we echt beslissen?
Oleg: Je kunt het naïef doen en belangrijke invarianten eenvoudigweg in het projectcharter schrijven, en als de invarianten kapot gaan, start je het project gewoon opnieuw. Het blijkt erg piembucky.
Michaël: Ja, het is mij overkomen dat wanneer risico's zich voordeden, het project eenvoudigweg opnieuw werd gedefinieerd. Leuk, bingo, probleem opgelost, maak je geen zorgen meer!
Tim: Laten we op de resetknop drukken! Nee, zo werkt het niet.
Keynote op DevOops 2019
Michaël: We zijn aangekomen bij de laatste vraag van dit interview. Je komt naar de volgende DevOops met een keynote. Kun je het gordijn van geheimhouding oplichten over wat je gaat vertellen?
Tim: Op dit moment schrijven zes van hen een boek over de werkcultuur, de onuitgesproken regels van organisaties. Cultuur wordt bepaald door de kernwaarden van de organisatie. Normaal gesproken merken mensen dit niet, maar omdat we al jaren in de consultancy werken, zijn we eraan gewend om het op te merken. Je komt een bedrijf binnen en letterlijk binnen een paar minuten begin je te voelen wat er gebeurt. Wij noemen dit ‘smaak’. Soms is deze geur echt lekker, en soms is het, nou ja, oeps. Voor verschillende organisaties zijn de zaken heel verschillend.
Michaël: Ook ik werk al jaren in de consultancy en begrijp goed waar je het over hebt.
Tim: Een van de dingen die het waard zijn om tijdens de keynote te bespreken, is eigenlijk dat niet alles door het bedrijf wordt bepaald. Jij en je team hebben als gemeenschap je eigen teamcultuur. Dit kan het hele bedrijf zijn, of een aparte afdeling, een apart team. Maar voordat je zei: dit is wat wij geloven, dit is wat belangrijk is... Je kunt een cultuur niet veranderen voordat de waarden en overtuigingen achter specifieke acties worden begrepen. Gedrag is gemakkelijk waar te nemen, maar het zoeken naar overtuigingen is moeilijk. DevOps is slechts een mooi voorbeeld van hoe zaken steeds complexer worden. Interacties worden alleen maar complexer, ze worden helemaal niet schoner of duidelijker, dus je moet nadenken over waar je in gelooft en waar iedereen om je heen zwijgt.
Als u snel resultaat wilt bereiken, is dit een goed onderwerp voor u: heeft u bedrijven gezien waar niemand zegt: “Ik weet het niet”? Er zijn plaatsen waar je iemand letterlijk martelt totdat hij toegeeft dat hij iets niet weet. Iedereen weet alles, iedereen is een ongelooflijke erudiet. Je benadert iemand en hij moet de vraag onmiddellijk beantwoorden. In plaats van te zeggen: ‘Ik weet het niet’. Hoera, ze hebben een stel erudieten ingehuurd! En in sommige culturen is het over het algemeen erg gevaarlijk om te zeggen: ‘Ik weet het niet’; het kan worden gezien als een teken van zwakte. Er zijn ook organisaties waarin juist iedereen kan zeggen: ‘Ik weet het niet’. Daar is het volkomen legaal, en als iemand op een vraag begint te onzin, is het volkomen normaal om te antwoorden: “Je weet niet waar je het over hebt, toch?” en maak er een grapje van.
Idealiter zou je een baan willen hebben waar je voortdurend gelukkig kunt zijn. Het zal niet gemakkelijk zijn, niet elke dag is zonnig en prettig, soms moet je hard werken, maar als je de balans opmaakt, zal het blijken: wauw, dit is echt een prachtige plek, ik voel me goed om hier te werken, zowel emotioneel als intellectueel. En er zijn bedrijven waar je als consultant naar toe gaat en meteen beseft dat je het drie maanden niet volhoudt en met afgrijzen weg zou rennen. Daar wil ik het in het rapport over hebben.
Tim Lister zal arriveren met een keynote naar de DevOops 2019-conferentie, die plaatsvindt op 29-30 oktober 2019 in St. Petersburg. Je kunt kaartjes kopen . Wij wachten op u bij DevOops!
Bron: www.habr.com