Toimittajan virhevastuu ketterässä IT-projektissa: mitä toimitussopimuksissa tulee huomioida laatuvirheiden osalta?
Loading...
URL
Journal Title
Journal ISSN
Volume Title
School of Business |
Master's thesis
Unless otherwise stated, all rights belong to the author. You may download, display and print this publication for Your own personal use. Commercial use is prohibited.
Authors
Date
2024
Department
Major/Subject
Mcode
Degree programme
Yritysjuridiikka
Language
fi
Pages
X + 58
Series
Abstract
Ketterät menetelmät ovat yleistyneet ohjelmistokehityksessä 2000-luvun alusta alkaen samalla, kun vesiputousmallin käyttö on alkanut vähentyä. Ketteriä menetelmiä käytettäessä asiakkaalta odotetaan aktiivista yhteistyötä toimittajan kanssa, kun taas samaan aikaan projektidokumentaatiota tai ohjelmistotoimitusta koskevia sopimusneuvotteluita ei nähdä ketterien menetelmien pääperiaatteiden mukaan niin tärkeinä. Sopimuksilla ja dokumentaatiolla on kuitenkin edelleen merkitystä. Etenkin virhevastuuseen liittyvien kysymysten kannalta ne ovat kriittisiä, sillä ketterissä ohjelmistoprojekteissa virheen määritelmä ja virhevastuun määräytyminen ovat vesiputousmalliin verrattuna monimutkaisempia. Virheet ovat yksi yleisimpiä konfliktien aiheuttajia toimittajan ja asiakkaan välillä, ja ne voidaan käsittää osapuolten intresseistä ja näkemyksistä riippuen myös muutospyyntöinä. Tämän tutkimuksen tarkoituksena on selvittää, mitä virhe tarkoittaa ketterässä ohjelmistokehityksessä sopimusoikeudellisesta näkökulmasta, ja mitä toimittajan kannattaa ottaa huomioon ketterissä implementointityötä koskevissa toimitussopimuksissa virhevastuuseen liittyen. Tutkimus on oikeusdogmaattinen tutkimus, ja sen aineistona toimivat pääosin sopimusoikeuden kirjallisuus ja IT 2022-ehtokokoelma. Toimittajan virhevastuuseen liittyvät kysymykset tuotiin esille tunnistamalla ja systematisoimalla virhevastuun sekä sen rajoittamisen kannalta keskeisimpiä sopimusehtoja. Sopimusehtoja tarkasteltiin hyödyntäen sanamuodon mukaista tulkintaa. Lisäksi tutkimuksessa hyödynnettiin ruotsalaisia ketterien ohjelmistotoimitusten sopimusehtoja joidenkin tutkimustulosten havainnollistamiseksi. Tutkimuksessa todettiin implementointityötä koskevien toimitussopimusten olevan pitkäkestoisia palvelusopimuksia, jolloin sopimuksia ei käytännössä sääntele mikään laki, eikä kauppalain analogiaa voida sopimusvastuuseen liittyvissä kysymyksissä juuri hyödyntää. Ohjelmistokehityksessä virheeksi käsitetään yleisesti tilanne, jossa ohjelmiston koodi ei toimi halutulla tavalla. Koska ketterässä projektissa toimittaja on yleensä sitoutunut toimintavelvoitteeseen, voivat virhevastuuseen liittyvät kysymykset olla monimutkaisia tulosvelvoitteeseen verrattuna. Monimutkaisuuteen vaikuttaa myös se, että asiakas osallistuu aktiivisesti kehitystyöhön, ja ohjelmistoon syntynyt virhe voi siten olla peräisin kumman tahansa osapuolen virheestä. Tutkimustuloksissa havaittiin myös, että virheen ja muutospyynnön erottamiseen toisistaan tulee hyödyntää asiakkaan vaatimuksien pohjalta laadittuja määrityksiä, mutta asiasta tulee sopia erikseen. Lisäksi virheet tulee luokitella olennaisiin ja epäolennaisiin virheisiin tarkemmin kuin miten ne on esimerkiksi yleisissä sopimusehdoissa luokiteltu. IT 2022-kokonaisuus on kuitenkin yleisesti hyvä lähtökohta sopimusehdoille, mutta virhevastuuseen liittyviä kohtia voi olla aiheellista täsmentää, minkä lisäksi toimitussopimuksen tulisi tukea osapuolten välistä yhteistyötä. Toimitussopimuksesta tulisi käydä ilmi, minkälaisiin velvoitteisiin osapuolet ovat sitoutuneet, joskin useimmiten ketterissä ohjelmistoprojekteissa toimittaja on sitoutunut toimintaan. Virheen käsitteen ja virhevastuun määräytymisen selkeyttämiseksi toimittajan kannattaa määritellä virheeksi sellaiset tilanteet, joissa toiminnallisuus ei vastaa asiakkaan hyväksymiä määrityksiä. Tätä varten tarvitsee sopia erillisestä määritysten hyväksymismenettelystä. Menettelyllä saadaan tehtyä selkeä ero virheen ja muutospyynnön välille, ja asiakkaalla on vahvempi intressi osallistua aktiiviseen yhteistyöhön. Lisäksi kannattaa sopia, ettei toimittajan virhe ole julkaisujen yhteensopimattomuus, mikäli se johtuu asiakkaan huolimattomasta työlistan priorisoinnista tai sen puutteellisesta sisällön suunnittelusta. Piilevien virheiden ja välillisten vahinkojen osalta toimittajan kannattaa rajata vastuutaan. Vaikka toimitussopimukset ovat perinteisin sopimusajattelun mukaisesti ennaltaehkäiseviä sopimuksia, kannattaa funktionaalisen sopimusajattelun periaatteita harkita, sillä ne ohjaavat sopimuspuolia tiiviimpään yhteistyöhön, mikä on myös ketterien menetelmien periaatteen mukaista. Yhteistyönäkökulmaan voi myös vaikuttaa panostamalla sopimusehtojen muotoiluun. Toimiva yhteistyö on lopulta tehokkain tapa ehkäistä virheiden syntymistä ja niistä aiheutuvia konflikteja osapuolten välillä.Agile methods have become more common in software development since the early 2000s, whereas the use of the waterfall model has started to decline. Agile methods expect the customer to actively collaborate with the supplier, while at the same time the project documentation or contract negotiations for software delivery are not seen as important according to the main principles of agile methods. However, contracts and documentation still matter. In particular, they are critical to issues of liability for defects, as the definition of defect and the determination of liability for defects in agile software projects are more complex than in the waterfall model. Defects are one of the most common causes of conflict between supplier and customer and, depending on the interests and views of the parties, can also be understood as change requests. The purpose of this study is to clarify what defect means in agile software development from contract law point of view, and what supplier should consider in agile implementation delivery contracts regarding to defect liability. The study is a legal-dogmatic research, and its material is mainly based on the literature of Finnish contract law and the Finnish IT 2022 general terms. Issues related to supplier's liability for defects were addressed by identifying and systematizing the most relevant contractual terms concerning liability for defects. The contractual terms were analyzed using literal interpretation. In addition, Swedish general terms for agile software delivery were used to illustrate some of the findings. The study found that delivery contracts for software implementation work are long-term service contracts. Basically, service contracts are not regulated by any law, and the analogy of the commercial law cannot be used to interpret liability issues. In software development, a defect is generally considered as a situation where the software code does not work as intended. Since in an agile project the supplier is usually bound by an obligation to perform, the issues of liability for defects can be complex compared to the issue of liability for performance. The complexity is also influenced by the fact that the customer is actively involved in the development process, and defect in the software can therefore be caused by an error on either party. The findings also showed that the distinction between defect and change request should be made using the specifications based on the customer's requirements, but that should be agreed separately. In addition, defects should be classified as majors and minors, as the accurate classification is not displayed in the IT 2022 terms. However, the IT 2022 terms are generally a good starting point for the delivery contract terms, but it may be appropriate to clarify certain terms related to liability for defects. In addition, the supply contract should support collaboration between the parties. The contract should indicate the obligation type to which the parties are committed, although in most agile software projects the supplier is committed to perform. In order to clarify the concept of defect and the determination of defect liability, the supplier should define defect as a situation where the software functionality does match with the specifications accepted by the customer. For this purpose, a separate acceptance procedure should be agreed. This procedure makes clear distinction between a defect and a change request, and the customer will have stronger interest in actively participating to development work. It should also be agreed that the supplier is not liable for an error related to a mismatch of releases, if it is either caused by customer's negligent prioritization or inadequate content planning of the backlog. In addition, the supplier should limit its liability for latent defects and consequential damages. Although supply contracts are preventive contracts in line with traditional contract approach, it is worth to consider to utilize the principles of functional contract approach as they guide the contracting parties towards closer collaboration, which is one of the principles of agile methodologies as well. Also, supplier can effect on collaboration by phrasing terms to support that. Ultimately, proper collaboration is the most effective way of preventing defects. Collaboration will therefore prevent conflicts between the parties as well.Description
Thesis advisor
Hietanen-Kunwald, PetraKeywords
virhe, virhevastuu, toimitussopimus, ohjelmistokehitys, ketterät menetelmät