Tim Lister - kirjojen toinen kirjoittaja

• "Inhimillinen tekijä. Onnistuneet projektit ja tiimit" (alkuperäisen kirjan nimi on "Peopleware")
• "Waltsing with the Bears: Riskienhallinta ohjelmistoprojekteissa"
• "Adrenaliinihullu ja kuvioiden zombie. Projektiryhmien käyttäytymismallit"

Kaikki nämä kirjat ovat alansa klassikoita, ja ne on kirjoitettu yhdessä kollegoiden kanssa Atlantic Systems Guild. Venäjällä hänen kollegansa ovat tunnetuimpia - Tom DeMarco и Peter Hruschka, joka kirjoitti myös monia kuuluisia teoksia.

Timillä on 40 vuoden kokemus ohjelmistokehityksestä vuonna 1975 (yksikään tämän habrapostin kirjoittajista ei syntynyt tänä vuonna), Tim oli jo Yourdon Inc:n varatoimitusjohtaja. Hän viettää nyt aikaansa konsultointiin, opettamiseen ja kirjoittamiseen, ja hän vierailee silloin tällöin raporttien kanssa konferensseja ympäri maailmaa.

Teimme haastattelun Tim Listerin kanssa erityisesti Habrille. Hän avaa DevOops 2019 -konferenssin, ja meillä on paljon kysymyksiä kirjoista ja muusta. Haastattelun tekevät Mikhail Druzhinin ja Oleg Chirukhin konferenssin ohjelmakomiteasta.

Michael: Voitko sanoa muutaman sanan siitä, mitä teet nyt?

Tim: Olen Atlantic Systems Guildin johtaja. Meitä on killassa kuusi, me kutsumme itseämme rehtoriksi. Kolme Yhdysvalloissa ja kolme Euroopassa - siksi kiltaa kutsutaan Atlantiksi. Olemme olleet yhdessä niin monta vuotta, ettei niitä voi laskea. Meillä kaikilla on erikoisuutemme. Olen työskennellyt asiakkaiden kanssa viimeisen vuosikymmenen tai enemmänkin. Projekteihini kuuluvat paitsi johtaminen, myös vaatimusten asettaminen, projektisuunnittelu ja arviointi. Vaikuttaa siltä, ​​että huonosti alkaneet projektit päättyvät yleensä huonosti. Siksi kannattaa varmistaa, että kaikki toiminta on todella hyvin harkittua ja koordinoitua, että tekijöiden ideat yhdistetään. Kannattaa miettiä mitä tekee ja miksi. Mitä strategioita käyttää projektin saattamiseksi päätökseen.

Olen neuvonut asiakkaita monin eri tavoin useiden vuosien ajan. Mielenkiintoinen esimerkki on yritys, joka valmistaa robotteja polvi- ja lonkkaleikkauksiin. Kirurgi ei toimi täysin itsenäisesti, vaan käyttää robottia. Turvallisuus on täällä suoraan sanoen tärkeää. Mutta kun yrität keskustella vaatimuksista ihmisten kanssa, jotka ovat keskittyneet ongelmien ratkaisemiseen... Kuulostaa oudolta, mutta Yhdysvalloissa on FDA (Federal Drug Administration), joka lisensoi näiden robottien kaltaisia ​​tuotteita. Ennen kuin myyt mitään ja käytät sitä eläville ihmisille, sinun on hankittava lisenssi. Yksi ehdoista on näyttää vaatimuksesi, mitkä ovat testit, miten testasit ne, mitkä ovat testitulokset. Jos muutat vaatimuksia, sinun täytyy käydä läpi koko tämä valtava testausprosessi yhä uudelleen ja uudelleen. Asiakkaamme onnistuivat sisällyttämään sovellusten visuaalisen suunnittelun vaatimuksiinsa. Heillä oli kuvakaappaukset suoraan osana vaatimuksia. Meidän täytyy vetää ne esiin ja selittää, että suurimmaksi osaksi kaikki nämä ohjelmat eivät tiedä mitään polvista ja lonkista, kaikista näistä asioista kameran kanssa jne. Vaatimusasiakirjat on kirjoitettava uudelleen niin, että ne eivät koskaan muutu, elleivät jotkut todella tärkeät taustaolosuhteet muutu. Jos visuaalinen suunnittelu ei ole vaatimusten mukainen, tuotteen päivittäminen on paljon nopeampaa. Meidän tehtävämme on löytää ne elementit, jotka käsittelevät polven, lonkan, selän leikkauksia, koota ne erillisiksi asiakirjoiksi ja sanoa, että nämä ovat perusvaatimukset. Tehdään erillinen ryhmä polvileikkauksia koskevia vaatimuksia. Tämä antaa meille mahdollisuuden rakentaa vakaampi vaatimussarja. Puhumme koko tuotelinjasta, emme yksittäisistä roboteista.

Töitä tehtiin paljon, mutta silti he pääsivät paikkoihin, joissa vietettiin viikkoja ja kuukausia toistuvia testejä ilman merkitystä tai tarvetta, koska heidän paperilla kuvatut vaatimukset eivät vastanneet todellisia vaatimuksia, joita varten järjestelmät rakennettiin. FDA kertoi heille joka kerta: vaatimukset ovat muuttuneet, nyt sinun on tarkistettava kaikki tyhjästä. Koko tuotteen täydelliset uudelleentarkastukset tappoivat yrityksen.

Joten on niin upeita tehtäviä, kun huomaat olevansa mielenkiintoisen alkuvaiheessa, ja aivan ensimmäiset toimet asettavat pelin lisäsäännöt. Jos varmistat, että tämä varhainen toiminta alkaa toimia hyvin sekä johtamisen että teknisen näkökulmasta, on mahdollista, että päädyt hienoon projektiin. Mutta jos tämä osa on mennyt raiteilta ja mennyt johonkin pieleen, jos et löydä perussopimuksia... ei, se ei tarkoita, että projektisi välttämättä epäonnistuisi. Mutta et voi enää sanoa: "Me onnistuimme loistavasti, teimme kaiken todella tehokkaasti." Näitä asioita teen kun kommunikoin asiakkaiden kanssa.

Michael: Eli käynnistät projekteja, teet jonkinlaisen kickoffin ja tarkistat, että kiskot ovat menossa oikeaan suuntaan?

Tim: Meillä on myös ideoita, kuinka kaikki palapelin palaset koota: mitä taitoja tarvitsemme, milloin niitä tarkalleen tarvitaan, miltä tiimin ydin näyttää ja muuta sellaista perustavanlaatuista. Tarvitsemmeko kokoaikaisia ​​työntekijöitä vai voimmeko palkata jonkun osa-aikaisen? Suunnittelu, johtaminen. Kysymyksiä kuten: Mikä on tärkeintä tälle projektille? Miten tämä saavutetaan? Mitä tiedämme tästä tuotteesta tai projektista, mitkä ovat riskit ja missä ovat tuntemattomat, miten aiomme käsitellä tätä kaikkea? Tietysti tällä hetkellä joku alkaa huutaa "Entä ketterä?!" Okei, olette joustavia, mutta mitä sitten? Miltä projekti tarkalleen ottaen näyttää, miten aiot viedä sen projektille sopivalla tavalla? Et voi vain sanoa, että "lähestymistapamme ulottuu kaikkeen, olemme Scrum-tiimi!" Tämä on hölynpölyä ja hölynpölyä. Mihin aiot mennä seuraavaksi, miksi sen pitäisi toimia, missä on järkeä? Opetan asiakkaitani ajattelemaan kaikkia näitä kysymyksiä.

19 vuotta ketterää

Michael: Agilessa usein yritetään olla määrittelemättä mitään etukäteen, vaan tehdä päätökset mahdollisimman myöhään sanoen: olemme liian isoja, en ajattele kokonaisarkkitehtuuria. En ajattele monia muita asioita, vaan toimitan asiakkaalle jotain, joka toimii juuri nyt.

Tim: Mielestäni ketterät menetelmät, alkaen Ketterä manifesti vuonna 2001, avasi alan silmät. Mutta toisaalta, mikään ei ole täydellistä. Kannatan iteratiivista kehitystä. Iteraatiolla on paljon järkeä useimmissa projekteissa. Mutta kysymys, jota sinun on mietittävä, on: kun tuote on poistunut ja käytössä, kuinka kauan se kestää? Onko tämä tuote, joka kestää kuusi kuukautta ennen kuin se korvataan jollain muulla? Vai onko tämä tuote, joka toimii monta, monta vuotta? En tietenkään mainitse nimiä, mutta... New Yorkissa ja sen talousyhteisössä perustavanlaatuisimmat järjestelmät ovat hyvin vanhoja. Tämä on hämmästyttävä. Katsot niitä ja ajattelet, jos vain voisit palata ajassa taaksepäin, vuoteen 1994, ja kertoa kehittäjille: "Tulin tulevaisuudesta, vuodesta 2019. Kehitä vain tätä järjestelmää niin kauan kuin tarvitset. Tee siitä laajennettavissa, ajattele arkkitehtuuria. Sen jälkeen sitä parannetaan yli XNUMX vuoden ajan. Jos viivyttelet kehitystä vielä vähän kauemmin, kukaan ei suuressa suunnitelmassa huomaa!” Kun arvioit asioita pitkällä aikavälillä, sinun on otettava huomioon, kuinka paljon se maksaa yhteensä. Joskus hyvin suunniteltu arkkitehtuuri on todella sen arvoista, joskus ei. Meidän on katsottava ympärillemme ja kysyttävä itseltämme: olemmeko oikeassa tilanteessa tällaiselle päätökselle?

Joten ajatus, kuten "Olemme ketterän puolesta, asiakas itse kertoo meille, mitä hän haluaa saada" - se on erittäin naiivi. Asiakkaat eivät edes tiedä, mitä he haluavat, ja vielä enemmän he eivät tiedä, mitä he voisivat saada. Jotkut ihmiset alkavat vedota historiallisiin esimerkkeihin perusteluina, olen jo nähnyt tämän. Mutta teknisesti edistyneet ihmiset eivät yleensä sano niin. He sanovat: "On vuosi 2019, nämä mahdollisuudet meillä on, ja voimme täysin muuttaa tapaamme tarkastella näitä asioita!" Sen sijaan, että matkisi olemassa olevia ratkaisuja, tekisi niistä hieman kauniimpia ja kammattumpia, sinun täytyy joskus mennä ulos ja sanoa: "Keksitään täysin uudelleen, mitä yritämme tehdä täällä!"

Ja en usko, että useimmat asiakkaat voivat ajatella ongelmaa sillä tavalla. He näkevät vain sen, mitä heillä jo on, siinä kaikki. Tämän jälkeen he esittävät pyyntöjä, kuten "tehdään tästä vähän yksinkertaisempi" tai mitä tahansa he yleensä sanovat. Mutta emme ole tarjoilijoita, joten voimme ottaa tilauksen kuinka tyhmäksi se osoittautuukin ja sitten leipoa sen keittiössä. Olemme heidän oppaita. Meidän on avattava heidän silmänsä ja sanottava: hei, meillä on täällä uusia mahdollisuuksia! Ymmärrätkö, että voimme todella muuttaa tapaa, jolla tämä osa liiketoimintaasi tehdään? Yksi Agilen ongelmista on, että se poistaa tietoisuuden siitä, mikä on mahdollisuus, mikä on ongelma, mitä meidän on edes tehtävä, mitkä saatavilla olevat tekniikat sopivat parhaiten tähän tilanteeseen.

Ehkä olen tässä liian skeptinen: ketterässä yhteisössä tapahtuu paljon ihmeellisiä asioita. Mutta minua vaivaa se tosiasia, että projektin määrittelemisen sijaan ihmiset alkavat oksentaa käsiään. Kysyisin täällä - mitä teemme, miten aiomme tehdä sen? Ja jotenkin maagisesti aina käy niin, että asiakkaan pitäisi tietää paremmin kuin kukaan muu. Mutta asiakas tietää parhaiten vasta, kun hän valitsee jonkun jo rakentamista asioista. Jos haluan ostaa auton ja tiedän perheeni budjetin koon, valitsen nopeasti elämäntyyliini sopivan auton. Täällä tiedän kaiken paremmin kuin kukaan muu! Mutta huomaa, että joku on jo tehnyt autot. Minulla ei ole aavistustakaan kuinka keksiä uusi auto, en ole asiantuntija. Kun luomme räätälöityjä tai erikoistuotteita, asiakkaan ääni on otettava huomioon, mutta se ei ole enää ainoa ääni.

Oleg: Mainitsit ketterän manifestin. Tarvitseeko sitä jotenkin päivittää tai tarkistaa ottaen huomioon nykyaikainen käsitys asiasta?

Tim: En koske häneen. Minusta se on hieno historiallinen dokumentti. Tarkoitan, hän on mitä hän on. Hän täyttää 19 vuotta, hän on vanha, mutta hän teki aikanaan vallankumouksen. Hän teki hyvin, että hän sai aikaan reaktion ja ihmiset alkoivat kuiskata hänestä. Todennäköisesti et ollut alalla vielä töissä vuonna 2001, mutta silloin kaikki työskentelivät prosessien mukaan. Software Engineering Institute, viisi tasoa ohjelmiston täydellisyysmallissa (CMMI). En tiedä, kertovatko sellaiset syvän antiikin legendat sinulle jotain, mutta sitten se oli läpimurto. Aluksi ihmiset uskoivat, että jos prosessit asetetaan oikein, ongelmat katoavat itsestään. Ja sitten tulee Manifesti ja sanoo: "Ei, ei, ei – perustumme ihmisiin, emme prosesseihin." Olemme ohjelmistokehityksen mestareita. Ymmärrämme, että ihanteellinen prosessi ei tapahdu. Projekteissa on liikaa omaperäisyyttä, ajatus yhdestä täydellisestä prosessista kaikille projekteille ei ole järkevää. Ongelmat ovat liian monimutkaisia ​​väittämään, että kaikkeen on vain yksi ratkaisu (hei, nirvana).

En viitsi katsoa tulevaisuuteen, mutta sanon, että ihmiset ovat nyt alkaneet miettiä enemmän projekteja. Mielestäni ketterä manifesti on erittäin hyvä hyppäämään ulos ja sanomaan: "Hei! Olet laivalla ja itse ajat tätä laivaa. Sinun on tehtävä päätös - emme ehdota yleistä reseptiä kaikkiin tilanteisiin. Olet laivan miehistö, ja jos olet tarpeeksi hyvä, voit löytää tien tavoitteeseen. Oli muita aluksia ennen sinua, ja tulee olemaan muita aluksia sinun jälkeensi, mutta silti matkasi on tietyssä mielessä ainutlaatuinen." Jotain sellaista! Se on tapa ajatella. Minulle ei ole mitään uutta auringon alla, ihmiset ovat purjehtineet ennenkin ja tulevat purjehtimaan uudelleen, mutta sinulle tämä on päämatkasi, enkä kerro mitä sinulle tapahtuu. Sinulla tulee olla koordinoidun tiimityöskentelyn taidot, ja jos ne todella on, kaikki järjestyy ja pääset minne haluat.

Peopleware: 30 vuotta myöhemmin

Oleg: Oliko Peopleware yhtä lailla vallankumous kuin manifesti?

Tim: Peopleware... Tom ja minä kirjoitimme tämän kirjan, mutta emme uskoneet sen tapahtuvan näin. Jotenkin se resonoi monien ihmisten ajatuksiin. Tämä oli ensimmäinen kirja, jossa sanottiin: ohjelmistokehitys on erittäin ihmisintensiivistä toimintaa. Teknisyydestämme huolimatta olemme myös ihmisten yhteisö rakentamassa jotain suurta, jopa valtavaa, hyvin monimutkaista. Kukaan ei voi luoda tällaisia ​​asioita yksin, eihän? Joten ajatus "joukkueesta" tuli erittäin tärkeäksi. Eikä vain johtamisen näkökulmasta, vaan myös teknisille ihmisille, jotka kokoontuivat ratkaisemaan todella monimutkaisia ​​syviä ongelmia joukolla tuntemattomia. Minulle henkilökohtaisesti tämä on ollut valtava älykkyystesti koko urani ajan. Ja tässä on voitava sanoa: kyllä, tämä ongelma on enemmän kuin pystyn yksin hoitamaan, mutta voimme yhdessä löytää tyylikkään ratkaisun, josta voimme olla ylpeitä. Ja luulen, että tämä ajatus herätti eniten huomiota. Ajatus siitä, että työskentelemme osan ajasta yksin, osan ajasta osana ryhmää ja usein päätöksen tekee ryhmä. Ryhmäongelmanratkaisusta on nopeasti tullut monimutkaisten projektien tärkeä ominaisuus.

Huolimatta siitä, että Tim on pitänyt valtavan määrän puheita, vain harvat niistä julkaistaan ​​YouTubessa. Voit katsoa raportin "The Return of Peopleware" vuodelta 2007. Laatu tietysti jättää paljon toivomisen varaa.

Michael: Onko mikään muuttunut 30 vuoden aikana kirjan ilmestymisen jälkeen?

Tim: Voit katsoa tätä monesta eri näkökulmasta. Sosiologisesti sanottuna... kerran, yksinkertaisempina aikoina, sinä ja tiimisi istuitte samassa toimistossa. Voisit olla lähellä joka päivä, juoda kahvia yhdessä ja keskustella työstä. Se, mikä on todella muuttunut, on se, että tiimit voidaan nyt jakaa maantieteellisesti, eri maihin ja aikavyöhykkeisiin, mutta silti he työskentelevät saman ongelman parissa, mikä lisää kokonaan uuden kerroksen monimutkaisuutta. Tämä saattaa kuulostaa vanhanaikaiselta, mutta ei ole mitään muuta kuin kasvokkain tapahtuva kommunikointi, jossa olette kaikki yhdessä, työskentelette yhdessä ja voit kävellä kollegan luo ja sanoa, katso mitä löysin, mitä pidät tästä? Kasvotusten keskustelut tarjoavat nopean tavan siirtyä epäviralliseen kommunikointiin, ja mielestäni ketterän harrastajankin pitäisi pitää siitä. Ja olen myös huolissani, koska todellisuudessa maailma on osoittautunut hyvin pieneksi, ja nyt se on peitetty hajautetuilla tiimeillä, ja kaikki on hyvin monimutkaista.

Me kaikki asumme DevOpsissa

Michael: Jopa konferenssin ohjelmakomitean näkökulmasta meillä on ihmisiä Kaliforniassa, New Yorkissa, Euroopassa, Venäjällä... Singaporessa ei ole vielä ketään. Maantieteellinen ero on melko suuri, ja ihmiset alkavat levitä entisestään. Jos puhumme kehityksestä, voitko kertoa meille lisää devopsista ja joukkueiden välisten esteiden murtamisesta? On olemassa ajatus, että kaikki istuvat bunkkereissaan, ja nyt bunkkerit ovat romahtamassa, mitä mieltä olet tästä analogiasta?

Tim: Minusta näyttää siltä, ​​että viimeaikaisten teknologisten läpimurtojen valossa devopsilla on suuri merkitys. Aikaisemmin sinulla oli kehittäjien ja ylläpitäjien ryhmiä, he työskentelivät, työskentelivät, työskentelivät, ja jossain vaiheessa ilmestyi asia, jolla voit tulla järjestelmänvalvojien luo ja levittää sen tuotantoon. Ja tästä alkoi keskustelu bunkkerista, koska järjestelmänvalvojat ovat tavallaan liittolaisia, eivät ainakaan vihollisia, mutta puhuit heidän kanssaan vasta kun kaikki oli valmis tuotantoon. Menitkö heille jollakin ja sanoit: katso, mikä sovellus meillä on, mutta voisitko ottaa tämän sovelluksen käyttöön? Ja nyt koko toimituskonsepti on muuttunut parempaan suuntaan. Tarkoitan, oli ajatus, että voit ajaa muutokset nopeasti läpi. Voimme päivittää tuotteita lennossa. Hymyilen aina, kun kannettavan tietokoneeni Firefox ponnahtaa esiin ja sanoo: Hei, olemme päivittäneet Firefoxisi taustalla, ja heti kun sinulla on hetki aikaa, klikkaa tästä, niin annamme sinulle uusimman julkaisun. Ja minä sanoin: "Ai niin, kulta!" Kun nukuin, he työskentelivät tuodakseen minulle uuden julkaisun suoraan tietokoneelleni. Tämä on upeaa, uskomatonta.

Mutta tässä on vaikeus: sinulla on tämä ominaisuus ohjelmiston päivityksessä, mutta ihmisten integrointi on paljon vaikeampaa. Haluan tuoda esille DevOops-puheenvuoron, että meillä on nyt paljon enemmän pelaajia kuin koskaan. Jos ajattelet vain kaikkia, jotka ovat mukana vain yhdessä tiimissä…. Ajattelit sitä tiiminä, ja se on paljon enemmän kuin pelkkä ohjelmoijatiimi. Nämä ovat testaajia, projektipäälliköitä ja joukko muita ihmisiä. Ja jokaisella on omat näkemyksensä maailmasta. Tuotepäälliköt ovat täysin erilaisia ​​kuin projektipäälliköt. Ylläpitäjillä on omat tehtävänsä. Kaikkien osallistujien koordinoinnista tulee melko vaikea ongelma, jotta pysyisimme tietoisena siitä, mitä tapahtuu, eikä tule hulluksi. On tarpeen erottaa ryhmän tehtävät ja kaikkia koskevat tehtävät. Tämä on erittäin vaikea tehtävä. Toisaalta mielestäni kaikki on paljon paremmin kuin monta vuotta sitten. Juuri tällä tiellä ihmiset kasvavat ja oppivat käyttäytymään oikein. Kun teet integraatiota, ymmärrät, että maanalaista kehitystä ei pitäisi tehdä, jotta ohjelmisto ei viime hetkellä ryömi ulos kuin jack-in-the-box: katso, mitä me täällä teimme! Ajatuksena on, että pystyt tekemään integroinnin ja kehittämisen, ja lopuksi rullaat siististi ja iteratiivisesti. Kaikki tämä merkitsee minulle paljon. Tämä mahdollistaa lisäarvon luomisen järjestelmän käyttäjille ja asiakkaallesi.

Michael: Devopsin koko idea on toimittaa mielekästä kehitystä mahdollisimman aikaisessa vaiheessa. Näen, että maailma on alkanut kiihtyä yhä enemmän. Kuinka sopeutua sellaisiin kiihtyvyyksiin? Kymmenen vuotta sitten tätä ei ollut olemassa!

Tim: Tietenkin kaikki haluavat enemmän ja enemmän toimintoja. Ei tarvitse liikkua, vain kasaa lisää. Joskus sinun on jopa hidastettava seuraavaa asteittaista päivitystä saadaksesi jotain hyödyllistä - ja se on täysin normaalia.

Ajatus siitä, että sinun täytyy juosta, juosta, juosta, ei ole paras. On epätodennäköistä, että kukaan haluaisi elää elämäänsä tuolla tavalla. Haluaisin toimitusten rytmin asettavan projektin oman rytmin. Jos vain tuottaa virran pieniä, suhteellisen merkityksettömiä asioita, se kaikki lisää merkityksetöntä. Sen sijaan, että yritetään mielettömästi julkaista asioita mahdollisimman aikaisessa vaiheessa, johtavien kehittäjien sekä tuote- ja projektipäälliköiden kanssa kannattaa keskustella strategiasta. Onko tässä edes järkeä?

Kuvioita ja antikuvioita

Oleg: Yleensä puhut kuvioista ja vastakuvioista, ja tämä on ero projektien elämän ja kuoleman välillä. Ja nyt devops purskahtaa elämäämme. Onko sillä omia kuvioita ja anti-kuvioita, jotka voivat tappaa projektin paikan päällä?

Tim: Kuvioita ja anti-kuvioita tapahtuu koko ajan. Jotakin puhuttavaa. No, on tämä asia, jota kutsumme "kiiltäväksi esineeksi". Ihmiset todella pitävät uudesta teknologiasta. Heidät yksinkertaisesti lumoaa kaiken siistiltä ja tyylikkäältä näyttävän loistosta, eivätkä he enää kysele: onko se edes välttämätöntä? Mitä aiomme saavuttaa? Onko tämä luotettava, onko siinä mitään järkeä? Näen usein ihmisiä niin sanotusti tekniikan kärjessä. He ovat hypnotisoituneita siitä, mitä maailmassa tapahtuu. Mutta jos tarkastellaan tarkemmin, mitä hyödyllisiä asioita he tekevät, usein ei yksinkertaisesti ole mitään hyödyllistä!

Keskustelimme juuri tovereidemme kanssa, että tämä vuosi on juhlavuosi, viisikymmentä vuotta ihmisten laskeutumisesta kuuhun. Tämä tapahtui vuonna 1969. Teknologia, joka auttoi ihmisiä pääsemään sinne, ei ole edes vuoden 1969 teknologiaa, vaan pikemminkin 1960 tai 62, koska NASA halusi käyttää vain sitä, jolla oli hyviä todisteita luotettavuudesta. Ja niin katsot sitä ja ymmärrät - kyllä, ja ne olivat totta! Nyt ei, ei, mutta joudut ongelmiin tekniikan kanssa yksinkertaisesti siksi, että kaikkea työnnetään liian lujasti, myydään kaikista halkeamista. Ihmiset huutavat kaikkialta: "Katso, mikä juttu, tämä on uusin, kaunein asia maailmassa, sopii ehdottomasti kaikille!" No, se on siinä... yleensä tämä kaikki osoittautuu vain houkuttimaksi, ja sitten se kaikki täytyy heittää pois. Ehkä se johtuu siitä, että olen jo vanha mies ja suhtaudun sellaisiin asioihin suurella skeptisesti, kun ihmiset loppuvat ja sanovat löytäneensä Ainoan, Oikein tavan luoda parhaat tekniikat. Tällä hetkellä sisälläni herää ääni, joka sanoo: "Mikä sotku!"

Michael: Todellakin, kuinka usein olemme kuulleet seuraavasta hopealuodista?

Tim: Aivan, ja tämä on tavallinen asioiden kulku! Esimerkiksi... näyttää siltä, ​​että tästä on tullut jo vitsi ympäri maailmaa, mutta täällä puhutaan usein lohkoketjuteknologiasta. Ja ne ovat todella järkeviä tietyissä tilanteissa! Kun todella tarvitset luotettavia todisteita tapahtumista, siitä, että järjestelmä toimii ja ettei kukaan ole pettänyt meitä, kun sinulla on tietoturvaongelmia ja kaikkea muuta sekaisin - blockchain on järkevää. Mutta kun he sanovat, että Blockchain pyyhkäisee nyt ympäri maailmaa pyyhkäisemällä pois kaiken tieltään? Unelmoi enemmän! Tämä on erittäin kallis ja monimutkainen tekniikka. Teknisesti monimutkainen ja aikaa vievä. Mukaan lukien puhtaasti algoritmisesti, joka kerta, kun joudut laskemaan matematiikan uudelleen, pienimmilläkin muutoksilla... ja tämä on loistava idea - mutta vain tietyissä tapauksissa. Koko elämäni ja urani ovat olleet tästä: mielenkiintoisia ideoita hyvin erityisissä tilanteissa. On erittäin tärkeää ymmärtää tarkalleen, mikä tilanteesi on.

Michael: Kyllä, pääkysymys elämästä, universumista ja kaikesta: sopiiko tämä tekniikka tai lähestymistapa tilanteeseesi vai ei?

Tim: Tästä kysymyksestä voidaan jo keskustella teknologiaryhmän kanssa. Ehkä jopa ota joku konsultti mukaan. Katso projektia ja ymmärrä - teemmekö nyt jotain oikein ja hyödyllistä, paremmin kuin ennen? Ehkä se sopii, ehkä ei. Mutta mikä tärkeintä, älä tee tällaista päätöstä oletuksena, yksinkertaisesti siksi, että joku huusi: "Tarvitsemme kipeästi lohkoketjun! Luin hänestä äsken lehdestä lentokoneessa! Vakavasti? Se ei ole edes hauskaa.

Myyttinen "devops-insinööri"

Oleg: Nyt kaikki toteuttavat devoppeja. Joku lukee netistä devopeista, ja huomenna rekrytointisivustolle ilmestyy uusi työpaikka. "devops-insinööri". Tässä haluan kiinnittää huomionne: onko tällä termillä "devops engineer" mielestäsi oikeus elämään? On olemassa mielipide, että devops on kulttuuri, ja jokin ei sovi tähän.

Tim: Niin ja niin. Anna heidän sitten antaa heti jokin selitys tälle termille. Jotain, joka tekee siitä ainutlaatuisen. Ennen kuin he todistavat, että tällaisen avoimen työpaikan takana on jokin ainutlaatuinen taitojen yhdistelmä, en osta sitä! Tarkoitan, että meillä on tehtävänimike "devops-insinööri", mielenkiintoinen nimike, kyllä, mitä seuraavaksi? Työnimikkeet ovat yleensä erittäin mielenkiintoinen asia. Sanotaan "kehittäjä" – mikä se muuten on? Eri organisaatiot tarkoittavat täysin eri asioita. Joissakin yrityksissä korkealaatuiset ohjelmoijat kirjoittavat testejä, jotka ovat järkevämpiä kuin muiden yritysten erikoisten ammattitestaajien kirjoittamat testit. Joten mitä, ovatko he nyt ohjelmoijia vai testaajia?

Kyllä, meillä on ammattinimikkeitä, mutta jos kysyt tarpeeksi kauan, lopulta käy ilmi, että olemme kaikki ongelmanratkaisijoita. Olemme ratkaisun etsijiä, joillakin on teknisiä taitoja ja toisilla erilaisia. Jos asut ympäristössä, johon DevOps on tunkeutunut, olet mukana kehityksen ja hallinnon integroinnissa, ja tällä toiminnalla on jokin melko tärkeä tarkoitus. Mutta jos sinulta kysytään, mitä tarkalleen ottaen teet ja mistä olet vastuussa, käy ilmi, että ihmiset ovat tehneet kaikkia näitä asioita ammoisista ajoista lähtien. "Olen vastuussa arkkitehtuurista", "Olen vastuussa tietokannoista" ja niin edelleen, mitä tahansa, näette - kaikki tämä oli ennen "devopsia".

Kun joku kertoo minulle työnimensä, en oikeastaan ​​kuuntele paljoa. On parempi antaa hänen kertoa, mistä hän itse asiassa on vastuussa, jotta voimme ymmärtää asiaa paljon paremmin. Suosikkiesimerkkini on, kun henkilö väittää olevansa "projektipäällikkö". Mitä? Se ei tarkoita mitään, en vieläkään tiedä mitä teet. Projektipäällikkö voi olla kehittäjä, neljän hengen tiimin johtaja, koodia kirjoittava, työtä tekevä, josta on tullut tiiminvetäjä, jonka ihmiset itse tunnistavat johtajaksi. Ja myös projektipäällikkö voi olla esimies, joka johtaa kuusisataa henkilöä projektissa, johtaa muita johtajia, vastaa aikataulujen laatimisesta ja budjettien suunnittelusta, siinä kaikki. Nämä ovat kaksi täysin erilaista maailmaa! Mutta heidän työnimikensä kuulostaa samalta.

Käännetään tämä vähän toisin. Missä olet todella hyvä, sinulla on paljon kokemusta, onko sinulla lahjakkuutta? Mistä otat vastuun, koska uskot pystyväsi hoitamaan tehtävän? Ja tässä joku alkaa heti kieltää: ei, ei, ei, minulla ei ole halua käsitellä projektiresursseja ollenkaan, se ei ole minun asiani, olen tekninen jätkä ja ymmärrän käytettävyyden ja käyttöliittymät, en Haluaisitko ylipäätään hallita ihmisjoukkoja, anna minun mennä töihin.

Ja muuten, olen suuri kannattaja lähestymistapaa, jossa tällainen taitojen erottaminen toimii hyvin. Siellä teknikot voivat kasvattaa uraansa niin pitkälle kuin haluavat. Näen kuitenkin edelleen organisaatioita, joissa teknikot valittavat: minun on mentävä projektinhallintaan, koska se on ainoa tapa tässä yrityksessä. Joskus tämä johtaa kauheisiin tuloksiin. Parhaat teknikot eivät ole ollenkaan hyviä johtajia, ja parhaat johtajat eivät osaa käsitellä tekniikkaa. Olkaamme rehellisiä tästä.

Näen tälle nyt paljon kysyntää. Jos olet teknikko, yrityksesi voi auttaa sinua, mutta siitä huolimatta sinun on todella löydettävä oma urapolkusi, koska tekniikka muuttuu jatkuvasti ja sinun on keksittävä itsesi sen mukana! Vain kahdessakymmenessä vuodessa teknologiat voivat muuttua vähintään viisi kertaa. Tekniikka on outo asia...

"Kaiken asiantuntijat"

Michael: Kuinka ihmiset voivat selviytyä tällaisen teknologian muutoksen nopeudesta? Niiden monimutkaisuus kasvaa, niiden määrä kasvaa, myös ihmisten välisen viestinnän kokonaismäärä kasvaa, ja käy ilmi, ettei sinusta voi tulla "kaiken asiantuntijaa".

Tim: Oikein! Jos työskentelet tekniikan parissa, kyllä, sinun täytyy ehdottomasti valita jotain erityistä ja syventyä siihen. Jotakin teknologiaa, jota organisaatiosi pitää hyödyllisenä (ja ehkä siitäkin on hyötyä). Ja jos se ei ole enää kiinnostunut - en olisi koskaan uskonut, että sanon näin - no, ehkä sinun pitäisi siirtyä johonkin muuhun organisaatioon, jossa tekniikka on mielenkiintoisempaa tai kätevämpää opiskella.

Mutta yleisesti ottaen olet oikeassa. Tekniikat kasvavat kaikkiin suuntiin kerralla, kukaan ei voi sanoa: "Olen asiantuntija kaikissa olemassa olevissa teknologioissa." Toisaalta on sieni-ihmisiä, jotka kirjaimellisesti imevät itseensä teknistä tietoa ja ovat siitä hulluja. Olen nähnyt pari tällaista ihmistä, he kirjaimellisesti hengittävät ja elävät sen mukaan, heidän kanssaan on hyödyllistä ja mielenkiintoista keskustella. He eivät tutki vain sitä, mitä organisaation sisällä tapahtuu, vaan he puhuvat siitä yleisesti, he ovat myös todella siistejä teknologeja, he ovat hyvin tietoisia ja määrätietoisia. He yrittävät vain pysyä aallon harjalla, riippumatta siitä, mikä heidän päätehtävänsä on, koska heidän intohimonsa on teknologian liike, teknologian edistäminen. Jos tapaat yllättäen sellaisen henkilön, sinun tulee mennä lounaalle hänen kanssaan ja keskustella lounaalla erilaisista hienoista asioista. Mielestäni mikä tahansa organisaatio tarvitsee ainakin pari tällaista henkilöä.

Riskit ja epävarmuus

Michael: Arvoisat insinöörit, kyllä. Käsitellään riskienhallintaa, kun meillä on aikaa. Aloitimme tämän haastattelun keskustelulla lääketieteellisistä ohjelmistoista, joissa virheet voivat johtaa vakaviin seurauksiin. Sitten puhuimme Lunar-ohjelmasta, jossa virhe maksaa miljoonia dollareita ja mahdollisesti useita ihmishenkiä. Mutta nyt näen alalla päinvastaisen liikkeen, ihmiset eivät ajattele riskejä, eivät yritä ennustaa niitä, eivät edes havainnoi niitä.

Oleg: Liiku nopeasti ja rikkoa asioita!

Michael: Kyllä, liiku nopeasti, riko asioita, lisää ja lisää asioita, kunnes kuolet johonkin. Miten keskivertokehittäjän pitäisi sinun näkökulmastasi suhtautua riskienhallinnan oppimiseen nyt?

Tim: Vedetään tähän raja kahden asian välille: riskit ja epävarmuus. Nämä ovat eri asioita. Epävarmuutta ilmenee, kun sinulla ei ole tarpeeksi tietoa tietyllä hetkellä lopullisen vastauksen saamiseksi. Jos esimerkiksi projektin varhaisessa vaiheessa joku kysyy sinulta ”milloin saat työsi valmiiksi”, jos olet melko rehellinen henkilö, vastaat: ”Minulla ei ole aavistustakaan”. Et vain tiedä, ja se on okei. Et ole vielä perehtynyt ongelmiin etkä tunne tiimiä, et tunne heidän taitojaan ja niin edelleen. Tämä on epävarmuutta.

Riskit syntyvät, kun mahdolliset ongelmat voidaan jo tunnistaa. Tällaista voi tapahtua, sen todennäköisyys on suurempi kuin nolla, mutta alle sata prosenttia, jossain siltä väliltä. Sen vuoksi voi tapahtua mitä tahansa, viivästyksistä ja turhasta työstä, mutta jopa projektin kohtalokkaaseen lopputulokseen. Lopputulos, kun sanotte - kaverit, käännetään sateenvarjomme ylös ja lähdetään rannalta, emme koskaan tee sitä loppuun, kaikki on ohi, piste. Oletimme, että tämä toimisi, mutta se ei toimi ollenkaan, on aika lopettaa. Nämä ovat tilanteita.

Usein ongelmat on helpoimmin ratkaistavissa, kun ne ovat jo ilmaantuneet, kun ongelma on juuri nyt tapahtumassa. Mutta kun ongelma on aivan edessäsi, et tee riskinhallintaa vaan teet ongelmanratkaisua, kriisinhallintaa. Jos olet johtava kehittäjä tai johtaja, sinun täytyy miettiä, mitä voisi tapahtua, mikä johtaisi viivästyksiin, ajanhukkaan, tarpeettomiin kustannuksiin tai koko projektin romahtamiseen? Mikä saa meidät pysähtymään ja aloittamaan alusta? Kun kaikki nämä asiat toimivat, mitä teemme niille? Siihen on yksinkertainen vastaus, joka pätee useimpiin tilanteisiin: älä pakene riskejä, vaan työskentele niiden parissa. Katso, kuinka voit ratkaista riskitilanteen, vähentää sen tyhjäksi, muuttaa sen ongelmasta joksikin muuksi. Sen sijaan, että sanoisimme: no, me ratkaisemme ongelmat sitä mukaa kun niitä ilmenee.

Epävarmuuden ja riskin tulisi olla kaiken, mitä käsittelet, eturintamassa. Voit tehdä projektisuunnitelman, tarkastella tiettyjä kriittisiä riskejä etukäteen ja sanoa: meidän on käsiteltävä tämä nyt, koska jos jokin tästä menee pieleen, millään muulla ei ole merkitystä. Pöydällä olevan pöytäliinan kauneudesta ei pidä huolehtia, jos on epäselvää, pystytkö valmistamaan illallisen. Ensin sinun on tunnistettava kaikki herkullisen illallisen valmistuksen riskit, käsiteltävä niitä ja vasta sitten mietittävä kaikkia muita asioita, jotka eivät aiheuta todellista uhkaa.

Jälleen, mikä tekee projektistasi ainutlaatuisen? Katsotaan, mikä saa projektimme karkaamaan raiteilta. Mitä voimme tehdä minimoidaksemme tämän todennäköisyyden? Yleensä et voi vain neutraloida niitä 100% ja julistaa puhtaalla omallatunnolla: "Siinä se on, tämä ei ole enää ongelma, riski on ratkaistu!" Minulle tämä on merkki aikuisen käytöksestä. Tämä on ero lapsen ja aikuisen välillä - lapset ajattelevat olevansa kuolemattomia, ettei mikään voi mennä pieleen, kaikki tulee olemaan hyvin! Samaan aikaan aikuiset katsovat kuinka kolmevuotiaat lapset hyppäävät leikkikentällä, seuraavat liikkeitä silmillään ja sanovat itselleen: "ooh-ooh, oeh-ooh." Seison lähellä ja valmistaudun saamaan kiinni, kun lapsi putoaa.

Toisaalta syy siihen, miksi pidän tästä liiketoiminnasta niin paljon, on se, että se on riskialtista. Teemme asioita, ja ne asiat ovat riskialttiita. He vaativat aikuisen lähestymistavan. Pelkkä innostus ei ratkaise ongelmiasi!

Aikuisen insinööriajattelu

Michael: Esimerkki lasten kanssa on hyvä. Jos olen tavallinen insinööri, olen iloinen siitä, että olen lapsi. Mutta miten siirtyä kohti aikuisempaa ajattelua?

Tim: Yksi idea, joka toimii yhtä hyvin joko aloittelijan tai vakiintuneen kehittäjän kanssa, on kontekstin käsite. Mitä teemme, mitä aiomme saavuttaa. Mikä tässä projektissa on todella tärkeää? Sillä ei ole väliä, kuka olet tässä projektissa, oletko harjoittelija tai pääarkkitehti, jokainen tarvitsee kontekstin. Meidän on saatava jokainen ajattelemaan omaa työtään suuremmassa mittakaavassa. "Teen teokseni, ja niin kauan kuin teokseni toimii, olen onnellinen." Ei ja taas ei. Aina kannattaa (olematta töykeä!) muistuttaa ihmisiä kontekstista, jossa he työskentelevät. Mitä me kaikki yritämme yhdessä saavuttaa. Ajatuksia siitä, että voit olla lapsi niin kauan kuin kaikki on hyvin projektisi kanssa - älä tee sitä. Jos ylitämme maaliviivan ollenkaan, ylitämme sen vain yhdessä. Et ole yksin, olemme kaikki yhdessä. Jos kaikki projektissa mukana olevat ihmiset, niin vanhat kuin nuoret, alkaisivat puhua siitä, mikä on projektille tarkalleen ottaen tärkeää, miksi yritys sijoittaa rahaa siihen, mitä me kaikki yritämme saavuttaa... useimmat heistä tuntevat olonsa paljon paremmaksi, koska he näkee kuinka heidän työnsä korreloi kaikkien muiden töiden kanssa. Yhtäältä ymmärrän kappaleen, josta olen henkilökohtaisesti vastuussa. Mutta työn loppuun saattamiseksi tarvitsemme myös kaikkia muita ihmisiä. Ja jos todella luulet, että olet valmis, meillä on aina tehtävää projektissa!

Oleg: Suhteellisesti sanottuna Kanbanin mukaan työskennellessäsi, kun osut jonkun testauksen pullonkaulaan, voit lopettaa siellä tekemäsi tekemisen (esim. ohjelmoinnin) ja mennä auttamaan testaajia.

Tim: Tarkalleen. Mielestäni parhaat teknikot, jos katsot heitä tarkasti, he ovat tavallaan omia manageriaan. Miten voin muotoilla tämän...

Oleg: Elämäsi on projektisi, jota hallitset.

Tim: Tarkalleen! Tarkoitan, että otat vastuun, ymmärrät asian ja tulet kosketuksiin ihmisten kanssa, kun näet, että päätöksesi voivat vaikuttaa heidän työhönsä, sellaisia ​​asioita. Kyse ei ole vain siitä, että istut työpöytäsi ääressä, teet työsi etkä edes ymmärrä, mitä ympärilläsi tapahtuu. Ei ei ei. Muuten, yksi parhaista asioista Agilessa on se, että ehdotettiin lyhyitä sprinttejä, koska näin kaikkien osallistujien asioiden tila on selvästi havaittavissa, he näkevät kaiken yhdessä. Puhumme toisistamme joka päivä.

Kuinka päästä riskienhallintaan

Oleg: Onko tällä alalla olemassa muodollista tietorakennetta? Olen esimerkiksi Java-kehittäjä ja haluan ymmärtää riskienhallinnan ilman, että minusta tulee koulutukseltani todellinen projektipäällikkö. Luultavasti luen ensin McConnellin "Kuinka paljon ohjelmistoprojekti maksaa" ja mitä sitten? Mitkä ovat ensimmäiset askeleet?

Tim: Ensimmäinen on aloittaa kommunikointi projektissa mukana olevien ihmisten kanssa. Tämä parantaa välitöntä kommunikointikulttuuria kollegoiden kanssa. Meidän on aloitettava avaamalla kaikki oletusarvoisesti sen sijaan, että piilottaisimme sen. Sano: nämä ovat ne asiat, jotka häiritsevät minua, nämä asiat pitävät minut hereillä öisin, heräsin tänään yöllä ja sanoin: Jumalani, minun täytyy ajatella tätä! Näkevätkö muut saman asian? Pitäisikö meidän ryhmänä vastata näihin mahdollisiin ongelmiin? Sinun täytyy pystyä tukemaan keskustelua näistä aiheista. Meillä ei ole valmiita kaavaa, jonka mukaan työskentelemme. Kyse ei ole hampurilaisten valmistamisesta, vaan ihmisistä. "Tee juustohampurilainen, myy juustohampurilainen" ei ole meidän juttumme, ja siksi rakastan tätä työtä niin paljon. Pidän siitä, että kaikki, mitä johtajat aiemmin tekivät, on nyt joukkueen omaisuutta.

Oleg: Olet puhunut kirjoissa ja haastatteluissa siitä, kuinka ihmiset välittävät enemmän onnellisuudesta kuin kaavion numeroista. Toisaalta, kun kerrot tiimille: siirrymme devopsiin, ja nyt ohjelmoijan on jatkuvasti kommunikoitava, tämä voi olla kaukana hänen mukavuusalueensa ulkopuolella. Ja tällä hetkellä hän voi, sanotaanko, olla syvästi onneton. Mitä tehdä tässä tilanteessa?

Tim: En ole varma, mitä tehdä. Jos kehittäjä on liian eristäytynyt, hän ei ymmärrä, miksi työtä tehdään, he vain katsovat omaa osaa työstään ja heidän on päästävä siihen, mitä minä kutsun "kontekstiin". Hänen täytyy selvittää, kuinka kaikki liittyy toisiinsa. Ja tietenkään en tarkoita virallisia esityksiä tai mitään sellaista. Puhun siitä, että sinun täytyy kommunikoida kollegoiden kanssa työstä kokonaisuutena, eikä vain siitä osasta, josta olet vastuussa. Täällä voit aloittaa keskustelun ideoista, yhteisistä sopimuksista, jotta työsi sopivat hyvin yhteen, ja kuinka ratkaista yhteinen ongelma yhdessä.

Auttaakseen heitä sopeutumaan he haluavat usein lähettää teknikot koulutukseen ja keskustelevat koulutuksesta. Eräs ystäväni sanoo mielellään, että koulutus on koirille. Siellä on koulutusta ihmisille. Yksi parhaista asioista kehittäjänä oppimisessa on vuorovaikutus kollegoidesi kanssa. Jos joku on todella hyvä jossakin, kannattaa katsoa hänen työskentelyään tai puhua hänen kanssaan työstään tai jostain muusta. Jotkut perinteiset Kent Beck puhuivat jatkuvasti äärimmäisestä ohjelmoinnista. Se on hauskaa, koska XP on niin yksinkertainen idea, mutta se aiheuttaa niin monia ongelmia. Joillekin XP:n tekeminen on kuin joutuisi riisumaan alasti ystävien edessä. He näkevät mitä teen! He ovat kollegoitani, he eivät vain näe, vaan myös ymmärtävät! Kauhea! Jotkut ihmiset alkavat hermostua vakavasti. Mutta kun ymmärrät, että tämä on perimmäinen tapa oppia, kaikki muuttuu. Työskentelet läheisesti ihmisten kanssa, ja jotkut ihmiset ymmärtävät aiheen paljon paremmin kuin sinä.

Michael: Mutta kaikki tämä pakottaa sinut poistumaan mukavuusalueeltasi. Insinöörinä sinun on poistuttava mukavuusalueeltasi ja kommunikoitava. Ongelmanratkaisijana sinun on jatkuvasti asetettava itsesi heikkoon asemaan ja mietittävä, mikä voisi mennä pieleen. Tämäntyyppinen työ on luonnostaan ​​suunniteltu häiritseväksi. Asetat itsesi tietoisesti stressaaviin tilanteisiin. Yleensä ihmiset pakenevat niitä, ihmiset haluavat olla onnellisia lapsia.

Tim: Mitä voidaan tehdä, voit tulla ulos ja sanoa avoimesti: ”Kaikki on hyvin, minä selviän! En ole ainoa, joka tuntee olonsa epämukavaksi. Keskustellaan erilaisista epämiellyttävistä asioista yhdessä, tiiminä!” Nämä ovat yhteisiä ongelmiamme, meidän täytyy käsitellä niitä, tiedätkö? Mielestäni omituiset nerokehittäjät ovat kuin mammutteja, ne katosivat. Ja niiden merkitys on hyvin rajallinen. Jos et osaa kommunikoida, et voi osallistua hyvin. Siksi puhu vain. Ole rehellinen ja avoin. Olen erittäin pahoillani, että tämä on jollekin epämiellyttävää. Voitteko kuvitella, monta vuotta sitten tehtiin tutkimus, jonka mukaan pääpelko Yhdysvalloissa ei ole kuolema, mutta arvaa mitä? Julkisen puhumisen pelko! Tämä tarkoittaa, että jossain on ihmisiä, jotka mieluummin kuolevat kuin sanoisivat kohteliaisuutensa ääneen. Ja mielestäni riittää, että sinulla on perustaidot, riippuen siitä, mitä teet. Puhutaitoa, kirjoitustaitoa - mutta vain sen verran kuin työssäsi todella tarvitaan. Jos työskentelet analyytikkona, mutta et osaa lukea, kirjoittaa tai puhua, sinulla ei valitettavasti ole mitään tekemistä projekteissani!

Viestinnän hinta

Oleg: Eikö tällaisten lähtevien työntekijöiden palkkaaminen ole eri syistä kalliimpaa? Loppujen lopuksi he juttelevat jatkuvasti työnteon sijaan!

Tim: Tarkoitin joukkueen ydintä, en vain kaikkia. Jos sinulla on joku, joka on todella taitava tietokantojen virittämisessä, rakastaa tietokantojen viritystä ja aikoo jatkaa tietokantojesi viritystä loppuelämänsä ja siinä kaikki, hyvä niin, jatka samaan malliin. Mutta puhun ihmisistä, jotka haluavat elää itse projektissa. Tiimin ydin, jonka tavoitteena on kehittää projektia. Näiden ihmisten on todellakin jatkuvasti kommunikoitava toistensa kanssa. Ja varsinkin projektin alussa, kun keskustellaan riskeistä, tavoista saavuttaa globaaleja tavoitteita ja muuta vastaavaa.

Michael: Tämä koskee kaikkia hankkeessa mukana olevia erikoisalasta, taidoista tai työskentelytavoista riippumatta. Olette kaikki kiinnostuneita projektin onnistumisesta.

Tim: Kyllä, sinusta tuntuu, että olet tarpeeksi uppoutunut projektiin, että sinun tehtäväsi on auttaa projektia toteutumaan. Olitpa ohjelmoija, analyytikko, käyttöliittymäsuunnittelija, kuka tahansa. Tästä syystä tulen töihin joka aamu, ja tätä teemme. Olemme vastuussa kaikista näistä ihmisistä heidän taidoistaan ​​​​riippumatta. Tämä on ryhmä ihmisiä, jotka keskustelevat aikuisista.

Oleg: Itse asiassa puheliasista työntekijöistä puhuttaessa yritin simuloida ihmisten, erityisesti esimiesten, vastalauseita, joita pyydetään vaihtamaan devopsiin, tätä aivan uutta maailmankuvaa kohtaan. Ja teidän, konsulttien, pitäisi olla tietoisia näistä vastalauseista paljon paremmin kuin minä, kehittäjä! Jaa mikä johtajia huolestuttaa eniten?

Tim: Johtajat? Hm. Useimmiten johtajat ovat ongelmien paineen alla, ja heidän on pakko vapauttaa jotain kiireellisesti ja tehdä toimitus ja vastaavat. He katsovat, kuinka jatkuvasti keskustelemme ja väittelemme jostain, ja he näkevät sen näin: keskusteluja, keskusteluja, keskusteluja... Mitä muita keskusteluja? Mene takaisin töihin! Koska puhuminen ei tunnu heille työltä. Et kirjoita koodia, et testaa ohjelmistoja, et näytä tekevän mitään - miksi et lähettäisi sinua tekemään jotain? Loppujen lopuksi toimitus on jo kuukauden päästä!

Michael: Kirjoita koodi!

Tim: Minusta tuntuu, että he eivät ole huolissaan työstä, vaan edistyksen näkyvyyden puutteesta. Jotta näyttäisi siltä, ​​että olemme tulossa lähemmäksi menestystä, heidän täytyy nähdä meidän painavan näppäimistön painikkeita. Koko päivä aamusta iltaan. Tämä on ongelma numero yksi.

Oleg: Misha, sinä ajattelet jotain.

Michael: Anteeksi, eksyin ajatuksiini ja sain takaiskun. Kaikesta tästä tuli mieleen mielenkiintoinen ralli, joka tapahtui eilen... Eilen oli liikaa mielenosoituksia... Ja kaikki kuulostaa hyvin tutulta!

Elämä ilman palkkoja

Tim: Muuten, ei ole ollenkaan tarpeen järjestää "kokouksia" viestintää varten. Tarkoitan, hyödyllisimmät keskustelut kehittäjien välillä tapahtuvat, kun he vain puhuvat keskenään. Kävelet sisään aamulla kupin kanssa kahvia, ja siellä on viisi ihmistä kokoontuneena keskustelemaan kiivaasti jostain teknisestä asiasta. Minulle, jos olen tämän projektin johtaja, on parempi vain hymyillä ja mennä jonnekin asioimaan, antaa heidän keskustella siitä. He ovat jo mukana niin paljon kuin mahdollista. Tämä on hyvä merkki.

Oleg: Muuten, kirjassasi on joukko muistiinpanoja siitä, mikä on hyvää ja mikä on huonoa. Käytätkö itse jotain niistä? Suhteellisesti sanottuna nyt sinulla on yritys, joka on rakenteeltaan hyvin epätavallinen...

Tim: Epätavallinen, mutta tämä laite sopii meille täydellisesti. Olemme tunteneet toisemme pitkään. Luotamme toisiimme, luotimme toisiimme paljon ennen kuin meistä tuli kumppaneita. Ja esimerkiksi meillä ei ole palkkoja ollenkaan. Teemme vain töitä, ja jos esimerkiksi ansaitsin asiakkailtani rahaa, niin kaikki rahat menivät minulle. Sen jälkeen maksamme yhdistykselle jäsenmaksuja, jotka riittävät yrityksen itsensä tukemiseen. Lisäksi olemme kaikki erikoistuneet erilaisiin asioihin. Työskentelen esimerkiksi kirjanpitäjien kanssa, täytän veroilmoituksia, teen kaikenlaisia ​​hallinnollisia asioita yritykselle, eikä kukaan maksa minulle siitä. James ja Tom työskentelevät verkkosivuillamme, eikä kukaan myöskään maksa heille. Niin kauan kuin maksat jäsenmaksusi, kukaan ei ajattele kertovansa sinulle, mitä sinun tulee tehdä. Esimerkiksi Tom työskentelee nyt paljon vähemmän kuin ennen. Nyt hänellä on muita kiinnostuksen kohteita, joita hän ei tee kiltalle. Mutta niin kauan kuin hän maksaa jäsenmaksunsa, kukaan ei tule hänen luokseen sanomaan: "Hei, Tom, mene töihin!" On erittäin helppoa asioida kollegoiden kanssa, kun välillänne ei ole rahaa. Ja nyt suhteemme on yksi perusideoista eri erikoisalojen suhteen. Se toimii ja se toimii erittäin hyvin.

Paras neuvo

Michael: Palatakseni "parhaisiin neuvoihin", kerrotko jotain asiakkaillesi yhä uudelleen ja uudelleen? On ajatus noin 80/20, ja joitain neuvoja luultavasti toistetaan useammin.

Tim: Ajattelin kerran, että jos kirjoittaisit kirjan, kuten Valssi karhujen kanssa, se muuttaisi historian kulun ja ihmiset pysähtyisivät, mutta... Katsos, yritykset usein teeskentelevät, että heidän kanssaan kaikki on hyvin. Heti kun jotain pahaa tapahtuu, se on heille shokki ja yllätys. "Katso, testasimme järjestelmää, eikä se läpäise järjestelmätestejä, ja tämä on vielä kolme kuukautta suunnittelematonta työtä, kuinka tämä voi tapahtua? Joka tiesi? Mikä voisi mennä pieleen? Vakavasti, uskotko tämän?

Yritän selittää, että sinun ei pitäisi olla liian vihainen nykyisestä tilanteesta. Meidän on puhuttava siitä, todella ymmärrettävä, mikä olisi voinut mennä pieleen ja miten estää tällaisten asioiden tapahtuminen tulevaisuudessa. Jos ongelma ilmaantuu, miten taistelemme sitä vastaan, miten hillitsemme sen?

Minusta tämä kaikki näyttää pelottavalta. Ihmiset käsittelevät monimutkaisia, kiusallisia ongelmia ja jatkavat teeskentelyä, että jos he vain pitävät sormensa ristissä ja toivovat parasta, "paras" todella tapahtuu. Ei, se ei toimi niin.

Harjoittele riskinhallintaa!

Michael: Kuinka moni organisaatio osallistuu mielestäsi riskienhallintaan?

Tim: Minua raivostuttaa se, että ihmiset vain kirjoittavat riskit muistiin, katsovat tuloksena olevaa listaa ja menevät töihin. Itse asiassa riskien tunnistaminen heille on riskienhallintaa. Mutta minusta tämä kuulostaa syyltä kysyä: okei, on luettelo, mitä aiot muuttaa? Sinun on muutettava vakiotoimintojasi näiden riskien huomioon ottamiseksi. Jos työssä on jokin vaikein osa, sinun on tartuttava siihen ja vasta sitten siirryttävä johonkin yksinkertaisempaan. Aloita ensimmäisissä sprinteissä monimutkaisten ongelmien ratkaiseminen. Tämä näyttää jo riskienhallinnasta. Mutta yleensä ihmiset eivät voi kertoa, mitä he muuttivat riskiluettelon laatimisen jälkeen.

Michael: Ja silti, kuinka moni näistä yrityksistä on mukana riskienhallinnassa, viisi prosenttia?

Tim: Valitettavasti en sano tätä, mutta tämä on hyvin merkityksetön osa. Mutta enemmän kuin viisi, koska on todella suuria projekteja, ja niitä ei yksinkertaisesti voi olla olemassa, jos he eivät tee ainakin jotain. Sanotaan vain, että olen erittäin yllättynyt, jos se on vähintään 25%. Pienet projektit vastaavat tällaisiin kysymyksiin yleensä näin: jos ongelma koskettaa meitä, niin me ratkaisemme sen. Sitten he joutuvat onnistuneesti vaikeuksiin ja osallistuvat ongelmanhallintaan ja kriisinhallintaan. Kun yrität ratkaista ongelman, mutta ongelma ei ratkea, tervetuloa kriisinhallintaan.

Kyllä, kuulen usein: "Ratkaisemme ongelmat sitä mukaa kun niitä ilmenee." Varmasti teemme? Päätämmekö todella?

Oleg: Voit tehdä sen naiivisti ja yksinkertaisesti kirjoittaa tärkeitä invariantteja projektin peruskirjaan, ja jos invariantit katkeavat, käynnistä projekti uudelleen. Se osoittautuu erittäin piembuckyksi.

Michael: Kyllä, minulle kävi niin, että kun riskit laukesivat, projekti yksinkertaisesti määriteltiin uudelleen. Hienoa, bingo, ongelma ratkaistu, älä huoli enää!

Tim: Paina reset-painiketta! Ei, se ei toimi niin.

Keynote DevOopsissa 2019

Michael: Pääsemme tämän haastattelun viimeiseen kysymykseen. Tulet seuraavaan DevOopsiin pääpuheenvuoron kanssa, voisitko nostaa salassapitoverhon siitä, mitä aiot kertoa?

Tim: Tällä hetkellä kuusi heistä kirjoittaa kirjaa työkulttuurista, organisaatioiden sanattomista säännöistä. Kulttuuri määräytyy organisaation perusarvojen mukaan. Yleensä ihmiset eivät huomaa tätä, mutta olemme työskennelleet konsulttina monta vuotta, olemme tottuneet huomaamaan sen. Tulet yritykseen ja kirjaimellisesti muutaman minuutin sisällä alat tuntea mitä tapahtuu. Kutsumme tätä "makuksi". Joskus tämä tuoksu on todella hyvä, ja joskus se on, no, oho. Asiat ovat hyvin erilaisia ​​eri organisaatioissa.

Michael: Minäkin olen työskennellyt konsulttina vuosia ja ymmärrän hyvin mistä puhut.

Tim: Itse asiassa yksi asioista, joista kannattaa puhua pääpuheenvuorossa, on se, että yritys ei määrää kaikkea. Sinulla ja tiimilläsi on yhteisönä oma tiimikulttuurisi. Tämä voi olla koko yritys tai erillinen osasto, erillinen tiimi. Mutta ennen kuin sanoit, tässä on se, mihin uskomme, tässä on mikä on tärkeää... Kulttuuria ei voi muuttaa ennen kuin tiettyjen toimien taustalla olevat arvot ja uskomukset on ymmärretty. Käyttäytymistä on helppo havaita, mutta uskomusten etsiminen on vaikeaa. DevOps on vain loistava esimerkki siitä, kuinka asiat muuttuvat yhä monimutkaisemmiksi. Vuorovaikutuksista tulee vain monimutkaisempia, ne eivät ole ollenkaan puhtaampia tai selvempiä, joten kannattaa miettiä, mihin uskot ja mistä kaikki ympärilläsi ovat hiljaa.

Jos haluat saavuttaa nopeita tuloksia, tässä on sinulle hyvä aihe: oletko nähnyt yrityksiä, joissa kukaan ei sano "en tiedä"? On paikkoja, joissa kirjaimellisesti kidutetaan henkilöä, kunnes hän myöntää, ettei hän tiedä jotain. Kaikki tietävät kaiken, jokainen on uskomaton oppinut. Lähestyt ketä tahansa henkilöä, ja hänen on välittömästi vastattava kysymykseen. Sen sijaan että sanoisi "en tiedä". Hurraa, he palkkasivat joukon erudiitteja! Ja joissakin kulttuureissa on yleensä erittäin vaarallista sanoa "en tiedä" se voidaan nähdä heikkouden merkkinä. On myös järjestöjä, joissa jokainen voi päinvastoin sanoa "en tiedä". Siellä se on täysin laillista, ja jos joku alkaa roskaa vastata kysymykseen, on täysin normaalia vastata: "Etkö tiedä mistä puhut, vai mitä?" ja muuta se vitsiksi.

Ihannetapauksessa haluaisit työpaikan, jossa voit olla jatkuvasti onnellinen. Se ei tule olemaan helppoa, joka päivä ei ole aurinkoista ja mukavaa, joskus pitää tehdä töitä, mutta kun alkaa arvioimaan, niin selviää: vau, tämä on todella ihana paikka, minulla on hyvä työskennellä täällä, sekä emotionaalisesti että älyllisesti. Ja on yrityksiä, joissa menet konsultiksi ja huomaat heti, että et kestäisi sitä kolmea kuukautta ja pakenisit kauhuissaan. Tästä haluan puhua mietinnössä.

Tim Lister saapuu pääpuheenvuoron kanssa "Hahmot, yhteisö ja kulttuuri: tärkeitä vaurauden tekijöitä"DevOops 2019 -konferenssiin, joka järjestetään 29.-30 Pietarissa. Voit ostaa lippuja virallisella verkkosivustolla. Odotamme sinua DevOopsissa!

Lähde: will.com