Evite ser tomado como refém por seus desenvolvedores

hostage100107Neste fim de semana, iniciei uma conversa com uma artista local que tem ajudado seu chefe no gerenciamento de alguns aplicativos da web que seu chefe possui.

A conversa mudou e houve algum desabafo sobre o pagamento de taxas de desenvolvimento semanais sem ver nenhum progresso com o desenvolvedor com quem estavam trabalhando. Agora, o desenvolvedor deseja cobrar outra quantia fixa para concluir o projeto, bem como uma taxa de manutenção semanal para cobrir outras solicitações. Fica pior.

O desenvolvedor transferiu os nomes de domínio para que ele pudesse gerenciá-los. O desenvolvedor também hospeda o aplicativo em sua conta de hospedagem. Resumindo, o desenvolvedor agora os mantém como reféns.

Felizmente, a mulher com quem estou trabalhando exigia acesso administrativo no passado para editar alguns dos arquivos de modelo do site. O desenvolvedor poderia ter fornecido acesso limitado a ela, mas não o fez. Ele (preguiçosamente) forneceu a ela o login administrativo para o site. Esta noite usei esse acesso para fazer backup de todo o código do site. Também descobri qual software de gerenciamento ele estava usando e fui para a administração do banco de dados, onde pude exportar os dados dos aplicativos e as estruturas de tabelas. Uau.

O proprietário estava planejando mover os sites para novos nomes de domínio assim que o desenvolvimento fosse concluído. Isso é enorme porque significa que os domínios atuais podem expirar no caso de haver uma separação violenta entre o desenvolvedor e a empresa. Já vi isso acontecer antes.

Algumas dicas se você for contratar uma equipe de desenvolvimento terceirizada:

  1. Registro do Domínio

    Registre seus nomes de domínio no nome de sua empresa. Não é ruim ter seu desenvolvedor como um contato técnico na conta, mas nunca transferir a propriedade do domínio para qualquer pessoa fora de sua empresa.

  2. Hospedando seu aplicativo ou site

    É ótimo que seu desenvolvedor tenha uma empresa de hospedagem e possa hospedar seu site para você, mas não faça isso. Em vez disso, peça suas recomendações sobre onde hospedar o aplicativo. É verdade que os desenvolvedores se familiarizam com o software de gerenciamento, versões e localização de recursos e isso pode ajudar seu produto a ser concluído mais cedo. Dito isso, porém, seja dono da conta de hospedagem e adicione seu desenvolvedor com seu próprio login e acesso. Dessa forma, você pode puxar o plugue sempre que precisar.

  3. Possui o código

    Não presuma que você possui o código, coloque-o por escrito. Se você não quiser que seu desenvolvedor use as soluções que você pagou para ele desenvolver em outro lugar, você deve decidir isso no momento do contrato. Eu desenvolvi soluções dessa forma, mas também as desenvolvi onde mantenho os direitos sobre o código. Neste último caso, negociei o custo do aplicativo menor para que houvesse um incentivo para a empresa me dar direitos. Se você não se importa que seu desenvolvedor use seu código em outro lugar, então você não deveria estar pagando caro!

  4. Obtenha uma segunda opinião!

    Não fere meus sentimentos quando as pessoas me dizem que estão aceitando ofertas ou consultando outros profissionais. Na verdade, eu recomendo!

O resultado final é que você está pagando pelo talento de seu desenvolvedor, mas deve manter o controle e a propriedade sobre a ideia. É seu. Foi você quem investiu nele, você que arriscou seu negócio e sua lucratividade… e é você quem deve mantê-lo. Os desenvolvedores podem ser substituídos e isso nunca deve colocar seu aplicativo, ou pior - seu negócio, em risco.

6 Comentários

  1. 1

    Sou desenvolvedor de aplicativos da web e concordo com a maioria dos seus pontos (talvez todos), mas gostaria de um esclarecimento sobre o nº 3.

    A duplicação por atacado de um site ou aplicativo vendido para outra empresa (ou pior, um concorrente) é antiético e deve sempre ser estipulado como não aceitável em seu contrato. No entanto, desenvolvi soluções inovadoras para problemas comuns enquanto trabalhava no projeto de um cliente que não tem nada a ver com seu negócio específico nem representa uma parte significativa da solução geral.

    Exemplo:
    O cliente queria controle de nível de página e nível de campo vinculado às funções do usuário. A funcionalidade “pronta para uso” para ASP.Net faz permissões de nível de pasta. Assim, estendi as permissões nativas para .Net e entreguei a solução como parte de um aplicativo geral da Web.

    Acredito que eles tenham direito a toda a base de código (conforme estipulado no contrato), mas me sinto justificado em usar a mesma metodologia e pedaços de código para realizar essa extensão em projetos futuros.

    Outra ruga:
    Eu fiz isso enquanto estava sendo cultivado por uma empresa de consultoria. A consultoria teria o direito em sua opinião de voltar e copiar aquela solução, comercializando-a como sua?

    • 2

      Na verdade,

      Acho que concordamos. Meu ponto nisso é garantir que você tenha o código e possa sair pela porta com ele. Se o seu desenvolvedor está compilando código para você e enviando-o para o seu site – você não tem o código. Já vi isso acontecer com tudo, desde gráficos, Flash, .NET, Java… qualquer coisa que exija um arquivo de origem e seja gerado.

      Doug

  2. 3

    Eu vejo de onde você está vindo e, embora eu não concorde 100% com tudo (tenho ressalvas), as empresas devem sempre ter isso em mente.

    1. ABSOLUTAMENTE. Não posso enfatizar isso o suficiente. Trabalhei para uma pequena empresa que fez isso e me senti esmagadoramente culpada por estar envolvida. Estou tão feliz por ter conseguido sair de lá. Os clientes devem manter absolutamente o controle de seus domínios. Se eles tiverem alguém experiente o suficiente, não dê ao desenvolvedor acesso a isso. Caso contrário, verifique se o desenvolvedor tem uma maneira de alterar as informações/transferir o domínio por meio de uma interface de revendedor de algum tipo, no mínimo.

    2. Concordo em parte com isso, mas depende da situação. Se você estiver implantando um aplicativo PHP simples e precisar de hospedagem de baixo custo, obtenha uma conta LunarPages ou DreamHost ou algo assim e despeje lá. Dê acesso ao desenvolvedor. No entanto, hospedagem compartilhada de baixo custo certamente tem suas desvantagens... especialmente para coisas maiores. Mas se você é grande o suficiente para se preocupar com isso, deve ter alguém técnico na equipe que possa lidar com isso. Muito disso é obviamente sobre confiança. Com certeza coloque algo em um contrato, se puder, sobre esse tipo de coisa (restrições e tal). A hospedagem de terceiros é ótima se o desenvolvedor não precisar fazer nada extravagante. Admito que estou dividido porque é realmente uma coisa situacional. Também depende do tamanho do site, do conjunto de tecnologias utilizadas. Se vai ser grande, considerando contratar uma pessoa na equipe. Nem sempre uma opção, mas mais seguro para coisas grandes.

    3. Isso também é algo que minha antiga empresa fez. Você poderia sair, eles lhe dariam o HTML, imagens etc…. mas sem código. O código era basicamente um serviço alugado. Dito isto, há possuir e possuir. Sempre fiz uma venda não exclusiva. Basicamente, eu preciso ser capaz de reutilizar meus componentes. Eu não tenho nenhum problema com o cliente possuí-lo, fazer o que quiser com ele e ter outra pessoa trabalhando nisso… mas eu não vou me hipotecar e ter que reinventar a roda toda vez.

    4. Sempre. Sempre. Sempre.

  3. 4

    Bom post… bem feito, embora eu discorde de um item (#2):

    “É ótimo que seu desenvolvedor tenha uma empresa de hospedagem e possa hospedar seu site para você, mas não faça isso.”

    Embora eu entenda a lógica por trás disso, pode ser contraproducente em alguns casos exigir que seu projeto seja hospedado em outro lugar. Se a empresa que está desenvolvendo seu site ou aplicativo tiver uma plataforma de hospedagem que prefere usar, é provável que seja mais eficiente e produtivo para ela.

    Além disso, do ponto de vista filosófico, se você se recusar a utilizar a plataforma de hospedagem do seu desenvolvedor porque não quer ser “refém”, isso cria um tom de desconfiança desde o início. Se você realmente não confia em seu desenvolvedor o suficiente para hospedar com eles, então você realmente quer trabalhar com eles em primeiro lugar?

    Eu sei que existem muitas histórias de terror sobre esse tipo de situação, mas em geral eu recomendaria que você se concentrasse em encontrar um desenvolvedor em quem confia. Você pode utilizar a hospedagem do seu desenvolvedor e ainda se proteger solicitando acesso administrativo e fazendo seus próprios backups.

    Mais uma vez, bom post e informações muito úteis.

    Obrigado!
    Michael Reynolds

    • 5

      Oi Michael,

      Pode soar como uma questão de confiança, mas não acho que seja – é realmente uma questão de controle e responsabilidade. Se você vai investir uma quantia significativa no desenvolvimento de seu site, você deve ter certeza de que pode controlar seu ambiente.

      Coisas acontecem nos negócios que rompem relacionamentos e não precisam ser negativas. Talvez seu desenvolvedor/empresa tenha um cliente muito grande e não possa lhe dar tempo. Talvez eles mudem os objetivos de negócios. Às vezes, sua empresa de hospedagem pode ter problemas.

      Estou defendendo que você controle e seja responsável por sua hospedagem para que possa depender de seu desenvolvedor para o que ele é ótimo – desenvolvimento!

      Agradeço o empurrão, Michael.

  4. 6

    Também sou desenvolvedor de aplicativos da Web e acho que você acertou em cheio. Alguns pensamentos:

    Eu acho que quase todo mundo concordaria (e com base nos comentários abaixo) # 1 é um absoluto. Nunca, nunca faça isso. Sempre. Sob qualquer circunstância.

    Eu tenho uma opinião diferente sobre o número 2 do que talvez alguns de meus colegas desenvolvedores: nos recusamos a hospedar o produto final para nossos clientes (é claro, hospedamos um servidor de teste para os clientes testarem o produto durante o desenvolvimento). Estamos felizes em ajudar os clientes a se prepararem para hospedá-lo ou encontrar um provedor de hospedagem. Nós simplesmente não queremos entrar no negócio de hospedagem. Se isso significa afastar o trabalho, que assim seja. Existem muitas grandes empresas de hospedagem ou empresas de infraestrutura por aí que podem fornecer esse serviço a um preço muito mais barato. Incentivamos a portabilidade de nosso trabalho e faremos o que pudermos para ajudar a hospedá-lo, mesmo que o cliente mude de provedor de hospedagem anos depois.

    Para #3, nossos clientes obtêm todo o código-fonte do produto final com uma ressalva: para produtos de terceiros usados ​​na solução (como controles da Web da Telerik ou Component One), podemos fornecer ao cliente a dll compilada para o controle de terceiros (digamos, uma grade). Nossos contratos de licenciamento com essas empresas terceirizadas (que fornecemos ao cliente) nos proíbem de redistribuir o código-fonte para esse tipo de controle, porque é propriedade intelectual de terceiros, não nossa. O uso desses tipos de produtos economiza tempo de desenvolvimento para o cliente e é muito mais barato do que construir a mesma funcionalidade do zero. Somos francos sobre esta política antes que qualquer trabalho seja feito. Obviamente, se o cliente desejar pagar pelo desenvolvimento de controle personalizado (em vez de usar o produto pré-construído de terceiros), fornecemos o código-fonte para esse controle personalizado junto com todo o resto.

    Quando se trata de reutilização de código, somos sinceros sobre o fato de que podemos reutilizar partes do código, a menos que ele tenha sido desenvolvido exclusivamente para uso do cliente (digamos, para um processo de negócios proprietário) antes de qualquer trabalho ser feito. Se o cliente quiser ter um código exclusivo desenvolvido, é claro, isso está disponível para ele.

    Como outros já disseram, o nº 4 é sempre recomendado. Sempre!

    Saudações,
    Tim Young

O que você acha?

Este site usa o Akismet para reduzir o spam. Saiba como seus dados de comentário são processados.