Jeremy Freeman, Allstacksin perustaja ja CTO – Haastattelusarja

Jeremy Freeman, Allstacksin perustaja ja CTO, on ohjelmistosuunnittelija, teknologia-arkkitehti ja yrittäjä, jolla on ura, joka kattaa ohjelmistokehityksen, laitteistosuunnittelun, koneoppimisen ja tuoteinnovaation. Allstacksin perustamisesta lähtien hän on johtanut yrityksen ydinalustan arkkitehtuurin ja kehityksen, ja auttanut muuttamaan ohjelmistojen toimituksen hallintaa ennustavan analytiikan ja tekoälyohjatun ennustamisen avulla. Ennen Allstacksia Freeman toimi johtotehtävissä Ravioli Labsissa ja CertiRxissä, missä hän työskenteli ohjelmistosuunnittelun, tutkimuksen, vastakopioinnin estämisen teknologioiden ja tuotekehityksen parissa. Uransa alussa hän sai kokemusta startup-yrityksistä, yritysteknologiayrityksistä ja akatemiasta, mukaan lukien web-kehityksen opettamisen Wake Technical Community Collegessa. Hänen tekninen taustansa kattaa upotetut järjestelmät, laitteistosuunnittelun, suurten ohjelmistojärjestelmien, koneoppimisen ja insinöörijohtamisen, mikä antaa hänelle ainutlaatuisen näkökulman datalähtöisten tuotteiden rakentamiseen, jotka auttavat organisaatioita parantamaan ohjelmistojen toimitustuloksia.

Allstacks on ohjelmistosuunnittelun älykkyys- ja arvoverkkohallintaplatforrmi, joka auttaa organisaatioita parantamaan ohjelmistojen kehityksen ennustettavuutta ja tehokkuutta. Alusta yhdistää dataa työkaluista, joita käytetään ohjelmistokehityksen elinkaaren aikana, mukaan lukien projektin hallinta, lähdekoodin hallinta ja käyttöönottojärjestelmät, ja soveltaa tekoälyä ja koneoppimista tunnistamaan riskit, ennustamaan toimitustuloksia ja tarjoamaan toiminnallisia oivalluksia. Tarjoamalla insinööri- ja tuotejohtajille näkyvyyttä projektiin, tiimin suorituskykyyn ja kehitystrendeihin, Allstacks mahdollistaa organisaatioiden tehdä perustuvampia päätöksiä, vähentää toimituksen epävarmuutta ja paremmin kohdistaa insinööritoimet liiketoimintatavoitteisiin. Sen teknologia on suunniteltu auttamaan yrityksiä siirtymään intuitiopohjaisesta suunnittelusta käyttämällä reaaliaikaisia operatiivisia tietoja parantamaan ohjelmistojen toimitussuorituskykyä ja strategista suorituskykyä.

Olet ollut mukana ainutlaatuisessa matkassa, jossa olet johtanut tutkimus- ja insinööritiimejä, jotka soveltavat koneoppimista ohjelmistokehityksen dataan, ja perustanut Allstacksin vuonna 2017. Mitkä tarkat aukot tai toistuvat ongelmat havainnoit, jotka lopulta johtivat yrityksen perustamiseen?

Kun aloimme Allstacksin, vietimme paljon aikaa asiakaskehityksessä, ja havainnoimme, että yritys toisensa jälkeen oli valtavat määrät dataa, mutta silti ei tiennyt, mitä oli todella tapahtumassa. Ohjelmistojen toimitus oli epävakaa, vaikka huoneessa oli joitakin älykkäimmistä ihmisiä. Tätä ongelmaa ei ollut ratkaistu.

Se, mikä selvisi nopeasti, ei ollut raportointiongelma tai integraatio-ongelma. Se oli suhdeongelma. Jos haluat tietää, onko jokin asia vaarassa, sinun on tiedettävä, miten työkohteet liittyvät haaraan, haara liittyy PR: ään, PR liittyy sprinttimaaliin ja sprinttimaali liittyy liiketoimintainnovaatioon. Tämä graafi ei ole olemassa oletusarvoisesti missään työkaluissa. Sinun on rakennettava se. Rakentaminen on perustavanlaatuinen inference-ongelma, jossa koneoppimistausta tulee suoraan hyödyksi.

Aloittaessamme tavoitteena ei ollut tehdä yksittäinen kehittäjä nopeammaksi ominaisuudessa X. Sen sijaan tavoitteena oli tehdä koko organisaatio paremmaksi. Miten voit kohdistaa insinööritoimet liiketoimintatuloksiin? Miten voit tehdä insinööritoiminnasta todella palvelevan liiketoimintaa, sen sijaan, että se vain on olemassa liiketoiminnan rinnalla? Sinun on tarvittava parempi ymmärrys datasuhteista vastata näihin kysymyksiin. Nämä kysymykset ovat ohjanneet lähes jokaista tuoteptsuomme.

Allstacks keskittyy analysoimaan dataa koko ohjelmistokehityksen elinkaaren ajan. Mitkä signaalit tai mallit ovat eniten ennustettavissa, kun on kyse siitä, tunnistetaanko toimitusriski aikaisin?

En usko, että on yksittäinen joukko mittareita, jotka ennustavat hyvää ja huonoa, vaan pikemminkin eri vaiheiden ja organisaatioiden mallit. Mitä olen havainnut hyödyllisemmäksi, on tunnistaa, että insinööriorganisaatiot kulkevat parantamisen kauden läpi. Tässä kuussa se on tietokannan suorituskyky. Seuraavassa kuussa se on joukkueiden välinen viestintä. Sitten se on “miksi emme voi sulkea mitään PR: ä?” Sitten se on havainnointi. Insinöörijohtajana olet uimassa signaaleissa: jotkut ovat diagnostisia, jotkut ovat valvontaa ja paljon niistä on vain melua.

Mitä auttaa, on aloittaa ongelman, jonka todella näet, eikä mittarilla, jonka haluat parantaa. Jos kysyt “miksi tuntuu, että toimitamme vähemmän kuin viime vuonna”, se on oikea lähtökohta. Siitä lähtien luulen, että tarvitset kolmea tyyppisiä mittareita: ensinnäkin, miten tiedät, onko ongelma todellinen (ehkä PR-laskuri kehittäjää kohden ajan myötä); toiseksi, mitkä muutokset teet ja miten seuraat niitä matkalla (sanotaan, agenteille PR-arvostelun omaksumista, jos se on interventio); ja kolmanneksi, kuinka merkittävä ongelma on liiketoiminnalle. Instinktisi saattaa olla oikein, että toimitat 20 prosenttia vähemmän koodia, mutta todellinen tarina saattaa olla, että laadunvarmistus kestää nyt kolme kertaa kauemmin. Tarvitset kaikki kolme linssien nähdäksesi, onko ratkaisemassa oikeaa asiaa.

Olet työskennellyt useissa aloissa, kuten terveydenhuollossa, energiassa ja teknologiassa. Miten haasteet ohjelmistojen toimituksessa eroavat näiden alojen välillä, ja miten se on muokannut Allstacks-alustaa?

Arvostan todella kokemustani ei-puhdas teknologia-alan aloilla. SaaS-yrityksissä on helppo eksyä ajatuksessa, että itse ohjelmisto on tavoite. Kun olet liiketoiminnassa, jossa et myy suoraan ohjelmistoa, roolisi muuttuu paljon selkeämmäksi: teknologia on siellä tukemaan liiketoimintaa. Usein sanon, että jos liiketoiminta voisi saavuttaa kaiken samalla nopeudella ilman, että heidän tarvitsisi koskea minuun, he valitsisivat sen ilman epäröintiä.

Se näkökulma on todella hyödyllinen. Se kontekstualisoi, mitä teemme tässä alalla, ja se asettaa paljon teknisiä kiistoja takaisin paikoilleen. Liiketoiminta ei välitä, käytätkö Pythonia vai Go: ta. Käyttämällä syklejä uudelleenkirjoittamiseen ei todennäköisesti ole se, missä todellinen tuotto on.

Mitä pysyy koko ajan samana kaikissa aloissa, on fragmentaatio-ongelma. Riippumatta alasta, jokaisella insinööriorganisaatiolla on dataa hajallaan kymmenissä työkaluissa, joilla on rajoitettu yhteys toisiinsa. Yksityiskohdat vaihtelevat: säännellyt alat ovat pidemmän suunnittelujakson ja matalamman epävarmuuden sietokyvyn alalla, koska väärän asian rakentamisen kustannus on korkeampi. Korkean nopeuden teknologia-yritykset kerryttävät piilevää velkaa nopeammin. Mutta perusvirhe on sama. Tiimit voivat kertoa, mitä on toimitettu. He eivät voi jäljittää, miksi jokin asia lipsahti, mitä se maksoi tai missä riski oli näkyvissä ennen kuin se muuttui ongelmaksi. Se on se, mitä Allstacks-alustan rakentamisessa on muokannut.

On kasvava kertomus, jonka mukaan tekoäly nopeuttaa itse koodaamista, mutta paljastaa heikkoudet muualla. Miksi vaatimukset, suunnittelu ja määrittelyvalmius muuttuvat todellisiksi pullonkauloiksi?

Näen tämän päivittäin. Hyvän agentin ja vankkaan harniin kanssa voit siirtyä ideasta, jopa suoraan asiakkaan suusta, tuotantoon muutamassa tunnissa.

Osittain, mikä tekee tämän muutoksen niin merkittäväksi, on muutos palautusilmassa. Copilot-tyyppisillä työkaluilla ihminen on silmukassa jokaisen ehdotuksen kohdalla. Tekoäly tarjoaa täydennystä; hyväksyt tai hylkäät sen välittömästi. Kun se on väärin, saat sen nopeasti. Räjähdysalue on yksi koodirivi. Agenteille koodaus toimii eri tavalla: annat agenteille tavoitteen, se hajottaa työn, suorittaa monivaiheisen suunnitelman ja toimittaa toimivan moduulin. Ihminen tarkistaa tuloksen, ei jokaista askelta. Kun määrittely on väärä, agentti rakentaa koko toteutuksen väärään määrittelyyn, ja huomaat sen tarkistuksessa.

Se kuulostaa puhdas etu, kunnes tunnistat, mitä aiempi viiveaikka todella teki. Viiveaikka palveli todellista tarkoitusta. Useat kierrokset älykkäiden ihmisten tarkastelua, suunnittelua, testausta ja työskentelyä ideoinnin parantamiseksi.

Houkutus on nyt ohittaa kaikki tämä. Mutta agentit ja harnaat eivät ole valmiit koko SDLC: lle vielä. Nopeus on todellista. Laadun valvonta, joka aiemmin tapahtui kaikkien nopeampien askelten aikana, ei ole korvattu. Se on aukko.

Monet organisaatiot mitätöivät edelleen tuottavuutta vanhentuneilla mittareilla. Mitä johtajat ymmärtävät väärin tuottavuudesta tekoälyohjatussa kehitysympäristössä?

Ihmiset ovat kehittyneet tässä aiheessa merkittävästi, kun Allstacks aloitti. Mittaus on siirtynyt asioihin, jotka todella merkitsevät, ja kehykset ovat muodostuneet monimutkaisemmiksi. Tekoäly kääntää kaiken ylösalaisin.

Perinteinen ohjelmistokehitys oli perustavanlaatuinen rajoitus siitä, kuinka nopeasti kehittäjä voi kirjoittaa koodia, joka täyttää liiketoiminnan ja perustavanlaatuisten teknologioiden vaatimukset. Se kustannus lähestyy nollaa. Mitä olemme siirtymässä, on järjestelmään, jossa yksittäinen kehittäjä on agenteille johtaja. Se malli vaatii täysin erilaisen lähestymistavan tuottavuuden mittaamiseen, joka perustuu johonkin muuhun kuin tokenien tuotantoon tai kehittäjän tunteihin.

Osittain vaaraa nykyisissä mittareissa on, että ne piilottavat, mitä todella tapahtuu tiimitasolla. Seniori-insinöörit, joilla on tekoälytyökalut, kasvattavat etuaan: heillä on koodipohjan konteksti ja tuomio valvoa agenttien tuotosta ja löytää sen epäonnistumiset. Aikaisempien urheilijoiden insinöörit tuottavat samaa määrää koodia, mutta viettävät enemmän aikaa agenttien tuotannon tarkastamiseen, jota he eivät voi täysin arvioida. Kokonaisnopeus näyttää hyvältä, ehkä jopa parantuneelta. Ero näiden ryhmien välillä ei näy missään standardiruudussa. Oikea kysymys, jota kannattaa aloittaa, ei ole “kuinka nopeasti menemme”, vaan “kuinka paljon siitä, mitä toimittimme, oli oikein ensimmäisellä kerralla”.

Emme ole saavuttaneet vielä konsensusta oikeasta mittausmallista, mutta tiimit, jotka alkavat seurata tuotoksen laatua ja uudelleen työn määrää, eivät vain läpimurtoa ja omaksumista, ovat paremmin asemissa kuin tiimit, jotka odottavat, että joku muu ratkaisee sen.

Platformatkonnektoida tietoa työkaluista, kuten projektin hallintajärjestelmistä ja koodivarastoista. Kuinka tärkeää on yhdistää nämä hajanaiset tietolähteet, ja mitä tapahtuu, kun organisaatiot eivät onnistu siinä?

Allstacks on ollut menestyksekäs tässä alalla, koska olemme rakentaneet kontekstigraafeja ennen kuin se oli termi. Tunnistimme aikaisin, että yhdistämällä kaiken datan yhteen oli välttämätöntä vastata asiakkaiden todellisiin kysymyksiin.

Kun yhteys ei ole olemassa, tekoäly, joka toimii insinöörijärjestelmillä, voi nähdä vain osan kuvaa. Se voi analysoida, mitä on projektin hallintajärjestelmässä. Se voi analysoida, mitä on koodivarastossa. Mitä se ei voi tehdä, on jäljittää toimitusviivästystä estävään riippuvuuteen kolmen työkalun välillä, koska suhde näiden signaalien välillä ei ole datatasolla. Saat vain pinnallisen analyysin, ja itsevarmat, väärät suositukset. Mallin laatu ei ratkaise tätä. Voit asettaa kyvykkäimmän mallin saatavilla olevan raakojen API-integrointien päälle ja silti jättää väliin todellisen ongelman syyn, koska data ei koodaa suhdetta signaalien välillä. Roska sisään, roska ulos, riippumatta siitä, kuinka älykäs malli on.

Se yhteys on perusta. Se on se, mikä mahdollisti meille olla ensimmäinen markkinoilla kyvyillä, jotka eivät ole vielä toistettu.

Kun tekoälyagentit muuttuvat kehitystyön prosessin osaksi, miltä näyttää hyvin valmistautunut insinööriorganisaatio verrattuna siihen, joka ei ole valmistautunut?

Ironisesti se ei ole kovin erilainen kuin olla valmistautunut tuomaan kesäharjoittelijoita. Tarvitset vankat automaattiset testisarjat, hyvän dokumentaation, kypsyn CI/CD-putken ja varmistukset, jotka asetat, kun lisäät luotettavan, mutta koulutetun kehittäjän tiimiin.

Mitä on myös tärkeää, ja mitä ihmiset usein aliarvioivat, on tulla takaisin perusasioihin säännöllisesti: agenteillesi säännöt, AGENTS.MD-tiedostot. Voit tehdä hyvän ensimmäisen kierroksen, mutta on helppo päätyä rytmiin, jossa toimit uudella tavalla ja unohtua, että voit kouluttaa pois paljon huonoja oletuksia. Asioiden kaltaiset opettaminen agenteille suorittamaan testejä ennen jokaista sitoutumista ei vaadi ihmisen muistutusta joka kerta.

Yksi diagnostinen kysymys, jonka asetan insinöörijohtajalle, on: voitko kertoa, mitä agenteille tuottivat viime sprintissä, kumpi tuotosta hyväksyttiin sellaisenaan ja kuka revisioon kohdistui? Jos voit vastata siihen, sinulla on välineet parantamiseen. Jos et voi, lennät tunteella.

Olet korostanut insinööritoiminnan ja liiketoimintatulosten välisen yhteyden tärkeyttä. Miten organisaatiot voivat siltaa tämän aukon käytännöllisellä ja mitattavalla tavalla?

Olen nähnyt kaksi pääasiallista epäonnistumisen mallia. Ensimmäinen on yritykset, jotka eivät pari insinööritiimejä tuotteiden kanssa. Monet tiimirakenteet ovat perintöjärjestelmiä, jotka ovat olleet paikallaan pitkään. Yksi tiimi saattaa omistaa osan kolmesta eri tuotteesta, kun taas toinen omistaa neljä kokonaan. Insinööritoimen panostus laskee pääasiassa henkilöstöön, ja kun tiimit eivät ole kohdistettu tuotteisiin, se muodostuu hyvin vaikeaksi nähdä, missä liiketoimintaoletukset poikkeavat todellisuudesta.

Toinen epäonnistumisen malli on, ettei oteta huomioon kaikkea työtä, joka menee ohjelmistojen rakentamiseen ja ylläpitämiseen. On valtava luokka liiketoimintanäkymättömää insinööritoimintaa. Lempi-esimerkkini on pakkauksien päivittäminen. Ei-tekniikkaa harjoittavat liiketoimintajohtajat usein kamppailevat ymmärtämään arvon tai miksi se on jatkuva ja epävarma. Mutta he voivat ymmärtää investointiluokkia. Jos kehrammalla sitä “kriittisiä turvallisuuspäivityksiä” ja näytät keskimäärin, kuinka paljon kapasiteettia se kuluttaa, puhut heidän kieltä, jota he voivat työskennellä.

Jos kysyt myyntijohtajalta valita npm-paketteja ja ominaisuutta, jota he tarvitsevat sulkea kauppa, ominaisuus voittaa aina. Mutta jos kehrammalla sitä “olemme ulos SOC: n mukaisuudesta tai toimitamme tämän ominaisuuden”, nyt osoitat heille kaksi vaihtoehtoa, joita he voivat todella arvioida. Se uudelleenmuotoilu on koko peli. Olemme nähneet asiakkaiden leikkaavan ja kehittävän R&D-kapitalisaatioreportointiajakson yli kolmanneksen tekemällä tämän työn luokan automaattiseksi eikä manuaaliseksi. Mekanismi on sama, riippumatta siitä, onko tavoitteena pääomarahastus, henkilöstöperustelut, AI: n hyötyjen osoittaminen: yhdistetty data korvaa korreloivat taulukot.

Kokemuksesi sekä käytännön insinööritoiminnasta että web-kehityksen opettamisesta, miten kehittäjien rooli muuttuu, kun tekoäly ottaa enemmän koodauksen työn?

Rehellisesti sanottuna olen hieman huolissani, vaikka luotan, että älykkäät ihmiset ratkaisevat sen.

Minun huoleni ovat todellisia. Uudet valmistuneet tulevat työelämään, eivätkä ole koskaan koodanneet maailmassa ilman koodaamisagentteja. Onko koulutus kestänyt mukana? Työkalut liikkuvat nopeasti; korkeakoulut eivät aina liiku rinnalla. Toinen muutos, jota seuraan, on seniori-insinöörien ja seniorituoteihmisten välinen raja. Menestyksekkäimmät käytännön toimijat uudessa mallissa ovat insinöörit, jotka ovat syvästi sitoutuneita tuoteajatteluun.

Mitä tulee arvokkaammaksi, on tuomio: kyky määritellä ongelmaa tarpeeksi tarkasti, jotta agentti voi ratkaista sen, arvioida, onko ratkaisu oikein, ja löytää hienot virheet, jotka menevät CI: n läpi, mutta luo arkkitehtuurin ongelman myöhemmin. Seniori-insinöörit kasvattavat etuaan: heillä on koodipohjan konteksti ja tuomio ohjata agenttien tuotosta ja tietää, mille tuotoksille voidaan luottaa. Huoleni on aikaisemman urapolun kehittymisessä. Perinteinen tapa rakentaa tuomio oli kirjoittaa paljon koodia ja oppia virheistä. Se palautusilmakierros muuttuu tavalla, jota ala ei ole vielä täysin työskennellyt läpi.

Historia tarjoaa kuitenkin jonkinlaista lohdutusta. Oli merkittävä joukko ihmisiä, jotka uskoivat, että kääntäjät poistaisivat assembly-kehittäjät. Teknologiamuutos tapahtui heidän ennustamallaan tavalla. Mitä tapahtui kehittäjille, jotka eivät seuranneet samaa käsikirjoitusta? Seuraavan vuosikymmenen aikana kehittäjien kokonaismäärä kasvoi. Monet assembly-ohjelmoijat oppivat uuden kielen ja menestyivät perustuvan tietämyksensä ansiosta. Luulen, että versio tästä mallista toistuu uudelleen.

Katsoessaan eteenpäin, miten tekoäly muokkaa ohjelmistokehityksen elinkaarta seuraavien kolmen vuoden aikana, ja missä yritykset saavat suurimman kilpailuedun?

Näemme tulevan ominaisuusaseen, jota emme ole koskaan nähneet. Kun kustannus rakentaa lähestyy nollaa, yritykset, myös suuret, kohtaavat uuden rajoituksen: keräämisen ja vahvistamisen riittävästi asiakaspalautetta laadukkaiden asioiden rakentamiseksi suuressa mittakaavassa.

Muutos, joka on tapahtumassa, on se, että rakennettavan asian kynnys on noussut. Nykyinen rajoitus useimmissa insinööriorganisaatioissa on yksinkertainen: viisi ylintä prioriteettia, ehkä kaksi toimitettua. Agenttien kanssa suhde kääntyy. Sinulla saattaa olla viisi ylintä, kymmenen seuraavaa ja kaksikymmentä ehkä. Ja toimitat sata. Kysymys, jota kukaan ei ole vielä täysin vastannut, on, miten pidät ne viimeksi 65 oikein suunniteltuina ja toteutettuina.

Kaksi asiaa, joihin olen melko varma kolmen-vuoden ikkunassa. Ensinnäkin, kilpailuetu insinööritoiminnan tekoälyssä tulee kontekstin syvyydestä ja leveydestä, ei mallin laadusta. Mallit tulevat pöytälaatikkoon; jokaisella työkalulla on kyvykkäitä. Se, mikä erottaa johtavat alustat, on, kuinka syvästi ne ymmärtävät yrityksesi: repot, tiimirakenne, toimitushistoria, käyttöönotto- ja jakaumismallit. Työkalut, jotka tuntevat järjestelmäsi, tuottavat perustavanlaatuista erilaisia vastauksia kuin ne, jotka eivät tee. Toiseksi, siirtyminen reaktiivisesta proaktiiviseen. Nykyiset työkalut vastaavat kysymyksiin, kun kysyt. Johtavat työkalut tulevat tarkkailemaan jatkuvasti ja paljastamaan riskin ennen kuin kysyt. Organisaatiot, jotka rakentavat tämän kontekstikerroksen nyt, kasvattavat etuaan. Seuraavan sukupolven työkalujen on ratkaistava laadun ongelma suuressa mittakaavassa, ja organisaatiot, jotka ratkaisevat sen ensin, saavat todellisen etun.

Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa vierailla Allstacks-sivustolla.