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 desenvolvedor 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 requiriu 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 estaba a usar 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 ocorrer 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 conservo 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 rendibilidade por iso ... 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 desenvolvedor 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 significativa da solución xeral.

    Exemplo:
    O cliente quería o control de nivel de páxina e campo relacionado cos roles de usuario. A funcionalidade "fóra da caixa" para ASP.Net fai permisos a nivel de cartafol. Así que ampliei 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ódigos (como se estipula no contrato) pero síntome xustificado en utilizar a mesma metodoloxía e anacos de código para realizar esta extensión en futuros proxectos.

    Outra engurra:
    Fíxeno mentres me explotaba unha empresa de consultoría. ¿Tería a empresa consultora o dereito de volver atrás e copiar esa solución, comercializándoa como propia?

    • 2

      En realidade non,

      Creo que estamos de acordo. O meu punto nisto é asegurarse de que ten o código e pode saír coa porta con el. Se o teu programador compila o teu código e o envía ao teu sitio, non tes o código. Vin isto ocorrer con todo, desde gráficos, Flash, .NET, Java ... calquera cousa que precise un ficheiro fonte e se produza.

      Doug

  2. 3

    Vexo de onde vés e aínda que non estou de acordo con todo ao 100% (teño advertencias), as empresas sempre deben telo presente.

    1. ABSOLUTAMENTE. Non podo subliñar isto o suficiente. Traballei nunha pequena empresa que fixo isto e sentín unha culpa esmagadora por estar involucrado. Estou moi contento de poder saír de alí. Os clientes deben manter absolutamente o control dos seus dominios. Se ten a alguén suficientemente experto, non lle dea acceso ao desenvolvedor. Se non, asegúrate de que o programador teña un xeito de cambiar información ou transferir o dominio a través dunha interface de revendedor dalgún tipo.

    2. Estaría en parte de acordo con isto, pero depende da situación. Se estás a implementar unha aplicación PHP sinxela e necesitas aloxamento de baixo custo, obviamente obtén unha conta LunarPages ou DreamHost ou algo así e bótaa alí. Dálle acceso ao desenvolvedor. Non obstante, o aloxamento compartido de baixo custo ten certamente os seus inconvenientes ... especialmente para cousas máis grandes. Pero se es o suficientemente grande como para preocuparte, debes contar con alguén técnico que poida xestionalo. Moito diso obviamente trata de confianza. Por suposto, poña algo nun contrato se pode sobre este tipo de cousas (restricións e demais). O aloxamento de terceiros é estupendo se o desenvolvedor non necesita facer nada de luxo. Admito que estou desgarrado porque é realmente unha situación. Tamén depende do tamaño do sitio, da variedade de tecnoloxías empregadas. Se vai ser grande, considerar a contratación dunha persoa en persoal. Non sempre é unha opción, pero máis seguro para cousas grandes.

    3. Isto tamén foi algo que fixo a miña antiga empresa. Podería marchar, daríanlle HTML, imaxes, etc. pero sen código. O código era un servizo arrendado basicamente. Dito isto, hai posuír e posuír. Sempre fixen unha venda non exclusiva. Basicamente, necesito poder reutilizar os meus compoñentes. Non teño ningún problema co feito de que o cliente o faga, faga o que queira con el e que alguén traballe nela ... pero non me hipotecarei e teño 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 (# 2):

    "É fantástico 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 diso, pode ser contraproducente nalgúns casos mandar que o seu proxecto se aloxe noutro lugar. Se a empresa que desenvolve o teu sitio ou aplicación ten unha plataforma de hospedaxe que prefiren usar, é probable que lles sexa máis eficiente e produtivo o seu uso.

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

    Sei que existen moitas historias de terror sobre este tipo de situacións, pero en xeral recomendaríache que te centres en atopar un desenvolvedor de confianza. Podes utilizar o aloxamento do teu programador e aínda así 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 o creo, é 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.

      Nas empresas sucédense cousas que rompen as relacións e non teñen por que ser negativas. Quizais o seu desenvolvedor / empresa teña un cliente moi grande e non lle poida permitir o tempo. Quizais cambien os obxectivos comerciais. Ás veces a súa empresa de hospedaxe pode ter problemas.

      Estou defendendo que controles e sexas responsable do teu aloxamento para que poidas depender do teu desenvolvedor no que é xenial: desenvolver.

      Agradezo o retroceso, Michael.

  4. 6

    Eu tamén son desenvolvedor de aplicacións web e creo que lle botaches o cravo. Algúns pensamentos:

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

    Teño un punto de vista diferente ao número 2 que quizais algúns dos meus compañeiros de desenvolvemento: rexeitamos aloxar o produto final para os nosos clientes (por suposto, aloxamos un servidor de probas para que os clientes proben o produto durante o desenvolvemento). Estamos encantados de axudar aos clientes a configurarse para aloxalos eles mesmos ou atopar un provedor de hospedaxe. Simplemente non queremos entrar no negocio do aloxamento. Se iso significa afastar o traballo, así sexa. Hai moitas grandes compañías de hospedaxe ou firmas de infraestrutura que non poden ofrecer este servizo a un prezo moito máis barato. Fomentamos a portabilidade do noso traballo e faremos todo o que poidamos para axudar a aloxalo, aínda que o cliente cambie de provedor de hospedaxe anos.

    No 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 controis web de Telerik ou Component One), podemos darlle ao cliente a dll compilada para o control de terceiros (digamos unha cuadrícula). Os nosos acordos de licenza con esas compañías de terceiros (que proporcionamos ao cliente) prohíbenos redistribuír o código fonte dese tipo de controis, porque é propiedade intelectual dos terceiros e non a 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. Estamos adiantados sobre esta política antes de que se faga calquera traballo. Por suposto, se o cliente desexa pagar polo desenvolvemento do control personalizado (en lugar de usar o produto prefabricado dun terceiro), fornecemos o código fonte dese control personalizado xunto con todo o demais.

    Cando se trata de reutilizar o código, estamos ao corrente sobre o feito de que podemos reutilizar partes do código a menos que se desenvolva expresamente exclusivamente para o uso do cliente (digamos para un proceso empresarial propietario) antes de que se faga calquera traballo. Se o cliente quere que o código exclusivo se desenvolva, por suposto, está dispoñible para eles.

    Como dixeron outros, sempre se recomenda o número 4. Sempre!

    Saúdos,
    Tim Young

¿Que pensas?

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