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.
Então eu acho que a conversa vai estar boa,
principalmente porque vocês tem
a vivência na prática, no dia a dia, né?
Falar aqui que não é só a visão,
mas sim a vivência.
Para quem está nos escutando,
é legal setar o que é a gestão
de projetos, uma definição.
Lógico, né, vamos seguir
o PMI/PMBOK, início, meio e fim, né?
Fiquem à vontade, Alê ou Edu, para definir.
Na visão de vocês, o que é
a gestão de projetos
dentro de desenvolvimento de um software?
Eu acredito que, antes de falarmos
da gestão de um projeto,
temos 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 temos hoje
implementando na prática.
Quando já falamos de um projeto,
o projeto é uma atividade bem clara,
onde você tem um início,
um meio bem-definido, e o fim.
Então isso caracteriza o projeto.
O projeto é 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 ligados
à 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 brincamos que temos
a metodologia, temos o processo,
mas apesar de dizerem
que 70% de um projeto
são a metodologia e 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
os elementos importantes
quando falamos 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á funcionando.
Muita gente fala
de ambidestria da empresa.
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 das diversas estratégias que temos
para implementação
de um projeto na prática.
É legal ouvir isso aí de você, Alê,
principalmente porque essa brincadeira...
Eu sabia que você ia falar que esse
projeto não é só o início, meio e fim, né,
mas 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.
E aí você trouxe uma sopinha a mais,
porque às vezes você pega um aluno nosso,
que começou agora a desenvolver, e ele pensa:
"Só vou desenvolver um sistema e-commerce".
E não é só isso.
Às vezes você já tem um RP
que você quer implementar
numa empresa de grande porte.
Exatamente.
Você trouxe toda essa sopa.
Edu, nós já estudamos
junto, aí nós brincamos
que quem sobe muito a regra
complica para o próximo, né?
Não que você não consiga
sair bem dessa, né?
E aí? O que você tem para complementar?
O 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 para eu falar, né?
Ainda bem que eu trabalho com ele,
e é meu amigo também, né?
Então já nos conhecemos
há um bocado de anos.
Faz mais de 15 anos
que nós trabalhamos juntos...
Dez anos trabalhando juntos.
Então foi treinada essa conversa aí?
Não, não foi treinada.
Ele complicou. Ele sempre dificulta
um pouquinho a minha vida.
Só para 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 é
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?
Quase nada.
- Quase nada?
- Quase nada.
- Só para saber.
- Quase nada.
Você acha que vai acontecer?
Monitora porque pode acontecer.
Então eu acho que o principal
ponto da gestão de projetos
é o monitoramento dos riscos,
é a mitigação dos riscos,
e 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 ele
uma metodologia tradicional,
que é cascata, "whatever".
Então, já que você falou isso, de puxar outro tema,
nós tentamos definir o que é gestão de projetos,
sem falar a tal gestão do PMI,
do PMBOK, ou ágil.
Será que conseguimos trazer essa
sopinha para a mesa da conversa,
essa quantidade de coisas?
Antes até de falarmos de metodologia,
entrar na abordagem métodos, né,
eu acho que temos uma pessoa
importante nesse cenário,
que é o gerente de projeto.
Em alguns contextos,
o gerente de programa.
O que é um programa?
Um programa é uma coleção de projetos
que serão 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,
Por quê?
Por mais que coloquemos metodologias,
métodos, processos,
um fator importante é o fator
humano dentro de um projeto.
E a gestão, aquele gerente que tem
a melhor habilidade na execução,
que consegue entregar um projeto...
Com qualidade no prazo.
esse gerente geralmente tem uma habilidade
fantástica em gestão de pessoas,
que é um dos elementos importantes
quando falamos de projeto.
Porque no projeto, nós vamos ter lá
o escopo, vamos ter o método,
vamos ter os recursos físicos
e os colaboradores,
que são aqueles que executam o projeto,
e vai ter aquela pessoa que vai fazer
a orquestração de tudo isso,
que é o gerente de projeto.
Então, a habilidade do gerente de projeto,
para mim, 70% da habilidade do gerente,
está ligado ao relacionamento.
Como ele trata os colaboradores,
como ele agrupa e gerencia aquele time,
como ele traz o time, engaja aquele grupo,
para entregar bem aquele projeto.
E aí podemos falar que,
dentro de um cenário,
existem metodologias melhores
para determinado tipo de problema.
Existe o ágil, que vai atender bem
um determinado tipo de problema,
existem métodos em cascata, ou métodos
orientados à implementação de RP,
que geralmente estão
atrelados 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 vamos ter uma gestão de projeto.
A projeção de projeto tem
em diversos ramos de atividade.
Até numa construção, que se pegarmos
a engenharia de software,
que ela é nova dentro desse
cenário de desenvolvimento,
a própria construção já
faz gestão de projetos,
faz a gestão da obra há muito tempo, 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 falarmos em diversos
ramos da tecnologia,
nos apropriamos de alguma
área do conhecimento
e implementamos dentro do nosso processo.
E a gestão de projetos é isso,
desenvolvemos melhor
para dentro das nossas
atividades de engenharia de software.
Mas não é só um tipo de problema
que temos que resolver
quando falamos de gestão de projeto.
Vai depender da necessidade.
E aí você vai ter a metodologia que melhor
se adaptar a essa necessidade.
E, Rafa, até para complementar
o que o Alexandre colocou,
eu acho que vale a pena
colocarmos o viés do colaborador,
que é o participante do projeto.
Tem o gestor, mas também tem
o executor, vamos dizer assim, do projeto.
E tem os executores
que querem se tornar líderes,
querem se tornar gerentes dentro
das organizações, gerentes de projeto.
O que eu acho que é
superrelevante colocar,
e que corrobora
com o que o Alexandre colocou,
é primeiramente a questão da comunicação,
a questão de como lidar com pessoas,
tanto a parte gerencial
quanto a parte dos colaboradores, dos...
Não vamos falar colaboradores.
Dos executores, propriamente dito,
dos desenvolvedores,
eles têm 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 estamos falando de ágil,
estamos falando com o Scrum Master.
se estamos falando
de um projeto mais formal,
estamos falando de um gerente
de projeto, propriamente dito.
Então eu acho assim:
aqueles que buscam a liderança,
seja ele como gestor,
seja ele como Scrum Master,
tem que ter essa capacidade
de comunicação.
Eu digo que gerenciar é 90% comunicar
e 10% você trabalhar com cronogramas,
trabalhar com Kanban,
trabalhar com processos.
O principal é comunicação.
Além disso, ter atitude.
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.
Legal ouvir isso, Edu e Ale,
porque eu fiz um MBA em 2011,
"Gestão de projetos nas práticas do PMI",
e o meu TCC foi focado
na gestão da comunicação.
Que foi o que você falou, é
a habilidade de lidar com as situações.
Eu acho que foi o Ale que falou.
Nós já sabemos quais são os recursos,
qual o escopo, qual é o custo previsto.
Antes de começar,
você tem todo esse levantamento.
O projeto vai começar, 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, né, Ale? Né, Edu?
Que legal que vocês falaram,
o que trouxeram para o aluno.
Eles acham que, na primeira aula,
vamos explicar
o que é PI e mais acha e já sai também
o que que é ágil.
O Scrum, por exemplo,
nós falamos: "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.