Desenvolvimento por projetos ágeis x tradicionais

Confira a entrevista com o especialista Victor Alves, com carreira em desenvolvimento de softwares há 20 anos, tendo atuado internacionalmente na Magento, com formação pela UFSC, hoje executivo co-fundador da empresa Tech Seller W16.

Diferenciando um projeto de desenvolvimento em formato ágil e tradicional

O desenvolvimento de softwares requer a alocação de pessoas especializadas, e isso pode ser feito de diferentes formas. Uma empresa pode ter sua equipe interna de desenvolvimento, alocar profissionais terceirizados para atuarem em suas equipes ou contratarem equipes completas externas em empresas especializadas chamadas “software houses”. 

Para falar sobre esses últimos formatos, conversamos com Victor Alves, com carreira em desenvolvimento de softwares há 20 anos, tendo atuado internacionalmente na Magento, com formação pela UFSC, hoje executivo co-fundador da empresa Tech Seller W16. A empresa é sediada na região de Florianópolis e completa 10 anos em 2023.

Segundo Victor, a contratação de projetos de desenvolvimento junto a software houses pode ser feita segundo método tradicional ou ágil de desenvolvimento. As principais diferenças entre os dois formatos são:

Desenvolvimento Tradicional

• Tem detalhamento de requisitos e especificações do escopo
• Tem um prazo e cronograma definidos
• Tem um orçamento fechado, por escopo

Desenvolvimento Ágil

• Tem alocação de uma equipe que trabalha de forma evolutiva ao longo do tempo
• Os entregáveis têm uma definição macro, mas os detalhes são definidos no percurso
• Tem um orçamento definido em função do tempo, relacionado ao número de sprints (ou ciclos de desenvolvimento)

Quando optar pelo modelo Tradicional ou Ágil ao contratar uma software house?

A escolha de um projeto tradicional em geral se dá em situações onde o prazo e orçamento está bem definido e, sobretudo, quando o conhecimento do que se precisa construir está muito claro. É uma escolha comum quando um cliente busca conhecer e construir confiança junto a uma software house, estabelecendo um primeiro projeto pequeno ou piloto para experimentar a parceria.

Já a escolha por um projeto ágil tem maior aderência a situações de inovação e pesquisa e desenvolvimento, pautando o escopo na evolução das descobertas ao longo da jornada, com maior flexibilidade. A evolução do produto digital ou do software é algo contínuo, um modelo que absorve os aprendizados e feedbacks do time e dos clientes ao longo do caminho.

O grande desafio é garantir transparência na comunicação entre cliente e empresa fornecedora, pautando a escolha por um projeto no formato ágil na segurança que o método traz para a gestão, e não por um tema de “seguir uma moda”. O orçamento e estimativa de prazo existe no método, e o controle da evolução faz parte da dinâmica, que desdobra o projeto em “pequenos projetos”, em pequenos contratos nos planejamentos das sprints. O método mais usual para o modelo ágil segue o formato scrum, e seus rituais e plataformas de gestão ajudam a trazer gestão para a jornada.

Por outro lado, projetos tradicionais usualmente empregam metodologias no formato waterfall de planejamento, como as previstas nas teorias do PMBok.

O papel da equipe nos diferentes modelos de desenvolvimento

É prudente prever equipes dedicadas aos projetos de desenvolvimento, sejam eles em formato ágil ou tradicional. As equipes têm flexibilidade para variar entre um modelo ou outro a depender de sua alocação, e a chave para direcionar o rítmo do método está no gestor de cada projeto.

O gestor de projetos dem papel fundamental nos diferentes modelos de desenvolvimento. Nos projetos ágeis eles têm chapéus como de Agilista, Scrum Master ou PO. Cabe a esses profissionais dar cadência ao método em prática e promover a integração com a equipe técnica e o cliente. Num projeto ágil, seu papel é menos de comando e controle e mais de estímulo à colaboração. 

Uma dificuldade para esse profissional quando lidera projetos tradicionais é muitas vezes dizer não a boas ideias, quando elas chegam do time mas não estão no escopo, pois nem sempre o cliente entende o valor de uma change request. 

Além do gestor do projeto, o desenvolvedor também tem atuação um pouco diferente quando atua num projeto ágil. Cabe a ele muito mais espaço para propôr, trazer insights, colaborar e participar, o que nem sempre o profissional iniciante está preparado para fazer. Para essa prática é importante que o profissional tenha curiosidade e mindset aberto, interessando-se pela visão do cliente e pelo negócio, não apenas pela excelência técnica do que está desenvolvendo.

Para isso, as discussões sobre detalhamento de entregas trabalhadas em fases de Grooming são importantes não apenas para detalhar tecnicamente o que se espera construir mas para desenvolver a habilidade de aprofundar o entendimento do que se está construindo. É uma etapa interessante para promover a compreensão coletiva das definições, e algo que ocorre ao longo de toda a jornada ágil.

Dicas para que Tech Buyers colaborem para promover projetos mais exitosos

Por mais que a definição de sucesso dos projetos varie com cada caso, na maioria das vezes ele tem maior probabilidade com o envolvimento real do Tech Buyer ao longo da jornada. O acompanhamento próximo de uma pessoa de interlocução dentro da equipe da empresa cliente de uma software house faz bastante diferença para otimizar o alinhamento de expectativas, apoiar na solução de desafios e ajustar rotas.

Ao mesmo tempo, é importante que essa proximidade se dê nos rituais previstos na metodologia escolhida para o projeto, prevendo também espaços de liberdade para que a equipe da empresa parceira possa trabalhar com espaço criativo e dinâmicas nas quais já tenha hábito.

Cada projeto tem seu contexto, e em clientes maiores há stakeholders diferentes para participar dessas interações: times técnicos de arquitetura, desenvolvedores internos que já tenham os guidelines de desenvolvimento, o próprio cliente final, o gestor de negócios. O interlocutor pode mudar ao longo das etapas do projeto.

Já em empresas menores, o interlocutor usualmente é uma pessoa não técnica, e é importante que possa confiar na equipe técnica que está à frente do projeto junto à empresa parceira. Isso se dá, por exemplo, na escolha da linguagem ou tecnologia de desenvolvimento, que deve considerar não apenas o momento atual mas o futuro de sustentação da plataforma, avaliando investimento, disponibilidade de profissionais, etc.

Em todos os casos, é importante que os Buyers entendam o produto digital ou o software como uma solução viva, que precisa evoluir e se adaptar ao longo do tempo. Seja por requisitos do mercado, de novas legislações, de demandas de escalabilidade. É natural que se lance uma primeira versão inicial ainda com oportunidades de melhoria, conhecida como MVP, e se façam alterações e evoluções à medida que haja necessidade do negócio, equilibrando investimento e benefícios.

Diferenciais da W16 como Tech Seller de Desenvolvimento de Softwares

A W16 vem investindo muito nos últimos 10 anos em formação e desenvolvimento de profissionias. Sua excência está na geração de otimismo junto às pessoas, trazendo segurança aos Tech Buyers e engajamento e confiança junto ao time interno. Com isso em mente, foca-se em promover bons relacionamentos a cada interação humana, customizando as relações, trazendo boas decisões de tecnologia e equipe, promovendo feedbacks.

O Tech Buyer ideal para a empresa é aquele que valoriza a transparência e a colaboração, o aprendizado e o crescimento daqueles ali envolvidos. São Buyers que buscam excelência no processo e no resultado dos projetos. São clientes dispostos a participar ativamente ao longo da jornada em prol da colaboração pelo melhor resultado, de forma exigente e próxima.

Você acredita ser o Tech Buyer que dá o match perfeito com as soluções da W16?

Conheça mais sobre a empresa no Spotlight da Match<IT>.

Ou mapeie outros potenciais Tech Sellers que dão match com a sua demanda de forma gratuita em nossa plataforma.

Confira no vídeo a entrevista completa com Victor, da W16, em nosso Canal do Youtube.