Sem textos longos (pois sabemos que seu tempo é importante), mas é importante dizer que, além de um processo transparente, buscamos aplicar as melhores práticas no desenvolvimento de um software. Valorizamos o Manifesto Ágil e principalmente o seguinte valor: Colaboração com o Cliente (você) mais que negociação de contratos. (Saiba mais sobre metodologias ágeis, clicando aqui).
Basicamente, trabalhamos com dois tipos de projetos:
Lembre-se que estamos falando de desenvolvimento, não de infraestrutura (hospedagem/domínio) ou suporte. Estes são serviços que não estão relacionados diretamente ao processo de desenvolvimento de software que aplicamos.
Neste artigo também não vamos discutir qual seria o melhor para o seu negócio. Se deseja conhecer mais sobre a metodologia, entre em contato através de nosso canal de relacionamento, que prontamente iremos lhe atender.
O importante é entender e não ficar com dúvidas, pois somos aptos há um processo transparente.
É um projeto que têm fim! A entrega ágil e com qualidade, é nosso interesse comum aqui. Como a gente faz isto?
Passo 1: Nossa equipe de UX desenvolve um layout e o cliente aprova (através do Slack);
Passo 2: Chega ao nosso desenvolvimento um layout, com fontes, elementos, cores, brieffing e manual de identidade visual do cliente;
Passo 3: No time, haverá um desenvolvedor que será responsável pelo seu projeto. Este possuí responsabilidades que são (em ordem de prioridade): 1) Honrar o layout aprovado pelo cliente; 2) Realizar testes, entregando qualidade;
Passo 4: Existe um tempo para que o(s) desenvolvedor(es) transforme(m) o layout aprovado em código e efetue testes. Quando finalizar, o desenvolvedor responsável irá disponibilizar um link do projeto para que o cliente possa testar. Chamamos isso de ‘testes de aceitação’. Após o cliente possui um prazo de 14 dias corridos para elencar quaisquer inconsistência, dúvidas e sugestões do projeto;
Passo 5: Durante os testes de aceitação, esporadicamente o desenvolvedor irá aplicar as devidas correções e realizar novamente os testes (garantindo que sua correção/adaptação não quebrou/danificou o restante). É nossa obrigação atender pelo menos 60% das solicitações de alteração/adaptação relatadas pelo cliente através do Slack;
Passo 6: O desenvolvedor responsável recebendo o OK antes dos 14 dias ou passado os 14 dias corridos, abrirá um ticket para que o suporte solicite autorização do cliente para disponibilizar o projeto no ar ou enviar o pacote;
Passo 7: O time de desenvolvimento será atribuído para outro projeto de escopo fechado ou aberto;
Diferente do escopo fechado, este é um projeto contínuo. Muitas vezes com a entrega de um MVP (Mínimo Produto Viável) e evoluído posteriormente. Escopo aberto é onde grandes projetos são construídos. Vamos ao passo a passo de como desenvolvemos projetos de escopo aberto:
Passo 1: Nossa equipe de UX desenvolve um layout e o cliente aprova (através do Slack);
Passo 2: Chega ao nosso desenvolvimento um layout, com fontes, elementos, cores, brieffing e manual de identidade visual do cliente;
Passo 3: No time, haverá um desenvolvedor que será responsável pelo seu projeto. Este possuí responsabilidades que são (em ordem de prioridade): 1) Honrar o layout aprovado pelo cliente; 2) Realizar testes, entregando qualidade;
Passo 4: Existe um tempo para que o(s) desenvolvedor(es) transforme(m) o layout aprovado em código e efetue testes. Quando finalizar, o desenvolvedor responsável irá disponibilizar um link do projeto para que o cliente possa testar. Chamamos isso de ‘testes de aceitação’. Após, o cliente possui um prazo de 14 dias corridos para elencar quaisquer inconsistência, dúvidas e sugestões do projeto;
Passo 5: Durante os testes de aceitação, esporadicamente o desenvolvedor irá aplicar as devidas correções e realizar novamente os testes (garantindo que sua correção/adaptação não quebrou/danificou o restante). É nossa obrigação atender pelo menos 50% das solicitações de alteração/adaptação relatadas pelo cliente através do Slack. Algumas vezes o desenvolvedor poderá tentar chegar a um consenso com o cliente para que a alteração seja feita após a entrega do MVP;
Passo 6: O desenvolvedor responsável recebendo o OK antes dos 14 dias ou passado os 14 dias corridos, abrirá um ticket para que o suporte solicite autorização do cliente para disponibilizar o projeto no ar ou enviar o pacote;
Passo 7: O time de desenvolvimento será atribuído para outro projeto de escopo fechado ou aberto;