Parece que foi ontem que eu estava passando pela fase de transição de carreira, consigo lembrar com exatidão a rotina de estudos que tinha na época, os milhares de currículos enviados, as mentorias realizadas, os retornos negativos em processos seletivos, a sensação de desânimo e a vontade de desistir.
Lembro ainda, a primeira vez que falei com o Bernard d Luna, em uma mentoria coletiva, nesse dia, eu estava trabalhando externo e no horário que iniciou estava me deslocando, saindo de uma agência para o inglês, não tive dúvidas, liguei o notebook dentro do Uber e iniciei uma bateria de perguntas mesmo com o barulho do trânsito.
Pois é caro leitor, não foi fácil chegar aqui, foi necessário muito esforço direcionado corretamente para o meu objetivo, mas também, não vou iludir você, confesso que as coisas não melhoraram depois que ingressei na área e por isso escrevi esse artigo.
Espero que meus erros te forneçam algum aprendizado ou que pelo menos confortem os corações ansiosos dos que iniciaram recentemente na área.
1- User stories
Sim, eu errei. E sei que você deve está pensando: Como assim? É tão fácil, existem milhões de dicas sobre isso, inclusive, acho que é uma das primeiras coisas que você estuda quando está na fase de transição, mas na prática a teoria é outra. Surgem várias dúvidas, como o tamanho, os critérios de aceite e além disso, a maturidade do time também impacta demais nessa construção.
Meus erros: Bem, na quebra das user stories, algumas ficaram enormes, outras separei front e back. Como consequência, os desenvolvedores passaram muito tempo para entregar 1 user story, travando o continuos delivery.
Aprendizados: Hoje quebro as user stories de acordo com a proposta de valor e com o racional de entrega incremental, além disso, utilizo o BDD (Behavior Driven Development) trazendo os cenários de testes, o que auxilia muito os desenvolvedores a entenderem o comportamento esperado da funcionalidade.
2- Discovery
Discovery, o terror das pessoas de negócio e verdade seja dita, o terror também das pessoas de produto. Aposto que você acha que os problemas foram as técnicas, inclusive, já escrevi um artigo sobre discovery, respondendo várias perguntas sobre o assunto, mas não foi isso, , preste bem atenção, na cereja do bolo é o que vou falar em seguida caro leitor.
Meus erros: Não envolver suficientemente os stakeholders no discovery e não comunicar a evolução do processo. E sabe o problema que isso acarreta? Pontas soltas, riscos não mapeados anteriormente. O propósito do discovery é justamente mitigar riscos, então imagina só, protótipo pronto e aí você chega no refinamento e “descobre” que ainda precisa definir várias coisas para seguir com o delivery ou que vai precisar realizar mudanças porque não levou em consideração o impacto daquela iniciativa para determinada área.
Aprendizados: Envolver os stakeholders durante todo o processo, não precisa marcar trocentas reuniões, pode realizar alinhamentos assíncronos, é algo inclusive que tenho apostado bastante. Além disso, documento tudo em um único repositório, links, pesquisas, evidências e acrescento o status para que qualquer parte interessada tenha acesso sempre que precisar (com isso evito mais reuniões desnecessárias). Dessa forma, consigo mapear o máximo possível de riscos e impactos em determinadas áreas, mantenho os stakeholders atualizados, com expectativas alinhadas e ainda mantenho uma documentação que serve de histórico, caso precise consultar posteriormente o motivo daquela iniciativa.
3- Estimativa
Há uns meses atrás o Diego Eis publicou um artigo genial, sobre a responsabilidade das pessoas de produto na gestão de expectativa dos stakeholders sobre as estimativas, minha cabeça fritou e me identifiquei em vários trechos.
Meus erros: Depositar toda a responsabilidade da estimativa nos desenvolvedores e ser apenas a portadora dessa informação. E gostaria de deixar claro aqui que estou trazendo isso como um erro meu, em hipótese alguma estou criticando as estimativas dos desenvolvedores. Isso porque, para algo subir em produção, como dizemos, não tem apenas o tempo de desenvolvimento, existe também o tempo do processo, aprovações, existem ainda, imprevistos que surgem no meio do caminho. Então se um stakeholder questionar o tempo de entrega de uma iniciativa e você responder levando em consideração somente o tempo de desenvolvimento informado pelos desenvolvedores, você cometerá o mesmo erro que eu.
Aprendizados: Não importa a maturidade do seu time, tenha ferramentas para lhe auxiliar com estimativas. Alinhe com seu time prazos internos e considere prazos maiores levando em consideração os pontos descritos acima. Entender o capacity do seu time é muito importante também, visto que, com essa compreensão e quebrando histórias em tamanhos similares, você consegue transmitir rapidamente uma previsão de uma iniciativa.
Conclusão
Um ano atuando na área de produto, olho para esses erros e me pergunto como pude cometê-los? Mas compartilho eles sem medo, porque foram graças a eles que me tornei a profissional que sou hoje.
Poderia, inclusive, fazer um post de comemoração só relatando as minhas vitórias nesse período, mas cara, eu cresci muito mais com os meus erros do que com os meus acertos.
É isso, caro leitor, espero que você tenha aprendido algo com esse artigo, do meu lado, sigo ansiosa por viver novas experiências, me cobrando menos em relação a perfeição, mas ainda exigente pois me recuso a cometer os mesmos erros novamente.
