Fiksuimmat meistä arvioivat teknistä työpaikkaa hakiessa yritystä vaikkapa Joel Testin avulla. Jos kuitenkin haluat työskennellä teknologiaroolissa yrityksessä jonka ohjelmistotyön johtamisen kypsyys ei vielä yllä ihan tälle tasolle, voi olla viisasta varmistaa selustasi ainakin peruskysymyksissä. Tässä kirjoituksessa käyn läpi miten voit selvittää tulevan työpaikan osalta itseltäsi seuraavan keskeisen kysymyksen laidan: Vastaavatko saatavilla olevat olosuhteet ja resurssit työkuormaa, jota sinun odotetaan hoitavan?
Jos sinulle sattuu ohjelmistotyötä tehdessäsi koskaan ei-tekninen pomo tai projektijohtaja, on tärkeää tunnistaa, kuinka erilaiseksi oma näkökulmasi on ohjelmistokehitystä tehtyäsi jo kehittynyt. Saatat pitää itsestäänselvyytenä monia asioita työstä, jotka eivät ole pomollesi helppoja ymmärtää.
Yksi teema, jossa näkökulmaero tyypillisesti näkyy, on ohjelmistoprojektien työmäärän arviointi. Sinulle koodarina on normaalia, että kun lähetään toteuttamaan muutosta tai uutta ominaisuutta olemassaolevaan ohjelmistoon tai palveluun, työmäärä riippuu monesta asiasta.
Olet ymmärtänyt, että koodari seisoo aina jättiläisten olkapäillä. Se, kuinka paljon supervoimia sinulla projektissa on, riippuu siitä, minkä jättiläisen olet valinnut (tai toiset ennen sinua ovat valinneet)! Toisin sanoen, toteutukseen ja työmääräarvioon vaikuttaa paljon se, mitä teknologioita on käytössä, ja mitä teknologiavalintoja projektissa on aiemmin tehty.
Yksittäisen ohjelmiston tasolla tämä kysymys on tarkemmin: Mikä ohjelmiston nykyinen arkkitehtuuri on? Minkä muutosten tekemiseen se on suunniteltu helpoksi? Mitkä aiemmat valinnat ovat niin sisäänrakennettuja ohjelmiston peruslogiikkaan, että niiden muuttamiseen pitäisi muuttaa koko ohjelmiston perusrakenne?
Vaikka muutos usein näyttää käyttäjän (pomon) käyttäjästä yksinkertaiselta, on siis täysin mahdollista, arkkitehtuuria ei ole suunniteltu ohjelmiston muuttamiseen pyydetyllä tavalla. Muista, että jos olet työsuhteessa, on työnantajan velvollisuus taata työturvallisuutesi ja siten myös varmistaa, että työtehtävät on mahdollista tehdä tarjotuissa olosuhteissa ja tarjotuilla resursseilla.
Koska ei-tekninen pomosi ei välttämättä ymmärrä ylläolevaa, keskustelussa on helppo joutua karikkoon. On tyypillistä että joudut ei-teknisen pomosi tai asiakkaan kanssa tilanteeseen, jossa hän on jyrkästi sitä mieltä, että tietyn ominaisuuden pitäisi olla helppo homma. Viisitoista minuuttia, tai korkeintaan pari tuntia. Lisäät vaan sen yhden nappulan tai sarakkeen tohon.
Keskustelun edetessä, epämukavuuden tunteesi kasvaa. Tässä kohtaa kannattaa ystävällisesti mutta taipumatta puolustaa tosiasioita. On selvää, että työmäärä ei aina ole suhteessa arvoon jota asiakas kokee saavansa. Se ei ole aina suhteessa myöskään muutoksen näennäiseen monimutkaisuuteen pinnasta käsin katsottuna.
Jos tilanne tulehtuu, ota ehdottomasti yhteyttä työpaikkasi ja viime kädessä työsuojeluvaltuutettuun. Tee tämä kun vielä olet työsuhteessa. Tämä voi tuntua hankalalta ollessa osa työyhteisöä. Työsuhteen purkauduttua työnantajaa kuitenkin on paljon vaikeampaa saada vastuuseen väärinkäytöksistä.
Nämä ovat perusasioita. Valitettavasti moni teknologiajohtajaksi itseään kutsuva ei Suomessakaan silti vielä hahmota, että ohjelmiston käyttöliittymä nimenomaan on rakennettu piilottamaan kaikki pinnan alla oleva monimutkaisuus. On itsestäänselvyys, ettei pelkkää pintaa katsomalla siksi voi päätellä kuinka vaikea jokin tietty työ on!
Itselläni on kokemusta tilanteista, joissa tilanne olisi vielä yksinkertainen, jos ongelmat päättyisivät tähän. Usein ei-teknisten pomojen ja asiakkaiden kanssa toimiessa myös asiakas pitää työtä itsestäänselvänä ja odottaa että toteuttaja käytännössä toimii yksityiskohtien osalta ajatustenlukijana.
UX-suunnittelijan tai softan toteuttajan näkökulmasta yksittäisessä ominaisuudessa on helposti paljon enemmän kysymyksiä joihin täytyy vastata, ennen kuin työmäärää edes lähdetään arvioimaan. Toisin sanoen ennen työmäärän arviointia olisi tehtävä määrittelytyötä: Mikä todellinen tarve itse asiassa edes on?
The secret to gaining the upper hand in negotiations, with a former FBI negotiator
Kuten organisaatiossa toimiessa yleensäkin, tapa jolla yhteisiä tavoitteita ja haasteita kommunikoidaan on kriittisen tärkeä. Myös väkivallaton vuorovaikutus ja toisen sanoman toistaminen takaisin keskustelukumppanille, saaden aikaan lisäreflektiota, ovat hyviä työkaluja.
Pohjimmiltaan kyse on kuitekin johtajuuden haasteesta. Siitä, ollaanko työ ylipäänsä valmis näkemään sellaisena kuin se on:
- Halutaanko organisaatiossa tehdä käyttäjäkeskeistä suunnittelua tai systemaattista määrittelytyötä, jotta asiakkaiden tarpeet ensinnäkin ymmärretään kunnnolla?
- Onko käytössä ketteriä menetelmiä tavalla, jotka valtaannuttavat itse ohjelmistotyön tekijät siten että he voivat jaksottaa työn ja asettaa asiakkaalle odotukset kustannuksista työn luonteen mukaisesti?
Mikä sitten ratkaisuksi hankalassa kommunikaatiotilanteessa? Ratkaisuja on monia. Usein kyse on ensinnäkin valtadynamiikoista.
On mahdollista, että pomosi kertakaikkiaan ei suostu kuuntelemaan tosiasioita työn luonteesta. Toisinaan ainoa vaihtoehto voi olla vaihtaa työpaikkaa ajoissa ennen kuin suostut projekteihin, joiden valtarakenne on kuin tehty tuhoamaan työn tekijän mielenterveys. Et halua joutua organisaatiopoliittiseen tilanteeseen, jossa projekti venyy ja ympäristö voi tuuduttaa itsensä ajattelemaan että alkuperäinen kuvitelma työn helppoudesta oli totta, ja projekti näyttää venyessään paljon todellistakin epäonnistuneemmalta.
It is difficult to get a man to understand something, when his salary depends on his not understanding it.
Upton Sinclair
Toivotaan kuitenkin että sinun tilanteesi ei ole tämä. Syy miksi olen kirjoittanut ylläolevan, on toive siitä että ehkä näkökulmaero voi tulla ymmärrettävämmäksi keskustelun molemmille osapuolille.
Kuulen mielelläni mitä ajatuksia sinulla heräsi! Kommentoi alle.