Tim Lister - könyvek társszerzője

• "Emberi tényező. Sikeres projektek és csapatok" (az eredeti könyv neve „Peopleware")
• "Waltzing with the Bears: kockázatkezelés szoftverprojektekben"
• „Adrenalintól őrült és a mintáktól zombivá vált. A projektcsapatok viselkedési mintái"

Ezek a könyvek mindegyike klasszikus a saját területén, és kollégáival együtt írták Atlantic Systems Guild. Oroszországban kollégái a leghíresebbek - Tom DeMarco и Hruschka Péter, aki számos híres művet is írt.

Tim 40 éves szoftverfejlesztési tapasztalattal rendelkezik; 1975-ben (a habraposztot írók közül senki sem idén született) Tim már a Yourdon Inc ügyvezető alelnöke volt. Most tanácsadással, tanítással és írással tölti idejét, alkalmanként meglátogatva jelentésekkel konferenciákon szerte a világon.

Interjút készítettünk Tim Listerrel, kifejezetten a Habr számára. Ő fogja megnyitni a DevOops 2019 konferenciát, és sok kérdésünk van a könyvekkel és egyebekkel kapcsolatban. Az interjút Mihail Druzhinin és Oleg Chirukhin készíti a konferencia programbizottságából.

Michael: Mondanál néhány szót arról, amit most csinálsz?

Tim: Én vagyok az Atlantic Systems Guild vezetője. Hatan vagyunk a Céhben, igazgatóknak mondjuk magunkat. Három az Egyesült Államokban és három Európában – ezért hívják a céhet Atlanticnak. Olyan sok éve vagyunk együtt, hogy nem lehet megszámolni őket. Mindannyiunknak megvannak a sajátosságai. Az elmúlt évtizedben vagy még tovább dolgozom ügyfelekkel. Projektjeim nem csak a menedzsmentet foglalják magukban, hanem a követelmények felállítását, a projekttervezést és az értékelést is. Úgy tűnik, hogy a rosszul induló projektek általában rosszul végződnek. Érdemes tehát odafigyelni arra, hogy minden tevékenység valóban átgondolt és összehangolt legyen, az alkotók ötletei ötvözve legyenek. Érdemes átgondolni, hogy mit és miért csinálsz. Milyen stratégiákat kell alkalmazni a projekt befejezéséhez.

Évek óta foglalkozom ügyfeleim sokrétű tanácsadásával. Érdekes példa egy térd- és csípőműtétekhez robotokat gyártó cég. A sebész nem működik teljesen önállóan, hanem robotot használ. A biztonság itt őszintén szólva fontos. De amikor megpróbálja megvitatni a követelményeket olyan emberekkel, akik a problémák megoldására összpontosítanak... Furcsán hangzik, de az USA-ban van FDA (Federal Drug Administration), amely az ilyen robotokhoz hasonló termékeket engedélyez. Mielőtt bármit eladna és élő embereken használná, engedélyt kell szereznie. Az egyik feltétel, hogy mutasd be az igényeidet, mik a tesztek, hogyan tesztelted, mik a vizsgálati eredmények. Ha megváltoztatja a követelményeket, akkor újra és újra át kell mennie ezen az egész hatalmas tesztelési folyamaton. Ügyfeleinknek sikerült beépíteni igényeik közé az alkalmazások vizuális tervezését. Közvetlenül a követelmények részeként rendelkeztek képernyőképekkel. Ki kell húznunk őket, és el kell magyaráznunk, hogy ezek a programok nagyrészt semmit sem tudnak a térdről és a csípőről, mindezekről a kameráról stb. Át kell írnunk a követelménydokumentumokat, hogy azok soha ne változzanak, hacsak nem változik meg néhány igazán fontos alapfeltétel. Ha a látványterv nem felel meg a követelményeknek, a termék frissítése sokkal gyorsabb lesz. A mi feladatunk az, hogy megkeressük azokat az elemeket, amelyek a térd, csípő, hát műtéteivel foglalkoznak, külön dokumentumokba szedjük, és elmondjuk, hogy ezek lesznek az alapvető követelmények. Készítsünk egy elszigetelt követelménycsoportot a térdműtétekkel kapcsolatban. Ez lehetővé teszi számunkra, hogy egy stabilabb követelményrendszert építsünk fel. A teljes termékcsaládról fogunk beszélni, nem pedig konkrét robotokról.

Rengeteg munka történt, de így is eljutottak olyan helyekre, ahol korábban hetekig, hónapokig ismételt teszteléseket töltöttek értelme és szükség nélkül, mert a papíron leírt követelményeik nem estek egybe a valós követelményekkel, amelyekre a rendszereket építették. Az FDA minden alkalommal azt mondta nekik: az Ön követelményei megváltoztak, most mindent a nulláról kell ellenőriznie. A teljes termék teljes újraellenőrzése megölte a vállalkozást.

Szóval vannak olyan csodálatos feladatok, amikor valami érdekes dolognak a legelején találod magad, és a legelső akciók meghatározzák a további játékszabályokat. Ha megbizonyosodik arról, hogy ez a korai tevékenység mind vezetési, mind technikai szempontból jól kezd működni, akkor nagy esély van arra, hogy egy nagyszerű projektet kapjon. De ha ez a rész kikerült a sínekből, és valahol elromlott, ha nem találja meg az alapvető megállapodásokat... nem, nem arról van szó, hogy a projektje szükségszerűen megbukik. De már nem mondhatja azt, hogy „Remekül teljesítettünk, mindent igazán hatékonyan csináltunk.” Ezeket a dolgokat csinálom, amikor az ügyfelekkel kommunikálok.

Michael: Vagyis elindítasz projekteket, csinálsz valami kickoffot és ellenőrzöd, hogy jó irányba mennek-e a sínek?

Tim: Arra is vannak ötleteink, hogyan rakjuk össze a puzzle minden darabját: milyen képességekre van szükségünk, pontosan mikor, hogyan néz ki a csapat magja és egyéb ilyen alapvető dolgok. Teljes munkaidős alkalmazottakra van szükségünk, vagy felvehetünk valakit részmunkaidőben? Tervezés, irányítás. Ilyen kérdések: Mi a legfontosabb ennél a projektnél? Hogyan lehet ezt elérni? Mit tudunk erről a termékről vagy projektről, mik a kockázatok és hol rejlenek az ismeretlenek, hogyan fogunk mindezt kezelni? Persze ebben a pillanatban valaki elkezd kiabálni, hogy "Mi van agilis?!" Rendben, rugalmasak vagytok, de mi van? Hogy néz ki pontosan a projekt, hogyan fogod a projektnek megfelelő módon kivenni? Nem lehet csak azt mondani, hogy „megközelítésünk bármire kiterjed, mi egy Scrum csapat vagyunk!” Ez nonszensz és nonszensz. Hova mész tovább, miért működne, hol a lényeg? Megtanítom ügyfeleimet, hogy gondolkodjanak ezeken a kérdéseken.

19 éves agilis

Michael: Az Agilisban az emberek gyakran megpróbálnak nem előre meghatározni semmit, hanem a lehető legkésőbbi döntéseket hozni, mondván: túl nagyok vagyunk, nem fogok a teljes architektúrára gondolni. Nem fogok sok más dologra gondolni, ehelyett olyan dolgot szállítok az ügyfélnek, ami most működik.

Tim: Azt hiszem, hogy agilis módszerek, kezdve Agilis manifesztum 2001-ben felnyitotta az iparág szemét. De másrészt semmi sem tökéletes. Én az iteratív fejlesztés mellett vagyok. Az iterációnak sok értelme van a legtöbb projektben. Ám a kérdés, amelyen el kell gondolkodnia, a következő: ha a termék kikerült és használatban van, mennyi ideig tart? Ez egy olyan termék, amely hat hónapig kitart, mielőtt valami másra cserélné? Vagy ez egy olyan termék, ami sok-sok évig működik? Természetesen nem mondok neveket, de... New Yorkban és pénzügyi közösségében a legalapvetőbb rendszerek nagyon régiek. Ez elképesztő. Nézed őket, és arra gondolsz, ha visszamehetnél az időben, 1994-be, és azt mondod a fejlesztőknek: „A jövőből jöttem, 2019-ből. Csak addig fejlessze ezt a rendszert, amíg szüksége van rá. Tedd bővíthetővé, gondolj az építészetre. Ezt követően több mint huszonöt éven keresztül javítják. Ha egy kicsit tovább halogatod a fejlesztést, akkor a dolgok nagy rendjén senki sem fogja észrevenni!” Ha hosszú távon becsüli meg a dolgokat, mérlegelnie kell, hogy ez összesen mennyibe fog kerülni. A jól megtervezett építészet néha tényleg megéri, néha pedig nem. Körül kell néznünk, és fel kell tennünk magunknak a kérdést: vajon jó helyzetben vagyunk-e egy ilyen döntéshez?

Tehát egy olyan ötlet, mint „Mi az agilisért vagyunk, az ügyfél maga fogja megmondani, mit szeretne kapni” – ez rendkívül naiv. Az ügyfelek azt sem tudják, mit akarnak, és még inkább nem tudják, mit kaphatnának. Néhányan történelmi példákat kezdenek majd felhozni érvként, ezt már láttam. De technikailag fejlett emberek általában nem mondanak ilyet. Azt mondják: „2019 van, ezek a lehetőségeink, és teljesen megváltoztathatjuk azt, ahogyan ezeket a dolgokat nézzük!” A meglévő megoldások utánzása, szebbé és fésültebbé tétele helyett időnként ki kell mennie, és azt kell mondania: „Feltaláljuk fel teljesen újra, amit itt akarunk csinálni!”

És nem hiszem, hogy a legtöbb ügyfél így gondolhatja a problémát. Csak azt látják, ami már van, ez minden. Ezt követően olyan kérésekkel jelentkeznek, mint „tegyük ezt egy kicsit egyszerűbbé”, vagy bármi mást, amit általában mondanak. De nem vagyunk pincérek vagy pincérlányok, így akármilyen hülyén is felvehetünk egy rendelést, majd a konyhában megsütjük. Mi vagyunk a vezetőik. Ki kell nyitnunk a szemüket, és azt kell mondanunk: hé, itt új lehetőségek vannak! Tisztában van azzal, hogy valóban meg tudjuk változtatni a vállalkozásának ezt a részét? Az Agile egyik problémája, hogy eltávolítja a tudatot arról, hogy mi a lehetőség, mi a probléma, mit kell még tennünk, milyen elérhető technológiák a legalkalmasabbak erre a helyzetre.

Talán túlságosan szkeptikus vagyok itt: nagyon sok csodálatos dolog történik az agilis közösségben. De azzal van a bajom, hogy ahelyett, hogy egy projektet definiálnának, az emberek elkezdik feltenni a kezüket. Itt megkérdezném - mit csinálunk, hogyan fogjuk csinálni? És valahogy varázsütésre mindig kiderül, hogy az ügyfélnek mindenkinél jobban kell tudnia. De a megrendelő csak akkor tudja a legjobban, ha valaki által már megépített dolgok közül választ. Ha autót szeretnék venni, és tudom, mekkora a családi költségvetésem, akkor gyorsan kiválasztom az életstílusomnak megfelelő autót. Itt mindent jobban tudok, mint bárki! De vegye figyelembe, hogy valaki már elkészítette az autókat. Fogalmam sincs, hogyan kell új autót feltalálni, nem vagyok szakértő. Amikor egyedi vagy speciális termékeket készítünk, a vásárló hangját is figyelembe kell venni, de már nem ez az egyetlen hang.

Oleg: Említetted az Agilis Kiáltványt. Valahogy frissítenünk vagy felül kell vizsgálnunk, figyelembe véve a probléma modern felfogását?

Tim: Nem nyúlnék hozzá. Szerintem ez egy nagyszerű történelmi dokumentum. Úgy értem, ő olyan, amilyen. 19 éves lesz, öreg, de a maga idejében forradalmat csinált. Amit jól csinált, az az volt, hogy reakciót váltott ki, és az emberek suttogni kezdtek róla. Ön valószínűleg 2001-ben még nem dolgozott az iparban, de akkor mindenki a folyamatok szerint dolgozott. Software Engineering Institute, a szoftverteljességi modell (CMMI) öt szintje. Nem tudom, mondanak-e valamit az efféle mély ókori legendák, de akkor ez volt az áttörés. Eleinte az emberek azt hitték, hogy ha a folyamatokat helyesen állítják be, akkor a problémák maguktól megszűnnek. Aztán jön a Kiáltvány, és azt mondja: „Nem, nem, nem – emberekre fogunk alapozni, nem folyamatokra.” A szoftverfejlesztés mesterei vagyunk. Megértjük, hogy az ideális folyamat egy délibáb, ez nem történik meg. Túl sok az egyediség a projektekben, nincs értelme annak az ötletnek, hogy egyetlen tökéletes folyamat legyen minden projekt számára. A problémák túl összetettek ahhoz, hogy azt állítsuk, mindenre csak egy megoldás létezik (hello, nirvána).

Nem feltételezem, hogy a jövőbe nézek, de azt mondom, hogy az emberek most kezdtek többet gondolkodni a projekteken. Szerintem az Agilis Kiáltvány nagyon jó abban, hogy kiugorjon és azt mondja: „Hé! Ön egy hajón van, és maga vezeti ezt a hajót. Dönteni kell – nem fogunk minden helyzetre univerzális receptet javasolni. Te vagy a hajó legénysége, és ha elég jó vagy, megtalálhatod a célhoz vezető utat. Voltak más hajók előtted, és lesznek más hajók is utánad, de bizonyos értelemben az utazásod mégis egyedülálló." Valami hasonló! Ez egy gondolkodásmód. Számomra nincs új a nap alatt, az emberek már vitorláztak, és még fognak vitorlázni, de neked ez a fő utad, és nem árulom el, mi fog veled pontosan történni. Rendelkeznie kell a csapatban végzett összehangolt munka készségeivel, és ha ez valóban megvan, minden sikerülni fog, és oda fog jutni, ahová akar.

Peopleware: 30 évvel később

Oleg: A Peopleware éppúgy forradalom volt, mint a Kiáltvány?

Tim: Peopleware... Tom és én írtuk ezt a könyvet, de nem gondoltuk, hogy ez így fog megtörténni. Valahogy sok ember ötletére visszhangzott. Ez volt az első könyv, amely azt mondta: a szoftverfejlesztés nagyon emberigényes tevékenység. Technikai természetünk ellenére mi is emberek közössége vagyunk, akik valami nagyot, sőt hatalmasat, nagyon összetettet építenek. Senki sem tud ilyen dolgokat egyedül létrehozni, igaz? Így a "csapat" ötlete nagyon fontossá vált. És nem csak menedzsment szempontból, hanem műszaki embereknek is, akik azért jöttek össze, hogy egy csomó ismeretlennel megoldják az igazán összetett mély problémákat. Számomra ez az intelligencia hatalmas próbája volt karrierem során. És itt el kell tudni mondani: igen, ez a probléma több annál, mint amit egyedül meg tudok oldani, de együtt találhatunk egy elegáns megoldást, amelyre büszkék lehetünk. És azt hiszem, ez az ötlet volt a legnagyobb visszhangot keltő. Az az elképzelés, hogy az idő egy részét egyedül, részben egy csoport tagjaként dolgozzuk, és gyakran a csoport hozza meg a döntést. A csoportos problémamegoldás gyorsan a komplex projektek fontos jellemzőjévé vált.

Annak ellenére, hogy Tim rengeteg előadást tartott, ezek közül nagyon kevés került fel a YouTube-ra. Megtekintheti a „The Return of Peopleware” című jelentést 2007-ből. A minőség természetesen sok kívánnivalót hagy maga után.

Michael: Változott valami a könyv megjelenése óta eltelt 30 évben?

Tim: Ezt sokféle szemszögből nézheted. Szociológiai szempontból... valamikor, az egyszerűbb időkben, te és a csapatod egy irodában ültél. Minden nap közel lehettek, együtt kávézhatnátok és megbeszélhetnétek a munkát. Ami igazán megváltozott, az az, hogy a csapatok már földrajzilag, különböző országokban és időzónákban is eloszthatók, de továbbra is ugyanazon a problémán dolgoznak, és ez egy teljesen új összetettséget ad hozzá. Lehet, hogy ez régimódinak hangzik, de semmi sem hasonlít a személyes kommunikációhoz, ahol mindannyian együtt vagytok, együtt dolgoztok, és odaléphettek egy kollégához, és azt mondjátok: nézd, mit fedeztem fel, hogy tetszik ez? A személyes beszélgetések segítségével gyorsan át lehet térni az informális kommunikációra, és szerintem az agilis rajongóknak is tetszeni kell. És azért is aggódom, mert a valóságban a világ nagyon kicsinek bizonyult, és most az egészet elosztott csapatok borítják, és mindez nagyon összetett.

Mindannyian DevOps-ban élünk

Michael: Még a konferencia programbizottságának szemszögéből is vannak emberek Kaliforniában, New Yorkban, Európában, Oroszországban... Szingapúrban még nincs senki. A földrajzi különbségek meglehetősen nagyok, és az emberek egyre jobban kezdenek szétszóródni. Ha már a fejlesztésről beszélünk, tudna többet mondani a devopokról és a csapatok közötti korlátok lebontásáról? Van egy olyan koncepció, hogy mindenki a bunkereiben ül, és most a bunkerek összeomlanak, mi a véleménye erről a hasonlatról?

Tim: Számomra úgy tűnik, hogy a közelmúlt technológiai áttörései fényében a devops nagy jelentőséggel bír. Korábban fejlesztői és rendszergazdák csapatai voltak, dolgoztak, dolgoztak, dolgoztak, és valamikor megjelent egy dolog, amivel el lehetett jönni az adminokhoz, és ki lehetett dobni a termelésbe. És itt kezdődött a beszélgetés a bunkerről, mert az adminok amolyan szövetségesek, legalábbis nem ellenségek, de csak akkor beszéltél velük, amikor minden készen állt a gyártásra. Elmentél hozzájuk valamivel, és azt mondod: nézd, milyen alkalmazásunk van, de ki tudnád dobni ezt az alkalmazást? És most az egész szállítási koncepció jobbra változott. Úgy értem, volt egy olyan ötlet, hogy gyorsan át lehet vinni a változásokat. A termékeket menet közben frissíthetjük. Mindig elmosolyodom, amikor felugrik a Firefox a laptopomon, és azt mondja: Hé, frissítettük a Firefoxot a háttérben, és amint van egy perce, kattintson ide, és megadjuk a legújabb kiadást. És azt mondtam: "Ó, igen, bébi!" Amíg aludtam, azon dolgoztak, hogy egy új kiadást szállítsanak nekem közvetlenül a számítógépemre. Ez csodálatos, hihetetlen.

De itt van a nehézség: a szoftver frissítésével rendelkezik ez a funkció, de az emberek integrálása sokkal nehezebb. A DevOops vitaindító előadásán hangot szeretnék adni, hogy most sokkal több játékosunk van, mint valaha. Ha csak egy csapatban mindenkire gondolsz… Úgy gondoltad, mint egy csapat, és ez sokkal több, mint egy programozói csapat. Ezek tesztelők, projektmenedzserek és egy csomó más ember. És mindenkinek megvan a maga véleménye a világról. A termékmenedzserek teljesen mások, mint a projektmenedzserek. Az adminisztrátoroknak saját feladataik vannak. Meglehetősen nehéz feladattá válik az összes résztvevő koordinálása, hogy továbbra is tisztában legyünk azzal, mi történik, és ne őrüljünk meg. Külön kell választani a csoport és a mindenkire vonatkozó feladatokat. Ez nagyon nehéz feladat. Másrészt szerintem minden sokkal jobb, mint sok évvel ezelőtt volt. Pontosan ez az az út, amelyen az emberek felnőnek és megtanulnak helyesen viselkedni. Az integráció során megérted, hogy nem szabad underground fejlesztést végezni, hogy a legutolsó pillanatban ne mászzon ki a szoftver, mint egy jack-in-the-box: nézd, mit csináltunk itt! Az ötlet az, hogy képes leszel integrálni és fejleszteni, és a végén szépen és iteratív módon kigurulsz. Mindez nagyon sokat jelent nekem. Ez lehetővé teszi, hogy több értéket teremtsen a rendszer felhasználói és az Ön ügyfele számára.

Michael: A devops egész ötlete az, hogy a lehető legkorábban értelmes fejlesztéseket hozzon létre. Úgy látom, a világ egyre jobban felgyorsult. Hogyan lehet alkalmazkodni az ilyen gyorsulásokhoz? Tíz évvel ezelőtt ez nem létezett!

Tim: Természetesen mindenki egyre több funkcionalitásra vágyik. Nem kell mozdulni, csak halmozzon fel többet. Néha még lassítani is kell a következő fokozatos frissítéshez, hogy valami hasznosat hozzon – és ez teljesen normális.

Az az elképzelés, hogy futni, futni, futni kell, nem a legjobb. Nem valószínű, hogy bárki is így akarja leélni az életét. Szeretném, ha a szállítások ritmusa meghatározná a projekt saját ritmusát. Ha csak egy kis, viszonylag értelmetlen dolgok folyamát állítod elő, akkor az egésznek nincs értelme. Ahelyett, hogy ész nélkül próbálnánk kiadni a dolgokat a lehető legkorábban, érdemes megbeszélni a vezető fejlesztőkkel, termék- és projektmenedzserekkel a stratégiát. Van ennek egyáltalán értelme?

Minták és antiminták

Oleg: Általában mintákról és antimintákról beszélsz, és ez a különbség a projektek élete és halála között. És most a devops berobban az életünkbe. Van valami saját mintája és anti-mintája, ami a helyszínen megölheti a projektet?

Tim: Minták és anti-minták mindig előfordulnak. Valamiről beszélni. Nos, van ez a dolog, amit "fényes dolgoknak" hívunk. Az emberek nagyon-nagyon szeretik az új technológiát. Egyszerűen megbabonázza őket minden menőnek és stílusosnak tűnő fénye, és abbahagyják a kérdéseket: szükség van rá? Mit fogunk elérni? Megbízható ez a dolog, van valami értelme? Gyakran látok embereket, hogy úgy mondjam, a technológia élvonalában. Hipnotizálják őket, ami a világban történik. De ha jobban megnézi, milyen hasznos dolgokat csinálnak, gyakran egyszerűen nincs semmi hasznos!

Éppen arról beszélgettünk a bajtársainkkal, hogy az idei évfordulós év, ötven éve, hogy az emberek leszálltak a Holdra. Ez 1969-ben történt. A technológia, amely segített az embereknek eljutni oda, még csak nem is 1969-es technológia, hanem inkább 1960-as vagy 62-es, mert a NASA csak azt akarta felhasználni, ami jó bizonyítékkal rendelkezik a megbízhatóságról. És így nézel rá, és megérted – igen, és igazak voltak! No, nem, nem, de egyszerűen azért kerülsz problémákba a technológiával, mert mindent túlságosan nyomnak, és minden repedésből árulnak. Az emberek mindenhonnan azt kiabálják: „Nézd, micsoda dolog, ez a legújabb, a legszebb dolog a világon, abszolút mindenkinek megfelel!” Nos, ez az... általában ez az egész csak csalinak bizonyul, aztán az egészet ki kell dobni. Talán azért, mert már öreg ember vagyok, és nagy szkepticizmussal nézek az ilyen dolgokra, amikor az emberek elfogynak, és azt mondják, hogy megtalálták a legjobb technológiák létrehozásának egyetlen, leghelyesebb módját. Ebben a pillanatban egy hang ébred fel bennem, ami azt mondja: „Micsoda rendetlenség!”

Michael: Valóban, milyen gyakran hallottunk a következő ezüstgolyóról?

Tim: Pontosan, és ez a dolgok szokásos menete! Például... úgy tűnik, ez már vicc lett világszerte, de itt gyakran beszélnek a blockchain technológiáról. És valóban van értelme bizonyos helyzetekben! Ha valóban megbízható bizonyítékra van szüksége az eseményekről, arról, hogy a rendszer működik, és senki sem csalt meg minket, ha biztonsági problémái vannak, és mindezek keverednek, a blokkláncnak van értelme. De amikor azt mondják, hogy a Blockchain most végigsöpör a világon, és mindent elsöpör, ami az útjába kerül? Álmodj többet! Ez egy nagyon drága és összetett technológia. Technikailag bonyolult és időigényes. Beleértve tisztán algoritmikusan, minden alkalommal, amikor újra kell számolni a matematikát, a legkisebb változtatásokkal... és ez nagyszerű ötlet - de csak bizonyos esetekben. Egész életem és pályafutásom erről szólt: érdekes ötletek nagyon konkrét helyzetekben. Nagyon fontos, hogy pontosan megértsd, mi a helyzeted.

Michael: Igen, az élet, az univerzum és minden fő kérdése: ez a technológia vagy megközelítés alkalmas az Ön helyzetére vagy sem?

Tim: Ezt a kérdést már meg lehet vitatni a technológiai csoporttal. Esetleg még egy tanácsadót is hívj. Vessen egy pillantást a projektre, és értse meg – fogunk most valamit helyesen és hasznosan, jobban, mint korábban? Talán bejön, lehet, hogy nem. De ami a legfontosabb, alapértelmezés szerint ne hozzon ilyen döntést, egyszerűen azért, mert valaki kifakadt: „Nagyon szükségünk van egy blokkláncra! Most olvastam róla egy magazinban a repülőn!” Komolyan? Még csak nem is vicces.

A mitikus „devops mérnök”

Oleg: Most mindenki devopokat valósít meg. Valaki a devopokról olvas az interneten, holnap pedig újabb üresedés jelenik meg egy toborzó oldalon. "devops mérnök". Itt szeretném felhívni a figyelmet: Ön szerint ennek a „devops engineer” kifejezésnek joga van az élethez? Van egy olyan vélemény, hogy a devops egy kultúra, és itt valami nem jön össze.

Tim: Is-is. Ezután azonnal adjanak magyarázatot erre a kifejezésre. Valami, ami egyedivé teszi. Amíg be nem bizonyítják, hogy egy ilyen üresedés mögött valami egyedi képesség-kombináció áll, addig nem veszem meg! Úgy értem, nos, van egy beosztásunk, „devops mérnök”, érdekes cím, igen, mi lesz ezután? A munkakörök általában nagyon érdekesek. Tegyük fel, hogy „fejlesztő” – mi ez? A különböző szervezetek teljesen mást jelentenek. Egyes cégeknél jó minőségű programozók olyan teszteket írnak, amelyeknek több értelme van, mint más cégek speciális, professzionális tesztelői által írt teszteknek. Akkor most ők programozók vagy tesztelők?

Igen, vannak beosztásaink, de ha elég hosszan kérdezel, végül kiderül, hogy mindannyian problémamegoldók vagyunk. Mi megoldáskeresők vagyunk, és van, aki rendelkezik bizonyos technikai ismeretekkel, és van, aki másokkal. Ha olyan környezetben élsz, ahová a DevOps behatolt, akkor a fejlesztés és az adminisztráció integrálásával foglalkozol, és ennek a tevékenységnek van néhány meglehetősen fontos célja. De ha megkérdezik, mit csinálsz pontosan, és mi a felelős, kiderül, hogy az emberek időtlen idők óta csinálják mindezt. „Felelős vagyok az architektúráért”, „Felelős vagyok az adatbázisokért” és így tovább, bármi, látod – mindez a „devops” előtt volt.

Ha valaki elmondja a beosztását, nem nagyon figyelek rá. Jobb, ha hagyod, hogy elmondja, valójában mi a felelős, így sokkal jobban megértjük a kérdést. A kedvenc példám az, amikor valaki „projektmenedzser”-nek vallja magát. Mit? Ez nem jelent semmit, még mindig nem tudom, mit csinálsz. Projektmenedzser lehet fejlesztő, egy négyfős, kódot író, munkát végző csapat vezetője, aki csapatvezetővé vált, akit az emberek maguk is vezetőnek ismernek el. És a projektmenedzser lehet olyan menedzser is, aki hatszáz embert irányít egy projektben, más menedzsereket irányít, felelős az ütemezések összeállításáért és a költségvetések tervezéséért, ez minden. Ez két teljesen különböző világ! De a beosztásuk ugyanúgy hangzik.

Fordítsuk meg ezt egy kicsit másképp. Miben vagy igazán jó, sok tapasztalatod van, van tehetséged? Miért vállalja a felelősséget, mert úgy gondolja, hogy meg tudja oldani a feladatot? És itt valaki azonnal tagadni kezd: nem, nem, nem, egyáltalán nincs kedvem projekt erőforrásokkal foglalkozni, nem az én dolgom, én műszaki csávó vagyok, és értek a használhatósághoz és a felhasználói felületekhez, nem. egyáltalán emberseregeket akarok irányítani, inkább menjek dolgozni.

És mellesleg nagy híve vagyok egy olyan megközelítésnek, amelyben a készségek effajta szétválasztása jól működik. Ahol a technikusok ameddig akarják, addig bővíthetik karrierjüket. Azonban még mindig látok olyan szervezeteket, ahol a technikusok panaszkodnak: projektmenedzsmenttel kell foglalkoznom, mert ebben a cégben ez az egyetlen lehetőség. Néha ez szörnyű eredményekhez vezet. A legjobb technikusok egyáltalán nem jó menedzserek, a legjobb menedzserek pedig nem tudják kezelni a technológiát. Legyünk őszinték ezzel kapcsolatban.

Erre most úgy látom, nagy az igény. Ha technikus vagy, a céged segíthet, de ettől függetlenül meg kell találnod a saját karriered, mert a technológia folyamatosan változik, és ezzel együtt újra fel kell találnod magad! Alig húsz év alatt a technológiák legalább ötször változhatnak. Furcsa dolog a technológia...

"Szakértők mindenben"

Michael: Hogyan tudnak az emberek megbirkózni a technológiai változás ilyen sebességével? Bonyolultságuk növekszik, számuk növekszik, az emberek közötti kommunikáció összmennyisége is nő, és kiderül, hogy nem lehetsz „mindenben szakértő”.

Tim: Jobb! Ha a technológiával foglalkozol, igen, mindenképpen választanod kell valami konkrétat, és bele kell mélyedned. Néhány technológia, amelyet szervezete hasznosnak talál (és talán valóban hasznos lesz). És ha ez már nem érdekli - soha nem hittem volna, hogy ezt mondom -, akkor talán költözzön valami más szervezethez, ahol érdekesebb vagy kényelmesebb tanulni a technológiát.

De általánosságban igen, igazad van. A technológiák minden irányban egyszerre fejlődnek, senki sem mondhatja azt, hogy „szakértő technológus vagyok az összes létező technológiában”. Másrészt vannak szivacsemberek, akik szó szerint magukba szívják a technológiai tudást, és megőrülnek tőle. Láttam pár ilyen embert, szó szerint lélegzik és megélik, hasznos és érdekes velük beszélgetni. Nemcsak azt tanulmányozzák, hogy mi történik a szervezeten belül, hanem úgy általában, beszélnek róla, nagyon menő technológusok is, nagyon tudatosak és céltudatosak. Csak igyekeznek a hullám csúcsán maradni, függetlenül attól, hogy mi a fő munkájuk, mert szenvedélyük a Technológia mozgalma, a technológia népszerűsítése. Ha hirtelen találkozol egy ilyen emberrel, menj el vele ebédelni, és ebéd közben beszélgess meg különféle klassz dolgokat. Szerintem minden szervezetnek szüksége van legalább pár ilyen emberre.

Kockázatok és bizonytalanság

Michael: Tisztelt mérnökök, igen. Érintse meg a kockázatkezelést, amíg van időnk. Ezt az interjút az orvosi szoftverek megvitatásával kezdtük, ahol a hibák súlyos következményekkel járhatnak. Aztán a Holdprogramról beszéltünk, ahol egy hiba több millió dollárba, és esetleg több emberéletbe is kerül. De most az ellenkezőjét látom az iparágban, az emberek nem gondolnak a kockázatokra, nem próbálják megjósolni, nem is figyelik meg őket.

Oleg: Mozogj gyorsan és törd össze a dolgokat!

Michael: Igen, haladj gyorsan, törj össze dolgokat, egyre több dolgot, amíg meg nem halsz valamitől. Az Ön szemszögéből most hogyan viszonyuljon az átlagos fejlesztőnek a tanulási kockázatkezeléshez?

Tim: Itt húzzunk határt két dolog között: a kockázatok és a bizonytalanság között. Ezek különböző dolgok. A bizonytalanság akkor jelentkezik, ha adott időpontban nincs elegendő adat a végleges válasz meghozatalához. Például egy projekt nagyon korai szakaszában, ha valaki megkérdezi tőled, hogy „mikor fejezed be a munkát”, ha elég becsületes ember vagy, azt mondod: „Fogalmam sincs”. Csak nem tudod, és ez rendben van. Még nem tanulmányozta a problémákat, és nem ismeri a csapatot, nem ismeri a képességeiket stb. Ez bizonytalanság.

A kockázatok akkor merülnek fel, ha a lehetséges problémákat már azonosítani lehet. Megtörténhet ilyesmi, a valószínűsége nagyobb, mint nulla, de kevesebb, mint száz százalék, valahol a kettő között. Emiatt bármi megtörténhet, a késésektől és a felesleges munkától, de akár a projekt végzetes kimeneteléig is. A végeredmény, ha azt mondod – srácok, hajtsuk össze az esernyőinket és hagyjuk el a strandot, soha nem fogjuk befejezni, mindennek vége, pont. Feltételeztük, hogy ez a dolog működni fog, de egyáltalán nem működik, ideje abbahagyni. Ezek a helyzetek.

A problémákat gyakran akkor a legkönnyebb megoldani, amikor már felmerültek, amikor a probléma éppen most történik. De amikor egy probléma közvetlenül előtted van, akkor nem kockázatkezelést végez, hanem problémamegoldást, válságkezelést. Ha Ön vezető fejlesztő vagy menedzser, biztos azon töpreng, mi történhet, ami késésekhez, időpazarláshoz, szükségtelen költségekhez vagy az egész projekt összeomlásához vezethet? Mi késztet arra, hogy megálljunk és újra kezdjük? Ha ezek a dolgok működnek, mit fogunk csinálni velük? Van egy egyszerű válasz, amely a legtöbb helyzetre érvényes: ne menekülj a kockázatok elől, dolgozz rajtuk. Nézze meg, hogyan lehet egy kockázatos helyzetet megoldani, semmivé csökkenteni, problémából valami mássá tenni. Ahelyett, hogy azt mondanánk: nos, akkor megoldjuk a problémákat, ahogy felmerülnek.

Mindenben, amivel foglalkozol, a bizonytalanságnak és a kockázatnak kell állnia. Készíthet egy projekttervet, előre megnézhet bizonyos kritikus kockázatokat, és azt mondhatja: ezzel most foglalkoznunk kell, mert ha ezek közül bármelyik elromlik, semmi más nem számít. Nem kell aggódnia az asztalon lévő terítő szépsége miatt, ha nem világos, hogy meg tudja-e főzni a vacsorát. Először is meg kell határoznia az ízletes vacsora elkészítésének minden kockázatát, kezelnie kell őket, és csak ezután kell gondolnia minden olyan dologra, amely nem jelent valós veszélyt.

Még egyszer, mitől egyedi a projekted? Lássuk, mi okozhatja projektünket a sínekről. Mit tehetünk, hogy minimálisra csökkentsük ennek a valószínűségét? Általában nem lehet őket 100%-osan semlegesíteni, és tiszta lelkiismerettel kijelenteni: "Ennyi, ez már nem probléma, a kockázat megoldódott!" Számomra ez a felnőtt viselkedés jele. Ez a különbség egy gyerek és egy felnőtt között – a gyerekek azt hiszik, hogy halhatatlanok, semmi sem romolhat el, minden rendben lesz! Ugyanakkor a felnőttek figyelik, hogyan ugrálnak a hároméves gyerekek a játszótéren, követik a szemükkel a mozdulatokat, és azt mondják magukban: "ó-ó, óóó." A közelben állok, és készen állok arra, hogy elkapjam, amikor a gyerek leesik.

Másrészt azért szeretem annyira ezt az üzletet, mert kockázatos. Csinálunk dolgokat, és ezek kockázatosak. Felnőtt megközelítést igényelnek. A lelkesedés önmagában nem oldja meg a problémáit!

Felnőtt mérnöki gondolkodás

Michael: A gyerekek példája jó. Ha közönséges mérnök vagyok, akkor örülök, hogy gyerek lehetek. De hogyan lehet elmozdulni a felnőttesebb gondolkodás felé?

Tim: Az egyik olyan ötlet, amely egyformán jól működik akár egy kezdő, akár egy tapasztalt fejlesztő számára, az a kontextus fogalma. Mit teszünk, mit fogunk elérni. Mi az igazán fontos ebben a projektben? Nem számít, hogy ki vagy a projektben, akár gyakornok, akár főépítész, mindenkinek szüksége van kontextusra. Mindenkit rá kell késztetni arra, hogy nagyobb léptékben gondolkodjon, mint a saját munkája. „Készítem a darabomat, és amíg a darabom működik, boldog vagyok.” Nem és még egyszer nem. Mindig érdemes (anélkül, hogy durva lennénk!) emlékeztetni az embereket arra a kontextusra, amelyben dolgoznak. Amit mindannyian együtt próbálunk elérni. Ötletek, hogy lehetsz gyerek, amíg minden rendben van a projekteddel – kérlek, ne tedd. Ha egyáltalán átlépjük a célvonalat, akkor csak együtt haladunk át. Nem vagy egyedül, mind együtt vagyunk. Ha a projektben résztvevők, idősek és fiatalok is, arról kezdenének beszélni, hogy pontosan mi a fontos a projekt számára, miért fektet be pénzt a cég abba, amit mindannyian szeretnénk elérni... a legtöbbjük sokkal jobban érzi magát, mert látni fogja, hogy az ő munkájuk hogyan kapcsolódik mindenki más munkájához. Egyrészt értem azt a darabot, amiért személyesen felelős vagyok. De a munka befejezéséhez szükségünk van a többi emberre is. És ha tényleg úgy gondolja, hogy végzett, mindig van tennivalónk a projektben!

Oleg: Viszonylagosan elmondható, hogy ha Kanban szerint dolgozol, amikor valamilyen tesztelés szűk keresztmetszetébe ütközöl, akkor abbahagyhatod azt, amit ott csináltál (például programozást), és segíts a tesztelőknek.

Tim: Pontosan. Szerintem a legjobb technikusok, ha alaposan megnézzük őket, a maguk menedzserei. Hogyan fogalmazhatnám meg ezt...

Oleg: Az életed a te projekted, amit te irányítasz.

Tim: Pontosan! Úgy értem, vállalod a felelősséget, megérted a kérdést, és kapcsolatba lépsz az emberekkel, amikor látod, hogy a döntéseid befolyásolhatják a munkájukat, ilyesmi. Nem arról van szó, hogy csak ülsz az íróasztalodnál, végzed a dolgod, és még csak észre sem veszed, mi történik körülötted. Nem nem nem. Amúgy az egyik legjobb dolog az Agile-ben, hogy rövid sprinteket javasoltak, mert így minden résztvevő helyzete jól megfigyelhető, mindent együtt láthatnak. Minden nap beszélünk egymásról.

Hogyan lépjünk be a kockázatkezelésbe

Oleg: Van-e formális tudásstruktúra ezen a területen? Például Java fejlesztő vagyok, és szeretném megérteni a kockázatkezelést anélkül, hogy végzettségemből valódi projektmenedzserré válnék. Valószínűleg előbb elolvasom McConnell "Mennyibe kerül egy szoftverprojekt" című művét, aztán mi van? Mik az első lépések?

Tim: Az első az, hogy elkezd kommunikálni az emberekkel a projektben. Ez azonnali javulást jelent a kollégákkal való kommunikáció kultúrájában. Azzal kell kezdenünk, hogy alapértelmezés szerint mindent kinyitunk, ahelyett, hogy elrejtnénk. Mondd: ezek a dolgok zavarnak, ezek ébresztenek fel éjszaka, ma éjjel felébredtem, és azt mondtam: Istenem, ezen gondolkodnom kell! Mások is látják ugyanezt? Csoportként reagálnunk kell ezekre a lehetséges problémákra? Támogatnia kell a vitát ezekről a témákról. Nincs előre elkészített képlet, ami alapján dolgozunk. Nem a hamburger készítés a lényeg, hanem az emberek. A „sajtburgert készíteni, sajtburgert eladni” egyáltalán nem a mi dolgunk, és ezért szeretem annyira ezt a munkát. Szeretem, ha minden, amit korábban a menedzserek csináltak, most a csapat tulajdonába kerül.

Oleg: Könyvekben és interjúkban beszélt arról, hogy az emberek jobban törődnek a boldogsággal, mint a grafikonon szereplő számokkal. Másrészt, ha azt mondod a csapatnak: devops-ra költözünk, és most a programozónak folyamatosan kommunikálnia kell, ez messze kívül esik a komfortzónáján. És ebben a pillanatban, mondjuk, mélységesen boldogtalan lehet. Mi a teendő ebben a helyzetben?

Tim: Nem tudom pontosan mit tegyek. Ha egy fejlesztő túlságosan elszigetelt, akkor nem látja, hogy miért végzik el a munkát, csak a munka saját részét nézik, és bele kell kerülniük abba, amit én "kontextusnak" nevezek. Ki kell találnia, hogyan kapcsolódik minden egymáshoz. És persze nem a formális előadásokra vagy ilyesmire gondolok. Arról beszélek, hogy a munka egészéről kell kommunikálnia a kollégákkal, nem csak arról a részről, amelyért felelős. Itt kezdheti meg az ötletek, a közös megegyezések megbeszélését, hogy a munkája jól illeszkedjen egymáshoz, és hogyan lehet közösen kezelni egy közös problémát.

Az alkalmazkodás elősegítése érdekében gyakran technikusokat akarnak képzésre küldeni, és megbeszélik a képzést. Egy barátom szereti azt mondani, hogy a tréning kutyáknak való. Van képzés az embereknek. A fejlesztői tanulásban az egyik legjobb dolog a társaival való interakció. Ha valaki valamiben nagyon jó, akkor nézze meg a munkáját, vagy beszéljen vele a munkájáról vagy valamiről. Néhány hagyományos Kent Beck állandóan az extrém programozásról beszélt. Vicces, mert az XP olyan egyszerű ötlet, de annyi problémát okoz. Egyesek számára XP-t csinálni olyan, mintha arra kényszerülnének, hogy meztelenre vetkőzzenek a barátok előtt. Majd meglátják, mit csinálok! Ők a kollégáim, nem csak látják, hanem megértik is! Szörnyű! Vannak, akik kezdenek komolyan ideges lenni. De amikor rájössz, hogy ez a tanulás végső módja, minden megváltozik. Szorosan együttműködik az emberekkel, és vannak, akik sokkal jobban értik a témát, mint te.

Michael: De mindez arra kényszerít, hogy kilépj a komfortzónádból. Mérnökként ki kell lépnie a komfortzónájából, és kommunikálnia kell. Problémamegoldóként folyamatosan gyenge helyzetbe kell hoznia magát, és azon kell gondolkodnia, hogy mi ronthat el. Ez a fajta munka eredendően zavaró. Tudatosan helyezed magad stresszes helyzetekbe. Általában az emberek menekülnek előlük, szeretnek boldog gyerekek lenni.

Tim: Amit megtehetsz, kijöhetsz és nyíltan elmondhatod: „Minden rendben, bírom! Nem én vagyok az egyetlen, aki kényelmetlenül érzi magát. Beszéljünk meg különféle kellemetlen dolgokat együtt, csapatban!” Ezek a közös problémáink, meg kell küzdenünk velük, tudod? Szerintem az egyedi zseniális fejlesztők olyanok, mint a mamutok, eltűntek. És jelentőségük nagyon korlátozott. Ha nem tudsz kommunikálni, nem tudsz jól részt venni. Ezért csak beszéljen. Légy őszinte és nyitott. Nagyon sajnálom, hogy ez valakinek kellemetlen. El tudod képzelni, sok évvel ezelőtt volt egy tanulmány, amely szerint az Egyesült Államokban nem a halál a fő félelem, de mit gondol? Félelem a nyilvános beszédtől! Ez azt jelenti, hogy valahol vannak olyan emberek, akik inkább meghalnak, mintsem hangosan bókot mondanak. És szerintem elég, ha rendelkezel néhány alapkészséggel, attól függően, hogy mit csinálsz. Beszédkészség, íráskészség – de csak annyi, amennyi a munkád során valóban szükséges. Ha elemzőként dolgozik, de nem tud olvasni, írni vagy beszélni, akkor sajnos semmi köze a projektjeimhez!

A kommunikáció ára

Oleg: Nem drágább az ilyen távozó alkalmazottak alkalmazása különböző okok miatt? Hiszen munka helyett állandóan chatelnek!

Tim: A csapat magjára gondoltam, és nem csak mindenkire. Ha van valaki, aki nagyon ügyes az adatbázisok tuningolásában, szereti az adatbázisok hangolását, és élete végéig folytatni fogja az adatbázisok hangolását, és ennyi, akkor menjen, csak így tovább. De azokról az emberekről beszélek, akik magában a projektben akarnak élni. A csapat magja, amelynek célja a projekt fejlesztése. Ezeknek az embereknek valóban folyamatosan kommunikálniuk kell egymással. És különösen a projekt elején, amikor megvitatják a kockázatokat, a globális célok elérésének módjait és hasonlókat.

Michael: Ez mindenkire vonatkozik, aki részt vesz a projektben, függetlenül a szakterülettől, készségektől vagy munkamódszerektől. Mindannyian érdeklődnek a projekt sikerében.

Tim: Igen, úgy érzed, hogy kellőképpen elmerültél a projektben, az a feladatod, hogy segítsd a projekt megvalósulását. Legyen Ön programozó, elemző, interfész tervező, bárki. Ez az oka annak, hogy minden reggel dolgozni jövök, és ezt csináljuk. Felelősséggel tartozunk ezekért az emberekért, függetlenül a képességeiktől. Ez egy olyan embercsoport, akik felnőttekkel beszélgetnek.

Oleg: Valójában, ha a beszédes alkalmazottakról beszélünk, megpróbáltam szimulálni azoknak az embereknek, különösen a menedzsereknek az ellenvetéseit, akiket arra kérnek, hogy váltsanak devopokra, ezzel a teljesen új világlátással szemben. És önnek, mint tanácsadónak sokkal jobban tisztában kell lennie ezekkel a kifogásokkal, mint nekem, mint fejlesztőnek! Ossza meg, mi aggasztja leginkább a vezetőket?

Tim: Menedzserek? Hm. Leggyakrabban a menedzserekre nyomás nehezedik a problémák miatt, és szembe kell nézniük azzal, hogy sürgősen el kell engedniük valamit, kézbesíteni kell, és hasonlók. Azt nézik, hogyan vitatkozunk és vitatkozunk folyamatosan valamiről, és ezt így látják: beszélgetések, beszélgetések, beszélgetések... Milyen beszélgetések még? Menj vissza dolgozni! Mert a beszélgetést nem érzik munkának. Nem ír kódot, nem tesztel szoftvert, úgy tűnik, nem csinál semmit – miért nem küldi el, hogy csináljon valamit? Hiszen a szállítás már egy hónap múlva!

Michael: Írj egy kódot!

Tim: Nekem úgy tűnik, hogy nem a munka miatt aggódnak, hanem a haladás láthatóságának hiánya miatt. Ahhoz, hogy úgy tűnjön, egyre közelebb kerülünk a sikerhez, látniuk kell, hogy nyomogatjuk a billentyűzet gombjait. Egész nap reggeltől estig. Ez az első számú probléma.

Oleg: Misha, gondolsz valamire.

Michael: Bocsánat, elmerültem a gondolataimban, és visszaemlékeztem. Mindez egy érdekes tüntetésre emlékeztetett, ami tegnap történt... Túl sok volt a tegnapi gyűlés... És mindez nagyon ismerősen hangzik!

Élet fizetés nélkül

Tim: A kommunikációhoz egyébként egyáltalán nem szükséges „gyűléseket” szervezni. Úgy értem, a leghasznosabb megbeszélések a fejlesztők között akkor történnek, amikor csak beszélgetnek egymással. Reggel bemész egy csésze kávéval, és öten összegyűlnek, és dühösen megbeszélnek valami technikai dolgot. Nekem, ha én vagyok ennek a projektnek a menedzsere, jobb, ha csak mosolyogok, és elmegyek valahova a dolgom miatt, hadd beszéljék meg. Már a lehetőségekhez mérten részt vesznek. Ez jó jel.

Oleg: Egyébként a könyvedben van egy csomó megjegyzésed arról, hogy mi a jó és mi a rossz. Te magad használod valamelyiket? Viszonylagosan szólva, most van egy céged, és egy nagyon rendhagyó módon felépített...

Tim: Unortodox, de nekünk ez a készülék tökéletesen megfelel. Régóta ismerjük egymást. Bízunk egymásban, nagyon bíztunk egymásban, mielőtt partnerek lettünk. És például egyáltalán nincs fizetésünk. Mi csak dolgozunk, és ha például pénzt kerestem az ügyfeleimtől, akkor az összes pénz rám ment. Ezt követően tagdíjat fizetünk a szervezetnek, ez pedig elegendő magának a társaságnak a támogatására. Ráadásul mindannyian különböző dolgokra specializálódtunk. Például könyvelőkkel dolgozom, adóbevallásokat töltök ki, mindenféle adminisztrációt végzek a cégnek, és senki nem fizet érte. James és Tom a weboldalunkon dolgoznak, és senki sem fizet nekik. Amíg fizeted a járulékot, senkinek nem jut eszébe, hogy megmondja, mit kell tenned. Például Tom most sokkal kevesebbet dolgozik, mint korábban. Most más érdekei vannak; bizonyos dolgokat nem a Céh számára csinál. De amíg fizeti a járulékát, senki nem fog odajönni hozzá és azt mondani: „Hé, Tom, menj dolgozni!” Nagyon könnyű elbánni a kollégákkal, ha nincs pénz köztetek. És most a kapcsolatunk az egyik alapgondolat a különböző szakterületekkel kapcsolatban. Működik és nagyon jól működik.

A legjobb tanács

Michael: Visszatérve a „legjobb tanácsra”: van valami, amit újra és újra elmondasz ügyfeleidnek? Van egy elképzelés a 80/20-ról, és néhány tanácsot valószínűleg gyakrabban ismételnek meg.

Tim: Egyszer azt hittem, hogy ha írsz egy olyan könyvet, mint a Keringős medvék, az megváltoztatná a történelem menetét, és az emberek megállnának, de... Nos, nézd, a cégek gyakran úgy tesznek, mintha minden rendben lenne velük. Amint valami rossz történik, az sokk és meglepetés számukra. „Nézd, teszteltük a rendszert, és nem megy át semmilyen rendszerteszten, és ez egy újabb három hónapos előre nem tervezett munka, hogyan történhetett ez meg? Aki tudta? Mi romolhat el? Komolyan, elhiszed ezt?

Azt próbálom elmagyarázni, hogy nem szabad túlságosan dühösnek lenni a jelenlegi helyzet miatt. Meg kell beszélnünk, valóban meg kell értenünk, mi romolhatott el, és hogyan lehet megakadályozni, hogy ilyen dolgok a jövőben megtörténjenek. Ha megjelenik egy probléma, hogyan küzdjünk ellene, hogyan tudjuk megfékezni?

Számomra ez az egész ijesztőnek tűnik. Az emberek összetett, bosszantó problémákkal küzdenek, és továbbra is úgy tesznek, mintha csak összefonják az ujjaikat, és a legjobbat remélik, a „legjobb” valóban megtörténik. Nem, ez nem így működik.

Gyakorold a kockázatkezelést!

Michael: Ön szerint hány szervezet foglalkozik kockázatkezeléssel?

Tim: Engem az dühít, hogy az emberek egyszerűen felírják a kockázatokat, megnézik a listát, és mennek dolgozni. Valójában a kockázatok azonosítása számukra kockázatkezelés. De számomra ez okként hangzik, hogy megkérdezzem: oké, van egy lista, pontosan min változtatsz? Ezeket a kockázatokat figyelembe véve módosítania kell a szokásos műveleti sorrendet. Ha van a munka legnehezebb része, akkor meg kell oldania, és csak ezután térjen át valami egyszerűbbre. Az első sprintekben kezdje el összetett problémák megoldását. Ez már kockázatkezelésnek tűnik. De az emberek általában nem tudják megmondani, mit változtattak a kockázatok listájának összeállítása után.

Michael: És mégis, hány ilyen cég foglalkozik kockázatkezeléssel, öt százalék?

Tim: Sajnos nem szeretem ezt kimondani, de ez egy nagyon jelentéktelen rész. De több mint öt, mert vannak igazán nagy projektek, és egyszerűen nem létezhetnek, ha nem tesznek legalább valamit. Mondjuk nagyon meg fogok lepődni, ha legalább 25%. A kis projektek általában így válaszolnak az ilyen kérdésekre: ha minket érint a probléma, akkor mi megoldjuk. Ezután sikeresen bajba keverik magukat, és belefognak a probléma- és válságkezelésbe. Ha megpróbálsz megoldani egy problémát, de a probléma nem oldódik meg, üdvözöljük a válságkezelésben.

Igen, gyakran hallom, hogy „megoldjuk a problémákat, amint felmerülnek”. Biztosan fogunk? Tényleg döntünk?

Oleg: Megteheti naivan, és egyszerűen beírhatja a fontos invariánsokat a projekt chartába, és ha az invariánsok megszakadnak, csak indítsa újra a projektet. Nagyon piembuckyra sikeredett.

Michael: Igen, megtörtént velem, hogy amikor a kockázatok kiváltottak, egyszerűen újradefiniálták a projektet. Szép, bingó, probléma megoldva, ne aggódj tovább!

Tim: Nyomjuk meg a reset gombot! Nem, ez nem így működik.

Keynote a DevOops 2019-en

Michael: Elérkeztünk az interjú utolsó kérdéséhez. A következő DevOopshoz jössz egy vitaindítóval. Fel tudnád emelni a titokzatos függönyt, hogy mit fogsz elmondani?

Tim: Jelenleg hatan írnak könyvet a munkakultúráról, a szervezetek kimondatlan szabályairól. A kultúrát a szervezet alapértékei határozzák meg. Általában ezt nem veszik észre az emberek, de miután hosszú évek óta dolgozunk a tanácsadásban, megszoktuk, hogy ezt észrevesszük. Belépsz egy társaságba, és szó szerint néhány percen belül kezded érezni, mi történik. Ezt "íznek" hívjuk. Néha nagyon jó ez az illat, néha pedig, hopp, hopp. A dolgok nagyon eltérőek a különböző szervezeteknél.

Michael: Én is évek óta tanácsadással foglalkozom, és jól értem, miről beszélsz.

Tim: Valójában az egyik dolog, amiről érdemes beszélni a vitaindítón, hogy nem mindent a cég határoz meg. Önnek és csapatának, mint közösségnek megvan a maga csapatkultúrája. Ez lehet az egész cég, vagy egy külön részleg, egy külön csapat. De mielőtt azt mondtad volna, itt van, amiben hiszünk, ez a fontos... Nem változtathatsz meg egy kultúrát addig, amíg meg nem érted a konkrét cselekedetek mögött rejlő értékeket és hiedelmeket. A viselkedést könnyű megfigyelni, de a hiedelmek után kutatni nehéz. A DevOps csak egy nagyszerű példa arra, hogy a dolgok egyre bonyolultabbá válnak. Az interakciók csak egyre összetettebbek, egyáltalán nem tisztábbak vagy tisztábbak, ezért érdemes végiggondolnod, miben hiszel, és miről hallgat körülötted mindenki.

Ha gyors eredményeket szeretne elérni, itt van egy jó téma: látott már olyan cégeket, ahol senki nem mondja, hogy „nem tudom”? Vannak helyek, ahol szó szerint addig kínoznak egy embert, amíg be nem vallja, hogy nem tud valamit. Mindenki mindent tud, mindenki hihetetlen művelt. Bármely emberhez fordulsz, és neki azonnal válaszolnia kell a kérdésre. Ahelyett, hogy azt mondaná: „Nem tudom”. Hurrá, felvettek egy csomó eruditát! És bizonyos kultúrákban általában nagyon veszélyes azt mondani, hogy „nem tudom”, ez a gyengeség jeleként fogható fel. Vannak olyan szervezetek is, amelyekben éppen ellenkezőleg, mindenki azt mondhatja, hogy „nem tudom”. Ott ez teljesen legális, és ha valaki egy kérdésre válaszolva szemétkedni kezd, teljesen normális azt válaszolni: "Nem tudod, miről beszélsz, igaz?" és viccsé változtatja az egészet.

Ideális esetben olyan munkahelyet szeretne, ahol állandóan boldog lehet. Nem lesz könnyű, nem minden nap süt és kellemes, néha keményen kell dolgozni, de amikor elkezded mérlegelni, akkor kiderül: hú, ez egy igazán csodálatos hely, jól érzem magam itt dolgozni, érzelmileg és intellektuálisan egyaránt. És vannak olyan cégek, ahol tanácsadónak mész, és azonnal rájössz, hogy három hónapig nem bírod ki, és rémülten elmenekülnél. Erről szeretnék beszélni a jelentésben.

Tim Lister vitaindítóval érkezik "Karakterek, közösség és kultúra: a jólét fontos tényezői"a DevOops 2019 konferenciára, amelyre 29. október 30-2019-án kerül sor Szentpéterváron. Jegyeket vásárolhat a hivatalos weboldalon. Várunk benneteket a DevOopsban!

Forrás: will.com