Como estruturei o time de produto dentro da TOTVS

Atualmente trabalho na empresa TOTVS, no segmento de hospitalidade, e vou compartilhar um cenário bem interessante de como o nosso time de engenharia/produto está funcionando. Comecei em um cenário dentro de um projeto tendo apenas cinco Totvers, mas que depois de um tempo se tornaram trinta e seis Totvers (Totver é o nome adotado pela empresa para os colaboradores). Neste texto vou contar um pouco de como esse crescimento foi escalado.

Proporção do time

Temos duas tribos aqui na TOTVS do Rio de Janeiro, no segmento de Hospitalidade. Uma delas é chamada de Frontoffice e a outra de Backoffice. Esse texto vai ser focado apenas na tribo Frontoffice, pois é a tribo em que atuo.

Como comentei no início, os trinta e seis Totvers são relacionados somente à parte de inovação da tribo Frontoffice, porque temos mais nove Totvers trabalhando no produto legado.

Divisão dos times

Hoje somos divididos em cinco squads. Seguem os nomes das squads e o propósito macro de cada uma delas:

BOX (Booking Organize eXperience): esta squad é responsável pela gestão de reservas dos nossos produtos, desde a parte da distribuição até a operacional. Em outras palavras, desde as reservas que saem dos channels (booking.com, decolar.com…) até a chegada delas no sistema de gestão do hotel.

FUX (Focus User eXperience): esta squad é responsável por garantir a melhor experiência para o usuário em todos os nossos produtos. Eles são focados em melhorar a experiência, por garantir uma melhor comunicação dos nossos clientes com os nossos produtos.

Underground: esta squad é responsável pela gestão financeira dos nossos produtos. Falou em dinheiro, orçamento, tarifas, valores, é com essa squad.

CSI (Code Solution Intelligence): esta squad é responsável pela arquitetura do produto, por aplicar soluções inovadoras, dar ideias inovadoras e também por cuidar de produtos internos.

VHF (Visual Hotal Front): esta squad é a responsável por manter o nosso produto legado que sustenta o nosso negócio, segmento e toda a equipe de inovação.

Qual é o sentido dessas divisões?

Quero destacar apenas dois pontos para explicar essas divisões que foram feitas:

Primeiro ponto que quero destacar é a nossa divisão por responsabilidades e não por produto. Com exceção da squad VHF que cuida do produto legado da empresa, as outras squads não possuem um produto específico para elas. Elas possuem responsabilidades que cruzam diversos produtos da empresa.

Esse modelo que implementamos têm o intuito de:

• Melhorar a comunicação entre o time de negócio. A ideia é que qualquer decisão que vá ser tomada na estratégia do produto, ela necessariamente precisa ser alinhada com todos os Product Managers de cada squad;
• Compartilhar conhecimento de todos os nossos produtos para todos os Totvers de todas as squads;

Segundo ponto é a squad CSI. Ela foi formada para facilitar o caminho das outras squads no desenvolvimento de novas funcionalidades e pensar em novas soluções para o negócio, além de melhorar e cuidar da arquitetura dos produtos.

Qual a necessidade disso? Não seria melhor todos cuidarem da arquitetura e todos pensarem em novas soluções para o negócio? Sim! Correto, todos realmente precisam pensar em novas soluções, cuidar da arquitetura, entre outras coisas, mas é sempre bom ter alguém responsável por isso.

É aquela velha história, se é de todo mundo, não é de ninguém. Por isso, a decisão de ter um time focado nisso. Não quer dizer que só esse time faça isso. De jeito nenhum! É apenas para ter alguém com essa responsabilidade, corresponder sobre o assunto e direcionar.

E se tornou muito mais fácil de sair ideias novas, soluções inovadoras de um time que não está na correria das entregas de negócio que sempre possuem prazos apertados. Essa foi a necessidade de criar esse time, além de desafogar nossa arquitetura para os produtos novos não ser tornarem legado.

Estrutura das squads

Cada squad possui aproximadamente um Product Manager, UX, Analista de qualidade e engenheiros de sistema. A quantidade de cargos (UX, QA, DEV) dentro das squads é atribuído de acordo com a necessidade dela.

Somente a squad CSI é que não possui UX, Analista de qualidade e Product Manager. Quem basicamente faz o papel de organizar o backlog e as tarefas do CSI é o Coordenador de desenvolvimento. Uma curiosidade boa de explorar é que o Backlog do CSI tem contribuição de todos os engenheiros de todas as squads também.

Conclusão

Crescer é bom. Crescer organizadamente é melhor ainda.

Hoje a palavra exponencial é muito comum no nosso cotidiano e isso é bom demais!

Essa exponencialidade no crescimento do tamanho da organização, precisa de muito cuidado para a empresa não inflar de cargos que acabam entrando em conflitos em suas funções e a referência de liderança seja perdida. Acredito que todo crescimento deve ser observado, desenhado e melhorado.

Antes de formar novos times, eles precisam ter propósitos. Antes de realizar contratações de novos funcionários, precisam estar desenhados dentro de todo o cenário que já existe e nunca desconsiderar o pilar da liderança que essas novas contratações vão fazer parte.

Com isso, finalizo este texto. Mostrei como estamos fazendo por aqui. Talvez não se aplique ao cenário do seu negócio, mas espero que tenha te inspirado em algum detalhe para contribuir com novas ideias onde você está.