Τι να βάλετε σε ένα RFP ανάπτυξης λογισμικού (και οι 5 ρήτρες που σας προστατεύουν)

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

Τι περιέχει ένα καλό RFP ανάπτυξης λογισμικού;

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

1. Το πρόβλημα και ο στόχος. Περιγράψτε τι έχει σπάσει ή λείπει και πώς φαίνεται η επιτυχία με απλούς όρους. Ένας καλός πωλητής προτείνει την κατασκευή. περιγράφεις το αποτέλεσμα. Εάν καθορίσετε τη λύση λεπτομερώς, μαθαίνετε μόνο εάν μπορούν να ακολουθήσουν τις οδηγίες.
2. Περιορισμοί και πλαίσιο. Εύρος προϋπολογισμού, χρονοδιάγραμμα, τα συστήματα με τα οποία πρέπει να ενσωματωθεί, τα δεδομένα που θα αγγίξει και τυχόν ρυθμιστικές υποχρεώσεις. Η απόκρυψη του προϋπολογισμού σπαταλά τον χρόνο όλων και παράγει προσφορές που δεν μπορείτε να συγκρίνετε.
3. Πεδίο εφαρμογής, σαφές και στις δύο πλευρές. Καταγράψτε τι είναι μέσα και, εξίσου σημαντικό, τι είναι έξω. Οι περισσότερες διαφωνίες ξεκινούν στο χάσμα μεταξύ αυτού που η μία πλευρά υπέθεσε ότι περιλαμβανόταν και της άλλης όχι.
4. Κριτήρια αξιολόγησης. Δηλώστε πώς θα βαθμολογήσετε τις προτάσεις: σχετική εμπειρία, τεχνική προσέγγιση, ομάδα, τιμή και τους παρακάτω όρους. Οι πωλητές γράφουν σε αυτό που μετράτε.
5. Οι προστατευτικές ρήτρες. Οι πέντε παρακάτω. Η τοποθέτηση τους στο RFP, όχι στο μεταγενέστερο συμβόλαιο, είναι το μοναδικό μεγαλύτερο πράγμα που διαχωρίζει έναν αγοραστή που διατηρεί τον έλεγχο από αυτόν που δεν έχει.

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

Ποιες 5 ρήτρες σας προστατεύουν σε ένα RFP λογισμικού;

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

Ρήτρα	Τι εξασφαλίζει	Τι πάει στραβά χωρίς αυτό
ιδιοκτησία IP	Σας ανήκει ο πηγαίος κώδικας, τα στοιχεία και το δικαίωμα να τα τροποποιήσετε	Ο προμηθευτής κατέχει τον κωδικό και δίνετε άδεια χρήσης του δικού σας συστήματος πίσω από αυτόν
Κριτήρια αποδοχής	Ένα αντικειμενικό τεστ για "έγινε" πριν από την τελική πληρωμή	Ατελείωτη διαφωνία για το αν το έργο πληροί τις προδιαγραφές
Παράδοση και τεκμηρίωση	Κωδικός, διαπιστευτήρια και έγγραφα που επιτρέπουν σε άλλη ομάδα να αναλάβει	Είσαι κλειδωμένος γιατί μόνο αυτοί καταλαβαίνουν πώς τρέχει
Αλλαγή ελέγχου	Μια συμφωνημένη διαδικασία και ποσοστό για αλλαγές στο πεδίο εφαρμογής	Τιμολόγια έκπληξη ή άρνηση προσαρμογής όπως μαθαίνετε
Υποστήριξη και συντήρηση	Καθορισμένοι χρόνοι απόκρισης και κόστος μετά την κυκλοφορία	Ένα ζωντανό σύστημα που δεν είναι υποχρεωμένος να το διορθώσει

Γιατί η ιδιοκτησία IP ανήκει στο RFP και όχι στη σύμβαση;

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

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

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

Πώς η παράδοση, η αλλαγή ελέγχου και η υποστήριξη σας κρατούν τον έλεγχο;

Αυτά τα τρία αποφασίζουν αν έχετε ένα σύστημα ή απλώς νοικιάζετε πρόσβαση στους ανθρώπους που το κατασκεύασαν.

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

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

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

Το πρακτικό takeaway

Αντιμετωπίστε το RFP ως το μέρος που ορίζετε τους όρους, όχι μόνο το μέρος που περιγράφετε το έργο. Οι πέντε ρήτρες (ιδιοκτησία IP, αποδοχή, παράδοση, έλεγχος αλλαγών, υποστήριξη) δεν κοστίζουν σχεδόν τίποτα για να συμφωνήσετε ενώ οι προμηθευτές εξακολουθούν να ανταγωνίζονται και πολλά μπορούν να προστεθούν μόλις επιλεγεί κάποιος. Γράψτε τα από νωρίς, κάντε προτάσεις εναντίον τους και διατηρείτε τον έλεγχο του συστήματος που πληρώνετε για να δημιουργήσετε. Εάν θέλετε ένα δεύτερο ζευγάρι μάτια σε ένα σλιπ πριν σβήσει, πείτε μας τι κατασκευάζετε· είναι το είδος οριοθέτησης με το οποίο ξεκινά ούτως ή άλλως η εργασία μας στο προσαρμοσμένο λογισμικό.