O que eu aprendi quando mudei da área de Customer Success para Desenvolvimento

A melhor coisa que eu já fiz foi mudar a área de Suporte da SocialBase de dentro de Customer Success (CS) para a área de Desenvolvimento.

A área de CS, por ser bastante relacional e ter muito contato com o cliente, deve se preocupar com não mascarar a forma como o time de Desenvolvimento trabalha.

Deixa eu explicar desde o começo.

Entrei na área técnica, e agora?

Eu não sou programadora, não tenho conhecimento técnico em desenvolvimento, sou formada em Administração e apaixonada por atendimento ao cliente. Costumo dizer que sou meio de exatas e meio humanas. Gosto de lógica, processos e cálculo, e tenho no coração o prazer por me relacionar, escrever e me comunicar.

Quando entrei na SocialBase, meu primeiro desafio foi estruturar a área de Suporte, mas não era só isso, o desafio era estruturar atendimento de suporte ao cliente dentro do time de desenvolvimento. Mas pera aí, como que eu, sem conhecimento técnico, estruturaria um processo de suporte na área de tecnologia?

Confesso que no começo eu fiquei bastante perdida até começar a aprender alguns termos bastante novos (e estranhos). Quando entendi o que era um deploy, uma branch e um rollback, eu comecei a compreender um pouco a lógica de desenvolvimento e os processos da área. Mas ainda assim, por eu possuir um perfil mais estratégico e processual, e nada técnico, não fazia muito sentido eu ficar no time de desenvolvedores, embora eu achasse interessante participar das plannings, dailys e retros.

Foi então que junto da diretoria da empresa, decidimos que, por conta do meu perfil mais relacional, processual e estratégico, faríamos uma mudança do Suporte. Com isso, com pouco mais de 5 ou 6 meses, eu e a área de Suporte fomos movidos para o CS, e foi onde eu me senti em casa e bem mais confortável. Afinal, relacionamento interpessoal faz parte do dia a dia de qualquer um, até mesmo dos desenvolvedores (rs rs ♥).

O que eu construí dentro do time de CS?

Com o remanejamento do atendimento de Suporte para dentro do time de CS, eu criei todo o processo de atendimento via chamados e construímos as atribuições de cada subárea para que não houvessem divergências ou até mesmo retrabalho entre os membros da equipe. Falei um pouco sobre a diferença entre CS e Suporte nesse artigo que escrevi para o blog User Onboarding da Conpass.

É dentro da área de CS que entra a maioria das demandas e cobranças dos clientes, e coisas como “aquele botão ficariam bem melhor se fosse azul e no canto esquerdo”. E enquanto eu fui do Suporte dentro da área de CS, eu não entendia porque era tão difícil mudar a cor do botão e porque demorava tanto tempo. Confesso que eu julgava, achava que o time de desenvolvimento era mole e não se empenhava nas mesmas causas do CS e do Suporte em prol da satisfação do cliente. Eu cobrava prazos, eu pedia datas, eu queria atender o cliente do melhor modo que eu pudesse, mesmo que não dependesse de mim e sim do time de desenvolvimento e de todas aquelas cerimônias que eles denominavam metodologia ágil.

O problema estava em eu não entender onde ficava o ágil nisso tudo sendo que, qualquer coisa que o cliente sugerisse, reclamasse ou pedisse não era priorizado ou realizado. Lembro que na época adotamos a hashtag #PriorizaPO a fim de gerar um movimento de transformação que nos ajudasse a gerar satisfação para cliente no front de atendimento.

Uma paixão chamada Qualidade ♥

Nessa trajetória, ainda no time de CS atendendo no Suporte, devido aos processos que foram criados, acabei estabelecendo contato muito próximo com a área de Qualidade (QA), que ficava no time de desenvolvimento. Isso acabou tornando o Suporte um área de qualidade número dois, servindo como um “double check” de testes de correções e novas features.

No intuito de manter um alto nível de qualidade e entregar sempre da melhor forma, eu perdi as contas de quantas vezes impedimos uma publicação de nova versão, pensando na experiência dos clientes só porque estávamos inseridas no processo de qualidade. Dessa forma eu comecei a aprender uma série de fluxos e processos de desenvolvimento e entender um pouco melhor a complexidade por trás da infraestrutura, front-end e back-end de um software.

A medida que fui me familiarizando com a lógica por trás de tudo isso, mudar a cor do botão e coloca-lo na esquerda deixou de ser “SÓ” isso e passou a ser mais complexo do que parecia.

Ao longo do tempo, conforme eu ia aprendendo nesse pareamento com o QA, eu fui aos poucos obrigada a parar de usar discursos como “mas é só mudar a cor”, “mas é tão simples, é só fazer o clique funcionar”, “porque não muda só o e-mail dele”, “me passa um prazo de conclusão dessa nova feature”, etc.

Quando comecei a pensar como um dev

Entre mudanças e transformações na empresa, ficamos um período sem uma área de Qualidade definida. Eu ajudava sempre que precisavam e me preocupava em garantir que o mínimo de erros fosse publicado e que a experiência dos clientes com novas features seria positiva. Foi quando o gerente de tecnologia na época me ofereceu o desafio de continuar tocando o Suporte e estruturar uma nova área de Qualidade dentro do time de desenvolvimento.

Área essa, que tecnicamente eu não dominava nada. Mais uma vez a pergunta: o que eu estou fazendo aqui?

Foi quando eu achei a resposta: era a oportunidade que eu tinha de entender e aprender sobre mais um tema/área. Comecei a estudar, conversar com pessoas que eram da área, que me ajudaram profundamente a chegar no MVP atual. Sabemos que pode não ser perfeito, mas ele nos atende e permite garantir a qualidade desejada do nosso sistema.

Opa! Voltamos a estaca zero lá do começo deste artigo. Movemos o Suporte, um time de “tecnicamente” 2 pessoas, para a área de desenvolvimento novamente.

O que os desenvolvedores me ensinaram?

Nesse turbulento percurso, além de continuar no Suporte, eu ia descobrindo que (1) por trás do sistema existe uma estrutura complexa. E a medida que o tempo ia passando e os problemas surgindo, conforme eu ia buscando resolvê-los, eu ia aprendendo.

Outro ponto interessante foi a aproximação com o time de Produto. Ajudar a conceber, validar e testar as ideias para melhorias me trouxe uma noção (lógica) de usabilidade e experiência muito maior, o que me fez entender que (2) nem tudo que o cliente sugere como uma solução, vai resolver o problema dele de fato e que (3) às vezes o problema nem existe e nosso produto já resolve a dor dele, basta mostrar para ele como fazer.

Eu estou muito acostumada a ver empresas reclamando da baixa qualidade na relação dos times de CS e Produto. E eu descobri que isso só acontece porque (4) quando um, desconhece o terreno do outro, é fácil apontar o dedo e julgar a complexidade do trabalho de cada um. Então, (5) estar mais familiarizado com a rotina do outro time/área, mesmo que um mínimo de entendimento básico lógico do fluxo de trabalho, faz muita diferença.

(6) O senso de urgência muda, e a forma de se relacionar com o time e com o cliente também. Acredito que (7) isso aumenta a transparência, segurança e autonomia na hora de tomar decisões difíceis, por exemplo, quando o cliente quer algo a qualquer custo e não é possível porque nosso padrão de infraestrutura utilizado não o atende, a forma de argumentar fica mais consistente. (8) Tudo o que for conversado e bem argumentado, estratégica ou tecnicamente, fica mais fácil de resolver entre os times e com o cliente.
A melhor coisa que me aconteceu na SocialBase foi ter migrado da área de CS para área de Desenvolvimento com Suporte e estruturar o MVP de Qualidade, porque (9) adquiri segurança.

Quando uma pessoa reconhece seu trabalho como importante, útil e legítimo, ela passa a ver sentido em sua função e, consequentemente, se sente mais motivada e desempenha melhor seu papel.

(10) Entender o emaranhado de estruturas por trás de um software fez muita diferença no meu trabalho, pois eu me relacionava diretamente com o cliente no Suporte, e esses aprendizados me tornaram mais firme e segura ao mostrar que eu dominava o assunto.

Mas isso não é orgânico, dificilmente vai acontecer naturalmente. É pouco provável um desenvolvedor tocar no seu ombro e dizer “vem cá que quero te ensinar uma coisa”. (11) É preciso ter iniciativa e interesse em aprender que vai ter alguém para te ensinar. E acreditem, quando tudo começa a fazer sentido é como fazer um strike no boliche ou alcançar o nirvana na meditação, é recompensador, é sério.

Quando encontramos paixão pela atividade que executamos, qualquer obstáculo se torna propulsor para resolução de problemas, além de proporcionar aprendizado e desenvolvimento pessoal e profissional.