Γεια σας φίλοι. Αρκετά συχνά, ειδικά στο outsourcing, βλέπω την ίδια εικόνα. Έλλειψη σαφούς ροής εργασιών σε ομάδες σε διάφορα έργα.
Το πιο σημαντικό είναι ότι οι προγραμματιστές δεν καταλαβαίνουν πώς να επικοινωνούν με τον πελάτη και μεταξύ τους. Πώς να δημιουργήσετε μια συνεχή διαδικασία ανάπτυξης ενός ποιοτικού προϊόντος. Πώς να προγραμματίσετε την εργάσιμη ημέρα και τα σπριντ σας.
Και όλα αυτά τελικά καταλήγουν σε χαμένες προθεσμίες, υπερωρίες, συνεχείς αναμετρήσεις για το ποιος φταίει και δυσαρέσκεια των πελατών για το πού και πώς κινούνται όλα. Πολύ συχνά, όλα αυτά οδηγούν σε αλλαγή προγραμματιστών ή ακόμα και ολόκληρων ομάδων. Απώλεια πελάτη, υποβάθμιση της φήμης και ούτω καθεξής.
Κάποτε, μόλις κατέληξα σε ένα τέτοιο έργο, όπου υπήρχαν όλες αυτές οι απολαύσεις.
Κανείς δεν ήθελε να αναλάβει την ευθύνη για το έργο (μια μεγάλη αγορά υπηρεσιών), ο τζίρος ήταν τρομερός, ο πελάτης ήταν απλά διχασμένος και απογοητευμένος. Ο Διευθύνων Σύμβουλος ήρθε μια φορά σε εμένα και μου είπε ότι έχετε την απαραίτητη εμπειρία, οπότε ορίστε τα χαρτιά στα χέρια σας. Πάρτε το έργο μόνοι σας. Αν τα χαλάσεις, θα κλείσουμε το έργο και θα τους διώξουμε όλους. Θα λειτουργήσει, θα είναι δροσερό, μετά οδηγήστε το και αναπτύξτε το όπως σας ταιριάζει. Ως αποτέλεσμα, έγινα ο επικεφαλής της ομάδας για το έργο και όλα έπεσαν στους ώμους μου.
Το πρώτο πράγμα που έκανα ήταν να αναπτύξω μια ροή εργασιών από την αρχή που ευθυγραμμίζεται με το όραμά μου εκείνη την εποχή και έγραψα μια περιγραφή εργασίας για την ομάδα. Η εφαρμογή του δεν ήταν εύκολη. Αλλά μέσα σε ένα μήνα περίπου όλα λύθηκαν, οι προγραμματιστές και ο πελάτης το συνήθισαν και όλα πήγαν ήσυχα και άνετα. Προκειμένου να δείξω στην ομάδα ότι δεν επρόκειτο απλώς για «καταιγίδα σε ένα φλιτζάνι τσαγιού», αλλά μια πραγματική διέξοδο από την κατάσταση, ανέλαβα το μέγιστο ποσό των ευθυνών, αφαιρώντας τη δυσάρεστη ρουτίνα από την ομάδα.
Έχει ήδη περάσει ενάμιση χρόνο και το έργο εξελίσσεται χωρίς υπερωρίες, χωρίς «ποντικοδρομίες» και κάθε είδους άγχος. Μερικοί άνθρωποι στην παλιά ομάδα δεν ήθελαν να δουλέψουν έτσι και έφυγαν· άλλοι, αντίθετα, ήταν πολύ ευχαριστημένοι που εμφανίστηκαν διαφανείς κανόνες. Αλλά τελικά, όλοι στην ομάδα έχουν πολύ κίνητρο και γνωρίζουν πλήρως το τεράστιο έργο, συμπεριλαμβανομένων τόσο του front-end όσο και του back-end. Συμπεριλαμβανομένης τόσο της βάσης κώδικα όσο και όλης της επιχειρηματικής λογικής. Έχει φτάσει στο σημείο να μην είμαστε απλώς «κωπηλάτες», αλλά εμείς οι ίδιοι έχουμε πολλές επιχειρηματικές διαδικασίες και νέα χαρακτηριστικά που αποδεικνύεται ότι αρέσουν στην επιχείρηση.
Χάρη σε αυτήν την προσέγγιση από την πλευρά μας, ο πελάτης αποφάσισε να παραγγείλει μια άλλη αγορά από την εταιρεία μας, κάτι που είναι καλά νέα.
Δεδομένου ότι αυτό λειτουργεί στο έργο μου, ίσως βοηθήσει επίσης κάποιον. Έτσι, η ίδια η διαδικασία που μας βοήθησε να σώσουμε το έργο:
Η διαδικασία της ομαδικής εργασίας στο έργο "My Favorite Project"
α) Εσωτερική διαδικασία ομάδας (μεταξύ προγραμματιστών)
- Όλα τα ζητήματα δημιουργούνται στο σύστημα Jira
- Κάθε εργασία πρέπει να περιγράφεται όσο το δυνατόν περισσότερο και να εκτελεί αυστηρά μία ενέργεια.
- Οποιοδήποτε χαρακτηριστικό, αν είναι αρκετά περίπλοκο, αναλύεται σε πολλές μικρές εργασίες
- Η ομάδα εργάζεται σε χαρακτηριστικά ως ενιαία εργασία. Πρώτα, εργαζόμαστε όλοι μαζί σε ένα χαρακτηριστικό, το στέλνουμε για δοκιμή και μετά παίρνουμε το επόμενο.
- Κάθε εργασία επισημαίνεται, για το backend ή το frontend
- Υπάρχουν τύποι εργασιών και σφαλμάτων. Πρέπει να τα υποδείξετε σωστά.
- Μετά την ολοκλήρωση μιας εργασίας, μεταφέρεται σε κατάσταση αναθεώρησης κώδικα (σε αυτήν την περίπτωση, δημιουργείται ένα αίτημα έλξης για έναν συνάδελφο)
- Το άτομο που ολοκλήρωσε την εργασία παρακολουθεί αμέσως το χρόνο του για αυτήν την εργασία.
- Αφού ελέγξει τον κωδικό, το PR θα εγκρίνει και μετά από αυτό, αυτός που εκτέλεσε αυτήν την εργασία ανεξάρτητα τον συγχωνεύει στον κύριο κλάδο, μετά τον οποίο αλλάζει την κατάστασή του σε έτοιμο για ανάπτυξη στον διακομιστή προγραμματισμού.
- Όλες οι εργασίες που είναι έτοιμες για ανάπτυξη στον διακομιστή προγραμματισμού αναπτύσσονται από τον επικεφαλής της ομάδας (τον τομέα της ευθύνης του), μερικές φορές από ένα μέλος της ομάδας, εάν κάτι είναι επείγον. Μετά την ανάπτυξη, όλες οι εργασίες από έτοιμες για ανάπτυξη σε προγραμματιστές μεταφέρονται στην κατάσταση - έτοιμες για δοκιμή σε dev
- Όλες οι εργασίες ελέγχονται από τον πελάτη
- Όταν ο πελάτης έχει δοκιμάσει την εργασία στον προγραμματιστή, τη μεταφέρει στην κατάσταση έτοιμη για ανάπτυξη στην παραγωγή
- Για την ανάπτυξη στην παραγωγή, έχουμε έναν ξεχωριστό κλάδο, όπου συγχωνεύουμε τον κύριο μόνο πριν από την ανάπτυξη
- Εάν κατά τη διάρκεια της δοκιμής ο πελάτης βρει σφάλματα, επιστρέφει την εργασία για αναθεώρηση, ορίζοντας την κατάστασή της ως επιστρεφόμενη για αναθεώρηση. Με αυτόν τον τρόπο διαχωρίζουμε τις νέες εργασίες από εκείνες που δεν έχουν περάσει δοκιμές.
- Ως αποτέλεσμα, όλες οι εργασίες περνούν από τη δημιουργία έως την ολοκλήρωση: Εκκρεμότητα → Σε εξέλιξη → Ανασκόπηση κώδικα → Έτοιμη ανάπτυξη σε προγραμματιστή → QA σε προγραμματιστή → (Επιστροφή σε προγραμματισμό) → Έτοιμη ανάπτυξη στην παραγωγή → QA σε παραγωγή → Ολοκληρώθηκε
- Κάθε προγραμματιστής δοκιμάζει τον κώδικά του ανεξάρτητα, ακόμη και ως χρήστης ιστότοπου. Δεν επιτρέπεται η συγχώνευση ενός κλάδου στον κύριο, εκτός εάν είναι γνωστό με βεβαιότητα ότι ο κώδικας λειτουργεί.
- Κάθε εργασία έχει προτεραιότητες. Οι προτεραιότητες τίθενται είτε από τον πελάτη είτε από τον επικεφαλής της ομάδας.
- Οι προγραμματιστές ολοκληρώνουν πρώτα τις εργασίες προτεραιότητας.
- Οι προγραμματιστές μπορούν να αναθέσουν εργασίες ο ένας στον άλλον εάν βρέθηκαν διαφορετικά σφάλματα στο σύστημα ή μια εργασία αποτελείται από την εργασία πολλών ειδικών.
- Όλες οι εργασίες που δημιουργεί ο πελάτης πηγαίνουν στον επικεφαλής της ομάδας, ο οποίος τις αξιολογεί και είτε ζητά από τον πελάτη να τις τροποποιήσει είτε τις αναθέτει σε ένα από τα μέλη της ομάδας.
- Όλες οι εργασίες που είναι έτοιμες για ανάπτυξη σε προγραμματιστές ή παραγωγούς πηγαίνουν επίσης στον επικεφαλής της ομάδας, ο οποίος καθορίζει ανεξάρτητα πότε και πώς να πραγματοποιήσει την ανάπτυξη. Μετά από κάθε ανάπτυξη, ο επικεφαλής της ομάδας (ή μέλος της ομάδας) πρέπει να ειδοποιεί τον πελάτη σχετικά. Και επίσης αλλάξτε τις καταστάσεις για εργασίες σε έτοιμες για δοκιμή για dev/cont.
- Κάθε μέρα την ίδια ώρα (για εμάς είναι στις 12.00) κάνουμε συνάντηση μεταξύ όλων των μελών της ομάδας
- Όλοι στη συνάντηση αναφέρουν, συμπεριλαμβανομένου του αρχηγού της ομάδας, για το τι έκαναν χθες και τι σχεδιάζουν να κάνουν σήμερα. Τι δεν λειτουργεί και γιατί. Με αυτόν τον τρόπο ολόκληρη η ομάδα γνωρίζει ποιος κάνει τι και σε ποιο στάδιο βρίσκεται το έργο. Αυτό μας δίνει την ευκαιρία να προβλέψουμε και να προσαρμόσουμε, εάν χρειάζεται, τις εκτιμήσεις και τις προθεσμίες μας.
- Στη συνάντηση, ο επικεφαλής της ομάδας μιλά επίσης για όλες τις αλλαγές στο έργο και το επίπεδο των τρεχόντων σφαλμάτων που δεν βρέθηκαν από τον πελάτη. Όλα τα σφάλματα επιλύονται και ανατίθενται σε κάθε μέλος της ομάδας για την επίλυσή τους.
- Στη συνάντηση, ο αρχηγός της ομάδας αναθέτει καθήκοντα σε κάθε άτομο, λαμβάνοντας υπόψη τον τρέχοντα φόρτο εργασίας των προγραμματιστών, το επίπεδο επαγγελματικής τους κατάρτισης και επίσης λαμβάνοντας υπόψη την εγγύτητα μιας συγκεκριμένης εργασίας με αυτό που κάνει ο προγραμματιστής αυτήν τη στιγμή.
- Στη συνάντηση, ο αρχηγός της ομάδας αναπτύσσει μια γενική στρατηγική για την αρχιτεκτονική και την επιχειρηματική λογική. Μετά από αυτό ολόκληρη η ομάδα το συζητά και αποφασίζει να κάνει προσαρμογές ή να υιοθετήσει αυτή τη στρατηγική.
- Κάθε προγραμματιστής γράφει κώδικα και δημιουργεί αλγόριθμους ανεξάρτητα στο πλαίσιο μιας ενιαίας αρχιτεκτονικής και επιχειρηματικής λογικής. Ο καθένας μπορεί να εκφράσει το όραμά του για την υλοποίηση, αλλά κανείς δεν αναγκάζει κανέναν να το κάνει με αυτόν τον τρόπο και όχι αλλιώς. Κάθε απόφαση είναι δικαιολογημένη. Εάν υπάρχει καλύτερη λύση, αλλά δεν υπάρχει χρόνος για αυτήν τώρα, τότε δημιουργείται μια εργασία στο λίπος για τη μελλοντική ανακατασκευή ενός συγκεκριμένου μέρους του κώδικα.
- Όταν ένας προγραμματιστής αναλαμβάνει μια εργασία, τη μεταφέρει σε κατάσταση ανάπτυξης. Όλη η επικοινωνία σχετικά με τη διευκρίνιση της εργασίας με τον πελάτη πέφτει στους ώμους του προγραμματιστή. Τεχνικές ερωτήσεις μπορούν να γίνουν στον επικεφαλής της ομάδας ή στους συναδέλφους.
- Εάν ο προγραμματιστής δεν κατανοεί την ουσία της εργασίας και ο πελάτης δεν μπορούσε να το εξηγήσει λογικά, τότε προχωρά στην επόμενη εργασία. Και ο επικεφαλής της ομάδας παίρνει το τρέχον και το συζητά με τον πελάτη.
- Κάθε μέρα, ο προγραμματιστής θα πρέπει να γράφει στη συνομιλία του πελάτη σχετικά με ποιες εργασίες εργάστηκε χθες και ποιες εργασίες θα εργαστεί σήμερα
- Η διαδικασία εργασίας πραγματοποιείται σύμφωνα με το Scrum. Όλα χωρίζονται σε σπριντ. Κάθε σπριντ διαρκεί δύο εβδομάδες.
- Τα σπριντ δημιουργούνται, γεμίζονται και κλείνονται από τον επικεφαλής της ομάδας.
- Εάν το έργο έχει αυστηρές προθεσμίες, τότε προσπαθούμε να εκτιμήσουμε κατά προσέγγιση όλες τις εργασίες. Και τα βάλαμε μαζί σε ένα σπριντ. Εάν ο πελάτης προσπαθήσει να προσθέσει περισσότερες εργασίες στο σπριντ, τότε ορίζουμε προτεραιότητες και μεταφέρουμε κάποιες άλλες εργασίες στο επόμενο σπριντ.
β) Διαδικασία συνεργασίας με τον πελάτη
- Κάθε προγραμματιστής μπορεί και πρέπει να επικοινωνεί με τον πελάτη
- Δεν επιτρέπεται στον πελάτη να επιβάλει τους δικούς του κανόνες παιχνιδιού. Είναι απαραίτητο να καταστήσουμε σαφές στον πελάτη με ευγενικό και φιλικό τρόπο ότι είμαστε ειδικοί στον τομέα μας και μόνο εμείς πρέπει να οικοδομήσουμε διαδικασίες εργασίας και να εμπλέκουμε τον πελάτη σε αυτές
- Είναι απαραίτητο, ιδανικά, πριν ξεκινήσετε την υλοποίηση οποιασδήποτε λειτουργικότητας, να δημιουργήσετε ένα διάγραμμα ροής ολόκληρης της λογικής διαδικασίας για το χαρακτηριστικό (ροή εργασίας). Και στείλτε το στον πελάτη για επιβεβαίωση. Αυτό ισχύει μόνο για περίπλοκες και όχι προφανείς λειτουργίες, για παράδειγμα, σύστημα πληρωμών, σύστημα ειδοποιήσεων κ.λπ. Αυτό θα μας επιτρέψει να κατανοήσουμε με μεγαλύτερη ακρίβεια τι ακριβώς χρειάζεται ο πελάτης, να αποθηκεύσουμε τεκμηρίωση για τη λειτουργία και επίσης να ασφαλιστούμε έναντι του γεγονότος ότι ο πελάτης μπορεί να πει στο μέλλον ότι δεν κάναμε αυτό που ζήτησε.
- Όλα τα διαγράμματα/διαγράμματα ροής/λογικές κ.λπ. Το αποθηκεύουμε στο Confluence/Fat, όπου ζητάμε από τον πελάτη να επιβεβαιώσει την ορθότητα της μελλοντικής υλοποίησης στα σχόλια.
- Προσπαθούμε να μην επιβαρύνουμε τον πελάτη με τεχνικές λεπτομέρειες. Εάν χρειαζόμαστε κατανόηση του πώς το θέλει ο πελάτης, τότε σχεδιάζουμε πρωτόγονους αλγόριθμους με τη μορφή ενός διαγράμματος ροής που ο πελάτης μπορεί να κατανοήσει και να διορθώσει/τροποποιήσει τα πάντα μόνος του.
- Εάν ο πελάτης βρει ένα σφάλμα στο έργο, τότε σας ζητάμε να το περιγράψετε με μεγάλη λεπτομέρεια στο Zhira. Υπό ποιες συνθήκες συνέβη, πότε, ποια σειρά ενεργειών πραγματοποιήθηκαν από τον πελάτη κατά τη διάρκεια της δοκιμής. Επισυνάψτε στιγμιότυπα οθόνης.
- Προσπαθούμε κάθε μέρα, κάθε δεύτερη μέρα το πολύ, να αναπτυχθούμε στον διακομιστή dev. Στη συνέχεια, ο πελάτης αρχίζει να δοκιμάζει τη λειτουργικότητα και το έργο δεν μένει αδρανές. Ταυτόχρονα, αυτό αποτελεί ένδειξη για τον πελάτη ότι το έργο βρίσκεται σε πλήρη ανάπτυξη και κανείς δεν του λέει παραμύθια.
- Συχνά συμβαίνει ο πελάτης να μην κατανοεί πλήρως τι χρειάζεται. Γιατί δημιουργεί μια νέα επιχείρηση για τον εαυτό του, με διαδικασίες που δεν έχουν ακόμη καθιερωθεί. Επομένως, μια πολύ συνηθισμένη κατάσταση είναι όταν πετάμε ολόκληρα κομμάτια κώδικα στον κάδο απορριμμάτων και επανασχεδιάζουμε τη λογική της εφαρμογής. Από αυτό προκύπτει ότι δεν πρέπει να καλύπτετε τα πάντα με δοκιμές. Είναι λογικό να καλύπτουμε μόνο κρίσιμες λειτουργίες με δοκιμές και μετά μόνο με κρατήσεις.
- Υπάρχουν περιπτώσεις που η ομάδα αντιλαμβάνεται ότι δεν τηρούμε προθεσμίες. Στη συνέχεια πραγματοποιούμε έναν γρήγορο έλεγχο των εργασιών και ενημερώνουμε αμέσως τον πελάτη σχετικά. Ως διέξοδος από την κατάσταση, προτείνουμε να ξεκινήσετε έγκαιρα σημαντική και κρίσιμη λειτουργικότητα και να αφήσετε τα υπόλοιπα για μετά την κυκλοφορία.
- Εάν ο πελάτης αρχίσει να επινοεί διαφορετικές εργασίες έξω από το μυαλό του, αρχίσει να φαντασιώνεται και να εξηγεί με τα δάχτυλά του, τότε του ζητάμε να μας παρέχει μια διάταξη σελίδας και ροή με λογική που θα πρέπει να περιγράφει πλήρως τη συμπεριφορά ολόκληρης της διάταξης και στοιχεία του.
- Πριν αναλάβουμε οποιαδήποτε εργασία, πρέπει να βεβαιωθούμε ότι αυτή η δυνατότητα περιλαμβανόταν στους όρους της συμφωνίας/σύμβασής μας. Εάν αυτό είναι ένα νέο χαρακτηριστικό που υπερβαίνει τις αρχικές συμφωνίες μας, τότε πρέπει να τιμήσουμε αυτό το χαρακτηριστικό ((εκτιμώμενος χρόνος ολοκλήρωσης + 30%) x 2) και να υποδείξουμε στον πελάτη ότι θα μας πάρει τόσος χρόνος για να το ολοκληρώσουμε, συν Η προθεσμία μετατοπίζεται με τον χρόνο εκτίμησης πολλαπλασιασμένο επί δύο. Ας κάνουμε το έργο πιο γρήγορα - υπέροχο, όλοι θα ωφεληθούν από αυτό. Αν όχι, τότε σας έχουμε καλύψει.
γ) Τι δεν δεχόμαστε σε μια ομάδα:
- Αδέσμευση, έλλειψη ψυχραιμίας, λήθη
- “Ταΐζοντας πρωινό.” Εάν δεν μπορείτε να ολοκληρώσετε μια εργασία και δεν ξέρετε πώς, τότε πρέπει να ειδοποιήσετε αμέσως τον επικεφαλής της ομάδας και να μην περιμένετε μέχρι την τελευταία στιγμή.
- Φρύδια και καυχιέται από ένα άτομο που δεν έχει ακόμη αποδείξει τις ικανότητες και τον επαγγελματισμό του. Αν αποδειχτεί, τότε είναι δυνατό, εντός των ορίων της ευπρέπειας :)
- Η εξαπάτηση σε όλες τις μορφές της. Εάν μια εργασία δεν έχει ολοκληρωθεί, τότε δεν πρέπει να αλλάξετε την κατάστασή της σε ολοκληρωμένη και να γράψετε στη συνομιλία πελάτη ότι είναι έτοιμη. Ο υπολογιστής χάλασε, το σύστημα κατέρρευσε, ο σκύλος μάσησε το φορητό υπολογιστή - όλα αυτά είναι απαράδεκτα. Εάν συμβεί ένα πραγματικό γεγονός ανωτέρας βίας, ο επικεφαλής της ομάδας πρέπει να ειδοποιηθεί αμέσως.
- Όταν ένας ειδικός είναι συνεχώς εκτός σύνδεσης και είναι δύσκολο να τον προσεγγίσεις κατά τις ώρες εργασίας.
- Δεν επιτρέπεται η τοξικότητα στην ομάδα! Αν κάποιος διαφωνεί με κάτι, τότε μαζεύονται όλοι μαζί σε ένα συλλαλητήριο και το συζητούν και το αποφασίζουν.
Και μια σειρά από ερωτήσεις/διατριβές που μερικές φορές ζητώ από τον πελάτη μου για να ξεκαθαρίσει όλες τις παρεξηγήσεις:
- Ποια είναι τα ποιοτικά σας κριτήρια;
- Πώς προσδιορίζετε εάν ένα έργο έχει προβλήματα ή όχι;
- Παραβιάζοντας όλες τις συστάσεις και τις συμβουλές μας σχετικά με την αλλαγή/βελτίωση του συστήματος, όλοι οι κίνδυνοι βαρύνουν μόνο εσάς
- Οποιεσδήποτε σημαντικές αλλαγές στο έργο (για παράδειγμα, κάθε είδους επιπλέον ροή) θα οδηγήσουν σε πιθανή εμφάνιση σφαλμάτων (τα οποία, φυσικά, θα διορθώσουμε)
- Είναι αδύνατο να καταλάβουμε μέσα σε λίγα λεπτά τι είδους πρόβλημα προέκυψε στο έργο, πόσο μάλλον να το διορθώσετε αμέσως
- Εργαζόμαστε σε μια συγκεκριμένη ροή προϊόντων (Εργασίες στο Zhira - Ανάπτυξη - Δοκιμές - Ανάπτυξη). Αυτό σημαίνει ότι δεν μπορούμε να απαντήσουμε σε ολόκληρη τη ροή αιτημάτων και παραπόνων στη συνομιλία.
- Οι προγραμματιστές είναι προγραμματιστές, όχι επαγγελματίες δοκιμαστές και δεν μπορούν να διασφαλίσουν τη σωστή ποιότητα των δοκιμών του έργου
- Η ευθύνη για τις τελικές δοκιμές και την αποδοχή των εργασιών παραγωγής ανήκει αποκλειστικά σε εσάς
- Εάν έχουμε ήδη αναλάβει μια εργασία, δεν μπορούμε να μεταβούμε αμέσως σε άλλες μέχρι να ολοκληρώσουμε την τρέχουσα (διαφορετικά αυτό οδηγεί σε ακόμη περισσότερα σφάλματα και αυξημένο χρόνο ανάπτυξης)
- Υπάρχουν λιγότερα άτομα στην ομάδα (λόγω διακοπών ή ασθενειών), αλλά υπάρχει περισσότερη δουλειά και φυσικά δεν θα έχουμε χρόνο να ανταποκριθούμε σε όλα όσα θέλετε
- Σας ζητάμε να κάνετε μια ανάπτυξη στην παραγωγή χωρίς δοκιμασμένες εργασίες στον προγραμματιστή - αυτός είναι μόνο ο κίνδυνος σας, όχι οι προγραμματιστές
- Όταν ορίζετε ασαφείς εργασίες, χωρίς σωστή ροή, χωρίς διατάξεις σχεδίασης, αυτό απαιτεί πολύ περισσότερη προσπάθεια και χρόνο υλοποίησης από εμάς, καθώς πρέπει να κάνουμε επιπλέον δουλειά αντί για εσάς
- Τυχόν εργασίες σχετικά με σφάλματα, χωρίς λεπτομερή περιγραφή της εμφάνισής τους και στιγμιότυπα οθόνης, δεν μας δίνουν την ευκαιρία να καταλάβουμε τι πήγε στραβά και πώς μπορούμε να διορθώσουμε αυτό το σφάλμα
- Το έργο απαιτεί συνεχή βελτίωση και βελτιώσεις για τη βελτίωση της απόδοσης και της ασφάλειας. Επομένως, η ομάδα αφιερώνει μέρος του χρόνου της σε αυτές τις βελτιώσεις
- Λόγω του ότι έχουμε υπερωρίες την ώρα (επείγουσες διορθώσεις), πρέπει να τις αποζημιώσουμε τις υπόλοιπες μέρες
Κατά κανόνα, ο πελάτης καταλαβαίνει αμέσως ότι όλα δεν είναι τόσο απλά στην ανάπτυξη λογισμικού και ότι η επιθυμία από μόνη της δεν αρκεί σαφώς.
Γενικά, αυτό είναι όλο. Αφήνω πίσω από τις σκηνές πολλές διαπραγματεύσεις και την αρχική αποσφαλμάτωση όλων των διαδικασιών, αλλά ως αποτέλεσμα, όλα λειτούργησαν. Μπορώ να πω ότι αυτή η διαδικασία έγινε για εμάς ένα είδος «Silver Bullet». Τα νέα άτομα που ήρθαν στο έργο θα μπορούσαν να εμπλακούν αμέσως στη δουλειά από την πρώτη μέρα, καθώς περιγράφηκαν όλες οι διαδικασίες και η τεκμηρίωση και η αρχιτεκτονική με τη μορφή διαγραμμάτων έδωσαν αμέσως μια ιδέα για το τι κάναμε όλοι εδώ.
ΥΓ Θα ήθελα να διευκρινίσω ότι δεν υπάρχει project manager από την πλευρά μας. Είναι από την πλευρά του πελάτη. Καθόλου τεχνικός. Ευρωπαϊκό έργο. Όλη η επικοινωνία γίνεται μόνο στα Αγγλικά.
Καλή επιτυχία σε όλους στα έργα σας. Μην καείτε και προσπαθήστε να βελτιώσετε τις διαδικασίες σας.
Πηγή στο δικό μου .
Πηγή: www.habr.com