Αποφύγετε την ομηρία από τους Προγραμματιστές σας

όμηρος100107Αυτό το Σαββατοκύριακο ξεκίνησα μια συνομιλία με έναν τοπικό καλλιτέχνη που βοηθούσε το αφεντικό της με τη διαχείριση δύο εφαρμογών ιστού που έχει το αφεντικό της.

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

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

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

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

Μερικές συμβουλές εάν πρόκειται να αποκτήσετε μια ομάδα ανάπτυξης εξωτερικού συνεργάτη:

  1. Εγγραφή τομέα

    Καταχωρίστε τα ονόματά σας στο όνομα της εταιρείας σας. Δεν είναι κακό να έχετε τον προγραμματιστή σας ως τεχνική επαφή στον λογαριασμό, αλλά ποτέ μεταβίβαση κυριότητας του τομέα σε οποιονδήποτε εκτός της εταιρείας σας.

  2. Φιλοξενία της εφαρμογής ή του ιστότοπού σας

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

  3. Είστε ο Κώδικας

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

  4. Λάβετε μια δεύτερη γνώμη!

    Δεν βλάπτει τα συναισθήματά μου όταν οι άνθρωποι μου λένε ότι κάνουν προσφορές ή συμβουλεύονται με άλλους επαγγελματίες. Στην πραγματικότητα, το προτείνω!

Η ουσία είναι ότι πληρώνετε για το ταλέντο του προγραμματιστή σας, αλλά πρέπει να διατηρήσετε τον έλεγχο και την ιδιοκτησία της ιδέας. Είναι δικό σας. Εσείς εσείς που επενδύσατε σε αυτήν, εσείς που διακινδυνεύσατε την επιχείρησή σας και την κερδοφορία γι 'αυτήν… και εσείς πρέπει να τη διατηρήσετε. Οι προγραμματιστές μπορούν να αντικατασταθούν και αυτό δεν πρέπει ποτέ να θέσει σε κίνδυνο την αίτησή σας, ή χειρότερα - την επιχείρησή σας.

6 Σχόλια

  1. 1

    Είμαι προγραμματιστής εφαρμογών ιστού και συμφωνώ με τα περισσότερα σημεία σας (ίσως όλα), αλλά θα ήθελα μια διευκρίνιση στο # 3.

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

    Παράδειγμα:
    Ο επιθυμητός από τον πελάτη έλεγχος επιπέδου σελίδας και επιπέδου πεδίου συνδέεται με ρόλους χρήστη. Η λειτουργικότητα "εκτός του πλαισίου" για το ASP.Net κάνει δικαιώματα επιπέδου φακέλου. Έτσι επέκτεινα τα εγγενή δικαιώματα για το .Net και παρέδωσα τη λύση ως μέρος μιας συνολικής εφαρμογής ιστού.

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

    Μια άλλη ρυτίδα:
    Το έκανα αυτό ενώ καλλιεργήθηκα από μια εταιρεία συμβούλων. Θα μπορούσε η συμβουλευτική εταιρεία να έχει το δικαίωμα κατά τη γνώμη σας να επιστρέψει και να αντιγράψει αυτήν τη λύση, την εμπορία ως δική τους;

    • 2

      Πραγματικά,

      Νομίζω ότι συμφωνούμε. Το θέμα μου σε αυτό είναι να βεβαιωθώ ότι έχετε τον κωδικό και ότι μπορείτε να βγείτε από την πόρτα μαζί του. Εάν ο προγραμματιστής σας συντάσσει κώδικα για εσάς και τον προωθεί στον ιστότοπό σας - δεν έχετε τον κωδικό. Έχω δει αυτό να συμβαίνει με τα πάντα, από γραφικά, Flash, .NET, Java… οτιδήποτε απαιτεί αρχείο προέλευσης και εξάγεται.

      Doug

  2. 3

    Βλέπω από πού προέρχεστε και ενώ δεν συμφωνώ με τα πάντα 100% (έχω επιφυλάξεις), οι εταιρείες θα πρέπει να το θυμούνται πάντα.

    1. ΑΠΟΛΥΤΩΣ. Δεν μπορώ να το τονίσω αρκετά. Έχω εργαστεί για μια μικρή εταιρεία που το έκανε αυτό και ένιωσα να συντρίβω την ενοχή για την ανάμιξή μου. Χαίρομαι πολύ που κατάφερα να φύγω από εκεί. Οι πελάτες πρέπει να διατηρούν απολύτως τον έλεγχο των τομέων τους. Εάν έχει κάποιον αρκετά καταλαβαίνω, μην παραχωρήσετε στον προγραμματιστή πρόσβαση σε αυτό. Εάν όχι, βεβαιωθείτε ότι ο προγραμματιστής έχει έναν τρόπο να αλλάξετε τις πληροφορίες / να μεταφέρετε τον τομέα μέσω διεπαφής μεταπωλητή κάποιου είδους τουλάχιστον.

    2. Θα συμφωνούσα εν μέρει με αυτό, αλλά στη συνέχεια εξαρτάται από την κατάσταση. Εάν αναπτύσσετε μια απλή εφαρμογή PHP και χρειάζεστε φιλοξενία χαμηλού κόστους, με κάθε τρόπο, αποκτήστε έναν λογαριασμό LunarPages ή DreamHost ή κάτι τέτοιο και απορρίψτε τον εκεί. Δώστε στον προγραμματιστή πρόσβαση. Ωστόσο, η χαμηλού κόστους κοινή φιλοξενία έχει σίγουρα τα μειονεκτήματά της… ειδικά για μεγαλύτερα πράγματα. Αλλά αν είστε αρκετά μεγάλοι για να ανησυχείτε ότι θα πρέπει να έχετε κάποιον τεχνικό στο προσωπικό που μπορεί να το αντιμετωπίσει. Πολλά από αυτά είναι προφανώς για την εμπιστοσύνη. Σίγουρα ως κόλαση βάλτε κάτι σε ένα συμβόλαιο αν μπορείτε για αυτό το είδος (περιορισμοί και άλλα) Η φιλοξενία τρίτων είναι εξαιρετική εάν ο προγραμματιστής δεν χρειάζεται να κάνει κάτι φανταχτερό. Παραδέχομαι ότι είμαι σχισμένος γιατί είναι πραγματικά ένα περιστατικό. Εξαρτάται επίσης από το μέγεθος του ιστότοπου, τη σειρά των τεχνολογιών που χρησιμοποιούνται. Εάν θα είναι μεγάλο, σκέφτεστε να προσλάβετε ένα άτομο στο προσωπικό. Όχι πάντα μια επιλογή, αλλά ασφαλέστερη για μεγάλα πράγματα.

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

    4. Πάντα. Πάντα. Πάντα.

  3. 4

    Ωραία ανάρτηση… καλά, αν και διαφωνώ με ένα στοιχείο (# 2):

    "Είναι υπέροχο που ο προγραμματιστής σας μπορεί να έχει μια εταιρεία φιλοξενίας και να μπορεί να φιλοξενήσει τον ιστότοπό σας για εσάς, αλλά μην το κάνετε."

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

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

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

    Και πάλι, καλή ανάρτηση και πολύ χρήσιμες πληροφορίες.

    Ευχαριστώ!
    Michael Reynolds

    • 5

      Γεια σου Μιχάλη,

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

      Τα πράγματα συμβαίνουν στις επιχειρήσεις που σπάνε τις σχέσεις και δεν χρειάζεται να είναι αρνητικά. Ίσως ο προγραμματιστής / εταιρεία σας έχει έναν πολύ μεγάλο πελάτη και δεν μπορεί να σας αντέξει το χρόνο. Ίσως αλλάζουν επιχειρηματικούς στόχους. Μερικές φορές η εταιρεία φιλοξενίας τους μπορεί να έχει προβλήματα.

      Υποστηρίζω ότι ελέγχετε και είστε υπεύθυνοι για τη φιλοξενία σας, ώστε να μπορείτε να βασιστείτε στον προγραμματιστή σας για αυτό που είναι υπέροχο - να αναπτύσσεται!

      Εκτιμώ το push-back, Michael.

  4. 6

    Είμαι επίσης προγραμματιστής εφαρμογών ιστού και νομίζω ότι έχετε χτυπήσει το κεφάλι. Μερικές σκέψεις:

    Νομίζω ότι όλοι θα συμφωνούσαν (και βασίστηκε στα παρακάτω σχόλια) # 1 είναι απόλυτο. Ποτέ, μην το κάνεις ποτέ. Πάντα. Σε κάθε περίσταση.

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

    Για το # 3, οι πελάτες μας λαμβάνουν όλο τον πηγαίο κώδικα του τελικού προϊόντος με μία προειδοποίηση: Για προϊόντα τρίτων που χρησιμοποιούνται στη λύση (όπως στοιχεία ελέγχου ιστού από την Telerik ή Component One), μπορούμε να δώσουμε στον πελάτη το μεταγλωττισμένο dll για τον έλεγχο τρίτων (πχ πλέγμα). Οι συμφωνίες αδειοδότησης με αυτές τις τρίτες εταιρείες (τις οποίες παρέχουμε στον πελάτη) μας απαγορεύουν να αναδιανέμουμε τον πηγαίο κώδικα για αυτούς τους τύπους ελέγχων, επειδή είναι πνευματική ιδιοκτησία τρίτων, όχι δικός μας. Η χρήση αυτών των τύπων προϊόντων εξοικονομεί χρόνο ανάπτυξης για τον πελάτη και είναι πολύ φθηνότερη από την κατασκευή της ίδιας λειτουργικότητας από το μηδέν. Είμαστε εκ των προτέρων σχετικά με αυτήν την πολιτική πριν από κάθε εργασία. Φυσικά, εάν ο πελάτης επιθυμεί να πληρώσει για την ανάπτυξη προσαρμοσμένου ελέγχου (αντί να χρησιμοποιήσει το προ-κατασκευασμένο προϊόν από το τρίτο μέρος), παρέχουμε τον πηγαίο κώδικα για αυτόν τον προσαρμοσμένο έλεγχο μαζί με οτιδήποτε άλλο.

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

    Όπως είπαν και άλλοι, το # 4 συνιστάται πάντα. Πάντα!

    Χαιρετισμούς,
    Τιμ Γιανγκ

Ποια είναι η γνώμη σας;

Αυτός ο ιστότοπος χρησιμοποιεί το Akismet για να μειώσει το spam. Μάθετε πώς επεξεργάζονται τα δεδομένα των σχολίων σας.