Quando se fala em desenvolvimento de software 100% personalizado, não podemos deixar de mencionar o maior tabu para esse mercado: cronogramas e prazos que não foram cumpridos, expectativas frustradas e o fim da parceria entre fornecedor e cliente.

Levando estes pontos em consideração, aqui neste artigo, vamos expor a nossa perspectiva enquanto empresa desenvolvedora de projetos e apresentar os pilares que dificultam o sucesso das expectativas traçadas.

Ao longo do conteúdo, abordaremos os seguintes pontos:

• PILAR 1: maturidade de software
• PILAR 2: processo
  • Cascata para escopo fechado
  • Alocação de time e o uso do kanban para entregas cadenciadas
  • Metodologia ágil na alocação de time com um objetivo macro
• PILAR 3: time multidisciplinar
• PILAR 4: alinhamento de expectativas
• Esteja alerta a algumas situações

PILAR 1: maturidade de software

Ao longo do ano, a Ubistart chega a conversar com uma média de 600 empresas, a fim de entender seus desafios, oportunidades e projetos. Dessa forma, conseguimos diagnosticar que o pilar principal para o insucesso de um projeto é o potencial cliente não ter maturidade de desenvolvimento de software.

O que, para nós, é perfeitamente compreensível, afinal, não podemos exigir de diretores, administradores, empreendedores e responsáveis de áreas que saibam de algo super complexo, como o desenvolvimento de projetos de software. 

Porém, paralelo a esse entendimento, o nosso maior desafio é mostrar para as empresas que, para passar um orçamento de software, não bastam 2, 3 ou 4 interações em reuniões agendadas.

Para que a informação seja o mais precisa possível, precisamos nos debruçar em um planejamento de horas, construção de layout e entendimento de integrações com ferramentas externas.

Mesmo assim, em nossa experiência, quando explicamos isso para as empresas, grande parte delas espera um orçamento rápido e contendo todos os cenários possíveis do escopo, inclusive aqueles que ainda não foram mapeados.

Isso se reflete também em empresas que desenvolvem produtos internos, em que preveem um planejamento de 4 a 6 meses mas, na prática, o prazo se estica porque não foram mapeados todos os cenários possíveis.

Nesse sentido, a pergunta a ser feita é: por que não foram mapeados? Bom, em grande parte, por dois motivos:

• Certas funcionalidades são entendidas de forma mais clara durante o processo de desenvolvimento, consequentemente, apresentando um grau maior de complexidade;
• Dependendo do projeto e do público para o qual ele vai ser aplicado, o escopo se torna “vivo” e muda de acordo com os testes feitos com os usuários nas primeiras entregas.

Em alguns projetos, passamos 3 meses planejando para que, dessa forma, possamos dar uma visão mais firme de escopo fechado, incluindo cronograma e orçamento. E é até curioso, porque quando é iniciada a etapa de desenvolvimento, a primeira solicitação do cliente é uma mudança de escopo.

Assim, não podemos nos frustrar por isso, pois já temos o entendimento de que a cultura de desenvolvimento de software não é suficiente para clarear esse cenário, diante da perspectiva do cliente. Isso faz parte do processo.

PILAR 2: processo

Existem diversas formas de desenvolver um projeto sob medida. Algumas são mais antigas, como cascata para escopo fechado ou entregas pequenas e rápidas com o uso do kanban. Outras são mais recentes, como a metodologia ágil, que utiliza o SCRUM.

Aqui, vamos nos concentrar em cada uma delas, trazendo a nossa percepção de acordo com o  momento da empresa.

Cascata para escopo fechado

O modelo de cascata pode ser considerado o mais clássico e que geralmente funciona para a maioria das corporações que já tem um histórico de contratação de software. Neste caso, a fábrica de software busca entender todo o projeto para passar uma visão mais assertiva de cronograma e orçamento. 

Neste tipo de modelo, há um alto risco de atrasos, pois, quanto maior o escopo do projeto, mais incertezas haverá pelo caminho. Por conta disso, quando trabalhamos com escopo fechado aqui na Ubistart, estabelecemos limites de orçamento e um processo rígido de planejamento de requisitos. Tudo para não frustrar nossos clientes, fazendo com que não voltem mais.

O modelo cascata é muito utilizado no ramo automotivo, afinal, não se entrega um carro para o mercado de forma parcial. Mas, as empresas de software estão se convencendo cada vez mais que, amarrar escopos complexos em contratos, é ruim para ambas as partes.

Em situações como essa, tanto  a empresa contratante perde a oportunidade de acompanhar a evolução do projeto, com melhorias, quanto  a empresa contratada tem obrigação de ser precisa e inflexível com mudanças.

Alocação de time e o uso do Kanban para entregas cadenciadas

Essa forma de trabalho é muito utilizada em processos mais rápidos de desenvolvimento ou quando a fábrica de software não quer seguir necessariamente pela metodologia ágil. 

Para empresas que precisam de mais agilidade no desenvolvimento do projeto  e utilizam listas das demandas a serem feitas, a fim de finalizá-las em um prazo mais curto, o Kanban é a opção mais indicada.

Porém, quando falamos de um processo mais avançado de desenvolvimento, devido a complexidade da demanda, o kanban acaba sendo muito simplista. Um exemplo disso é o desenvolvimento de aplicativos e plataformas que envolvem de 4 a 6 meses de desenvolvimento.

Com base nisso, podemos concluir que o Kanban tem o seu uso mais direcionado para suporte, melhorias pontuais ou ajustes finos. Já para desenvolvimento de software com uma equipe multidisciplinar, ele pode não ser a melhor saída. 

Metodologia Ágil na alocação de time com um objetivo macro

Agora vamos falar da mais famosa e desejada das metodologias. No entanto, aceitar essa metodologia com os braços abertos não é muito comum em uma cultura de software mais tradicional.

Se pararmos pra pensar, qual empresa ou diretor que está disposto a assinar um cheque em branco para sua equipe de desenvolvimento ou fornecedor de software? Ou não ter prazos concretos de quando terá o seu projeto pronto?

Bem, de certo, esta é uma situação sensível e que deve envolver conversas transparentes com o cliente, além de uma análise cuidadosa de todos os cenários, feita por ambas as partes.

A metodologia ágil, por essência, trabalha com um objetivo a ser alcançado em um período maior, que pode ir de 4 a 12 meses, fazendo entregas a cada duas semanas , que são denominadas sprints.

Somado a isso, também há uma equipe super capacitada, formada por gestores de projetos, analistas de requisitos, designers UX/UI, testers, desenvolvedores, scrum master e POs. Ainda assim, este time de peso, se direcionado para um objetivo claro, poderá dar o seu melhor, mas nunca alcançar a meta da empresa.

Aqui na Ubistat, a metodologia ágil vem crescendo muito, pois apresentamos para os nossos clientes que ela pode ser poderosa para ajustes de prioridades, testes antes da solução total e acompanhamento do cliente. Isso tudo, certamente, se estiver alinhado a um objetivo claro.

No entanto, a empresa que está disposta a utilizar a metodologia ágil, precisa entender que não existe um escopo escrito em pedra, diferente do escopo fechado onde um super planejamento é feito com antecedência. 

Analisando tudo isso, não é atoa que, para iniciar a etapa de desenvolvimento por escopo fechado, aqui na Ubistart, podemos levar de 3 a 5 meses, enquanto a metodologia ágil já inicia em 1 mês.

PILAR 3: time multidisciplinar

Quando estamos amadurecendo a cultura de desenvolvimento do cliente, é muito comum escutarmos a seguinte pergunta:

“Então, não dá para contratar apenas o desenvolvedor em vez de todo esse time?”

Isso costuma acontecer bastante e nós entendemos, pois ele não tem a obrigação de saber contratar software. Porém, nós, como consultora de software, temos a obrigação de orientá-lo sobre qual é o melhor caminho.

A pergunta acima é comum porque, à primeira vista, como diz o ditado popular, parece que “é muito cacique para pouco índio”. Porém, em vez de trabalhar apenas com o desenvolvedor, explicamos a importância do time complementar como mostraremos abaixo:

• Analista de negócios: faz um mapeamento  das regras e é especializado em falar a linguagem de negócios aliada à tecnologia;
• Tech Leader: é um profissional de desenvolvimento mais sênior, que acompanha tanto a qualidade quanto tira dúvidas dos desenvolvedores;
• Designer UX/UI: é alguém especializado em acompanhar comportamentos de uso e propor a usabilidade certa para a aplicação, além de construir telas que podem ser aprovadas antes mesmo do desenvolvimento;
• Analista de testes: a missão desse profissional é achar erros na plataforma. Este papel é fundamental, visto que os demais profissionais estão “viciados” no uso da aplicação, impedindo que visualizem certos erros. Por isso, o analista de testes entra com processos de uso para quebrar a plataforma e evitar que o usuário encontre esses problemas.
• Gestor de projeto (scrum master): esse profissional é responsável pelo bom andamento do projeto, além de tirar impeditivos da frente do time, proporcionando também um bom relacionamento com o PO do cliente;
• Desenvolvedores: podemos ter desenvolvedores só para a parte visual web, para regras de negócio, aplicativos e até infra-estrutura.

Ou seja, um time multidisciplinar traz qualidade e seriedade de desenvolvimento na entrega do projeto. Quando colocamos um único profissional de desenvolvimento para ser responsável por projetos estratégicos da empresa, estamos depositando nele todo o peso da gestão e outras responsabilidades. No nosso entendimento, tudo tem seu momento:

• Demandas pontuais e únicas: um profissional de desenvolvimento pode ajudar, sim;
• Demandas complexas e longas: um time multidisciplinar é fundamental para o sucesso do projeto.

PILAR 4: alinhamento de expectativas

Há mais uma solicitação que acontece com bastante frequência:

“Pessoal, precisamos desse projeto entregue em 4 meses, dobra o time de desenvolvimento e pronto!”

Para que você entenda, vamos usar uma analogia que ilustra esse cenário muito bem:

Pegue um frango que deve ser assado em 3 horas a 150ºC e coloque ele para assar em 1 hora a 300ºC. O que vai acontecer? Será que aumentar a potência vai fazer o frango ficar delicioso por dentro e por fora? Sabemos que não! No final, o frango ainda estará cru por dentro e tostado por fora.

Nesse sentido, podemos identificar que certas coisas não podem ser resolvidas simplesmente aumentando sua capacidade para entregar mais rápido. E o software é uma delas. 

Em alguns projetos, trazer um desenvolvedor a mais aumenta o prazo, ao invés de diminuir. Porque, no final, um profissional tem que passar o conhecimento  para o outro e ainda há uma curva de aprendizado.

Por isso, é preciso tomar cuidado quando for pensar na possibilidade de aumentar o número de profissionais como uma estratégia para acelerar o processo. Todo projeto exige um tempo de maturidade específico.

Assim, podemos ver que este pilar está muito conectado com a maturidade de software. Pois, quando você está entrando nessa jornada de desenvolvimento, parece que as coisas são mais simples e rápidas do que realmente são.

Dessa forma, aqui na Ubistart sempre orientamos os clientes sobre prazos estipulados antes de termos um conhecimento claro do escopo. Por exemplo, 2 meses é um prazo muito curto para iniciar plataformas complexas do zero.

Além disso, é preciso estar atento a valores muito acessíveis, comparados ao que é cobrado por grandes empresas. Neste mercado, quando a empresa cobra mais caro não é porque ela está superfaturando, e sim porque durante a sua jornada, ela entendeu quanto tempo é necessário para viabilizar o projeto.

Partindo desse entendimento, podemos definir três desejos que sempre se colidem:

• Quero pagar mais barato
• Quero receber rápido 
• Quero qualidade

Normalmente, se a empresa escolhe o primeiro, a qualidade certamente será afetada. Se escolher o segundo, a probabilidade de não receber algo dentro do prazo é alta, pois como comentamos, existe um prazo mínimo de construção. E por fim, qualidade é o que sempre indicamos, pois logo ali na frente, a solução poderá ser continuada e ser escalável.

Esteja alerta a algumas situações

Por fim, é preciso estar atento a alguns alertas que sempre trazemos para empresas que estão preocupadas com o atendimento do prazo e investimentos esperados. Confira abaixo:

• Se é sua primeira jornada de contratação de software sob demanda, olhe o portfólio da empresa, e solicite uma conversa;
• Cuidado com promessas de prazos firmes quando a empresa teve pouco tempo para entender o projeto. Aqui, na Ubistart, às vezes usamos 100h para entender um projeto e conseguir passar um prazo e orçamento firme. Reuniões de 2 a 10h totais não são suficientes para um projeto completo que custará mais de 200 mil;
• Quer segurança? A opção é o escopo fechado (cascata). Se você quer flexibilidade, o caminho é a Metodologia ágil. Ainda assim, não tente ter segurança de prazo e valores querendo ter flexibilidade de mudança durante o processo. A metodologia ágil é ideal para inovação, projetos que mudam durante a construção. Já o escopo fechado é para empresas que têm certeza do que desejam construir e sabem que não vão mudar de ideia durante o processo;
• Um desenvolvedor não é um herói que irá resolver sua vida. É importante entender se você quer “arrumar o piso da cozinha” ou “construir uma casa do zero”, pois, se for construir uma casa do zero, você precisa de mais especialistas;
• Se você quer um orçamento rápido para fazer comparações entre empresas, é possível que você só se frustre, pois terá orçamentos muito variados e algumas empresas vão comunicar que não trabalham assim. Projetos complexos de software estão mais para uma relação de confiança entre empresas do que comparar com a mais barata ou mais rápida;
• O resultado final bem feito, barato e rápido é para um produto pronto. Geralmente, projetos de software são demorados e com um investimento alto, por isso precisa ser feito com bastante cautela e isso acontece quando se escolhe um bom parceiro.

É claro que podem surgir algumas dúvidas após a leitura deste artigo. Neste caso, você pode entrar em contato conosco e esclarecer tudo que achar necessário. É só clicar aqui e teremos o prazer de entender seu desafio apoiá-lo no que for preciso.