PBL ESO ANO 01 FASE 05 2024 VIDEOCAST PROJETOS & TI

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
e entregá-lo 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.

Nós vamos falar sobre a gestão,

que é a parte tão importante
na entrega de um software.

Eu sou o Rafael Ronqui
e estou aqui com dois convidados.

Vou apresentar para vocês
o Alexandre.

Olá, Alexandre, tudo bem? Como você está?

Tudo bom, Rafael?

Obrigado pelo convite.

Eu trabalho hoje como responsável
de operações Brasil da Softtek.

É um prazer estar aqui com você.

Show!

E aí, Eduardo, tudo bem? Como você está?

Se você puder apresentar para quem
está nos escutando, por favor.

Claro.

Primeiramente,
obrigado pelo convite, Rafael.

Bom, meu nome é Eduardo Floriano,
eu trabalho há dez anos na Softex,

sou responsável por algumas verticais
de negócio, pelo delivery,

então eu tenho que gerenciar
alguns projetos aí,

ou melhor, algumas centenas de projetos.

Então o desafio é bastante interessante.

Legal.

Eu 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 é só a visão,
nem sem a vivência.

Começar é para 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.