> ## Content Index > Fetch the complete content index at: https://productoversee.com/llms.txt > Use this file to discover other available public pages before exploring further. # 4 erros que aprendi como PM ao lidar com refactoring - URL: https://productoversee.com/blog/4-erros-que-aprendi-como-pm-ao-lidar-com-refactoring/ - Published: 2023-01-19T10:45:38.000Z - Updated: 2023-01-19T10:45:46.000Z - Description: Será que o PM é o profissional apropriado para liderar mudança de código no produto? Acho que não… - Author: Tiago Ferreira - Tags: Desenvolvimento, #blog, Carreira, Opinião ### Antes, o conceito. Segundo o ChatGPT*:* > *Refactoring é o processo de alterar a estrutura interna de um código sem mudar sua funcionalidade externa. Isso pode ser feito por várias razões, como tornar o código mais legível, mais fácil de manter ou mais eficiente. Refactoring é uma prática importante em desenvolvimento de software, pois ajuda a manter o código limpo e organizado, o que pode tornar mais fácil adicionar novas funcionalidades e corrigir erros.* Se você já tiver se deparado com o termo *refactoring*, muito provavelmente deve ter sentido arrepios. Isso porque se trata de reestruturação de código, algo que muitas empresas, principalmente *startups*, uma hora ou outra acabam precisando. É fácil entender o motivo: digamos que uma *startup* tivesse que validar um produto rapidamente no mercado. Para isso, ela pode ter partido de uma aplicação *low-code* ou simplesmente partido de uma API, ou biblioteca básica de JavaScript, por exemplo. Com a necessidade de justificar aporte, o produto foi sendo moldado a partir de uma estrutura pouco escalável. Resultado? Vai chegar uma hora que a aplicação ficará pesada, com baixa performance ou até mesmo limitada a inovações. Grandes empresas também passam por problemas semelhantes, seja na hora de criar um produto para ampliação do portfólio, para adequar produtos adquiridos em sua estratégia de M&A ou para dar escalabilidade para algo que já tenha sido validado. Sendo bem simplista, *refactoring* deveria ser uma preocupação apenas do time de Tecnologia. Mas, como todo produto ou serviço digital é geralmente construído a partir de código, toda e qualquer iniciativa de *refactoring* impacta o seu produto. A seguir, trago alguns erros e aprendizados que tive lidando com o tema *refactoring* como Product Manager. ## 1) Achar que produto pode liderar um *refactoring* Mudança de código deve ser feita e liderada pelo time de Tecnologia. O que acontece é que, em muitas estruturas, não existe uma distinção clara entre produto e tecnologia. Já vi acontecer casos de conflitos de interesse: um se preocupa mais com segurança, outro em métricas de negócio e, por fim, com receio de um desdobramento conflituoso dessas estratégias, as coisas não ficam claras para o time (produto e engenharia). Em busca de ter algum tipo de destaque, o Product Manager pode acabar tomando a frente da implementação de um projeto que certamente lhe dará visibilidade. Infelizmente, caí nessa armadilha ao me deparar com essa situação: liderando um time de Plataforma, reuni os engenheiros mais seniores da companhia, fiz diversos alinhamentos e estabelecemos um plano para estruturar o *refactoring* do produto. Porém, outras necessidades foram entrando no meio e, sem autonomia para tomadas de decisão nesse sentido, o *refactoring* foi sendo postergado. A boa notícia é que, em dado momento, tive a oportunidade de montar o time que cuidaria disso. Mas, até isso acontecer, muitos murros em ponta de faca, tentativas, acertos e erros consumiram os times envolvidos. Pior de tudo: perdemos tempo. E tempo, vocês sabem… ## 2) Juntar *refactoring* com *redesign* e *design system* *Refactoring* tem a ver com mudar código. *Redesign* tem a ver com propor ou melhorar a experiência - quando não estiver conectado com uma estratégia de *rebranding*, que é outro assunto. E *design system* tem o propósito de padronizar os componentes do produto, com objetivo de dar escala ao desenvolvimento e gerar unidade visual no produto como um todo. Enfim, sabendo da necessidade de refatorar o código, havia uma pressão dos executivos da companhia de melhoria de design. Bom, se tanta coisa tinha que mudar, por que não casar tudo de uma vez, não é mesmo? Por mais que tivesse alinhado essas duas iniciativas de uma só vez com o time executivo, a empresa não tinha os profissionais adequados no momento para essa condução. Além disso, o tempo era escasso, e o processo de *redesign* foi conduzido basicamente por meio de análise heurística - com pouca leitura, contextualização e debate dos dados gerados pelo produto. Por fim, o *refactoring* veio com uma nova proposta de *design*. Conduzimos testes de usabilidade e realizamos *rollout* de forma progressiva. Porém, alguns elogios do público não foram o suficiente para o valor esperado. Perdemos a oportunidade de fazer um diagnóstico crítico do produto para acelerar o *dual tracking* do *redesign* e do *refactoring.* Deu certo, mas gerou pouco valor. Faltou seguir uma das regras de ouro de Martin Fowler, que dedicou um livro inteiro a este assunto: > “*Melhorar o* design *depois que tiver escrito código”. É uma frase estranha. Pelo nosso entendimento atual de desenvolvimento de software, acreditamos que nós fazemos o design e, então, codamos. Um bom design vem antes, e o código vem em seguida. Ao longo do tempo, o código será modificado, e a integridade do sistema, além de sua estrutura, de acordo com aquele design, gradualmente desaparece. O código afunda lentamente da engenharia para hacking”.* Em resumo, primeiro você propõe uma mudança de design para, então, seguir com escrita de código. No contexto em que atuei, isso significaria postergar a prioridade da refatoração de código - e o motivo é tema do próximo tópico. ## 3) Falta de apoio da liderança Como o trabalho do *refactoring* não é tão visível, os alinhamentos e o *buy-in* da liderança eram complicados. Embora o CTO tivesse imposto a agenda do *refactoring*, as discussões com os demais líderes não dimensionaram a complexidade e a necessidade de comprometimento dos times. Infelizmente, eram comuns discussões de cobrança para lidar com funcionalidades e desconfiança de diversos *stakeholders* executivos. Em busca de lidar com essa gangorra, fiz uma divisão das pessoas que deveriam atuar com refatoração de código e com novas funcionalidades - sem esquecer, claro, dos *bugs*. A cadência do time melhorou, mas a falta de envolvimento da liderança complicou bastante o processo. ## 4) Não ter uma medição tangível dos ganhos *Refactoring* é um trabalho a longo prazo: precisa de preparo dos líderes de engenharia, treinamento para os desenvolvedores, envolvimento do início ao fim dos *testers* e um longo processo de desenvolvimento - algo que pode facilmente levar 1 ano da concepção à entrega completa. Geralmente, prevê-se uma melhora na performance da aplicação e na redução do tempo de desenvolvimento. Mas, como fazer esse comparativo, se não acompanhávamos essas métricas à risca antes do *refactoring*? Embora o processo de *redesign* tenha sido concebido e executado com poucos recursos e pouco tempo, o *refactoring* exigiu um tempo maior. Além disso, faltou comprometer um engenheiro sênior da área de qualidade para acompanhar o processo do início ao fim. Como líder dessa iniciativa, não dei a devida importância em entender em detalhes o impacto do código legado no produto para além de métricas de performance. Por mais que tivéssemos separado instâncias e funcionalidades como fatiamento do *refactoring* como um todo, um longo trabalho foi feito, em detrimento de outras atividades que poderiam alavancar as métricas de negócio do produto nesse decorrer. ## Conclusão No contexto que trouxe para este artigo, era mandatório fazer *refactoring*. Mas, para isso, não é necessário o envolvimento de um PM. É um alinhamento do time técnico de Engenharia, envolvendo arquitetura, desenvolvimento e qualidade. Vale lembrar que o usuário final não está nem aí para o código - logo, o valor para o usuário final deveria ser refletido pelo menos em melhoria de performance. Isso aconteceu, claro, mas não conseguimos captar como isso se refletiu em tempo de desenvolvimento, agilidade nos *deploys*, entre outras métricas internas de produtividade. *Refactoring* é um tema importante. Empresas grandes e startups, em algum momento, terão que lidar com revisão de código. Para isso, porém, é necessário que a liderança executiva de Engenharia conduza esse processo do início ao fim, seja na orientação aos Tech Managers, com a construção de um time técnico focado nessa iniciativa, com o *buy-in* da liderança e, principalmente, com clareza de onde se está e para onde se quer chegar. Todo e qualquer produto é impactado por uma refatoração de código. Porém, isso precisa ser debatido e priorizado a nível estratégico, com protagonismo do time técnico e métricas apropriadas de acompanhamento e evolução. ## Referências - [Livro: Refatoração: Aperfeiçoando o Design de Códigos Existentes (Martin Fowler)](https://www.amazon.com.br/Refatora%C3%A7%C3%A3o-Aperfei%C3%A7oando-Design-C%C3%B3digos-Existentes/dp/8575227246/ref=sr%5F1%5F5?crid=3GT5SC68KHPFE&keywords=refactoring+martin+fowler&qid=1673355479&sprefix=refac%2Caps%2C233&sr=8-5&ref=productoversee.com) - [Artigo: Code Refactoring Best Practices: When (and When Not) to Do It (Altexsoft)](https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/?ref=productoversee.com) - [Artigo: Code Refactoring: Meaning, Benefits and Best Practices (Mad Devs)](https://maddevs.io/blog/code-refactoring/?ref=productoversee.com)