Évitez d'être pris en otage par vos développeurs

hostage100107Ce week-end, j'ai entamé une conversation avec une artiste locale qui a aidé son patron dans la gestion de quelques applications Web que son patron possède.

La conversation a pris une tournure et certains évanouissements se sont poursuivis sur le paiement des frais de développement hebdomadaires sans voir aucun progrès avec le développeur avec lequel ils ont travaillé. Maintenant, le développeur souhaite leur facturer un autre montant forfaitaire pour terminer le projet ainsi que des frais de maintenance hebdomadaires pour couvrir d'autres demandes. Ça s'empire.

Le développeur a transféré les noms de domaine pour pouvoir les gérer. Le développeur héberge également l'application sur son compte d'hébergement. Bref, le développeur les tient désormais en otage.

Heureusement, la femme avec qui je travaille a demandé un accès administratif dans le passé pour modifier certains des fichiers modèles du site. Le développeur aurait pu lui fournir un accès limité, mais il ne l'a pas fait. Il lui a (paresseusement) fourni les identifiants administratifs du site. Ce soir, j'ai utilisé cet accès pour sauvegarder tout le code du site. J'ai également compris quel logiciel de gestion il utilisait et je me suis dirigé vers l'administration de la base de données où j'ai pu exporter les données des applications et les structures des tables. Ouf.

Le propriétaire prévoyait de déplacer les sites vers de nouveaux noms de domaine une fois le développement terminé. C'est énorme car cela signifie que les domaines actuels pourraient expirer en cas de séparation fâcheuse entre le développeur et l'entreprise. J'ai déjà vu cela arriver.

Quelques conseils si vous envisagez de faire appel à une équipe de développement externalisée :

  1. Enregistrement de domaines

    Enregistrez vos noms de domaine au nom de votre entreprise. Ce n'est pas mal d'avoir votre développeur comme contact technique sur le compte, mais ne gardent transférer la propriété du domaine à toute personne extérieure à votre entreprise.

  2. Hébergement de votre application ou site

    C'est bien que votre développeur puisse avoir une société d'hébergement et puisse héberger votre site pour vous, mais ne le faites pas. Au lieu de cela, demandez ses recommandations pour savoir où héberger l'application. Il est vrai que les développeurs se familiarisent avec le logiciel de gestion, les versions et l'emplacement des ressources, ce qui peut aider à terminer votre produit plus tôt. Cela dit, cependant, possédez le compte d'hébergement et ajoutez votre développeur avec ses propres identifiant et accès. De cette façon, vous pouvez débrancher la prise quand vous en avez besoin.

  3. Posséder le code

    Ne présumez pas que vous possédez le code, mettez-le par écrit. Si vous ne voulez pas que votre développeur utilise les solutions que vous l'avez payé pour développer ailleurs, vous devez le décider au moment du contrat. J'ai développé des solutions de cette façon, mais je les ai également développées où je conserve les droits sur le code. Dans ce dernier cas, j'ai négocié le coût de l'application à la baisse pour que l'entreprise soit incitée à me donner des droits. Si cela ne vous dérange pas que votre développeur utilise votre code ailleurs, alors vous ne devriez pas payer le gros lot !

  4. Obtenez un deuxième avis!

    Cela ne me blesse pas lorsque les gens me disent qu'ils acceptent des offres ou consultent d'autres professionnels. En fait, je le recommande !

En fin de compte, vous payez pour le talent de votre développeur, mais vous devez conserver le contrôle et la propriété de l'idée. C'est le tien. C'est vous qui y avez investi, vous qui avez risqué votre entreprise et votre rentabilité pour cela… et c'est vous qui devez le garder. Les développeurs peuvent être remplacés et cela ne devrait jamais mettre votre application, ou pire – votre entreprise, en danger.

6 Commentaires

  1. 1

    Je suis développeur d'applications Web et je suis d'accord avec la plupart de vos points (peut-être tous), mais j'aimerais une clarification sur le n ° 3.

    La duplication en gros d'un site ou d'une application vendue à une autre société (ou pire à un concurrent) est contraire à l'éthique et doit toujours être stipulée comme non acceptable dans votre contrat. Cependant, j'ai développé des solutions innovantes à des problèmes courants tout en travaillant sur le projet d'un client qui n'a rien à voir avec leur entreprise particulière et qui ne représente pas une partie significative de la solution globale.

    Mise en situation :
    Le client souhaitait un contrôle au niveau de la page et du champ lié aux rôles utilisateur. La fonctionnalité «prête à l'emploi» pour ASP.Net fait des autorisations au niveau des dossiers. J'ai donc étendu les autorisations natives pour .Net et fourni la solution dans le cadre d'une application Web globale.

    Je pense qu'ils ont droit à l'intégralité de la base de code (comme stipulé dans le contrat) mais je me sens justifié d'utiliser la même méthodologie et les mêmes morceaux de code pour accomplir cette extension sur de futurs projets.

    Une autre ride:
    J'ai fait cela tout en étant cultivé par une société de conseil. La société de conseil aurait-elle le droit, à votre avis, de revenir en arrière et de copier cette solution en la commercialisant comme la sienne?

    • 2

      Pas vraiment,

      Je pense que nous sommes d’accord. Mon objectif est de m'assurer que vous avez le code et que vous pouvez sortir avec lui. Si votre développeur compile du code pour vous et le pousse sur votre site, vous n'avez pas le code. J'ai vu cela se produire avec tout, des graphiques, Flash, .NET, Java… tout ce qui nécessite un fichier source et est sorti.

      Doug

  2. 3

    Je vois d'où vous venez et même si je ne suis pas d'accord avec tout à 100% (j'ai des mises en garde), les entreprises devraient toujours garder cela à l'esprit.

    1. ABSOLUMENT. Je ne peux pas insister assez sur cela. J'ai travaillé pour une petite entreprise qui a fait cela et j'ai ressenti une culpabilité écrasante d'être impliquée. Je suis tellement contente d'avoir pu sortir de là. Les clients doivent absolument garder le contrôle de leurs domaines. S'ils ont quelqu'un d'assez averti, n'autorisez pas le développeur à y accéder. Sinon, assurez-vous que le développeur a un moyen pour vous de modifier les informations / transférer le domaine via une interface de revendeur de quelque type que ce soit.

    2. Je suis en partie d'accord avec cela, mais cela dépend de la situation. Si vous déployez une application PHP simple et que vous avez besoin d'un hébergement à faible coût, procurez-vous un compte LunarPages ou DreamHost ou autre chose et déposez-le là-bas. Donnez l'accès au développeur. Cependant, l'hébergement mutualisé à faible coût a certainement ses inconvénients… en particulier pour les grandes choses. Mais si vous êtes assez grand pour vous en inquiéter, vous devriez avoir quelqu'un de technique dans le personnel qui peut s'en occuper. Une grande partie est évidemment une question de confiance. Bien sûr, mettez quelque chose dans un contrat si vous le pouvez à propos de ce genre de chose (restrictions et autres). L'hébergement tiers est idéal si le développeur n'a pas besoin de faire quelque chose d'extraordinaire. J'avoue que je suis déchiré parce que c'est vraiment une chose situationnelle. Cela dépend également de la taille du site, de l'éventail des technologies utilisées. Si ça va être gros, envisagez d'embaucher un membre du personnel. Pas toujours une option, mais plus sûre pour les gros objets.

    3. C'est également ce que faisait mon ancienne entreprise. Vous pourriez partir, ils vous donneraient le HTML, les images etc…. mais pas de code. Le code était essentiellement un service loué. Cela étant dit, il y a posséder et posséder. J'ai toujours fait une vente non exclusive. En gros, j'ai besoin de pouvoir réutiliser mes composants. Je n'ai aucun problème à ce que le client le possède, fasse ce qu'il veut avec et demande à quelqu'un d'autre de travailler dessus… mais je ne m'hypothéquerai pas et je devrai réinventer la roue à chaque fois.

    4. Toujours. Toujours. Toujours.

  3. 4

    Beau message ... bien fait même si je ne suis pas d'accord avec un élément (# 2):

    "C'est formidable que votre développeur ait une société d'hébergement et puisse héberger votre site pour vous, mais ne le faites pas."

    Bien que je comprenne la logique derrière cela, il peut être contre-productif dans certains cas d'exiger que votre projet soit hébergé ailleurs. Si l'entreprise qui développe votre site ou votre application dispose d'une plate-forme d'hébergement qu'elle préfère utiliser, il est probable qu'il sera plus efficace et productif pour elle de l'utiliser.

    De plus, d'un point de vue philosophique, si vous refusez d'utiliser la plate-forme d'hébergement de votre développeur parce que vous ne voulez pas être «pris en otage», cela donne un ton de méfiance dès le départ. Si vous ne faites vraiment pas suffisamment confiance à votre développeur pour héberger avec eux, voulez-vous vraiment travailler avec eux en premier lieu?

    Je sais que de nombreuses histoires d'horreur existent sur ce genre de situation, mais en général, je vous recommande de vous concentrer sur la recherche d'un développeur en qui vous avez confiance. Vous pouvez utiliser l'hébergement de votre développeur tout en vous protégeant en demandant un accès administratif et en effectuant vos propres sauvegardes.

    Encore une fois, bon message et informations très utiles.

    Merci!
    Michael Reynolds

    • 5

      Salut michael,

      Cela peut sembler un problème de confiance, mais je ne pense pas que ce soit le cas - c'est vraiment un problème de contrôle et de responsabilité. Si vous allez investir une somme importante dans le développement de votre site Web, vous devez être sûr de pouvoir contrôler son environnement.

      Il se passe dans les affaires des choses qui brisent les relations et qui n'ont pas besoin d'être négatives. Peut-être que votre développeur / entreprise a un très gros client et ne peut pas vous donner le temps. Peut-être changent-ils les objectifs commerciaux. Parfois, leur société d'hébergement peut avoir des problèmes.

      Je recommande que vous contrôliez et soyez responsable de votre hébergement afin que vous puissiez compter sur votre développeur pour ce qu'il fait - développer!

      J'apprécie le recul, Michael.

  4. 6

    Je suis également développeur d'applications Web et je pense que vous avez frappé dans le mille. Quelques idées:

    Je pense que presque tout le monde serait d'accord (et a basé sur les commentaires ci-dessous) # 1 est un absolu. Jamais, jamais. Déjà. En toutes circonstances.

    J'ai un point de vue différent sur le # 2 peut-être que certains de mes collègues développeurs: nous refusons d'héberger le produit final pour nos clients (bien sûr, nous hébergeons un serveur de test pour que les clients testent le produit pendant le développement). Nous sommes heureux d'aider les clients à se préparer à l'héberger eux-mêmes ou à trouver un fournisseur d'hébergement. Nous ne voulons tout simplement pas nous lancer dans l'hébergement. Si cela signifie détourner le travail, qu'il en soit ainsi. Il existe de nombreuses sociétés d'hébergement ou de sociétés d'infrastructure qui peuvent fournir ce service à un prix beaucoup moins cher. Nous encourageons la portabilité de notre travail et ferons tout notre possible pour aider à l'héberger, même si le client change de fournisseur d'hébergement des années plus tard.

    Pour le n ° 3, nos clients obtiennent tout le code source du produit final avec une mise en garde: pour les produits tiers utilisés dans la solution (tels que les contrôles Web de Telerik ou Component One), nous pouvons donner au client la DLL compilée pour le contrôle tiers (disons une grille). Nos accords de licence avec ces sociétés tierces (que nous fournissons au client) nous interdisent de redistribuer le code source pour ce type de contrôles, car il s'agit de la propriété intellectuelle de tiers, pas de la nôtre. L'utilisation de ces types de produits économise du temps de développement pour le client et coûte beaucoup moins cher que de créer la même fonctionnalité à partir de zéro. Nous sommes francs au sujet de cette politique avant tout travail. Bien sûr, si le client souhaite payer pour le développement d'un contrôle personnalisé (au lieu d'utiliser le produit prédéfini du tiers), nous fournissons le code source de ce contrôle personnalisé avec tout le reste.

    En ce qui concerne la réutilisation du code, nous sommes francs sur le fait que nous pouvons réutiliser des parties du code à moins qu'il n'ait été expressément développé exclusivement pour l'usage du client (par exemple pour un processus commercial propriétaire) avant que tout travail ne soit effectué. Si le client souhaite bien entendu développer un code exclusif, il est à sa disposition.

    Comme d'autres l'ont dit, le n ° 4 est toujours recommandé. Toujours!

    Salutations,
    Tim Young

Que pensez-vous?

Ce site utilise Akismet pour réduire les spams. Découvrez comment sont traitées les données de vos commentaires..