Evite que sus desarrolladores lo tomen como rehén

rehén100107Este fin de semana inicié una conversación con una artista local que ha estado ayudando a su jefe con el manejo de un par de aplicaciones web que posee.

La conversación dio un giro y algunos desahogos continuaron sobre el pago de tarifas de desarrollo semanales sin ver ningún progreso con el desarrollador con el que han estado trabajando. Ahora el desarrollador quiere cobrarles otra tarifa global para completar el proyecto, así como una tarifa de mantenimiento semanal para cubrir otras solicitudes. Se pone peor.

El desarrollador transfirió los nombres de dominio para poder administrarlos. El desarrollador también aloja la aplicación en su cuenta de alojamiento. En resumen, el desarrollador ahora los tiene como rehenes.

Afortunadamente, la mujer con la que estoy trabajando exigió acceso administrativo en el pasado para editar algunos de los archivos de plantilla para el sitio. El desarrollador podría haberle proporcionado acceso limitado, pero no lo hizo. Él (perezosamente) le proporcionó el acceso administrativo al sitio. Esta noche usé ese acceso para hacer una copia de seguridad de todo el código del sitio. También descubrí qué software de gestión estaba usando y me dirigí a la administración de la base de datos, donde pude exportar tanto los datos de las aplicaciones como las estructuras de las tablas. Uf.

El propietario planeaba trasladar los sitios a nuevos nombres de dominio una vez que se completara el desarrollo. Eso es enorme porque significa que los dominios actuales podrían expirar en caso de que haya una separación enojada entre el desarrollador y la empresa. He visto esto suceder antes.

Algunos consejos si va a contratar un equipo de desarrollo subcontratado:

  1. Registro de Dominio

    Registre sus nombres de dominio a nombre de su empresa. No está mal tener a su desarrollador como contacto técnico en la cuenta, pero nunca transferir la propiedad del dominio a cualquier persona ajena a su empresa.

  2. Alojamiento de su aplicación o sitio

    Es genial que su desarrollador tenga una empresa de alojamiento y pueda alojar su sitio por usted, pero no lo haga. En su lugar, pregunte sus recomendaciones sobre dónde alojar la aplicación. Es cierto que los desarrolladores se familiarizan con el software de administración, las versiones y la ubicación de los recursos y eso puede ayudar a que su producto se complete antes. Dicho esto, sin embargo, sea propietario de la cuenta de alojamiento y agregue a su desarrollador con su propio inicio de sesión y acceso. De esta manera, puede desconectar el enchufe siempre que lo necesite.

  3. Poseer el código

    No asuma que es el propietario del código, póngalo por escrito. Si no desea que su desarrollador utilice las soluciones que le pagó para desarrollar en otro lugar, debe decidirlo en el momento del contrato. He desarrollado soluciones de esta manera, pero también las he desarrollado donde conservo los derechos sobre el código. En el último caso, negocié el costo de la aplicación más bajo para que hubiera un incentivo para que la empresa me diera derechos. Si no le importa que su desarrollador use su código en otro lugar, ¡entonces no debería pagar mucho dinero!

  4. ¡Obtenga una segunda opinión!

    No hiere mis sentimientos cuando la gente me dice que están aceptando ofertas o que están consultando con otros profesionales. De hecho, ¡lo recomiendo!

La conclusión es que está pagando por el talento de su desarrollador, pero debe mantener el control y la propiedad sobre la idea. Es tuyo. Fuiste tú quien invirtió en él, tú quien arriesgó tu negocio y la rentabilidad por él… y eres tú quien debe mantenerlo. Los desarrolladores pueden ser reemplazados y eso nunca debería poner en riesgo su aplicación, o peor aún, su negocio.

6 Comentarios

  1. 1

    Soy un desarrollador de aplicaciones web y estoy de acuerdo con la mayoría de sus puntos (quizás con todos), pero me gustaría una aclaración sobre el n. ° 3.

    La duplicación al por mayor de un sitio o aplicación vendida a otra empresa (o peor aún, a un competidor) no es ética y siempre debe estipularse como no aceptable en su contrato. Sin embargo, he desarrollado soluciones innovadoras para problemas comunes mientras trabajaba en el proyecto de un cliente que no tiene nada que ver con su negocio en particular ni representa una parte significativa de la solución general.

    Ejemplo:
    El cliente quería un control de nivel de página y de campo vinculado a los roles de usuario. La funcionalidad "lista para usar" para ASP.Net hace permisos a nivel de carpeta. Entonces extendí los permisos nativos para .Net y entregué la solución como parte de una aplicación web general.

    Creo que tienen derecho a todo el código base (como se estipula en el contrato), pero me siento justificado al usar la misma metodología y fragmentos de código para lograr esta extensión en proyectos futuros.

    Otra arruga:
    Hice esto mientras estaba en una granja de una empresa de consultoría. ¿La empresa consultora tendría derecho, en su opinión, a retroceder y copiar esa solución, comercializándola como propia?

    • 2

      Realmente no,

      Creo que estamos de acuerdo. Mi punto en esto es asegurarme de que tiene el código y puede salir por la puerta con él. Si su desarrollador compila código para usted y lo envía a su sitio, no tiene el código. He visto que esto sucede con todo, desde gráficos, Flash, .NET, Java ... cualquier cosa que requiera un archivo fuente y se genere.

      Doug

  2. 3

    Veo de dónde vienes y aunque no estoy de acuerdo con todo al 100% (tengo salvedades), las empresas siempre deben tener esto en cuenta.

    1. ABSOLUTAMENTE. No puedo enfatizar esto lo suficiente. Trabajé para una pequeña empresa que hizo esto y me sentí muy culpable por estar involucrado. Estoy tan contento de haber podido salir de allí. Los clientes deben mantener absolutamente el control de sus dominios. Si tiene a alguien lo suficientemente inteligente, no le dé acceso al desarrollador a esto. De lo contrario, asegúrese de que el desarrollador tenga una forma de cambiar la información / transferir el dominio a través de una interfaz de revendedor de algún tipo como mínimo.

    2. Estoy de acuerdo en parte con esto, pero depende de la situación. Si está implementando una aplicación PHP simple y necesita alojamiento de bajo costo, por supuesto, obtenga una cuenta LunarPages o DreamHost o algo y tírelo allí. Dar acceso al desarrollador. Sin embargo, el alojamiento compartido de bajo costo ciertamente tiene sus inconvenientes ... especialmente para cosas más grandes. Pero si eres lo suficientemente grande como para preocuparte por eso, deberías tener a alguien técnico en el personal que pueda lidiar con eso. Mucho de esto, obviamente, tiene que ver con la confianza. Seguro que ponga algo en un contrato si puede sobre este tipo de cosas (restricciones y cosas así). El alojamiento de terceros es excelente si el desarrollador no necesita hacer nada elegante. Admito que estoy desgarrado porque es realmente una cuestión de situación. También depende del tamaño del sitio, la variedad de tecnologías utilizadas. Si va a ser grande, considere contratar a una persona en el personal. No siempre es una opción, pero es más seguro para cosas grandes.

    3. Esto también es algo que hizo mi antigua empresa. Podrías irte, te darían el HTML, las imágenes, etc…. pero sin código. Básicamente, el código era un servicio alquilado. Dicho esto, existe la propiedad y la propiedad. Siempre he hecho una venta no exclusiva. Básicamente, necesito poder reutilizar mis componentes. No tengo ningún problema con que el cliente lo posea, haga lo que quiera con él y tenga a alguien más trabajando en él en el futuro ... pero no me voy a hipotecar y tengo que reinventar la rueda cada vez.

    4. Siempre. Siempre. Siempre.

  3. 4

    Buena publicación ... bien hecho, aunque no estoy de acuerdo con un elemento (# 2):

    "Es fantástico que su desarrollador tenga una empresa de alojamiento y pueda alojar su sitio por usted, pero no lo haga".

    Aunque entiendo la lógica detrás de esto, puede ser contraproducente en algunos casos ordenar que su proyecto se aloje en otro lugar. Si la empresa que desarrolla su sitio o aplicación tiene una plataforma de alojamiento que prefiere usar, es probable que sea más eficiente y productiva para ellos.

    Además, desde un punto de vista filosófico, si se niega a utilizar la plataforma de alojamiento de su desarrollador porque no quiere ser "rehén", esto establece un tono de desconfianza desde el principio. Si realmente no confías en tu desarrollador lo suficiente como para alojar con ellos, ¿realmente quieres trabajar con ellos en primer lugar?

    Sé que existen muchas historias de terror sobre este tipo de situaciones, pero en general te recomiendo que te concentres en encontrar un desarrollador en quien confíes. Puede utilizar el alojamiento de su desarrollador y aún protegerse solicitando acceso administrativo y haciendo sus propias copias de seguridad.

    Nuevamente, buen post e información muy útil.

    ¡Gracias!
    Michael Reynolds

    • 5

      Hola Michael,

      Puede parecer un problema de confianza, pero no creo que lo sea, es realmente un problema de control y responsabilidad. Si va a invertir una cantidad significativa en el desarrollo de su sitio web, debe estar seguro de que puede controlar su entorno.

      En los negocios suceden cosas que rompen relaciones y no tienen por qué ser negativas. Quizás su desarrollador / empresa obtenga un cliente muy grande y no pueda permitirse el tiempo. Quizás cambien los objetivos comerciales. A veces, su empresa de alojamiento puede tener problemas.

      Abogo por que usted controle y sea responsable de su alojamiento para que pueda depender de su desarrollador para lo que es excelente: ¡desarrollar!

      Aprecio el rechazo, Michael.

  4. 6

    También soy desarrollador de aplicaciones web, y creo que has dado en el clavo. Algunos pensamientos:

    Creo que casi todo el mundo estaría de acuerdo (y según los comentarios a continuación) el n. ° 1 es absoluto. Nunca jamás lo hagas. Nunca. Bajo cualquier circunstancia.

    Tengo una visión diferente del n. ° 2 que quizás algunos de mis compañeros desarrolladores: nos negamos a alojar el producto final para nuestros clientes (por supuesto, alojamos un servidor de prueba para que los clientes prueben el producto durante el desarrollo). Nos complace ayudar a los clientes a configurarse para alojarlo ellos mismos o encontrar un proveedor de alojamiento. Simplemente no queremos meternos en el negocio del hosting. Si eso significa rechazar el trabajo, que así sea. Existen muchas empresas de alojamiento o empresas de infraestructura excelentes que pueden proporcionar este servicio a un precio mucho más económico. Fomentamos la portabilidad de nuestro trabajo y haremos todo lo posible para ayudar a que se aloje, incluso si el cliente cambia de proveedor de alojamiento en el futuro.

    Para el n. ° 3, nuestros clientes obtienen todo el código fuente del producto final con una advertencia: para los productos de terceros que se utilizan en la solución (como los controles web de Telerik o Component One), podemos darle al cliente la dll compilada para el control de terceros (digamos una cuadrícula). Nuestros acuerdos de licencia con esas empresas de terceros (que proporcionamos al cliente) nos prohíben redistribuir el código fuente para ese tipo de controles, porque es propiedad intelectual de terceros, no nuestra. El uso de este tipo de productos ahorra tiempo de desarrollo al cliente y es mucho más económico que construir la misma funcionalidad desde cero. Somos sinceros sobre esta política antes de que se realice cualquier trabajo. Por supuesto, si el cliente desea pagar por el desarrollo del control personalizado (en lugar de utilizar el producto prediseñado de un tercero), proporcionamos el código fuente para ese control personalizado junto con todo lo demás.

    Cuando se trata de la reutilización del código, somos sinceros sobre el hecho de que podemos reutilizar partes del código a menos que haya sido desarrollado expresamente exclusivamente para el uso del cliente (por ejemplo, para un proceso comercial propietario) antes de que se realice cualquier trabajo. Si el cliente quiere tener un código exclusivo desarrollado, por supuesto, está disponible para él.

    Como han dicho otros, siempre se recomienda el # 4. ¡Siempre!

    Saludos,
    Tim young

¿Qué piensas?

Este sitio usa Akismet para reducir el correo no deseado. Descubra cómo se procesan los datos de sus comentarios.