Desenvolvimento de software é a única carreira em tecnologia? - LabeCast #03

Conheça quais são as principais profissões na área de tecnologia, além dos famosos Programador e Desenvolvedor de Software.

No terceiro episódio do LabeCast, Paula Arantes, Letícia Chijo e Rafael Miau conversam sobre suas atuações no mercado de tecnologia.

Entenda o que cada área executa dentro de um projeto de programação, o perfil de cada profissional, para você decidir qual carreira em tecnologia seguir.

Rafael Miau:

Oi. Meu nome é Miau, minha família me chama de Rafael e eu sou head de operações, aqui na Labenu.

Paula Arantes:

Oi, meu nome é Paula, também me chamam de Paulinha. Eu sou líder de dados aqui na Labenu.

Letícia Chjo:

Eu sou Letícia Chijo. Vamos para mais um episódio do LabeCast, o podcast oficial da Labenu.

[INTRO]

Chijo:

Hoje a gente está aqui então com a Paulinha e com o Miau, pra responder a uma pergunta que a gente recebe bastante que é quais são as outras carreiras que tem dentro da área de tecnologia? Então acho que a primeira pergunta é tem outras carreiras dentro da tecnologia?

Paula:

Sim! Próximo episódio.

Miau:

Com certeza.

Chijo:

E eu acho legal que nessa mesa, acho que todos nós sabemos programar, mas nenhum de nós trabalha com programação, você faz excel é quase. E eu queria que vocês contassem um pouquinho o que vocês estão fazendo hoje, o que vocês já fizeram aí.

Paula:

Sou engenheira de materiais de formação aparentemente nada a ver com tecnologia. Decidi migrar de carreira quando eu estava no final da graduação. Comecei como programadora e também trabalhava um pouquinho com análise de dados, no meu TCC, meu trabalho de formatura, foi com machine learning, aplicado em aço. Então eu consegui juntar um pouquinho das duas coisas. Depois de um tempo, eu fiquei como desenvolvedora e depois eu vim trabalhar aqui na Labenu. Aqui eu já fiz de tudo, fui instrutora,  fui do processo seletivo de estudantes. Depois liderei o time de CX e atualmente eu estou como líder da área de dados aqui na Labenu. Então é uma área de dentro da tecnologia, é mais voltada para dados.

Miau:

Sou formado como engenheiro eletricista. Nada a ver também com o que eu faço hoje. Comecei a minha carreira no mercado de trabalho, como Product Owner, a gente vai falar um pouquinho mais, depois sobre isso. Mas dentro da Labenu eu sempre assumi um papel quase que de, sei lá, zelador aqui da empresa. Então acho que a tecnologia sempre esteve presente no meu dia a dia, tanto no contexto de conversar com os meus amigos, conversar com quem estava trabalhando aqui, com os alunos e alunas que tinham.

Mas também no dia a dia de trabalho, mesmo não trabalhando de fato com tecnologia, eu utilizo ela muito como uma ferramenta. Então também passei pelo time de CX, por time de processo seletivo, time de vendas, time do administrativo, e todos eles eu acho que eu acabei usando um pouquinho de tecnologia e construindo uma carreira mesmo e em que eu consigo dizer que de fato a tecnologia está presente hoje em dia.

Chijo:

E eu já contei em episódios anteriores um pouquinho. Eu comecei trabalhando como programadora, mas agora aqui na Labenu, eu fui instrutora de programação, não estava programando diretamente, mas estava ensinando as pessoas, e agora eu estou aqui nessa área de criação de conteúdo, que também é conteúdo de programação, de tecnologia, mas uma outra forma e também um pouco indireta de fazer isso.

E acho que vocês citaram duas áreas legais: Dados e Product Owner. Vou começar com Miau, que eu já trabalhei com ele, ele já foi meu P.O., inclusive por um tempinho, para você contar o que faz um P.O.?

Miau:

P.O. é abreviação de product owner, que é o dono do produto, na tradução. Sei lá, acho que eu meio que isso.

Chijo:

Dono da bola.

Miau:

A gente brincava muito quando trabalhava como P.O., que eu trabalho era escrever card. Então que o é o card? Eu escrevia as tarefas e entregava para os devs, e eles tinham que fazer. E acho que, de maneira geral, bem simplificada, é um pouco isso. Você tem um projeto, você precisa ter uma equipe. Você precisa, de alguma forma, ajudar com que esse projeto tenha um andamento.

Mas acho que eu digo que hoje o principal desafio mesmo de uma carreira de P.O., é muito saber gerir bem as expectativas, não simplesmente com sua equipe, mas também com a empresa, com a área comercial mas também com os próprios clientes.

Eu acho que é muito um trabalho de gestão de expectativas mesmo, sabe? Tem um tempo determinado, tem coisas a serem feitas e muitas das vezes acho que todas as vezes, nunca sai exatamente como a gente planeja. Então, essa questão de gestão de expectativas é muito importante, mas de toda forma, no meu dia a dia de trabalho eu precisava minimamente entender o linguajar do dev, então saber como conversar com ele, saber como falar. Ele me falava de diversos termos e eu falava beleza. Mas esses termos significam o que?

Então, foi muito um aprendizado legal que eu tive de cada vez mais me inserir nesse contexto de desenvolvimento. Eu brinco com os meus amigos, são programadores que eu consigo ter conversas de três, quatro horas, só colocando buzzword, só colocando palavras dentro do mundo dos programadores.

Brincadeiras à parte, o trabalho de um P.O. é muito gerir bem as expectativas, não só gerir o projeto, mas gerir bem as expectativas com todo mundo que está envolvido nesse projeto. Então acho que é um pouquinho disso.

Chijo:

Eu acho que você fazia muito esse papel de ligar as diferentes áreas da empresa para fazer aquele projeto sair. Então, o dev teve um problema, teve que falar com o cliente, não é o dev que vai falar com o cliente. Passa pelo P.O., pelo comercial e tudo. Então são algumas etapas que você acaba juntando.

E eu acho que ter um pouquinho de conhecimento de programação, de tecnologia é interessante, para quem está nessa área. Mas não é assim absolutamente essencial saber programar, saber fazer as coisas.

Miau:

Com certeza, eu acho que eu tenho até uma filosofia que eu chamo de lei da exposição. Por mais que você muitas vezes não saiba nada, se você está exposto aquele cenário, você acaba absorvendo e acaba aprendendo cada vez mais.

Eu vou te dizer que ajuda bastante você entender minimamente algumas coisas de programação. Eu não sei programar de fato. Se me derem um código, uma linha de código, eu vou talvez demorar quatro horas para fazer alguma coisa que seja simples.

Mas eu entender o macro, como as coisas funcionam, me ajudava muito a entender a complexidade de tarefas também. Então, por exemplo, putz, tinha algum problema nesse mesmo cenário que você falou, algum problema que teve com dev, alguma coisa que descobriu que não daria para fazer. E não era o dev, principalmente, que ia lá e conversava com o cliente, e nem o dev que ia conversar com o resto da empresa.

Acho que era um papel do P.O., pelo menos no meu contexto que eu estava lá, fazer essa gestão e entender qual a gravidade de fato do problema. A gente tem alguma outra solução ou não? Qual a complexidade desse problema? Acho que entender o macro da tecnologia. Não vou nem colocar a programação, mas as tecnologias que a gente tava mexendo me ajudava muito a gerir bem as expectativas porque às vezes eu chegava com um problema que era complexo. Mas eu mesmo não tinha esse conhecimento e geria mal uma expectativa.

Eu falava: " isso aqui deu errado. Mas talvez a gente consiga na próxima semana soltar isso aqui para você". E, na verdade, pela falta de entendimento, no momento, você acabava gerando uma expectativa errada. E só batendo na tecla de que gerir uma expectativa errada faz parte do trabalho. Eu acho que você só vai aprender e vai entender cada vez mais. Estando dentro dessa lei da exposição, se expondo nesses cenários e abrindo a cabeça e perguntando e não levando essa dúvida pra casa. Acho que é um pouco disso.

Paula:

A gente, muitas vezes, antes de entrar para a área, tem uma visão de que pessoas que são programadoras, desenvolvedoras trabalham sozinhas ali, com fone de ouvido e codando. Mas acho que numa empresa quanto maior for a empresa, muitas dessas pessoas trabalham em equipes e com pessoas de várias áreas diferentes, que é o que muitas vezes se chama de squad você vai ter ali uma pessoa de produto, uma pessoa de design, uma pessoa às vezes de dados junto.

Acho que muito do papel do P.O. também é fazer a gestão entre as diferentes áreas dentro do Squad e também para fora com o cliente, com outras áreas, caso seja um produto interno. Então acho que do que eu conheci na minha carreira de pessoas que foram P.O., que é um trabalho que com certeza exige muita comunicação, um perfil muito comunicativo.

Então, sei lá, você está aí querendo entrar para a área de tecnologia, está estudando programação, mas também gosta dessa parte de comunicação. Às vezes tem alguma graduação nisso, tem interesse nisso, pode ser um caminho bem legal. E acho que também comentando um pouco mais de perfil. Tem que ser uma pessoa muito organizada, com um olhar mais estratégico sobre as coisas que acho que é uma coisa também que você vai desenvolvendo, mas que algumas pessoas às vezes já têm. Então, se você tem esse perfil, com certeza pode ser algo para se explorar.

E eu já vi pessoas de tecnologia migrando para essa área de produto. Então a pessoa era desenvolvedora antes e acaba migrando porque acha mais interessante ou faz mais sentido com o perfil dela. Então não é algo incomum, apesar de não ser necessário. Como você mesmo falou, Miau, de ter esse conhecimento de programação. Eu já vi acontecendo de pessoas que eram desenvolvedoras antes acabarem se tornando P.O., ou P.M. também que é Product Manager, também estar dentro dessa área de produto.

Chijo:

Até aqui no curso, a gente é um curso de programação bem focado em ensinar desenvolvimento web. Então a parte de front, de back,  e as pessoas fazem o curso e até a aprendi com faz site legal, mas gostei mais daquela parte de pensar em gerenciar o projeto e tal. Então a gente tem bastante aluno que sai e vai para essa área de produto. Ela é bem interessante. Ter conhecimento pode ser útil, mas isso não é obrigatório.

É uma coisa que você vai já ter desde o início essa bagagem para conversar com as pessoas. Então talvez seja um pouco mais fácil ali no início. Mas é o que Miau falou. É uma coisa muito de convivência. Você vai pegando, vai conversando com as pessoas vai entendendo os termos ali. Não precisa ter um conhecimento profundo, porque é pra isso que dev está ali, inclusive para conversar com P.O., explicar o que está acontecendo. E a gente está falando de uma carreira nova P.O. ou P.M., todas essas novas frentes de produto.

Miau:

É uma coisa muito nova, que o próprio desenvolvimento é novo. Quando a gente tá falando de produto, pessoas que estão olhando pra isso, é uma coisa muito nova. Então não tem muito de fato conhecimentos estruturados ou que você precisa ter, ou principais características, ou principais competências. Eu acho que, de certa forma, a gente, ainda no mercado brasileiro, está passando muito por essa questão de entender o que são esses cargos. Você vai entrar no lugar que você é chamado de P.O., mas na verdade faz um papel de P.M..

Na verdade, você entra como P.M. e faz o papel de papel de P.O. E assim existe essa diferença. A gente pode entrar ou não aqui a respeito dessas diferenças. Mas acho que o principal ponto é que é uma coisa nova no Brasil e que as pessoas estão precisando de alguém que consiga gerir bem expectativas. As empresas estão precisando de alguém que consiga gerenciar essa equipe de desenvolvedores que está cada vez mais crescendo aqui no Brasil.

E acho que todas as características que tanto a Chijo, quanto a Paulinha, falou, são bem válidas pra gente ter um pouco mais de olhar. A Chijo falou uma coisa que me chamou muito atenção, que no fim das contas, o "P" vem de produto, então é uma área de produto. E uma das coisas que eu fazia muito no dia a dia, também, de P.O., não é simplesmente gerenciar e conversar. Uma das atribuições era testar o produto e cara, acho que me deu a maior visão de produto com essa tarefa.

Por mais que seja uma das tarefas chatas, repetitivas, que eu tinha que pegar e testar a aplicação que os desenvolvedores e desenvolvedoras faziam. Me ajudou muito a ter um entendimento do produto como um todo, porque eu, sem saber muito de como fazia aquilo por trás, tentava fazer funções que eu mesmo tinha escrito. Então, sei lá esse botão precisa redirecionar para a próxima página e eu testava aquilo, mas não só testando aquilo.

Eu entendia, mas eu cliquei e não aconteceu nada. Era pra acontecer alguma coisa? Eu ficava levantando algumas dúvidas. Então isso foi me ajudando a ter também uma cabeça muito mais voltada para produto. Eu acho que é muito importante a gente entender não só o que a gente está codando nas linhas ali, mas por que, o que aquelas linhas vão fazer nesse projeto como um todo. Então eu gostei bastante dessa divisão que trouxe como produto, tecnologia.

Chijo:

Você falou uma coisa bem legal, que era dessa parte, de Q.A., que você fazia também, que não é o papel de um P.O. fazer isso, mas não tinha ninguém na empresa que fazia. Então você pegava muito essa parte de Q.A. também. Já teve vários cards meu que você voltou, rancorosa aqui, mas fala um pouquinho também de como essa parte de Q.A., que é a parte de quality assurance. A pessoa que está garantindo que aquilo que fez está com a qualidade que deveria ter.

Miau:

Acho que para falar sobre Q.A., a gente tem que voltar desde o momento em que o card é criado, eu estava comentando um pouquinho disso antes. Eu acho que o principal ponto do que eu falo que o principal desafio é gerir expectativas é que os clientes geralmente não sabem muito bem o que eles querem. E para você traduzir da cabeça deles e colocar no papel, chegam algumas coisas do tipo: "eu quero um aplicativo igual a esse".

Aí você abre e eles mostram o Instagram, mostram Tik Tok. Você fala que isso já existe. Já tem uma equipe enorme, uma empresa enorme. O que você de fato quer fazer com esse produto? Qual é a solução que você quer colocar? Então todo esse trabalho é feito no começo e claramente vão rolar pontos em que a expectativa não foi muito gerida, em pontos em que você não entende muito bem. Mas a ideia do projeto você entende como um todo, e como é que funciona na prática, pelo menos na minha empresa antiga, esse fluxo de temos uma ideia e vamos passar até o momento do teste.

Existia uma ou várias reuniões, em que a gente chegava com a definição do projeto, definição do produto como um todo, e a partir do momento, a gente começava de fato a planejar isso daqui pra frente. Então, a gente literalmente pegava o projeto e quebrava em pequenas partes o clássico dividir para conquistar. A gente dividia isso em features, e agregava aquilo em caixinhas.

E falava, a gente vai ter essa caixinha de implementação primeiro e depois a segunda e depois a terceira. E dentro desse processo de, a partir do que dividimos, o que a gente precisa fazer é o momento de fato da gente controlar isso. Então, muitas empresas usam diversos softwares, Gira, Trello, qualquer tipo de kanban ou qualquer tipo de estrutura,  que as pessoas consigam enxergar o desenvolvimento do projeto. E eu entrava muito na parte de estava na reunião com o cliente. Vou pegar o que eu absorvi na reunião e escrever um card.

Na escrita do card, geralmente tem uma definição de "feito". Você coloca ali como que o dev, sabe que ele terminou, você coloca ali, qual a definição de feito. Se é um botão que vai para o mapa a definição de feito é: o usuário deve clicar no botão e conseguir ser redirecionado para o aplicativo do mapa. Só que quando você escreve isso, quando você passa essa tarefa que você tirou do cliente para o desenvolvedor, você está atuando como uma ponte.

E se você não for tão claro o suficiente, nem com a ponta do cliente, nem com a ponta do desenvolvedor, vai chegar um card para o desenvolvedor ou para desenvolvedora, ele vai fazer isso, vai achar que está certo, define de feito funcionando perfeitamente. E aí, na hora de testar, eu percebo que não era isso que o cliente queria.

Então vou voltar esse card aqui para que ele seja corrigido. E é um pouco disso que Chijo está falando. Claro que às vezes tem implementações que não funcionam. A gente encontra alguns bugs, algumas coisas, faz parte do projeto. Mas eu vejo que muitos dos cards que davam problema eram falta de gestão de expectativa, falta de entender do cliente o que ele queria, a falta de entender o que eu precisava passar de informação para o dev.

E isso tudo faz parte de uma gestão de projetos. Então, essa questão de voltar cards e tester, eu acho que você consegue amarrar muito bem para ver se o que você está testando vai ser mesmo o que precisa estar acontecendo com a principal implementação que a gente escreveu lá atrás e foi testada até o fim.

Paula:

Acho que produto é um conceito muito complexo também, mas que é algo legal da gente discutir aqui também. Uma palavra super simples, com várias explicações. Acho que produto, quando a gente fala de tecnologia, muitas vezes a gente vai pensar em um site ou em um aplicativo, mas muitas vezes o produto também pode ser um serviço, pode ser um processo.

Então, acho que também o papel da pessoa de produto é não só definir o que vai ser feito ali em termos de tecnologias em si, mas quais são os seus processos para aquilo funcionar. Então, acho que dando um exemplo nossa que da Labenu, o nosso produto principal é o próprio curso, né?

Então é muito mais um serviço que alguém teve que ir lá e pensar quais vão ser as atividades do curso, qual vai ser o cronograma como vai ser o atendimento às pessoas. Isso tudo também é definição de produto e algum dia a gente vai ter aplicativo, vai ter tudo isso, isso também vão ser outros produtos, sem contar a parte de desenvolvimento interno também.

Então, os nossos sistemas internos também são considerados produtos, só que internos. Então, acho que toda essa parte também de definir o que é que vai ser o produto também é uma complexidade da própria função.

Miau:

Você tocou no assunto bem legal, que é o que é produto. Putz, produto é uma coisa muito ampla mesmo. Você comentou pode ser um software, pode ser um serviço, pode ser uma peça, pode ser alguma coisa física ou uma coisa digital e ter um entendimento na sua totalidade.

Qual é o objetivo principal disso que você está querendo vender? Seja serviço, seja alguma coisa física? Eu acho que é o principal desafio, sabe? E aí a gente pode entrar em diversas discussões, em diversas outras áreas também relacionadas à tecnologia, que não são de programadores, mas que são essenciais pra gente conseguir fechar e ter um produto redondinho. Acho que alguns exemplos, Paulinha está aqui, dados.

Mas a gente pode citar questão de design, mesmo de Q.A. testers, até  mesmo pessoas que que olham pra U.I., U.X., que são experiências de usuário ou experiências de interface, tem um monte de caminhos a seguir em que o produto centraliza e que os desenvolvedores eles são quase que quem vai dar a vida ali para aquele produto. Se a gente está falando de uma coisa digital.

Mas eu acho que só os desenvolvedores conseguirem dar a vida naquilo, é necessário toda uma outra gama ali de entender para que que a gente vai fazer isso e que não vai. Acho que seria até legal você comentar um pouquinho sobre qual que é a parte de dados que você enxerga em relação a um produto.

Paula:

Muitas vezes, dados eles podem ajudar a tomar decisões estratégicas dentro de um produto. Então, um exemplo clássico aí é um teste A B, por exemplo, que eu vou pegar o Instagram. Então o Instagram vai lançar uma funcionalidade nova. Ele pode dividir os usuários aleatoriamente em dois grupos.

Pra uma parte do grupo, ele vai lançar a funcionalidade de um jeito, para a outra parte, ele lança de outro e muitas vezes eles até têm um grupo de controle ali que não lançou a funcionalidade nova que eles ficam segurando. E aí eles avaliam como aqueles usuários, qual é o comportamento deles ao longo do tempo. Então as pessoas estão gostando da funcionalidade, estão usando.

Elas estão abrindo mais o Instagram ou menos, e aí eles ficam avaliando isso. Depois fazem essa análise de dados aí, do comportamento dos usuários para decidir se vai lançar mesmo essa funcionalidade para todo o mundo. Se não vai, se vai alterar alguma coisa. Então, muitas vezes dentro de produtos, dados também podem contribuir. Acho que também as pessoas que estão como P.O. ou P.M. também tem que ter essa capacidade analítica para muitas vezes tomar decisões, aí baseadas em dados. Como Miau falou, tem muitas carreiras, a gente está falando só de produto.

Nem entramos ainda na área de dados, só dentro de produtos já tem um monte de carreira e tanto de management, de gestão do próprio produto, mas também essa parte de teste. U.X., U.I,  que vai um pouco mais para o design de produto. E muitas vezes a gente pensa em design só como design de tela, e desenhar, design gráfico e tudo mais.

Mas também tem essa parte de design dentro da tecnologia, que é pensar em como vai ser as telas de um site ou de um aplicativo, como que vai ser a experiência de usuário daquele aplicativo. Tem toda essa parte também dentro de design e dentro dessas carreiras. Então, um mundo de possibilidades, né, gente, não precisa ser só pessoa programadora, desenvolvedora, para trabalhar com tecnologia.

Chijo:

Eu acho que a gente pensa num site, no aplicativo, a gente já pensa direto, tem que programar o negócio, mas programar eu acho que é quase o detalhe do negócio. Tem todo um processo que vai começar com a pessoa que teve a ideia daquele produto. E desenvolver essa ideia em algo que faça sentido, que nem o Miau falou. Não dá pra falar, eu vou criar uma cópia do TikTok. E é isso. Por que você quer fazer isso?

O que você quer fazer com essa plataforma e entender tudo isso e aí vai ter uma pessoa de design, então, que nem a Paulinha citou, designer por si só, também é uma coisa que é um pouco fora da tecnologia, no sentido de que você pode ser designer de outras coisas. Então você vai para uma faculdade de design. Você aprende um pouco dessa parte de mais tecnologia, mas você aprende, sei lá, a diagramação coisas físicas e design de serviços. Tem várias áreas dentro do design, por si só também. E essa pessoa ela ela vai desenhar as telas, porque se o dev fosse desenhar as telas, ia sair uma coisa incrível.

Miau:

Tem alguns devs que manjam.

Chijo:

Tem alguns devs que conseguem, mas… Mas tem umas coisas que você olha assim... por que a pessoa fez isso? Tem dois input, um colado no outro, um botão, e a pessoa acha que esse é o formulário. Então a pessoa de design, ela vai não só deixar tudo bonito, que é muito importante também, mas pensar em como aquilo vai ser usado. Então é uma pessoa que pode fazer teste com os usuários para entender, se aquele negócio do jeito que está feito, está funcionando mesmo, ver o usuário usando o aplicativo no site mesmo.

Então, fazer algum tipo de pesquisa. É uma pessoa que conhece sobre como as coisas vão acontecer na tela. Então, muitas vezes a gente não repara, mas você aperta um botão, tem uma animação que faz sentido para levar você a clicar em alguma coisa. Então tudo isso é muito pensado antes. Se vocês começarem a olhar os sites, os aplicativos que vocês usam com mais detalhe, assim vocês vão notar que tem muita coisa que é pequena. Às vezes você não nota, mas teve alguém que pensou muito em como fazer aquela animação e geralmente foi a pessoa de design ali.

Miau:

Mas sobre essa questão do design, eu lembro de ter visto algum talk, alguma palestra relacionada que acho que, se eu não me engano, posso estar falando besteira aqui. Mas se eu não me engano,  era da Uber, e a Uber estava com um problema de as pessoas pedirem o aplicativo, e a galera sentir que está demorando muito para achar o motorista. Então, como eles fizeram para mitigar um pouco, para maquiar um pouco esse sentimento de: "meu Deus, estou aqui esperando muito".

É muito a questão da animação. Enquanto o motorista não aceitava a corrida, você pode ver que a tela do seu aplicativo tem uma barrinha que vai carregando ali, que vai te mostrar progresso, mostra alguns carros mexendo mesmo que eles não estejam lá, que eles não existam, para te dar um sentimento de que está progredindo, está avançando. Dentro do desenvolvimento, eu acho que até mais rápido, de você for pensar em performance,  codar uma coisa em que, beleza eu faço uma requisição e hora que o motorista aceitar, eu vou ter que mandar essa resposta de volta.

E aí, beleza, você tem uma corrida. Só que para o lado do usuário. Muitas vezes o que acontecia ele entrava, ficava esperando, via que nada acontecia, saía do app e a corrida era perdida. Então eu acho que esses elementos do design, esses elementos de usabilidade, são muito importantes dentro do produto. E é muito isso. Não é simplesmente tela, não é simplesmente a tela. O aplicativo é bonito, mas pensar na usabilidade como um todo, acho. que faz muito parte de uma área de tecnologia que não requer programação, que é essa parte do design.

Uma coisa que eu queria comentar que você falou sobre o teste AB, e foi uma vivência da semana passada. Acho que é legal trazer aqui. Estava aqui mesmo no escritório, conversando com algumas pessoas, e aí a gente estava falando sobre a mudança do Instagram. \

Não sei se vocês já repararam. Não sei se já atingiu vocês ou não, porque é um teste AB sim. O feed infinito Instagram que você abre parece que é tudo reels. Parece que é tudo TikTok, não sei se aconteceu com todo mundo ou que não, mas isso é um sinal de teste AB. As pessoas que estavam com esse feed infinito falaram: "Nossa, tá muito feio, não estou gostando. Era muito melhor do jeito antigo". Mas se você for olhar nos dados do Instagram, as pessoas começam a passar mais tempo na plataforma porque eles mudaram isso. E é uma plataforma que precisa que as pessoas fiquem ali porque elas ganham por ads.

Paula:

Eu acho que esse é um caso que você não pode se guiar puramente pelos dados, por isso que eu acho que tem uma parte também dentro do design de produto ali, das pessoas fazerem testes com usuários, fazerem pesquisas com usuários. Acho que já deve ter acontecido com vocês.

Já aconteceu comigo de eu estar usando alguma coisa, aparecer lá a conta aqui o feedback do que você está achando de usar e tal. Então acho que tem sim essa questão de deles usarem dados de usabilidade. Quanto tempo as pessoas estão passando, se aumentou ou não, mas se eles se levarem só por isso também eles podem acabar implementando coisas que com o tempo, vai afastar as pessoas da plataforma.

Então é sempre esse jogo assim, de ver o que beneficia mais o negócio que está fazendo as pessoas usarem. É isso. Se eles vão puramente por, não, as pessoas estão passando mais tempo, então vão manter isso aí, sei lá. Com o tempo a galera desiste de usar, porque acho que está ficando muito chato também. Isso não vai ser bom para o negócio, então são vários tipos de dados que você consegue coletar.

Muitas vezes um vai ser contra, vai ficar um contra o outro ali. E aí também tem essa parte de tomada de decisão ali, estratégica por aqui, que vai fazer mais sentido a médio e longo prazo também.

Chijo:

E aproveitando que a gente entrou no assunto de dados, aí queria saber um pouco como que é o dia a dia de uma pessoa de dados que você faz.

Paula:

Bom, eu acho que a área de dados ela vem crescendo muito aí, nos últimos tempos, a gente escuta várias buzzword sobre isso. Machine learning, inteligência artificial e tudo mais. E com certeza, conforme a tecnologia foi avançando, a gente tem cada vez mais dados sendo coletados dessa forma. Se a gente consegue usar esses dados de uma boa forma, a gente consegue gerar mais insights, para as empresas e isso pode ser um grande aliado estratégico para a tomada de decisão, como a gente estava comentando. Então, a gente pode ter vários tipos de profissionais de dados assim.

Queria comentar um pouquinho de cada um deles, porque acho que a rotina vai ser bem diferente. Então acho que dentro da carreira de dados você pode seguir para uma parte mais de data engineering ou engenharia de dados, que vai trabalhar um pouco mais com a parte de coleta de armazenamento de dados, de fluxos, processamento.

Então, quando a gente está falando, por exemplo, de uma aplicação, de um site, a gente tem aqueles dados do site sendo guardados num banco de dados, tanto os dados que a gente chama de transacionais ali e a gente tem no nosso sistema interno, por exemplo, qual é a presença dos estudantes. Então isso tudo é armazenado no banco de dados.

Mas a gente pode ter também dados de usabilidade ali. Então, quanto tempo a pessoa ficou logada no sistema, quais páginas ela mais acessou e tudo isso fica guardado num banco que é o banco de produção ali. E, obviamente, ninguém vai usar o banco de produção para fazer análise de dados para rodar o algoritmo de machine learning, porque se der algum problema, vai dar muito problema, na aplicação ali. Então, muitas vezes, o que se faz, um exemplo de aplicação do data engineering.

É você fazer um fluxo de dados para você replicar esse banco que está em produção num outro banco que o pessoal usa para fazer consultas, análises e tudo mais então esse é um tipo assim. Muitas vezes vai ter um processamento ali dos dados pra ele ficar numa estrutura diferente, que é mais fácil para as pessoas consultarem e analisarem, por exemplo.

É uma área que  vai ter mais programação mesmo assim. Então, sei lá, uma pessoa que gosta de back end, por exemplo, talvez curta um pouco essa parte de data engineering, que acho que é um pouco mais parecido assim. Mas, além disso, a gente também tem a parte de data analysis, e data science, muitas vezes  o pessoal também engloba tudo como data science, mas algumas empresas também têm essa separação.

Parte de data analysis ou análises de dados, vai ser justamente essa questão de fazer análises mais pontuais. Então, muitas vezes tem um problema ali pra resolver, uma pergunta que alguma outra equipe vai trazer, também se trabalha com dashboard de acompanhamento. Então você conecta alguma ferramenta com seu banco de dados para conseguir ver gráficos que vão atualizando periodicamente para você fazer algum tipo de acompanhamento.

Também tem a questão do machine learning ali que você vai ter modelos tentando fazer predição com base nos dados que você tem, históricos ali armazenados, modelos de classificação ou recomendação, que acho que é o que a gente tem mais contato no nosso dia a dia. Você está ali num streaming, aí você assiste a um filme, depois que você assiste e aparece um monte de recomendação.

Aquilo é basicamente tem um algoritmo ali por trás, trabalhando ali na classificação do que você pode gostar com base no que você já assistiu. Tem esses, essa parte aí dentro da área de dados, que também é uma área bem ampla e com vários tipos diferentes de atuação.

Chijo:

Você falou um pouco, que tem uma parte ali, um pouco de programação, mas acho que são ferramentas bem diferentes do que a gente usa para desenvolvimento web, mobile e tudo mais, o que você usa mais ali hoje no dia a dia, que é mais diferente?

Paula:

Na área de dados, aqui na Labenu, a gente tem usado mais a linguagem Python, então é uma das linguagens mais comuns aí de serem usadas, diferente do desenvolvimento web, que acaba indo mais para o JavaScript, às vezes Java também e outras linguagens.

Não é impossível fazer ciência de dados com outras linguagens. Mas é o que a gente vê, por exemplo, do Python. É que se tem muitas bibliotecas que foram construídas para ajudar na análise de dados, então, por exemplo, outro dia eu estava fazendo um projeto que eu demorei um mês pra fazer um monte de gráficos e depois descobri uma biblioteca que fazia a mesma coisa em segundos.

Chijo:

Quem nunca?

Paula:

A comunidade do Python é muito grande e o pessoal acaba desenvolvendo essas bibliotecas aí para para ajudar mesmo no dia a dia. A gente usa também ferramentas de dashboard, como eu tinha comentado, então tem várias por aí. A gente aqui usa o Google Data Studio mas existe também o Power B.I., Tableau. São todas as ferramentas que vai permitir conectar no banco de dados e trazer gráficos, análises, visualizações de dados para tirar insight.

E além do Python, tem outras linguagens também que são comuns, que são o R é a letra R mesmo.  A primeira vez que alguém me falou R,  eu fiquei meio confusa, mas sim gente. A letra R mesmo é o nome da linguagem e tem uma outra que se chama Stata, também é bem comum de ser utilizada em mercado, principalmente no mundo acadêmico.

Chijo:

Miau já mexeu um pouco com B.I., também.

Miau:

Já mexi, minha experiência não é vasta, mas eu acho que ao longo da minha trajetória é muito isso, sabe? Você quando olha pra um banco de dados, a primeira coisa precisa ter registrado então eu acho que dados têm muito esse papel de pegar e registrar os dados de alguma forma que a gente consiga analisar depois.

Só que existem análise, análise, sabe e eu acho que o principal de a gente ter a possibilidade de coletar esses dados e olhar para eles, essas ferramentas, que é a que Chijo  comentou que eu já tive contato, é muito pra ajudar a gente a tirar insight, tirar ideias melhores ali no dia a dia.

Aprender de alguma forma, ter um contato com a programação com a tecnologia, tanto na minha experiência de trabalho quanto um pouco na graduação me ajudou muito a desenvolver essa questão analítica de não simplesmente olhar para uma tabela e me assustar.

Eu acho que o que mais me ajudou foi ter esse contato de tipo beleza se vai me assustar a primeira vez, vai me assustar na primeira vez, vai me assustar da segunda vez, mas não pode me assustar para o resto da vida. Então eu pegava, sentava ali e falava: "vamos brincar com isso aqui". Vamos olhar quantas pessoas tem vermelho, quantas pessoas estão de azul e assim você vai se desenvolvendo. Queria chamar a atenção de uma coisa da questão das bibliotecas e até mesmo da tecnologia, ajudando no trabalho.

Eu fiz uma análise um dia que eu demorei dois, três dias para montar um gráfico, pra até pensar, limpar os dados e montar, e montei isso. Aí eu estava conversando assim com com um amigo, e ele falou: "isso aqui na biblioteca Python é uma linha e você coloca ali os dois parâmetros e o bagulho sai bonitinho".

Falei: "não, lógico que não, você tem que limpar os dados, você tem que fazer uma série de coisas". Ele falou: "vem aqui, o que você quer fazer?".  "Eu quero fazer esse tipo de gráfico". Aí ele pegou, digitou ali e deu play e o gráfico bonitão ali. Então, assim a tecnologia, ela vem muito pra ajudar a gente. Eu acho que todas essas ferramentas que a Paulinha falou você consegue programar e plotar um gráfico usando JavaScript, você consegue.

Mas tem outras momentos, outras ferramentas que vão te ajudar cada vez mais no seu dia a dia de trabalho. Então acho que já também falando um pouquinho da minha visão em relação a saber programar e entrar no mercado de tecnologia. Eu acho que tem a questão que comentei no começo de lei da exposição quanto antes você tiver exposto aquele cenário, mais cedo você começa a absorver aquilo.

Mas também eu vejo que algumas coisas dentro da tecnologia me ajudam muito em tarefas do dia a dia. Sabe? Eu não sei programar uma aplicação, não sei fazer uma página web, mas eu sei fazer… Eu sei o que que é um for, o que é um loop. E eu já usei esses conhecimentos do que é o for, que é um loop pra próprios projetos, aqui dentro do Labenu. Vou dar um exemplo para vocês. Quando comecei a trabalhar aqui no Labenu, um dos primeiros projetos que eu recebi foi: "você precisa criar a tabela de presenças desses alunos aqui".

E aí eu comecei a pensar: "putz, criar a tabela de presença é tranquila, o nome das pessoas e pronto acabou". Aí eu comecei a pensar um pouquinho mais a fundo. Putz, mas na verdade, todos os dias que tem aula as pessoas vão ter que ter presenças e todas as atividades que a gente dá tem que ter presença. Então, daquela lista que eu tinha que gerar uma vez por dia, eu comecei a ter que gerar diversas listas por dia com os nomes das pessoas para controlar aquilo na planilha.

Então a V0 ali como a gente controlava presenças, foi muito feito conceitos básicos de programação que me ajudaram muito. Eu peguei uma planilha e eu precisava de uns 130 dias de curso eram 20 pessoas. Eu precisava de 200… 2600 linhas. E usei um for para ficar printando o nome das pessoas ali para eu conseguir copiar e colar e jogar na planilha. Então, a programação é uma ferramenta que ajuda muito no dia a dia de trabalho. Mas isso não é essencial para desempenhar certos papéis.

Paula:

Eu queria voltar um pouco nessa questão de ferramentas. Na área de dados, existem muitas ferramentas superpoderosas, como a que você comentou, putz, uma linha de código faz um monte de coisa. Mas eu acho que a área de dados ela não é só isso, acho que é entrando também um pouco, como a gente comentou de perfil pra pessoas de produtos, acho que também existe um perfil para pessoas de dados assim. Eu acho que uma coisa de diferença entre a área de desenvolvimento de software e a área de dados é a questão do pensamento mais matemático.

O estatístico, né? A gente frisa muito aqui na Labenu e eu sou maior defensora disso, de que pra aprender a programar não precisa ser bom em exatas, não precisa. Precisa ter a lógica, que é uma coisa que vocês até discutiram no episódio passado. O que é lógica? Tem que ter, sim, um pensamento lógico, mas que você consegue desenvolver de várias formas. Mas quando a gente está falando de dados especificamente, acaba precisando de um conhecimento ali, uma base um pouco maior de estatística  de probabilidade.

Então, um conhecimento mais matemático mesmo é mais exigido até para coisas mais complexas de machine learning, acaba exigindo um pouquinho de cálculo, álgebra linear. Já vi um pouco. Foram coisas que eu fui aprender só na faculdade de engenharia, que assim não é impossível de você aprender por outros cursos. Você vai ter que ter um pouco  dessa base ali na matemática de talvez pegar para estudar estatística básica primeiro ter um pouco ali de contato com o que é uma distribuição normal, o que é probabilidade?

Coisas nesse sentido. Porque sim, as ferramentas são Poderosíssimas. Mas a gente precisa também saber avaliar o que é aquele resultado. Então, putz você usou uma ferramenta para fazer um gráfico. Mas como você interpreta os gráficos? Como que a partir desse gráfico você leva uma resposta para o seu stakeholder? Que a pessoa que é que tem interesse naquele seu projeto então tem muito dessa parte, desse pensamento analítico, estatístico que você, sei lá, olha para um modelo de machine learning, por exemplo, e vai pensar putz, mas esse conjunto de dados que eu usei pra esse  para treinar esse modelo pode estar enviesado.

Pode ter algum problema... tem um conjunto é pequeno demais para eu tirar conclusões a partir disso. Então acho que a maior dificuldade, mesmo dentro da área de data science, data analysis, é realmente essa parte de você avaliar o que você está fazendo, de você tirar conclusões a partir dos gráficos que você gerou. Mas acho que não só essas áreas mais de exatas estão se inserindo nessa nessa área de dados.

Eu vejo atualmente muitas pessoas do mundo acadêmico em geral migrando para a área de dados. Então pessoas da biológicas que muitas vezes têm ali uma base estatística boa. Assim, e até a parte de humanas então, atualmente a gente tem uma parte de jornalismo de dados que está sendo superimportante. Sim, vejo várias pessoas entrando nisso.

Um exemplo de combate à Fake News por exemplo, tem pessoas que fazem análise de dados de jornalismo pra evitar Fake News e até na área de letras, tem uma parte de processamento de linguagem natural, que também que é uma área de machine learning do Data Science, que o pessoal usa. Então, outro dia eu vi no Twitter uma pessoa que usou o processamento de linguagem natural para avaliar os textos do Machado de Assis, por exemplo, pra ver quais capítulos eram mais felizes e quais eram mais tristes e enfim, então tem várias aplicações da ciência de dados.

Chijo:

Aí a gente comentou aqui um pouquinho de precisar ter essa formação essa base mais matemática. Mas não é só a única aplicação que você pode aplicar em diversas áreas e eu vejo pessoas de diversas áreas se interessando por essa área. Só precisa ter mesmo esse olhar e essa vontade de aprender estatística. Um pouquinho de matemática aí, porque às vezes vai precisar.

E mesmo essa parte da formação da pessoa é tipo, da mesma forma que a gente. Antigamente, se quisesse programar, tinha que fazer uma faculdade realmente estudar mais. Hoje eu vejo que está surgindo bastante cursos nessa área de data science, principalmente é o que aparece mais, que são mais curtos, que resumem ali o que você precisa nunca olhei muito a ementa, mas enfim, cursos mais acessíveis digamos assim.

Paula:

Com certeza, com certeza. Vários bootcamps, da mesma forma que a gente tem bootcamps em desenvolvimento web, como é o caso aqui da Labenu. A gente também tem bootcamps de data science. Você tem vários cursos online e é por aí que as pessoas conseguem aprender. Então a gente está começando a ver agora. Algumas faculdades quererem ter cursos de ciências de dados, mas com certeza você não precisa fazer uma formação nisso para se tornar cientista de dados. Você consegue migrar de várias carreiras aí.

Miau:

Uma coisa que eu queria adicionar nesse perfil de dados eu acho que não só de dados, mas de qualquer área da tecnologia. Essa questão que você comentou de ser quase que Sherlock Holmes, quase que é um processo investigativo. Para você entender de fato o que precisa acontecer. É importante algumas características de senso crítico. Você se questionar se o base de dados está tão ideal, se está conduzindo olhar para isso ou não.

Mas eu acho que também uma das coisas mais importantes dentro de dados. Eu vejo muito que é você conseguir chegar nas informações que você quer. Eu acho que a análise às vezes está na sua cabeça. Você pode ter uma base muito legal sobre as estatísticas e sobre tudo. Mas se os dados não estiverem ali, com a qualidade ou com uma quantidade legal, pouco você consegue fazer.

E mais do que isso, às vezes você tem até uma base legal para trabalhar, mas ela não está padronizada e então tem que passar assim por um processo quase que investigativo para entender como que está sendo isso. Como a gente está coletando isso, em que momento? Porque tudo isso vai ajudar você a tomar uma decisão e uma análise final aí pra para entregar para as pessoas.

Paula:

Eu e a analista de dados da minha equipe, a gente brinca que para ser analista de dados tem que ser fofoqueira, porque vocês se encontram um negócio ali. Você fala: "que babado é esse, vou investigar mais". Aí você vai atrás para descobrir e você encontra erro na base. Aí você, a partir do erro, você encontra erro de processo aí vai falar com a equipe: "por que isso aqui está preenchido errado?".

Aí vai descobrir. E aí descobre que o erro está porque alguém falou pra não sei quem que era desse jeito, que fazia e aí você vai entrando num buraco sem fundo. Então sim, muitas vezes tem que ter esse perfil Sherlock Holmes. Aí tem que ser fofoqueira ir atrás dos babados. Perfil analítico e fofoqueira. Está muito bem valorizada em qualquer área, não só em dados. Eu acho que esse tipo de coisa perguntar e questionar sempre muito bem vindo.

Chijo:

A gente começou lá no comecinho então uma pessoa de produto ajuda a pensar no produto. O pessoal de design vai transformar isso que a pessoa de produto pensou em uma interface que faz sentido. Vai passar para desenvolvedor e vai começar a desenvolver tudo mais. E a gente volta, então, pra falar um pouquinho mais daquela parte de QA.. Porque a desenvolvedora criou ali o código do jeito que achou que devia ser ali. Mas quem é dev sabe, gente, que nada dá certo as primeiras vezes, não na segunda nem na terceira. É o processo. E às vezes a gente está olhando o nosso código.

A gente faz o melhor que a gente pode, mas os erros eles passam porque o usuário é uma pessoa incrível. Ele consegue criar coisas que a gente nunca espera. Então a pessoa Q.A., que vai garantir a qualidade daquilo que você fez, a pessoa vai testar o que a gente fez ali no aplicativo e ele vai pegar, vai apertar cinco vezes o botão pra ver o que acontece. Vai fazer uns fluxos ali para realmente testar, não só as vezes aquilo que você acabou de fazer. Então, vamos supor, eu tinha uma tarefa para fazer a tela de login.

Mas depois que eu coloquei a tela de login, será que eu não quebrei alguma outra coisa no aplicativo que eu nem estava prestando atenção? Geralmente, a resposta é sim, acontece. E aí eu queria comentar. Então acho que principalmente o Miau,  como que era essa parte mais de Q.A., que não era exatamente o seu cargo, mas era uma coisa que você acabava fazendo também como funcionava o dia a dia ali?

Miau:

O esquema é muito, a partir do momento que o dev falou: "pronto, acabei", ele arrasta um card. Você fala: "está disponível para testar". E aí, dependendo da aplicação, se é mobile, se é desktop, você vai realmente brincando e tentando explorar todas as possibilidades ali. Eu gosto de brincar que eu sou muito bom, eu sou um bom clicador de botão. Então, se tem o botão ali, eu vou clicar pra entender o que funciona.

Putz, quebrou, quebrou, vou falar pro dev ali que quebrou, e eu não sei por que quebrou, mas quebrou então precisa reportar isso pra ele. Tem até o Darvas que veio no episódio anterior, ele… Eu fui Q.A. tester dele de alguns projetos que ele fez e ele me chamava muito de dedo podre, porque era meio que eu encostava e parecia que quebrava, que não estava bonito. O processo é meio muito simples, sabe?

Você tenta fazer primeiramente o fluxo padrão. O que está na nossa cabeça. Então, por exemplo, a Chijo falou, vou ter uma área de uma tela de login e alguém precisa testar isso. Acho que a primeira coisa que eu vou testar, pegar essa tela, colocar ali usuário e senha e dar um ok, e ver se foi. Putz, foi, meu trabalho acabou? Eu acho que não, porque isso é o fluxo ideal. E ele geralmente tá certo, o problema é fluxo não ideal. Putz, tentei fazer o login, digitei a senha errada e ele foi, isso é um problema grave de questão de segurança.

Então esse card vai precisar voltar. Alguns outros exemplos. Putz, coloquei senha, apertei pra ir. Ele não foi. Mas se eu fechar o aplicativo e abrir de novo, ele vai estar logado. Então você tem uma série de pontos em que você vai aprendendo e literalmente fazendo, literalmente entregando a tela para a pessoa e pedindo: "clica no botão e vê o que que você acha, o seu objetivo e logar".

E a pessoa geralmente vai tentar logar de alguma forma ou de outra. Conforme vai testando diversas aplicações, várias coisas, você vai começando a ter um olhar um pouco melhor, se eu fizer isso e se eu der um espaço antes do usuário e se não tiver arroba? E se eu digitar a senha errada de propósito três vezes, ele vai bloquear? Não vai? E se eu apertar que esqueci a senha, e depois logar com a senha antiga.

Então tenho uma série de fluxos, que você tem que pensar, exercitar, para hora que você fizer o teste que é muito rico também para o próprio produto, porque às vezes você pensou num fluxo que não foi mapeado nem para o cliente nem para você, mas que agrega muito. Então não sei se eu te respondi ou não, mas acho que o processo é muito esse. É de fato pegar, sentar e pensar no caso ótimo. E nos casos não ótimos, que são infinitos.

Paula:

Uma vez eu participei de um processo de Q.A. numa empresa que eu trabalhava. O Q.A. chamou várias pessoas de áreas diferentes da empresa, porque eles iam lançar uma tela de cadastro nova. E putz, a galera de Q.A. já tinha testado tanto que eles já estavam muito enviesados. Aí eles falaram: "vamos chamar umas pessoas aí que nunca viram essa tela na vida e vamos falar pra elas tentarem fazer o cadastro aí".

E aí a gente tinha que testando e justamente tentar esses fluxos não usuais. Então, deixa eu clicar para ir pra próxima e depois voltar pra ver o que acontece. Então foi muito divertido. Achei muito legal.

Chijo:

Basicamente, o perfil de uma pessoa Q.A., então é ter maldade no coração. É tentar destruir o aplicativo dos outros.

Miau:

Acho que é não ter medo de errar, porque eu acho que é isso você está procurando o erro e clicar em todo o botão onde não é o botão, clicar também porque vai que quebra. E acho que o objetivo é você achar isso. Acho que controle de qualidade passa muito por essa questão de estresse mesmo, não estresse, tipo eu estou estressado ali testando, mas você estressar o teste.

Vou tentar desse jeito. Vou tentar de outro jeito ou de outro jeito, do jeito, do jeito. Porque um bom trabalho de Q.A. feito redondinho vai permitir que, no futuro, esses desenvolvedores e desenvolvedoras não tenham que revisitar essa task específica para ter que corrigir ou para implementar uma coisa. E quando a gente tá falando de gestão de expectativas, gestão de projetos, uma das coisas importantes também é evitar quebra de contexto.

Então a pessoa está ali focada numa nova tela, uma nova implementação. E aí, do nada, volta três meses depois, o pesadelo do tela de login. Então eu acho que é uma das profissões essenciais, mas que você também vai ficando cada vez melhor, tendo mais referência. É uma daquelas coisas que você só melhora fazendo mais, eu acho.

Paula:

E até pensando do lado do próprio usuário. Se a gente tem um processo de Q.A.  bem feito, a gente pode evitar que a pessoa desista de usar o seu produto, de comprar alguma coisa ou se cadastrar, porque ela não tem ou não teve uma experiência muito boa, né? Então, acho que tem pensando no outro lado também. E além das pessoas estão desenvolvendo também, tem isso. E muitas vezes, no desenvolvimento de software, a gente tem os testes automatizados também, que eles já evitam algum desses, alguns desses problemas.

Mas algumas coisas nem sempre são problemas de código. Eles são problemas de experiência de usuário. Eu não sei se Chijo já passou por alguma situação assim. Mas acho que até essa questão do teste, tem os testes automatizados que as pessoas desenvolvedoras fazem para garantir um nível de qualidade ali antes de passar.

Chijo:

Mas eu vejo muitas pessoas de Q.A. também trabalhando com testes automatizados no sentido de, por exemplo, eu conheço uma pessoa que ela trabalhava com Q.A. em uma empresa de jogos. Então, toda vez que os devs mandavam uma versão do jogo.

É muito fácil ter quebrado coisas que ela já testou várias vezes. E aí ela fazer esse processo de automatizar essas coisas. Então, sei lá, eu quero testar a feature nova, que foi um menu novo que foi criado no jogo. Mas esse menu não pode ter quebrado como a tela aparece, como o personagem anda, como todo o resto do jogo acontece.

E se ela fosse ficar testando toda vez o personagem andando, bater na parede e tudo mais, ia demorar muitas horas para fazer esses testes, então você consegue automatizar alguns dos processos que você faria na hora de testar. E eu acho que isso também. Apesar de ser um pouco na área de programação, tem ferramentas também que ajudam a fazer isso com um pouco menos de código e que o pessoal de Q.A. também entra um pouco nessa área.

Miau:

Eu queria comentar sobre o que você falou, que é muito essa questão das ferramentas que não precisam tanto de código, tanto que a gente chama de low code ou quase que no code. São ferramentas que fazem a mesma coisa que a programação.

Os desenvolvedores estão ali, mas de uma forma mais simples, de uma forma quase que em blocos ou quase que seleções de alguma coisa, é muito para simplificar e eu vejo que essa é uma perspectiva muito boa naquele mesmo papo da lei da exposição. Não sei programar, não sei fazer nada. Quero entrar no mercado de tecnologia. Algumas ferramentas auxiliam muito. Eu utilizo diversas ferramentas ao longo do meu dia para me ajudar e todas elas são quase que clicar em botões.

Chijo:

O próprio site, o blog da Labenu, que se você não conhece, www.labenu.com.br, ele não foi feito para programadores. Ele foi feito pelos nossos designers, principalmente, usando uma ferramenta que se chama webflow. Então você consegue criar o site ali sem programar. Você pode colocar o seu próprio código personalizado se você quiser se você conhecer, mas você consegue fazer sites muito bons assim, sem escrever código ali, principalmente. Tem várias ferramentas que fazem isso.

Então, mesmo para fazer coisas que a gente acha que de fato precisa de código, tem ferramentas hoje que conseguem tirar isso um pouco e facilita. Acho que muitas vezes, até se você tem interesse de aprender a programar, mas não começou ainda, às vezes é um primeiro passo legal também. Você já consegue fazer um site e entender como funciona o navegador, as ferramentas, enfim.

Miau:

Quem nunca mexeu no thumblr, no HTML? Sou um programador nato, deixar tudo em negrito. Mas eu acho que passa muito por isso, sabe? Essas ferramentas estão evoluindo, está cada vez mais deixando a tecnologia acessível. Mas, invariavelmente, o que já me perguntaram uma vez, você acha que com essas ferramentas low code aí a carreira de programação vai acabar? E a minha opinião é clara: não, porque tem que ter alguém para manter esse serviço, tem que ter alguém para continuar desenvolvendo.

Eu acho que essas ferramentas vêm muito mais para ajudar a inserir mais pessoas no mercado do que para, na verdade, retirar vagas de programadores. Então, eu sou muito a favor das ferramentas low code. A Chijo comentou um pouco do porquê que a gente tem, utiliza o webflow e já veio também esse questionamento pra mim, de: "cara, vocês são uma empresa de programação, por que que o site de vocês é utilizando uma plataforma X Y Z que vocês não programam?". E eu acho que a solução, a resposta passa muito para a gente olhar para a operação que a gente tem.

Hoje a gente não quer ficar dedicando tempo, construindo nossa landing page, deixando ela bonitinha. Entra alguém novo na empresa. Você precisa atualizar a foto ali da galeria dos funcionários que tem. Precisava um programador entrar ali, colocar a foto, dar deploy, e fazer isso. Era um tempo alocado para manutenção desse site que a gente via, que ele é mais estático do que dinâmico.

Então ele vai ficar ali com as informações e, se precisar mudar, muito provavelmente quem vai mudar o conteúdo não é o desenvolvedor, é alguma outra pessoa de alguma outra área. Então, por que não a gente capacitar essas pessoas que são de outras áreas para utilizar essas ferramentas e ter autonomia de fazer o próprio trabalho então, um pouco disso, do que eu acho que o mercado de tecnologia precisa ser da matemática.

Eu preciso ser programador. Eu acho que não. Acho que cada vez mais o mundo está sendo moldado para que a tecnologia seja inserida. E eu acho que a gente também faz um pouco do papel para moldar esse mundo. Aí a gente tem o nosso curso, mas o nosso curso, ele é para programação, não é para você aprender coisas low code.

Eu acho que é um facilitador, mas que de fato, se você quer se aprofundar, se você quer ter uma carreira de desenvolvedor, é necessário mesmo ter esse conhecimento técnico. Para quem não quer, ou quem não quer focar nesse momento ou quer só aprender aquela coisa específica. Eu acho que o mundo do low code é super bem vindo, pelo menos para mim, e eu vejo com muito bons olhos.

Chijo:

Agora, se você quer aprender um pouco sobre programação, a gente tem o curso da Labenu, que é um curso de desenvolvimento web full stack, então você aprende a parte de frontend, de backend, e você só paga pelo curso quando você tiver empregado e ganhando mais do que R$3.000, por mês. Então, se você tem vontade de entrar nesse mercado, de aprender mais sobre programação, você pode entrar lá no nosso site para ver as informações das novas turmas. www.labenu.com.br

Então a gente falou aqui de algumas áreas. Então a gente começou lá no produto, no design, desenvolvimento. Depois que o produto está desenvolvido, alguém foi lá e testa. Acho que tem uma parte final ali, que ele é um pouco relacionado com desenvolvimento. Ou pelo menos a maioria das pessoas que eu conheci que faziam isso eram desenvolvedoras, mas que cuida mais da parte da infraestrutura, da coisa também.

Depois que o aplicativo está pronto, por exemplo, você subiu Netflix vai ter no dia do lançamento de Stranger Things, milhões de pessoas assistindo aquilo. E como você garante que isso não vai cair? Não vai explodir tudo?

Paula:

Quem nunca passou um perrengue tentando assistir a Game of Thrones?

Miau:

Ou tentando comprar o show de Sandy & Junior.

Chijo:

E aí tem a pessoa que cuida disso ali, que é o profissional de Dev.Ops. Então essa pessoa cuida dessa parte, mais de infraestrutura, de nuvem e de garantir que aquele serviço, aquele produto que você fez dev fez, todo mundo fez, antes de subir, vai continuar funcionando quando tiver pessoas usando. Entender as ferramentas que estão envolvidas nisso.

E acho que depois disso também entra a parte de dados, uma vez que está tudo funcionando. Aí a gente consegue coletar os dados ali e fazer as análises e voltar lá para o começo do produto. Aí melhora o produto, passa a design e passa para o dev, um grande ciclo de todo mundo trabalhando junto. A gente fala muito de programação, mas é um pedacinho pequenininho de uma coisa muito maior.

Paula:

Com certeza aquilo que eu falei. A pessoa que programa muitas vezes vai trabalhar numa equipe com várias pessoas aí de áreas diferentes. A gente tem ali a pessoa de produto fazendo essa ponte entre essas áreas. Mas muitas vezes você dentro da sua carreira vai ter que conversar com pessoas de outras áreas. Não vai ficar só ali com seu fone, programando. Muitas vezes seu dia a dia, vai ter algumas reuniões com pessoas de outras áreas. Então eu acho que isso também faz parte do dia a dia de uma pessoa que programa.

Miau:

Para ver se eu entendi todo esse papo que a gente fez. Eu passei no paralelo, eu queria ouvir se vocês acham que é muito viajado, ou se vocês concordam com isso ou não? Estava muito pensando aqui. Então, se a gente está pensando, sei lá em um prédio como a gente está aqui, que o produto é o aluguel das salas. A gente vai vender esse aluguel das salas para outras pessoas.

Quem constrói o prédio é o desenvolvedor, quem pensa na experiência das pessoas aqui no prédio, na arquitetura, no visual, é o arquiteto. Quem vai pensar em vamos ver se está acontecendo isso bem, se não está gerindo esse projeto, é o P.O., e quem depois de todo esse projeto rodando, a gente está alugando as salas aqui, vendo se está sendo rentável. O que pode fazer para melhorar? Pesquisando, conversando com as pessoas, entendendo é a galera de dados. Acham que faz sentido essa analogia, muito viajada?

Chijo:

Não... gostei!

Chijo:

Você criou agora do nada?

Miau:

Do nada!

Pensando aqui no prédio em que estamos.

Chijo:

Devia ser professor. Legal, gente acho que por hoje é isso, então queria que vocês se despedissem e dessem uma última dica para quem tem interesse nas áreas de dados de P.O., que vocês quiserem falar. 

Miau:

A minha dica que eu dou para quem quer entrar na área de tecnologia. Acho que a primeira delas é: não, você não precisa saber programação pra entrar, mas vai te ajudar muito. Eu uso programação básica como uma ferramenta no meu dia a dia de trabalho. Isso me ajuda muito, eu vejo que ajuda a gerenciar melhor o meu tempo, a fazer coisas que eu demoraria muito mais tempo e fazer em menos.

Então, eu acho que é tudo uma questão de se você quer entrar nessa área. Eu acho que você precisa chegar em algum lugar em que você consiga se inserir nesse espaço, seja entrando como Q.A., seja entrando como dados, seja entrando como produto, seja entrando como desenvolvedor ou desenvolvedora. Eu acho que o mais importante é você não ter esse medo de clicar no botão e errar e quebrar as coisas, porque é só quando você fizer isso, você vai tendo mais referência e aprendendo a como navegar nesse mundo complexo da tecnologia.

Paula:

Bacana, acho que a minha dica final é isso. Tem várias áreas diferentes aí. Eu acho que você que está querendo entrar pra esse mundo da tecnologia pode pegar algumas áreas que você se identificou mais. Talvez estudar um pouquinho mais sobre isso, assistir alguns vídeos no YouTube ou ter contato com pessoas que trabalham nessa área e pede para a pessoa contar um pouco do dia a dia dela. Acho que isso pode te ajudar a escolher.

E, se você quiser vir para a área de dados, puxar sardinha aqui para meu lado, eu acho que é uma boa forma de começar, seria pela parte de estatística, mesmo que acho que é algo fundamental aí para a área de dados. Então, se você não tem uma base disso, procurar, tem bastante coisa disponível no YouTube, tem livros, estudando um pouco mais dessa parte, recomendo pegar algumas linguagens de programação.

O Python, eu sou muito suspeita para falar porque foi minha primeira linguagem e eu tenho um carinho muito grande por ela, porque é uma linguagem mais simples de aprender a sintaxe, que é a forma que você escreve ali. O código é um pouco mais simples, tem muita coisa disponível na internet porque a comunidade é muito grande. Então eu iria por aí.

Explorar um pouquinho de estatística explorar um pouquinho de Python ali e tentar pegar algum projetinho para fazer e tentar pegar, mesmo que seja alguns dados seus assim de sei lá, hábitos, você vai ter uma planilha ali com seus hábitos. E aí analisa tipo: "quantos dias na semana fez exercício físico? Será que tem alguns dias da semana que eu fiz mais ou menos exercício?" Enfim, daria essa ideia de pegar para fazer algum projeto pessoal.

Chijo:

Muito obrigada. Gostei bastante das dicas. Obrigado pela conversa por virem aqui e até próxima.

Paula:

Eu que agradeço aí pelo convite.

Miau:

Tchau, gente.

Paula:

Até a próxima galera.

Paula:

E aí? Você curtiu o episódio de hoje? Lembre de acompanhar a gente lá pelo Instagram pra ver os próximos episódios: @labenu_

Miau:

Se você quiser ouvir esse episódio, ler um pouquinho mais, entender sobre tecnologia, sobre programação, só acessar: www.labenu.com.br/blog

que a gente tem uma série de conteúdos ali disponíveis para vocês.

Chijo:

Se você gostou do episódio, já deixa seu like, se inscreve no canal e ativa o sininho para saber sempre que a gente tiver novos vídeos. Até a próxima