maanantai 30. maaliskuuta 2015

37signals - Getting Real

Ammattitavaus oli tarkoituksella naftaliinissa noin yhdeksän kuukautta, mutta nyt on aika taas aktivoitua tälläkin saralla. Kaikkea uutta jännittävää opittavana, jota varten voi lukea mielenkiintoisia uusia kirjoja!

Avaan pelin 37signalsin (nykyinen Basecamp) kirjalla Getting Real. Getting Real on kokoelma noin yhden sivun mittaisia ajatuksia kevyestä, ketterästä ja oleelliseen keskittyvästä ohjelmistokehityksestä. Kirjan tavoitteena on antaa eväitä webbiapplikaatioiden tekemistä varten. Perusohjeena on tehdä kaikki mahdollisimman pienesti, mahdollisimman vähillä featureilla ja mahdollisimman kirkkaalla näkemyksellä.




37signals on kovasti internet-uskottava yritys, joka on esimerkiksi Ruby on Rails -ohjelmistokehyksen alkuperäinen kehittäjä. Olen viimeiset puoli vuotta ollut vetämässä ohjelmistohanketta, jota toteutetaan Ruby on Railssilla, joten tämä yhteys tuli hauskana yllätyksenä lukemisen aikana.

Pieni on kaunista

Isommin ja paremmin tekeminen on mennyttä aikaa. Getting Realin mukaan ei kannata tehdä kilpailijan tuotetta suurempaa ja monipuolisempaa härveliä. Parhaat tuotteet ovat pieniä ja hallittuja ja vastaavat täsmälleen kuluttajan tarpeeseen. Tähän pystyy parhaiten pitämällä myös oman organisaationsa pienenä. Pieni organisaatio on näppärä liikkeissään ja ne ovat muutenkin sympaattisempia. Ison organisaation viestintäpäällikön assistentti saa kuulla somekohusta siinä vaiheessa, kun pienen organisaation toimari on jo hoitanut koko tilanteen.

Pienet tuotteet ovat kauniita. Vain muutamia ominaisuuksia sisältävä tuote on nopea saada markkinoille, nopea päivittää ja nopea korjata. Mitä suurempi tuote on kyseessä, sitä vaikeampaa ja hitaampaa kaikki on. Sitä harvempi ominaisuus on juuri täsmälleen, mitä kaikki asiakkaat haluavat. Getting Realin mukaan on hyödytöntä rakentaa massiivinen tuote, joka palvelee hirveää määrää potentiaalisia asiakkaita jotenkin. Sen sijaan kannattaisi rakentaa tuote, joka palvelee tiettyjä asiakkaita Lllloistavasti.

Sano kaikelle ei

Mahdollisimman pienen tuotteen tekeminen onnistuu, kun sanoo kaikelle ei. Kun uusi ominaisuus tai idea tulee mieleen, ensimmäinen reaktio on aina hylätä se. Jos ominaisuus on ihan erityisen erinomainen, se tulee vastaan kyllä uudestaankin. Jos joku ominaisuus aina vain tupsahtaa vastaan, se voi ehkä joskus päätyä osaksi tuotetta. Getting Real esittelee listan, joka pitäisi aina käydä läpi mahdollisen uuden ominaisuuden kohdalla:
  1. Hylkää ensimmäisen kerran
  2. Mieti ominaisuuden arvo: onko tämä nyt ihan oikeasti tarpeellinen?
  3. Jos on:
  4. Hahmottele UI
  5. Suunnittele UI
  6. Koodaa ominaisuus
  7. Testaa, säädä, testaa, säädä, jne. Jonka jälkeen...

  8. (tämä on se ovela osa listaa)

  9. Päivitä ohjetekstit
  10. Päivitä tutoriaalit yms.
  11. Päivitä markkinointimateriaalit
  12. Päivitä käyttöehdot
  13. Päivitä hinnat
  14. Launchaa ominaisuus
Getting Real onnistuu mainiosti esittämään, miten ominaisuuden hinta ei koostu pelkästään koodaamiseen käytetystä ajasta. Ohjelmistot ovat monimutkainen kasa ohjeita, grafiikkaa, koodia ja sopimuksia ja jokainen uusi ominaisuus nostaa monimutkaisuutta taas yhdellä muuttujalla.

Tämän vuoksi kaikelle pitäisi sanoa ei.

Näin luettuna ja kirjoitettuna tämä kuulostaa mainiolta ja selkeältä. Tällaisen listan noudattaminen käytännössä on toki heti vaikeampaa. Varsinkin jos ympärillä on mitään valmista rakennetta, jota vastaan joutuu taistelemaan. Tästä problematiikasta voisin kuitenkin kirjoittaa ihan oman merkintänsä.

Tärpit


Tyhjä sivu on tärkeä: ensivaikutelma on tärkeä myös internetissä. Käyttäjät saavat eteensä ensimmäiseksi tyhjät lomakkeet, joissa ei ole mitään tietoa. Muista siis suunnitella myös tämä käyttökokemus! Jos tyhjien lomakkeiden taitto repeilee ja kenttien täyttämiseksi ei ole mitään ohjeita, menee ensikokemus välittömästi pieleen. Jos aina suunnittelee kaiken lorem ipsumilla tai esimerkkidatalla, antaa itselleen valheellisen kuvan siitä, miten käyttäjä kohtaa palvelun!

Unohda käyttäjien toiveet: Getting Realin metodi käyttäjien toiveiden kuuntelemiseen on lukea ne kertaalleen ja sen jälkeen unohtaa ne. Jos joku asia on erityisen nerokas, sen kyllä huomaa. Jos taas se on erityisen yleinen toive, se tulee kyllä esiin uudestaankin. 

Älä tarjoa liikaa asetuksia: Tekijän tehtävä on päättää, miltä ohjelmisto näyttää. Asiakkaan ei pidä joutua pähkäilemään, onko 25 viestiä vai 142 viestiä samalla sivulla hyvä määrä. Päätä itse oikea määrä. Näin välttää sähläämästä uusien ominaisuuksien kanssa ja käyttäjän käyttökokemus pysyy sellaisena kuin pitääkin. Olen itse kovasti suuri taiteilija -koulukuntaa, joten tästä ohjeesta tykkään!

Kirjoittamisen tärkeyttä ei voi yliarvioida: hyvät kirjoittajat ovat hyviä koodaajia, työntekijöitä ja ihmisiä. Kirjoittaminen on viestimistä. Viestintä taas on elinehto, kun puhutaan ketterästä ja lähellä asiakkaitaan olevasta pienestä organisaatiosta. Blogin kirjoittajana tykkään myös tästä ohjeesta!

Seuraa, kuka sinua seuraa: hyvä neuvo myös esimerkiksi bloggaajille. Yleinen virhe on tuijottaa vain omaan napaansa. Yksikään uusi lukija ei löydä blogia, vaikka sinne kuinka tursuaisi uutta loistavaa sisältöä jatkuvasti. Tehokkaampaa on olla aktiivinen kaikkialla muualla! Saman aihepiirin blogeissa, teknologiafoorumeilla, jne. Jos on jotain uutta tulossa, ole aktiivinen kaikkialla muualla, kuin oman firman kotisivuilla!


Getting Real oli varsin mainio kirja. Heti lukemisen jälkeen en ollut mitenkään erityisen vaikuttunut, mutta tämä on tässä pienen pureskelun jälkeen selvästi parantunut. Toisaalta kävin nyt läpi lähinnä ne kohdat, jotka olin merkinnyt kirjasta muistiin. Sen lisäksi tavaraa on vielä 150 sivua lisää, mutta ihan hyvää sekin varmasti oli. Nopea luettava ja saatavissa ilmaiseksi, joten ei tätä voi kuin suositella.

Ei kommentteja:

Lähetä kommentti