Rakensin itselleni ops-tutkan: tiedostot ja git, ei sovellus

Minulla on tällä hetkellä käynnissä useampi rinnakkainen projekti, ja niiden intake tulee sieltä mistä työkin tulee: Slack-viesteinä, palavereissa sivulauseessa mainittuina, sähköpostiketjuina joita kukaan ei enää muista avata. Yksittäinen velvoite syntyy, unohtuu, ja ilmestyy takaisin viikkoa myöhemmin kun joku kysyy missä se on. OKR:t ovat säännönmukaisesti myöhässä, en siksi että en tekisi töitä, vaan koska työ on reaktiivista: reagoin siihen mikä on juuri äänessä, en siihen mikä on oikeasti kiireellistä.

Valmis task-manageri ei tätä ratkaise, ja syy on tärkeämpi kuin itse ratkaisu jota lopulta rakensin.

Miksi valmis appi ei riitä

Task-managerit ratkaisevat yhden ongelman: mitä pitää tehdä. Minun ongelmani ei ole se. Minun ongelmani on “missä olinkaan tässä projektissa”, ja se on eri kysymys. Kun palaan projektiin viikon tauon jälkeen, en tarvitse listaa tehtävistä, tarvitsen kontekstin: mitä päätettiin viimeksi, mitkä parametrit olivat voimassa, kuka lupasi mitä ja mihin mennessä. Task-manageri säilöö rivejä. Se ei säilö sitä miksi rivi on olemassa.

Valmiiden työkalujen yhteinen virhe tässä käytössä on oletus, että velvoite on itsenäinen, kertaluontoinen rivi, jonka voi merkitä tehdyksi ja unohtaa. Minun todellisuudessani velvoitteet elävät säikeinä: yksi projekti voi olla auki viikkoja, ja sen aikana siihen kertyy uusia parametreja ja uusia riippuvuuksia muihin projekteihin, joita mikään rivipohjainen näkymä ei pidä koossa. Kun avaan projektin uudestaan, en halua nähdä siistiä tehtävälistaa, haluan nähdä mihin ajatuksenjuoksuun palaan. Se on eri tietomalli kuin mitä yksikään task-manageri tarjoaa oletuksena.

Toinen syy on käytännöllisempi. Haluan että sekä minä että tekoälyavustimeni voivat lukea ja päivittää samaa dataa. Jos data asuu jonkun SaaS-palvelun tietokannassa API:n takana, jokainen työkalu tarvitsee oman integraationsa sinne, ja se integraatio on aina se hauraimmin ylläpidetty osa koko putkesta. Jos data sen sijaan on hakemisto tiedostoja gitissä, jokainen työkalu jonka otan käyttöön osaa lukea ja kirjoittaa sitä suoraan, ilman erillistä sovitinta: editori, komentorivi, tekoälyagentti puhuvat kaikki samaa kieltä heti kun kieli on “tiedostojärjestelmä”. Tästä on tullut oma nyrkkisääntöni tekoälyaikakaudella: file over app, tiedosto ennen sovellusta.

Mitä rakensin

Ratkaisu on paikallinen git-repo, jossa velvoitteet, käynnissä olevat säikeet ja projektikohtaiset parametrit ovat strukturoituja markdown-tiedostoja. Ei tietokantaa, ei pilvipalvelua jolla on oma kirjautuminen, pelkkä hakemisto joka on samalla versionhallittu. Kun muutan jotain, git muistaa mitä muutin ja milloin.

Tämän päälle rakensin kaksi asiaa. Ensimmäinen on HTML-dashboard, joka lukee nuo markdown-tiedostot ja näyttää yhdellä silmäyksellä mikä on myöhässä ja mihin pitäisi palata. Toinen on kalenterin sisäänluku icalBuddyllä, eli komentorivityökalulla joka lukee macOS-kalenterin tapahtumat tekstimuotoon ilman että täytyy avata sovellusta tai kirjautua mihinkään erikseen. Kalenteri ja velvoitteet näkyvät siis samassa paikassa, koska ne kuuluvat samaan päätökseen: mihin tämä viikko oikeasti menee.

Intake-puoli on tekoälyavusteinen: kun kopioin Slack-viestin, jossa joku pyytää tai sopii jotain, liitän sen tekstinä sisään, ja Gemini-pohjainen jäsennin muuttaa sen strukturoiduksi velvoitteeksi, samaan tiedostomuotoon kuin muut. Ei erillistä lomaketta, ei uutta käyttöliittymää opeteltavaksi. Sama tekoälyassistentti jota käytän muutenkin lukee ja päivittää näitä tiedostoja jatkossa, kun projekti etenee tai velvoite valmistuu.

Tämä on koko rakenteen kannalta se kohta josta koko idea sai alkunsa. Intake on aina ollut hajallaan, koska työ tulee sisään sieltä missä ihmiset oikeasti puhuvat, eli Slackissa ja palavereissa, ei siellä missä minulla olisi mukava strukturoitu lomake valmiina. Ratkaisu ei siis ollut pakottaa ihmisiä käyttämään uutta työkalua velvoitteiden ilmoittamiseen. Ratkaisu oli hyväksyä että intake tulee raakana tekstinä, ja siirtää strukturointi minun puolelleni, tekoälyn tekemänä muutamassa sekunnissa. Se on pieni ero, mutta se on koko järjestelmän toimivuuden kannalta ratkaiseva: kynnys jäädä kirjaamatta on lähes olematon, koska ainoa mitä minulta vaaditaan on liittää teksti ja hyväksyä tulos.

Rajoite joka piti hyväksyä

Tämä on kohta jossa pitää olla rehellinen. Valmis appi on hölmö mutta anteeksiantava: se ei vaadi mitään sinulta, koska se ohjaa käyttäjää valikoilla ja pakollisilla kentillä. Tiedostopohjainen järjestelmä ei ohjaa mitään. Se vaatii kurinalaisuutta jota valmis sovellus ei koskaan vaatisi: jos en päivitä tiedostoa kun tilanne muuttuu, dashboard näyttää vanhentunutta tietoa eikä kukaan huomauta siitä. Ei ole pakollista kenttää joka estäisi minua unohtamasta.

Tämä on tietoinen vaihtokauppa, en sanoisi että se on ratkaistu ongelma. Luotan siihen että intake-vaihe, jossa Slack-viesti muuttuu tiedostoksi muutamassa sekunnissa, madaltaa kynnystä riittävästi että päivittäminen tapahtuu oikeasti, ei vain periaatteessa. Mutta jos jonain päivänä huomaan että tiedostot alkavat elää omaa elämäänsä irti todellisuudesta, se on merkki siitä että kurinalaisuus on pettänyt, ei että työkalu on väärä.

Sanon tämän suoraan koska se on rehellisin tapa kuvata mitä olen rakentanut: en ole ostanut itselleni kurinalaisuutta valmiina ominaisuutena, olen rakentanut työkalun joka tekee kurinalaisuuden noudattamisesta halvempaa. Ero näiden kahden välillä on koko sen väitteen ydin, jonka takana seison tässä: teknologia ei koskaan poista tarvetta tehdä oikeita valintoja säännöllisesti, se voi vain laskea sitä hintaa mikä oikean valinnan tekemisestä pitää maksaa.

Mitä tästä voi viedä omaan tilanteeseen

Jos tunnistat oman kipupisteesi tästä, eli monta rinnakkaista lankaa, hajallaan oleva intake ja jatkuva “missä olinkaan”-tunne, kannattaa kysyä ensin mikä oikeasti on ongelma. Jos ongelma on tehtävälista, valmis task-manageri riittää hyvin, eikä kannata rakentaa mitään omaa. Mutta jos ongelma on kontekstin palautus, eli tarvitset nopeasti vastauksen kysymykseen miksi jokin päätettiin ja mitä siitä seurasi, tekstitiedostot gitissä ratkaisevat sen paremmin kuin mikään sovellus jonka tietomalli on suunniteltu rivien listaamiseen. Ratkaisu ei vaadi ohjelmointitaitoa sinänsä, se vaatii sen että on valmis pitämään tiedostorakenteen yksinkertaisena ja antamaan tekoälylle tehtäväksi sekä lukea että kirjoittaa sitä.

Mitä seuraavaksi

Seuraava vaihe on viedä sama malli laajemmalle: tällä hetkellä järjestelmä kattaa oman työni, mutta osa velvoitteista syntyy yhteistyössä muiden kanssa, ja heillä ei ole pääsyä samaan git-repoon eikä pitäisikään olla. Avoin kysymys on, miten kontekstin palautus toimii silloin kun toinen osapuoli ei elä samassa tiedostojärjestelmässä: riittääkö että dashboard on jaettavissa katselulinkkinä, vai tarvitaanko jotain kevyempää siltaa, esimerkiksi Slack-botti joka osaa kysyä tilannetta suoraan tiedostoista. En ole vielä päättänyt, ja se on ihan hyvä paikka olla juuri nyt.