Tim Lister - kunaŭtoro de libroj

• "Homa faktoro. Sukcesaj Projektoj kaj Teamoj" (la origina libro nomiĝas "Peopleware")
• "Valso kun la Ursoj: Administrado de Risko en Programaro-Projektoj"
• “Adrenalino-frenezigita kaj zombigita de ŝablonoj. Ŝablonoj de konduto de projektteamoj"

Ĉiuj ĉi tiuj libroj estas klasikaj en sia kampo kaj estis skribitaj kune kun kolegoj en Atlantic Systems Gildo. En Rusio, liaj kolegoj estas plej famaj - Tom DeMarco и Petro Hruschka, kiu verkis ankaŭ multajn famajn verkojn.

Tim havas 40 jarojn da sperto pri programaro en 1975 (neniu el tiuj kiuj skribis ĉi tiun habrapost naskiĝis ĉi-jare), Tim jam estis la plenuma vicprezidanto de Yourdon Inc. Li nun pasigas sian tempon konsultante, instruante kaj skribante, kun fojaj vizitoj al kun raportoj konferencoj tra la mondo.

Ni faris intervjuon kun Tim Lister precipe por Habr. Li malfermos la konferencon DevOops 2019, kaj ni havas multajn demandojn, pri libroj kaj pli. La intervjuo estas farita de Miĥail Druzhinin kaj Oleg Ĉiruĥin el la konferenca programo-komitato.

Mikaelo: Ĉu vi povas diri kelkajn vortojn pri tio, kion vi faras nun?

Tim: Mi estas la estro de la Atlantika Sistemo-Gildo. Estas ses el ni en la Gildo, ni nomas nin rektoroj. Tri en Usono kaj tri en Eŭropo - tial la Gildo nomiĝas Atlantiko. Ni estas kune dum tiom da jaroj, ke vi simple ne povas kalkuli ilin. Ni ĉiuj havas niajn specialaĵojn. Mi laboris kun klientoj dum la lasta jardeko aŭ pli. Miaj projektoj inkluzivas ne nur administradon, sed ankaŭ agordon de postuloj, projektplanadon kaj taksadon. Ŝajnas, ke projektoj, kiuj komenciĝas malbone, kutime malbone finiĝas. Tial indas certigi, ke ĉiuj agadoj estas vere bone pripensitaj kaj kunordigitaj, ke la ideoj de la kreintoj estas kombinitaj. Indas pensi pri tio, kion vi faras kaj kial. Kiajn strategiojn uzi por plenumi la projekton.

Mi konsilas klientojn en diversaj manieroj dum multaj jaroj. Interesa ekzemplo estas firmao kiu faras robotojn por genuo kaj kokso-kirurgio. La kirurgo ne funkcias tute sendepende, sed uzas roboton. Sekureco ĉi tie, sincere parolante, estas grava. Sed kiam vi provas diskuti postulojn kun homoj, kiuj fokusiĝas al solvado de problemoj... Ĝi sonos strange, sed en Usono ekzistas FDA (Federacia Drug Administration), kiu licencas produktojn kiel ĉi tiuj robotoj. Antaŭ ol vi vendas ion kaj uzas ĝin sur vivantaj homoj, vi devas akiri permesilon. Unu el la kondiĉoj estas montri viajn postulojn, kiaj estas la testoj, kiel vi testis ilin, kiaj estas la testrezultoj. Se vi ŝanĝas la postulojn, tiam vi devas trairi ĉi tiun tutan grandegan testan procezon denove kaj denove. Niaj klientoj sukcesis inkluzivi vidan dezajnon de aplikoj en siaj postuloj. Ili havis ekrankopiojn rekte kiel parto de la postuloj. Ni devas eltiri ilin kaj klarigi, ke plejparte ĉiuj ĉi tiuj programoj scias nenion pri genuoj kaj koksoj, ĉiuj ĉi aferoj per la fotilo, ktp. Ni devas reverki la postuldokumentojn por ke ili neniam ŝanĝu, krom se iuj vere gravaj subaj kondiĉoj ŝanĝiĝas. Se vida dezajno ne estas en la postuloj, ĝisdatigi la produkton estos multe pli rapida. Nia tasko estas trovi tiujn elementojn, kiuj traktas operaciojn sur la genuo, koksoj, dorso, eltiri ilin en apartajn dokumentojn kaj diri, ke ĉi tiuj estos la fundamentaj postuloj. Ni faru izolitan grupon de postuloj pri genuaj operacioj. Ĉi tio permesos al ni konstrui pli stabilan aron de postuloj. Ni parolos pri la tuta produktserio, kaj ne pri specifaj robotoj.

Multe da laboro estis farita, sed ili ankoraŭ atingis lokojn, kie antaŭe ili pasigis semajnojn kaj monatojn da ripetaj provoj sen signifo aŭ bezono, ĉar iliaj postuloj priskribitaj surpapere ne koincidis kun la realaj postuloj, por kiuj la sistemoj estis konstruitaj. La FDA diris al ili ĉiufoje: viaj postuloj ŝanĝiĝis, nun vi devas kontroli ĉion de nulo. Kompletaj rekontroloj de la tuta produkto mortigis la entreprenon.

Do, estas tiaj mirindaj taskoj kiam vi trovas vin ĉe la komenco de io interesa, kaj la plej unuaj agoj starigas la pliajn regulojn de la ludo. Se vi certigas, ke ĉi tiu frua agado ekfunkciu bone de kaj administra kaj teknika vidpunkto, estas ŝanco, ke vi finiĝos kun bonega projekto. Sed se ĉi tiu parto deturniĝis kaj iris ien malbone, se vi ne povas trovi la fundamentajn interkonsentojn... ne, ne estas ke via projekto nepre malsukcesos. Sed vi ne plu povos diri: "Ni bonege faris, ni faris ĉion vere efike." Ĉi tiuj estas la aferoj, kiujn mi faras kiam mi komunikas kun klientoj.

Mikaelo: Tio estas, ĉu vi lanĉas projektojn, faras ian piedbaton kaj kontrolas, ke la reloj iras en la ĝustan direkton?

Tim: Ni ankaŭ havas ideojn pri kiel kunmeti ĉiujn pecojn de la enigmo: kiajn kapablojn ni bezonas, kiam precize ili estas bezonataj, kia aspektas la kerno de la teamo kaj aliaj tiaj fundamentaj aferoj. Ĉu ni bezonas plentempajn dungitojn aŭ ĉu ni povas dungi iun partatempe? Planado, administrado. Demandoj kiel: Kio estas plej grava por ĉi tiu aparta projekto? Kiel atingi ĉi tion? Kion ni scias pri ĉi tiu produkto aŭ projekto, kiaj estas la riskoj kaj kie kuŝas la nekonatoj, kiel ni traktos ĉion ĉi? Kompreneble, en ĉi tiu momento iu komencas krii "Kion pri lerta?!" Bone, vi ĉiuj estas flekseblaj, sed kio? Kiel precize aspektas la projekto, kiel vi elprenos ĝin en maniero konforma al la projekto? Vi ne povas simple diri, ke "nia aliro etendiĝas al io ajn, ni estas Scrum-teamo!" Ĉi tio estas sensencaĵo kaj sensencaĵo. Kien vi tuj iros, kial ĝi funkciu, kie estas la celo? Mi instruas miajn klientojn pensi pri ĉiuj ĉi tiuj demandoj.

19 jaroj da lerta

Mikaelo: En Agile, homoj ofte provas ne difini ion anticipe, sed fari decidojn kiel eble plej malfrue, dirante: ni estas tro grandaj, mi ne pensos pri la ĝenerala arkitekturo. Mi ne pensos pri amaso da aliaj aferoj anstataŭe, mi liveros ion kiu funkcias al la kliento ĝuste nun.

Tim: Mi pensas, ke lertaj metodikoj, komencante Agra Manifesto en 2001, malfermis la okulojn de la industrio. Sed aliflanke, nenio estas perfekta. Mi estas tute por ripeta evoluo. Iteracio havas multan sencon en plej multaj projektoj. Sed la demando, pri kiu vi devas pensi, estas: kiam la produkto estas ekstere kaj uzata, kiom longe ĝi daŭras? Ĉu ĉi tio estas produkto kiu daŭros ses monatojn antaŭ ol esti anstataŭigita per io alia? Aŭ ĉu ĉi tio estas produkto kiu funkcios dum multaj, multaj jaroj? Kompreneble, mi ne nomos nomojn, sed... En Novjorko kaj ĝia financa komunumo, la plej fundamentaj sistemoj estas tre malnovaj. Ĉi tio estas mirinda. Vi rigardas ilin kaj pensas, se vi nur povus reiri en la tempo, al 1994, kaj diri al la programistoj: "Mi venis de la estonteco, de 2019. Nur disvolvu ĉi tiun sistemon tiom longe kiom vi bezonas. Faru ĝin ekspansiebla, pensu pri la arkitekturo. Ĝi tiam estos plibonigita dum pli ol dudek kvin jaroj. Se vi prokrastos iom pli longe evoluon, en la grandioza skemo de aferoj neniu rimarkos!" Kiam vi taksas aferojn longtempe, vi devas konsideri kiom ĝi kostos entute. Foje bone desegnita arkitekturo vere valoras ĝin, kaj foje ne. Ni devas ĉirkaŭrigardi kaj demandi nin: ĉu ni estas en la ĝusta situacio por tia decido?

Do ideo kiel "Ni estas por lertaj, la kliento mem diros al ni kion li volas akiri" - ĝi estas super naiva. Klientoj eĉ ne scias, kion ili volas, kaj eĉ pli do ili ne scias, kion ili povus akiri. Kelkaj homoj komencos citi historiajn ekzemplojn kiel argumentojn, mi jam vidis tion. Sed teknike progresintaj homoj ne kutime diras tion. Ili diras: "Estas 2019, ĉi tiuj estas la ŝancoj, kiujn ni havas, kaj ni povas tute ŝanĝi la manieron kiel ni rigardas ĉi tiujn aferojn!" Anstataŭ imiti ekzistantajn solvojn, farante ilin iom pli belaj kaj kombitaj, foje vi devas eliri kaj diri: "Ni tute reinventu tion, kion ni provas fari ĉi tie!"

Kaj mi ne pensas, ke la plej multaj klientoj povas pensi pri la problemo tiel. Ili vidas nur tion, kion ili jam havas, jen ĉio. Post tio ili venas kun petoj kiel "ni simpligu ĉi tion" aŭ kion ajn ili kutime diras. Sed ni ne estas kelneroj aŭ kelneroj, do ni povas preni mendon kiel ajn stulta ĝi rezultas kaj poste baki ĝin en la kuirejo. Ni estas iliaj gvidantoj. Ni devas malfermi iliajn okulojn kaj diri: hej, ni havas novajn ŝancojn ĉi tie! Ĉu vi rimarkas, ke ni vere povas ŝanĝi la manieron kiel ĉi tiu parto de via komerco estas farita? Unu el la problemoj kun Agile estas ke ĝi forigas la konscion pri kio estas ŝanco, kio estas problemo, kion ni eĉ bezonas fari, kiaj disponeblaj teknologioj plej taŭgas por ĉi tiu aparta situacio.

Eble mi estas tro skeptika ĉi tie: okazas multaj mirindaĵoj en la lerta komunumo. Sed mi havas problemon pri tio, ke anstataŭ difini projekton, homoj komencas levi la manojn. Mi demandus ĉi tie - kion ni faras, kiel ni faros ĝin? Kaj iel magie ĉiam rezultas, ke la kliento devus scii pli bone ol iu ajn. Sed la kliento scias plej bone nur kiam li elektas el aferoj jam konstruitaj de iu. Se mi volas aĉeti aŭton kaj mi scias la grandecon de mia familia buĝeto, tiam mi rapide elektos aŭton, kiu konvenas al mia vivstilo. Ĉi tie mi scias ĉion pli bone ol iu ajn! Sed bonvolu noti, ke iu jam faris la aŭtojn. Mi ne scias kiel inventi novan aŭton, mi ne estas fakulo. Kiam ni kreas kutimajn aŭ specialajn produktojn, oni devas konsideri la voĉon de la kliento, sed ĉi tiu ne plu estas la sola voĉo.

Oleg: Vi menciis la Agile Manifeston. Ĉu ni bezonas iel ĝisdatigi aŭ revizii ĝin konsiderante la modernan komprenon de la afero?

Tim: Mi ne tuŝus lin. Mi pensas, ke ĝi estas bonega historia dokumento. Mi volas diri, li estas tia, kia li estas. Li fariĝas 19-jara, li estas maljuna, sed siatempe li faris revolucion. Kion li bone faris estis ke li ekigis reagon kaj homoj komencis flustri pri li. Vi, plej verŝajne, ankoraŭ ne laboris en la industrio en 2001, sed tiam ĉiuj laboris laŭ procezoj. Software Engineering Institute, kvin niveloj de la programara kompleteca modelo (CMMI). Mi ne scias, ĉu tiaj legendoj de profunda antikva tempo rakontas al vi ion, sed tiam ĝi estis trarompo. Komence homoj kredis, ke se la procezoj estus ĝuste aranĝitaj, tiam la problemoj malaperus memstare. Kaj tiam venas la Manifesto kaj diras: "Ne, ne, ne - ni estos bazitaj sur homoj, ne procezoj." Ni estas majstroj pri programaro-disvolviĝo. Ni komprenas, ke la ideala procezo estas miraĝo, ĝi ne okazas. Estas tro da idiosinkrazio en projektoj, la ideo de unu sola perfekta procezo por ĉiuj projektoj ne havas neniun sencon. La problemoj estas tro kompleksaj por aserti, ke ekzistas nur unu solvo al ĉio (saluton, nirvano).

Mi ne supozas rigardi en la estontecon, sed mi diros, ke homoj nun komencis pensi pli pri projektoj. Mi pensas, ke la Agile Manifesto tre kapablas elsalti kaj diri: “Hej! Vi estas sur ŝipo, kaj vi mem veturas ĉi tiun ŝipon. Vi devos fari decidon - ni ne proponos universalan recepton por ĉiuj situacioj. Vi estas la skipo de la ŝipo, kaj se vi estas sufiĉe bona, vi povas trovi vojon al la celo. Estis aliaj ŝipoj antaŭ vi, kaj estos aliaj ŝipoj post vi, sed tamen, iusence, via vojaĝo estas unika.” Io simila! Ĝi estas pensmaniero. Por mi, estas nenio nova sub la suno, homoj antaŭe navigis kaj denove navigos, sed por vi ĉi tio estas via ĉefa vojaĝo, kaj mi ne diros al vi, kio precize okazos al vi. Vi devas havi la kapablojn de kunordigita laboro en teamo, kaj se vi vere havas ilin, ĉio funkcios kaj vi atingos kien vi volis.

Peopleware: 30 jarojn poste

Oleg: Ĉu Peopleware estis revolucio same kiel la Manifesto?

Tim: Homoj... Tom kaj mi skribis ĉi tiun libron, sed ni ne pensis, ke ĝi okazos tiel. Iel ĝi resonis kun multaj ideoj de homoj. Ĉi tiu estis la unua libro, kiu diris: programaro-disvolviĝo estas tre homintensa agado. Malgraŭ nia teknika naturo, ni ankaŭ estas komunumo de homoj konstruantaj ion grandan, eĉ grandegan, tre kompleksan. Neniu povas krei tiajn aferojn sole, ĉu ne? Do la ideo de "teamo" fariĝis tre grava. Kaj ne nur el administra vidpunkto, sed ankaŭ por teknikaj homoj, kiuj kuniĝis por solvi vere kompleksajn profundajn problemojn kun amaso da nekonataĵoj. Por mi persone, ĉi tio estis grandega provo de inteligenteco dum mia kariero. Kaj ĉi tie vi devas povi diri: jes, ĉi tiu problemo estas pli ol mi mem povas trakti, sed kune ni povas trovi elegantan solvon, pri kiu ni povas fieri. Kaj mi pensas, ke estis ĉi tiu ideo, kiu plej resonis. La ideo ke ni laboras parto de la tempo memstare, parto de la tempo kiel parto de grupo, kaj ofte la decido estas farita de la grupo. Solvo de grupaj problemoj rapide fariĝis grava trajto de kompleksaj projektoj.

Malgraŭ tio, ke Tim donis grandegan nombron da paroladoj, tre malmultaj el ili estas afiŝitaj en Jutubo. Vi povas rigardi la raporton "La Reveno de Peopleware" el 2007. La kvalito, kompreneble, lasas multon por deziri.

Mikaelo: Ĉu io ŝanĝiĝis en la lastaj 30 jaroj de kiam la libro estis eldonita?

Tim: Vi povas rigardi ĉi tion el multaj malsamaj anguloj. Sociologie parolante... iam, en pli simplaj tempoj, vi kaj via teamo sidis en la sama oficejo. Vi povus esti proksima ĉiutage, trinki kafon kune kaj diskuti laboron. Kio vere ŝanĝiĝis estas, ke teamoj nun povas esti distribuitaj geografie, en malsamaj landoj kaj horzonoj, sed tamen ili laboras pri la sama problemo, kaj tio aldonas tute novan tavolon de komplekseco. Ĉi tio povas soni malnovlerneja, sed ekzistas nenio kiel vizaĝ-al-vizaĝa komunikado kie vi ĉiuj estas kune, kunlaborante, kaj vi povas iri al kolego kaj diri, rigardu, kion mi malkovris, kiel vi ŝatas ĉi tion? Vizaĝ-al-vizaĝaj konversacioj disponigas rapidan manieron transiri al neformala komunikado, kaj mi pensas, ke ankaŭ lertaj entuziasmuloj devus ŝati ĝin. Kaj mi ankaŭ maltrankviliĝas ĉar fakte la mondo montriĝis tre malgranda, kaj nun ĝi estas ĉio kovrita per distribuitaj teamoj, kaj ĉio estas tre kompleksa.

Ni ĉiuj vivas en DevOps

Mikaelo: Eĉ el la vidpunkto de la kongresa programkomitato, ni havas homojn en Kalifornio, en Novjorko, Eŭropo, Rusio... ankoraŭ neniu estas en Singapuro. La diferenco en geografio estas sufiĉe granda, kaj homoj komencas disvastiĝi eĉ pli. Se ni parolas pri evoluo, ĉu vi povas diri al ni pli pri devopoj kaj malkonstruado de baroj inter teamoj? Estas koncepto, ke ĉiuj sidas en siaj bunkroj, kaj nun la bunkroj kolapsas, kion vi pensas pri ĉi tiu analogio?

Tim: Ŝajnas al mi, ke pro lastatempaj teknologiaj progresoj, devopoj estas tre grava. Antaŭe, vi havis teamojn de programistoj kaj administrantoj, ili laboris, laboris, funkciis, kaj iam aperis afero, per kiu vi povis veni al la administrantoj kaj ruliĝi ĝin por produktado. Kaj ĉi tie komenciĝis la konversacio pri la bunkro, ĉar la administrantoj estas ia aliancanoj, almenaŭ ne malamikoj, sed vi parolis kun ili nur kiam ĉio estis preta por iri al produktado. Ĉu vi iris al ili kun io kaj diris: rigardu kian aplikaĵon ni havas, sed ĉu vi povus lanĉi ĉi tiun aplikaĵon? Kaj nun la tuta koncepto de livero ŝanĝiĝis al pli bone. Mi volas diri, estis ĉi tiu ideo, ke vi povus rapidigi ŝanĝojn. Ni povas ĝisdatigi produktojn sur la flugo. Mi ĉiam ridetas kiam Firefox sur mia tekkomputilo aperas kaj diras, he, ni ĝisdatigis vian Fajrovulpon en la fono, kaj tuj kiam vi havas minuton, ĉu vi ĝenus klaki ĉi tie kaj ni donos al vi la lastan eldonon. Kaj mi estis kiel, "Ho jes, bebo!" Dum mi dormis, ili laboris por liveri al mi novan eldonon ĝuste en mia komputilo. Ĉi tio estas mirinda, nekredebla.

Sed jen la malfacilaĵo: vi havas ĉi tiun funkcion kun ĝisdatigo de la programaro, sed integri homojn estas multe pli malfacila. Kion mi volas esprimi ĉe la ĉefprelego de DevOops estas, ke ni nun havas multe pli da ludantoj ol ni iam havis. Se vi nur pensas pri ĉiuj implikitaj en nur unu teamo... Vi pensis pri ĝi kiel teamo, kaj ĝi estas multe pli ol nur teamo de programistoj. Ĉi tiuj estas testistoj, projektestroj kaj amaso da aliaj homoj. Kaj ĉiu havas siajn proprajn opiniojn pri la mondo. Produktmanaĝeroj estas tute malsamaj de projektestroj. Administrantoj havas siajn proprajn taskojn. Fariĝas sufiĉe malfacila problemo kunordigi ĉiujn partoprenantojn por daŭre konscii pri tio, kio okazas kaj ne freneziĝi. Necesas apartigi la taskojn de la grupo kaj taskojn kiuj validas por ĉiuj. Ĉi tio estas tre malfacila tasko. Aliflanke, mi pensas, ke ĉio estas multe pli bona ol antaŭ multaj jaroj. Ĝuste ĉi tiu estas la vojo, sur kiu homoj kreskas kaj lernas ĝuste konduti. Kiam vi faras integriĝon, vi komprenas, ke ne devus esti subtera disvolviĝo, tiel ke en la lasta momento la programaro ne elrampas kiel fanto-en-kesto: kiel, rigardu, kion ni faris ĉi tie! La ideo estas, ke vi povos fari integriĝon kaj evoluon, kaj fine vi disruliĝos en bonorda kaj ripeta maniero. Ĉio ĉi signifas multon por mi. Ĉi tio ebligas krei pli da valoro por la uzantoj de la sistemo kaj por via kliento.

Mikaelo: La tuta ideo de devops estas liveri signifajn evoluojn kiel eble plej frue. Mi vidas, ke la mondo komencis pli kaj pli rapidi. Kiel adaptiĝi al tiaj akceloj? Antaŭ dek jaroj ĉi tio ne ekzistis!

Tim: Kompreneble, ĉiuj volas pli kaj pli da funkcieco. Ne necesas moviĝi, nur amasigu pli. Kelkfoje vi eĉ devas malrapidiĝi por la sekva pliiga ĝisdatigo por alporti ion utilan - kaj tio estas tute normala.

La ideo, ke vi devas kuri, kuri, kuri ne estas la plej bona. Estas neverŝajne, ke iu volas vivi sian vivon tiel. Mi ŝatus, ke la ritmo de liveraĵoj starigu la propran ritmon de la projekto. Se vi nur produktas fluon de malgrandaj, relative sensencaj aferoj, ĉio aldonas al neniu signifo. Anstataŭ senpripense provi liberigi aferojn kiel eble plej frue, kio indas diskuti kun la gvidaj programistoj kaj produktaj kaj projektestroj estas strategio. Ĉu ĉi tio eĉ havas sencon?

Ŝablonoj kaj kontraŭŝablonoj

Oleg: Vi kutime parolas pri ŝablonoj kaj kontraŭŝablonoj, kaj ĉi tio estas la diferenco inter la vivo kaj morto de projektoj. Kaj nun, devops eksplodas en niajn vivojn. Ĉu ĝi havas iun el siaj propraj ŝablonoj kaj kontraŭ-ŝablonoj, kiuj povas mortigi la projekton surloke?

Tim: Ŝablonoj kaj kontraŭ-ŝablonoj okazas la tutan tempon. Io por paroli. Nu, estas ĉi tiu afero, kiun ni nomas "brilaj aferoj". Homoj vere, tre ŝatas novan teknologion. Ili estas simple hipnotigitaj de la brilo de ĉio, kio aspektas malvarmeta kaj eleganta, kaj ili ĉesas demandi demandojn: ĉu ĝi eĉ estas necesa? Kion ni atingos? Ĉu ĉi tiu afero estas fidinda, ĉu ĝi havas sencon? Mi ofte vidas homojn, por tiel diri, sur la avangardo de teknologio. Ili estas hipnotigitaj de tio, kio okazas en la mondo. Sed se vi rigardas pli detale kiajn utilajn aferojn ili faras, ofte estas simple nenio utila!

Ni ĵus diskutis kun niaj kamaradoj, ke ĉi tiu jaro estas datrevena jaro, kvindek jarojn de kiam homoj surluniĝis. Ĉi tio estis en 1969. La teknologio kiu helpis homojn atingi tien ne estas eĉ 1969 teknologio, sed prefere 1960 aŭ 62, ĉar NASA volis uzi nur tion, kio havis bonajn pruvojn de fidindeco. Kaj tiel vi rigardas ĝin kaj komprenas — jes, kaj ili estis veraj! Nun, ne, ne, sed vi eniras problemojn kun teknologio simple ĉar ĉio estas puŝita tro forte, vendita de ĉiuj fendoj. Homoj krias de ĉie: "Vidu, kia afero, ĉi tio estas la plej nova, la plej bela en la mondo, taŭga por absolute ĉiuj!" Nu, jen... kutime ĉio ĉi montriĝas nur forlogaĵo, kaj tiam ĉio devas esti forĵetita. Eble ĉio estas ĉar mi jam estas maljunulo kaj rigardas tiajn aferojn kun granda skeptiko, kiam homoj elkuras kaj diras, ke ili trovis la Nur, Plej Ĝustan Vojon Krei la Plej Bonajn Teknologiojn. En ĉi tiu momento, en mi vekiĝas voĉo, kiu diras: "Kia malordo!"

Mikaelo: Efektive, kiom ofte ni aŭdis pri la sekva arĝenta kuglo?

Tim: Ĝuste, kaj ĉi tio estas la kutima kurso de la aferoj! Ekzemple... ŝajnas, ke ĉi tio jam fariĝis ŝerco tra la mondo, sed ĉi tie oni ofte parolas pri blokĉena teknologio. Kaj ili efektive havas sencon en certaj situacioj! Kiam vi vere bezonas fidindajn pruvojn pri eventoj, ke la sistemo funkcias kaj ke neniu trompis nin, kiam vi havas sekurecproblemojn kaj ĉiujn tiujn aĵojn miksitaj kune - blokĉeno havas sencon. Sed kiam ili diras, ke Blockchain nun balaos tra la mondo, forbalaante ĉion sur sia vojo? Revu pli! Ĉi tio estas tre multekosta kaj kompleksa teknologio. Teknike kompleksa kaj tempopostula. Inkluzive pure algoritme, ĉiufoje necesas rekalkuli la matematikon, kun la plej etaj ŝanĝoj... kaj tio estas bonega ideo - sed nur por certaj kazoj. Mia tuta vivo kaj kariero temis pri tio: interesaj ideoj en tre specifaj situacioj. Estas tre grave kompreni ĝuste kia estas via situacio.

Mikaelo: Jes, la ĉefa "demando de vivo, universo kaj ĉio": ĉu ĉi tiu teknologio aŭ aliro taŭgas por via situacio aŭ ne?

Tim: Ĉi tiu demando jam povas esti diskutita kun la teknologia grupo. Eble eĉ venigu iun konsiliston. Rigardu la projekton kaj komprenu - ĉu ni nun faros ion ĝustan kaj utilan, pli bonan ol antaŭe? Eble ĝi taŭgos, eble ne. Sed plej grave, ne prenu tian decidon defaŭlte, simple ĉar iu eldiris: "Ni ege bezonas blokĉenon! Mi ĵus legis pri li en revuo en la aviadilo!” Ĉu serioze? Ĝi eĉ ne estas amuza.

La mita "devops-inĝeniero"

Oleg: Nun ĉiuj efektivigas devopojn. Iu legas pri devopoj en la Interreto, kaj morgaŭ aperas alia vakantaĵo sur varba retejo. "devops-inĝeniero". Ĉi tie mi ŝatus atentigi vian atenton: ĉu vi opinias, ke ĉi tiu termino "devops-inĝeniero" havas rajton je vivo? Estas opinio, ke devops estas kulturo, kaj io ne kuniĝas ĉi tie.

Tim: Tiel-tiel. Ili do tuj donu ian klarigon pri ĉi tiu termino. Io por fari ĝin unika. Ĝis ili pruvos, ke estas ia unika kombinaĵo de kapabloj malantaŭ vakantaĵo kiel ĉi tiu, mi ne aĉetos ĝin! Mi volas diri, nu, ni havas labortitolon, "devops-inĝenieron", interesan titolon, jes, kio poste? Labortitoloj estas ĝenerale tre interesa afero. Ni diru "programisto" - kio ĝi estas ĉiuokaze? Malsamaj organizoj signifas tute malsamajn aferojn. En iuj kompanioj, altkvalitaj programistoj skribas testojn kiuj havas pli da senco ol testoj skribitaj de specialaj profesiaj testistoj en aliaj kompanioj. Do kio, ĉu ili nun estas programistoj aŭ testistoj?

Jes, ni havas labortitolojn, sed se vi demandas sufiĉe longe, eventuale rezultas, ke ni ĉiuj estas solvantoj de problemoj. Ni estas serĉantoj de solvoj, kaj iuj havas iujn teknikajn kapablojn kaj iuj havas malsamajn. Se vi loĝas en medio, kie DevOps penetris, vi okupiĝas pri integriĝo de disvolviĝo kaj administrado, kaj ĉi tiu agado havas sufiĉe gravan celon. Sed se oni demandas vin, kion precize vi faras kaj pri kio vi respondecas, rezultas, ke homoj faras ĉiujn ĉi tiujn aferojn de antikva tempo. "Mi respondecas pri la arkitekturo", "Mi respondecas pri la datumbazoj" kaj tiel plu, kiel ajn, vi vidas - ĉio ĉi estis antaŭ "devops".

Kiam iu diras al mi sian labortitolon, mi vere ne multe aŭskultas. Estas pli bone lasi lin diri al vi pri kio li fakte respondecas, ĉi tio permesos al ni kompreni la aferon multe pli bone. Mia plej ŝatata ekzemplo estas kiam persono asertas esti "projektestro". Kio? Ĝi signifas nenion, mi ankoraŭ ne scias, kion vi faras. Projektestro povas esti programisto, gvidanto de teamo de kvar homoj, skribanta kodon, faranta laboron, kiu fariĝis teamgvidanto, kiun homoj mem rekonas inter si kiel gvidanton. Kaj ankaŭ, projektestro povas esti administranto, kiu administras sescent homojn en projekto, administras aliajn administrantojn, respondecas pri ellaboro de horaroj kaj planado de buĝetoj, jen ĉio. Ĉi tiuj estas du tute malsamaj mondoj! Sed ilia labortitolo sonas same.

Ni turnu ĉi tion iom alimaniere. Pri kio vi vere lertas, havas multan sperton, ĉu vi havas talenton? Por kio vi prenos respondecon ĉar vi pensas, ke vi povas trakti la taskon? Kaj ĉi tie iu tuj komencos nei: ne, ne, ne, mi tute ne emas trakti projektajn rimedojn, ne estas mia afero, mi estas teknika ulo kaj mi komprenas uzeblecon kaj uzantinterfacojn, mi ne volas entute administri armeojn da homoj, lasu min pli bone labori.

Kaj cetere, mi estas granda propagandanto de aliro, en kiu tia disiĝo de kapabloj bone funkcias. Kie teknikistoj povas kreskigi siajn karierojn kiom ili volas. Tamen, mi ankoraŭ vidas organizojn, kie teknikistoj plendas: mi devos iri en projekt-administradon ĉar tio estas la sola maniero en ĉi tiu kompanio. Kelkfoje ĉi tio kondukas al teruraj rezultoj. La plej bonaj teknikistoj tute ne estas bonaj administrantoj, kaj la plej bonaj administrantoj ne povas pritrakti teknologion. Ni estu honestaj pri ĉi tio.

Mi nun vidas multe da postulo pri tio. Se vi estas teknikisto, via kompanio povas helpi vin, sed sendepende, vi bezonas, vere bezonas trovi vian propran karieron ĉar teknologio daŭre ŝanĝiĝas kaj vi devas reinventi vin kune kun ĝi! En nur dudek jaroj, teknologioj povas ŝanĝiĝi almenaŭ kvin fojojn. Teknologio estas stranga afero...

"Spertuloj pri Ĉio"

Mikaelo: Kiel homoj povas elteni tian rapidon de teknologia ŝanĝo? Ilia komplekseco kreskas, ilia nombro kreskas, la tuta kvanto de komunikado inter homoj ankaŭ kreskas, kaj rezultas, ke oni ne povas fariĝi "sperta pri ĉio".

Tim: Ĝuste! Se vi laboras en teknologio, jes, vi certe devas elekti ion specifan kaj enprofundiĝi en ĝi. Iu teknologio kiun via organizo trovas utila (kaj eble efektive estos utila). Kaj se vi ne plu interesiĝas pri ĝi - mi neniam kredus, ke mi dirus ĉi tion - nu, eble vi transloĝiĝu al iu alia organizo, kie la teknologio estas pli interesa aŭ pli oportuna por studi.

Sed ĝenerale, jes, vi pravas. Teknologioj kreskas en ĉiuj direktoj samtempe neniu povas diri "Mi estas sperta teknologo en ĉiuj teknologioj kiuj ekzistas." Aliflanke, estas spongaj homoj, kiuj laŭvorte sorbas teknologiajn sciojn kaj frenezas pri ĝi. Mi vidis kelkajn tiajn homojn, ili laŭvorte spiras kaj vivas ĝin, estas utile kaj interese paroli kun ili. Ili studas ne nur tion, kio okazas ene de la organizo, sed ĝenerale, ili parolas pri tio, ili ankaŭ estas vere bonegaj teknologoj, ili estas tre konsciaj kaj celkonsciaj. Ili nur provas resti sur la kresto de la ondo, sendepende de tio, kio estas ilia ĉefa laboro, ĉar ilia pasio estas la movado de Teknologio, la antaŭenigo de teknologio. Se vi subite renkontas tian homon, vi devus tagmanĝi kun li kaj diskuti diversajn malvarmetajn aferojn dum tagmanĝo. Mi pensas, ke iu ajn organizo bezonas almenaŭ kelkajn tiajn homojn.

Riskoj kaj necerteco

Mikaelo: Honoritaj inĝenieroj, jes. Ni tuŝu riskan administradon dum ni havas tempon. Ni komencis ĉi tiun intervjuon kun diskuto pri medicina programaro, kie eraroj povas konduki al teruraj sekvoj. Tiam ni parolis pri la Luna Programo, kie la kosto de eraro estas milionoj da dolaroj, kaj eble pluraj homaj vivoj. Sed nun mi vidas la kontraŭan movadon en la industrio, homoj ne pensas pri riskoj, ne provas antaŭdiri ilin, eĉ ne observas ilin.

Oleg: Movu rapide kaj rompu aferojn!

Mikaelo: Jes, movu rapide, rompu aferojn, pli kaj pliajn aferojn, ĝis vi mortos pro io. Laŭ via vidpunkto, kiel la averaĝa programisto devas nun aliri lernan riskan administradon?

Tim: Ni desegnu limon ĉi tie inter du aferoj: riskoj kaj necerteco. Ĉi tiuj estas malsamaj aferoj. Necerteco okazas kiam vi ne havas sufiĉajn datumojn en iu ajn momento por alveni al definitiva respondo. Ekzemple, en la tre frua etapo de projekto, se iu demandas al vi "Kiam vi finos la laboron", se vi estas sufiĉe honesta persono, vi diros: "Mi ne havas ideon." Vi simple ne scias, kaj tio estas en ordo. Vi ankoraŭ ne studis la problemojn kaj ne konas la teamon, vi ne konas iliajn kapablojn, ktp. Ĉi tio estas necerteco.

Riskoj aperas kiam eblaj problemoj jam povas esti identigitaj. Tiaj aferoj povas okazi, ĝia probableco estas pli granda ol nulo, sed malpli ol cent procentoj, ie intere. Pro tio, ĉio povas okazi, de prokrastoj kaj nenecesa laboro, sed eĉ ĝis fatala rezulto por la projekto. La rezulto, kiam vi diras - infanoj, ni faldu niajn ombrelojn kaj forlasu la plaĝon, ni neniam finos ĝin, ĉio estas finita, punkto. Ni faris la supozon, ke ĉi tiu afero funkcios, sed ĝi tute ne funkcias, estas tempo ĉesi. Ĉi tiuj estas la situacioj.

Ofte, problemoj estas plej facile solvi kiam ili jam aperis, kiam la problemo okazas ĝuste nun. Sed kiam problemo estas ĝuste antaŭ vi, vi ne faras riskan administradon—vi faras problemon solvantan, krizadministradon. Se vi estas ĉefprogramisto aŭ administranto, vi devas scivoli, kio povus okazi, kio kondukus al prokrastoj, malŝparo de tempo, nenecesaj kostoj aŭ kolapso de la tuta projekto? Kio igos nin halti kaj rekomenci? Kiam ĉiuj ĉi aferoj funkcios, kion ni faros kun ili? Estas simpla respondo, kiu validas por plej multaj situacioj: ne forkuru de riskoj, laboru pri ili. Vidu kiel vi povas solvi riskan situacion, redukti ĝin al nenio, turni ĝin de problemo al io alia. Anstataŭ diri: nu, ni solvos problemojn kiam ili aperos.

Necerteco kaj risko devus esti ĉe la avangardo de ĉio, kion vi traktas. Vi povas preni projektplanon, rigardi certajn kritikajn riskojn antaŭe kaj diri: ni devas trakti ĉi tion nun, ĉar se io el ĉi tio fuŝiĝas, nenio alia gravos. Vi ne devas zorgi pri la beleco de la tablotuko sur la tablo, se ne estas klare ĉu vi povas kuiri vespermanĝon. Unue vi devas identigi ĉiujn riskojn prepari bongustan vespermanĝon, trakti ilin, kaj nur tiam pensi pri ĉiuj aliaj aferoj, kiuj ne prezentas realan minacon.

Denove, kio faras vian projekton unika? Ni vidu, kio povas fari nian projekton ekster la vojo. Kion ni povas fari por minimumigi la probablecon de tio okazi? Kutime oni ne povas simple neŭtraligi ilin 100% kaj deklari kun pura konscienco: "Jen, ĉi tio ne plu estas problemo, la risko solviĝis!" Por mi ĉi tio estas signo de plenkreska konduto. Jen la diferenco inter infano kaj plenkreskulo - infanoj pensas, ke ili estas senmortaj, ke nenio povas misfunkcii, ĉio estos bone! Samtempe plenkreskuloj rigardas kiel trijarajn infanojn saltas sur la ludejo, sekvas la movojn per la okuloj kaj diras al si: "oh-ooh, ooh-ooh." Mi staras proksime kaj pretas kapti, kiam la infano falos.

Aliflanke, la kialo, kial mi tiom ŝatas ĉi tiun komercon, estas ĉar ĝi estas riska. Ni faras aferojn, kaj tiuj aferoj estas riskaj. Ili postulas plenkreskan aliron. Entuziasmo sole ne solvos viajn problemojn!

Plenkreska inĝenieristiko pensado

Mikaelo: La ekzemplo kun infanoj estas bona. Se mi estas ordinara inĝeniero, tiam mi ĝojas esti infano. Sed kiel vi moviĝas al pli plenkreska pensado?

Tim: Unu el la ideoj, kiuj funkcias same bone kun komencanto aŭ establita programisto, estas la koncepto de kunteksto. Kion ni faras, kion ni atingos. Kio estas vere grava en ĉi tiu projekto? Ne gravas, kiu vi estas en ĉi tiu projekto, ĉu vi estas staĝanto aŭ la ĉefarkitekto, ĉiuj bezonas kuntekston. Ni devas igi ĉiujn pensi sur pli granda skalo ol siaj propraj verkoj. "Mi faras mian pecon, kaj dum mia peco funkcias, mi estas feliĉa." Ne kaj ne denove. Ĉiam indas (sen malĝentile!) rememorigi homojn pri la kunteksto en kiu ili laboras. Kion ni ĉiuj provas atingi kune. Ideoj ke vi povas esti infano kondiĉe ke ĉio estas en ordo kun via peco de la projekto - bonvolu, ne faru tion. Se ni entute transpasos la cellinion, ni transiros ĝin nur kune. Vi ne estas sola, ni ĉiuj estas kune. Se ĉiuj homoj en la projekto, kaj maljunaj kaj junaj, komencus paroli pri tio, kio ĝuste gravas por la projekto, kial la kompanio investas monon en tio, kion ni ĉiuj provas atingi... la plej multaj el ili sentos multe pli bone ĉar ili vidos kiel ilia laboro korelacias kun la laboro de ĉiuj aliaj. Unuflanke, mi komprenas la pecon pri kiu mi persone respondecas. Sed por fini la laboron ni bezonas ankaŭ ĉiujn aliajn homojn. Kaj se vi vere pensas, ke vi finis, ni ĉiam havas laboron por fari en la projekto!

Oleg: Relative parolante, se vi laboras laŭ Kanban, kiam vi trafas la proplemon de iu testado, vi povas ĉesi tion, kion vi faris tie (ekzemple, programado) kaj iri helpi la testistojn.

Tim: Ĝuste. Mi pensas, ke la plej bonaj teknikistoj, se vi atente rigardas ilin, ili estas ia siaj propraj administrantoj. Kiel mi povas formuli ĉi tion...

Oleg: Via vivo estas via projekto, kiun vi administras.

Tim: Ĝuste! Mi volas diri, vi prenas respondecon, vi komprenas la aferon, kaj vi kontaktas homojn kiam vi vidas, ke viaj decidoj povas influi ilian laboron, aferojn tiajn. Ne temas nur sidi ĉe via skribotablo, fari vian laboron kaj eĉ ne rimarki, kio okazas ĉirkaŭ vi. Ne ne ne. Cetere, unu el la plej bonaj aferoj pri Agile estas, ke ili proponis mallongajn spurtojn, ĉar tiel la stato de ĉiuj partoprenantoj estas klare observebla, ili povas vidi ĉion kune. Ni parolas pri unu la alian ĉiutage.

Kiel eniri en riskan administradon

Oleg: Ĉu ekzistas iu formala scistrukturo en ĉi tiu areo? Ekzemple, mi estas Java-programisto kaj volas kompreni riskan administradon sen iĝi vera projektestro per edukado. Mi verŝajne legos unue "Kiom Kostas Programaro-Projekto" de McConnell, kaj poste kio? Kio estas la unuaj paŝoj?

Tim: La unua estas komenci komuniki kun homoj en la projekto. Ĉi tio provizas tujan plibonigon en la kulturo de komunikado kun kolegoj. Ni devas komenci malfermi ĉion defaŭlte, anstataŭ kaŝi ĝin. Diru: jen la aferoj, kiuj ĝenas min, jen la aferoj, kiuj tenas min nokte, mi vekiĝis nokte hodiaŭ kaj estis kiel: mia Dio, mi bezonas pensi pri tio! Ĉu aliaj vidas la samon? Kiel grupo, ĉu ni respondu al ĉi tiuj eblaj problemoj? Vi devas povi subteni diskuton pri ĉi tiuj temoj. Ne ekzistas antaŭpreparita formulo, per kiu ni laboras. Ne temas pri fari hamburgerojn, ĝi temas pri homoj. "Faru fromaĝburgeron, vendu fromaĝburgeron" tute ne estas nia afero, kaj tial mi tiom amas ĉi tiun laboron. Mi ŝatas, kiam ĉio, kion faris administrantoj, nun fariĝas posedaĵo de la teamo.

Oleg: Vi parolis en libroj kaj intervjuoj pri kiel homoj pli zorgas pri feliĉo ol pri nombroj sur grafiko. Aliflanke, kiam vi diras al la teamo: ni moviĝas al devopoj, kaj nun la programisto devas konstante komuniki, tio eble estas multe ekster sia komforta zono. Kaj en ĉi tiu momento li povas, ni diru, esti profunde malfeliĉa. Kion fari en ĉi tiu situacio?

Tim: Mi ne certas precize kion fari. Se programisto estas tro izolita, ili ne vidas kial la laboro estas farita en la unua loko, ili nur rigardas sian parton de la laboro, kaj ili bezonas eniri tion, kion mi nomas "kunteksto". Li devas eltrovi kiel ĉio estas kunligita. Kaj kompreneble, mi ne celas formalajn prezentojn aŭ ion similan. Mi parolas pri tio, ke oni devas komuniki kun kolegoj pri la tuta laboro, kaj ne nur pri la parto de ĝi, pri kiu vi respondecas. Ĉi tie vi povas komenci diskuti ideojn, komunajn interkonsentojn por ke via laboro bone kongruu, kaj kiel trakti komunan problemon kune.

Por helpi ilin adaptiĝi, ili ofte volas sendi teknikistojn al trejnado, kaj ili diskutas trejnadon. Mia amiko ŝatas diri, ke trejnado estas por hundoj. Estas trejnado por homoj. Unu el la plej bonaj aferoj pri lernado kiel programisto estas interagi kun viaj samuloj. Se iu vere kapablas pri io, vi devus rigardi ilin labori aŭ paroli kun ili pri ilia laboro aŭ io. Iu konvencia Kent Beck konstante parolis pri ekstrema programado. Estas amuza ĉar XP estas tiel simpla ideo, sed ĝi kaŭzas tiom da problemoj. Por iuj, fari XP estas kiel esti devigita senvestiĝi antaŭ amikoj. Ili vidos, kion mi faras! Ili estas miaj kolegoj, ili ne nur vidos, sed ankaŭ komprenos! Terure! Iuj homoj komencas grave nervoziĝi. Sed kiam vi rimarkas, ke ĉi tio estas la finfina maniero lerni, ĉio ŝanĝiĝas. Vi laboras proksime kun homoj, kaj kelkaj homoj komprenas la temon multe pli bone ol vi.

Mikaelo: Sed ĉio ĉi devigas vin eliri el via komforta zono. Kiel inĝeniero, vi devas eliri el via komforta zono kaj komuniki. Kiel solvanto de problemoj, vi devas konstante meti vin en malfortan pozicion kaj pensi pri kio povus misfunkcii. Ĉi tiu speco de laboro estas esence dizajnita por esti ĝeno. Vi konscie metas vin en streĉajn situaciojn. Kutime homoj forkuras de ili, homoj ŝatas esti feliĉaj infanoj.

Tim: Kion oni povas fari, oni povas eliri kaj malkaŝe diri: “Ĉio estas en ordo, mi povas trakti ĝin! Mi ne estas la sola, kiu sentas sin malkomforta. Ni diskutu diversajn malkomfortajn aferojn, ĉiuj kune, kiel teamo!" Ĉi tiuj estas niaj komunaj problemoj, ni devas trakti ilin, ĉu vi scias? Mi pensas, ke idiosinkraziaj geniaj programistoj estas kiel mamutoj, ili malaperis. Kaj ilia signifo estas tre limigita. Se vi ne povas komuniki, vi ne povas bone partopreni. Tial nur parolu. Estu honesta kaj malfermita. Mi tre bedaŭras, ke ĉi tio estas malagrabla por iu. Ĉu vi povas imagi, antaŭ multaj jaroj estis studo laŭ kiu la ĉefa timo en Usono ne estas morto, sed divenu kio? Timo pri parolado! Ĉi tio signifas, ke ie estas homoj, kiuj preferus morti ol laŭte diri komplimenton. Kaj mi pensas, ke sufiĉas por vi havi kelkajn bazajn kapablojn, depende de tio, kion vi faras. Parolado, skribkapablo - sed nur tiom, kiom vere necesas en via laboro. Se vi laboras kiel analizisto, sed ne povas legi, skribi aŭ paroli, tiam, bedaŭrinde, vi havos nenion por fari en miaj projektoj!

La prezo de komunikado

Oleg: Ĉu dungi tiajn eksiĝintajn dungitojn ne estas pli multekosta pro diversaj kialoj? Post ĉio, ili konstante babilas anstataŭ labori!

Tim: Mi celis la kernon de la teamo, kaj ne nur ĉiujn. Se vi havas iun, kiu estas vere mojosa pri agordado de datumbazoj, amas agordi datumbazojn, kaj daŭrigos agordi viajn datumbazojn por la resto de sia vivo kaj jen ĝi, trankvile, daŭrigu ĝin. Sed mi parolas pri homoj, kiuj volas vivi en la projekto mem. La kerno de la teamo, celis disvolvi la projekton. Ĉi tiuj homoj vere bezonas konstante komuniki unu kun la alia. Kaj precipe komence de la projekto, kiam vi diskutas pri riskoj, manieroj atingi tutmondajn celojn kaj similajn.

Mikaelo: Ĉi tio validas por ĉiuj implikitaj en la projekto, sendepende de specialiĝo, kapabloj aŭ labormanieroj. Vi ĉiuj interesiĝas pri la sukceso de la projekto.

Tim: Jes, vi sentas, ke vi estas sufiĉe mergita en la projekto, ke via tasko estas helpi la projekton realiĝi. Ĉu vi estas programisto, analizisto, interfacprojektisto, iu ajn. Jen la kialo, ke mi venas al laboro ĉiumatene kaj ĉi tion ni faras. Ni respondecas pri ĉiuj ĉi tiuj homoj, sendepende de iliaj kapabloj. Ĉi tio estas grupo de homoj havantaj plenkreskajn konversaciojn.

Oleg: Fakte, parolante pri parolemaj dungitoj, mi provis simuli la obĵetojn de homoj, precipe de administrantoj, kiuj estas petataj ŝanĝi al devopoj, al ĉi tiu tuta nova vizio de la mondo. Kaj vi, kiel konsultistoj, devus esti konscia pri ĉi tiuj obĵetoj multe pli bone ol mi, kiel programisto! Kunhavigi kio plej maltrankviligas administrantojn?

Tim: Perantoj? Hm. Plej ofte, administrantoj estas sub premo de problemoj, alfrontitaj kun la bezono urĝe liberigi ion kaj fari liveraĵon, kaj simile. Ili rigardas kiel ni konstante diskutas kaj diskutas pri io, kaj ili vidas tion tiel: konversacioj, konversacioj, konversacioj... Kiaj aliaj konversacioj? Reiru al laboro! Ĉar paroli ne ŝajnas al ili laboro. Vi ne skribas kodon, ne testas programaron, ŝajnas nenion fari - kial ne sendi vin fari ion? Post ĉio, livero estas jam en monato!

Mikaelo: Iru skribi iom da kodo!

Tim: Ŝajnas al mi, ke ili ne zorgas pri laboro, sed pri la manko de videbleco de progreso. Por ŝajni, ke ni proksimiĝas al sukceso, ili devas vidi nin premante butonojn sur la klavaro. La tutan tagon de mateno ĝis vespero. Ĉi tio estas problemo numero unu.

Oleg: Miŝa, vi pensas pri io.

Mikaelo: Pardonu, mi perdiĝis en pensoj kaj kaptis retromemoron. Ĉio ĉi rememorigis min pri interesa mitingo, kiu okazis hieraŭ... Hieraŭ estis tro da amaskunvenoj... Kaj ĉio sonas tre konata!

Vivo sen salajroj

Tim: Cetere, tute ne necesas organizi "mitingojn" por komunikado. Mi volas diri, ke la plej utilaj diskutoj inter programistoj okazas kiam ili nur parolas unu kun la alia. Vi eniras matene kun taso da kafo, kaj estas kvin homoj kunvenintaj kaj furioze diskutantaj pri io teknika. Por mi, se mi estas la administranto de ĉi tiu projekto, estas pli bone simple rideti kaj iri ien pri mia komerco, lasu ilin diskuti ĝin. Ili jam estas engaĝitaj kiel eble plej multe. Ĉi tio estas bona signo.

Oleg: Cetere, en via libro vi havas amason da notoj pri kio estas bona kaj kio estas malbona. Ĉu vi mem uzas iun el ili? Relative parolante, nun vi havas firmaon, kaj unu kiu estas strukturita en tre neortodoksa maniero...

Tim: Neortodoksa, sed ĉi tiu aparato perfekte konvenas al ni. Ni konas unu la alian jam delonge. Ni fidas unu la alian, ni multe fidis unu la alian antaŭ ol ni fariĝis partneroj. Kaj ekzemple, ni tute ne havas salajrojn. Ni nur laboras, kaj ekzemple, se mi gajnis monon de miaj klientoj, tiam la tuta mono iris al mi. Post tio, ni pagas membrokotizon al la organizo, kaj tio sufiĉas por subteni la kompanion mem. Krome, ni ĉiuj specialiĝas pri malsamaj aferoj. Ekzemple, mi laboras kun librotenistoj, plenigas impostdeklarojn, faras ĉiajn administrajn aferojn por la firmao, kaj neniu pagas min por ĝi. James kaj Tom laboras en nia retejo kaj ankaŭ neniu pagas ilin. Dum vi pagos viajn kotizojn, neniu pensos diri al vi, kion vi devas fari. Ekzemple, Tom nun laboras multe malpli ol iam. Nun li havas aliajn interesojn li faras kelkajn aferojn ne por la Gildo. Sed dum li pagos sian kotizon, neniu venos al li kaj diros: "He, Tom, eklaboru!" Estas tre facile trakti kolegojn kiam ne estas mono inter vi. Kaj nun nia rilato estas unu el la fundamentaj ideoj rilate al diversaj fakoj. Ĝi funkcias kaj ĝi funkcias tre bone.

Plej bona konsilo

Mikaelo: Revenante al "plej bonaj konsiloj", ĉu estas io, kion vi diras al viaj klientoj denove kaj denove? Estas ideo pri 80/20, kaj iuj konsiloj verŝajne ripetas pli ofte.

Tim: Mi iam pensis, ke se vi verkis libron kiel Valso kun Ursoj, ĝi ŝanĝus la kurson de la historio kaj homoj ĉesos, sed... Nu, vidu, kompanioj ofte ŝajnigas, ke ĉio estas en ordo al ili. Tuj kiam io malbona okazas, ĝi estas ŝoko kaj surprizo por ili. "Rigardu, ni testis la sistemon, kaj ĝi ne trapasas iujn ajn sistemajn provojn, kaj ĉi tio estas pliaj tri monatoj da neplanita laboro, kiel tio povus okazi? Kiu sciis? Kio povus misfunkcii? Serioze, ĉu vi kredas ĉi tion?

Mi provas klarigi, ke vi ne devas tro koleri pri la nuna situacio. Ni devas paroli pri tio, vere kompreni, kio povus esti misfunkciinta, kaj kiel malhelpi tiajn aferojn okazi estonte. Se problemo aperas, kiel ni batalos ĝin, kiel ni enhavos ĝin?

Al mi ĉio ĉi aspektas timiga. Homoj traktas kompleksajn, ĝenajn problemojn kaj daŭre ŝajnigas, ke se ili nur krucas la fingrojn kaj esperas la plej bonan, la "plej bona" ​​efektive okazos. Ne, ĝi ne funkcias tiel.

Praktiku riskan administradon!

Mikaelo: Laŭ via opinio, kiom da organizoj okupiĝas pri riska administrado?

Tim: Kio furiozas min estas, ke homoj simple notas riskojn, rigardas la rezultan liston kaj eklaboru. Fakte, identigi riskojn por ili estas riska administrado. Sed al mi tio sonas kiel kialo por demandi: bone, estas listo, kion precize vi ŝanĝos? Vi devas ŝanĝi viajn normajn sekvencojn de agoj konsiderante ĉi tiujn riskojn. Se estas iu plej malfacila parto de la laboro, vi devas trakti ĝin, kaj nur tiam pluiri al io pli simpla. En la unuaj spurtoj, komencu solvi kompleksajn problemojn. Ĉi tio jam aspektas kiel riska administrado. Sed kutime homoj ne povas diri kion ili ŝanĝis post kompili liston de riskoj.

Mikaelo: Kaj tamen, kiom da ĉi tiuj kompanioj okupiĝas pri riska administrado, kvin procentoj?

Tim: Bedaŭrinde, mi malamas diri ĉi tion, sed ĉi tio estas tre sensignifa parto. Sed pli ol kvin, ĉar estas vere grandaj projektoj, kaj ili simple ne povas ekzisti, se ili ne faras almenaŭ ion. Ni nur diru, ke mi tre surprizos se ĝi estas almenaŭ 25%. Malgrandaj projektoj kutime respondas tiajn demandojn jene: se la problemo influas nin, tiam ni solvos ĝin. Tiam ili sukcese eniras sin en problemojn kaj okupiĝas pri problemo-administrado kaj kriz-administrado. Kiam vi provas solvi problemon kaj la problemo ne estas solvita, bonvenon al krizadministrado.

Jes, mi ofte aŭdas, "ni solvos problemojn kiam ili aperos." Certe ni faros? Ĉu ni vere decidos?

Oleg: Vi povas fari ĝin naive kaj simple skribi gravajn invariaĵojn en la projektoĉarton, kaj se la invariantoj rompiĝas, simple rekomencu la projekton. Ĝi rezultas tre piembucky.

Mikaelo: Jes, okazis al mi, ke kiam riskoj estis ekigitaj, la projekto estis simple redifinita. Bela, bingo, problemo solvita, ne zorgu plu!

Tim: Ni premu la butonon de restarigi! Ne, ĝi ne funkcias tiel.

Konferenco ĉe DevOops 2019

Mikaelo: Ni venas al la lasta demando de ĉi tiu intervjuo. Vi venas al la sekva DevOops kun ĉefprelego, ĉu vi povus levi la kurtenon de sekreteco pri tio, kion vi rakontos?

Tim: Ĝuste nun, ses el ili verkas libron pri laborkulturo, la nediritaj reguloj de organizoj. Kulturo estas determinita de la kernaj valoroj de la organizo. Kutime homoj ne rimarkas tion, sed laborinte en konsultado dum multaj jaroj, ni kutimas rimarki ĝin. Vi eniras kompanion, kaj laŭvorte ene de kelkaj minutoj vi komencas senti tion, kio okazas. Ni nomas ĉi tion "gusto". Foje ĉi tiu odoro estas vere bona, kaj foje ĝi estas, nu, ho. Aferoj estas tre malsamaj por malsamaj organizoj.

Mikaelo: Ankaŭ mi laboras en konsultado de jaroj kaj bone komprenas, pri kio vi parolas.

Tim: Efektive, unu el la aferoj pri kiuj valoras paroli ĉe la ĉefkoncepto estas, ke ne ĉio estas determinita de la kompanio. Vi kaj via teamo, kiel komunumo, havas vian propran teaman kulturon. Ĉi tio povus esti la tuta kompanio, aŭ aparta fako, aparta teamo. Sed antaŭ ol vi diris, jen kion ni kredas, jen kio gravas... Vi ne povas ŝanĝi kulturon antaŭ ol la valoroj kaj kredoj malantaŭ specifaj agoj estas komprenitaj. Konduto estas facile observi, sed serĉi kredojn estas malfacila. DevOps estas nur bonega ekzemplo de kiel aferoj fariĝas pli kaj pli kompleksaj. Interagoj nur fariĝas pli kompleksaj, ili tute ne fariĝas pli puraj aŭ pli klaraj, do vi devus pensi pri tio, pri kio vi kredas kaj pri kio silentas ĉiuj ĉirkaŭ vi.

Se vi volas atingi rapidajn rezultojn, jen bona temo por vi: ĉu vi vidis kompaniojn, kie neniu diras "Mi ne scias"? Estas lokoj kie oni laŭvorte torturas homon ĝis li konfesas, ke li ne scias ion. Ĉiuj scias ĉion, ĉiuj estas nekredebla erudiciulo. Vi alproksimiĝas al iu ajn persono, kaj li devas tuj respondi la demandon. Anstataŭ diri "Mi ne scias." Hura, ili dungis aron da erudiciuloj! Kaj en kelkaj kulturoj estas ĝenerale tre danĝere diri "Mi ne scias" ĝi povas esti perceptita kiel signo de malforteco. Ekzistas ankaŭ organizoj en kiuj, male, ĉiuj povas diri "Mi ne scias." Tie ĝi estas tute laŭleĝa, kaj se iu komencas rubo responde al demando, estas tute normale respondi: "Vi ne scias, pri kio vi parolas, ĉu?" kaj transformu ĉion en ŝercon.

Ideale, vi ŝatus havi laboron kie vi povus esti konstante feliĉa. Ne estos facile, ne ĉiu tago estas suna kaj agrabla, foje vi devas labori forte, sed kiam vi komencos bilanci, tio rezultos: uu, ĉi tio estas vere mirinda loko, mi sentas min bone laborante ĉi tie, kaj emocie kaj intelekte. Kaj estas kompanioj, kie vi iras kiel konsultisto kaj tuj rimarkas, ke vi ne povus elteni ĝin dum tri monatoj kaj forkurus pro hororo. Jen kion mi volas paroli ĉe la raporto.

Tim Lister alvenos kun ĉefprelego " Karakteroj, komunumo kaj kulturo: Gravaj faktoroj por prospero "al la konferenco DevOops 2019, kiu okazos la 29-30-an de oktobro 2019 en Sankt-Peterburgo. Vi povas aĉeti biletojn en la oficiala retejo. Ni atendas vin ĉe DevOops!

fonto: www.habr.com