Γιατί λειτουργεί το Kanban — και πώς να καταλάβετε αν η ομάδα σας είναι έτοιμη
Οι περισσότερες ομάδες υιοθετούν το Kanban επειδή κάποιος διάβασε ένα άρθρο. Η πιο έξυπνη ερώτηση είναι αν τα προβλήματα που λύνει το Kanban είναι πράγματι τα προβλήματα της δικής σας ομάδας.
Υπάρχει μια στιγμή που οι περισσότερες ομάδες αναγνωρίζουν, συνήθως όταν ξεπεράσουν τα οκτώ ή εννέα άτομα. Η δουλειά προχωράει — στέλνονται email, παραδίδονται λειτουργίες, εξυπηρετούνται πελάτες — αλλά κανείς δεν έχει σαφή εικόνα για το τι κάνουν οι υπόλοιποι. Τα έργα συσσωρεύονται. Δίνονται υποσχέσεις που ξεχνιούνται αθόρυβα. Ξοδεύετε είκοσι λεπτά πριν από κάθε σύσκεψη για να βρείτε σε ποιο σημείο βρίσκεται πραγματικά μια εργασία. Η απάντηση, συνήθως, είναι «κάπου».
Αυτό είναι το πρόβλημα που σχεδιάστηκε να λύσει το Kanban. Όχι το πρόβλημα του καθορισμού στρατηγικής, της πρόσληψης των κατάλληλων ανθρώπων ή της οικοδόμησης κουλτούρας — αλλά το συγκεκριμένο, καθημερινό, επιχειρησιακό πρόβλημα του να ξέρετε με τι ασχολείται η ομάδα σας και τι την εμποδίζει.
Είναι ένα εκπληκτικά απλό εργαλείο για κάτι που έχει τραβήξει τόσο μεγάλη προσοχή. Το Kanban δεν ισχυρίζεται ότι θα διορθώσει τον οργανισμό σας. Απλώς κάνει τη δουλειά ορατή. Και αποδεικνύεται ότι η ορατότητα, όταν εφαρμόζεται με συνέπεια, αλλάζει εντυπωσιακά πολλά πράγματα στη συνέχεια.
Από πού προέρχεται πραγματικά το Kanban
Η λέξη είναι ιαπωνική — σημαίνει «πινακίδα» ή «διαφημιστικός πίνακας» — και το σύστημα αναπτύχθηκε από την Toyota στα τέλη της δεκαετίας του 1940 για τη διαχείριση των αποθεμάτων στα εργοστάσιά της. Η ιδέα ήταν απλή: αντί να παράγονται εξαρτήματα με σταθερό χρονοδιάγραμμα, το εργοστάσιο τα παρήγαγε μόνο όταν ένας επόμενος σταθμός σήμαινε ότι τα χρειαζόταν. Μια φυσική κάρτα — το kanban — ταξίδευε προς τα πίσω στη γραμμή παραγωγής ως αίτημα. Τίποτα δεν κατασκευαζόταν προληπτικά. Τίποτα δεν συσσωρευόταν άσκοπα.
Η διαπίστωση της Toyota, που αργότερα δανείστηκαν οι ομάδες λογισμικού, είναι ότι η περισσότερη αναποτελεσματικότητα σε ένα σύστημα δεν προέρχεται από ανθρώπους που δουλεύουν πολύ αργά, αλλά από τη λάθος δουλειά που γίνεται σε λάθος χρόνο. Πάρα πολλά πράγματα ξεκινούν ταυτόχρονα. Σημεία συμφόρησης που κανείς δεν προσέχει μέχρι να είναι πολύ αργά. Δουλειά που μένει ολοκληρωμένη σε ένα σημείο ενώ το επόμενο βήμα πνίγεται κάπου αλλού.
Προγραμματιστές λογισμικού, ιδίως σε εταιρείες όπως η Microsoft στις αρχές της δεκαετίας του 2000, άρχισαν να προσαρμόζουν αυτές τις ιδέες στη δουλειά γνώσης. Οι κάρτες έγιναν εργασίες. Οι σταθμοί του εργοστασίου έγιναν στάδια μιας ροής εργασίας. Και η πινακίδα έγινε πίνακας — αρχικά φυσικός, έπειτα ψηφιακός — όπου οποιοδήποτε μέλος της ομάδας μπορούσε να δει με μια ματιά τι βρισκόταν σε εξέλιξη, τι περίμενε και τι είχε ολοκληρωθεί.
Ο πίνακας δεν είναι το σύστημα. Ο πίνακας είναι αυτό που κάνει το σύστημα ορατό. Το σύστημα είναι ο τρόπος με τον οποίο δουλεύει πραγματικά η ομάδα σας — και το κατά πόσον αυτός ο τρόπος σας εξυπηρετεί.
Τι σας δείχνει πραγματικά ένας πίνακας Kanban
Ένας βασικός πίνακας Kanban έχει τρεις στήλες: Προς υλοποίηση, Σε εξέλιξη και Ολοκληρωμένα. Αυτό αρκεί για πολλές μικρές ομάδες και είναι ένα καλό σημείο εκκίνησης. Η πραγματική αξία προκύπτει όταν αρχίσετε να προσαρμόζετε αυτά τα στάδια στον τρόπο με τον οποίο ρέει πράγματι η δουλειά σας — όχι στον τρόπο που θα θέλατε να ρέει.
Μια ομάδα περιεχομένου μπορεί να χρησιμοποιεί: Ιδέα, Brief, Σε συγγραφή, Σε αναθεώρηση, Προγραμματισμένο, Δημοσιευμένο. Μια ομάδα λογισμικού μπορεί να χωρίσει το «Σε εξέλιξη» σε ξεχωριστές στήλες για ανάπτυξη, έλεγχο κώδικα και QA. Μια ομάδα συμβούλων μπορεί να παρακολουθεί τα στάδια Διερεύνηση, Πρόταση, Ενεργό, Αναμονή πελάτη και Κλειστό. Τα στάδια πρέπει να αντικατοπτρίζουν πραγματικές παραδόσεις εργασίας και πραγματικούς χρόνους αναμονής — σημεία όπου η δουλειά αλλάζει χέρια ή όπου περιμένει μέχρι να συμβεί κάτι άλλο.
Προσέξτε την κάρτα στη μεσαία στήλη — την αναφορά ελέγχου αποθήκης, οκτώ ημέρες μετά την έναρξη, σημειωμένη ως μπλοκαρισμένη. Σε ένα σύστημα χωρίς πίνακα, αυτή η εργασία θα μπορούσε να μείνει ακίνητη άλλες δύο εβδομάδες πριν το καταλάβει κανείς. Κάποιος περιμένει έναν τρίτο. Ή χρειάζεται μια απόφαση από έναν διευθυντή που δεν ξέρει ότι εκείνος είναι το εμπόδιο. Ο πίνακας κάνει το μπλοκάρισμα ορατό. Αυτό είναι το μεγαλύτερο μέρος της δουλειάς.
Ο κανόνας που κάνει τη διαφορά: τα όρια WIP
Αν υπάρχει μία έννοια που ξεχωρίζει τις ομάδες που χρησιμοποιούν σωστά το Kanban από εκείνες που απλώς έχουν μια πιο όμορφη λίστα εκκρεμοτήτων, είναι τα όρια ταυτόχρονης εργασίας σε εξέλιξη — εν συντομία όρια WIP. Η ιδέα είναι ότι κάθε στήλη έχει έναν μέγιστο αριθμό στοιχείων που επιτρέπεται να βρίσκονται εκεί ταυτόχρονα. Όταν μια στήλη γεμίσει, δεν μπορείτε να προσθέσετε περισσότερη δουλειά μέχρι να φύγει κάτι από αυτήν.
Αυτό φαίνεται αντιφατικό. Σίγουρα, το να έχετε περισσότερες εργασίες σε εξέλιξη σημαίνει ότι γίνεται περισσότερη δουλειά; Όχι. Όταν οι άνθρωποι δουλεύουν σε πάρα πολλά πράγματα ταυτόχρονα, στην πράξη το καθετί διαρκεί περισσότερο. Η συνεχής εναλλαγή πλαισίου κοστίζει ακριβά. Η μισοτελειωμένη δουλειά δημιουργεί επιπλέον κόστος συντονισμού. Και όταν δέκα πράγματα είναι «σε εξέλιξη», είναι πολύ δύσκολο να καταλάβετε ποια προχωρούν πραγματικά και ποια έχουν απλώς κολλήσει χωρίς να έχει σημειωθεί.
Ένα όριο WIP ίσο με τρία στη στήλη «Σε εξέλιξη» σημαίνει ότι, όταν φτάσει το τέταρτο στοιχείο στο γραφείο κάποιου, κάποιος στην ομάδα πρέπει να πάρει μια απόφαση: ποια από τις υπάρχουσες εργασίες ολοκληρώνεται πρώτη; Επιβάλλει ιεράρχηση. Επιβάλλει συζήτηση. Και τείνει να οδηγεί σε ταχύτερη ολοκλήρωση των επιμέρους στοιχείων, ακόμη κι αν ο ρυθμός έναρξης νέων στοιχείων επιβραδύνεται.
Οι μελέτες για την πολυδιεργασία δείχνουν σταθερά ότι η εναλλαγή μεταξύ εργασιών κοστίζει περίπου 20–40% του παραγωγικού χρόνου. Ένας προγραμματιστής που εναλλάσσεται ανάμεσα σε τρεις λειτουργίες δεν είναι κατά το ένα τρίτο παραγωγικός σε καθεμία — είναι πιθανότατα πιο κοντά στο ένα πέμπτο, αν υπολογίσετε τη νοητική επιβάρυνση της επανόδου στο πλαίσιο. Τα όρια WIP του Kanban αποτελούν, εν μέρει, μια δομική λύση σε αυτό το πρόβλημα.
Kanban ή Scrum: η ερώτηση που κάνουν πάντα οι ομάδες
Αν έχετε περάσει κάποιον χρόνο γύρω από ομάδες λογισμικού ή τη σύγχρονη διαχείριση λειτουργιών, πιθανότατα έχετε συναντήσει το Scrum — το πλαίσιο που οργανώνει τη δουλειά σε σταθερά δίεβδομα sprint, με συνεδρίες σχεδιασμού, retrospectives και καθορισμένους ρόλους όπως ο Scrum Master και ο Product Owner. Πολλές ομάδες αντιμετωπίζουν το Scrum και το Kanban ως ανταγωνιστικές μεθοδολογίες και νιώθουν ότι πρέπει να επιλέξουν. Στην πραγματικότητα η διάκριση είναι απλούστερη.
Το Kanban σας ταιριάζει αν
- Η δουλειά φτάνει απρόβλεπτα ή συνεχώς
- Οι εργασίες έχουν πολύ διαφορετικό μέγεθος
- Η ομάδα σας καλύπτει πολλαπλές λειτουργίες
- Θέλετε να ξεκινήσετε ελαφριά και να εξελίξετε τη διαδικασία
- Η ταχύτητα των επιμέρους στοιχείων έχει τη μεγαλύτερη σημασία
Το Scrum σας ταιριάζει αν
- Η δουλειά μπορεί να σχεδιαστεί σε σταθερές δέσμες
- Η ομάδα σας έχει κυρίως μηχανικό προσανατολισμό
- Ένας προβλέψιμος ρυθμός παράδοσης αποτελεί προτεραιότητα
- Διαθέτετε ειδική δυναμικότητα για τη διευκόλυνση της διαδικασίας
- Τα ενδιαφερόμενα μέρη χρειάζονται τακτική, δομημένη ενημέρωση
Πολλές ομάδες — ιδίως όσες δεν είναι καθαρά ομάδες μηχανικών λογισμικού — βρίσκουν το τελετουργικό του Scrum βαρύ και τη δομή των σταθερών sprint δύσκολη στην εφαρμογή σε διαρκή επιχειρησιακή δουλειά. Οι ομάδες μάρκετινγκ, επιτυχίας πελατών και λειτουργιών, καθώς και οι ιδρυτές που διαχειρίζονται τα πάντα ταυτόχρονα, σπάνια έχουν δουλειά που χωρά τακτοποιημένα σε κύκλους δύο εβδομάδων. Το μοντέλο συνεχούς ροής του Kanban τείνει να τους ταιριάζει καλύτερα.
Ωστόσο, πολλές ομάδες συνδυάζουν και τα δύο. Χρησιμοποιούν κύκλους σχεδιασμού τύπου sprint για την ανάπτυξη προϊόντος, ενώ διατηρούν έναν πίνακα Kanban για την επιχειρησιακή δουλειά και την υποστήριξη που προκύπτουν ανεξάρτητα από το σε ποιο sprint βρίσκεστε. Είναι ένα απόλυτα λογικό υβρίδιο.
Οι τρεις ερωτήσεις στις οποίες πρέπει να απαντά ο πίνακάς σας σε τριάντα δευτερόλεπτα
Ένας πίνακας Kanban είναι ο πιο χρήσιμος όταν μπορείτε να τον κοιτάξετε και, χωρίς να μιλήσετε σε κανέναν, να απαντήσετε γρήγορα σε αυτές τις τρεις ερωτήσεις: Με τι ασχολείται η ομάδα αυτή τη στιγμή; Πού κολλάει η δουλειά; Υπάρχει κάτι που θα έπρεπε να γίνει και δεν έχει ξεκινήσει;
Αν δεν μπορείτε να απαντήσετε και στις τρεις μέσα σε τριάντα δευτερόλεπτα από τη στιγμή που κοιτάξατε τον πίνακα, πιθανότατα δεν συντηρείται σωστά. Ο πιο συνηθισμένος τρόπος αποτυχίας είναι ένας πίνακας όπου οι εργασίες δημιουργούνται αλλά δεν μετακινούνται ποτέ — γίνεται νεκροταφείο καλών προθέσεων αντί για έναν ζωντανό χάρτη της πραγματικής δουλειάς. Ένας πίνακας που δεν είναι ενημερωμένος είναι χειρότερος από κανέναν πίνακα, επειδή δημιουργεί ψευδή αίσθηση ορατότητας.
Η πειθαρχία που απαιτείται για τη συντήρηση ενός πίνακα είναι υπαρκτή. Οι εργασίες πρέπει να μετακινούνται όταν μετακινείται η δουλειά. Τα μπλοκαρισμένα στοιχεία πρέπει να επισημαίνονται τη στιγμή που κολλούν, όχι δύο εβδομάδες αργότερα. Οι κάρτες πρέπει να έχουν σαφείς υπευθύνους και οι υπεύθυνοι πρέπει να ενημερώνουν τις κάρτες τους. Τίποτα από αυτά δεν απαιτεί πολύ χρόνο — μια καλά οργανωμένη πρακτική Kanban μπορεί να παίρνει πέντε με δέκα λεπτά ανά άτομο την ημέρα — απαιτεί όμως συνέπεια. Οι ομάδες που ωφελούνται περισσότερο από το Kanban είναι εκείνες που αντιμετωπίζουν τον πίνακα ως την πηγή αλήθειας και όχι ως μια συμπληρωματική διαδικασία καταγραφής.
Η προβολή πίνακα του FabricLoop είναι χτισμένη ακριβώς γύρω από αυτό: έναν ζωντανό χώρο εργασίας όπου εργασίες, μηνύματα και σημειώσεις βρίσκονται μαζί, ώστε η ενημέρωση μιας κάρτας να μη σημαίνει μετάβαση σε ξεχωριστό εργαλείο. Όταν κάποιος σημειώνει μια εργασία ως μπλοκαρισμένη ή τη μετακινεί στα Ολοκληρωμένα, το πλαίσιο παραμένει συνδεδεμένο — η συζήτηση που εξηγεί γιατί κάτι κόλλησε, το αρχείο που ήταν το τελικό παραδοτέο, η σημείωση που καταγράφει τι αποφασίστηκε. Ο πίνακας μένει ενημερωμένος επειδή η ενημέρωσή του κοστίζει τον ίδιο κόπο με ένα σχόλιο.
Τι δεν κάνει το Kanban
Το Kanban δεν είναι εργαλείο στρατηγικής. Δεν θα σας βοηθήσει να αποφασίσετε με τι να ασχοληθείτε — μόνο να διαχειριστείτε όσα έχετε ήδη αποφασίσει να κάνετε. Αν ο οργανισμός σας έχει πρόβλημα ιεράρχησης, ασαφή εντολή ή το πρόβλημα του «ξεκινάμε πολλά έργα πριν ολοκληρώσουμε τα παλιά», που πηγάζει από τη συμπεριφορά της ηγεσίας και όχι από τη διαδικασία, ένας πίνακας Kanban θα αποκαλύψει αυτά τα προβλήματα αλλά δεν θα τα λύσει.
Δεν υποκαθιστά επίσης την καλή διοίκηση. Ένας πίνακας δεν αντικαθιστά τις ατομικές συναντήσεις, την προσεκτική ανάθεση ή τη σαφή επικοινωνία για το γιατί μετράνε ορισμένες εργασίες. Οι ομάδες μερικές φορές υιοθετούν εργαλεία διαδικασιών ελπίζοντας ότι η διαδικασία θα κάνει τη σχεσιακή και οργανωτική δουλειά που στην πραγματικότητα ανήκει στον διευθυντή. Δεν θα την κάνει.
Αυτό που θα κάνει είναι να μειώσει την υποβόσκουσα αβεβαιότητα που επιβραδύνει τις περισσότερες ομάδες. Τα ερωτήματα «ποιος δουλεύει τι», «έχει τελειώσει αυτό» και «τι να αναλάβω στη συνέχεια» παράγουν τεράστιο όγκο επικοινωνίας χαμηλής αξίας σε οργανισμούς που δεν διαθέτουν ένα κοινό, ορατό σύστημα. Το Kanban εξαλείφει το μεγαλύτερο μέρος αυτού του θορύβου. Και για τις ομάδες όπου αυτός ο θόρυβος είναι το κυρίαρχο πρόβλημα, η διαφορά είναι σημαντική.
Πώς να ξεκινήσετε — χωρίς τριήμερο workshop
Οι καλύτερες εφαρμογές Kanban που έχω δει ξεκίνησαν μικρές και εξελίχθηκαν. Οι χειρότερες περιλάμβαναν έναν σύμβουλο, ένα διήμερο offsite και έναν υπέροχα σχεδιασμένο πίνακα που κανείς δεν χρησιμοποιούσε μέχρι την τρίτη εβδομάδα.
Ξεκινήστε με την ομάδα σας όπως πραγματικά είναι, με τη δουλειά που πραγματικά έχετε. Δημιουργήστε τρεις στήλες: Backlog, Σε εξέλιξη, Ολοκληρωμένα. Αφιερώστε τριάντα λεπτά με την ομάδα σας ώστε να περάσετε κάθε τρέχουσα εργασία σε μια κάρτα. Συμφωνήστε σε έναν κανόνα: όταν ξεκινάτε κάτι, μπαίνει στον πίνακα. Όταν προχωράει, μετακινείτε την κάρτα. Μην κάνετε τίποτα άλλο για δύο εβδομάδες.
Μετά από δύο εβδομάδες, κοιτάξτε τον πίνακα όλοι μαζί. Πού συσσωρεύτηκαν τα πράγματα; Τι έμεινε στο Backlog ενώ όλοι έλεγαν ότι ήταν προτεραιότητα; Τι προχώρησε ταχύτερα από το αναμενόμενο; Τι κόλλησε και γιατί; Χρησιμοποιήστε όσα παρατηρήσατε για να βελτιώσετε τις στήλες και να προσθέσετε περισσότερη ακρίβεια. Ίσως το «Σε εξέλιξη» χρειάζεται να χωριστεί σε «Σε εξέλιξη» και «Αναμονή εξωτερικού παράγοντα». Ίσως χρειάζεστε μια στήλη «Σε αναθεώρηση» επειδή αυτό το βήμα χάνεται συνεχώς. Αφήστε τον πίνακα να εξελιχθεί ανάλογα με όσα αποκαλύπτει η πραγματική σας δουλειά, όχι ανάλογα με το πώς λέει ένα βιβλίο μεθοδολογίας ότι πρέπει να μοιάζει.
Μην προσθέτετε περισσότερες στήλες για να δείχνει ο πίνακας εκλεπτυσμένος. Κάθε στήλη είναι μια παράδοση — και κάθε παράδοση είναι ένα σημείο όπου η δουλειά μπορεί να κολλήσει. Ξεκινήστε απλά. Προσθέστε πολυπλοκότητα μόνο όταν η απλή εκδοχή σας δείξει πού τη χρειάζεστε.
Το μακροπρόθεσμο παιχνίδι: μετρικές ροής
Μόλις ένα σύστημα Kanban λειτουργήσει, παράγει δεδομένα που οι περισσότερες ομάδες δεν αξιοποιούν ποτέ. Ο χρόνος παράδοσης (lead time) — ο συνολικός χρόνος από τη δημιουργία μιας εργασίας μέχρι την ολοκλήρωσή της — είναι ο πιο σημαντικός. Αν ο μέσος χρόνος παράδοσης μιας τυπικής εργασίας είναι δώδεκα ημέρες και θέλετε να γίνει πέντε, έχετε πλέον έναν αριθμό για να δουλέψετε και έναν πίνακα που θα σας δείξει πού πάνε αυτές οι επιπλέον επτά ημέρες.
Ο χρόνος κύκλου (cycle time) μετρά μόνο την περίοδο ενεργής εργασίας, χωρίς τον χρόνο που μια εργασία περιμένει στο backlog. Η απόδοση (throughput) μετρά πόσα στοιχεία ολοκληρώνει η ομάδα σας ανά εβδομάδα. Καμία από αυτές τις μετρικές δεν απαιτεί ειδικό λογισμικό, αν είστε πειθαρχημένοι στην καταγραφή του πότε δημιουργούνται και πότε κλείνουν οι κάρτες. Και μαζί σας δίνουν πολύ πιο ειλικρινή εικόνα της δυναμικότητας της ομάδας σας από οποιαδήποτε διαδικασία σχεδιασμού βασισμένη σε εκτιμήσεις.
Οι περισσότερες μικρές και μεσαίες ομάδες δεν φτάνουν ποτέ ως εδώ. Χρησιμοποιούν το Kanban ως εργαλείο ορατότητας — που από μόνο του έχει αξία — και δεν προχωρούν παραπέρα. Και δεν πειράζει. Αν όμως βρεθείτε να θέλετε να δίνετε δεσμεύσεις στους ενδιαφερόμενους για το πότε θα ολοκληρωθεί κάτι, ή να θέλετε να καταλάβετε γιατί ορισμένες εργασίες διαρκούν τριπλάσιο χρόνο από τον αναμενόμενο, οι μετρικές είναι εκεί όταν τις χρειαστείτε.
Στο FabricLoop, κάθε κάρτα φέρει το ιστορικό της — πότε δημιουργήθηκε, πότε μετακινήθηκε μεταξύ σταδίων, πότε ολοκληρώθηκε. Αυτά τα δεδομένα υπάρχουν είτε τα χρησιμοποιείτε τώρα είτε όχι. Οι ομάδες που ξεκινούν απλά συχνά επιστρέφουν σε αυτά έξι μήνες αργότερα, όταν θέλουν να καταλάβουν γιατί ένα τρίμηνο ήταν τόσο χαοτικό, και ανακαλύπτουν ότι ο πίνακας κατέγραψε ό,τι χρειάζονταν να γνωρίζουν.