Eviteu que els vostres desenvolupadors els prenguin com a ostatges

ostatge100107Aquest cap de setmana vaig iniciar una conversa amb un artista local que ha estat ajudant el seu cap amb la gestió d'un parell d'aplicacions web que posseeix el seu cap.

La conversa va fer un gir i es van continuar desafiant les quotes de desenvolupament setmanals sense veure cap progrés amb el desenvolupador amb el qual han estat treballant. Ara el desenvolupador vol cobrar-los una altra tarifa global per completar el projecte, així com una quota de manteniment setmanal per cobrir altres sol·licituds. Empitjora.

El desenvolupador va transferir els noms de domini perquè els pogués gestionar. El desenvolupador també allotja l'aplicació al seu compte d'allotjament. En resum, ara el desenvolupador els manté com a ostatges.

Afortunadament, la dona amb qui treballo va demanar accés administratiu en el passat per editar alguns dels fitxers de plantilla del lloc. El desenvolupador li podria haver proporcionat un accés limitat, però ell no. Ell (mandrós) li va proporcionar l'inici de sessió administratiu al lloc. Aquesta nit he utilitzat aquest accés per fer còpies de seguretat de tot el codi del lloc. També vaig descobrir quin programari de gestió utilitzava i em vaig dirigir a l’administració de bases de dades, on vaig poder exportar tant les dades de les aplicacions com les estructures de taula. Vaja.

El propietari tenia previst moure els llocs a nous noms de domini un cop finalitzat el desenvolupament. Això és enorme perquè significa que els dominis actuals podrien caducar en cas que hi hagi una ràbia separació entre el desenvolupador i l’empresa. Ja ho he vist passar.

Alguns consells per obtenir un equip de desenvolupament subcontractat:

  1. Registre de dominis

    Registreu els vostres noms de domini al nom de la vostra empresa. No està malament tenir el vostre desenvolupador com a contacte tècnic al compte, però mai transfereixi la propietat del domini a qualsevol persona que no sigui la vostra empresa.

  2. Allotjar la vostra sol·licitud o lloc

    És fantàstic que el vostre desenvolupador tingui una empresa d’allotjament i pugui allotjar el vostre lloc, però no ho feu. En el seu lloc, pregunteu a les seves recomanacions sobre on allotjar l'aplicació. És cert que els desenvolupadors es familiaritzen amb el programari de gestió, les versions i la ubicació dels recursos, cosa que pot ajudar a que el vostre producte es completi abans. Dit això, però, teniu el compte d’allotjament i afegiu el vostre desenvolupador amb el seu propi inici de sessió i accés. D’aquesta manera, podeu estirar l’endoll sempre que ho necessiteu.

  3. Posseir el codi

    No suposeu que sou el propietari del codi, poseu-lo per escrit. Si no voleu que el vostre desenvolupador utilitzi les solucions que li heu pagat perquè es desenvolupi en un altre lloc, heu de decidir-ho en el moment del contracte. He desenvolupat solucions d’aquesta manera, però també les he desenvolupat on conservo els drets sobre el codi. En aquest darrer cas, vaig negociar el cost de l'aplicació més baix per tal que hi hagués un incentiu a l'empresa perquè em concedís drets. Si no us importa que el vostre desenvolupador faci servir el vostre codi en un altre lloc, no hauríeu de pagar els millors diners.

  4. Obteniu una segona opinió!

    No em fa mal les sensacions quan la gent em diu que fa ofertes o que consulta amb altres professionals. De fet, el recomano!

La conclusió és que pagueu pel talent del vostre desenvolupador, però heu de mantenir el control i la propietat de la idea. És teu. Vostè va ser qui va invertir-hi, vostè qui va arriscar el seu negoci i la seva rendibilitat ... i és qui ho ha de mantenir. Es poden substituir els desenvolupadors i això mai no hauria de posar en risc la vostra aplicació, o el que és pitjor, la vostra empresa.

6 Comentaris

  1. 1

    Sóc desenvolupador d'aplicacions web i estic d'acord amb la majoria dels vostres punts (potser tots), però voldria una aclarició sobre el número 3.

    La duplicació a l’engròs d’un lloc o d’una aplicació venuda a una altra empresa (o pitjor encara a un competidor) no és ètica i sempre s’ha d’estipular com a no acceptable al vostre contracte. Tot i això, he desenvolupat solucions innovadores per a problemes habituals mentre treballava en el projecte d’un client que no té res a veure amb el seu negoci particular ni representa una part important de la solució general.

    Exemple:
    El client volia que el control de nivell de pàgina i de camp estigués lligat a les funcions dels usuaris. La funcionalitat "fora de la caixa" per a ASP.Net fa permisos a nivell de carpeta. Per tant, vaig ampliar els permisos natius de .Net i vaig lliurar la solució com a part d’una aplicació web general.

    Crec que tenen dret a tota la base de codis (tal com s’estipula al contracte), però em sento justificat d’utilitzar la mateixa metodologia i trossos de codi per aconseguir aquesta extensió en futurs projectes.

    Una altra arruga:
    Vaig fer-ho mentre m’explotava una empresa de consultoria. La vostra empresa consultora tindria dret a tornar enrere i copiar aquesta solució, comercialitzant-la com a pròpia?

    • 2

      No realment,

      Crec que estem d’acord. El meu punt en això és assegurar-me que teniu el codi i que pugueu sortir amb la porta. Si el vostre desenvolupador compila el codi i el fa arribar al vostre lloc, no el teniu. He vist això succeir amb tot, des de gràfics, Flash, .NET, Java ... qualsevol cosa que requereixi un fitxer font i que es produeixi.

      Doug

  2. 3

    Veig d’on veniu i, tot i que no estic d’acord amb tot al 100% (tinc advertències), les empreses sempre ho haurien de tenir en compte.

    1. ABSOLUTAMENT. No ho puc subratllar prou. He treballat per a una petita empresa que ho feia i sentia una culpa aclaparadora per la implicació. Estic molt content d’haver pogut sortir d’allà. Els clients haurien de mantenir absolutament el control dels seus dominis. Si tenen algú prou expert, no doneu accés al desenvolupador. Si no és així, assegureu-vos que el desenvolupador tingui una manera de canviar informació o transferir el domini a través d’una interfície de revenedor d’alguna mena.

    2. Estaria en part d'acord amb això, però depèn de la situació. Si esteu desplegant una senzilla aplicació PHP i necessiteu allotjament de baix cost, obtingueu un compte de LunarPages o DreamHost o alguna cosa així i deixeu-lo allà. Doneu accés al desenvolupador. No obstant això, l’allotjament compartit de baix cost té certament els seus inconvenients ... sobretot per a coses més grans. Però si sou prou gran per preocupar-vos, hauríeu de comptar amb algú tècnic que pugui fer-hi front. Molt, evidentment, es tracta de confiança. Per descomptat, poseu alguna cosa en un contracte si podeu sobre aquest tipus de coses (restriccions, etc.). L’allotjament de tercers és fantàstic si el desenvolupador no necessita fer res de fantàstic. Reconec que estic esquinçat perquè realment és una situació. També depèn de la mida del lloc, de la gamma de tecnologies utilitzades. Si serà gran, penseu en contractar una persona en plantilla. No sempre és una opció, però més segura per a coses grans.

    3. Això també va fer la meva antiga empresa. Podríeu marxar, us donarien l'HTML, les imatges, etc. però sense codi. El codi era bàsicament un servei arrendat. Dit això, hi ha propietat i propietat. Sempre he fet una venda no exclusiva. Bàsicament, he de poder reutilitzar els meus components. No tinc cap problema amb el fet que el client el posseeixi, faci el que vulgui amb ell i que hi faci treballar algú més ... però no em hipotecaré i hauré de reinventar la roda cada vegada.

    4. Sempre. Sempre. Sempre.

  3. 4

    Bon post ... ben fet tot i que no estic d'acord amb un element (núm. 2):

    "És fantàstic que el vostre desenvolupador tingui una empresa d'allotjament i pugui allotjar el vostre lloc per vosaltres, però no ho feu".

    Tot i que entenc la lògica que hi ha darrere, en alguns casos pot ser contraproduent exigir que el vostre projecte s’allotgi en un altre lloc. Si l’empresa que desenvolupa el vostre lloc o aplicació té una plataforma d’allotjament que prefereix utilitzar, és probable que els sigui més eficient i productiu.

    A més, des del punt de vista filosòfic, si us negueu a utilitzar la plataforma d'allotjament del vostre desenvolupador perquè no voleu ser "ostatge", això establirà un to de desconfiança des del principi. Si realment no confieu prou en el vostre desenvolupador per allotjar-vos-hi, voleu treballar amb ells en primer lloc?

    Sé que existeixen moltes històries de terror sobre aquest tipus de situacions, però, en general, us recomanaria que us centreu a buscar un desenvolupador de confiança. Podeu utilitzar l’allotjament del vostre desenvolupador i, tot i així, protegir-vos sol·licitant accés administratiu i fent les vostres pròpies còpies de seguretat.

    De nou, bona publicació i informació molt útil.

    Gràcies!
    Michael Reynolds

    • 5

      Hola Michael,

      Pot semblar un problema de confiança, però no ho crec, és realment un problema de control i responsabilitat. Si voleu invertir una quantitat important en el desenvolupament del vostre lloc web, heu d'estar segur que podeu controlar-ne l'entorn.

      En els negocis passen coses que trenquen les relacions i no necessiten ser negatives. Potser el vostre desenvolupador / empresa aconsegueix un client molt gran i no us pot permetre el temps. Potser canvien els objectius de negoci. De vegades, la seva empresa d’allotjament pot tenir problemes.

      Estic defensant que controleu i sigueu responsables del vostre allotjament perquè pugueu dependre del vostre desenvolupador per al que és fantàstic: desenvolupar.

      Agraeixo el retrocés, Michael.

  4. 6

    També sóc desenvolupador d'aplicacions web i crec que us heu clavat el cap. Alguns pensaments:

    Crec que la majoria de tots estaria d'acord (i s'ha basat en els comentaris següents): el número 1 és absolut. Mai, mai ho feu. Sempre. Sota qualsevol circumstància.

    Tinc una visió diferent del número 2 que potser alguns dels meus companys de desenvolupament: ens neguem a allotjar el producte final per als nostres clients (per descomptat, allotgem un servidor de proves perquè els clients provin el producte durant el desenvolupament). Ens complau ajudar els clients a configurar-se per allotjar-los ells mateixos o trobar un proveïdor d'allotjament. Simplement no volem dedicar-nos al negoci de l’allotjament. Si això vol dir desviar la feina, així sigui. Hi ha moltes empreses d’allotjament o empreses d’infraestructures fantàstiques que no poden proporcionar aquest servei a un preu molt més barat. Fomentem la portabilitat del nostre treball i farem tot el possible per ajudar-lo a allotjar-lo, fins i tot si el client canvia de proveïdor d’allotjament durant anys.

    Per al número 3, els nostres clients obtenen tot el codi font del producte final amb una sola advertència: per als productes de tercers que s’utilitzen a la solució (com ara controls web de Telerik o Component One), podem proporcionar al client la dll compilada per el control de tercers (per exemple, una graella). Els nostres acords de llicència amb aquestes empreses de tercers (que proporcionem al client) ens prohibeixen la redistribució del codi font d’aquest tipus de controls, ja que és propietat intel·lectual de tercers i no la nostra. L’ús d’aquest tipus de productes permet estalviar temps de desenvolupament per al client i és molt més barat que crear la mateixa funcionalitat des de zero. Estem avançats en aquesta política abans de fer qualsevol treball. Per descomptat, si el client vol pagar pel desenvolupament del control personalitzat (en lloc d’utilitzar el producte prefabricat de tercers), proporcionem el codi font d’aquest control personalitzat juntament amb tota la resta.

    Quan es tracta de la reutilització del codi, ens expliquem per avançat sobre el fet que podem reutilitzar parts del codi, tret que s’hagi desenvolupat expressament exclusivament per a l’ús del client (per exemple, per a un procés empresarial propietari) abans de fer qualsevol treball. Si el client vol que es desenvolupi un codi exclusiu, per descomptat, estarà disponible per a ell.

    Com han dit altres, sempre es recomana la # 4. Sempre!

    Salutacions,
    Tim Young

Què et sembla?

Aquest lloc utilitza Akismet per reduir el correu no desitjat. Esbrineu com es processa el vostre comentari.