Η εκτίμηση χρόνου υλοποίησης είναι μεγάλο κεφάλαιο, και πολύ δύσκολο.
Το βασικό για μένα είναι να υπάρχει διαδικασία εκτίμησης. Τι εννοώ με αυτό; Να μην προσπαθεί απλα ο εκάστοτε project manager να "εκμαιεύσει" από τον developer το χρόνο που ο ίδιος ο PM πιστεύει οτι χρειάζεται για την υλοποίηση του έργου, ή, ακόμα χειρότερα, έχει ήδη υποσχεθεί. Ειχα διαβάσει ένα σχετικό κείμενο στο "Death March" του Yourdon, με χαρακτηριστική τη φράση "Guess what I'm thinking".
Αν αυτό το εμπόδιο ξεπεραστεί, έχουμε έπειτα το πρόβλημα της αξιόπιστης εκτίμησης χρόνου από τον ίδιο τον Developer. Ας δουμε ποια δυο σημεία χρήζουν προσοχής σε αυτό το θέμα:
1. Ο developer δεν μπορεί να εκτιμήσει σωστά τον απαιτούμενο χρόνο λόγω μικρής εμπειρίας
2. Οι προδιαγραφές δεν είναι πλήρεις ή διαμορφώνονται "on the go" (σύνηθης πρακτική στην Ελλάδα αλλά όχι μόνο)
Η περίπτωση (1) συναντάται συχνά. Προσωπικά, έχει τύχει να δώσω *απελπιστικά* λανθασμένες εκτιμήσεις (μιλάμε για διαφορά 300%) λόγω απειρίας αλλά και, ορισμένες φορές, λόγω επιπολαιότητας. Ολοι πιστεύω έχουμε περάσει ή θα περάσουμε τουλάχιστον μια φορά από αυτό. Το "φαρμακο" για αυτές τις περιπτώσεις είναι να την πατήσεις 1-2 φορές, και να μάθεις να εκτιμάς όλες τις παραμέτρους και τους πιθανούς κινδύνους πριν ξεστομίσεις ένα νούμερο. Α, και πάντα να δίνεις +/- 20% περιθώριο σε αυτό που λές.
Το (2) είναι δυστυχώς πολύ δύσκολη κατάσταση. Εκεί, αν είσαι πονηρός, υπολογίζεις το χρόνο που θα ήθελες πραγματικά αν όλα ήταν fixed και τον προσαρμόζεις προς τα πάνω κατα βούληση σε σχεση με την εμπειρία που πιθανόν έχεις από τον πελάτη ή από τον τρόπο με τον οποίο η εταιρία συμπεριφέρεται σε σχέση με τους πελάτες.
Σωτήρης Φιλιππίδης
DotSee Web Services