Evite que os seus desenvolvedores te refiren

refén100107Esta fin de semana iniciei unha conversa cun artista local que estivo axudando ao seu xefe coa xestión dun par de aplicacións web que posúe o seu xefe.

A conversa deu un xiro e algúns desafogáronse no pago de taxas de desenvolvemento semanais sen ver ningún progreso co programador co que estiveron traballando. Agora o desenvolvedor quere cobrarlles outra taxa global para completar o proxecto, así como unha taxa de mantemento semanal para cubrir outras peticións. Empeora.

O desenvolvedor transferiu os nomes de dominio para poder xestionalos. O programador tamén aloxa a aplicación na súa conta de hospedaxe. En resumo, agora o desenvolvedor está a mantelos como reféns.

Afortunadamente, a muller coa que estou a traballar solicitou acceso administrativo no pasado para editar algúns dos ficheiros de modelos do sitio. O desenvolvedor podería proporcionarlle un acceso limitado pero non o fixo. (Perezoso) proporcionoulle o inicio de sesión administrativo no sitio. Esta noite usei ese acceso para facer copia de seguridade de todo o código do sitio. Tamén descubrín o software de xestión que empregaba e dirixinme á administración de bases de datos onde puiden exportar tanto os datos das aplicacións como as estruturas de táboas. Whew.

O propietario planeaba trasladar os sitios a novos nomes de dominio unha vez finalizado o desenvolvemento. Iso é enorme porque significa que os dominios actuais poderían caducar no caso de que haxa unha irritada separación entre o desarrollador e a empresa. Xa vin isto acontecer antes.

Algúns consellos para conseguir un equipo de desenvolvemento subcontratado:

  1. Rexistro de dominios

    Rexistra os teus nomes de dominio no nome da túa empresa. Non está mal ter o teu programador como contacto técnico na conta, pero nin transferir a propiedade do dominio a calquera persoa allea á súa empresa.

  2. Aloxamento da súa aplicación ou sitio

    É xenial que o teu programador poida ter unha empresa de hospedaxe e poida aloxar o teu sitio por ti, pero non o fagas. En lugar diso, pregúntalle ás súas recomendacións onde aloxar a aplicación. É certo que os desenvolvedores coñecen o software de xestión, as versións e a localización dos recursos e iso pode axudar a completar o seu produto antes. Dito isto, con todo, ten a conta de hospedaxe e engade o seu programador co seu propio inicio de sesión e acceso. Deste xeito, pode tirar do enchufe sempre que o precise.

  3. Posuír o Código

    Non asuma que é o propietario do código, poñelo por escrito. Se non quere que o seu desenvolvedor empregue as solucións que lle pagou para que se desenvolva noutros lugares, debe decidilo no momento do contrato. Desenvolvei solucións deste xeito pero tamén as desenvolvín onde gardo os dereitos do código. Neste último caso, negociaba o custo da aplicación máis baixo para que houbese un incentivo á empresa para que me dese dereitos. Se non che importa que o teu programador use o teu código noutro lugar, non deberías pagar o máximo.

  4. Obtén unha segunda opinión!

    Non me doe a sensación cando a xente me di que están a facer ofertas ou que consultan con outros profesionais. De feito, recoméndoo.

A conclusión é que estás pagando polo talento do teu creador, pero debes manter o control e a propiedade sobre a idea. É teu. Fuches ti o que investiches niso, ti o que arriscaches o teu negocio e a túa rendibilidade ... e ti debes mantelo. Os desenvolvedores pódense substituír e iso nunca debería poñer en risco a túa aplicación ou, peor aínda, a túa empresa.

6 Comentarios

  1. 1

    Son un programador de aplicacións web e estou de acordo coa maioría dos teus puntos (quizais todos), pero gustaríame unha aclaración sobre o número 3.

    A duplicación por xunto dun sitio ou aplicación vendida a outra empresa (ou peor a un competidor) non é ética e sempre debe estipularse como non aceptable no seu contrato. Non obstante, desenvolvín solucións innovadoras para problemas comúns mentres traballaba no proxecto dun cliente que non ten nada que ver co seu negocio particular nin representa unha parte importante da solución global.

    Exemplo:
    O cliente quería o control do nivel de páxina e do campo ligado aos roles dos usuarios. A funcionalidade "fóra da caixa" para ASP.Net fai permisos a nivel de cartafoles. Entón estendei os permisos nativos para .Net e entreguei a solución como parte dunha aplicación web global.

    Creo que teñen dereito a toda a base de código (tal e como se estipula no contrato) pero síntome xustificado para usar a mesma metodoloxía e anacos de código para realizar esta extensión en proxectos futuros.

    Outra engurra:
    Fixen isto mentres estaba a cargo dunha empresa de consultoría. A consultora tería dereito na súa opinión a volver e copiar esa solución, comercializando como propia?

    • 2

      En realidade non,

      Creo que estamos de acordo. O meu punto neste é asegurarme de que tes o código e podes saír pola porta con el. Se o teu programador está a compilar código para ti e a envialo ao teu sitio, non tes o código. Vin que isto ocorre con todo, desde gráficos, Flash, .NET, Java... calquera cousa que requira un ficheiro fonte e se saia.

      Doug

  2. 3

    Vexo de onde vén e aínda que non estou de acordo 100% con todo (teño salvedades), as empresas deberían ter isto en conta sempre.

    1. ABSOLUTAMENTE. Non podo enfatizar isto o suficiente. Traballei para unha pequena empresa que fixo isto e sentín unha culpa esmagadora por estar implicado. Estou moi feliz de poder saír de alí. Os clientes deben manter o control dos seus dominios. Se teñen alguén o suficientemente experto, non lle deas acceso ao programador. Se non, asegúrate de que o programador teña un xeito de cambiar a información/transferir o dominio a través dunha interface de revendedor como mínimo.

    2. Estaría de acordo en parte con isto, pero despois depende da situación. Se estás implementando unha aplicación PHP sinxela e necesitas hospedaxe de baixo custo, obtén unha conta LunarPages ou DreamHost ou algo así e bótaa alí. Dálle acceso ao programador. Non obstante, o hospedaxe compartido de baixo custo ten certamente os seus inconvenientes... especialmente para cousas máis grandes. Pero se es o suficientemente grande como para preocuparte por iso, deberías contar con alguén técnico no persoal que poida xestionalo. Moito é obviamente sobre a confianza. Seguro que pon algo nun contrato se pode sobre este tipo de cousas (restricións e tal). O aloxamento de terceiros é xenial se o programador non precisa facer nada extravagante. Recoñezo que estou desgarrado porque realmente é unha cousa situacional. Tamén depende do tamaño do sitio, da variedade de tecnoloxías utilizadas. Se vai ser grande, tendo en conta a contratación dunha persoa do persoal. Non sempre é unha opción, pero é máis seguro para cousas grandes.

    3. Isto tamén é algo que fixo a miña antiga empresa. Poderías marchar, dábanche o HTML, imaxes, etc... pero sen código. O código era basicamente un servizo alugado. Dito isto, hai posuír e posuír. Sempre fixen unha venda non exclusiva. Basicamente, teño que ser capaz de reutilizar os meus compoñentes. Non teño ningún problema con que o cliente o posúa, faga o que queira con el e que alguén traballe nel máis tarde... pero non me vou hipotecar e ter que reinventar a roda cada vez.

    4. Sempre. Sempre. Sempre.

  3. 4

    Boa publicación... ben feito aínda que non estou de acordo cun elemento (nº 2):

    "É xenial que o teu programador teña unha empresa de hospedaxe e poida aloxar o teu sitio por ti, pero non o fagas".

    Aínda que entendo a lóxica detrás disto, pode ser contraproducente nalgúns casos esixir que o teu proxecto estea aloxado noutro lugar. Se a empresa que desenvolve o teu sitio ou aplicación ten unha plataforma de hospedaxe que prefire usar, é probable que sexa máis eficiente e produtivo usala.

    Ademais, desde un punto de vista filosófico, se rexeitas utilizar a plataforma de hospedaxe do teu programador porque non queres "ser refén", entón isto establece un ton de desconfianza desde o principio. Se realmente non confías o suficiente no teu programador como para aloxar con eles, entón realmente queres traballar con eles en primeiro lugar?

    Sei que existen moitas historias de terror sobre este tipo de situacións, pero en xeral recomendaríache que te concentres en buscar un programador no que confíes. Podes utilizar o hospedaxe do teu programador e aínda protexerte solicitando acceso administrativo e facendo as túas propias copias de seguridade.

    De novo, boa publicación e información moi útil.

    Grazas!
    Michael Reynolds

    • 5

      Ola Michael,

      Pode parecer un problema de confianza, pero non creo que o sexa, é realmente un problema de control e responsabilidade. Se vas investir unha cantidade importante no desenvolvemento do teu sitio web, debes estar seguro de que podes controlar o seu entorno.

      Nos negocios pasan cousas que rompen as relacións e non teñen por que ser negativas. Quizais o teu programador/empresa teña un cliente moi grande e non che poida dar tempo. Quizais cambien os obxectivos comerciais. Ás veces, a súa empresa de hospedaxe pode ter problemas.

      Estou a defender que controles e sexas responsable do teu hospedaxe para que poidas depender do teu programador para o que é xenial: desenvolver!

      Agradezo o retroceso, Michael.

  4. 6

    Tamén son un programador de aplicacións web e creo que deches o cravo. Algunhas reflexións:

    Creo que a maioría de todos estarían de acordo (e baseouse nos comentarios a continuación) o número 1 é un absoluto. Nunca, nunca o fagas. Sempre. Baixo calquera circunstancia.

    Teño unha visión diferente do número 2 que quizais algúns dos meus compañeiros desenvolvedores: negámonos a aloxar o produto final para os nosos clientes (por suposto, aloxamos un servidor de probas para que os clientes poidan probar o produto durante o desenvolvemento). Estamos encantados de axudar aos clientes a configurarse para aloxalo eles mesmos ou atopar un provedor de hospedaxe. Simplemente non queremos entrar no negocio de hospedaxe. Se iso significa desviar o traballo, así sexa. Hai moitas grandes empresas de hospedaxe ou empresas de infraestruturas que poden ofrecer este servizo a un prezo moito máis barato. Fomentamos a portabilidade do noso traballo e faremos todo o que poidamos para axudarlle a aloxalo, aínda que o cliente cambie de provedor de hospedaxe anos máis tarde.

    Para o número 3, os nosos clientes obteñen todo o código fonte do produto final cunha advertencia: para os produtos de terceiros que se usan na solución (como os controis web de Telerik ou Component One), podemos darlle ao cliente a dll compilada para o control de terceiros (por exemplo, unha cuadrícula). Os nosos acordos de licenza con esas empresas de terceiros (que proporcionamos ao cliente) prohíbennos redistribuír o código fonte para ese tipo de controis, porque é propiedade intelectual de terceiros, non nosa. O uso deste tipo de produtos aforra tempo de desenvolvemento para o cliente e é moito máis barato que construír a mesma funcionalidade desde cero. Nós somos sinceros sobre esta política antes de facer calquera traballo. Por suposto, se o cliente quere pagar o desenvolvemento de control personalizado (en lugar de utilizar o produto preconstruído de terceiros), fornecemos o código fonte para ese control personalizado xunto con todo o demais.

    Cando se trata de reutilizar o código, somos sinceros sobre o feito de que podemos reutilizar partes do código a non ser que fose desenvolvido expresamente exclusivamente para o uso do cliente (por exemplo, para un proceso de negocio propietario) antes de realizar calquera traballo. Se o cliente quere ter un código exclusivo desenvolvido, por suposto, está dispoñible para eles.

    Como dixeron outros, o número 4 sempre é recomendable. Sempre!

    Saúdos,
    Tim Young

¿Que pensas?

Este sitio usa Akismet para reducir o spam. Aprende a procesar os teus datos de comentarios.