-
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 é isso.
-
Mas 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 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! Eduardo, tudo bem com você?
-
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.