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

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

Τι θα λέγαμε έξω από τα δόντια: Μην «σνομπάρετε» την ανάλυση και μην επιχειρείτε να αρχίσετε να γράφετε datagrids και φόρμες με το «καλημερα». Οι πιθανότητες είναι ότι θα χτυπάτε το κεφάλι σας στον τοίχο πολύ σύντομα.

Για την εταιρία: Φροντίστε να εκμεταλλευθείτε το ανθρώπινο δυναμικό που έχετε στη διάθεσή σας με τον καλύτερο δυνατό τρόπο. Λαβετε υπόψη ότι η συλλογή και η σωστή κατάρτιση προδιαγραφών πολλές φορές αναλώνει σημαντικό μέρος του συνολικού χρόνου ανάπτυξης και διαθέστε εκεί τους απαιτούμενους πόρους. Εξασφαλίστε απρόσκοπτη επικοινωνία με τους εκπροσώπους του πελάτη οι οποίοι θα σας προσφέρουν όλες τις απαιτούμενες πληροφορίες. Αναθέστε σε ένα άτομο ή μια όμάδα ανθρώπων τη συλλογή προδιαγραφών για κάθε έργο που αναλαμβάνετε. Εντάξτε το κόστος της συλλογής προδιαγραφών στο συνολικό κόστος του έργου. ΒΑΛΤΕ ΤΟΝ ΠΕΛΑΤΗ ΝΑ ΥΠΟΓΡΑΨΕΙ. Αν φοβάστε ότι με τις προδιαγραφές το κόστος θα εκτιναχθεί στα ύψη και ο πελάτης δεν θα συμφωνήσει, ΜΗΝ ΑΝΑΛΑΜΒΑΝΕΤΕ ΤΟ ΕΡΓΟ. Καλύτερα μια άμεση απώλεια παρά μια εικονική «ανάσα» στα οικονομικά της εταιρίας σας με μακροπρόθεσμες δυσάρεστες συνέπειες που θα σας βάλουν ακόμα πιο «μεσα» από πριν.

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

Η δημοσίευση αυτή αντιγράφεται από την πρωτότυπη δημοσίευση (απο το blog μου) με σκοπό τη συζήτησή της.

Disclaimer: Οι παραπάνω απόψεις και θέσεις ανήκουν στο συγγραφέα της δημοσίευσης και μπορούν να χαρακτηριστούν υποκειμενικές. Η αρχική ιδέα της συγγραφής βασίστηκε πάνω σε μια δημοσίευση που έγινε στο JoelOnSoftware.com και την οποια μπορείτε να βρείτε εδώ: http://www.joelonsoftware.com/articles/fog0000000043.html. Δεν διεκδικούν σε καμμια περίπτωση τον τίτλο επίσημων συμβουλών παραγωγικότητας και η συζήτηση ή / και αμφισβήτησή τους όχι μόνο επιτρέπεται, αλλά ενθαρρύνεται!

---

Σωτήρης Φιλιππίδης

DotSee Web Services

"Ποιά είναι η σχέση σας με τις προδιαγραφές;"
Καταραμένη! Τι άλλο;

Δεν σας φαίνεται ουτοπικό να κλείσετε κάθε πιθανή τρύπα που θα βρει ο πελάτης; Τουλάχιστον για Ελλάδα αφού εδώ δουλεύουμε. Ως τώρα τουλάχιστον μου έχει φανεί αδύνατο να αποφύγω το ράβε ξήλωνε, ακριβώς για τους λόγους που αναφέρεις. Κανείς δε λογαριάζει τις προδιαγραφές σοβαρά στο χρόνο του έργου, προκειμένου να αναλάβει το έργο. Οι εκπτώσεις είναι τεράστιες αφού και οι συμβάσεις των έργων μπάζουν από παντού. Μήπως δεν γελάμε όλοι όταν μας πουν τα deadline που υπογράφουν; Έχει γίνει τόσο συνηθισμένο να παραβιάζονται πια. Ας πάρουμε τη σύμβαση και μετά βλέπουμε σου λέει. Και φυσικά όσο μικρότερη η εταιρεία τόσο εντονότερο το φαινόμενο. Που καιρός για τέτοιες πολυτέλειες.

---

Εις τον στρατό Καραμάνο δεν γίνονται διακρίσεις! Και επιστήμων να είσαι, σκατά θα καθαρίσεις!

kcb wrote:

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

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

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Συμφωνώ σ'αυτά που λες. Να εξηγήσω καλύτερα τι είδους project είχα κατά νου όταν έγραφα τα παραπάνω: Ο πελάτης προσπαθεί να βγάλει από τη μύγα ξύγκι και εκμεταλευόμενος τα παραθυράκια των προδιαγραφών, δεν κλείνει ποτέ τον πρώτο κύκλο του έργου (οπότε και θα πρέπει να καταβάλει το αντίτιμο...) Ισχυρίζεται ότι δεν πήρε αυτό που είχε συμφωνηθεί και πιέζει την εταιρεία να του βάλει κι άλλα στην ίδια τιμή. Η εταιρεία αν έχει πλάτες και είναι σοβαρή έχει λάβει τα μέτρα της και πάει στα δικαστήρια. Αν είναι μικρή κι έχει ανάγκη το project βάζει το κεφάλι κάτω και συνεχίζει μέχρι να εξαντληθούν οι developers, τα λεφτά της ή και τα δύο ή μέχρι να φιλοτιμηθεί να πετάξει κανένα κοκκαλάκι ο πελάτης να πληρώσει τον κόσμο της.
Δεν ξέρω αν μόνο εγώ έχω δει τέτοιο project.
Αυτό που αναφέρεις είναι η καθόλα αποδεκτή διαδικασία ενός δεύτερου κύκλου πιθανά μετά τα UAT αλλά αφού έχει κλείσει ένα πρώτο μέρος του έργου με αποδοχή και από τις δύο πλευρές.
Επίσης να προσθέσω σ'αυτά που αναφέρεις την παντοτινή αποστροφή των χρηστών (ιδιαίτερα των μεγαλύτερων σε ηλικία ή αυτών που βολευόταν από κάποια κατάσταση...) προς οτιδήποτε καινούργιο με αποτέλεσμα να μη συνεργάζονται στην καταγραφή προδιαγραφών και να δημιουργούν ηθελημένα ή όχι εμπόδια.

---

Εις τον στρατό Καραμάνο δεν γίνονται διακρίσεις! Και επιστήμων να είσαι, σκατά θα καθαρίσεις!

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

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

kcb, εμείς είχαμε 2 περιπτώσεις project χωρίς σαφείς προδιαγραφές.

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

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

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

Ωστόσο, αν υπήρχε η δυνατότητα για δημιουργία προδιαγραφών και αναλυτική καταγραφή απαιτήσεων από την αρχή, θα είχε τελειώσει στα 2/3 του χρόνου.

---

Μην αφήνετε τα media να σας "ταΐζουν"!

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

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

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Mitsaras wrote:

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

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

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

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

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

papadi wrote:

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

Γενικά είναι σωστό αυτό για να μην πω αυτονόητο. Στην περίπτωση όμως μικρών εταιρειών που ανέφερα έχω δει να σέρνεται κυριολεκτικά η εταιρεία από τον πελάτη, να έχει τελειώσει το 70-80% του project και να μην έχουν πέσει υπογραφές στις προδιαγραφές!!!! .... Και στο meeting για υπογραφή μετά από όλη αυτή τη δουλειά να σου λένε ότι αν δε δεχτείτε να κάνετε ό,τι ζητάμε (επιπλέον των αρχικών ανυπόγραφων προδιαγραφών) σταματάμε επι τόπου το project. Μεγάλη εταιρεία είμαστε τι είναι για εμάς το Χ ποσό που είχαμε δώσει για προκαταβολή; Θα πάμε αλλού.... Ξέρει βέβαια αυτός που το λέει εκ μέρους του πελάτη ότι η εταιρεία είναι μικρή και τον έχει ανάγκη...

---

Εις τον στρατό Καραμάνο δεν γίνονται διακρίσεις! Και επιστήμων να είσαι, σκατά θα καθαρίσεις!

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

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

Τελικώς, έχω αποφασίσει να πιέζω πολύ περισσότερο για προδιαγραφές από εδώ και εμπρός. Όπως είπε και ο cap, και οι developers έχουν άποψη και δύναμη επ' αυτού!!!

Feel the Force! Developers unite!

---

Στερνή μου γνώση να σε είχα πρώτα...

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

---

Who Dares Wins