Quando se fala em desenvolvimento de produtos, algumas definições e conceitos surgem imediatamente em nossos pensamentos, como três telas com um monte de caracteres, letras e números. Dizem até que os desenvolvedores são taxados como loucos.
Apesar desses conceitos estarem associados ao desenvolvimento, na prática é um pouco diferente. O setor de desenvolvimento das empresas é formado, de modo geral, por um time ágil.
Você sabia que dentro desse time ágil os profissionais não desempenham somente um papel específico?
Ao pensarmos em setor de desenvolvimento, associamos a responsabilidade de desenvolver um produto através de uma linguagem de programação, porém, nem só de código se vive o mundo do desenvolvimento.
Equipe de desenvolvimento
Para um produto, novas funcionalidades, melhorias ou ajustes, diversos times de profissionais participam do processo e têm o seu papel igualmente importante para o desenvolvimento.
Você pode chamá-los como quiser: squads, times ou equipes. A nomenclatura utilizada não muda a formação desse setor, que é composta por profissionais de diversas funções: experiência de usuário, programador, analista de negócio, analista de requisito, product owner e head de produto. Cada um deles com um papel definido.
Quando falamos em agilidade no desenvolvimento, nos vem à cabeça a rapidez para desempenhar os processos. A agilidade não diz respeito a isso, mas sim a adaptações para executar com eficácia e trazer resultados e valor ao produto referido.
As práticas e cartilhas são muitas. Cada time deve entender as metodologias presentes no mercado e então adaptá-las à realidade da empresa.
Foi o que fizemos na IXC Soft, em nosso setor. Agrupamos um misto de metodologias que se enquadram em cada uma das realidades de nossos produtos.
Mas como vocês fazem isso na IXC Soft?
Trabalhar com tecnologia é uma coisa muito louca. Uma hora você está com tudo planejado, mas as alterações de escopo, de roadmap e mudanças nos times obrigam você a ser escalável, mutável e muito adaptativo.
No desenvolvimento da IXC isso não é diferente, estamos sempre buscando novas metodologias para que possamos ser cada vez mais ágeis (lembrando que não estou falando apenas de rapidez, mas sim de qualidade).
Atualmente no setor temos head de produto, product owner, analistas de experiência de usuário, analistas de requisitos, analistas de negócio e programadores.
Tá, mas que isso quer dizer?
Significa que temos um fluxo que envolve diversos times com apenas um propósito: entregar valor ao produto e ao cliente. Ou seja, deixarmos o cliente feliz!
Existem subtimes, formados dentro de times, que trabalham em cada um dos produtos.
Isso quer dizer que temos uma equipe responsável pelo módulo Inmap, uma pelo IXC Provedor, uma pelo Opa! Suite, uma pelo desenvolvimento de integrações de equipamentos, de monitoramento de redes e autenticação, e uma para Projetos do IXC Provedor.
Isso faz com que nossa equipe seja eficaz e tenha um olhar crítico voltado ao produto trabalhado.
Cada um desses times conta com product owner, analista de negócio, UX (experiência do usuário) e programadores.
Sabe a diferença do papel de cada um? Não? Eu te digo!
O Product Owner, ou PO, é responsável por entregar valor ao produto. É responsabilidade dele, ainda, priorizar as tarefas e os requisitos da implementação.
Já o Analista de Negócio é responsável por entender a demanda e o valor repassado já priorizado pelo PO e fazer uma análise criteriosa de como isso será implementado no sistema, prevendo novos tratamentos, manutenções futuras e também modulação de banco e estrutura de código.
Por sua vez, o UX é responsável por analisar como será a melhor prática de uso daquela funcionalidade: em quantos cliques podemos fazê-lo, quais os melhores formatos de uso em relação aos componentes (checkbox, múltipla seleção, estrutura de campo), nomenclatura de funcionalidades e afins. Em resumo, o que envolve a usabilidade.
Ao chegar na programação, é codificado, reanalisado e estruturado da melhor forma possível para a entrega final ao cliente.
Após isso, temos os testes feitos por usuários internos e também revistos pelo PO e UX.
Grande né? Pois é, depois do fluxo, todo a funcionalidade é entregue ao cliente.
Esse emaranhado de papéis torna o time multidisciplinar e o faz trabalhar com agilidade.
Não podemos esquecer de como esse fluxo é controlado. A metodologia técnica utilizada atualmente é o Kanban, mas não deixamos de adaptar alguns pontos-chave, assimilando-os às práticas da XP Investimentos.
Para apoio no controle de demandas e tarefas, utilizamos o Jira Software, que nos auxilia a manter o fluxo andando para as entregas.
Quando iniciamos o uso de metodologias ágeis, tínhamos como prática o Scrum. Mas lembra que falei de adaptação? Então, na maioria das equipes mantivemos algumas práticas como sprints e dailys. Sprint para que o time possa reavaliar um cartão, estimar e trocar experiências. E a daily com o objetivo reunir todos os membros do time (PO, programador, analista) e remover impedimentos, identificar problemas para, juntos, encontrar a solução. 🙂
As dailys são reuniões feitas no início da manhã que têm como principal objetivo remover impedimentos e alinhar o time para que todos conversem na mesma linguagem. É um momento destinado a falar de forma breve sobre a entrega do dia anterior e o dia atual.
Nossa, gente, quanta informação. Já acabou Jessica?
Não. Na verdade, não mesmo! O que precisamos ter em mente é que o desenvolvimento de um produto não envolve apenas um programador e um suporte. Temos uma preparação muito grande antes desse passo, que envolve planejar, levantar requisitos, priorizar, tomar decisões, analisar preços, métricas, escutas ativas, mercado, design, usuário… vai longe 🙂
E ainda existem muitos outros cargos/papéis sobre os quais podemos discorrer. Mas isso eu vou deixar pra próxima. 😀
Aline Fraporti | Product Manager
