Kaikki alkoi kiiltävästä uudesta julkaisusta. Google oli juuri julkistanut Geminin multimodaaliset ominaisuudet – teknologian, joka vaikutti riittävän lupaavalta ratkaisemaan mahdollisesti ihmisen ja selaimen välisen vuorovaikutuksen ongelmia. Insinööritiimi ajatteli, että kyseessä olisi nopea ja vähäriskinen kokeilu.
Yksi tiimi kokeili sitä. Sitten toinen. Sitten kolmas.
Vaikka konsepti oli kiinnostava, varsinainen työkalu ei kuitenkaan ollut vielä valmis. Se oli varhaisessa kehitysvaiheessa, ei tuotantokäyttöön valmis eikä todellakaan räätälöity tiimin käyttötapaukseen.
”Se oli häiriötekijä, joka olisi voinut helposti suistaa olemassa olevien prioriteettien edistymisen raiteiltaan, ellemme olisi painaneet jarruja,” muistelee Anand Sainath, 100x:n tekniikan johtaja ja toinen perustaja, joka päätti lopettaa integraation.
Kaikilla ei kuitenkaan ole käynyt yhtä hyvä tuuri. Monilla tiimeillä ”seuraavan suuren asian” tavoittelu kaappasi hiljalleen tuotteen tiekartan. Jäljelle jäi paikka paikoin koottu kokoelma keskeneräisiä työkaluja ja sivuutettuja prioriteetteja – jotain, mitä Sainath kutsuu kiiltävien esineiden syndrooman hiljaiseksi hinnaksi.
Mikä ihme kiiltävien esineiden syndrooma oikein on?
Kiiltävien esineiden syndrooma (SOS) syntyy, kun uudet työkalut, kehykset tai teknologiat vievät tiimien huomion, usein olemassa olevien prioriteettien kustannuksella.
”Kun uusi teknologia ilmaantuu, kuten tekoälyn tapauksessa nykyään, markkinat innostuvat sen sovelluksista. Suuntaus voi luoda paineen kääntyä trendin suuntaan, jotta kilpailijoiden edellä pysyttäisiin,” sanoo Raju Malhotra, Certinian CPTO.
Silloin ”kiiltävä” työkalu tai kehys alkaa hiipiä suunnitelmiisi ja ”vetää insinöörit pois työstä, jolla on asiakkaille oikeasti merkitystä tänään.”
Evernoten tarina täyttää kaikki kiiltävien esineiden syndrooman bingokortin kohdat. Sillä oli kaikki oikeat ainekset: uskolliset käyttäjät, vankka tuote ja selkeä markkinarako. Sen sijaan, että yritys olisi keskittynyt ydinominaisuuksiinsa, se laajensi toimintaansa fyysisiin tuotteisiin ja julkaisi keskeneräisiä tuoteominaisuuksia, kuten Work Chatin.
Tuotteesta tuli paisunut, suorituskyky heikkeni ja käyttäjät siirtyivät yksinkertaisempiin työkaluihin, kuten Notioniin ja Google Keepiin. Vuonna 2022 Evernote ostettiin, ja vuoden 2023 alkuun mennessä suurin osa sen henkilöstöstä oli irtisanottu.
SOS ei aina pääty konkurssiin tai irtisanomisiin, mutta se suistaa lähes aina kehityksen raiteiltaan seuraavilla tavoilla:
- Projektin toimitusten viivästyminen: Toistuvat siirtymät uusiin teknologioihin kesken projektin voivat sekoittaa suunnittelun, häiritä toteutussyklejä ja kasvattaa suunnittelemattoman työn määrää. Juuri näin kävi FBI:n Virtual Case File -projektille. Viiden vuoden ja 170 miljoonan dollarin kulujen jälkeen projekti hylättiin osittain siksi, että muuttuva byrokraattisen ja liiketoiminnallisen yhteensopivuuden tavoittelu rikkoi jatkuvasti toimitusten rytmin.
- Insinöörikustannusten kasvaminen: Ilman uusien teknologioiden arviointiin tarkoitettua viitekehystä kiiltävien esineiden ohjaamat päätökset johtavat usein työkalujen paisumiseen, tekniseen velkaan ja korkeisiin ohjelmistokehityskustannuksiin. Tiimit käyttävät jopa aikaa prototyyppeihin, joita ei koskaan julkaista tai jotka pahempaa kyllä otetaan käyttöön ja kirjoitetaan myöhemmin uudelleen.
- Kehittäjien tuottavuuden romahduttaminen: Jokainen uusi työkalu merkitsee uutta oppimiskäyrää, lisää virheitä ja uusia ”pikakokeita”, jotka harvoin pysyvät pikaisina. Tämä hajauttaa insinöörien työpanosta, vähentää tuottavuutta jopa 40 % ja johtaa uupumukseen sekä jatkuvaan tulipalojen sammuttamiseen – energiaan, joka olisi voitu käyttää tuotteen ydinominaisuuksien rakentamiseen.
- Sidosryhmien luottamuksen rapautuminen: SOS antaa myös väärän signaalin liiketoimintajohtajille. Kun prioriteetit vaihtuvat liian usein ja aikataulut venyvät, ylin johto voi alkaa kyseenalaistaa insinööritiimin kyvyn toimittaa. Kun luottamus on menetetty, sitä on vaikea ansaita takaisin.
Vältä kiiltävän esineen aiheuttama katumus: 3 vaistonvaraista kysymystä tiimillesi
Tiedät, millaista tuhoa kiiltävien esineiden syndrooma voi aiheuttaa tiimillesi. Miten siis määrität, onko uusi kirjasto, SDK tai palvelu vaivan arvoinen – ennen kuin se kuluttaa aikaa ja keskittymiskykyä? Asiantuntijoillamme on muutama hyväksi havaittu tarkistuskysymys:
- Onko se ”kääre” vai ”laastari”?
Sainathin suodatin uusia kiiltäviä työkaluja ja teknologioita arvioitaessa on yksinkertainen: ratkaiseeko tämä jotain, jolla on pitkällä aikavälillä merkitystä, vai onko se vain laastari?
”Laastari paikkaa vain pieniä poikkeustapauksia tai peittää lyhytaikaisia rajoituksia. Mutta todennäköisesti mallin seuraava versio ratkaisee ongelman joka tapauksessa. Silloin rakentamasi ratkaisu vanhenee välittömästi.”
Häntä kiinnostaa enemmän kääreiden rakentaminen – perustamallien päälle luotuja selkeitä kerroksia, jotka tuovat todellista käytettävyyttä suunnittelun, työnkulkujen tai kontekstin avulla.
”Termi LLM-kääre sai aluksi lähes halventavan sävyn, mutta pohjimmiltaan monet arvokkaat tuotteet rakennetaan taustalla olevan teknologian päälle”, kommentoi Sainath. ”Katsokaa vaikka Cursor-ohjelmaa. Voisi väittää, että se on vain kääre, mutta se tarjoaa merkittävää ja kohdennettua arvoa.”
Hänen näkemyksensä mukaan pikaratkaisut ovat häiriötekijöitä, jotka voivat helposti muuttua kiiltäviksi kohteiksi. Hyvin suunnitelluista kääreistä voi sen sijaan tulla ydintuotteita.
- Mitä päätämme olla rakentamatta?
Malhotran mukaan sen seuraaminen, mitä tiimi päättää olla rakentamatta, on aivan yhtä tärkeää kuin sen seuraaminen, mitkä asiat päätyvät etenemissuunnitelmaan. ”Se estää meitä jahtaamasta ominaisuuksia, jotka saattavat näyttää hyvältä demossa mutta eivät tosiasiassa paranna päivittäistä työtä”, hän sanoo.
Vaikka tiimi ei olisikaan varma, että jokin asia on valmis laajempaan käyttöönottoon, he testaavat sitä silti varhaisten käyttäjien kanssa. ”Näin saamme palautetta häiritsemättä etenemissuunnitelmaa.”
- Mikä on liiketoiminta-arvo?
Customer.ion tekniikan varapääjohtajalle, Paul Senechkölle, insinöörityön taustalla olevan liiketoiminta-arvon ymmärtäminen on ensimmäinen ja kriittisin suodatin. Jos uusi työkalu tai järjestelmä ei palvele kumpaakaan, hän sanoo, sille ei todennäköisesti ole vielä oikea aika.
”Yrityksemme johtamisperiaate on, että olemme asiakkaiden asiantuntijoita”, Senechko selittää. ”Käytämme tätä periaatetta ohjaamaan teknologiainvestointejamme ja varmistamaan, että rakennamme asiakkaat ja liiketoiminnan huomioiden.”
Pitääkseen tiiminsä jalat maassa Senechko luottaa muutamaan yksinkertaiseen mutta tehokkaaseen kysymykseen: Mitä tämä maksaa meille ajan ja resurssien muodossa? Parantaako se tuotettamme? Auttaako se asiakkaitamme menestymään paremmin?
Sainath lisää oman näkökulmansa niin kutsutuilla ”mitä jos” -kysymyksillä: ”Mitä tapahtuu, jos taustalla oleva teknologia kehittyy kymmenen kertaa paremmaksi? Paraneeko tuotteemme luonnostaan vai muuttuuko se yhtäkkiä merkityksettömäksi?”
Hän selvittää myös, millaisia ponnisteluja näiden parannusten toteuttaminen vaatii: ”Hyödymmekö näistä parannuksista automaattisesti vai vaatiiko niiden hyödyntäminen merkittävää uudelleenarkkitehtuuria?”
Näiden skenaarioiden läpikäyminen tiimin kanssa voi auttaa tekemään päätöksen siitä, asetetaanko uusi kiiltävä teknologiapino etusijalle vai pitäydytäänkö siinä, mikä jo toimii.
Etenemissuunnitelman suojaaminen kiiltävien esineiden oireyhtymältä (innovaatioita tappamatta)
Kun innostava uusi teknologia rikkoutuu, siihen on suhtauduttava varauksella ja innovaatiot on tasapainotettava todellisen edistymisen kanssa.
Näin teknologiajohtajat hallitsevat FOMOa ja pitävät tiiminsä jalat maassa sekä keskittyneinä:
- Määrittele projektien lopetuskriteerit ennen aloittamista
Monet ”tutkivat” teknologiakokeilut muuttuvat pitkäkestoisiksi sivuprojekteiksi, joiden laajuus kasvaa vähitellen ja tekninen velka uusiutuu, lähinnä siksi, ettei kukaan määrittele, miten tai milloin ne päättyvät. Jos omistajuutta, aikataulua tai onnistumiskriteerejä ei ole, on vain ajan kysymys, milloin kiiltävien esineiden oireyhtymä ajaa koko hankkeen karille. Tämän välttämiseksi kohtele jokaista teknologiakokeilua kuin tuoteominaisuutta: rajaa sen laajuus, määritä sille aikaraja ja omistaja sekä ohjaa sitä todellisen käyttötapauksen avulla.
Kuten Senechko asian ilmaisee: ”Soveltakaa niitä pieniin mutta todellisiin käyttötapauksiin ja edetkää siitä. Kun päätämme kokeilla uusia trendejä, varmistamme, että tunnistamme pienen tai hyvin rajatun kohteen, jossa voimme testata ja varmistaa, että tämä toimii. Näin voimme kokeilla teknologiaa ja hankkia siitä todellista kokemusta ennen kuin teemme siihen suuren panostuksen.”
Ota mukaan monialainen arvioija (EM + PM + henkilöstötason insinööri) objektiivista arviointia varten ja laadi jäsennelty aikataulu, joka sisältää:
- Enimmäiskesto: Rajoita kesto kahteen sprinttiin (+1 puskurisprintti), jotta kokeilu pysyy kevyenä ja testattavana
- Jatketaanko vai ei -välietapit ja lopetusehdot: Määrittele selkeä arviointihetki, jolloin tiimi päättää jatkaa, iteroida tai lopettaa (yli 10 % koonneista epäonnistui tai integraatio CI/CD-työkaluun puuttuu).
Senechko ehdottaa jopa, että tiimit kokeilevat kiinteän ajan ja muuttuvan laajuuden hankkeita, joissa tiimi määrittää aluksi ”panostushalukkuuden” eli sen, kuinka paljon aikaa se on valmis käyttämään, ja pyrkii tuottamaan arvokkaimman lopputuloksen kyseisen ajanjakson aikana. ”Tämän ansiosta olemme voineet innovoida ja epäonnistua nopeasti, kun uudet suunnat eivät vaikuta vievän oikeaan suuntaan.”
- Mittaa onnistumista mittareiden avulla
Kun tekninen toteutettavuus ja tekniseen työhön tarvittava työmäärä on ymmärretty, määrittele, miltä onnistuminen näyttää. Se erottaa kurinalaisen käyttöönoton laajuudeltaan hallitsemattomaksi kasvavasta SOS-projektista. Rakenna kehys, joka mittaa onnistumista useilla ulottuvuuksilla:
- Ihmiset: Kehittäjien tuottavuuden kasvu, syvälliseen työhön käytettyjen tuntien lisääntyminen
- Prosessit ja työnkulut: Testikokoelman lyhyempi suoritusaika, regressioiden vähentyminen, kevyemmät julkaisutyönkulut, markkinoille saattamiseen kuluvan ajan lyheneminen
- Asiakaskokemus: Parempi sivujen suorituskyky, vähemmän UX-valituksia, paremmat vasteajat
- Järjestelmän suorituskyky: Nopeampi laskenta, pienemmät infrastruktuurikustannukset, vähemmän häiriöitä tai palautuksia
- Tunne asiakkaasi
“Aikataulussa pysyminen riippuu siitä, että olemme rehellisiä siitä, missä asiakasarvo syntyy,” Malhotra väittää. “Trendit voivat kuulostaa innostavilta, mutta niistä voi nopeasti tulla häiriötekijöitä, jos ne eivät suoraan auta asiakkaita tekemään työtään paremmin tai nopeammin.”
Tämä periaate näkyy siinä, miten monet tiimit yhdistävät nykyään tuote- ja teknisen kehityksen asiakaspalveluun reaaliaikaista seuraamista varten. Muutama insinööri osallistuu tukipuheluihin, perehdytysistuntoihin tai asiakastapaamisiin saadakseen aitoa, suodattamatonta palautetta. Omakohtainen kuuleminen siitä, mikä hämmentää käyttäjiä, mikä rikkoutuu ja mistä annetaan kiitosta, lisää empatiaa ja voi jopa terävöittää teknisten tiimien priorisointia.
Pelkkä kuunteleminen ei kuitenkaan riitä. Tunnistaaksesi, missä asiakkailla todella on vaikeuksia, täydennä laadullista palautetta tuotteen telemetriatiedoilla. Todennäköisesti analytiikkatyökalusi (PostHog, Amplitude, Heap) on tähän tarkoitukseen vajaakäytössä. Aloita seuraamalla, miten käyttäjät todella ovat vuorovaikutuksessa tuotteen kanssa: aina napsautuksista, valintakytkimistä ja navigointisilmukoista virhepolkuihin asti.
Yhdistä nämä käyttäytymistiedot tukipyyntöihin löytääksesi malleja. Jätetäänkö ominaisuus huomiotta, koska sitä on vaikea löytää? Eivätkö käyttäjät pysty suorittamaan kriittisiä työnkulkuja loppuun? Käytä näitä vahvoina signaaleina asiakaskeskeisille pilottiprojekteille.
Ajan myötä rakennat orgaanisesti "asiakkaan ääni" -lomakkeen, joka sisältää asiakkaiden kipupisteet, palautteen, ilonaiheet ja toistuvat esteet, jotka kulkevat menestystiimeiltä tuote- ja teknisen kehityksen päätöksiin.
Se on sama järjestelmä, jota Senechkon tiimi käytti priorisoidessaan työtä mitattavan asiakasarvon perusteella: “Suuri asiakasmäärä ja alhaiset viivevaatimukset ovat ajaneet tiimimme keksimään ratkaisuja, joita valmiit tekniikat eivät olisi pystyneet toteuttamaan. Tekniseen alustaamme investoiminen kuuluu yrityksemme DNA:han, sillä olemme nähneet sen hyödyt asiakkaille ja liiketoiminnalle.”
Loppujen lopuksi teknisen kehityksen todellinen edistys syntyy uusien ominaisuuksien suunnittelusta niin, että ne laajentavat jo toimivaa, ei rakentamalla sen ympärille tai liittämällä siihen jotakin täysin uutta. Näin tiimit kehittyvät rikkomatta hyväksi havaittuja järjestelmiä.
“Innovoinnin ei tarvitse tarkoittaa mullistamista. Sen pitäisi vahvistaa jo toimivaa ja auttaa asiakkaita etenemään nopeammin pienemmällä vaivalla,” Malhotra tiivistää.
Haluatko lisää tällaisia näkemyksiä? Tilaa The CTO Clubin uutiskirje.
