Tão importante quanto escrever linhas e mais linhas de código
é você também fazer a gestão do seu projeto
e ao término, você criar o seu produto, entregar e documentado para o seu cliente.
Se você está pensando que hoje você vai escutar mais um podcast
falando sobre linguagem de programação que seja do front end ou back end.
Não, não é isso.
Mas vamos falar sobre a gestão,
que é a parte tão importante na entrega de um software.
E eu sou o Rafael Ronqui
e estou aqui com dois convidados.
Vou apresentar para vocês o Alexandre e o Alexandre.
Tudo bem com vocês?
Tudo bom, Rafael?
Obrigado pelo convite.
Trabalho hoje como responsável de Operações Brasil da Soft Tech.
É um prazer estar aqui com você.
Show! Edward, tudo bem com vocês?
Se eu pudesse apresentar para quem está nos escutando, por favor, claro.
Obrigado primeiramente pelo convite, Rafael.
Bom, meu nome é Eduardo Floriano, eu trabalho na Softex fazem dez anos,
sou responsável por algumas verticais de negócio, pelo delivery,
então tenho que gerenciar alguns projetos aí,
ou melhor, algumas centenas de projetos.
Então o desafio é bastante interessante.
Legal, Então acho que a conversa vai estar boa,
principalmente se tem a vivência na prática e no dia a dia.
Falar aqui não é nem só a visão, nem sem a vivência.
Começar é pra quem está nos escutando.
Não é legal setar o que é a gestão de projetos,
pedir uma definição Sim, lógico, não conseguiu pé mais tem boca.
E aí né?
E nesse meio fim, na visão de vocês, porque a vontade é a lei.
Ou Edu para definir a visão de vocês, o que é a gestão de projetos
dentro de desenvolvimento de um software?
Eu acredito que antes de a gente falar da gestão de um projeto,
a gente tem que olhar para um cenário de governança,
porque depende do
tipo de projeto, depende do tipo de necessidade
e também depende do tipo de apoio que você vai dar para a organização.
Você precisa estabelecer uma governança
sobre todo esse arcabouço de projetos
que a gente tem hoje implementando na prática.
Quando a gente já fala de um projeto, o projeto é uma atividade bem clara,
onde você tem um início,
um meio bem definido.
É o fim.
Então isso caracteriza o projeto e o projeto.
Ele é composto de uma fase inicial,
onde é necessário planejamento,
porque em cima do planejamento você vai determinar esses recursos
e esses recursos tem que estar ligado a sua estratégia de governança
dentro da implementação de qualquer tipo de projeto.
Terminou essa parte do planejamento definiu bem essas atividades.
Tem que colocar os recursos, que é a parte mais importante de um projeto.
Às vezes a gente brinca que temos a metodologia, temos o processo.
Mas apesar de dizerem que 70% de um projeto é a metodologia
e são os processos, o mais importante é você ter
o colaborador daquele projeto
endereçando a execução
na prática do dia a dia.
Então, para mim, são esses elementos importantes.
Quando a gente fala de um projeto
e aí você vai ter projetos de diferentes dimensões,
diferentes tamanhos e diferentes propósitos, melhorias evolutivas.
Projetos do zero, onde você vai fazer um desenvolvimento completo.
Uma implementação de um RP que é a característica de um projeto,
é diferente de um projeto de desenvolvimento de software.
Você tem projetos ligados a parte de manter a empresa funcionando,
Então você tem o dia a dia da empresa que está aqui funcionando.
Muita gente fala de ambidestria da empresa,
então você tem um lado que precisa desenvolver
a empresa e tem um outro lado que precisa manter a empresa.
Então, como que você lida com isso?
Por isso eu falo que a governança é um ponto importante
dentro de uma estratégia das e das diversas estratégias
que a gente tem para implementação de um projeto na prática legal
isso ai de você, principalmente porque essa brincadeira
sabia que você ia falar que esse projeto é só o início, meio e fim.
Tem todo um contexto por trás.
Por exemplo, se uma empresa quer implementar algo
sem fazer a gestão de projetos faz sentido,
até porque tem uma governança sobre isso.
Exatamente.
Você trouxe uma sopinha mais que às vezes você pega um aluno nosso.
Começou agora a desenvolver e pensa só vou desenvolver um sistema ecommerce.
E não é só isso, você já tem Tem um RP que você quer implementar,
uma empresa de grande porte. Exatamente.
Toda essa sopa, o Edu a gente já estudou junto, aí a gente brinca, quem começou
sabe muita regra, complica para o próximo que você não consiga sair bem dessa área.
E o que você tem para complementar? O que que é a gestão de projetos aí?
Bom Rafa, ainda bem que nós estudamos juntos, você me conhece um pouquinho aí
e sorte a minha que ele deixou pouca coisa pra eu falar, né?
Ainda bem que eu trabalho com ele e meu amigo também, né?
Então já conhecemos já um bocado de anos.
Aí fazem mais de 15 anos que nós trabalhamos
juntos, dez anos trabalhando juntos, então foi treinada essa conversa.
Não, não foi treinada, então ele complicou.
Ele sempre dificulta um pouquinho a minha vida,
mas você saber como você se sai.
Pois é, mas vamos lá, eu vou tentar simplificar um pouco mais
a abordagem que o Alexandre colocou, que foi bem completa,
mas eu colocaria o seguinte quem quer gerenciar projetos
tem que ter em mente que e gerenciar crises e mitigar riscos, ou seja,
não vai ter projeto que você não vai encontrar problemas para serem resolvidos.
Tem riscos, então tem quase nada, quase nada, quase nada, só pra fazer quase nada.
Você acha que vai acontecer?
Monitora ali, Monitora que pode acontecer.
Então eu acho que o principal ponto da gestão de projetos
é o monitoramento dos riscos e a mitigação dos riscos.
É a habilidade de gerenciar problemas.
Porque problemas vão acontecer. Então?
Esses são os principais requisitos que eu entendo no gerenciamento de projetos,
seja ele ágil, seja ela uma metodologia tradicional que é cascata
forever.
Então, já que você falou isso
do puxar outro tema, a gente tem tentou definir o que é gestão de projetos,
sem falar a tal gestão do PMP pelo e-book ou ágil.
Será que a gente consegue trazer essa sopinha
aí para a mesa dessa conversa, essa quantidade de coisas?
Eu acho que antes até da gente falar de metodologia,
entrar na abordagem, métodos,
eu acho que a gente é
uma pessoa
importante nesse cenário, que é o gerente de projeto legal
em alguns contextos, o gerente de programa, que é um programa,
um programa é uma coleção de projetos que vão estar
sendo executados em paralelo, sendo administrados
e que tem uma integração dentro de um contexto maior dentro da organização.
Essa é uma figura extremamente importante o gerente, porque
por mais que a gente coloque metodologia, métodos, processo,
um fator importante é o fator humano dentro de um projeto.
É a gestão.
E é aquele gerente que tem
a melhor habilidade na execução,
que tem aquele que
consegue entregar um projeto de forma
com qualidade no prazo.
Geralmente esse gerente ele tem uma habilidade fantástica
em gestão de pessoas,
que é um dos elementos importantes.
Quando a gente fala de projeto, porque projeto a gente vai ter lá o escopo,
a gente vai ter um método,
a gente vai ter os recursos físicos e os colaboradores,
que são aqueles que executam o projeto e vai ter aquele ou aquele, aquela pessoa
que vai fazer a orquestração de tudo isso, que é o gerente de projeto.
Então, a habilidade do gerente de projeto, ou seja, para mim
é 70% da habilidade do gerente, tá ligado no relacionamento?
Como é que ele trata os colaboradores, como é que ele agrupa
e gerencia aquele time, como é que ele traz o time,
engaja aquele grupo para entregar bem aquele projeto
e aí a gente pode falar poxa, dentro de um cenário,
a gente pode entender que existem metodologias melhores
para determinado tipo de problema,
existem metodologia e existe o ágil, que vai atender bem um determinado
problema tipo de problema existindo métodos em cascata ou métodos orientados.
A implementação de RP que geralmente está atrelado aos fabricantes
são processos que o próprio fabricante coloca para você
poder desenvolver poder seguir, poder trazer dentro de uma implementação.
Porque não é só o desenvolvimento de software
que a gente vai ter uma gestão de projeto, projeção de projeto pode
tem em diversos ramos de atividade,
até numa construção que se a gente pega
a engenharia de software que ela é, é um novo.
Dentro desse cenário de
desenvolvimento, a própria
construção já faz gestão de projetos,
faz a gestão da obra a muito tempo e ele aplica métodos
e também faz gestão de pessoas, enfim,
gestão completa de um projeto.
E a área de tecnologia se apropriou muito
desses tipos de abordagem de outras áreas em diversos.
Se a gente falar em design em diversos ramos da tecnologia, a gente se apropria
de alguma área do conhecimento e implementa dentro do nosso processo.
E é a gestão de projetos.
É isso.
A gente desenvolveu melhor para dentro da nossa,
das nossas atividades de engenharia de software.
Mas não é só um tipo de problema que a gente tem que resolver.
Quando a gente fala de gestão de projeto, vai depender
da necessidade e você vai ter a metodologia
que vai melhor se adaptar a essa necessidade.
E até para complementar ao que o Alexandre colocou,
eu gostaria também de também
acho que vale a pena a gente colocar o viés do colaborador que está,
que é o participante do projeto, tem um gestor, mas também tem o executor,
vamos dizer assim, do projeto.
E tem os executores que querem se tornarem líderes,
querem se tornarem gerentes dentro das organizações, gerentes de projeto.
E o que?
O que eu acho que é super relevante colocar
e corrobora com o que o Alexandre colocou é o que primeiramente,
a questão da comunicação, a questão de como lidar com pessoas,
isto tanto a parte gerencial quanto a parte dos colaboradores.
Nós vamos falar aos colaboradores,
as pessoas dos executores propriamente dito, dos desenvolvedores.
Eles tem que ter hoje uma capacidade de comunicação muito alta,
muito bacana entre todos os membros do time, inclusive com o gestor dele.
Então, se a gente está falando de de ágil, gente está falando com o Scrum.
Mas se a gente está falando de um projeto mais formal,
a gente tá falando um gerente de projeto propriamente dito.
Então eu acho assim
a capacidade é aqueles que buscam
a liderança, seja ele como gestor, seja ele como Scrum Master,
tem que ter essa capacidade de comunicação, gerenciar.
Eu digo que é 90% comunicar
e 10% você trabalhar com cronogramas,
trabalhar com Kanban, trabalhar com processos.
O principal é comunicação.
Além disso, ter atitude.
Se a pessoa para um projeto ser bem sucedido,
se as pessoas que estão nesse projeto tiverem atitude
positiva, atitude de realizar,
a grande probabilidade de sucesso é enorme nos projetos.
Envolve isso aí
que eu fiz um MVP
em 2011 Gestão de projetos nas práticas PMI
e o meu TCC foi focado na gestão da comunicação que você falou.
É a habilidade de lidar com as situações, foi o que ele falou.
A gente já sabe quais são os recursos, qual o escopo, qual é o custo previsto
antes de começar.
Você tem todo esse levantamento, projeto vai começar.
E aí, quem vai fazer essa maestria de tudo?
Andar bem sincronizado
é uma pessoa com habilidade de se comunicar, de entender, de mapear o risco.
E é uma coisa que não vem pronta e não vem pronto.
E aí, que legal que vocês falaram, porque a gente traz para o aluno.
Eles acham que na primeira aula a gente vai explicar
o que é Pi e mais acha e já sai também o que que é ágil.
O Scrum, por exemplo, a gente fala não, calma,
vamos falar primeiro que o projeto tem início, meio e fim.
Foi o que você falou.
Mas antes vamos falar algumas coisas.
Você tem que ter habilidade para participar do projeto
e aí o aluno às vezes até falar pra nós assim esse professor, você
tá muito acadêmico, solto o mundo da vivência e do profissional.
É por isso, até que a gente convida vocês.
É e foi provocativo.
Até foi legal você quebrar o mesmo falado do tema, acho que seja em cascata.
E vão falar do ágil ali falou.
Não vamos falar dessa habilidade, as coisas que acontecem antes do projeto
e se tocar em tema de percentual ali, por exemplo,
do desenvolvimento de um projeto de software.
E os alunos acham às vezes que 90% do tempo alocado em um projeto
é código, por exemplo, Se for pensar, esses já quebraram com alguns percentuais.
Aí é importante assim, né?
Código dentro de um projeto a 30%
quando você coloca dentro uma métrica,
porque se você não definiu bem seu escopo,
se você não realizou uma entrevista, é um levantamento, um mapeamento.
Independente da prática de
o método que você utilize
ajo ou processos unificados
que seriam mais voltados para a parte de cascata.
Então você tem a fase de análise.
Quando você faz análise, você tem que ir lá
no seu usuário entender o problema dele,
discutir com ele até o código, especificar o problema
depois que você especificou o problema, pensar como vai resolver o problema.
E aí, antes de ir para o código, ele vai ter que chamar um cara
de arquitetura e falar Cara, tem esse problema aqui.
Como é que a gente vai criar uma arquitetura que suporte
para solucionar esse problema para depois?
Você falou Olha, pensei em tudo, Você vai voltar o escopo na especificação,
na arquitetura, criamos uma arquitetura
que possa ser implementada de forma coerente
para a organização.
E aí você vai falar Poxa, agora
vamos trabalhar o código trabalhou código
e você entrou numa outra parte, que é a parte da qualidade do código.
Tenho que testar, tenho que verificar,
tem que fazer uma validação e depois
ainda tem que ter um aceite desse usuário para colocar em produção.
Então um projeto
ele não é código projeto.
O código é uma parte dentro do projeto e
se não você não pensa
as outras partes desse projeto de forma coerente.
A hora que você implementou o código você pode
está desenvolvendo algo que lá na frente você vai ter problema de performance,
você vai ter problema de integração, você vai ter problema de lentidão
da organização porque não vai conseguir utilizar a ferramenta.
Você pode ter problema de usabilidade porque você não pensou
como que o usuário vai utilizar aquela ferramenta.
Então existem vários elementos importantes
antes de chegar no código.
Isso não é de agora que a gente analisa dessa forma.
A gente brinca que hoje, com a transformação digital, todo mundo quer
inovar, sair desenvolvendo soluções dentro das organizações.
Isso não evento novo.
Na década de
90, existe um conceito chamado reengenharia.
Todo mundo queria
redesenhar seus processos
e aplicar tecnologia para resolver problema.
Na década de 90 só mudou nome e tesoura.
Aí, como é que você acha?
A gente tem alguns outros elementos que a transformação digital traz
dentro desse cenário da reengenharia, que naquele tempo
a gente não tinha nem tanto ferramentas, nem tantos métodos e nem
nem tinha descoberto ainda essa integração, tecnologia, negócio
naquele ainda estávamos engatinhando naquele tempo.
Então foi o tempo que começou a criar, desenvolver.
Foi quando veio a internet e aí o boom do crescimento tecnológico também surgia.
Exatamente. Só que hoje
não é
só código que você tem que pensar, porque você pode estar
desenvolvendo várias coisas dentro da empresa
e você está criando novamente um problema que no passado criaram,
porque durante a reengenharia
existiam várias áreas que começaram a querer desenvolver seu próprio
e suas próprias ferramentas internas nas áreas
e onde contratava um profissional de TI.
Eu posso falar que eu trabalhei
numa situação dessa, onde eu trabalhava na área, não na na TI
para desenvolver diretamente para aquela área
onde perdeu se o que o controle da tecnologia
que estava dentro organização.
E quando veio o advento
do ano dois do ano 2000
e com a chegada dos RPs, foi o gancho que teve para que?
Para que as empresas pudessem se reestruturar, se reagrupar, reagrupar
e centralizar novamente a tecnologia e pensar na arquitetura da empresa.
E se você pensar que arquitetura corporativa ela também tem aí
começa na década de 90 para cá arquitetura corporativa.
Ela tem o primeiro grande artigo lá dos.
Hackman foi o cara que escreveu a arquitetura corporativa
pensando o que cara, vamos estruturar a organização
e vamos criar uma arquitetura que integre tanto a TI como o negócio
que não tinha se desenhado, para que você possa aí começar a olhar
e sair desenvolvendo dentro da organização.
Então o RP ajudou muito nisso, porque o RP,
por ser um software que já tinha sua própria integração,
tinha seus elementos, já tinha todo o ASN,
as boas práticas implementadas.
Ajudou porque você já tem a arquitetura de pronto.
O negócio é falar da Ripper.
Ela é até para quem está nos ouvindo aqui em RP.
É um sistema que você pode comprar, como por exemplo, empresas como o Motos,
como esse a pé e você compra por módulos, que era a área de RH,
que era a área de logística.
Você vai lá e compra o status de uma vez que não é adequado ou estava lá
por módulos.
Eu vivi uma vez uma mudança de cálculo de frete
com uma multinacional, claro, s a p.
Abriu se um projeto para isso.
Fizemos um levantamento de escopo, mapeamento, muitas horas alocado,
muitas pessoas para isso e no fim o desenvolvimento foi feito.
Mas dentro dessa p foram horas tipo vai 10%.
Vamos supor que foram 500 horas de projeto.
Se fosse, foram 40 ou 50 horas de desenvolvimento.
Foi muito legal.
Mas qual que a parte boa se foi bem levantado,
bem documentado, não estamos nem falando do tipo de gestão.
Entrou em ambiente de regressão para prod.
Bom, aí subiu e olha que legal, você falou e deu certo.
Mas aí você vai me falar qual o que foi feito.
A gente não fez nesse que talvez seja um pouquinho
mais rápido que a gente daqui a pouco tenta definir.
Ai, e aí, você acha que dá para a gente falar um pouquinho aí dessa definição
da Alê ou colocar o Alê?
Colocou Apimentando, Apimentando?
Ele colocou o tema. Eu acho que até extrapolou
a gestão de projeto, colocou um tema estratégico, né?
Falando de arquitetura corporativa, aqui as coisas tem que andar junto.
Aí isso já colocou um plus dentro da conversa, dificultou mais, né?
Mas eu acho que agrega mais
para todo para todos nós aqui e aproveitando do vocês ajudam aqui.
Quem está nos escutando a falar, Pô, então o que o Rafa
e outros professores trazem não é coisa acadêmica, Estava brigado aí não foi
treinado, Você foi contra a verdade Aí na verdade não é isso, é script pré
script prévio, não teve treinamento, nem é uma ideia que flui.
Se não for, eu faço disclaimer aqui, então
fica a vontade.
Lá é assim, eu acho que
que é importante
Como? Como alguém comentou.
Como você comentou, o código é uma parte,
uma parte importante e significativa.
Mas antes de falar disso
e também tranquilizar o pessoal que está escutando a gente que é assim,
não fiquem com preocupados ou com medo de entrar na área de gestão, de projeto
ou em projetos,
mas que em qualquer outra profissão ou qualquer outra alta atuação
da sua atividade profissional, vão existir desafios.
Vou falar para vocês que projetos.
Quem gosta de desafios é um excelente ambiente para se trabalhar projetos.
Vão existir diversos tipos de desafios a serem superados
e eu gostaria de colocar.
Rafa, o ponto seguinte a gente está falando de metodologia de processo.
Já a questão estratégica dentro da organização de mitigação de riscos.
Falei um pouquinho lá atrás de gestão de problemas,
mas imagine assim a gente não falou ainda do nosso.
A gente falou que tem escopo, prazo, custo, mas imagine vocês lá dentro.
Parece simples o projeto, mas imagine vocês que
o executivo separa um valor,
um montante de dinheiro, mas o budget budget de 100.000 R$.
Vou colocar um valor hipotético aqui porque é alto
e alto, mas são projetos que são de milhões e app.
A gente fala em milhões, mas vamos colocar um número, um número
aí, 100.000 R$ e que durante o projeto você identifique situações
que aquele escopo que você está fazendo não vai atender
e que você não vai atender àquele escopo.
E ao invés de custar
100.000 R$ o seu projeto que você informou hoje à sua presidência,
você vai ter que informar que ele vai custar 200.000 R$.
Olha a complexidade que tem
do gerente do time que está sendo gerenciado.
Provêem informações para convencer
o seu presidente que seja o CEO dessa pequeno broker
desse mundo, o dobro de valor de valor.
Então, são situações como essa que são complexas
em ser administradas dentro do projeto.
E aí vão existir aqueles velhos ou velhos costumes.
Vamos identificar quem são os culpados e na verdade tem quem identifique os nomes
e não funciona assim.
Gente, um projeto Quando um projeto falha,
existe percentuais de falhas em diversos locais.
Não é só um local que falha, são diversas
falhas que aconteceram e aconteceu uma falha grande.
Então tem que se trabalhar a causa raiz, identificar essas causas,
os efeitos que elas geraram, consequentemente os impactos
e trabalhar planos de ações e contra argumentar com o presidente.
Pedir mais dinheiro que não é fácil, não é fácil.
É uma situação bem complexa e acontece no dia a dia.
A responsabilidade que tem um gerente nesse sentido é bastante alta.
Rafael, gostaria de colocar esse ponto que eu acho que
eu achei legal, até vinculando a parte de levantamento de escopo.
Se você está fazendo
a gestão, fez a previsão de 100.000, mas você faz ali um levantamento
que o budget não reflete devido ao que você levantou.
Vocês tem esse budget, mas baseado em todas as entrevistas,
o que a gente conversou, levantou na empresa em x dias
o não vai atender não é que a gente não quer.
Fazendo o volume aqui para vocês, a gente não vai entregar conforme a necessidade.
Aí eles tentam muitas vezes diminuir o escopo.
Esse falar deles é melhor nem fazer, né?
Às vezes é melhor nem fazer, mas se tiver bons argumentos,
que seria essa documentação, essa conversa,
você levantou que se não foi você que levantou, você que criou,
foi a equipe
da empresa que passou a toda essa parte do escopo.
E aí vai muito na linha do que ela é.
Como em toda a parte
estratégica, também financeira, um projeto,
ela tem que trazer algum resultado para a empresa.
Normalmente é alguma otimização processual,
alguma otimização
da produção que traga algum venda, aumento de venda, ou seja, que traga
algum benefício tangível, normalmente financeiro, para a organização.
Se você conseguir provar o projeto estava 100.000,
vai passar 200.000, mas você vai ter tais ganhos totais, ganhos.
É uma maneira de você encontrar o ROI aí que seja bom ou ruim.
É isso aí.
Você deve defender direto projetos, principalmente vocês.
A parte de consultoria, essas conversas devem ser bem agradáveis.
O fato, acho que para nós, assim,
a defesa do projeto está mais ligada na abordagem
que é na estratégia de entrega de como vai ser desenvolvido
esse convencimento de que o projeto vai dar retorno.
O projeto vai ter
um benefício para a empresa,
geralmente parte da própria empresa ou parte das pessoas que estão ali
integradas no dia a dia do negócio
e que dentro de uma solução ou dentro de uma estratégia,
ou dentro de uma análise de problema que eles identifiquem,
eles vão trazer uma solução que vai envolver tecnologia
e dentro disso eles vão aí abrir pra gente não é algo como consultoria,
oportunidade de participar de um processo de
de de venda, da solução.
Às vezes a gente ajuda e muitas vezes a gente ajuda eles a construir
a defesa mais.
Geralmente quem defende o mesmo é a própria organização,
os próprios gestores da organização, que dentro dessa estratégia
vão levar para o board ou para um comitê para apresentar
quais seriam os projetos e que benefícios eles trariam para a empresa.
Mas geralmente são vocês de consultorias que alimentam ela com essas informações
para eles levarem para as vezes a gente alimenta assim, participa
de um projeto de levantamento, é um projeto mais de consultoria,
não seria nem um projeto de desenvolvimento nem de análise.
É um projeto mais consultivo e aí a gente ajuda eles a desenhar
a solução, a ideia é como resolver o problema, mas de fato
é quem defende isso
vai ser a própria própria empresa
pelos próprios gestores perante a empresa.
É legal o tema que você trouxe aí a gente acabou falando de ROI, mas
nem sempre um projeto de desenvolvimento de um sistema de implementação do
s API aí não é só voltada para a parte do retorno financeiro.
Às vezes você está fazendo uma implementação para ter um mitigar risco
fiscal ou a operação parar diretamente.
Ele só trazem qual é a parte financeira e aí tem essa visão de processo
e até mesmo essa parte fiscal ainda mais brasileira.
É difícil
e é importante a gente também olhar que às vezes
um projeto pode ser uma evolução tecnológica.
Muitas empresas demoram
para investir em tecnologia.
É um dos problemas que as empresas têm
hoje é a obsolescência tecnológica, tanto de hardware como de software,
porque é um ativo que já está,
muitas vezes, já está e
não tem uma reposição
da organização na parte sistêmica
e de software, não tem uma evolução daquela ferramenta, daquele
e a evolução da própria ferramenta para uma nova tecnologia.
E aquela empresa acaba ficando com um parque tecnológico obsoleto.
Muitas empresas hoje que querem ir para um processo de transformação digital
encontram uma dificuldade.
Por quê?
Porque a sua arquitetura
ainda é uma arquitetura monolítica.
Então ele precisa se atualizar
e muitas coisas ainda para poder começar a trazer novos elementos
e de inovação, de transformação para dentro do negócio.
Então, esse é um ponto importante que tem que ser pensado
dentro das organizações de negócio. Elas.
Se ele quer implementar uma tecnologia, mas às vezes para implementar
aquela nova tecnologia, aquele projeto antes,
ele tem que tomar outras ações, até que ele desenvolveu seu sistema
para que esse sistema possa integrar com a nova tecnologia
ou criar uma situação ali
de convivência, onde você convive com
a sua situação atual
e o que você está trazendo para o futuro.
Só que sempre tem uma perda na mão, porque
o meio natural é a obsolescência da tecnologia
e você aí acaba perdendo algumas vantagens aí, dependendo da tecnologia.
Então é isso que é importante também olhar nesse cenário, quando a gente
vai falar de criar novos projetos, fazer inovação, desenvolver novas soluções
e até pegando isso.
Quando a gente fala no mundo corporativo, a gente não tem, não é?
País das Maravilhas.
Tá no ar as pessoas que estão iniciando agora, vocês que estão iniciando agora,
muitos na área vão encontrar.
Pô, vou lá, eu vou chegar a desenvolver, Não, você vai desenvolver, você vai,
você vai chegar, desenvolver, você vai entender o projeto,
mas você vai ter que seguir algumas regras e padrões, inclusive de conformidade.
As padrões, os requisitos legais.
Hoje a gente tem o LGPL, o LGPD,
que são as políticas de saber Security Security,
plantar diretamente no código, pois você tem as questões que você vai ter
que seguir, Não é sentar lá, simplesmente lá você desenvolver e está pronto, não.
Você vai ter uma documentação,
você vai ter que seguir essa documentação,
alguém vai validar, vai fazer um perceber o que você está fazendo, está certo
mesmo ou ter ferramentas para validar se aquilo que você está desenvolvendo
está em conformidade para garantir acessos indevidos
para não ter violação de dados.
Então, assim,
não existe país das maravilhas,
tem que colocar realidade aqui, certo?
Rafael Tem que colocar, pode colocar, pode ser até um ponto nesse gancho
que às vezes o nosso aluno com a gente corrige uma atividade, acontece.
O Rafa tirou 10% da nota porque no código algum professor aqui eu não segui boa
prática ou não fiz a identação do código ou não comentei código.
Foi sim, estava escrito no exercício.
Se você entregar funcionando, mas não seguir, boa prática, perde três pontos
ali. Fala porque?
Porque dentro de uma governança, entre uma gestão, de um projeto,
de uma empresa, você tem que segui las, porque você não está trabalhando sozinho.
Mesmo que tivesse trabalhado sozinho.
Depois você desse esse código
e provavelmente alguém vai fazer reengenharia
ou vai ter que analisar para criar o novo sistema.
Não é o exemplo clássico, porque, por exemplo, a gente falou de programação
e um eu já fiz várias entrevistas na época,
quando ainda cuidava dessa frente de desenvolvimento,
eu perguntava Cara, as perguntas que eu fazia.
O que acontece se você fizer um select asterisco dentro da base?
Será que você pergunta, fala não sei, você vai fazer ou não faz?
Não, pera ai o cara olhar?
Eu perguntei Mas que pergunta é essa?
Você sabe o impacto que você tem?
Colocar um asterisco sem um lugarzinho para travar?
Pois é.
Porque se você não criar, se você colocar isso no seu código,
você vai ter o impacto lá na frente, que em performance, dependendo
de que tipo de dado você está pensando, de que tipo de tabela você está
acessando, então não é uma boa prática você utilizar isso
dentro do seu código.
Ah, e as empresas geralmente tem seus manuais de
de de boas práticas de programação, regras de programação.
Então são perguntas que eu fazia na entrevista para já mapear
o quanto aquele e aquele desenvolvedor
tinha habilidade para desenvolver determinado tipo de código.
O para onde eu ia direcionar ele para o desenvolvimento.
Você falou um para um ponto que eu vivi isso.
Eu trabalhava multinacional, eu comecei como desenvolvedor
e aí estava atendendo a área de vendas, área de vendas, uma multinacional base
muito alta e aí vez escalados da alta gerência, um desenvolvedor júnior,
um e-mail falando por que a gente tem que formar, qual é o range de clientes
que a gente quer enxergar?
Eu quero clicar e baixar toda a base de clientes.
Nossa, por sorte, eu, Júnior, desenvolvedor, muitos anos atrás,
eu tive a maturidade de perguntar ao meu coordenador técnico houve escalada
que da alta gerência de vendas ele não tem culpa, Mas oh,
eu entendo que se eu atender e tirar o era aqui, o que você falou
rapidinho tira sobra em testes, aí não vai dar impacto para subir a produção.
Só que se eu subir isso daqui, o outro não uso o relatório, se o sistema não cair
até explicar para essa pessoa se executivo da área de vendas,
que se eu fizer isso atrapalha a performance, vicia, dá stress.
Foram falar com ele, falou Então compra o servidor novo,
nem se você comprar mais muito tempo atrás e resolver.
Bem interessante essa fala,
mas por alguns segundos eu como um júnior vou ser bem transparente.
Eu pensei em fazer hora que fez calado, quase levando uma bronca.
Eu falei Pera aí, eu disse não faz sentido.
Eu como desenvolvedor, só que eu consultei não é bom isso,
mas conta que a maturidade na Rafa existe em Passos, né?
Não adianta, você pode ter uma excelente lógica de programação que não
Será que essas teorias vai rolar?
Vai travar tudo, mas a senioridade você mede inclusive sobre isso.
Mas que impactos que eu posso ter fazendo isso?
Então são etapas que você acaba adquirindo não somente com o aprendizado
da linguagem de desenvolvimento,
mas com a experiência que você tem a vivência dentro dos projetos.
Pô, eu fiz isso aqui, o vício aqui posto aqui pode impactar.
Se eu fizer isso aqui, eu não sei o que pode acontecer,
mas deixa eu fazer uma ponte aqui para ver se pode gerar impacto.
Mas vou te falar que a dor na pressão eu confirmei.
Eu voltei a professora.
Essa história que hoje eu lembro, Júnior,
serviu de experiência, crescimento mesmo.
Pera aí, eu atendo ele, mas meu coordenador técnico aqui vai dar ruim.
Aí eu falei Serjão pergunta ele quer fazer, eu faço, mas vai parar.
Tudo bem que você não fez. Onde dar esse problema?
Eu vou falar com essa pessoa.
Não foi fácil.
Ele teve que lidar com situação de conflito.
Mas enfim, esse é o tipo de
desafio que
inclusive um gerente tem de terminar em identificar
quem são essas esses colaboradores que vão trabalhar com ele,
qual nível de senioridade,
que tipo de desenvolvimento
é melhor para cada um poder desenvolver.
Hoje gente fala que tem o front end e o back end,
então isso já é um tipo de segregação de função para o desenvolvedor.
Tem profissional que vão conseguir fazer melhor
o front end, tem profissionais que vão fazer melhor
o back end, tem profissionais que conseguem fazer as duas pontas,
mas no passado.
Hoje, por exemplo, você tem ferramentas que te ajudam a fazer
auditoria no código ou fazer uma expressão de código.
No passado ainda não
tinha. E aí
os Legacy é onde tinha,
aí é onde entravam as metodologias
que algumas dessas metodologias tinham.
Uma etapa importante que era fazer um peer review no código,
então e aí?
Com a evolução da metodologia, com a evolução das ferramentas,
com a evolução das tecnologias, isso facilitou muito
a vida, prega o desenvolvimento em pares, não seria um pegar, viu?
Mas é basicamente isso.
E tem gente que não quer trabalhar nessa, que fala que é muito estressante
porque é estressante até pra mim é uma segurança.
Toda vez antes de eu mandar esse código para hackear, por exemplo, eu te ajudo.
Se passa pelo meu parceiro de revisão, que é o Edu,
é uma segurança, eu sei desenvolver é um problema.
E eu vou dizer uma coisa para você hoje
a questão de código está tão.
A questão de tecnologia está tão crítica
que para mim a gente deveria ter responsabilidade civil
sobre os códigos que a gente desenvolve
penal e civil.
Ai ele já pegou. Tá vendo por que?
Porque hoje você desenvolve software para avião, para carro,
você desenvolve software para.
Só que você não tem
responsabilidades, não sabe lidar com aquilo que você desenvolveu.
É diferente de você,
do médico, o médico, ele não tem.
Ele vai pedir dez consulta pra MD, ele assina por aquilo ali.
Se o seu paciente tiver algum problema, ele é responsável sobre aquilo.
Para você fazer uma construção, não tem um engenheiro que assina embaixo
e vai o CREA dele naquele documento.
Então eu acho que
falta na área de tecnologia também.
Acredito que
algo desse sentido para que as pessoas criem mais consciência
quando desenvolverem um software ou quando criarem um código
de desenvolver um código para algum programa, algum sistema.
Você não está falando em burocratizar, não é isso,
não é isso é trazer a responsabilidade legal
para não ter esse tipo de coisa que você acabou de dar.
Exemplo Não, eu não quero trabalhar porque eu vou fazer uma verificação
sobre o meu trabalho.
Não, não estou fazendo uma verificação de sobre seu trabalho.
Estou fazendo um peer review para garantir que você não vai ter um problema
a hora que você implementa sistema quer dizer o que você está fazendo.
Você não viu que se fizer por mal só vai dar um pouco não sei o que melhor
a perform, porque você tem código hoje, programas e software
desenvolvido em várias situações
você tem numa hidrelétrica, você tem software,
você tem software no avião, você tem software no automóvel,
na área da saúde, você software na área da saúde,
você hoje tem software em tudo quanto é área
do conhecimento.
Então, assim você também deveria ter responsabilidade
sobre aquele código que você escreve.
É legal quando você cria um podcast.
Vocês conseguiram trazer esse contexto, porque para quem está nos escutando,
Porque se você achava que você ia ter uma resposta O que é um projeto?
O que é?
Qual o melhor gestão de projeto ágil ou em cascata ou permite in box?
Seja, você não ia nenhum momento dar uma pausa e fazer uma anotação breve.
Isso não se é uma aula, Às vezes o professor faz uma definição.
Anota aí que vai cair na prova, tá?
A ideia aqui era para trazer na mesa mais coisas aí que ele trouxe o Edu aí.
E não é para te deixar confuso na verdade, é você entender
que quando você faz uma gestão de projeto, não é só olhar o seu documento,
pedir pra alguém 80% do tempo do projeto rodar, tá entregue.
Se for ágil, melhor ainda que vai fazer.
A qualidade nem sempre se move. Verdade.
Se for poema, o escopo conhecido, então depende.
Se negociou com seu cliente, então é isso que era o tópico da nossa conversa.
E aí eu trago para uma última, leia duas e fica a vontade pra
quem quer ser o primeiro, para quem está nos escutando, nos.
O que você deixa de dica primeiro que a gente está falando
é que os alunos que estão escutando é um aluno do nosso da graduação.
Às vezes ele já tem experiência ou não, mas principalmente
isso, começaram o desenvolvimento.
Eu comecei, acredito que vocês também.
E aí largar o desenvolvimento, porque só 30% vocês deixam de dica
para quem está nos escutando.
Uma frase de fechamento de cada um, favor, um contexto,
uma dica para quem
é desenvolvedor ou que está na carreira de engenharia de software.
Aí tanto em teste, desenvolvimento, análise,
migrar para um cargo
de gestão
é o que a gente colocou aqui.
Vai lidar com pessoas,
pessoas do projeto, pessoas da sua empresa,
usuários e o cliente,
os gestores do cliente.
A pessoa tem que avaliar o quanto ele vai,
o quanto ele está se desenvolvendo
em relação ao relacionamento com as pessoas,
que isso é fundamental.
É mais até do que a metodologia,
é mais até do que saber codificar ou não.
Então ele tem que definir bem
para onde ele quer direcionar a carreira dele.
E hoje a gente sabe que eu
não preciso tomar uma decisão de ir para uma carreira de gestor.
Tem pessoas que continuam na trilha técnica.
Esses jovens formam um super.
Isso se transforma.
Especialistas se transformam em técnicos,
em líderes técnicos dentro das equipes,
se transformam em excelentes arquitetos.
E não necessariamente precisam estar num cargo
de gerente de projetos ou num cargo de de Scrum Master.
Enfim, por quê?
Porque grande parte desse trabalho é a habilidade de trabalhar a equipe,
a colaboração do time, para que consiga naquele
produto que você pensou.
Eu cheguei no final com ele
concluído e entra em produção e o cliente fica satisfeito
ou a empresa fica satisfeita com aquilo que foi feito.
Então, esse é o ponto importante que tem que ser avaliado.
Eu não pensar só em código, não pensar só em organização.
Se ele tem a pretensão de ser um gerente, de ir
uma carreira, de gestor,
virar um diretor, crescer para um lado mais executivo,
ele vai ter que analisar e ver qual é,
qual é o gap que ele tem em relação à parte humana.
A soft skill ali, exatamente.
Falar é um software já preparado para guardar, aguardando aqui.
Mas eu tenho medo
de não entender só essa palavrinha do do que eu tomo essa dica aí.
Tá bom, deixa a dica pessoal.
É o seguinte eu acho que muitos dos alunos, alguns pelo menos,
acredito que já tenho escutado que muitas vezes
as pessoas são contratadas pelos hard skills,
que são os ar de skills, são os conhecimentos técnicos.
Então quando você fala engenharia de software você está boa,
ganhando conhecimento técnico, que são hard skills,
porém elas são demitidas pelo soft skill, que são os soft skills.
É a capacidade de comunicação, é a capacidade de colaboração
de como trabalhar em equipe.
Então o recado a dica que eu dou é o Hard Skill.
Você vai ser contratado rádio.
Por isso que a gente tem que estudar, a gente vive nela, a gente
aqui, nós três aqui estuda muito.
Doutora fazendo doutorado, agora
sofrendo, está mais à frente ela ler, fazer doutorado.
Eu parei no mestrado
ou doutorado, vamos ver.
Acho que vou então assim.
Mas é super importante trabalhar essa frente de soft skill,
independente da carreira, se a carreira técnica
ou se é carreira gerencial, é para quem quer ser líder.
Uma dica que eu digo é liderança não é dada.
Se é conquistada, não é necessário você ter um cargo de gestor
para você se tornar um líder dentro da sua equipe.
A própria equipe consegue reconhecer o líder quando
existe dentro desse grupo de pessoas.
Então, gente, não precisa esperar
virar gerente para se tornar líder.
Normalmente é o contrário.
Você vai se tornar um líder conquista para depois
você se tornar um gerente, ou um executivo, ou um cargo de gestor.
Então vai pra cima sem medo de ser feliz.
Ousadia com responsabilidade
e bora agilidade.
XO agradecer aí a sua presença
e a liberdade que você teve de trazer os temas até de uma maneira até polêmica.
Edu Também nessa liberdade é com certeza soma para os nossos alunos.
A gente sempre fala, vai além dos nossos materiais
que a gente deixa disponível, que o professor ensina, escuta
e também os profissionais de mercado que a gente traz
para vocês verem que o que às vezes a gente cobra,
porque a gente vê um dizer chato na hora de uma correção,
e sim porque a gente quer que você entenda
que o mercado trabalha nem sempre como tá a cartilha do Agile, por exemplo.
Isso ai Edu, agradecer também a sua presença e da mesma forma e
a liberdade você teve para trazer os temas e até mesmo somar para os nossos alunos.
Obrigado!
E você aluno, deu pra entender que para você
fazer uma gestão de projetos não basta apenas você saber
fazer a gestão, mas também tudo o que tem envolvido.
Vou ficando por aqui e até uma próxima.