Ποιο είναι το Ιαπωνικό νομικό πλαίσιο που αφορά την 'κατάρρευση' ενός έργου ανάπτυξης συστημάτων

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

Γιατί «Φλέγονται» τα Προγράμματα;

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

• Η προθεσμία παράδοσης έχει καθοριστεί εκ των προτέρων, ενώ οι προδιαγραφές και οι απαιτήσεις παραμένουν ασαφείς καθώς περνά ο χρόνος
• Τα μέλη της ομάδας αποσπώνται από τα προβλήματα της εσωτερικής πολιτικής της εταιρείας, με αποτέλεσμα πολλοί να εγκαταλείπουν λόγω του στρες των ανθρώπινων σχέσεων
• Υπάρχει έλλειψη διαπραγματευτικών ικανοτήτων στο επίπεδο της διοίκησης, συμπεριλαμβανομένου του PM, και δεν απαιτείται από τα μέλη η κατάλληλη αναφορά, επικοινωνία και συμβουλή

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

Τύπος Φλεγόμενου Έργου 1: Όταν ένα έργο αποτυγχάνει στη μέση της διαδικασίας

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

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

https://monolith.law/corporate/project-management-duties[ja]

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

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

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

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

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

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

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

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

Τύπος Φλεγόμενου Προβλήματος 2: Όταν ο χρήστης ακυρώνει για προσωπικούς λόγους

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

Κατ’ αρχάς, το ζήτημα του πώς πρέπει να κατασκευαστεί ένα IT σύστημα που χρησιμοποιείται από μια εταιρεία δεν μπορεί να αποσπαστεί από το προκαταρκτικό ερώτημα του ‘ποιες είναι οι εργασίες που υπάρχουν εντός της εταιρείας’. Ως εκ τούτου, είναι πραγματικά πιθανό ότι οι απαιτήσεις για το απαιτούμενο (ή περιττό) σύστημα μπορεί να αλλάξουν μετά από σημαντικές αλλαγές στη δομή της οργάνωσης, την επανασύνθεση των τμημάτων της επιχείρησης ή μια ριζική αναθεώρηση της στρατηγικής.

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

・Σε περίπτωση σύμβασης ανάθεσης έργου: Άρθρο 641 του Αστικού Κώδικα
Άρθρο 641 του Αστικού Κώδικα
→ Ο παραγγελιοδόχος μπορεί να ακυρώσει τη σύμβαση ανά πάσα στιγμή, αποζημιώνοντας τον εργολάβο για τυχόν ζημιές, εφόσον το έργο δεν έχει ολοκληρωθεί.
・Σε περίπτωση σύμβασης παρόμοιας με εντολή: Άρθρο 648 παράγραφος 3 του Αστικού Κώδικα (ανάλογα με τις συνθήκες, μπορεί να υπάρξει και απαίτηση αποζημίωσης βάσει του Άρθρου 651)
Άρθρο 648 του Αστικού Κώδικα
→ Εάν η εντολή τερματιστεί στη μέση της εκτέλεσης λόγω αιτίας που δεν μπορεί να αποδοθεί στον εντολοδόχο, ο εντολοδόχος μπορεί να απαιτήσει αμοιβή ανάλογη με το μέρος της εργασίας που έχει ήδη εκτελέσει.
Άρθρο 651 του Αστικού Κώδικα
→ 1. Η εντολή μπορεί να ακυρωθεί ανά πάσα στιγμή από κάθε μέρος.
→ 2. Εάν ένα από τα μέρη ακυρώσει την εντολή σε μια περίοδο που είναι μειονεκτική για το άλλο μέρος, το μέρος που προχώρησε στην ακύρωση πρέπει να αποζημιώσει το άλλο μέρος για τυχόν ζημιές, εκτός αν υπήρχε αναγκαστικός λόγος για την ακύρωση.

Τύπος Φλεγόμενου Ζητήματος 3: Όταν ανακαλύπτονται ελλείψεις στο παραδοθέν σύστημα αργότερα

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

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

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

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

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

Τα σημεία που πρέπει να εξεταστούν σε αυτή την περίπτωση μπορούν να οργανωθούν ως εξής:

https://monolith.law/corporate/defect-warranty-liability[ja]

Τα παραπάνω σημεία οργανώνονται κατ’ αυτόν τον τρόπο.

Συνοπτικά

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

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