Πόσο πολύ θα πρέπει νομικά να υλοποιηθεί μια λειτουργία που δεν περιλαμβάνεται στις προδιαγραφές ανάπτυξης συστήματος;

Τα έργα που αναπτύσσουν συστήματα IT που χρησιμοποιούνται σε εταιρείες, καταρτίζονται καταρχήν σύμφωνα με προδιαγραφές που έχουν καθοριστεί εκ των προτέρων. Ωστόσο, αν λάβουμε υπόψη τη σημασία του ότι ο προμηθευτής έχει ανατεθεί ως ειδικός στην ανάπτυξη συστημάτων, οι προσδοκίες του χρήστη μπορεί να μην είναι χαμηλές, ακόμη και αν απλώς εφαρμόζετε μηχανικά αυτά που έχουν γραφτεί στις προδιαγραφές. Σε αυτό το άρθρο, θα εξηγήσουμε πόσο μακριά πρέπει να αναλάβετε την ευθύνη για την εφαρμογή ενός προγράμματος που “δεν είναι αναγραμμένο στις προδιαγραφές, αλλά είναι απαραίτητο για την εφαρμογή του σκοπού της ανάπτυξης”.

Νομικά ζητήματα που συνδέονται με την υλοποίηση στοιχείων που δεν περιλαμβάνονται στις προδιαγραφές

Απαιτείται διακριτική ευχέρεια στις εργασίες του προμηθευτή

Ένα από τα σημαντικά χαρακτηριστικά των συμβάσεων που σχετίζονται με ένα έργο ανάπτυξης συστημάτων και των διάφορων νομικών ζητημάτων που συνοδεύουν αυτές, είναι ότι ο προμηθευτής που αναλαμβάνει την εργασία έχει μεγάλη διακριτική ευχέρεια.

Σχετικό άρθρο: Τι είναι οι υποχρεώσεις διαχείρισης έργου στην ανάπτυξη συστημάτων

Ωστόσο, η “διακριτική ευχέρεια” που αναφέρεται εδώ δεν εφαρμόζεται απαραίτητα σε όλη τη διαδικασία ανάπτυξης συστημάτων. Μετά την εξαγωγή κάθε διαδικασίας και την προώθηση της εξαγωγής λεπτομερών εργασιών, μπορεί να υπάρχουν πολλές εργασίες που πλησιάζουν την απλή εργασία. Ωστόσο, γενικά, όσο πιο πολύ γίνεται εργασία της προηγούμενης διαδικασίας, δηλαδή της ανώτερης διαδικασίας, τόσο πιο δύσκολη γίνεται η εκτέλεση της εργασίας χωρίς μεγάλη διακριτική ευχέρεια. Αυτός είναι επίσης ο λόγος για τον οποίο οι συμβάσεις της ανώτερης διαδικασίας ταιριάζουν συχνά καλύτερα με την εντολή.

Σχετικό άρθρο: Η διάκριση και η διαφορά μεταξύ των συμβάσεων εργολαβίας και των συμβάσεων εντολής στην ανάπτυξη συστημάτων

Η διακριτική ευχέρεια πρέπει επίσης να εκδηλώνεται μέσα σε αυστηρές διαδικασίες ανάπτυξης

Ωστόσο, ακόμη και αν λέμε ότι ο προμηθευτής που αναπτύσσει το σύστημα έχει μεγάλη διακριτική ευχέρεια, το να αποδεχτεί τις απαιτήσεις του πελάτη με αυθαίρετο τρόπο μπορεί να προκαλέσει σημαντικές ζημιές στις επόμενες διαδικασίες. Ένα IT σύστημα αποτελείται από μια συλλογή λεπτομερών εξαρτημάτων, και για αυτόν τον λόγο, ακόμη και αν πρόκειται μόνο για μια μικρή αλλαγή στην εμφάνιση, μπορεί να απαιτηθεί σημαντική αλλαγή στο χρόνο εργασίας από την πλευρά του προγραμματιστή. Επιπλέον, υπάρχουν άρθρα που εξηγούν τον τρόπο διαχείρισης των αλλαγών στις προδιαγραφές της ανάπτυξης συστημάτων από νομική άποψη. Τα παρακάτω άρθρα εξηγούν πώς να διαχειρίζεστε τις αλλαγές, αλλά επίσης συζητούν πόσο μεγάλη επίπτωση έχουν οι αλλαγές στις προδιαγραφές από την άποψη του μηχανικού.

Σχετικό άρθρο: Η διαχείριση των αλλαγών στην ανάπτυξη συστημάτων από νομική άποψη

Χωρίς να περιορίζεστε στις προδιαγραφές, τι πρέπει να κάνετε ως ειδικός;

Για να προωθήσετε ομαλά ένα έργο ανάπτυξης συστήματος, είναι σημαντικό να ορίσετε εκ των προτέρων τις απαιτήσεις της ανάπτυξης και να προχωρήσετε σύμφωνα με αυτές. Από την άλλη πλευρά, υπάρχουν περιπτώσεις όπου δεν μπορείτε να εκπληρώσετε πλήρως τον ρόλο σας ως ειδικός στην ανάπτυξη συστημάτων αν απλώς κάνετε αυτό που σας λένε, σύμφωνα με τις απαιτήσεις που έχουν οριστεί εκ των προτέρων. Μέσα σε αυτό το δίλημμα, το ζήτημα “τι πρέπει να υλοποιηθεί, ακόμη και αν δεν είναι διατυπωμένο στις προδιαγραφές” αρχίζει να εμφανίζεται.

Οι νομικές υποχρεώσεις καθορίζονται σύμφωνα με τον “σκοπό” των τεχνικών προδιαγραφών και των συμβολαίων

Το περιεχόμενο των στοιχείων που πρέπει να υλοποιηθούν, ακόμη και αν δεν έχουν αναφερθεί στο συμβόλαιο ή στις τεχνικές προδιαγραφές, καθορίζεται από τον “σκοπό” αυτών των στοιχείων του συμβολαίου ή των τεχνικών προδιαγραφών, δηλαδή, “με ποια έννοια ή πρόθεση έχει συμφωνηθεί κάτι τέτοιο”. Ας δούμε μερικά παραδείγματα από δικαστικές αποφάσεις παρακάτω.

Παράδειγμα δικαστικής απόφασης που αρνήθηκε την υποχρέωση εφαρμογής λόγω απουσίας αναφοράς

Στο παράδειγμα δικαστικής απόφασης που παραθέτουμε παρακάτω, ο προμηθευτής ανέπτυξε ένα σύστημα που είχε φτάσει στο στάδιο της προσωρινής λειτουργίας, όταν ο χρήστης ζήτησε την ακύρωση της σύμβασης λόγω ελλείψεων στις απαιτούμενες λειτουργίες. Η “αυτόματη ενημέρωση δεδομένων” ήταν η λειτουργία που ο χρήστης ισχυρίστηκε ότι έλειπε, και αυτή υποτίθεται ότι ήταν ένα από τα κύρια σημεία πώλησης του συστήματος, αλλά το δικαστήριο δεν αναγνώρισε αυτήν την υποχρέωση εφαρμογής.

Όπως αναγνωρίστηκε παραπάνω, δεν υπάρχει καμία αναφορά στη σύμβαση ή στα βασικά και λεπτομερή σχέδια που να υποδεικνύει ότι η λειτουργία ③ ήταν στόχος ανάπτυξης του συστήματος.

Ο αγωγεύς υποστηρίζει ότι η λειτουργία ③ ήταν ένα από τα κύρια σημεία πώλησης του συστήματος από τον ενάγοντα προς τον αγωγεύοντα, και τονίζει την ανάγκη για αυτήν τη λειτουργία, αλλά αν αυτό ήταν αλήθεια, θα έπρεπε να έχει σημειωθεί στη σύμβαση και άλλα έγγραφα, και είναι δύσκολο να πιστέψουμε ότι η ανάπτυξη αυτής της λειτουργίας συμφωνήθηκε χωρίς αυτήν την αναφορά.

Απόφαση του Δικαστηρίου του Τόκιο, 18 Φεβρουαρίου 2009 (Heisei 21)

Αυτή η απόφαση, αν πάρουμε μόνο το συμπέρασμα, μπορεί να φαίνεται ότι λέει “αν δεν υπάρχει αναφορά στο σχέδιο, δεν χρειάζεται να δημιουργήσετε κάτι που δεν υπάρχει”. Ωστόσο, για να είμαστε πιο ακριβείς, δεν είναι ένα απλό ζήτημα του αν υπάρχει αναφορά στο σχέδιο ή όχι, αλλά μια απόφαση που λαμβάνει υπόψη την “πρόθεση” των αναφορών στο σχέδιο και τη σύμβαση. Δηλαδή, “αν λάβουμε υπόψη τους λόγους για τους οποίους δεν υπήρχε αναφορά στο σχέδιο ή τη σύμβαση, είναι λογικό να θεωρήσουμε ότι δεν υπήρχε συμφωνία που να αντιστοιχεί σε αυτήν την αναφορά”.

Περιπτώσεις δικαστικών αποφάσεων που επιβεβαιώνουν την υποχρέωση υλοποίησης ακόμη και χωρίς γραπτή αναφορά

Από την άλλη πλευρά, υπάρχουν περιπτώσεις δικαστικών αποφάσεων που έχουν καταλήξει στο συμπέρασμα ότι θα πρέπει να αναγνωριστεί η υποχρέωση υλοποίησης, ακόμη και αν δεν υπάρχει γραπτή αναφορά σε συμβόλαια ή τεχνικές προδιαγραφές. Η παρακάτω περίπτωση που παραθέτουμε αφορά την ανάπτυξη ενός συστήματος για τη διαχείριση της ιστορίας φαρμακευτικής αγωγής, όπου δεν ήταν δυνατή η μεταφορά δεδομένων από το υπάρχον σύστημα στο νέο, με αποτέλεσμα να μην μπορεί να χρησιμοποιηθεί το νέο σύστημα και ο χρήστης να ακυρώσει τη σύμβαση. Ωστόσο, η πλευρά του προμηθευτή αντιτάχθηκε, ισχυριζόμενη ότι η μεταφορά δεδομένων δεν ήταν εντός του πεδίου των υποχρεώσεών της.

Η ανάπτυξη ενός νέου συστήματος συχνά συνοδεύεται από την κατάργηση του υπάρχοντος συστήματος και τη μεταφορά δεδομένων. Η σημασία αυτών των εργασιών και τα συναφή νομικά ζητήματα εξηγούνται λεπτομερώς στο παρακάτω άρθρο.

Σχετικό άρθρο: Νομικά ζητήματα που συνδέονται με τη μετάβαση από το παλιό σύστημα στην ανάπτυξη συστημάτων

Στο υπάρχον σύστημα έχουν ήδη αποθηκευτεί δεδομένα περισσότερων από 50.000 ασθενών και ο εφεσίβλητος χρησιμοποιούσε αυτά τα δεδομένα για να βελτιώσει την αποδοτικότητα των εργασιών του. Είναι προφανές ότι, αν δεν μπορούσε να μεταφέρει τα δεδομένα των ασθενών από το υπάρχον σύστημα στο νέο, θα προκαλούσε προβλήματα στην εκτέλεση των φαρμακευτικών εργασιών στο φαρμακείο. Επίσης, είναι λογικό να θεωρηθεί ότι ο εκπρόσωπος του εφεσίβλητου ήταν ενήμερος για αυτό. Επιπλέον, παρά το γεγονός ότι η μεταφορά δεδομένων δεν ήταν προϋπόθεση στην παρούσα σύμβαση, είναι δύσκολο να φανταστούμε ότι ο εφεσίβλητος θα επέλεγε να εκτελέσει αυτήν την εργασία που απαιτεί τόσο χρόνο ως υπηρεσία.

Απόφαση του Δικαστηρίου του Τόκιο, 18 Νοεμβρίου 2010 (Έτος Heisei 22)

Αυτό που είναι σημαντικό εδώ είναι ο σκοπός της σύμβασης και η “έννοια” των στοιχείων που αναφέρονται στη σύμβαση. Το δικαστήριο επεσήμανε ότι, αν οι δύο πλευρές είχαν συνάψει τη σύμβαση με την επίγνωση ότι η μεταφορά δεδομένων δεν ήταν εντός του πεδίου των υποχρεώσεών τους, θα ήταν ασυνήθιστο για και τους δύο να έχουν συνάψει τη σύμβαση με αυτήν την πρόθεση. Δηλαδή, ο χρήστης θα έπρεπε να αναλάβει έναν τεράστιο όγκο εργασίας χειρόγραφα, ενώ ο προμηθευτής θα έπρεπε να προσεγγίσει το έργο γνωρίζοντας ότι θα προκαλούσε προβλήματα στις εργασίες του χρήστη στο μέλλον, κάτι που είναι εξαιρετικά ανεπίληπτο.

Τι μπορούμε να καταλάβουμε από τις δύο αποφάσεις

Σχετικά με τη μεταφορά δεδομένων, ακόμη και αν δεν υπάρχει αναφορά σε συμβόλαιο ή τεχνικές προδιαγραφές, φαίνεται ότι το πλαίσιο για την υλοποίηση έχει επικυρωθεί. Ένας από τους λόγους για αυτό είναι ότι η συζήτηση αφορούσε τα “δεδομένα”, ένα θέμα που δεν εμφανίζεται στην εμφάνιση της οθόνης. Η “έλλειψη απαραίτητων λειτουργιών” που αναφέρεται παραπάνω είναι κάτι που εμφανίζεται απευθείας στην εμφάνιση και την οθόνη του συστήματος. Επομένως, ακόμη και για έναν αρχάριο στην ανάπτυξη συστημάτων, δεν είναι πολύ δύσκολο να ανακαλύψει την παράλειψη στις τεχνικές προδιαγραφές. Από την άλλη πλευρά, το ζήτημα της μεταφοράς δεδομένων έχει την ιδιαιτερότητα ότι είναι δύσκολο για έναν αρχάριο στην ανάπτυξη συστημάτων να αναγνωρίσει τη σημασία της διαδικασίας, τη δυσκολία της εργασίας και τον χρόνο που απαιτείται. Επομένως, υπάρχει η πεποίθηση ότι υπήρχαν περιπτώσεις όπου θεωρούνταν ότι ο προμηθευτής θα έπρεπε να διαχειριστεί ομαλά το ζήτημα με επαγγελματικότητα.

Αν το σκεφτούμε έτσι, η παράλειψη στις τεχνικές προδιαγραφές και τα συμβόλαια μπορεί να θεωρηθεί ότι σχετίζεται άμεσα με το “καθήκον συνεργασίας” του χρήστη. Δηλαδή, το ζήτημα είναι εάν ο χρήστης έχει πραγματικά εκπληρώσει το “καθήκον συνεργασίας” για τη σύναψη συμβολαίου και τη δημιουργία τεχνικών προδιαγραφών. Μια γενική εξήγηση των νομικών καθηκόντων που πρέπει να εκπληρώσει ο χρήστης σε ένα έργο ανάπτυξης συστήματος παρέχεται στο παρακάτω άρθρο.

Σχετικό άρθρο: Τι είναι το καθήκον συνεργασίας που πρέπει να εκπληρώσει ο χρήστης που παραγγέλνει την ανάπτυξη συστήματος

Αν ελέγξετε και το παραπάνω άρθρο, θα καταλάβετε αυτομάτως ότι η συζήτηση διαφέρει σημαντικά όταν παραλείπεται η εξέταση της μεταφοράς δεδομένων, σε σχέση με τομείς όπου απαιτείται μεγάλη συνεργασία από τον χρήστη, όπως η εξαγωγή οθόνης και απαραίτητων λειτουργιών.

Πώς πρέπει να αντιμετωπίζουμε την αμοιβή για την ανάπτυξη που δεν περιλαμβάνεται στις προδιαγραφές;

Ένα άλλο θέμα που μπορεί να σας ενδιαφέρει σχετικά με το θέμα αυτού του άρθρου είναι εάν είναι νομικά αποδεκτό να ζητηθεί επιπλέον αμοιβή για τη δημιουργία κάτι που δεν περιλαμβάνεται στις προδιαγραφές. Σχετικά με το εάν είναι δυνατή η αύξηση της αμοιβής και τον τρόπο υπολογισμού του εκτιμώμενου ποσού σε περίπτωση που είναι δυνατό, παρέχουμε λεπτομερή εξήγηση στο παρακάτω άρθρο.

Σχετικό άρθρο: Είναι δυνατή η αύξηση του εκτιμώμενου ποσού για την ανάπτυξη συστημάτων;

Στο παραπάνω άρθρο, εξηγούμε ότι είναι σημαντικό εάν υπήρχαν εργασίες που υπερβαίνουν το πεδίο εργασίας που σχετίζεται με την αμοιβή και την ανταμοιβή. Δηλαδή, σε σχέση με αυτό το άρθρο, εάν ο προμηθευτής ανταποκριθεί στην ανάπτυξη κάτι που δεν περιλαμβάνεται στις αρχικές προδιαγραφές (δηλαδή, το αρνητικό παράδειγμα σε αυτό το άρθρο), τότε είναι δυνατό να αποδεχτεί επιπλέον αίτηση για αμοιβή.

Συμπέρασμα

Στην ανάπτυξη συστημάτων, ο ρόλος που πρέπει να εκπληρώσει ο προμηθευτής καθορίζεται, από τη μία πλευρά, από το περιεχόμενο των συμβάσεων και των τεχνικών προδιαγραφών. Ωστόσο, λαμβάνοντας υπόψη ότι έχουν ανατεθεί καθήκοντα με βάση την υψηλή εμπιστοσύνη ως ειδικοί, καταλαβαίνουμε ότι η πραγματικότητα δεν καθορίζεται από την τυπικότητα. Ωστόσο, κατά την κατανόηση της πραγματικότητας, πρέπει να κατανοήσουμε ότι ο νόμος παίζει σημαντικό ρόλο.