-
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?
-
- Não vem pronta.
- Não.
-
Que legal o que vocês falaram,
porque quando nós trazemos para o aluno,
-
eles acham que, na primeira aula,
vamos explicar o que é PI
-
e também o que é ágil
e 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, como
você ter habilidade para participar do projeto.
-
E aí o aluno às vezes até falar para nós:
"Professor, você está muito acadêmico.
-
Solta o mundo da vivência do profissional".
-
É por isso até que convidamos vocês.
-
E foi provocativo.
-
Foi legal você quebrar.
-
Vamos falar do PMI, ou seja,
em cascata, e vamos falar do ágil.
-
O Ale falou: "Não, vamos falar dessa habilidade,
das coisas que acontecem antes do projeto".
-
E vocês tocaram no tema de percentual dentro
do desenvolvimento de um projeto de software.
-
E os alunos às vezes acham que, 90% do tempo
alocado em um projeto é código, por exemplo.
-
Vocês já quebraram com alguns percentuais aí.
-
Importante assim, né...
-
Código dentro de um projeto é 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,
-
independentemente da prática
ou o método que você utilize,
-
ágil ou processos unificados, que seriam
mais voltados para a parte de cascata.
-
Então você tem a fase de análise...
-
Quando você faz a análise,
você tem que ir lá no seu usuário
-
entender o problema dele,
discutir com ele,
-
especificar o problema.
-
Depois que você especificou o problema,
pensar como vai resolver o problema.
-
E aí, antes de ir para o código, você ainda
vai ter que chamar um cara de arquitetura
-
e falar: "Cara, tem esse problema aqui.
-
Como vamos criar uma arquitetura
que suporte solucionar esse problema?".
-
Para depois você falar: "Olha, pensei em tudo.
-
No escopo, na especificação, na arquitetura.
-
Criamos uma arquitetura
para a organização
-
que pode ser implementada
de forma coerente".
-
E aí você vai falar: "Puxa,
agora vamos trabalhar o código".
-
Trabalhou código, aí você entra numa outra
parte, que é a parte da qualidade do código.
-
Eu tenho que testar, eu tenho que verificar,
-
tenho 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 não é código.
-
O código é uma parte dentro do projeto.
-
E se não você não pensar as outras partes
desse projeto de forma coerente,
-
a hora que você implementar o código,
você pode desenvolver 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.