Αναζήτηση του Άγιο Δισκοπότηρου Διαχείρησης Χρόνου και Deadlines σε project λογισμικού

[PC_MAGAS]

Καλησπέρες,

Πολλάκις στο εργασιακό περιβάλλον σας ζητάτε να υπολογίσετε χρόνο για το πόσο θα σου πάρει μια εργασία. Αλλά λόγο του μεγέθους των πρότζεκτ αυτό είναι πολές φορές οι εκτιμήσεις σου πάνε παρέα με τον Τιτανικό κατά Kαιάδα μεριά ειδικά όταν πέφτουν deadlines πολλές φορές τρέχεις με υπερωρίες και WD-40 και duct tape ή το τραβας μέχρι δεν ξέρεις πότε.

 

Αυτό έχει τις κάτωθι συνέπειες:

• Boss υπερνευριασμένο.
• Πελάτες στα πρόθυρα νευρικού κλωνισμού.
• Υπερωρίες λίγο πριν το release.

Δε εαν το συνδιάσεις με περιβάλλον το οποίο υπάρχουν και δυσκολίες όπως:

• Συχνές Αλλαγές.
• Block από άλλές εργασίες που τρέχουν παράλληλα.
• Ξαφνικές Αλλαγές στα Deadlines.
• Μικρό team για το μέγεθος του έργου.
• Δεν έχεις πλήρη επίγνωση του μεγέθουε του task-έργου.
• Ο πελάτης δεν ξέρει τι θέλει.

Τότε έχεις ένα "μικρό" εφιάλτη. Έτσι θέλω να ρωτήσω:

1. Πως εκτιμάς ποιο "σωστά" πόσο χρόνο θες για να πεις στο αφεντικό;
2. Σε περίπτωση λάθους εκτίμησης πως το διαχειρίζεσε;
3. Εαν εσύ είσαι αφεντικό-leader πως εξαλείφεις και βοηθάς το προσωπικό να δώσει ποιο σωστές εκτιμήσεις;
4. Στην τελική μπορείς να δώσεις μια εκτίμηση για ένα project λογισμικού εαν ναι πως;

H ερώτηση πηγάζει από επέκταση χρόνου μετά από deadline και πιθανή δεύτερη επέκταση.

[tsofras]

Η λύση μπορεί να είναι η agile μεθοδολογία. 

Τουλάχιστον σύμφωνα με την δική μου εμπειρία με τον κλασικό project manager που δεν έχει γράψει ποτέ κώδικα και σου φτιάχνει το deadline όπως θέλει αυτός , ή waterfall που καταλαβαίνεις μετά απο 12 μήνες οτι τελικά θές άλλους 12 για να τελειώσεις και κάνει fail το project , δουλεύοντας agile τον τελευταίο χρόνο ( scrum για την ακρίβεια) βλέπω ότι σώζεις όλα τα παραπάνω.

 

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

 

Αν έχεις όρεξη ρίξε μια ματιά και στο spotify που δουλεύει με αυτόν τον τρόπο

 

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

 

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

[defacer]

Πως εκτιμάς ποιο "σωστά" πόσο χρόνο θες για να πεις στο αφεντικό;

Σε περίπτωση λάθους εκτίμησης πως το διαχειρίζεσε;

Εαν εσύ είσαι αφεντικό-leader πως εξαλείφεις και βοηθάς το προσωπικό να δώσει ποιο σωστές εκτιμήσεις;

Στην τελική μπορείς να δώσεις μια εκτίμηση για ένα project λογισμικού εαν ναι πως;

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

 

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

 

Αυτό το σπάσιμο των εργασιών φυσικά θέλει δουλειά (that is the whole point, αναγκάζοντάς σε να το σπάσεις σε κομμάτια αναγκάζεσαι να σκεφτείς πολύ συγκεκριμένα τι θα περιλαμβάνει καθένα από αυτά, οπότε μπορείς να το εκτιμήσεις ακριβέστερα) και πολύ συχνά ο ίδιος άνθρωπος που θέλει την εκτίμηση θεωρεί αυτή τη δουλειά υπερβολική και χωρίς αντίκρισμα. Μου έχει τύχει αυτή η περίπτωση, εκεί είναι η φάση που σηκώνεις το ανάστημά σου σαν επαγγελματίας και λες (σε λογικά πάντα πλαίσια) my way or the highway. Δε νομίζω ότι θα δυσκολευτείς πάντως γιατί ο μάνατζερ ήδη έχει δει με τα μάτια του το πόσο εκτός πραγματικότητας είναι οι εκτιμήσεις που γίνονται διαφορετικά, οπότε όσο και να πιέζει κατά βάθος ξέρει πως έχεις δίκιο.

 

Τώρα, το rule of thumb λέει χαριτολογώντας πως αφού κάνεις εκτίμηση, τη διπλασιάζεις, προσθέτεις άλλο 1/3 (του διπλάσιου) και αυτό είναι το νούμερο που θα πεις. Ή όπως το λένε αλλού, το πρώτο 80% της δουλειάς απαιτεί το 80% του χρόνου, και το τελευταίο 20% της δουλειάς απαιτεί το άλλο 80% του χρόνου.   

 

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

 

Ακόμα και τέλεια να είναι η εκτίμηση με κάποιο μαγικό τρόπο, πάλι το project θα έχει θέματα επειδή η ολόσωστη εκτίμηση έγινε παίρνοντας κάποια πράγματα σα δεδομένα:

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

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

 

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

 

Εκεί πρέπει λοιπόν να διαπιστώσεις:

• Πόσο εκτός προγράμματος είσαι, και πόσο θα είσαι μέχρι το τέλος αν συνεχίσεις έτσι. Εκτίμηση δηλαδή... 
• Αν υπάρχουν άλλες εναλλακτικές πέραν του "θα κοστίσει περισσότερο σε χρόνο και χρήμα" και ποιές είναι αυτές. Τυπικά όταν μιλάμε για software εκεί είναι που βγαίνουν τα τσεκούρια και φαίνεται η διαφορά μεταξύ του πλυμένου (nice to have) και πραγματικά καθαρού (absolutely required).
• Ποιές από αυτές τις εναλλακτικές είναι λιγότερο επιζήμιες για το stakeholder, ο οποίος έχει δικά του προβλήματα να τον απασχολούν (κόστος, time to market, ανειλημμένες υποχρεώσεις προς τρίτους, κλπ).

και με βάση αυτά να πορευτείς ανάλογα.

 

TL;DR

• It is unbelievably hard and you will fuck up estimations all the time. Ιδιαίτερα καθώς ακριβείς εκτιμήσεις χρειάζονται αηδιαστική λεπτομέρεια, αλλά η συλλογή αηδιαστικής λεπτομέρειας είναι μια δουλειά που "δε χρειάζεται, απλά δώσε μου την καλύτερή σου εκτίμηση". Όποιος project manager το πει αυτό δεν ξέρει τι του γίνεται.
• Όταν γίνει η μαλακία πρέπει να υπάρχει όσο το δυνατόν καλύτερη και πιο ειλικρινής επικοινωνία για να περιοριστεί η ζημιά (όλοι θα πάθουν ζημιά ανεξαιρέτως ο καθένας με άλλο τρόπο, οπότε θεωρητικά όλοι έχουν κίνητρο να την περιορίσουν).
• Αν θες να παίζεις με μικρές ανοχές πρέπει να είσαι έτοιμος για μεγάλες αναμπουμπούλες. Αν θες απόλυτη σιγουριά, πας στην IBM, υπογράφεις 400 σελίδες συμβόλαια, πληρώνεις εφτά ψηφία, και αυτά έχουν μέσα 500% tolerance οπότε μάλλον τα πράγματα θα γίνουν στην ώρα τους. Ο πελάτης πρέπει να το καταλάβει αυτό, εκτός κι αν είσαι ninja engineer και πάντα με κάποιο μαγικό τρόπο είσαι on time. Υπάρχουν τέτοιοι άνθρωποι, αλλά δε θα τους κρατήσεις πολύ γιατί θα πάνε στην IBM να γίνουν project managers.
• Το καλύτερο είναι να καταλάβεις από την αρχή τη φάση του πελάτη και να του μιλήσεις ανάλογα ("προσέχουμε για να έχουμε"). Αν δεις ότι ο άλλος δεν ξέρει τι θέλει αλλά το θέλει με μικρό κόστος και βιάζεται, είτε καταφέρνεις να του επικοινωνήσεις ότι δε γίνεται έτσι, είτε δεν παίρνεις τη δουλειά επειδή το έχεις ξαναδεί το έργο, είτε συμβαίνει το living hell που περιέγραψες.
• Δες λίγο περί agile (μία νοοτροπία προσέγγισης του project management που στοχεύει στο να ελαχιστοποιούνται αυτά τα παρατράγουδα) αλλά προσοχή: 99 στα 100 άτομα λένε agile και δεν καταλαβαίνουν για τι πράγμα μιλάνε. Ενδεικτικά θα πω ότι ενώ το agile είναι νοοτροπία και όχι διαδικασία, και οι εμπνευστές του έγραψαν "δεν υπάρχουν κανόνες και αν εσύ βρεις άλλο τρόπο να προσεγγίσεις το θέμα και σου δουλέψει, τέλεια, κάνε αυτό και εμάς γράψε μας στα τέτοια σου", τις προάλλες άκουσα κάποιον να λέει "όχι αυτό δεν επιτρέπεται στο agile". Η ειρωνία του να μην καταλαβαίνεις πως λέγεται agile ακριβώς επειδή δεν έχει επιτρέπεται και δεν επιτρέπεται...

[PC_MAGAS]

Και τώρα στο ζουμί. Είπα στο Boss ότι θα τελείωνα ένα refactor task αύριο μετά από επέκταση deadline από την Προηγουμενη Παρασκευή.

 

Η ομάδα είναι από 4 άτομα με 2 project ένα το site της εταιρείας και ένα άλλο εξωτερικό.

 

Το task που μου ζητήθηκε να μεταφέρω ένα PHP site από Azute apps/IIS σε GNU/Linux αλλά όλο το url mapping το έφαγε ο IIS με rewrite rules, έτσι είπα θέλει refactor.

 

To boss μου ζήτησε εκτίμηση και είπα 1 μήνα (από όσα έχω δει με μερικά κλικ απο το site), αλλά μου έσκασε και ένα το refactor του api από έναν συνάδελφο που έπρεπε να συνδέσω το νέο site (αυτό που κάνω refactor) με αυτό συν κάποια feature που έχει το παλιό site και δεν είχα ιδέα ότι έπρεπε να υλοποιηθούν.

 

Ακόμη όλο το site ήταν αρκετά κακογραμμένω και δεν ήξερα τι έκανε τι (και ούτε γραμμή documentation).

 

Έτσι θέλω να (ξανα)ρωτήσω.

 

Εαν δεν προλάβω το αυριανό deadline πως να του πω πως ξαναθέλω έξτρα χρόνο. Δε το boss μου είπε στι Προηγούμενο extention εάν δεν προλαύεις μέχρι Παρασκευή να δουλέψεις ΣΚ να το κάνεις Κυριακή το θέλω έτοιμο.

 

Ακόμη όλα τα project έχουν strict deadlines και έπρεπε να δουλέψουμε overtime για να το πετύχουμε ένα εξ' αυτών. Ένα εξ' αυτών είναι επιδοτούμενο από την google.

 

Άρα ποιες επιλογές να κάνω:

1. Να του πω πως τελικά είναι μεγάλη μπουκιά και να εξηγήσω γιατί αργώ (με όποια επιπλοκή-νεύρα);
2. Να το κάνω το Σκ και Δευτέρα να του δώσω ένα Χαρτί που να αναγράφει "Παραίτηση" και να φρεσκάρω το CV;
3. Επιλογή Χ (πείτε μου εσεις);

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

 

Δε είμαι ο άνθρωπος που πιστεύει τα Desighn Patterns και best practices πρέπει να ακολουθούντε ευλαβικά (δλδ θέλω ένα instruction manual ανα χείρας για οτιδήποτε), έτσι πχ. εάν κάνω ένα api και η DB ΔΕΝ φέρει αποτέλεσμα θεωρώ αυτονόητο ότι το API θα πετάξει 404 βάση του json spec.

 

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

 

Δε τι έκανα λάθος ως προς την διαχείρηση του project/task;

 

(Btw είμαι μισθωτός και με πήραν από σύσταση άλλου ατόμου το οποίο με πήρε συνέντευξη.)

[defacer]

Και τώρα στο ζουμί. Είπα στο Boss ότι θα τελείωνα ένα refactor task αύριο μετά από επέκταση deadline από την Προηγουμενη Παρασκευή.

Είμαι ο τελευταίος που τον παίρνει να κατηγορήσει άλλον για υπερβολικό refactoring, αλλά ο καιρός γι' αυτά τα πράγματα πέρασε ακόμα πιο πριν κι απ το πρώτο σου deadline.

 

Όταν πας για δεύτερο overshoot και αντί για παραδοτέο νύφη έχεις στα χέρια σου να παρουσιάσεις γορίλα, δεν τον κάνεις refactor. Του φοράς κραγιόν και νυφικό.

 

 

Το task που μου ζητήθηκε να μεταφέρω ένα PHP site από Azute apps/IIS σε GNU/Linux αλλά όλο το url mapping το έφαγε ο IIS με rewrite rules, έτσι είπα θέλει refactor.

 

To boss μου ζήτησε εκτίμηση και είπα 1 μήνα (από όσα έχω δει με μερικά κλικ απο το site), αλλά μου έσκασε και ένα το refactor του api από έναν συνάδελφο που έπρεπε να συνδέσω το νέο site (αυτό που κάνω refactor) με αυτό συν κάποια feature που έχει το παλιό site και δεν είχα ιδέα ότι έπρεπε να υλοποιηθούν.

 

Ακόμη όλο το site ήταν αρκετά κακογραμμένω και δεν ήξερα τι έκανε τι (και ούτε γραμμή documentation).

Όλα αυτά δεν έχουν σημασία τώρα. Τώρα σημασία έχει το να παραδόσεις κάτι αποδεκτό (εννοείται θα είναι υποδεέστερο από αυτό που και ο πελάτης αλλά και εσύ είχες στο μυαλό σου) όσο πιο γρήγορα γίνεται.

 

Δες το από την πλευρά του πελάτη. Όλα αυτά δεν τον ενδιαφέρουν. Υποτίθεται πως είστε επαγγελματίες και σας πληρώνει ακριβώς για να μην ασχολείται με αυτά. Στα μάτια του το να εστιάζουμε στα challenges μας κάνει ανίκανους losers. Αντίθετα, αν καταφέρουμε να περισώσουμε κάτι από την καταστροφή τότε υπάρχει η περίπτωση να μας θυμάται όχι σαν το συνεργάτη που τα φούνταρε όλα αλλά σαν το συνεργάτη που όταν γαμήθηκε ο Δίας κάπως κατάφερε να κρατήσει το project ζωντανό.

 

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

 

 

 

 

Εαν δεν προλάβω το αυριανό deadline πως να του πω πως ξαναθέλω έξτρα χρόνο. Δε το boss μου είπε στι Προηγούμενο extention εάν δεν προλαύεις μέχρι Παρασκευή να δουλέψεις ΣΚ να το κάνεις Κυριακή το θέλω έτοιμο.

Να του πεις την αλήθεια με τα πιο απλά λόγια που μπορείς: μπος, συγγνώμη που σου το λέω αυτό αλλά δεν προλαβαίνω. Όπως κάποτε άκουσα να λένε και μου άρεσε: the truth is the truth, and all you can do is live with it.

 

Εννοείται πως οι επόμενες ερωτήσεις που θα σου κάνει (αν νιώθει ως αφεντικό) και την οποία θα πρέπει να απαντήσεις παραπάνω από ικανοποιητικά, είναι:

• ΟΚ, δεν προλαβαίνεις. Τι ακριβώς δεν προλαβαίνεις; Τι προλαβαίνεις όντως να κάνεις στο αρχικό deadline που είχες;
• Αν δε μας ικανοποιεί η απάντηση στην προηγούμενη ερώτηση, τι deadline θέλεις για να κάνεις κάτι που μας ικανοποιεί;

Προφανώς έχοντας τινάξει 2 deadlines στον αέρα η θέση σου είναι δύσκολη και δε μπορείς να φέρεσαι "με αέρα" όσο δίκιο κι αν έχεις. Όλοι όσοι είναι εμπλεκόμενοι θα έπρεπε (αλλά μόνο εσύ για τον εαυτό σου μπορείς να ελέγξεις, οι άλλοι ας κάνουν ότι νομίζουν) να ασθάνονται we live together or we die together, οπότε σε καμία περίπτωση δε θέλω να παρουσιάσω τα παραπάνω ως αντικείμενο καυγά ή διαπραγμάτευσης. Το πλοίο βυθίζεται και προσπαθείτε να μείνετε ζωντανοί. Άμα τα καταφέρετε, αργότερα θα υπάρχει καιρός για οτιδήποτε άλλο.

 

 

 

 

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

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

 

Αμα περάσεις επιτυχώς αυτό το στάδιο και φτάσεις να είσαι φίρμα τότε by all means λέγε στους πελάτες πως αν δε μπουν μέσα στο γραφείο σου με σειρά ύψους δε δουλεύεις μαζί τους.

 

Υπόψη μπορεί να αστειεύομαι στο παράδειγμα, αλλά στην ουσία δεν αστειεύομαι καθόλου.

 

 

 

 

Δε είμαι ο άνθρωπος που πιστεύει τα Desighn Patterns και best practices πρέπει να ακολουθούντε ευλαβικά (δλδ θέλω ένα instruction manual ανα χείρας για οτιδήποτε), έτσι πχ. εάν κάνω ένα api και η DB ΔΕΝ φέρει αποτέλεσμα θεωρώ αυτονόητο ότι το API θα πετάξει 404 βάση του json spec.

 

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

 

Δε τι έκανα λάθος ως προς την διαχείρηση του project/task;

 

(Btw είμαι μισθωτός και με πήραν από σύσταση άλλου ατόμου το οποίο με πήρε συνέντευξη.)

 

Κλείνοντας:

• Τίποτα δεν είναι αυτονόητο. Άμα ξέρεις τον άλλο 10 χρόνια τότε κάποια πράγματα μπορείς να τα υποθέσεις, αλλά γενικά όσο λιγότερα υποθέσεις τόσο λιγότερο θα απογοητευτείς στη ζωή.
• Ο συνάδελφος μπορεί να έκανε καλά, μπορεί και όχι, δεν ξέρουμε και σ' αυτή τη φάση δεν έχει και σημασία.
• Δε μπορώ να ξέρω τι έκανες λάθος, αυτό μπορείς να το ξέρεις στην καλύτερη περίπτωση μόνο εσύ και ο μάνατζέρ σου.
• Ειλικρίνεια και επικοινωνία με συναδέλφους και αφεντικό. Μπες στη θέση του πελάτη και προσπάθησε να βρεις μια οποιαδήποτε λύση που να μην είναι Βατερλώ. Δε θα έλεγα να παραιτηθείς ντε και καλά αλλά το βιογραφικό φρεσκάρισέ το γιατί μπορεί να χρειαστεί.

[PC_MAGAS]

Τελικά το ψιλοέσωσα έχω ένα working site με μικά missing parts τα οποίο έγινε deploy. Τα parts είναι κάποιες φόρμες που στέλνουν email, τίποτα το ιδιαίτερο. Δηλαδή οκ παίζεις απλά 2-3 πράγμανα να φτιάξω και είσαι οκ αλλά έχεις κάτι.

[Alithinos]

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

Και όταν είναι απαραίτητο να το κάνεις, να το κάνεις για μικρές εργασίες, και για μικρές χρονικές περιόδους.

 

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

units, features, στα οποία έχουμε εργαστεί ξανά στο παρελθόν.

 

Αν κάτι που ζητείται για ένα νέο project είναι κάτι σε μεγάλο βαθμό ίδιο με κάτι που έχουμε δουλέψει στο παρελθόν, (έστω με κάποιες custom πινελιές) έχουμε το χρόνο που μας πήρε τη προηγούμενη φορά ως μέσο αναφοράς. Ως 'κάτι' δεν αναφέρομαι πχ σε site, σε mobile app, αλλά σε πιο μικρά μεγέθη πχ σχεδιασμός βάσης δεδομένων με στοιχεία επικοινωνίας πελατών, ή το υποσύστημα που μετράει XP σε ένα video game. Πχ για παράδειγμα εγώ (που φτιάχνω κάτι μόνος) κάνω συχνά ενημερώσεις στο git, και για κάθε μια γράφω μια μικρή περιγραφή του τι έκανα. Κοιτόντας το ιστορικό που αποθηκεύει ημερομηνία, ώρα, και τη περιγραφή του κάθε commit, βλέπω πόσο χρόνο μου πήρε η κάθε εργασία, και έτσι έχω ένα point of reference, ώστε σε περίπτωση που χρειαστώ να φτιάξω κάποιο παρόμοιο unit, να μπορώ να κάνω μια εκτίμηση. Για κάτι όμως που δεν έχω ασχοληθεί ξανά ως τώρα... Δεν θα έδινα, και αν θα έδινα θα έβγαινα λάθος.

 

 

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

 

Θα σου δώσω ένα παράδειγμα δικής μου κακής εκτίμησης. Φτιάχνω ένα video game το οποίο διαθέτει έναν 'ανοιχτό κόσμο' που μπορεί να τριγυρνά ο παίκτης. Αντί για levels δηλαδή υπάρχει 1 κόσμος, αλλά γεμάτος με διάφορες δραστηριότητες. Χρειάζεται το παιχνίδι ένα υποσύστημα το οποίο θα αποθηκεύει τη πρόοδο του παίκτη, θα κάνει save και load. Πριν ξεκινήσω να εργάζομαι σε αυτό νόμιζα ότι θα ήταν κάτι σχετικά εύκολο και είχα φτιάξει ένα σωρό άλλες κλάσεις για άλλα υποσυστήματα. "Θα φτιάξω μια serializable κλάση στην οποία θα βάλω references των αντικειμένων που περιέχουν τα data που θέλω, και αυτή η νέα κλάση θα αντιστοιχεί στο save, και έτσι λοιπόν θα ανοίγω IO stream που θα γράφει για το save, και ένα που θα διαβάζει για το load..." σκεφτόμουν. Όταν άρχισα όμως να εργάζομαι στο συγκεκριμένο module, έμαθα ότι μια κλάση του api της game engine που χρησιμοποιώ για σχεδόν τα πάντα,(μιας και με αναγκάζει οι κλάσεις μου να τη κληρονομούν για να μπορούν να αλληλεπιδράν με τα συστήματα της engine) δεν έχει επισημανθεί ως serializable στο api, του οποίου δεν έχω πρόσβαση στο source code. Που σημαίνει ότι ένα σωρό αντικείμενα που έχω ήδη φτιάξει, δε μπορώ απλά να τα περάσω ως reference μεταβλητές σε ένα νέο που θα αποθηκεύσω. Έτσι λοιπόν ξεκίνησα να φτιάχνω custom data structures που η κάθε μια κρατά τα απαραίτητα δεδομένα για κάθε αντίστοιχο αντικείμενο που κληρονομεί τη κλάση του api και δε μπορώ να το αποθηκεύσω, και φυσικά όλο το κώδικα που παίρνει το data από τα αντικείμενα και τα φτιάχνει data structures... Και δεν είναι λίγα τα πράγματα που πρέπει να αποθηκεύονται. Φαντάσου ένα εικονικό κόσμο με βουνά, λίμνες, δάση, πόλεις κτλπ,  και να πρέπει να κρατάς από το που βρίσκεται ο κάθε χαρακτήρας και πόση ζωή έχει, μέχρι το αν ο παίκτης άνοιξε ένα chest που βρήκε χωμένο σε μια σπηλιά και πήρε ότι είχε μέσα ή τα άφησε...

Είμαι ήδη στη 5η ημέρα εργασίας πάνω στα saves, και έχω μέλλον ακόμα μπροστά μου. Όλη αυτή η αστοχία πρόβλεψης λόγο μιας παράβλεψης που έκανα λόγο του ότι δεν υπολόγισα ότι η βασική κλάση του api απ την οποία κληρονομεί η πλειοψηφία των κλάσεών μου, δεν έχει επισημανθεί με το attribute για το serialization.

Επεξ/σία 18 Νοεμβρίου 2017 από Alithinos

[PC_MAGAS]

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

Και όταν είναι απαραίτητο να το κάνεις, να το κάνεις για μικρές εργασίες, και για μικρές χρονικές περιόδους.

Αυτό δεν είναι πάντα option το boss θα θέλει να του πεις χρόνο γιατί και θα σου πει "Πόσο χρόνο θες για το Χ αντικείμενο;" εκεί έχεις τις πρόσεγγίσεις:

 

1. Του λές ένα Χ χρόνο στο περίπου και στα σκούρα το πας από μέρα σε μέρα η βδόμάδα σε βδόμάδα ή δουλεύεις 24/7.
2. Του λες μα το δω λίγο και να σου πω όπου το σπας σε Μικρά κομματάκια λες στο περίπου για το κάθε κομμάτι πόσο θα σου πάρει και μετά αθροίζεις τις εκτιμήσεις και δίνεις αποτέλεσμα.

 

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

units, features, στα οποία έχουμε εργαστεί ξανά στο παρελθόν.

Πολλές φορές όμως ειδικά εάν είσαι νέος και ΔΕΝ έχεις δουλέψει σε κανένα unit ή καλείσε να πεις:

 

"Πόσο χρόνο θες για να αναπτύξεις ένα full responsive website σε meteor με ένα api αξιοποιόντας ES6 ενώ ξέρεις COBOL."

 

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

 

Άρα νομίζω είναι συμαντικό ότι η προσέγγιση του ζητήματος εξαρτάτε και από το περιβάλλον. Πιστεύω πως θα υπάρχουν κάποια pattern τα οποία εξαρτόνται:

1. Από τον τρόπο εργασίας της ομάδας.
2. Από το boss.
3. Από τουε συναδέλφους
4. Τον τρόπο ανάπτυξης λογισμικού (εφαρμόζοντε τα best practices, γνωρίζουν όλοι οι συνάδελφοι ποια είναι αυτά, εφαρμόζοντε σωστά τα pattern;)

Επεξ/σία 21 Νοεμβρίου 2017 από PC_MAGAS

[Aztec]

Στην εκτίμηση που κανείς βάζεις παντα ένα buffer γύρω στο 20-30%.

 

Βασικό κομμάτι είναι πάλι ποτέ ενημερώνεις τον μάνατζέρ ότι δεν βγαίνει . Σίγουρα όχι την τελευταία μέρα . Δουλειά του μάνατζέρ είναι να δινει λύσεις και για αυτό θέλει χρόνο . Τελευταία στιγμή δεν μπορεί να κάνει τίποτα εκτός από το δώσει παράταση . Όμως αν έχει κάποιο χρόνο μπροστά του μπορεί να βάλει ένα additional resource στο έργο η ακόμα και να επικοινωνήσει στον πελάτη μειωμένα expectations ως προς το προϊόν