Fabrício Ramos
outubro 18, 2018
18:13
Novos negócios, principalmente aqueles relacionados à tecnologia, lidam constantemente com softwares. Assim como o próprio Lexio, empresas de tecnologia, necessitam do software para promover soluções técnicas para seus clientes. No nosso caso, oferecemos o software como um serviço (SaaS), ou como preferimos definir, software como uma solução.
Nesse sentido, toda empresa que lida com desenvolvimento de softwares passa por uma importante questão: é melhor desenvolvê-lo internamente ou externamente? A resposta nem sempre é simples e depende das características de cada negócio.
Uma das alternativas para o desenvolvimento de software é internalizar o/a desenvolvedor/a na companhia. Trazer a pessoa para dentro do negócio, entretanto, depende das condições econômicas, financeiras e até societárias da empresa. Afinal, esse colaborador terá que ser remunerado ou até receber participação societária. Nesse sentido, contratar alguém com dedicação exclusiva para essa função faz sentido quando a tecnologia é o core business do negócio.
Mesmo assim, não é possível dizer que existe uma regra para empresas no que tange à internalização ou não do desenvolvimento. Entretanto, é possível apresentar as vantagens e desvantagens que cada modelo possui.
Internalizar o desenvolvimento deve ser uma decisão estratégica da companhia, baseada em uma avaliação sobre os pontos positivos de ter essa pessoa intimamente ligada ao dia-a-dia da empresa.
A maior vantagem da internalização do desenvolvedor do software é garantir o engajamento desse colaborador. Trazer quem cria a solução tecnológica para dentro da companhia facilita o alinhamento de interesses, pois essa pessoa enxergará o sucesso da companhia como seu próprio sucesso. Esse sentimento de pertencimento gera incentivos para uma atuação diligente e motivada. Além disso, a integração proporciona ao desenvolvedor uma visão mais clara dos objetivos da empresa e as razões por trás da demanda pelo desenvolvimento. Isso é crucial para a criação de um produto que responda às demandas da startup.
Somada ao alinhamento dos interesses do desenvolvedor com os da companhia, internalizar o desenvolvimento permite o exercício de maior controle. Ora, ter um funcionário, presente no cotidiano da companhia, respondendo aos chefes e aos outros funcionários diretamente evita que comandos se percam ou sejam mal entendidos. Há, dessa forma, um ganho de eficiência.
Em termos de eficiência quanto ao aprendizado, internalizar é positivo. O desenvolvedor está habituado com o código, linguagem e framework do software. Logo, não haverá um dispêndio de tempo grande para o aprendizado.
Por fim, há uma importante questão monetária que advém da internalização do desenvolvedor na companhia. Trazer essa pessoa para dentro do negócio, principalmente como sócio, evita o pagamento de remunerações altas. Para startups, que não tem bolsos fundos, oferecer participação societária para o desenvolvedor pode ser mais interessante do que pagar salário ou remuneração pela prestação do serviço.
A decisão de internalizar, entretanto, nem sempre é positiva para todos os negócios. Tudo depende da lógica empresarial, do modelo de negócio, dos outros integrantes da companhia e até dos objetivos com a entrada do desenvolvedor no time da empresa.
Um dos principais problemas do desenvolvimento interno relaciona-se à dificuldade de medir a qualidade do trabalho do criador. Normalmente, empreendedores e empresários não possuem o know-how sobre tecnologia e programação. Não é uma atividade cuja avaliação depende apenas de bom senso. Ao contrário, é preciso ter uma métrica diferenciada de avaliação.
Dessa forma, leigos têm dificuldade em acompanhar os resultados parciais do desenvolvedor, o que pode prejudicar a criação de um software que responda às demandas exatas da companhia. A solução para esse problema pode vir com a presença de um CTO (Chief Technology Officer) que controle o grupo dos programadores
Programadores normalmente possuem hábitos diferentes, se comparados com empreendedores ou empresários tradicionais. Trabalho no período noturno, dress code casual, hábito de deixar tudo para última hora e home office são características comuns. Dependendo do modelo de negócio, é difícil para que os programadores e os demais membros da equipe consigam conciliar essas diferenças, o que pode gerar atritos. Esse desgaste pode corroer a relação e prejudicar o andamento da companhia.
Ademais, outro ponto que deve ser lembrado é a quantidade de riscos e encargos trabalhistas que decorrem da internalização do desenvolvimento. Dependendo da relação estabelecida entre a empresa e os desenvolvedores, sempre há o risco de a Justiça do Trabalho considerar o vínculo como uma relação trabalhista. Isso pode ocorrer ainda que, no papel, o time de programação tenha sido contratado através de uma PJ própria.
A alternativa ao desenvolvimento interno está na contratação de um agente externo independente que preste o serviço, normalmente as chamadas software houses. Normalmente, esse tipo de contratação é utilizada nos casos em que a tecnologia não é o core business da empresa. É, portanto, uma opção para demandas pontuais específicas ou para oferecer suporte externo para empresas que pouco utilizam tecnologia diariamente.
A primeira vantagem de contratar um desenvolvedor externo é a expertise e know-how que o mesmo possui. Por ser esse ser o business da software house, ela sempre traz novidades do mercado e novas ideias, além de insights importantes para o design do produto. Há, claramente, uma distância de conhecimento e capacidade operacional das softwares houses em comparação com freelancers ou desenvolvedores internos. Essa mão de obra qualificada é um grande atrativo desse modelo.
Ademais, apesar de aparentar ser mais cara, a opção pelo desenvolvimento externo pode ser economicamente mais vantajosa a longo prazo. Em casos de projetos que demandam alta especificidade e técnica, vale mais a pena gastar uma quantia alta e ter um produto de qualidade do que investir o tempo e recursos internos para capacitar um desenvolvedor que já trabalha na companhia.
Por fim, os desenvolvedores externos estabelecem relação profissional de prestação do serviço com a empresa contratante. Há, portanto, a clareza de que um pólo da relação é o cliente e o outro é o prestador de serviço. Algumas empresas preferem essa formalidade e a definição de que o desenvolvedor é de fato um prestador de serviço remunerado, e não um membro da companhia, que estaria menos sujeito à lógica de resultados.
Entretanto, softwares houses apresentam pontos negativos, como todo modelo de contratação. Como já mencionado, é recomendável que haja internalização em negócios que giram em torno de softwares. Logo, não parece ser eficiente terceirizar a responsabilidade por criação de plataformas e programas que são imprescindíveis para o negócio.
Ademais, a software house, até por ser uma prestadora de serviços, tem menos interesse no resultado da empresa e, consequentemente, do software. Há um desalinhamento de interesses e dificuldade para deixar claro quais são os objetivos da companhia no desenvolvimento do software, até porque eles podem mudar durante a vigência da relação.
Não ter a empresa desenvolvedora no mesmo barco é um risco para o desenvolvimento do software, criando riscos e custos que talvez sejam insuportáveis.
Uma maneira criativa de mitigar esse problema, além de exigir garantias ou prever a rescisão contratual, é ser criativo na forma de remuneração. Oferecer participação societária como remuneração pelo fornecimento do software é uma maneira inovadora de alinhar os interesses da software house, futura sócia, com os da cliente. Isso deve ser feito com muito cuidado, pois nem sempre a desenvolvedora pode ter participação societária ou interesse em se ver integrada a outro negócio. Outra solução possível é evitar a remuneração por hora, à medida que essa é contraproducente: o cliente quer gastar menos e acaba conversando menos com a prestadora, enquanto a desenvolvedora não tem incentivos para tornar as reuniões mais eficientes. Nesse sentido, uma remuneração pelo trabalho pode ser interessante, já que as partes vão aproveitar o tempo juntas para alinhar os interesses e não terão preocupações com quanto tempo é necessário para que os rumos da prestação de serviço estejam claros.
Há um esforço grande que os negócios e startups devem ter ao optar pela software house, que é gastar recursos (dinheiro e tempo) para equilibrar a curva de aprendizado. Caso a software house seja contratada para uma demanda pontual ou para dar continuidade a um projeto já iniciado, a empresa precisará ensinar a linguagem que usa e as ferramentas até então utilizadas. Como, às vezes, o software cresce de maneira caoticamente ordenada, não é tão simples ensinar os que estão de fora do processo.
Somado a isso, há a dificuldade de avaliar o trabalho da software house, principalmente se as empresas não possuem alguém interno com essa capacidade. É possível que a empresa não consiga distinguir a qualidade da entrega do software, o que culminaria na contratação de empresas que não produzem os resultados esperados. Por isso, ainda que externalizando o serviço, é interessante que haja alguém interno capaz de avaliar minimamente a entrega.
Por fim, é possível que o trabalho da software house apresente problemas que necessitem correções. Caso o contrato não forneça soluções, como garantias ou responsabilidades pós contratuais, a com犀利士
panhia pode se ver de mãos atadas e com um produto inutilizável, sem que possa exigir as devidas reparações.
A criação de modelos é importante para gerar categorias que possam facilitar nosso entendimento da realidade. Entretanto, isso não pode ser vista como uma verdade absoluta e imutável. O mesmo se aplica aos modelos de desenvolvimento de software.
Seja o desenvolvimento feito por agente integrado à companhia ou por uma software house, é crucial que o modelo optado reflita as demandas de cada negócio. Recursos financeiros, tempo, tamanho e know-how da equipe, urgência para o desenvolvimento e importância do software no negócio são alguns dos requisitos que devem ser avaliados na escolha por um dos modelos.
No fim do dia, os riscos jurídicos e contratuais são apenas orientadores para a melhor decisão negocial dos empresários.
fabricio.ramos@lexio.legal
Desenvolvedor jurídico e comercial do Lexio.
