Πώς επιλέγει software house ένας μη τεχνικός CEO

Ένας CEO δεν χρειάζεται να αξιολογήσει γραμμές κώδικα. Χρειάζεται να αξιολογήσει αν ο προμηθευτής καταλαβαίνει το επιχειρησιακό πρόβλημα, μπορεί να μετατρέψει ασάφεια σε σαφές scope και διαθέτει σύστημα παράδοσης που μειώνει τον κίνδυνο.

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

Ξεκινήστε από το επιχειρηματικό αποτέλεσμα

Πριν ζητήσετε προσφορά, περιγράψτε τι πρέπει να αλλάξει στη λειτουργία. Για παράδειγμα, να μειωθεί ο χρόνος έκδοσης προσφοράς, να μην χάνονται αιτήματα, να συνδεθεί το πελατολόγιο με το ERP ή να δημιουργηθεί νέο ψηφιακό κανάλι εσόδων.

Αποφύγετε να ξεκινήσετε με μια μεγάλη λίστα features. Τα features είναι πιθανές λύσεις. Το αποτέλεσμα είναι ο λόγος που επενδύετε. Ένας καλός συνεργάτης θα σας βοηθήσει να συνδέσετε κάθε κρίσιμη λειτουργία με χρήστη, πρόβλημα και μετρήσιμο στόχο. Αν το ερώτημα αφορά συγκεκριμένα CRM, δείτε πρώτα αν σας ταιριάζει έτοιμο ή custom CRM.

Ελέγξτε πώς γίνεται το discovery

Ρωτήστε τι συμβαίνει πριν ξεκινήσει η ανάπτυξη. Ποιοι συμμετέχουν; Πώς καταγράφονται οι ροές; Πώς επιβεβαιώνονται οι απαιτήσεις; Ποιο είναι το παραδοτέο του discovery;

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

Ζητήστε να γνωρίσετε την πραγματική ομάδα

Η εμπορική παρουσίαση μπορεί να γίνει από senior στελέχη, αλλά το έργο να ανατεθεί αλλού. Ζητήστε να γνωρίσετε τον project owner και τον τεχνικό υπεύθυνο. Ρωτήστε ποιοι θα συμμετέχουν, πόσο διαθέσιμοι είναι και ποιος αποφασίζει όταν εμφανίζεται τεχνικό εμπόδιο.

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

Αξιολογήστε παρόμοια έργα με σωστό τρόπο

Ένα μεγάλο portfolio δεν αποδεικνύει από μόνο του καταλληλότητα. Ζητήστε δύο ή τρία έργα με παρόμοια πολυπλοκότητα, integration ή κανονιστικό περιβάλλον. Ρωτήστε ποιο ήταν το πρόβλημα, τι παραδόθηκε, τι άλλαξε κατά την υλοποίηση και ποιο αποτέλεσμα μετρήθηκε.

Οι εικόνες μιας εφαρμογής αποδεικνύουν design. Δεν αποδεικνύουν σταθερότητα, adoption, απόδοση ή επιχειρησιακό αποτέλεσμα.

Ζητήστε σαφές scope και κριτήρια αποδοχής

Κάθε βασική λειτουργία πρέπει να έχει κριτήριο αποδοχής. Αν το σύστημα «συνδέεται με το ERP», πρέπει να ορίζεται ποια δεδομένα μεταφέρονται, προς ποια κατεύθυνση, πόσο συχνά, τι γίνεται σε σφάλμα και ποιος έχει ευθύνη για το API.

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

Καταλάβετε το μοντέλο κόστους

Στο fixed price ο προμηθευτής αναλαμβάνει μεγαλύτερο κίνδυνο scope και συνήθως προσθέτει περιθώριο ασφαλείας. Στο time and materials ο πελάτης πληρώνει πραγματικό χρόνο αλλά αναλαμβάνει μεγαλύτερη αβεβαιότητα συνολικού κόστους. Στο phased model κάθε στάδιο εγκρίνεται πριν ξεκινήσει το επόμενο.

Δεν υπάρχει μοντέλο που είναι πάντα καλύτερο. Το σωστό εξαρτάται από το πόσο ώριμες είναι οι απαιτήσεις και πόση αλλαγή αναμένεται.

Ελέγξτε ασφάλεια και συνέχεια

Ρωτήστε πού φιλοξενείται το σύστημα, πώς γίνεται backup, πώς διαχειρίζονται οι προσβάσεις, πώς καταγράφονται τα περιστατικά και ποιοι subprocessors χρησιμοποιούνται. Ζητήστε να μάθετε ποιος κατέχει τους κρίσιμους λογαριασμούς και πώς θα συνεχιστεί το έργο αν αλλάξει η συνεργασία.

Η απάντηση «είμαστε GDPR compliant» δεν είναι επαρκής. Χρειάζονται συγκεκριμένα μέτρα, ρόλοι και συμβατικά κείμενα.

Αξιολογήστε τον τρόπο επικοινωνίας

Η συνεργασία σε software project περιλαμβάνει αβεβαιότητα. Αυτό που μετρά είναι πόσο γρήγορα η ομάδα αναδεικνύει πρόβλημα και τι στοιχεία δίνει για να ληφθεί απόφαση. Αναζητήστε σταθερό cadence, γραπτές αποφάσεις, demo λειτουργικού υλικού και ορατό backlog.

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

Δέκα ερωτήσεις πριν από την ανάθεση

1. Ποιο πρόβλημα θεωρείτε ότι λύνουμε και πώς θα μετρήσουμε την επιτυχία;
2. Ποιο είναι το πρώτο παραδοτέο και πότε θα το δούμε να λειτουργεί;
3. Ποιος είναι υπεύθυνος για scope, τεχνικές αποφάσεις και επικοινωνία;
4. Ποιες υποθέσεις περιλαμβάνει η προσφορά;
5. Πώς εγκρίνονται αλλαγές και πώς επηρεάζουν κόστος και χρόνο;
6. Ποια δεδομένα και integrations εξαρτώνται από εμάς ή τρίτους;
7. Ποια είναι τα κριτήρια αποδοχής;
8. Πώς γίνονται ασφάλεια, backups, monitoring και incident response;
9. Τι παραδίδεται αν σταματήσει η συνεργασία;
10. Ποιο είναι το συνολικό κόστος λειτουργίας μετά το launch;

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

Επόμενο βήμα

Αξιολογήστε το έργο, το ρίσκο και το αναμενόμενο αποτέλεσμα πριν δεσμεύσετε budget.

Συχνές ερωτήσεις

Πρέπει να επιλέξω τη χαμηλότερη προσφορά;

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

Χρειάζομαι δικό μου CTO;

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

Τι είναι το σημαντικότερο red flag;

Η αδυναμία του προμηθευτή να περιγράψει καθαρά τι δεν γνωρίζει ακόμη και πώς θα το επιβεβαιώσει.