Mikä on käyttäjän, joka tilaa järjestelmän kehityksen, yhteistyövelvollisuus?

Järjestelmän kehittämisen työ vaatii sitä enemmän ihmisiä ja työtunteja, mitä suuremmasta järjestelmästä on kyse. Tästä syystä ei ainoastaan kehitystyön suorittavan toimittajan, vaan myös järjestelmän tilaavan käyttäjän tulee ottaa tiettyjä yhteistyövelvoitteita.

Tämä eroaa normaalista tilaus- ja toimitussuhteesta. Esimerkiksi, jos tilaat räätälöidyn puvun räätäliltä eikä IT-järjestelmästä, tilaajana olevalla asiakkaalla (käyttäjällä) ei ole erityisiä “velvollisuuksia”. “Velvollisuudet” kuuluvat pääasiassa tilauksen vastaanottajalle, eli räätälille (toimittajalle). Juuri monien ihmisten ja työtuntien tarve IT-järjestelmässä tekee siitä rakenteen, jossa myös käyttäjän on “yhteistyötä” toimittajan kanssa.

Tässä artikkelissa selitämme, millaisia ​​lakisääteisiä velvollisuuksia tilaajalla on järjestelmän kehittämisessä, jota ei voida jättää pelkästään toimittajan vastuulle.

Oman järjestelmän ollessa kyseessä, kaiken ulkoistaminen ei riitä

Yksittäisessä järjestelmänkehitysprojektissa on usein mukana monia ihmisiä ja organisaatioita. Koodaustaitoihin erikoistuneet insinöörit ja ohjelmoijat ovat tietenkin tärkeitä, mutta näiden henkilöiden tuotoksen yhdistäminen yhdeksi saavutukseksi vaatii myös projektinjohtajan roolia.

Kuitenkin, vaikka toimittajalla olisi kuinka korkea tekninen ja organisatorinen kyky, järjestelmän kehittäminen ei onnistu pelkästään toimittajan voimin. Esimerkiksi yrityksen sisäisesti käytettyjä termejä tai yrityskohtaista liiketoimintatietoa ei voida ymmärtää pelkästään toimittajan yksipuolisella ponnistelulla. Mitä suurempi järjestelmän kehitys on kyseessä, sitä yleisemmin kyseinen järjestelmä on käytössä suuressa yrityksessä, jolla on paljon ihmisiä ja tehtäviä. Järjestelmän kehitysprojektin menestykseen johtamiseksi on usein tärkeää järjestää nämä liiketoimintalogiikat ennen tietokonetyötä.

Tästä syystä käyttäjän ei tulisi olla passiivinen sillä perusteella, että “en ole IT-asiantuntija”, vaan päinvastoin aktiivisesti tarjota tietoa, jotta projekti sujuisi sujuvasti. Tässä mielessä käyttäjän rooli järjestelmänkehitysprojektissa ei ole lainkaan vähäinen.

Käyttäjän yhteistyövelvollisuus oikeustapausten valossa

Mitä käyttäjän yhteistyövelvollisuus tarkoittaa konkreettisesti järjestelmänkehitysprojekteissa? Tähän kysymykseen löytyy monia vihjeitä aikaisemmista oikeustapauksista.

Oikeudenkäynnissä toimittajan (vastaajan) viivästynyt toimitusaika nousi esille, koska käyttäjän (kantajan) päätöksenteko oli viivästynyt. Tässä yhteydessä käyttäjän yhteistyövelvollisuus järjestelmän kehittämisessä oli kiistanalainen. Oikeus totesi, että käyttäjä oli rikkonut yhteistyövelvollisuutensa ja kiisti toimittajan vastuun sopimusrikkomuksesta. (Vaikka sopimuksen purkaminen hyväksyttiin, myös 60%:n vahingonkorvausvastuun vähennys hyväksyttiin.)

Tämä tietojärjestelmän kehityssopimus on ns. räätälöity järjestelmänkehityssopimus, jossa toimittaja ei voi yksin valmistaa järjestelmää. Käyttäjän on kehitysprosessin aikana sovitettava yhteen sisäiset näkemykset, yhdenmukaistettava kantansa, kerrottava selkeästi toimittajalle, mitä toimintoja hän haluaa, tutkittava yhdessä toimittajan kanssa haluttuja toimintoja, lopulta päätettävä toiminnot, lisäksi, päätettävä näytöt ja raportit, hyväksyttävä lopputuotteet jne. Tämä on välttämätöntä.

Tokion alioikeuden päätös 10. maaliskuuta 2004 (Heisei 16)

Tämä päätös ei ainoastaan osoita, että järjestelmän kehittäminen on yhteistyötä käyttäjän kanssa, vaan myös erittäin havainnollisesti selittää, “mitä yhteistyö konkreettisesti tarkoittaa”.

Kokeillaanpa kääntää yllä olevan päätöksen sanamuoto IT-terminologiaan järjestelmänkehityksen yhteydessä.

Nämä voidaan järjestää edellä mainitulla tavalla. Kaikki nämä ovat asioita, joita ei voida tehdä yksin, riippumatta siitä, kuinka korkeatasoinen asiantuntemus IT-järjestelmästä on, ilman käyttäjän yhteistyötä. Käyttäjän on periaatteessa selkeytettävä, mitä toimintoja hän haluaa ja miltä näytön asettelu näyttää, ja vain käyttäjä voi tarkistaa, onko haluttu toteutettu.

Muuten, samalla tavalla kuin toimittajalle on asetettu projektinhallintavelvollisuus, myös käyttäjälle on asetettu yhteistyövelvollisuus. Jos käyttäjä rikkoo yhteistyövelvollisuuttaan edellä mainituissa prosesseissa, on mahdollista, että toimittaja voi vaatia käyttäjältä sopimusrikkomukseen tai laittomaan toimintaan perustuvaa vahingonkorvausta.

Miten jälkikäteiset muutospyyntöjä tulkitaan?

Olettaen, että järjestelmän kehitysprojekti on käyttäjän ja toimittajan yhteistyötä, keskustelu etenee edelleen kehittyneempään suuntaan. Kysymys on siitä, kuka on vastuussa, jos käyttäjä pyytää jälkikäteen lisätoimintoja tai korjauksia, mikä vaikeuttaa määräajan noudattamista.

Järjestelmän kehitys pyrkii yleensä etenemään siten, että vaatimusten määrittely alkaa, ja seuraavat vaiheet ovat perussuunnittelu, yksityiskohtainen suunnittelu, valmistus (ohjelman toteutus) ja testaus, pyrkien välttämään mahdollisimman paljon takaiskuja (yleisesti kutsutaan vesiputousmalliksi). Kuitenkin, jos jostain syystä paljastuu, että edellisessä vaiheessa on puutteita, takaiskut ovat yleisiä.

Miten tätä pitäisi ajatella, jos määräaikaa ei noudateta näissä tapauksissa? Tulkittaessa aikaisempia oikeustapauksia, näyttää siltä, että johtopäätöksissä on eroja sen mukaan, milloin lisätyötä on pyydetty.

Jos lisätyötä pyydettiin ennen ulkoisen suunnittelun ja muiden vaatimusten selkeyttämistä

Edellä mainitussa oikeustapauksessa todetaan, että käyttäjän pyynnöt lisäkehityksestä perussuunnittelun aikana (ennen ohjelman toteutusvaihetta) eivät ole erityisen ristiriidassa yhteistyövelvoitteen kanssa.

Käyttäjän pyynnöt toimittajalle erilaisista vaatimuksista järjestelmän rakentamiseksi perussuunnittelun aikana ovat luonnollisia tämän tyyppisessä järjestelmän kehitysprosessissa, ja lisäksi, ammattitaidottoman käyttäjän on vaikea arvioida tarkasti, vaatiiko pyyntö lisämaksuja tai toimitusajan pidentämistä, tai aiheuttaako se haittaa työprosessille. Siksi käyttäjän ei voida odottaa pidättäytyvän pyynnöistä, jotka saattavat johtaa lisämaksuihin tai toimitusajan pidentämiseen. Päinvastoin, jos käyttäjä esittää pyyntöjä, jotka vaativat lisämaksuja tai toimitusajan pidentämistä, projektinhallintavelvollisuuden omaavan toimittajan tulisi ilmoittaa tästä käyttäjälle, pyytää pyynnön peruuttamista tai keskustelua toimitusajan pidentämisestä jne., jotta kehitystyö ei häiriintyisi.

Tokion alioikeuden päätös 10. maaliskuuta 2004 (Heisei 16)

Tässä päätöksessä todetaan, että käyttäjällä on tietty yhteistyövelvollisuus, mutta samalla otetaan huomioon, että käyttäjä ei ole järjestelmän kehityksen asiantuntija. Toisin sanoen, koska tilaaja ei ole järjestelmän kehityksen asiantuntija, on ymmärrettävää, että hän saattaa esittää erilaisia pyyntöjä kehityksen aikana, ja on kohtuutonta odottaa, että hän huomaa itse, että pyynnöt saattavat vaatia toimitusajan tarkistamista.

Kuitenkin, toimittajan tässä tapauksessa velvoitettu velvollisuus viittaa lähinnä kommunikaation ponnisteluihin, kuten toimitusajan pidentämisen pyytämiseen (tai jos toimitusaikaa ei voida siirtää, ehdottamaan, että lisäpyyntö peruutetaan). Siksi on tärkeää huomata, että tämä ei tarkoita, että toimittajan olisi velvollisuus hyväksyä kaikki käyttäjän pyynnöt ja toimittaa tuote alkuperäisen aikataulun mukaisesti.

Jos lisätyötä pyydettiin valmistuksen tai testausvaiheen jälkeen, kun vaatimukset oli jo vahvistettu

Edellä mainitun päätöksen perusteella voidaan jossain määrin ennustaa, millainen lopputulos olisi ollut, jos lisäkehitystä olisi pyydetty sen jälkeen, kun vaatimukset oli jo vahvistettu. Tässä tapauksessa tällaiset pyynnöt olisivat todennäköisesti vaikeita hyväksyä. On totta, että käyttäjän ja toimittajan ymmärrys kehitystyöstä eroaa suuresti, riippumatta siitä, onko vaatimukset vahvistettu ennen vai jälkeen.

Kuitenkin, jos muutetaan tai lisätään tilauksia sen jälkeen, kun vaatimukset on vahvistettu, on suuri todennäköisyys, että työ on tehtävä uudelleen. Useimmissa tapauksissa on vaikea puolustaa toimitusajan viivästymistä, joka johtuu siitä, että “asiakas on luonnollisesti esittänyt erilaisia pyyntöjä”. Lisäksi, jos suuri määrä vaatimusten muutoksia tai toimintojen lisäyksiä tapahtuu jälkikäteen, se herättää kysymyksen, oliko käyttäjän yhteistyövelvollisuuden rikkominen jo olemassa perussuunnittelussa, joka olisi pitänyt olla valmis etukäteen.

Näistä syistä on realistista ajatella, että toimittajan vastuulla ei ole toimitusajan viivästymistä, joka johtuu vaatimusten muutoksista, jotka on tehty sen jälkeen, kun vaatimukset on kerran vahvistettu. Edellä mainitusta päätöksestä voidaan päätellä, että tämä on oikea tulkinta.

Lisäksi tällaiset päätökset tehdään usein ei vain sopimuksen perusteella, vaan myös järjestelmän kehityksen edistymisen mukaisesti pidettyjen kokousten pöytäkirjojen perusteella. Pöytäkirjoista on yksityiskohtainen selitys alla olevassa artikkelissa.

Liittyvä artikkeli: Miten järjestelmän kehityksen kokousten pöytäkirjat tulisi jättää oikeudellisesta näkökulmasta[ja]

Yhteenveto: On tärkeää muistaa, että vaatimusten määrittely on käyttäjän prosessi

Vaatimusten määrittely on paitsi toimittajan taitojen näyte, myös ensisijaisesti käyttäjän tehtävä. Tämä tulisi pitää mielessä. Vaikka järjestelmä olisi yrityksen itsensä käyttämä ja se olisi rakennettu ulkopuolisen asiantuntijan avulla, oletuksena on, että yrityksen hallinto ulottuu siihen ja se on oikeudellisesti asianmukainen alue.

Jos käyttäjä ei ole yhteistyöhaluinen kehitysprosessissa, on tärkeää ymmärtää, että tuomioistuin saattaa olla ankara käyttäjälle, vaikka projekti olisi tulessa.