Verkkopalveluprojektien top-10 haasteet

Artikkeli

Otathan huomioon, että tämä artikkeli on yli 15 vuotta vanha, joten sisältö ja linkit eivät ole välttämättä ihan ajan tasalla. Tuoreena lukemisena samasta kategoriasta: Hankintavälkky-botti on harvinainen, hyödyllinen chatbotti.

Vierityspalkin artikkelisarjassa on aiheena verkkosivujen konseptisuunnittelu ja siihen liittyvät vaiheet, menetelmät, käsitteet ja dokumentit. 

Tässä artikkelissa on listattu käytännön kokemuksen kautta syntyneitä havaintoja verkkopalveluprojekteista vuonna 2019. Haasteet on listattu niiden arvioidun yleisyyden ja merkittävyyden mukaiseen järjestykseen. Listalla on yleisiä haasteita, palvelutoimittajiin liittyviä haasteita sekä asiakasnäkökulmaan liittyviä.

Haaste 1: Asiakkaiden ja käyttäjien odotukset kasvavat nopeammin kuin mihin teknologia kykenee vastaamaan

Yhä useammin oman firman intranettiä verrataan Facebookiin ja valitetaan miksei homma toimi kuten Facebookissa. Pahimmillaan vielä argumentoidaan Facebookin olevan ilmainen ja oman intran sentään maksaneen satoja tuhansia euroja. Tavallisella web-käyttäjällä onkin nykyisin käytettävissään miljoonien eurojen ohjelmistot täysin ilmaiseksi. Googlen, Microsoftin ja kumppaneiden hyperkilpailu on luonut varsin mielenkiintoisen asetelman. Harva tavallinen käyttäjä hahmottaa, että suosituimpien ilmaispalveluiden takana saattaa olla satoja ihmisiä kehittämässä palvelua ja työtä on saatettu tehdä jo vuosia. Esimerkiksi moni verkkopalvelun omistaja haluaisi videopalvelunsa sisältävän samat ominaisuudet kuin YouTube. Yllätys voi olla suuri kun ratkaisutoimittaja kertoo hintalapun olevan karsitullekin YouTube-kopiolle helposti puoli miljoonaa euroa.

Haaste edellyttää vahvempaa liiketoimintasuunnittelua ja projektien perusteiden rakentamista. Käyttäjien tarpeita on kuunneltava, mutta vain liiketoiminnallisesti tärkeisiin vaatimuksiin kannattaa vastata.

On myös suositeltavaa harjoittaa avointa viestintää käyttäjille päin, jotta useammat avainhenkilöt ymmärtävät, että isojen verkkopalveluiden kehittäminen ja käyttöönotto ei ole menossa halvempaan ja yksinkertaisempaan suuntaan.

Haaste 2: Julkaisujärjestelmät eivät ole lähteneet kovin ketterästi mukaan Web 2.0 -maailmaan

Monia järeitä web-sisällönhallintajärjestelmiä kehitetään jopa satojen ihmisten voimin, mutta on eri asia kehittää monikäyttöistä alustaa kuin yksittäistä palvelua. Tästä syystä Googlenkin askeleet kohti yrityksiä ovat olleet pieniä ja varovaisia. Täten on myös epätodennäköistä, että julkaisujärjestelmien ja esim. Facebookin välinen ominaisuuskuilu katoaisi lähitulevaisuudessa. Monet järjestelmätoimittajat ovat toki ryhtyneet vannomaan sosiaalisen median, semanttisen webin ja sähköisten työpöytien nimiin viime aikoina, mutta kuilu Googlen ja kumppaneiden ominaisuuksiin tulee varmasti pysymään.

Haaste edellyttää julkaisujärjestelmiä kehittäviä tahoja keskittymään vain tiettyihin käyttötapauksiin. Asiakkailta haaste vaatii kirkasta verkkostrategiaa eikä päätöntä ominaisuuskilpailua jossa omaan verkkopalveluun halutaan milloin mitäkin ominaisuuksia. ”Paraskaan” järjestelmä ei taivu kaikkeen.

Haaste 3: Iso kasa ominaisuuksia ei korvaa strategisen näkemyksen puutetta

Kaiken Web 2.0 -huuman keskellä on vaikea säilyttää malttinsa kun uusia ja upeita juttuja keksitään koko ajan. Ymmärrettävää. Valitettavasti se ei ole strategia, että ”haluaa kaiken”.

Uusista jutuista vain murto-osa päätyy pitkäkestoiseen käyttöön organisaatioiden verkkopalveluissa. Moni yritys on vasta nyt löytänyt sähköpostisuoran, verkkokaupan ja Google Adwordsin. Blogit, hakukoneoptimointi ja moni muu ovat vasta nousemassa tavallisten verkkopalveluiden valtavirtaan.

Hyviä verkkopalveluita ei tehdä ominaisuuksien määrällä – vaikka mediatalojen sivustoja katsomalla sellaisen illuusion saattaa itselleen pystyä rakentamaan.

Tämä haaste koskettaa erityisesti asiakkaita, mutta välillisesti myös projekteja toteuttavia osapuolia. Mitä enemmän hankkeen strategia on hukassa ja hajallaan, niin sitä todennäköisemmin projektissa tulee ongelmia tai erimielisyyksiä. Selkein merkki strategian puutteesta on, että vaatimusmäärittely kattaa kaiken mahdollisen sosiaalisesta nettiTV:stä aina mobiilisti toimiviin ryhmätyötiloihin ja googlemaisesti toimiviin personoituviin hakutoimintoihin.

Haaste 4: Projektin alkuvaiheessa lukittavat aikataulut

Edelleen on kummallisen yleistä, että asiakastaho näkee omaksi roolikseen vain vaatimusmäärittelyn ja laadun valvonnan. Massiivisen määrittelydokumentin valmistuttua projekti kilpailutetaan ja toteutukselle annetaan neljä kuukautta aikaa. Sitten kun homma on runnottu kasaan niin asiakas aloittaa kirjoittamaan virhelistaa ja valittamaan laatuongelmista. Esimerkki on hyvin kärjistetty, mutta ei täysin irrallaan todellisuudesta.

Verkkopalveluiden kehittäminen ja uudistuksien käyttöönotto tapahtuu parhaimmillaan vaiheistetusti ja yhteistyössä käyttäjien kanssa. Tiukat projektiaikataulut ja perinteiset vesiputousmallit ovat usein ristiriidassa käyttäjien arkitodellisuuden kanssa. Uudistuksien ajaminen sisään kertarysäyksillä on hyvin harvoin käyttäjien toivoma tapa. Lisäksi verkkopalveluille ja sisällönhallintajärjestelmille on tyypillistä käydä läpi julkaisun jälkeen pitkähkö sopeutusvaihe jossa ominaisuudet hiotaan ja viimeistellään käyttäjien haluamiksi.

Kaikkeen uuteen teknologiaan liittyy myös tarve kyseenalaistaa alkuperäisiä suunnitelmia toteutusvaiheessa. Projektitiimi voi oppia uusia asioita järjestelmästä projektin aikana tai asiakas voi nähdä tuotteen tarjoamat mahdollisuudet uudella tavalla. Tämän oppimisen vieminen käytäntöön vaatii neuvotteluvaraa aikatauluihin ja ketteriä projektimenetelmiä.

Tiivistetysti: Tiukat ja joustamattomat aikataulut tuottavat tyytymättömiä käyttäjiä ja huonoa teknistä laatua. Jos aikataulut on pakko lukita etukäteen, niin näihin seurauksiin on varauduttava. Piste.

Haaste 5: Resursointiongelmat ja arkkitehtuuriosaamisen niukkuus

Viides haaste koskettaa lähes ainoastaan projektien toteutusvaiheita ja liittyy toimittajien toimintatapoihin. Verkkopalveluiden toteutus edellyttää poikkeuksellisen laajan teknologiapaletin hallintaa. Tällaisia todella osaavia suunnittelijoita ja arkkitehtejä on Suomessa hyvin rajallinen määrä. Erityisesti laajojen sisällönhallinta- ja portaalituotteiden kohdalla vaaditaan laajaa ymmärrystä koko paletin mahdollisuuksista.

Junioritekijät päätyvät yleensä koodaamaan enemmän ja nostavat näin projektien hintaa ja tuovat haasteita ylläpidolle. Kokeneilla tekijöillä taas on niin paljon kysyntää koko ajan, että heitä on vaikea saada mukaan projekteihin. Tämä haaste lienee varsin pysyvä alalla joka ottaa käyttöön jatkuvasti uutta teknologiaa ja jossa kilpailu on armotonta.

Fiksut asiakkaat näkevät tämän jo sopimusvaiheessa ja vaativat mustaa valkoiselle tiimin kokoonpanosta ja käytettävyydestä. Ei ole ollenkaan harvinaista että tarjouksissa tarjotaan tiimiin tekijöitä jotka on jo kiinnitetty lähes kokonaan muihin projekteihin.

Projektiliiketoiminnan yksi suurimpia haasteita on resurssien optimointi ja tämä optimointi on usein ristiriidassa projektien laadun kanssa. Asiakkaan kannalta parhaita keinoja helpottaa tilannetta on panostaa konsepti- ja arkkitehtuurisuunnitteluun sekä sallia neuvottelu tavoiteaikatauluista projektin aikana. Usein juuri tiukat aikataulut johtavat tilanteisiin joissa homma runnotaan kasaan niillä tekijöillä jotka sattuvat olemaan saatavilla. Seurauksena on lähes aina laatuongelmia myöhemmässä vaiheessa. Osaavia tekijöitä ei vain ole rajattomasti.

Haaste 6: Valitseminen kokonaisuudistuksen ja vaiheittaisen kehittämisen välillä

Kuudes haaste liittyy erityisesti asiakkaiden näkökulmaan verkkopalveluiden kehittämiseen.

Nykyisin verkkopalveluita kehitetään jatkuvana prosessina. On hyvin tyypillistä, että kerran rakennettuun palvelukokonaisuuteen tehdään muutaman vuoden aikana useita kymmeniä pienempiä parannuksia ja laajennuksia. Pienet kehitysprojektit saavat helpommin vihreätä valoa ja tuottavat nopeita tuloksia. Tarve isommalle uudistukselle tiedostetaan, mutta vuosia rakennettu järjestelmäkokonaisuus ei ole helppo uudistettava. Joskus täysremontti on kuitenkin paikallaan. Sopivan hetken tunnistaminen ei vain ole helppoa.

Nykyisin on tarjolla paljon vaihtoehtoja kokonaisuudistukselle. Ominaisuuksia voidaan lisätä käyttämällä kolmansien osapuolien palveluita ja laajennuksia. Järjestelmiä voidaan myös räätälöidä nykyisin aiempaa kevyemmin kun kaikkea ei tarvitse aina koodata alusta asti.

On kuitenkin monia toiminnallisuuksia joita ei ole mahdollista rakentaa vanhan alustan päälle kovinkaan ketterästi. Tällaisia ovat yleensä mm. kehittyneet hakutoiminnot, käyttäjäprofiilit, sisältöjen automaattinen suosittelu ja käyttöoikeuksien tarkempi hallinta.

Asiakkaiden kannalta kehityksen suunta on haastava, koska arkkitehtuurinäkemystä tarvitaan yhä enemmän myös ostajan puolella. Enää ei kannata vain lähettää kasaa tarjouspyyntöjä maailmalle ja odottaa toimittajien esittävän parhaat ratkaisut. Tulevaisuuden mahdollisuudet riippuvat paljolti tehdystä alustaratkaisusta ja erilaisten alustojen tulevaisuutta on vaikea ennustaa.

Kaikki tämä edellyttää, että joko asiakkaalla on itsellään vahvaa näkemystä alan kehityksestä tai saatavilla on kumppaneita joiden liiketoiminta ei ole riippuvainen jatkuvista koodausprojekteista, lisäräätälöinnistä tai järjestelmäpäivityksistä. Huomattavaa on myös se, että mainostoimistoista ei tähän rooliin ole. Harva ns. “digitaalinen mainostoimistokaan” hahmottaa kovin suuria kokonaisuuksia ja pystyy katsomaan kokonaisuutta asiakkaan näkökulmasta.

Haaste 7: Jatkuvan kehityksen palveluntarjoajien vähäisyys

Verkkopalveluiden tietojärjestelmiä toimittavat palveluntarjoajat elävät vielä vahvasti isojen uudistusprojektien maailmassa. It-talot haluavat isoja projekteja ja puskevat asiakkaille näitä kankeita mammuttijärjestelmiä riippumatta asiakkaiden tarpeista. Mainostoimistot eivät ole sen parempia. Useimmat haluaisivat koodailla kokonaisuudesta irrallaan olevia Flash-saitteja ja katsovat asioita erittäin kampanjalähtöisesti. Mainostoimistot myös kunnostautuvat usein julkaisujärjestelmien haukkumisessa, koska järjestelmien olemassaolo tehokkaasti heikentää mainostoimistojen tuottoisaa Flash-saittibisnestä.

Markkinoilla on krooninen pula osaajista ja yrityksistä jotka olisivat keskittyneet jatkuvan kehityksen palvelutarjontaan. Suomalaiset verkkopalvelut elävät edelleen aivan liikaa massiivisten uudistusprojektien kautta. Uudistusten välissä verkkopalvelut uinuvat ruususen unta ja ylläpidosta maksetaan vaikka mitään ei tehtäisikään.

Tämän haasteen ratkaisu edellyttää asiakkailta ajattelutavan muutosta. Markkinointi- ja viestintävetoisesta projektitoiminnasta tulee siirtyä yhä enemmän pitkäjännitteiseen palvelu- ja sisältötuotantoon jossa pääpaino on jatkuvassa inkrementaalisessa kehittämisessä.

Esimerkiksi Aki Björklundin artikkeli “A website is never done” antaa kehittäjän näkökulman siihen miten parhaat web-innovaatiot syntyvät nykyisin. Lyhyesti: Ne eivät synny tiukassa tilaaja-tuottajamallissa jossa kiinteät projektit ovat ainut sopimusmuoto.

Haaste 8: Lanseerauksen merkityksen aliarviointi

Verkkopalveluprojekteja tehdään helposti liian pienessä piirissä ja oma henkilökunta saattaa lukea uudistuksesta jopa lehdistötiedotteesta. Tämä on omiaan herättämään negatiivisen arvostelun ja tähän ei millään yrityksellä pitäisi olla varaa. Jopa uusi intranet saattaa vain ilmestyä henkilökunnan käyttöön ilman sen kummempia ennakkotiedotteita, koulutuksia tai esittelytilaisuuksia.

Etenkin jos sisällöntuotantoon halutaan sitouttaa laajempi joukko ihmisiä niin uuden palvelun lanseerauksessa tulisi soveltaa samoja oppeja kuin minkä tahansa uuden tuotteen kohdalla. Avainvaikuttajat tulee sitouttaa ajoissa, viestintä tulee suunnitella etukäteen, koulutukset tulee järjestää ja lanseerauksen pitää tapahtua rytinällä. Sisältöpalveluiden kohdalla hiljainen beta-vaihe ja pilottistrategia ovat myös suosittuja, mutta yhtä lailla nämäkin tulee suunnitella osana kokonaisuutta.

Verkkopalvelut ovat yhä merkittävämpiä tietojärjestelmäprojekteja. Useampien alan toimijoiden kannattaisi tutustua esimerkiksi toiminnanohjausjärjestelmien käyttöönotoista opittuihin asioihin. SAP-tietojärjestelmiä ei viedä organisaatioihin matalalla profiililla. Tästä pitäisi ottaa oppia.

Haaste 9: Sisältöjen siirron työllistävyyden aliarviointi

Sisältöjen siirron haasteiden osalta tilanne on vuosien varrella parantunut, koska useammilla alan ihmisistä on jo takana useita projekteja. Esimerkiksi viestintä saattaa nykyisin jo projektoida erillisen projektin pelkästään sisältöjen siirrolle, kehittämiselle ja sisällöntuottajien koulutukselle.

Siirtojen kanssa kohdataan yleensä ongelmia kaikissa projekteissa. Automaattinen siirto on yleensä mahdollista vain hyvin rajalliselle määrälle sisältöjä ja vaadittava henkilötyömäärä usein yllättää. Ongelmat sisältöprojektissa onkin tyypillisin julkaisuaikataulun viivästyttäjä.

Sisällöntuotantoon ja lanseeraukseen tulisi aina perustaa oma projektinsa joka johdetaan samalla tarkkuudella kuin varsinainen teknologinen uudistusprojektikin.

Haaste 10: Yhteensopivuusongelmat kirjavien päätelaitteiden kanssa

Web-standardeista ja moderneista selaimista huolimatta verkkopalveluiden kehittäminen päätelaiteriippumattomasti on käytännössä mahdotonta. Asiakkailla on houkutus luetella vaatimusmäärittelyssä kaikki selaimet IE6:sesta Operaan, Chromeen ja Windows Mobileen. Toteuttajat sitten joutuvat selittelemään kun viikkojen testaamisen ja korjaamisen jälkeenkään palvelu ei toimi virheettömästi edes IE:n ja FF:n uudemmilla versioilla. Pelkästään järkevän selainyhteensopivuuden saavuttaminen on verkkopalveluprojektien megahaaste johon tarvitaan tehtävään erikoistuneita osaajia.

Minikannettavien ja mobiililaitteiden kehittyessä haasteet vain kasvavat. Eri päätelaitteiden tukemisesta tulisi neuvotella jokaisen palvelun kohdalla erikseen ja etukäteen. Palveluntarjoajat lupailevat herkästi liikoja joten tämä haaste vaatii asiakkailtakin ymmärrystä, koska tilanne ei näytä olevan menossa pelkästään parempaan suuntaan.

Yhteenveto: Asiakkailta ja toimittajilta tarvitaan monimutkaistuvassa verkkomaailmassa entistäkin parempaa yhteistyötä. Toisaalta asiakkaan rooli edellyttää yhä enemmän näkemystä – tai kykyä haalia näkemystä ympärilleen. Myös projektien käytännön tekemisestä alkaa nykyisin olla jo paljon kokemusta alalla. Kokemuksen tuomia oppeja ei kuitenkaan sovelleta projekteissa automaattisesti – ei asiakkaan puolelta eikä toimittajan toimesta. Verkkopalveluprojektien menestyksekäs läpivienti on edelleen erityistaito johon kannattaa panostaa.

Tämä artikkeli on kirjoitettu, koska haasteista on tärkeätä keskustella ennen kuin ne muuttuvat ongelmiksi ja vievät projektit kriisitilaan.

PS. Jos kaipaat riippumatonta asiantuntijan näkemystä verkkopalvelun jatkokehitykseen, uudistukseen tai teknologian vaihtamiseen, kannattaa tutustua North Patrolin konsultointipalveluihin. North Patrol tuntee Drupalin, WordPressin sekä monet muut teknologiat ja auttaa lukuisia asiakkaitaan uudistuksissa ja verkkopalveluiden jatkokehityksen suunnittelussa.

Perttu Tolvanen

Perttu on Vierityspalkin päätoimittaja ja kirjoittaja.

Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu on konsulttiyhtiö North Patrol Oy:n konsultti ja toinen perustaja. North Patrol on digitoimistoista ja järjestelmätoimittajista riippumaton konsulttiyhtiö, joka suunnittelee digitaalisia palveluita ja auttaa asiakkaita onnistumaan uudistushankkeissaan. Ota yhteyttä Perttuun!

16 kommenttia on “Verkkopalveluprojektien top-10 haasteet”

  1. Tommi Forsström

    Todella esimerkillinen kirjoitus ja verkkopalveluiden kehittämisen lähes kaikilla osa-alueilla toistakymmentä vuotta ammatikseni räplänneenä voin jotakuinkin varauksetta allekirjoittaa jokaisen pointin! Mahtavaa!

  2. Oletko pyörinyt meidän projektissa? Toinen ääni kirjoituksen täydelliselle paikkansapitävyydelle!

  3. Todella tarpeellinen ja asiantunteva kirjoitus, toivottavasti aiheuttaa laajempaa keskustelua. Tällaista puolueetonta artikkelia ei muuten löydy ihan helposti.

  4. Petteri Numminen

    Kiitokset täältäkin! Linkki artikkeliin leviää sähköposteissa, mikä on merkki täysosumasta. Tämän lukeminen sattui, mutta positiivisessa mielessä.

  5. No, itselläni on suunnittelijana ollut viime aikoina suurimpina haasteina seuraavat:

    1. Alihankkijoilla ei ole minkäänlaista laadunvalvontaa, ammattiylpeyttä tai ilmeisesti edes halua tehdä asioita ekalla kerralla oikein. Järjestelmien korjaaminen jälkikäteen asiakkaan vaatimuksesta kuluttaa huomattavasti enemmän molempien osapuolien resursseja kuin asioiden tekeminen alun perin oikein ja testaaminen itse toteutuksen yhteydessä.

    2. Toteuttajilla ei ole hajuakaan käytettävyydestä, käyttökokemuksesta tai edes terveestä järjestä. Eikö niitä voitaisi opettaa jo koulussa? Tai edes kurssittaa työntekijöitä jälkikäteen, elleivät ole kiinnostuneita lukemaan itse aiheesta?

    Netin parissa työskennellessä tuntuu usein siltä, että useimmat tämän alan yritykset tuottavat uskomatonta kuraa. Ihmekö sitten, että jokaisen uuden asiakkaan kanssa on todella työlästä saavuttaa tarvittavaa luottamusta, kun muut saman alan firmat ja tekijät ovat tuottaneet niin pahoja pettymyksiä?

    Pakko avautua rankan viikon jälkeen. ;-)

  6. Yhdyn ylistyskuoroon: erinomainen analyysi, Perttu! Saat olla varma, että tarjoan linkkiä artikkeliisi lähitulevaisuudessa sadoilla nettikirjoittamisen tai muun verkkoviestinnän valmennuksiin osallistuville.
    Tekee mieli puuttua 7. haasteeseen. ”Suomalaiset verkkopalvelut elävät edelleen aivan liikaa massiivisten uudistusprojektien kautta.” Inhottavan totta.
    Itse toivoin, että taantuma innostaisi hoitamaan verkkopalveluja projektien välillä – ottamaan olevasta tekniikasta enemmän irti. Mutta ei, taantuma käy tekosyyksi olla tekemättä mitään.

  7. Hämmentävä, muttei pieni ongelma: asiakkaan projektipäällikkö ei tiedä (tai halua tietää) lainkaan mitä on ostettu/sopimukseen kirjattu. Aiheuttaa poikkeuksetta kriisin.

  8. Muuten siis liityn kiittäjien joukkoon, tuo edellinen on tuskaisin itselle kohdallle muutaman kerran sattunut asia. On siis se ongelma, jota ei voi korjata ns. ammattitaidolla. Vaatii järeämpiä aseita.

  9. Nyökkäilin koko ajan tekstiä lukiessani – niin totta! Allekirjoitan joka sanan! Ja kiitos Pertulle taas naulan kantaan osuneesta analyysistä!

  10. Totta tosiaan – ihan hyvä nämäkin taas kerrata. Enemmän hämmennystä tosin herätti pomoni linkitys tähän artikkeliin, kun useammassa hänen alaisuudessaan olevassa projektissa ollaan menossa niin v*tuilleen eikä vastata oikeastaan yhteenkään näistä haasteista.

    Ja Mikko P:n 2:s kohtaan. Olen juuri nyt sellaisessa projektissa, jossa kopioidaan pashaa. Tiedän, että teemme käytettävyydeltä aivan sontaa, mutta parannuksia ei saa tehdä / ei saa ajatella että jokin toiminto olisi ihan päin helvettiä tai että sitä saisi parantaa. Olen alimmalla portaalla ja huudot ylöspäin ovat turhia, koska ylempiä kiinnostaa aikataulu ja kustannus – ei enää projekti. Teknologiavalinnat ja ”arkkitehtuuri”-valinnat on tehty joskus, joku joka ei ole enää paikalla ja pasha valuu toteuttajalle – eli minulle. Tässä sitten yritetään tehdä 80 mummosta kasvojenkohotuksella Missi-Essiä työkaluina vasara ja paistinlasta.

    Suurin ongelma projekteissa on toimimaton keskijohto, eli paikka, jota kukaan ei halua ja 90% tapauksista on osaamatonta.

  11. Mikko P ja Toteuttaja DQ:

    Teidän puheista päästäänkin siihen, kannattaako hommia tehdä ulkoistettuna ja projektiluontoisina? Jostain syystä yrityksissä elää vahvana usko, että ulkoa ostaminen on halvempaa.

    Eikö olisi parempi, että otetaan tekijät sisään, koulutetaan ja kuunnellaan niitä ja sitoutetaan tekijät hommiin pitkäksi aikaa. Koodaajien, suunnittelijoiden jne käyttö ei toimi kuten tehdastyöläisten.

    Jos ulkoaostetua koodia kuitenkin halutaan, sopparit ja koko prosessi pitäisi tehdä niin, että jos alihankkijalta tulee pashaa, silloin koodi bumerangataan takaisin alihankkijalle ja alihankkijan kustannuksella uusiksi. Tämä tosin vaatii myös sen, että joku tilaajan päässä lukee kaiken koodin läpi ja katsoo, että homma toimii.

  12. Kiitoksia paljon kehuista! Erityiskiitokset Tommille artikkelin kääntämisestä englanniksi Futuricen blogiin! Mahtavaa!

  13. […] 4. Verkkopalveluprojektien top-10 haasteet vuonna 2009. Artikkelissa listattiin kymmenen käytännön kokemuksen kautta havaittua haastetta verkkopalveluprojekteista. Artikkeliin linkitettiin tavallista runsaammin sähköposteista, Facebookista ja yrityksien sisäisistä wikeistä ja intraneteista. Artikkelin kirjoittaja Perttu Tolvanen. […]

  14. Pitäisiköhän tämä otsikoida ”Verkkopalveluprojektieni top-10 haasteet vuonna 2009”, sillä missään ei viitata lähteisiin tai edes keskusteluihin ulkopuoliseten kanssa.

  15. Perttu Tolvanen

    Ehdotus on ihan hyvä ja sitäkin tuli mietittyä. Yleisempi otsikko valikoitui koska kaikkia mainittuja haasteita en ole itse omissa projekteissa kohdannut.

    Vähän omituista kyllä, että moni odottaisi listan perustuvan johonkin lähteisiin tai haastatteluihin. Ensimmäisessä lauseessa kuitenkin todetaan varsin yksiselitteisesti, että kyse on listasta joka perustuu omiin projektikokemuksiin/käsitykseen. Työskentelen verkkopalveluprojektikonsulttina ja näen paljon erilaisia projekteja. Lähteiden ilmoittaminen tällaisessa listassa tekisi listan julkaisemisesta täysin mahdottoman. Mutta toisaalta kaikki artikkelia kommentoineet asiakkaani ovat kiittäneet artikkelista – samalla kun ovat todenneet artikkelin dokumentoivan terävästi myös heidän tilannettaan. Sanoisin, että tällaiset empiiriset vahvistukset ovat vahvempi puolustus artikkelin eri kohtien osuvuudelle kuin viittaukset yksittäisiin lähteisiin tai keskusteluihin.

    Eikä tällaista artikkelia voi verrata mihinkään tutkimukseen tai haastattelukyselyyn. Listalle on nostettu asioita jotka eivät yleensä esimerkiksi ole asiakkaille näkyviä ongelmia ollenkaan – ja toisinpäin moni toimittajapuolen kokema ongelma on ihan aidosti seurausta projektin ostaneen osapuolen osaamattomuudesta. Kummallakin puolella on parantamista ja mitä enemmän näistä asioista saadaan keskustelua, niin sitä lähempänä projektien laadun parantumista ollaan.

    Uskoisin, että monella alalla on hyviä esimerkkejä siitä, että ala kehittyy hitaasti koska kipeimmistä alan ongelmakohdista uskalletaan puhua vasta sitten kun ollaan itse eläkkeellä.

  16. Osuvaa, niin osuvaa. Ja kiteyttää hyvin sen tuskan, minkä pohjalta olemme omat asiakassegmenttimme identifioineet. Kiitos tästä! Projektit ketteröityvät edelleen, kun mukaan saadaan mm. helppokäyttöisempiä ja joustavampia webpalvelujen rakennustyökaluja.

Kommentointi on suljettu.



Vierityspalkki.fi

Julkaistu vuodesta 2006. Vierityspalkki on blogi kotimaisen internet-alan trendeistä, teknologioista ja alan toimistoista. Seuraa, niin tiedät miten ja kenen toimesta syntyvät parhaat verkkopalvelut, verkkokaupat ja räätälöidyt web-sovellukset. Uutiskirjeellä on jo yli 1000 tilaajaa.


Tilaa uutiskirje.

  • 40-50 asiantuntija-artikkelia vuosittain.

    Toimitettua asiasisältöä kattavasti teknologioista ja web-alan ilmiöistä. Vierityspalkki nostaa esiin alan puheenaiheita ja tuoretta tutkimustietoa, osallistuu keskusteluun sekä haastattelee alan asiantuntijoita ja toimistoja. Julkaistuja artikkeleita jo yli 1000 kappaletta.


    Kaikki artikkelit

  • 150-200 julkaistua referenssicasea joka vuosi.

    Julkaisut-palsta tarjoaa näkyvyyttä kiinnostaville uusille verkkopalveluille ja web-sovelluksille, ja antaa asiakkaille mahdollisuuden arvioida eri toimistojen osaamista.


    Selaa toimistojen julkaisuja

  • 300-400 työpaikkailmoitusta vuosittain.

    Vuodesta 2007 toiminut ilmoituspalsta on edelleen sivuston suosituin osio. Moni asiantuntija on löytänyt useammankin työpaikan palstan kautta vuosien varrella.


    Selaa avoimia työpaikkoja

  • 31 kokenutta digitoimistoa

    on päässyt aina ajantasaiselle Toimistot-listalle. Lista on auttanut asiakkaita löytämään kokeneita digitoimistokumppaneita jo usean vuoden ajan. Lista keskittyy WordPress-osaajiin ja räätälöityjen web-sovellusten tekijöihin.


    Selaa Toimistot-listaa

Tilaa kuukausikirje

Kerran kuukaudessa ilmestyvä uutiskirje koostaa artikkelit, julkaisut, työpaikat ja linkkivinkit. Kirjeellä on jo yli 1000 tilaajaa.
Huom. Sähköpostiosoitettasi ei luovuteta eteenpäin, eikä käytetä mihinkään muuhun tarkoitukseen – ihan oikeasti.

Siirry takaisin sivun alkuun