Ποιες είναι οι υποχρεώσεις συνεργασίας που αναλαμβάνει ο πελάτης ως εντολέας στην ανάπτυξη συστημάτων

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

Αυτό διαφέρει από τις συνήθεις σχέσεις παραγγελίας και προμήθειας. Για παράδειγμα, όταν κάποιος παραγγέλνει ένα σύνολο για ένα προσαρμοσμένο κοστούμι από έναν έμπορο κοστουμιών, ο πελάτης (χρήστης) δεν έχει καμία «υποχρέωση». Η «υποχρέωση» βαρύνει αποκλειστικά τον προμηθευτή, δηλαδή τον έμπορο κοστουμιών (προμηθευτή). Είναι η δομή του IT συστήματος που απαιτεί πολλά χέρια και χρόνο που καθιστά απαραίτητη την «συνεργασία» του χρήστη με τον προμηθευτή.

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

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

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

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

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

Τι είναι οι υποχρεώσεις συνεργασίας του χρήστη βάσει της νομολογίας

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

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

“`html

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

Απόφαση του Δικαστηρίου του Τόκιο, Έτος Χέισει 16 (2004), 10 Μαρτίου

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

Ας δοκιμάσουμε να μεταφράσουμε τα λόγια της παραπάνω απόφασης σε IT όρους ανάπτυξης συστημάτων.

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

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

“`

Πώς ερμηνεύονται τα αιτήματα για αλλαγές στις προδιαγραφές μετά την εκτέλεση;

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

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

Σε τέτοιες περιπτώσεις, πώς πρέπει να σκεφτούμε όταν δεν τηρούνται οι προθεσμίες; Αναλύοντας παλαιότερες δικαστικές αποφάσεις, φαίνεται ότι τα συμπεράσματα διαφέρουν ανάλογα με το χρόνο που προέκυψε η ανάγκη για επιπλέον εργασία.

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

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

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

Απόφαση του Δικαστηρίου του Τόκιο, 16ο έτος της εποχής Χέισει (2004), 10 Μαρτίου

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

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

Σε περίπτωση που η επιπλέον εργασία πραγματοποιήθηκε μετά την οριστικοποίηση των προδιαγραφών στην κατασκευή ή τη δοκιμαστική διαδικασία

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

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

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

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

Σχετικό άρθρο: Πώς να κρατάτε τα πρακτικά στην ανάπτυξη συστημάτων από νομική σκοπιά[ja]

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

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

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