É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 un tour et quelques évents ont continué 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 veut 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 laquelle je travaille a exigé 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 la connexion administrative au 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 et les structures de table des applications. 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âchée entre le développeur et l'entreprise. J'ai déjà vu cela arriver.

Quelques conseils si vous comptez 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 n'allons jamais transférer la propriété du domaine à toute personne extérieure à votre entreprise.

  2. Hébergement de votre application ou site

    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. Au lieu de cela, demandez à ses recommandations 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 et cela peut aider votre produit à être terminé plus tôt. Cela dit, cependant, possédez le compte d'hébergement et ajoutez votre développeur avec ses propres identifiants et accès. De cette façon, vous pouvez retirer la prise quand vous en avez besoin.

  3. Posséder le code

    Ne supposez pas que vous possédez le code, mettez-le par écrit. Si vous ne souhaitez pas que votre développeur utilise les solutions que vous lui avez payées 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 la demande plus bas afin 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, vous ne devriez pas payer le prix fort!

  4. Obtenez un deuxième avis!

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

L'essentiel est que 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 la conserver. Les développeurs peuvent être remplacés et cela ne devrait jamais mettre votre application, ou pire encore, votre entreprise, en danger.

6 Commentaires

  1. 1

    Je suis un 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 point 3.

    La duplication en gros d'un site ou d'une application vendue à une autre entreprise (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 son entreprise particulière et qui ne représente pas non plus une partie importante de la solution globale.

    Mise en situation :
    Le client souhaitait un contrôle au niveau de la page et au niveau du champ lié aux rôles des utilisateurs. La fonctionnalité "prête à l'emploi" pour ASP.Net effectue 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 réaliser cette extension sur de futurs projets.

    Une autre ride :
    Je l'ai fait tout en étant sous-traité par une société de conseil. La société de conseil aurait-elle le droit, selon vous, 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 but est de m'assurer que vous avez le code et que vous pouvez sortir avec. Si votre développeur compile le code pour vous et le transmet à 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 doivent toujours garder cela à l'esprit.

    1. ABSOLUMENT. Je ne saurais trop insister là-dessus. J'ai travaillé pour une petite entreprise qui a fait ça et j'ai ressenti une culpabilité écrasante d'être impliqué. Je suis tellement content 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, ne donnez pas accès à cela au développeur. Si ce n'est pas le cas, assurez-vous que le développeur dispose d'un moyen pour vous de modifier les informations/transférer le domaine via une interface de revendeur quelconque à tout le moins.

    2. Je serais 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 quelque chose et déposez-le là-bas. Accordez l'accès au développeur. Cependant, l'hébergement mutualisé à faible coût a certainement ses inconvénients… surtout pour les choses plus importantes. Mais si vous êtes assez grand pour vous en préoccuper, 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 choses (restrictions et autres). L'hébergement tiers est idéal si le développeur n'a pas besoin de faire quoi que ce soit d'extraordinaire. J'avoue que je suis déchiré parce que c'est vraiment une question de situation. Cela dépend aussi de la taille du site, de l'éventail des technologies utilisées. Si ça va être gros, envisager d'embaucher une personne dans le personnel. Pas toujours une option, mais plus sûre pour les gros trucs.

    3. C'est aussi quelque chose que mon ancienne entreprise a fait. Vous pourriez partir, ils vous donneraient le HTML, les images etc…. mais pas de code. Le code était essentiellement un service loué. Cela dit, il y a possession et possession. 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 en soit propriétaire, en fasse ce qu'il veut et que quelqu'un d'autre travaille dessus… mais je ne vais pas m'hypothéquer et devoir réinventer la roue à chaque fois.

    4. Toujours. Toujours. Toujours.

  3. 4

    Bel article… bravo 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'elle sera plus efficace et productive pour elle.

    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 lui, voulez-vous vraiment travailler avec lui en premier lieu ?

    Je sais qu'il existe de nombreuses histoires d'horreur à propos de 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 article et informations très utiles.

    Merci!
    Michael Reynolds

    • 5

      Salut michael,

      Cela peut ressembler à 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 que vous pouvez contrôler son environnement.

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

      Je préconise que vous contrôliez et soyez responsable de votre hébergement afin que vous puissiez dépendre de votre développeur pour ce qu'il fait de mieux : développer !

      J'apprécie le refoulement, Michael.

  4. 6

    Je suis également développeur d'applications Web, et je pense que vous avez mis le doigt sur la tête. Quelques idées:

    Je pense que presque tout le monde serait d'accord (et sur la base des commentaires ci-dessous) # 1 est un absolu. Ne le faites jamais, jamais. Déjà. En toutes circonstances.

    J'ai une vision différente de #2 que peut-être 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 refuser le travail, qu'il en soit ainsi. Il existe de nombreuses grandes sociétés d'hébergement ou 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 ce qui est en notre pouvoir pour faciliter son hébergement, même si le client change de fournisseur d'hébergement des années plus tard.

    Pour #3, nos clients obtiennent tout le code source du produit final avec une mise en garde : pour les produits tiers qui sont 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 des tiers, pas de la nôtre. L'utilisation de ces types de produits permet au client de gagner du temps de développement et est beaucoup moins chère que de créer la même fonctionnalité à partir de zéro. Nous sommes francs au sujet de cette politique avant que tout travail ne soit effectué. Bien entendu, 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é ainsi que 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'utilisation du client (par exemple pour un processus métier propriétaire) avant que tout travail ne soit effectué. Si le client souhaite faire développer un code exclusif, bien sûr, celui-ci 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..