Home

log

2010/02/17

Ήθελα να σχολιάσω το άρθρο αυτό καιρό τώρα:

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

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

Το πραγματικό πρόβλημα είναι όμως πως οι information workers δεν έχουν μάθει να δουλεύουν έτσι:

  • Θα γράψουμε documentation αργότερα
  • Θα γράψουμε τα σχόλια στον κώδικα αργότερα
  • Ο κώδικάς μου είναι self-documented, δε χρειάζεται σχόλια

Αργότερα. Όλα αργότερα. Όταν θα έχουμε χρόνο. Μόνο που χρόνο δεν έχουμε ποτέ, γιατί το επόμενο project χτυπάει την πόρτα (ή τη χτυπάμε εμείς φεύγοντας).

Advertisements

15 Responses to “log”

  1. Aristotelis Says:

    Από πολλούς νέους φοιτητές του τμήματος πληροφορικής δεν ξέρω πιο είναι πιο ανησυχητικό:

    Το να πιστεύουνε ότι μπορούνε να βάλουνε τα σχόλια αρχότερα στον κώδικα και να το κάνουνε και να είναι και καλής ποιότητας, ή ότι πολλοί πιστεύουνε ότι είναι self-documented ο κώδικας τους.

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

    Για τα άλλα συμφωνώ απόλυτα. Το μόνο που με σώζει lately είναι πως επειδή η μνήμη μου βαράει συχνά GPF και δεν την εμπιστεύομαι πολύ, κάθομαι και κάνω document ότι μπορώ με το που τελειώνει και το έχω ακόμη φρέσκο.


  2. Επιπλέον.. Η μνήμη μιας εταιρίας με πελάτες, προϊόντα, requests κλπ φαίνεται στο TICKETING σύστημά της. Οσοι άνθρωποι κι αν αλλάξουν, η πληροφορία μένει πάντα στο TICKET.

    Η ανταλλαγή emails θα πρέπει να απαγορευτεί δια ροπάλου, γιατί παραμένουν μόνο στο mailbox του παραλήπτη.

  3. thanasisk Says:

    2 words:
    Job Security :-)

  4. Nikos Says:

    Ένα wiki και μια mailing list είναι απαραίτητα σε κάθε οργανισμό.

    Όπως και ενα svn ή και mercurial repository. Και αν αναπτύσει πολυ κώδικα εσωτερικά ένα trac.

    Εσείς; Τι άλλο χρησιμοποιείτε;

    • adamo Says:

      Νίκο η βεβαιότητές σου με αναγκάζουν να σε ρωτήσω:

      “Ένα wiki και μια mailing list είναι απαραίτητα σε κάθε οργανισμό.”

      Γιατί; Γιατί wiki και για ποιους υπαλλήλους; Γιατί mailing list και για ποια χρήση;

      Hint: 90-9-1 Theory.

      “Όπως και ενα svn ή και mercurial repository. Και αν αναπτύσει πολυ κώδικα εσωτερικά ένα trac.”

      Γιατί; Γιατί svn / mercurial; Γιατί trac;

      Hint: Οτιδήποτε θεωρείς δεδομένο μπορεί και να μην ισχύει.

      “Εσείς; Τι άλλο χρησιμοποιείτε;”

      Εμείς είμαστε 6 άτομα. Η διάχυση γνώσης για ότι χρειάζεται κανείς να μάθει είναι αναγκαστική.

    • keramida Says:

      Νίκο, το να στήσεις ένα wiki είναι το εύκολο. Το να πείσεις τον κόσμο να γράφει τα πάντα σε αυτό είναι το δύσκολο μέρος. Το “πρόβλημα” με το logging που περιγράφει ο adamo δεν είναι τόσο τεχνικό όσο mindset & πολιτικής.

      Για παράδειγμα δεν υπάρχει κανένας τεχνικός λόγος για να μη γράψεις σωστά σχόλια στον κώδικα. Δεν υπάρχει κανένας τεχνικός περιορισμός ο οποίος να εμποδίζει ένα προγραμματιστή να γράψει test cases για κάποιο bug που μόλις έφτιαξε. Δεν υπάρχει κανένας πραγματικά λόγος που κάνει αδύνατη τη χρήση ενός ticketing συστήματος με πολιτική “κάθε commit στο trunk μας πρέπει να έχει αντίστοιχο bug id στο bug tracker, period”.

      Η ψυχολογική διάσταση του “έλα μωρέ, θα το γράψω καλύτερα μετά” είναι κυρίως μη τεχνικής φύσης :-)

      • keramida Says:

        Μόνο στο Solaris έχω δει BTW να εφαρμόζεται το “κάθε commit πρέπει να έχει bug id”. Θα ήμουνα ιδιαίτερα ευτυχισμένος αν μπορούσα να το δω έστω και σε ένα από τα team projects που έχω συμμετάσχει ως τώρα.

        • johnnieinlab Says:

          Η δική μου εμπειρία είναι πως αυτοί που έχουν την εξουσία/αρμοδιότητα να ορίσουν και να απαιτήσουν να ακολουθούνται τέτοιοι κανόνες, σε ένα project, πολλές φορές δεν έχουν χρόνο και διάθεση να ασχοληθούν με το “πρήξιμο” του dev team, είτε δεν συνειδητοποιούν τη σπουδαιότητα του να υπάρχει σαφής και 99% απαράβατη πολιτική, είτε θεωρούν πως ο χρόνος για την εκπαίδευση της ομάδας είναι μια πολυτέλεια που οι σημερινές προτεραιότητες (το θελω χθες) δεν την επιτρέπουν.

          Δυστυχώς υπάρχουν πάντα αυτοί (και συχνά συμπεριλαμβάνει κι εμένα) που νοιώθουν πως οι πολλές διαδικασίες υπάρχουν μόνο για να τους περιορίζουν την ελευθερία!


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

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

            Γενικά, η αίσθηση που αφήνουν οι διαδικασίες του τύπου “για να κάνεις commit πρέπει να υπάρχει bug id και να έχει αποδεχτεί τουλάχιστον άλλος ένας την αλλαγή” είναι ακριβώς αυτή που λες. Ότι καθυστερεί το development σε απίστευτο βαθμό κι ότι η γραφειοκρατική προσέγγιση του ελέγχου σε κάθε μικρή αλλαγή είναι χειρότερη από βαριεστημένο υπάλληλο στο Ελληνικό Δημόσιο.

            Η άλλη πλευρά του νομίσματος, όμως, είναι ότι σε ένα περιβάλλον το οποίο δεν έχει τέτοιες οργανωτικές δομές, είναι πολύ συχνό το φαινόμενο να μην ξέρει κανείς τι γίνεται με ένα κομμάτι του κώδικα, επειδή (α) αυτός που τό ‘γραψε έχει φύγει, (β) αυτός που τό ‘γραψε δε θυμάται γιατί το έγραψε, (γ) κανείς δε θυμάται πότε είχε γίνει η τελευταία “gold” έκδοση που δουλεύει 100% σωστά, (δ) κανείς δεν ξέρει πότε άρχισε να εμφανίζεται το πρόβλημα που καθυστερεί το release αυτής της εβδομάδας, κλπ.

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

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

            (1) τεκμηρίωση του τι έκανες σήμερα
            (2) ανάλυση της επιτυχίας και αποδοτικότητας αυτών που έκανες ως τώρα
            (3) post-mortem ανάλυση από κάτι που δεν έπαιξε σωστά
            (4) καταγραφή των πάντων στο εσωτερικό wiki για αργότερα

            Η εντύπωση που μου δίνει αυτός ο τρόπος δουλειάς είναι πως όντως κάποια πράγματα μπορεί να πάρουν περισσότερο καιρό να αλλάξουν (π.χ. ένα wiki tutorial changeset που πρότεινα πριν από μια βδομάδα ακόμη περιμένει στο review queue να το δει κάποιος υπεύθυνος). Δεν πειράζει πολύ όμως που ορισμένα πράγματα προχωράνε πιο αργά επειδή έτσι έχω ηρεμήσει πάρα πολύ ξέροντας ότι ισχύει κάτι το οποίο με κάνει να κοιμάμαι ήσυχα τα βράδια:

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

            Χαίρομαι πάρα πολύ που επιτέλους μπορώ να το πω αυτό για τη δουλειά που κάνω κάθε μέρα ;-)

  5. apostolos Says:

    μιλάς για hand-writing ημερολόγιο?

    • adamo Says:

      Περίπου. Ότι αφορά μόνο εμένα, μένει σε χαρτί (δες και το “On Paper“). Όταν λέω ημερολόγιο μην πάει το μυαλό σου στο “Αγαπητό μου ημερολόγιο σήμερα…”. Πιο πολύ σε αυτό το είδος σημειώσεων που κρατάει κάποιος όταν κάνει εργαστήρια / πειράματα ώστε να αλλάζει μόνο μία παράμετρο τη φορά, να ξέρει πότε έγινε αυτό και πως επηρεάστηκε το πείραμα.

      Στη δουλειά έχουμε εσωτερικό wiki.


  6. Η καταγραφή είναι μέρος της “οργάνωσης”:

    Για κάποιον υπάλληλο, που ήταν πολύ καιρό στην ίδια υπηρεσία, ο κύριος Κ. άκουσε να διατυπώνουν τον εξής έπαινο: ο υπάλληλος ήταν τόσο καλός, που ήταν αναντικατάστατος. “Τι θα πει αναντικατάστατος;” ρώτησε εκνευρισμένος ο κύριος Κ. “Θα πει ότι η υπηρεσία δε λειτουργεί χωρίς αυτόν” είπαν οι υμνητές του. “Μα πώς μπορεί να ‘ναι καλός υπάλληλος, αν η υπηρεσία δε λειτουργεί χωρίς αυτόν;” είπε ο κύριος Κ. “Έχει χρόνια σ’ αυτή την υπηρεσία, και θα μπορούσε να την οργανώσει τόσο καλά, ώστε να μην είναι πια αναντικατάστατος. Και τι έκανε τόσον καιρό; Να σας πω εγώ: εκβιασμό έκανε!”

    ΜΠΕΡΤΟΛΤ ΜΠΡΕΧΤ “ΙΣΤΟΡΙΕΣ ΤΟΥ κ. ΚΟΫΝΕΡ”

    • adamo Says:

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

      1- Αυτό που περιγράφεις
      2- Downsizing, με αποτέλεσμα να μείνει αυτός
      3- Επανάπαυση του οργανισμού, αλλά “what if Linus Torvalds gets hit by a bus?
      4- Υπερσυγκεντρωτισμός και έλλειψη εμπιστοσύνης
      5- Hot potato task που κανείς δεν αναλαμβάνει
      6- Άλλα τυχαία γενότα

      Δεν είναι θέμα καλού ή κακού υπαλλήλου, αλλά διοίκησης.

  7. Antonis Says:

    Στο “πολιτισμένο κόσμο” η λύση στο πρόβλημα που περιγράφεται στο αρχικό post λέγεται laboratory notebook. Χρησιμοποιείται κυρίως σε περιβάλλοντα R&D, αλλά μπορεί να χρησιμοποιηθεί και σε οποιοδήποτε άλλο τμήμα της επιχείρησης. Εκτός από αυτά βέβαια υπάρχουν και τα “κλασσικά” πλέον CRM, ERP, κοκ, όπου θεωρητικά όλες οι δραστηριότητες των μελών μια εταιρίας/φορέα μπορούν να καταγραφούν και να είναι άμεσα διαθέσιμες σε όλους. Φυσικά όμως ότι σύστημα και να χρησιμοποιήσεις, όταν δεν εισάγεις τίποτα δεν μπορείς να εξάγεις και τίποτα χρήσιμο… Άρα επανερχόμαστε στο γνωστό πρόβλημα: “Έλα μωρέ θα το κάνει κάποιος άλλος, που να ασχολούμαι τώρα” ή “Έπρεπε να το είχες κάνει ήδη, τώρα δεν προλαβαίνεις, κάνε αυτό μέχρι χθες”, κοκ…

  8. Πέτρος Says:

    Το θέμα (ή τέλος πάντων μια διάστασή του) το έχει πιάσει κατά καιρούς κι ο Dilbert:

    http://dilbert.com/strips/comic/2010-02-27/
    http://dilbert.com/strips/comic/2010-03-01/


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: