Στο σύμπαν των έργων πληροφορικής, το περίφημο τρίγωνο ποιότητα – κόστος – χρόνος (γνωστό και ως project management triangle) λειτουργεί ως το θεμελιώδες αξίωμα αλλά και ως διαρκές δίλημμα. Η βασική του υπόθεση είναι απλή: μπορείς να βελτιώσεις δύο πλευρές, αλλά όχι την τρίτη, χωρίς συνέπειες. Αν επιθυμείς υψηλή ποιότητα με γρήγορη παράδοση, τότε θα χρειαστείς μεγαλύτερο κόστος. Αν περιορίσεις το κόστος και θέσεις αυστηρό χρονοδιάγραμμα, θα πρέπει να θυσιάσεις την ποιότητα. Η εξίσωση δείχνει απλή. Στην πράξη, όμως, είναι συχνά ψευδής.
Το πρόβλημα δεν είναι το τρίγωνο καθαυτό, αλλά η χρήση του ως δικαιολογία για επιλογές χωρίς ορατότητα. Σε πολλές περιπτώσεις, το τρίγωνο καταλήγει να καλύπτει την έλλειψη σαφών προτεραιοτήτων ή την απουσία στρατηγικής. Η επιλογή, για παράδειγμα, να υποβαθμιστεί η ποιότητα σε ένα έργο ώστε να «πιαστεί το deadline», δεν είναι ουδέτερη απόφαση, αλλά προκαθορισμός τεχνικού χρέους και μελλοντικής αποτυχίας.
Ας δούμε ένα παράδειγμα από τον τραπεζικό τομέα: μια νέα πλατφόρμα mobile banking, με στόχο τη γρήγορη είσοδο στην αγορά, εκτελέστηκε με περιορισμένο budget και πίεση χρόνου. Το αποτέλεσμα ήταν μια εντυπωσιακή πρώτη έκδοση, με εξαιρετικό UI — αλλά με ασταθές backend και ανεπαρκές testing. Σε διάστημα τριών μηνών, τα παράπονα πελατών πολλαπλασιάστηκαν, το προϊόν κατέρρευσε και η εταιρεία αναγκάστηκε να επενδύσει εκ νέου, αυτή τη φορά με υπερδιπλάσιο προϋπολογισμό, για να αποκαταστήσει τη ζημιά. Το τρίγωνο διαταράχθηκε — και το τίμημα πληρώθηκε σε αξιοπιστία και κόστος υποστήριξης.
Στην agile κουλτούρα, το τρίγωνο αποκτά μια νέα δυναμική: δεν είναι απαραίτητο να επιλέξεις μία γωνία εις βάρος των άλλων. Μέσα από πρακτικές όπως το incremental delivery, το definition of done, και το continuous integration, μπορείς να διαχειριστείς την πολυπλοκότητα χωρίς να ακυρώνεις την ποιότητα. Ωστόσο, απαιτείται πειθαρχία, ευθυγράμμιση μεταξύ επιχειρησιακών και τεχνικών stakeholders, και συνεχής διάλογος για το τι αξίζει πραγματικά να παραδοθεί τώρα και τι μπορεί να περιμένει.
Το κρίσιμο στοιχείο είναι η σαφήνεια των αξιών που διέπουν το έργο. Αν η αξία για τον τελικό χρήστη είναι η διαθεσιμότητα και η ευκολία χρήσης, τότε η καθυστέρηση για debugging δεν είναι “κόστος”, αλλά επένδυση. Αν το έργο προορίζεται για short-term demo χωρίς επιπτώσεις παραγωγής, τότε ίσως η γωνία της ταχύτητας να υπερισχύει προσωρινά. Κάθε έργο έχει τη δική του τοπολογία, και το τρίγωνο πρέπει να λυγίζει, όχι να ραγίζει.
Η συνειδητοποίηση ότι η ισορροπία στο τρίγωνο δεν είναι στατική αλλά διαρκώς επαναδιαπραγματεύσιμη, είναι ίσως η πιο ώριμη πράξη διακυβέρνησης έργων πληροφορικής.
Βιβλιογραφία
- Highsmith, J. (2009). Agile Project Management: Creating Innovative Products. Addison-Wesley.
- Boehm, B., & Turner, R. (2003). Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley.
- McConnell, S. (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press.
- Beck, K., & Andres, C. (2004). Extreme Programming Explained: Embrace Change. Addison-Wesley.
- DeMarco, T., & Lister, T. (2013). Waltzing with Bears: Managing Risk on Software Projects. Dorset House
Δεν υπάρχουν σχόλια:
Δημοσίευση σχολίου