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

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

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

Γιατί τα έργα ανάπτυξης συστημάτων “αλλάζουν” μετά την ολοκλήρωσή τους;

Η ανάπτυξη συστημάτων είναι μια κοινή προσπάθεια του προμηθευτή και του χρήστη

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

https://monolith.law/corporate/user-obligatory-cooperation[ja]

Παρά την υποχρέωση συνεργασίας, οι χρήστες συχνά ζητούν αλλαγές

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

Τι είναι το Έγγραφο Διαχείρισης Αλλαγών

Περιπτώσεις χρήσης του Εγγράφου Διαχείρισης Αλλαγών

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

Παραδείγματα περιπτώσεων όπου είναι απαραίτητο το Έγγραφο Διαχείρισης Αλλαγών περιλαμβάνουν:

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

Αυτά είναι μερικά παραδείγματα.

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

https://monolith.law/corporate/increase-of-estimate[ja]

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

Στοιχεία που πρέπει να αναφέρονται στο Έγγραφο Διαχείρισης Αλλαγών

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

(Διαδικασία Διαχείρισης Αλλαγών)
Άρθρο 37 Ο Α ή Β, όταν λάβει πρόταση αλλαγής βάσει του άρθρου 34 (Αλλαγή των προδιαγραφών του συστήματος κ.λπ.), του άρθρου 35 (Έγκριση των ενδιάμεσων υλικών από τον χρήστη), του άρθρου 36 (Χειρισμός των αναπροσδιοριστικών θεμάτων), πρέπει να παραδώσει στον αντίπαλο εντός Χ ημερών από την ημερομηνία λήψης, ένα έγγραφο (εφεξής αναφέρεται ως “Έγγραφο Διαχείρισης Αλλαγών”) που περιέχει τα εξής στοιχεία. Ο Α και Β θα συζητήσουν για την αποδοχή ή όχι της προτεινόμενης αλλαγής στην επιτροπή επικοινωνίας που ορίζεται στο άρθρο 12.
① Όνομα της αλλαγής
② Υπεύθυνος της πρότασης
③ Ημερομηνία
④ Λόγος της αλλαγής
⑤ Λεπτομερή στοιχεία της αλλαγής, συμπεριλαμβανομένων των προδιαγραφών που σχετίζονται με την αλλαγή
⑥ Αν η αλλαγή απαιτεί κόστος, το ποσό αυτού
⑦ Χρονοδιάγραμμα των εργασιών αλλαγής, συμπεριλαμβανομένης της περιόδου εξέτασης
⑧ Άλλες επιπτώσεις της αλλαγής στους όρους αυτής της σύμβασης και των ειδικών συμβάσεων (περίοδος εργασίας ή προθεσμία παράδοσης, αμοιβή, όροι της σύμβασης κ.λπ.)

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

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

Αυτά που θα ήταν καλό να γνωρίζετε σχετικά με τη διαχείριση αλλαγών

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

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

Είναι καλύτερο να καθορίσετε επίσης τον τρόπο διεξαγωγής των διαπραγματεύσεων για αλλαγές

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

Συζήτηση για αλλαγές και υποχρέωση ειλικρίνειας

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

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

Για παράδειγμα, ένα παράδειγμα διατύπωσης είναι το εξής (αναφέρεται παράδειγμα του άρθρου από το “Πρότυπο Συμβόλαιο Βασικής/Ειδικής Σύμβασης” που δημιουργήθηκε επίσημα από τον Ιαπωνικό Οργανισμό Προώθησης Επεξεργασίας Πληροφοριών).

Άρθρο 4, παράγραφος 3: Στη συζήτηση για αλλαγές, θα εξεταστούν τα θέματα της αλλαγής, η δυνατότητα αλλαγής, οι επιπτώσεις της αλλαγής στην τιμή και την προθεσμία παράδοσης, και και οι δύο μέρη θα συζητήσουν ειλικρινά για το αν θα γίνει η αλλαγή.

Διατάξεις για την Τροποποίηση

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

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Περίληψη

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

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