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 ser boa,

principalmente porque vocês têm 
a vivência na prática, no dia a dia, né?

Falar aqui que nem é 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 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 têm 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 à 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 e-commerce".

E não é só isso.

Às vezes vai ter 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 régua 
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ó 
no desenvolvimento de software

que vamos ter uma gestão de projeto.

A gestão de projeto pode ter
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 Alê,

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ê já 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,
já 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 
de algumas habilidades

que você vai ter que ter 
para participar do projeto.

E aí o aluno às vezes até fala 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 até provocativo.

Foi legal você quebrar.

Vamos falar do PMI, ou seja, 
em cascata, e vamos falar do ágil.

O Ale falou: "Não, antes, 
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 o usuário vai utilizar 
aquela ferramenta.

Então existem vários elementos importantes

antes de chegar no código.

Não é de agora que analisamos dessa forma.

Nós brincamos 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 1990,

existia um conceito chamado "reengenharia".

Todo mundo queria 
redesenhar seus processos

e aplicar tecnologia
para resolver problema.

Na década de 1990.

Será que só mudou nome, ou gourmetizou?

O que você acha?

Nós temos alguns outros elementos
que a transformação digital traz

dentro desse cenário da reengenharia,
que, naquele tempo,

não tínhamos nem tantas ferramentas,
nem tantos métodos,

e ainda nem tínhamos descoberto
essa integração tecnologia/negócio.

Ainda estávamos
engatinhando naquele tempo.

Então foi o tempo em que se começou
a criar, desenvolver.

Foi quando veio a internet, e aí o boom
do crescimento tecnológico nas organizações...

Fora implementar a tecnologia, né?

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 estar criando novamente
um problema que no passado criaram.

Durante a reengenharia, 
existiam várias áreas

que começaram a querer desenvolver

as suas próprias ferramentas 
internas nas áreas,

e onde contratavam um profissional de TI.

Eu posso falar que eu trabalhei
numa situação dessa,

onde eu trabalhava na área, não na TI,

para desenvolver diretamente 
para aquela área

onde perdeu-se o controle da tecnologia

que estava dentro organização.

E quando veio o advento do ano 2000

e com a chegada dos RPs,
foi o gancho que teve.

Para quê?

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

também começou na década de 90 para cá,

arquitetura corporativa tem 
o primeiro grande artigo do Zackman,

que foi o cara que escreveu
a arquitetura corporativa,

pensando o quê? "Cara,
vamos estruturar a organização

e vamos criar uma arquitetura 
que integre tanto a TI como o negócio,

para que você possa aí começar a olhar

e sair desenvolvendo
dentro da organização.

E o RP ajudou muito 
nisso, porque o RP,

por ser um software que já tinha a sua 
própria integração, tinha seus elementos,

já tinha todas as boas 
práticas implementadas,

ajudou porque você já tem
a arquitetura pronta ali.

É legal você falar da RP, Ale,

até para quem está nos ouvindo aqui,

RP é um sistema que você 
pode comprar, por exemplo,

empresas como a Tottus, como o SAP,
e você compra por módulos.

Se você quer a área de RH,
a área de logística,

você vai lá e compra, instala tudo 
de uma vez, o que não é adequado,

ou instala por módulos.

Eu vivi uma vez uma mudança de cálculo 
de frete numa multinacional,

que lá era o SAP.

Abriu-se um projeto para isso.

Fizemos um levantamento de escopo,
mapeamento, muitas horas alocado,

muitas pessoas para isso, e, no fim, 
o desenvolvimento feito dentro desse SAP

foi de horas, tipo 10%.

Vamos supor que foram 
500 horas de projeto.

Se foram 40 ou 50 horas 
desenvolvendo, foi muito.

Mas qual foi a parte boa?

Se foi bem levantado, bem documentado...

Nem estamos falando de tipo de gestão.

Entrou em ambiente 
de regression, pré-prod...

Aí subiu.

E olha que legal o que você falou.

E deu certo.

Mas aí você vai me falar:
"Qual que foi feito?".

Nós não fizemos nesse que talvez 
fosse um pouquinho mais rápido, né,

que daqui a pouco tentaremos definir.

E aí, Edu, você acha que dá para falarmos
um pouquinho dessa definição?

Dá sim.

O Ale colocou um tema...

- Está apimentando, hein? 
- Está apimentando.

Eu acho que até extrapolou
a gestão de projeto.

Ele colocou um tema estratégico, né,

falando de arquitetura corporativa...

- Que as coisas têm que andar juntas, né?
- Juntas, né, TI e negócio.

Já colocou um plus dentro da conversa.

Dificultou mais, né,
mas eu acho que agrega mais

para todos nós aqui.

E aproveitando, Edu e Ale, vocês 
ajudam quem está nos escutando

a saber que, o que o Rafa 
e os outros professores trazem,

não é coisa acadêmica.

Obrigado!

Isso não foi treinado.

Você foi e contou a verdade aí.

Não, não, é isso mesmo.

Não teve script prévio.

Não teve script prévio, não 
teve treinamento nenhum, tá?

- Saiu na raça aqui.
- Fluido.

- Fluido.
- Que bom.

Se não for, eu faço 
disclaimer aqui, tá bom?

Não, não, não. Está fluido.

- Pode ficar à vontade aí.
- Vamos lá.

Eu acho que é importante...

Como o Ale, comentou,
como você comentou,

o código é uma parte 
importante e significativa.

Mas antes de falar disso,

é também tranquilizar o pessoal 
que está nos escutando.

Não fiquem preocupados ou com medo de entrar 
na área de gestão de projeto, em projetos,

mas em qualquer outra profissão, qualquer 
outra atuação da sua atividade profissional,

vão existir desafios.

Eu vou falar para vocês que, projetos,
para quem gosta de desafios,

é um excelente ambiente para se trabalhar.

Em projetos, vão existir diversos 
tipos de desafios a serem superados.

E eu gostaria de colocar, Rafa,
o seguinte ponto:

estamos falando muito 
de metodologia, de processo,

da questão estratégica dentro da
organização, de mitigação de riscos.

Eu falei um pouquinho lá atrás 
de gestão de problemas.

Mas imagine assim: nós ainda 
não falamos do nosso...

Nós falamos que tem escopo, prazo, custo.

Mas imaginem vocês dentro...

Parece simples o projeto, né?

Mas imaginem vocês 
que o executivo separe um valor,

um montante de dinheiro,
o budget, de 100 mil reais...

Eu vou colocar um valor hipotético aqui.

Supondo que é alto, né?

É, supondo que é algo, tá,

mas às vezes são projetos de milhões.

Em SAP, nós falamos em milhões.

Mas vamos colocar 
um número aí de 100 mil reais.

E que, durante o projeto,
você identifique situações

em que você não vai conseguir 
atender àquele escopo,

e por não conseguir atender àquele escopo,

ao invés de custar 100 mil reais o seu projeto,

que você já informou à sua presidência,

você vai ter que informar
que ele vai custar 200 mil reais.

Olhe a complexidade de informações

que o gerente do time que está 
sendo gerenciado deverá ter

para convencer o seu 
presidente, o CEO, que seja,

desse pequeno dobro de valor.

Então, são situações complexas como essa

a serem administradas dentro do projeto.

E aí existem aqueles velhos costumes.

Vamos identificar quem são os culpados, né?

E, na verdade, não funciona assim, gente.

Quando um projeto falha,

existem 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,

trabalhar planos de ações,
e contra-argumentar com o presidente

e pedir mais dinheiro, o 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, Rafa.

Eu gostaria de colocar esse ponto
porque eu acho que vale.

Eu achei legal porque está vinculando
a parte de levantamento de escopo, né?

Se você está fazendo a gestão, 
fez a previsão de 100 mil,

mas você faz ali um levantamento

que o budget não reflete
devido ao que você levantou...

"Temos esse budget, mas 
baseado em todas as entrevistas,

o que nós conversamos e levantamos 
em x dias na empresa, não vai atender.

Não é que não queremos 
fazer o gourmet para vocês.

É que não vamos entregar 
conforme a necessidade".

Aí eles tentam muitas vezes
diminuir o escopo.

Aí às vezes você pode falar
que é melhor nem fazer, né?

Às vezes é melhor nem fazer.

Mas se tiver bons argumentos,

que seria essa documentação,
essa conversa, tudo que você levantou...

Não foi você que levantou, 
não foi você que criou.

Foi a equipe da empresa que passou 
toda essa parte de escopo, né?

E aí vai muito na linha 
do que o Ale comentou,

da parte estratégica também, financeira.

Um projeto tem que trazer 
algum resultado para a empresa.

Normalmente é alguma
otimização processual,

alguma otimização da produção,
venda, aumento de venda,

ou seja, que traga algum benefício tangível, 
normalmente financeiro, para a organização.

Se você conseguir provar que,
de 100 mil para o projeto

passou para 200 mil, 
mas vai ter tais ganhos,

é uma maneira de você contra-argumentar.

O famoso ROI.

É isso aí.

Vocês devem defender direto projetos,
principalmente na parte de consultoria, né?

Essas conversas devem 
ser bem agradáveis, né?

Para nós, a defesa do projeto
está mais ligada na abordagem

e na estratégia de entrega,
de como vai ser desenvolvido.

Esse convencimento
de que o projeto vai dar retorno,

ou o projeto vai ter 
um benefício para a empresa,

geralmente parte da própria empresa,
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 
para nós, como consultoria,

oportunidade de participar 
de um processo de venda da solução.

Muitas vezes nós ajudamos, né, Ale?

E muitas vezes nós os ajudamos
a construir a defesa.

Geralmente quem defende 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 quais benefícios eles 
trariam para a empresa.

Mas geralmente são vocês, de consultorias,

que os alimentam com essas 
informações para eles levarem...

- Para o board da empresa, né? 
- Às vezes alimentamos...

Participamos 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í nós os ajudamos 
a desenhar a solução, a ideia,

e como resolver o problema.

Mas quem vai defender isso de fato

vai ser a própria empresa,

os próprios gestores perante a empresa.

É legal o outro tema 
que você trouxe aí, Ale.

Acabamos, falando de ROI, mas nem sempre 
um projeto de desenvolvimento de um sistema,

seja de implementação de um SAP,

é só voltado para a parte
do retorno financeiro.

Às vezes você está fazendo uma implementação 
para mitigar risco fiscal,

ou a operação parar,
que indiretamente, ali por trás,

corre a parte financeira, né?

E aí, ter essa visão de processo,

e até mesmo essa parte fiscal,
ainda mais brasileira, é bem difícil, né?

E é importante também 
olharmos que às vezes um projeto

pode ser uma evolução tecnológica.

Muitas empresas demoram
para investir em tecnologia.

E um dos problemas 
que as empresas têm hoje

é a obsolescência tecnológica,
tanto de hardware como de software...

Porque é um ativo que, 
muitas vezes, já está...

Não tem uma reposição 
dentro da organização.

Na parte sistêmica e de software,

não tem uma evolução
daquela ferramenta,

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 dificuldade 
porque a sua arquitetura

ainda é uma arquitetura monolítica.

Então ele precisa se atualizar 
em muitas coisas ainda

para poder começar
a trazer novos elementos

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.

É legal você falar, porque às vezes ele 
quer implementar uma tecnologia.

Mas para implementar aquela 
nova tecnologia com aquele projeto,

ele tem que tomar outras ações antes...

- Para mudar sua organização. 
- Ele tem que redesenvolver o 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 né,

porque tem a própria 
obsolescência da tecnologia

e você acaba perdendo algumas 
vantagens, dependendo da tecnologia.

Então, é isso que também é 
importante olharmos nesse cenário

quando vamos falar 
de criar novos projetos,

fazer inovação, 
desenvolver novas soluções.

E até pegando isso, quando 
falamos no mundo corporativo, pessoal,

não é o país das maravilhas, tá?

As pessoas que estão iniciando
agora, vocês que estão iniciando agora,

muitos na área, vão encontrar...

"Pô, vou lá, chegar e desenvolver?".

Não.

Você vai desenvolver, você 
vai chegar a desenvolver,

você vai entender o projeto,

mas você vai ter que seguir 
algumas regras e padrões,

inclusive de conformidade.

Os requisitos legais, né?

Hoje nós temos o LGPD,

que são as políticas de Cyber Security...

Implantar diretamente no código, né?

Pois é. Você tem as questões 
que você vai ter que seguir.

Não é sentar-se lá simplesmente
e 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 peer review...

"Pô, 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 
a realidade aqui, certo, Rafa?

Tem que colocar... Pode colocar, né?

Pode. Você até trouxe um ponto,

porque às vezes o nosso aluno,
quando corrigimos uma atividade...

"Pô, Rafa, você me tirou 10% da nota porque 
eu não segui a boa prática no código...",

ou não fez a identação do código,
ou não comentou código.

Estava escrito no exercício que,
se você entregar funcionando,

mas não seguir a boa prática, 
perde tais pontos.

Aí ele pergunta por quê.

Porque dentro de uma governança,
dentro de uma gestão de um projeto,

dentro uma empresa, você tem que segui-la
porque você não está trabalhando sozinho.

Mesmo que estivesse trabalhado 
sozinho, você deixa esse código

e alguém provavelmente 
vai fazer reengenharia depois,

ou vai ter que analisar
para criar um novo sistema.

E o exemplo clássico, né?

Porque, por exemplo, 
falamos de programação, né?

Eu já fiz várias entrevistas na época,

quando eu ainda cuidava dessa 
frente de desenvolvimento.

Eu perguntava: cara, 
o que acontece se você fizer

um "select*" dentro da base?

Será que trava essa pergunta?

Você vai fazer?

Não, não faz não, espera aí!

Aí o cara olhava e falava: 
"Mas que pergunta é essa?"

Você sabe o impacto que você 
tem em colocar um select*?

Sem o wherezinho para travar, né?

Pois é.

Porque se você colocar isso no seu código,

você vai ter o impacto lá na frente.

No quê? Em performance,

dependendo do tipo de dado 
que você está acessando,

do tipo de tabela que você está acessando.

Então não é uma boa prática você 
utilizar isso dentro do seu código.

E geralmente as empresas 
têm os seus manuais

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 de habilidade 
aquele desenvolvedor tinha

para desenvolver
determinado tipo de código,

ou para onde eu iria direcioná-lo
para o desenvolvimento.

Você falou de um ponto que eu vivi.

Eu trabalhei numa multinacional
e comecei como desenvolvedor,

e aí eu estava atendendo a área de vendas,

a área de vendas de uma multinacional
com uma base muito alta,

e aí veio escalado da alta gerência

um e-mail falando 
por que temos que formar,

qual é o range de clientes
que queremos enxergar.

Eu quero clicar e baixar 
toda a base de clientes.

Por sorte, eu, como desenvolvedor júnior,

tive a maturidade de perguntar
ao meu coordenador técnico:

olha, veio escalado da alta 
gerência de vendas.

Ele não tem culpa.

Mas eu entendo que, se eu 
atender e tirar o "where" daqui...

Foi o que você falou, 
tira ali rapidinho, sobe em teste,

aí não vai dar impacto 
para subir para a produção.

Só que, se eu subir isso daqui, o outro
usa o relatório, se o sistema não cair.

Até explicar para essa pessoa,
esse executivo da área de vendas,

que, se eu fizesse isso, ia atrapalhar 
a performance, ia dar stress.

Foram falar com ele, e ele falou:
"Então comprem um servidor novo".

Nem se você comprasse ia resolver, 
ainda mais há um tempo.

Bem interessante essa fala.

Mas, por alguns segundos, 
eu, como um júnior,

eu vou ser bem transparente, 
pensei em fazer.

Na hora que veio escalado, 
quase levando uma bronca,

eu, como desenvolvedor, falei: 
espera aí, isso não faz sentido!

Sorte que eu consultei.

E isso conta como maturidade, né, Rafa?

Existem passos, né?

Você pode ter uma excelente lógica 
de programação, que é fantástico, né?

- "Select*" lá, deixa rolar...
- Vai embora, vai embora!

Vai travar tudo ali.

Mas você mede a senioridade 
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, a vivência 
que você tem dentro dos projetos.

"Pô, eu fiz isso aqui, eu vi isso aqui...

Isso aqui pode impactar.

Pô, se eu fizer isso aqui,
eu não sei o que pode acontecer,

mas deixe-me fazer uma POC aqui
para ver se pode gerar impacto".

Mas eu vou te falar, Edu, que, 
na pressão, a hora que vi o e-mail...

- A vontade era fazer.
- Tem a pressão, né?

Eu juro para vocês.

Até hoje eu lembro.

Serviu de experiência, crescimento mesmo.

Eu falei: espera aí, eu o atendo, mas
o meu coordenador técnico aqui...

Vai dar ruim.

Aí eu falei: Sérgio, só uma pergunta:

se ele quer fazer, eu faço, 
mas vai parar tudo.

"Ainda bem que você não fez, meu amigo.

Me dá esse problema que eu 
vou falar com essa pessoa."

Não foi fácil.

Ele teve que lidar
com uma situação de conflito.

Mas esse é o tipo de desafio 
que um gerente tem.

Determinar, identificar quem 
são esses colaboradores

que vão trabalhar com ele,

qual o nível de senioridade,

que tipo de desenvolvimento é melhor 
para cada um poder desenvolver.

Hoje nós falamos que tem 
o front-end e o back-end.

Isso já é um tipo de segregação 
de função para o desenvolvedor.

Tem profissionais 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 pontes.

Mas, no passado...

Hoje, por exemplo, você tem ferramentas 
que te ajudam a fazer auditoria no código,

fazer uma inspeção de código.

No passado, ainda não tinha.

E aí?

- Os legados estão aí, né?
- Aí é onde...

Entravam as metodologias,

e que em algumas dessas metodologias 
tinha uma etapa importante,

que era fazer um peer review no código,

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é?

Não seria um peer review,
mas é basicamente isso...

- Desenvolvimento em pares.
- E tem gente que não quer...

Trabalhar nessa porque fala 
que é muito estressante.

Por que estressante?

Para mim, é até uma segurança.

Toda vez antes de eu mandar esse código
para a QA, Quality Assurance , por exemplo,

passa pelo meu parceiro 
de revisão, que é o Edu,

para mim, é uma segurança.

Se eu sei desenvolver, não é um problema.

Com certeza!

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, nós deveríamos 
ter responsabilidade civil

sobre os códigos que desenvolvemos.

Penal e civil, né?

Ai ele já pegou...Tá vendo?

Por quê?

Porque hoje você desenvolve
software para avião, para carro.

Você desenvolve software para...

Né?

Só que você não tem...

- Responsabilidade sobre aquilo lá.
- Responsabilidade...

Sobre aquilo que você desenvolveu.

É diferente de você...

Do médico.

O médico não tem...

- Ele vai pedir dez consultas, dez exames...
- O CRM dele?

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

algo nesse sentido também,

para que as pessoas criem mais consciência
quando desenvolverem um software

ou quando criarem um código,
desenvolverem um código,

para algum programa, algum sistema.

Você não está falando 
em burocratizar, né, Ale?

- Não, não é burocratizar.
- Não é isso?

É trazer a responsabilidade

para não ter esse tipo de coisa 
que você acabou de dar o exemplo.

"Ah, não, eu não quero trabalhar

porque vão fazer uma verificação 
sobre o meu trabalho."

Não, não estou fazendo 
uma verificação sobre o seu trabalho.

Eu estou fazendo um peer review para garantir
que você não vai ter um problema

na hora que você implementar esse sistema.

Porque às vezes você não viu 
o que fizeram. Não é por mal.

O seu amigo vai dar um toque para você 
de como melhorar a performance.

Porque você tem código hoje, 
programas e softwares,

desenvolvidos em várias situações.

Numa hidrelétrica, você tem software,

você tem software no avião,
você tem software no automóvel...

- Na área da saúde, na área de ensino.
- Você tem software na área da saúde.

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 criamos um podcast

em que vocês conseguem trazer esse 
contexto para quem está nos escutando.

Porque se você achava que você ia ter 
uma resposta do que é um projeto,

de qual o melhor, a gestão de projeto ágil
ou em cascata, ou PMI, ou PMBOK que seja,

em nenhum momento você iria dar 
uma pausa e fazer uma anotação breve.

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í, como o Ale e o Edu trouxeram.

E não é para te deixar confuso.

Na verdade, é para você entender que, 
quando você faz uma gestão de projeto,

não é só olhar o seu documento,
pedir para alguém codar

80% do tempo do projeto, e está entregue.

Se for ágil, melhor ainda 
porque vai fazer a qualidade.

Nem sempre isso é uma verdade.

Se for PMA... "Ah, é um escopo conhecido".

Depende, você negociou com o seu cliente?

Então esse era o tópico da nossa conversa.

E aí eu trago para uma última, Ale e Edu.

Fiquem à vontade para quem 
quiser ser o primeiro.

Para fecharmos, o que você deixa de dica
para quem está nos escutando?

Às vezes os alunos que estão nos escutando,
alunos nossos da graduação,

já têm experiência, mas começam 
principalmente na área de desenvolvimento.

Eu comecei, e acredito 
que vocês também, né?

E aí? Larga a área de desenvolvimento
porque é só 30%?

O que vocês deixam de dica
para quem está nos escutando?

Uma frase de fechamento
de cada um, por favor, um contexto.

Uma dica para quem é desenvolvedor

ou que está na carreira 
de engenharia de software,

tanto em teste, 
desenvolvimento, análise, é:

migrar para um cargo de gestão,

é o que nós colocamos aqui,
você 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 está se desenvolvendo

em relação ao relacionamento 
com as pessoas, porque isso é fundamental.

É mais até que metodologia, é mais 
até que saber codificar ou não.

Então ele tem que definir bem para onde 
ele quer direcionar a carreira dele.

E hoje nós sabemos que não é preciso

tomar uma decisão de ir 
para uma carreira de gestor.

Tem pessoas que continuam 
na trilha técnica

e se transformam em 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 Scrum Master, enfim.

Por quê? Porque grande parte desse trabalho
é a habilidade de trabalhar a equipe,

a colaboração do time, 
para que se consiga,

naquele produto que você se pensou,

chegar ao final com ele concluído,

que entre em produção 
e o cliente fique satisfeito,

ou a empresa fique satisfeita,
com aquilo que foi feito.

Então, esse é o ponto importante
que tem que ser avaliado.

Não pensar só em código ali?

Não pensar só em código.

Se ele tem a pretensão
de ser um gerente,

de ir para uma carreira de gestor,

virar um diretor, crescer
para um lado mais executivo,

ele vai ter que analisar e ver 
qual é o gap que ele tem

em relação à parte humana.

A soft skill ali, né?

Exatamente.

Eu queria falar isso, Rafa, 
eu estava guardando aqui.

Mas pode terminar, Ale.

Ele subiu a régua ali de novo!

- É, então, ele sobe a régua.
- "Ah, eu soltei a palavrinha do soft skill..."

Deixa a dica aí então, Edu.

Deixa a dica para o pessoal.

O que eu ia falar é o seguinte: eu acho 
que muitos dos alunos, alguns, pelo menos,

já tenham escutado, né,
que, muitas vezes,

as pessoas são contratadas 
pelos hard skills.

O que são os hard skills?

São os conhecimentos técnicos.

Então, quando você fala
em engenharia de software,

você está ganhando conhecimento
técnico, que são hard skills,

porém, elas são demitidas pelo soft skill.

O que são os soft skills?

É a capacidade de comunicação,
é a capacidade de colaboração,

de como trabalhar em equipe.

Então, a dica que eu 
dou é: hard skill...

Você vai ser contratado pelo hard skill, 
por isso que temos que estudar.

Nós aqui, nós três aqui, estudamos muito.

Fazendo Doutorado agora, né, Rafa?

O Ale fazendo Doutorado, 
e eu parei no Mestrado.

Agora, quem sabe, eu vou no Doutorado.

Vamos ver.

Eu acho que vou.

Mas é superimportante
trabalhar essa frente de soft skill,

independentemente da carreira,

se é carreira técnica 
ou se é carreira gerencial.

E 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 ele 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 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, né?

Show!

Eu gostaria de agradecer 
a sua presença, Ale,

a liberdade que você teve de trazer
os temas, de uma maneira até polêmica.

Edu também.

Essa liberdade com certeza 
soma para os nossos alunos.

Sempre falamos: "Vá além 
dos nossos materiais

que deixamos disponíveis,
onde o professor ensina.

Escutem também os profissionais 
de mercado que nós trazemos

para vocês verem que, 
o que cobramos às vezes,

não é porque somos chatos
na hora de uma correção,

e sim porque queremos que você entenda
que nem sempre o mercado trabalha

como está a cartilha 
do ágil, por exemplo, tá?".

É isso aí!

Edu, eu também gostaria 
de agradecer a sua presença,

e, da mesma forma, a liberdade 
que você teve para trazer os temas,

e até mesmo somar para os nossos alunos.

Obrigado!

E você, aluno, deu para entender que, 
para você fazer uma gestão de projetos,

não basta apenas 
você saber fazer a gestão,

mas também tudo que tem envolvido.

Eu vou ficando por aqui, 
e até uma próxima.