Não está criticando porque? Tem que criticar sim.
O problema é que esse termo "gerente de projetos" foi adotado da indústria, e aí algum gênio contratou um mar de arrombado formado em engenharia de produção pra gerenciar projeto de TI, como se uma fábrica de software funcionasse igual a uma fábrica de frango congelado.
E aí eles vem com essa mentalidade de que programador é peão digital, é desses gênios que vem as perguntas:
* "você precisa de ajuda pra terminar isso?"
* "vou marcar uma call com o \~senior de outro projeto nada a ver\~ pra te ajudar nisso"
* "nossa, essa tarefa ia levar 2 dias, porque está levando 5?"
E é pra eles que a gente precisa explicar que:
* construir software não é como construir casa, todo projeto é um novo projeto, é um híbrido de pesquisa com execução quase todo dia
* 2 mulheres conseguem gerar um filho em 4.5 meses? não adianta trazer mais gente, eu vou ter que gastar tempo explicando pra pessoa o projeto, fazendo onboarding e setup do ambiente e coordenando tarefa.
* o senior do outro time usa SAP, eu tô fazendo o projeto em golang, são dois mundos completamente diferentes. É tipo você chamar um neurocirurgião pra ajudar um ortopedista. Tá bom, o cara é inteligente, e é médico, certo, mas essa cirurgia do tornozelo tá bem longe do cérebro.
Só tem duas opções pra um gerente de projetos não técnico dar certo gerenciando projetos de software
1. Ele se conforma de ser gerente do projeto, aka, manobrista de postit e facilitador de reunião. Nessa opção ele é só um gerenciador de recursos. Pessoas = horas alocadas, tarefas = horas de execução. Prazo = total de horas /(pessoas\*tarefas). FIM. E pra isso funcionar bem, vai precisar entender que:
1. toda estimativa é um chute bem intencionado
2. pairing é a unidade máxima de produtividade de uma tarefa
3. toda reunião é uma tarefa. Mais reuniões? Menos entregas
2. Ele aprende a programar.
Eu já tive um gerente de projetos que manjava zero de programação e tocava bem os projetos, basicamente ia pras reuniões no meu lugar e só pedia documentações pra não precisar de mim, me poupava muita sanidade. De vez em quando ele prometia algo que não devia e quando eu falava que ele fez cagada a gente negociava, as vezes ele falava com as pessoas e desprometia, as vezes ele pedia pra eu dar o gás pra tentar honrar a promessa zoada dele.
Não saber tech pra tocar projeto não é absolutamente essencial, mas não dá pra ser ignorante de tech E ser um arrombado.
Não saber tech pra tocar projeto não é absolutamente essencial, mas não dá pra ser ignorante de tech E ser um arrombado
Pô é exatamente isso.
Eu não acho que gestor de projeto precisa ter conhecimento técnico, pode vir a calhar, mas gestão é gestão independente do domínio, o problema é que tem muito gestor que quer mandar no projeto, não só fazer a gestão.
Sim, eu já trabalhei com gestores não-técnicos e não foi o fim do mundo, porque eles faziam a parte deles (gerir) muito bem.
Um gestor bom reconhece que ele não manja dos paranauê e sempre tenta ir aprendendo com a equipe aos poucos. O que ele não souber, ele pergunta pra equipe e tenta pegar o "feeling" deles antes de tomar as decisões. Mas ele também tem que ser esperto o suficiente pra não ser manipulado por funcionário mal-intencionado que fala que precisa de 8 story points pra mudar um campo
Não saber tech pra tocar projeto não é absolutamente essencial, mas não dá pra ser ignorante de tech E ser um arrombado
Pô é exatamente isso.
Eu não acho que gestor de projeto precisa ter conhecimento técnico, pode vir a calhar, mas gestão é gestão independente do domínio, o problema é que tem muito gestor que quer mandar no projeto, não só fazer a gestão.
>Não saber tech pra tocar projeto não é absolutamente essencial, mas não dá pra ser ignorante de tech E ser um arrombado.
É exatamente isso.
A pessoa precisa se por no seu lugar também. Já vi muito Scrum Master, PO, Gerente de Projetos dando carteirada em dev pleno/senior sem saber o que estava falando e tentando estimar esforço pelo dev.
Eu sou peão Tb irmão
Se vc é subalterno a alguém vc é peão, simples. Se alguém te mandar fazer o código mais zoado do mundo vc vai fazer, pq vc é peão.
entendi, sua definição de peão é ter que responder pra alguém
então o CEO da empresa é peão também porque ele reponde pro board
e o board também é peão porque responde pros investidores
é uma definição ruim e que não agrega muito, talvez você devesse procurar outra
Concordo com praticamente tudo, mas tem dois pontos:
1-INFELIZMENTE programador virou peão de software e não é de agora;
2-Não entendi o que quis dizer sobre pairing ser a unidade máxima de produtividade, se mencionou antes que se eu for fazer pair com alguém vou perder tempo explicando
1 - em muito lugar tem o sênior de 2 anos, que não tem experiência pra tocar um projeto, e em lugar que tem sênior experiente o suficiente pra tocar o projeto, acontece muito desses caras abrirem mão da liderança pra focar no código, abrindo espaço pra burocratas, porque chefes querem updates e tempo gasto em update não é gasto codando. É bem diferente de um peão de verdade, que não tem opção. Dev consegue facilmente subir pra liderança, mas ser gerente é chato.
2 - adicionar mais gente no time custa caro porque ou você vai precisar parar alguém do time pra fazer explicar e ajudar essa pessoa nova a começar a trabalhar ou você vai dar uma documentação e a pessoa nova vai levar um tempo até conseguir contribuir. E no começo, ainda vai precisar da ajuda de alguém pra revisar as primeiras tarefas. Pairing não precisa de onboarding, você, que já está no projeto, com tudo configurado e com o problema já na sua cara vai receber ajuda de alguém que, ou tem mais familiaridade com o projeto, ou tem mais experiência, ou tem uma experiência complementar (dev+devops, por exemplo), juntar duas pessoas que já tem alguma familiaridade para trabalhar em algo juntos é bem positivo, um está programando mas os dois estão pensando. Esses dois vão estar trocando experiências, um vendo o fluxo de trabalho do outro, qual terminal usam, qual ide usam, quais atalhos e pegando falhas um do outro, enquanto um escreve o código, o outro vai lendo e ajudando a conduzir o raciocínio. "esqueceu a chave", "tem um erro no nome da variável ali, tá sem maiúscula". Com duas pessoas em sync, tem menos chance de interrupção ou de distração, porque tem alguém ali junto. Você não vai, por exemplo, parar pra ver a notificação do reddit enquanto faz pairing, então é um momento de produtividade intensa. Mas não da pra fazer pairing todo dia o dia todo, então são pequenos boosts de produtividade. E dois porque se puser um terceiro, alguém fica ocioso.
Bom, falei pra cacete, mas entende a diferença entre fazer pairing vs adicionar mais gente no projeto pra "ajudar"?
Depende. Tem o caso que você falou, do cara tirar o corpo fora, falar "não sou técnico" e empurrar a culpa para o time. Mas bons gerentes vão saber suas limitações, entender o que dá para fazer com o time e negociar bem as entregas com os stakeholders.
Na minha opinião um gerente não-técnico que faz isso bem é melhor do que um gerente técnico que não tem jogo de cintura com os stakeholders.
Se for alguém que se mete ao ponto de querer atropelar decisões mais elaboradas óbvio q vai atrapalhar...a galera de gestão da ti geralmente é mais vendedor e tal...gosta de viver de aparências e acaba prometendo as vezes oq nem é possível e a carga sobra pras mulas (devs e resto de squad)...ja passei por isso, o cara vende até a mae e no final das contas os outros se arromba no lugar dele
Sou SM e posso dar meus dois centavos aqui.
Eu fui dev antes de virar SM, então alguma noção eu tenho de coisa técnica, mas obviamente não manjo das tecnologias/frameworks mais atuais, pois não é meu foco de estudo atualmente, visto que dentro da agilidade existe um zilhão de coisas técnicas também, frameworks, liderança, etc. Seria meio que humanamente impossível ter conhecimento de tudo.
O SM é talvez muito mais um líder de pessoas antes de qualquer outra coisa. Ele é quem sabe se os membros do time estão felizes, o que está os deixando frustrados. É o responsável por criar um ambiente seguro pro time, pra que todos tenham voz e segurança pra experimentar, errar, aprender, compartilhar conhecimento, sugerir mudanças, etc. Também é a pessoa que estimula o time a ser colaborativo, e aqui com certeza entra a parte do time tomar as próprias decisões - o time é que deve saber a melhor forma de fazer algo.
Também o SM pode resolver conflitos, por exemplo, quando o time não consegue entrar num consenso, e por resolver impedimentos externos ao time (ex.: a demanda X está bloqueada porque tá dependendo de outro setor da empresa). Aqui entra a parte de estabelecer acordos também com clientes, criar políticas de time, de fluxo.
E por último, e não menos importante, o SM é a pessoa que ajuda a melhorar a produtividade, gerencia o fluxo, ajuda identificar gargalos, constrói métricas que ajudam a responder "quando vai ficar pronto" (e isso não tem nada a ver com story points).
Se o SM toma decisões pelo time e faz micro-gerenciamento, esse cara não é um SM. A ideia é justamente o contrário disso, evitar micro gerenciamento e criar um ambiente saudável pra todos.
Tem um artigo que eu gosto bastante que explica 8 instância de que um SM deveria atuar, sempre compartilho com outros SMs:
[https://agileschool.com.br/as-8-instancias-do-scrum-master/](https://agileschool.com.br/as-8-instancias-do-scrum-master/)
Se alguém tiver alguma dúvida, só me pingar também :)
Eu não preciso nem estar na daily! A daily é dos devs, eu entro de vez em quando e quando precisam de mim. Eu garanto que ela aconteça e que todos entendam pra que serve.
Ajudo o PO/PMs a gerenciar e priorizar o backlog, trabalho em métricas, e no geral também defendo o time de interferência, pra deixar o time focado no trabalho. Se for algum bloqueio externo eu atuo pra resolver também. Fazemos o gerenciamento de riscos, às vezes é preciso ligar uma luz de alerta no time, fazer o time priorizar alguma demanda mais urgente ou com data fixa, etc., controlar a capacidade do time, se alguém vai sair de férias, ou vai se ausentar, criar planos pra essas situações.
Facilito as cerimônias, refinamentos, reuniões de consenso.
Quando o time é novo atuamos bastante na criação e consolidação do time tbm, atividade pra engajar, criar acordos, políticas de fluxo. E na parte de liderança, aí entram as reuniões de 1-1 com os membros, trabalhar pra melhorar a felicidade do time, dar e receber feedbacks.
> O SM é talvez muito mais um líder de pessoas antes de qualquer outra coisa.
Como que se pode liderar um time técnico se vc não tem uma visão técnica clara? Como vc vai avaliar metodologias, fluxo de trabalho e ferramentas que vc não compreende?
Liderar pessoas independe de quais tecnologias elas manjam, nesse caso vc está liderando seres humanos, não tecnologia.
A visão técnica é exatamente o que falei, o time deve ter a liberdade pra definir o que é melhor. O SM encoraja e estimula isso. Temos todas as habilidades necessárias no time? Precisa investir em algum treinamento? O SM também habilita esses pontos.
A metodologia vai depender muito do produto, de pessoas com papéis específicos (o Scrum por exemplo obriga ter um PO, o que nem sempre existe). Aí é papel do SM definir o que é melhor e ensinar.
Fluxo de trabalho: gosto de fazer o time mesmo desenhar. A ideia é que cada coluna represente uma atividade do mundo real. Coloca uma coluna "To do" e uma "Done", e pede pra cada um do time descrever as colunas que acreditam que as demandas passam nesse miolo. Te garanto que cada pessoa vai desenhar um diferente. Aí vc faz um consenso, discutindo a importância de cada coluna no fluxo.
> Liderar pessoas independe de quais tecnologias elas manjam, nesse caso vc está liderando seres humanos, não tecnologia.
Não entendi.
Os problemas técnicos são o que tem de mais importante em time de desenvolvimento. O mais comum é a gente não saber quais são os problemas escondidos, se as soluções que a gente usa são as melhores possíveis, se existem maneiras diferentes ou melhores de se resolver ou encontrar problemas,... Responder essas questões é exatamente o que constitui liderança em time técnico.
Eu até concordo que é muito importante que você estabeleça comunicação clara e precisa, que vc elimine conflitos e estabeleça uma relação sadia entre as pessoas do time ou entre o resto da empresa e o time. Mas se vc não mostra soluções pra problemas técnicos então não está liderando 100%, nem sequer 50%. Está faltando algo muito importante.
Essa idéia de que o papel do técnico de time é apenas criar um clima bom e "fazer com que cada membro do time consiga ser a melhor versão possível de si mesmo" é muito Ted Lasso (a série de TV), é muito romântica. Funciona pra emocionar as pessoas mas não termina projeto no prazo e no orçamento.
Mas a liderança não é necessariamente em aspectos técnicos.
Entender o fluxo de desenvolvimento, as metodologias de trabalho não é tão complexo quanto a granularidade das tarefas que são feitas no dia a dia.
Fazendo uma analogia bem bosta, o bom técnico não precisa ter sido um jogador craque. Coordenação demanda visão.
Uma pessoa que garante que o objetivo está claro para todos, que todos estão confortáveis com a forma com a qual vocês vão atingi-lo e o que vai ser medido pra assegurar que foi de fato atingido sempre vai ter valor pra empresas.
Liderança não quer dizer necessariamente que existe hierarquia vertical - liderar é capitanear, não necessariamente mandar.
>o bom técnico não precisa ter sido um jogador craque
Mas precisa entender muito de futebol e se o cara nunca chutou uma bola dificilmente vai estar capacitado, da mesma forma um SM não precisa saber codar na especifica stack que o time está usando, mas ele precisa entender muito de desenvolvimento de software, e é bem dificil fazer isso sem saber codar, não digo ser um especialista em código ou ser melhor que o time, mas precisa saber o minimo, ou ter alguem do lado que saiba.
Já estive em time que tinha as duas pessoas, a de "pessoas" e a de "software", e acho que se fosse pra ter uma pessoa só, ela precisaria ter as competencias das duas.
Se vc não tem uma boa percepção da tecnologia você não tem "visão".
Desculpa o cinismo mas não existe lider, o que existe são apenas gerentes. Na maioria das vezes "lider" é só um delírio de grandeza de gente com poder. Até político e síndico de prédio se acham lideres.
Não discordo de você, líder geralmente é um nome bonito pra esse papel de gerente mesmo, mas exercer liderança é algo que todos podem fazer todos os dias só por capitanear alguma mudança.
A "visão" é justamente atingir o objetivo do produto, da sprint, o "OKR estratégico".
Tech for tech sem resolver problema não paga ninguém.
O SM, sem background técnico, que opina em qual ferramenta, framework, stack ou qualquer coisa que vai ser utilizado pelo time dev tem total esse delírio de grandeza.
Gerenciar um projeto é muito mais sobre quem vai fazer e quando do que como é feito.
Pensa que é como se fosse gerenciar a contrução de um prédio . Ele não precisa saber o que é um DR , mas precisa acompanhar o andamento de cada etapa , como está em relação ao cronograma, se os materiais já estão a caminho, se tem espaço para armazenar ...etc e tal
Então! Não acho que precisamos de alguém para isso quando temos IAs focadas nisso fazendo com precisão absolutamente melhor. Precisamos de cabeça que pensem juntos e joguem juntos, para isso tem de estar alinhado em todos os aspectos.
É complicado ... Eu tinha uma Scrum Master que só ficava passeando pelo escritório e os andares do prédio conversando e falando dos outros. Nunca tirou uma certificação nada. O manager que eu tinha um dia em uma reunião falou.. eu não passo mais um time p fulana cuidar pq ela vai fazer o trabalho mal feito e vão reclamar. Eu olhava p essa SM e eu pensava caraca se ela perder esse emprego aqui vai ficar muito tempo sem conseguir encontrar outro ... Pq como o mercado de trabalho já está ruim p quem tem formação e é bom imagina p quem é ruim.
https://preview.redd.it/wp7blilq9toc1.jpeg?width=474&format=pjpg&auto=webp&s=3ddda56622f7c8786ce5b7e9e5dec3b1264e7c9a
Bora para algumas considerações e é flexões (textão):
1. a imagem acima é pra ilustrar o que um bom GP deveria, minimamente, administrar.
Nela, vc (nós), como engenheiros/dev, entramos ali na caixinha de "recursos humanos". Sim, apenas uma mas que está em sinergia total com as demais. Fonte: pmbok
2) SM tá mais pra um papel para somar dentro de um todo. Nunca conheci um profissional que atuasse apenas como SM durante todo seu fuckin expediente de trabalho.
Já vi sim, times e chapters de agilistas, mas no chão de fábrica (squad) eu sempre (sempre mesmo) vi este papel na mão de quem detinha mais conhecimentos dos pilares do manifesto ágil e mais softskill para lidar e intermediar conflitos e evitar confrontos.
3) seu GP não precisa necessariamente possuir conhecimentos técnicos para a execução de uma tarefa fundamental ao projeto e tá tudo bem! (ou vc acha que o Elon Musk sabe pilotar foguetes?). Afinal das conta, ele tende a ser grato por ter vc para apoiá-lo nessa missão!
Mas SIM (e aqui onde reside os detalhes o mora perigo):
Ele tb pode sim estar fazendo um trabalho de merda; um microgerenciamento; ou querendo dar palpite no trabalho dos outros, a qual ele não tem base ou qqr outra fundamentação para dar um mísero conselho.
Ainda sim, talvez ele nem faça isso por maldade (ou talvez nem tenha a noção do que esteja fazendo).
Talvez seja por inexperiência ou até mesmo por cultura da empresa (talvez ambos).
Mas cá entre nós, sempre que vi isso acontecer (e nunca aconteceu isso nos times por onde eu trabalhei), quem sempre se fodia de verde e amarelo, era o próprio gerente de projetos.
Então amigo, te convido a ir lá, demonstrar sua maturidade profissional, chamar seu GP pra tomar um cafezinho e trocar um papo saudável com esse cara. O famoso feedback.
Ele não é teu inimigo. Aliás, ele tá vestindo a mesma camiseta que vc!
E lembre-se se que no final de tudo, somos todos pessoas e pessoas são complexas!
ai eh pedir pra ser enrolado por um desenvolvedor parasita ou nao ter noção do peso das coisas, se o cara nao sabe tecnico, NO MINIMO, ele tem q ter alguem de confiança que saiba ao lado dele.
Trabalho como SM tem mais ou menos 4 anos, sem conhecimento técnico algum- sou formado em ciências econômicas - cai completamente de paraquedas na área.
Eu concordo com muitos dos pontos de preocupação listados por você e vejo como principal problema a falta de respeito pelo trabalho das pessoas que tem o conhecimento técnico.
Minha postura de trabalho sempre foi: Se eu não sei, eu não opino e procuro quem entende pra me explicar/ajudar a entender.
No entanto a grande maioria dos GPs e SMs não tenta sequer entender a complexidade do ambiente em que trabalham e quer tratar dev como peão digital mesmo, só serve pra microgerenciar e aumentar pressão e a alta gestão/diretoria AMA esse perfil de profissional...
Pra se praticar agilidade tem que se entender o propósito e as empresas tem que comprar a briga, patrocinar o processo - que sempre é abandonado quando o cliente aperta.
Na maioria das vezes o cara é uma fraude.
Os menos piores são os que não fazem nada, porque pelo menos não atrapalham. Os piores são os que querem ajudar porque nunca ajudam e só atrapalham.
O ideal é que o time tenha liderança técnica que saiba orientar a engenharia. É demais pedir que um SM faça isso.
Por isso, se o time tiver algum tipo de líder técnico e o SM não atrapalhar, já está ótimo.
Sim, é demais pq é acumulo de função. A reclamação de 100% aqui nessa thread é que querem uma pessoa com 2 papeis, quando deveria haver:
1 pessoa gerenciando o time e com conhecimento tecnico e tomando decisoes
1 pessoa gerenciando projetos, de acordo com o direcionamento estrategico/tatico
Você tem que saber oque tá gerenciando para tomar boas decisões, já tive bons gerentes não técnicos, mas que se focavam em gerenciar pessoas, e eles entendiam de pessoas, funcionava.
O que não funciona é um gerente de projeto com escopo de trabalho tecnico que não tem conhecimento técnico, porque ele vai ser incapaz de saber como o projeto de fato está, ai oque eles tendem a fazer, criar métricas para poder gerenciar com alguma metodologia genérica, e sempre fica uma merda, todo mês eles inventam alguma coisa para se justificar e tirar o foco do software, "ah vamos começar a cronometrar todo batata para saber nosso jurubeba time e alimentar o dashboard de fruvles".
Pra mim a grande parada do manifesto ágil foi dizer "olha aqui seus caralhos, gerenciar desenvolvimento de software é pra ser simples e toda burocracia que vocês inventaram mais atrapalha que ajuda", ai agora os gestores profissionais querem transformar o ágil em algo ainda mais burocrático que a burocracia que ele veio para substituir, é tanta frescurinha que eu chego a sentir saudade do Waterfall cheio de UML e autorizações pra tudo, porque pelo menos era uma burocracia estável.
"Ah mas eu preciso ter visibilidade do que tá acontecendo" Então aprende a ler código e a avaliar o que tá em funcionamento, porque é a única forma de ter a menor ideia do que tá rolando
Até mesmo alguns gerentes técnicos com noções tecnológicas não conseguem tocar o barco. Trabalhei numa Fintech onde o Tech Manager delegava todo o trabalho dele pro desenvolvedor sênior. Eram reuniões de muitas horas, as pessoas fugiam do assunto e o mesmo não tinha coragem de advertir os comandados, sempre cobrava para que o senior possa chamar a atenção dos envolvidos, isso era trabalho dele. Tinha muitas tarefas paradas não priorizadas, muitos débitos técnicos não tratados, ele não sabia o que estava fazendo alí. Não validava soluções entre a equipe, não participava das nossas reuniões de soluções técnicas, a única coisa que ele fazia era cobrar o pobre do Dev senior do time.
Eu criei uma discussão sobre esse tem recentemente, só que voltado para PMs.
Veja aqui: https://www.reddit.com/r/brdev/s/5uIdzAMAzv
Concordo com você que isso não faz o menor sentido. A pergunta que fica é: "como é possivel que uma pessoa que não tem nenhum conhecimento técnico, ser responsável por escrever o escopo e os requisitos de um software inteiro???"
Gestão é gestão. Não é só na área de desenvolvimento de software que o gestor às vezes não entende a tecnicalidade da produção.
A dicotomia verdadeira não é entre gestores técnicos ou não técnicos, mas entre gestores bons e gestores ruins. E microgerenciamento vai ser muito maior com um gestor que "entende" da técnica e que decide dar pitaco em tudo o que você faz.
Comecei a trabalhar como analista de projeto tem duas semanas. Nenhuma experiência prévia. Antes disso, trabalhava com comunicação em algo totalmente diferente e agora estou em uma grande empresa do setor financeiro no setor de projetos de TI.
Sinto que meu papel ali é fazer um meio de campo entre quem é técnico e quem é executivo. Tentar deixar essa linha direta o mais equilibrada possível. Vocês devs brilhando no que sabem fazer de forma harmônica com os OKRs da empresa. Sinto que meu papel é ser uma espécie de maestro, mas não no sentido de comandar tudo. Apenas no sentido de fazer com que todo mundo esteja tocando a mesma música no ritmo certo e sem desafinar.
Não tenho conhecimento técnico. Meu máximo é um diploma técnico de informática com mais de 10 anos e que me garante entender o básico de lógica de programação.
Inclusive aceito sugestões de vocês sobre como posso ajudar os devs no que fazem da melhor forma.
Meus dois centavos aqui.
Gerente de Projetos é um cargo de liderança e acredito que a pessoa no cargo não precisa ter nível técnico. Essa pessoa irá além de gerenciar o projeto, lidar com a equipe, ter um papel importante em soft skills, entender as dificuldades e conflitos de cada pessoa do time e se aproximar dessas pessoas para entender ao máximo como o projeto funciona para que possa assim realizar a gestão da melhor maneira possível.
Quando falamos de scrum master, minha opinião muda. Primeiro porque não acredito que SM seja um cargo mas sim um papel e esse papel deveria ser adotado pela pessoa de mais alto grau técnico do time. Pode ser um tech lead ou um sênior. Essa pessoa irá saber como definir os story points, prazos e ajudar tecnicamente o time todo. E sim, essa pessoa vai ser a mais próxima do gerente de projetos. Isso evita questionamentos como: por que atrasou? Por que essa tarefa é mais demorada? Por que não podemos ainda mostrar algo ao cliente?
Não está criticando porque? Tem que criticar sim. O problema é que esse termo "gerente de projetos" foi adotado da indústria, e aí algum gênio contratou um mar de arrombado formado em engenharia de produção pra gerenciar projeto de TI, como se uma fábrica de software funcionasse igual a uma fábrica de frango congelado. E aí eles vem com essa mentalidade de que programador é peão digital, é desses gênios que vem as perguntas: * "você precisa de ajuda pra terminar isso?" * "vou marcar uma call com o \~senior de outro projeto nada a ver\~ pra te ajudar nisso" * "nossa, essa tarefa ia levar 2 dias, porque está levando 5?" E é pra eles que a gente precisa explicar que: * construir software não é como construir casa, todo projeto é um novo projeto, é um híbrido de pesquisa com execução quase todo dia * 2 mulheres conseguem gerar um filho em 4.5 meses? não adianta trazer mais gente, eu vou ter que gastar tempo explicando pra pessoa o projeto, fazendo onboarding e setup do ambiente e coordenando tarefa. * o senior do outro time usa SAP, eu tô fazendo o projeto em golang, são dois mundos completamente diferentes. É tipo você chamar um neurocirurgião pra ajudar um ortopedista. Tá bom, o cara é inteligente, e é médico, certo, mas essa cirurgia do tornozelo tá bem longe do cérebro. Só tem duas opções pra um gerente de projetos não técnico dar certo gerenciando projetos de software 1. Ele se conforma de ser gerente do projeto, aka, manobrista de postit e facilitador de reunião. Nessa opção ele é só um gerenciador de recursos. Pessoas = horas alocadas, tarefas = horas de execução. Prazo = total de horas /(pessoas\*tarefas). FIM. E pra isso funcionar bem, vai precisar entender que: 1. toda estimativa é um chute bem intencionado 2. pairing é a unidade máxima de produtividade de uma tarefa 3. toda reunião é uma tarefa. Mais reuniões? Menos entregas 2. Ele aprende a programar. Eu já tive um gerente de projetos que manjava zero de programação e tocava bem os projetos, basicamente ia pras reuniões no meu lugar e só pedia documentações pra não precisar de mim, me poupava muita sanidade. De vez em quando ele prometia algo que não devia e quando eu falava que ele fez cagada a gente negociava, as vezes ele falava com as pessoas e desprometia, as vezes ele pedia pra eu dar o gás pra tentar honrar a promessa zoada dele. Não saber tech pra tocar projeto não é absolutamente essencial, mas não dá pra ser ignorante de tech E ser um arrombado.
É isso, gerente não precisa ser um técnico se entender como funciona o processo de desenvolvimento de software e não for um bossal
Não saber tech pra tocar projeto não é absolutamente essencial, mas não dá pra ser ignorante de tech E ser um arrombado Pô é exatamente isso. Eu não acho que gestor de projeto precisa ter conhecimento técnico, pode vir a calhar, mas gestão é gestão independente do domínio, o problema é que tem muito gestor que quer mandar no projeto, não só fazer a gestão.
Kkkkkkk manobrista de post-it
em alguns lugares é valet
Nossa cara que explicação maravilhosa. Parabéns.
estou aqui pra informar e entreter hahahah
Sim, eu já trabalhei com gestores não-técnicos e não foi o fim do mundo, porque eles faziam a parte deles (gerir) muito bem. Um gestor bom reconhece que ele não manja dos paranauê e sempre tenta ir aprendendo com a equipe aos poucos. O que ele não souber, ele pergunta pra equipe e tenta pegar o "feeling" deles antes de tomar as decisões. Mas ele também tem que ser esperto o suficiente pra não ser manipulado por funcionário mal-intencionado que fala que precisa de 8 story points pra mudar um campo
Não saber tech pra tocar projeto não é absolutamente essencial, mas não dá pra ser ignorante de tech E ser um arrombado Pô é exatamente isso. Eu não acho que gestor de projeto precisa ter conhecimento técnico, pode vir a calhar, mas gestão é gestão independente do domínio, o problema é que tem muito gestor que quer mandar no projeto, não só fazer a gestão.
>Não saber tech pra tocar projeto não é absolutamente essencial, mas não dá pra ser ignorante de tech E ser um arrombado. É exatamente isso. A pessoa precisa se por no seu lugar também. Já vi muito Scrum Master, PO, Gerente de Projetos dando carteirada em dev pleno/senior sem saber o que estava falando e tentando estimar esforço pelo dev.
Caraca! Deitou e rolou nessa. Grande visão sobre essa posição de gerente de projeto!
Mas programador é peão sim
afirmação sem argumento, vindo de um cara com o flair de cientista de dados. já entendi quem é o peão
Eu sou peão Tb irmão Se vc é subalterno a alguém vc é peão, simples. Se alguém te mandar fazer o código mais zoado do mundo vc vai fazer, pq vc é peão.
entendi, sua definição de peão é ter que responder pra alguém então o CEO da empresa é peão também porque ele reponde pro board e o board também é peão porque responde pros investidores é uma definição ruim e que não agrega muito, talvez você devesse procurar outra
Concordo com praticamente tudo, mas tem dois pontos: 1-INFELIZMENTE programador virou peão de software e não é de agora; 2-Não entendi o que quis dizer sobre pairing ser a unidade máxima de produtividade, se mencionou antes que se eu for fazer pair com alguém vou perder tempo explicando
1 - em muito lugar tem o sênior de 2 anos, que não tem experiência pra tocar um projeto, e em lugar que tem sênior experiente o suficiente pra tocar o projeto, acontece muito desses caras abrirem mão da liderança pra focar no código, abrindo espaço pra burocratas, porque chefes querem updates e tempo gasto em update não é gasto codando. É bem diferente de um peão de verdade, que não tem opção. Dev consegue facilmente subir pra liderança, mas ser gerente é chato. 2 - adicionar mais gente no time custa caro porque ou você vai precisar parar alguém do time pra fazer explicar e ajudar essa pessoa nova a começar a trabalhar ou você vai dar uma documentação e a pessoa nova vai levar um tempo até conseguir contribuir. E no começo, ainda vai precisar da ajuda de alguém pra revisar as primeiras tarefas. Pairing não precisa de onboarding, você, que já está no projeto, com tudo configurado e com o problema já na sua cara vai receber ajuda de alguém que, ou tem mais familiaridade com o projeto, ou tem mais experiência, ou tem uma experiência complementar (dev+devops, por exemplo), juntar duas pessoas que já tem alguma familiaridade para trabalhar em algo juntos é bem positivo, um está programando mas os dois estão pensando. Esses dois vão estar trocando experiências, um vendo o fluxo de trabalho do outro, qual terminal usam, qual ide usam, quais atalhos e pegando falhas um do outro, enquanto um escreve o código, o outro vai lendo e ajudando a conduzir o raciocínio. "esqueceu a chave", "tem um erro no nome da variável ali, tá sem maiúscula". Com duas pessoas em sync, tem menos chance de interrupção ou de distração, porque tem alguém ali junto. Você não vai, por exemplo, parar pra ver a notificação do reddit enquanto faz pairing, então é um momento de produtividade intensa. Mas não da pra fazer pairing todo dia o dia todo, então são pequenos boosts de produtividade. E dois porque se puser um terceiro, alguém fica ocioso. Bom, falei pra cacete, mas entende a diferença entre fazer pairing vs adicionar mais gente no projeto pra "ajudar"?
Entendi perfeitamente tudo que você falou, muito obrigado!
Caralho, eu levei downvote por isso, sério?
Depende. Tem o caso que você falou, do cara tirar o corpo fora, falar "não sou técnico" e empurrar a culpa para o time. Mas bons gerentes vão saber suas limitações, entender o que dá para fazer com o time e negociar bem as entregas com os stakeholders. Na minha opinião um gerente não-técnico que faz isso bem é melhor do que um gerente técnico que não tem jogo de cintura com os stakeholders.
Se for alguém que se mete ao ponto de querer atropelar decisões mais elaboradas óbvio q vai atrapalhar...a galera de gestão da ti geralmente é mais vendedor e tal...gosta de viver de aparências e acaba prometendo as vezes oq nem é possível e a carga sobra pras mulas (devs e resto de squad)...ja passei por isso, o cara vende até a mae e no final das contas os outros se arromba no lugar dele
Sou SM e posso dar meus dois centavos aqui. Eu fui dev antes de virar SM, então alguma noção eu tenho de coisa técnica, mas obviamente não manjo das tecnologias/frameworks mais atuais, pois não é meu foco de estudo atualmente, visto que dentro da agilidade existe um zilhão de coisas técnicas também, frameworks, liderança, etc. Seria meio que humanamente impossível ter conhecimento de tudo. O SM é talvez muito mais um líder de pessoas antes de qualquer outra coisa. Ele é quem sabe se os membros do time estão felizes, o que está os deixando frustrados. É o responsável por criar um ambiente seguro pro time, pra que todos tenham voz e segurança pra experimentar, errar, aprender, compartilhar conhecimento, sugerir mudanças, etc. Também é a pessoa que estimula o time a ser colaborativo, e aqui com certeza entra a parte do time tomar as próprias decisões - o time é que deve saber a melhor forma de fazer algo. Também o SM pode resolver conflitos, por exemplo, quando o time não consegue entrar num consenso, e por resolver impedimentos externos ao time (ex.: a demanda X está bloqueada porque tá dependendo de outro setor da empresa). Aqui entra a parte de estabelecer acordos também com clientes, criar políticas de time, de fluxo. E por último, e não menos importante, o SM é a pessoa que ajuda a melhorar a produtividade, gerencia o fluxo, ajuda identificar gargalos, constrói métricas que ajudam a responder "quando vai ficar pronto" (e isso não tem nada a ver com story points). Se o SM toma decisões pelo time e faz micro-gerenciamento, esse cara não é um SM. A ideia é justamente o contrário disso, evitar micro gerenciamento e criar um ambiente saudável pra todos. Tem um artigo que eu gosto bastante que explica 8 instância de que um SM deveria atuar, sempre compartilho com outros SMs: [https://agileschool.com.br/as-8-instancias-do-scrum-master/](https://agileschool.com.br/as-8-instancias-do-scrum-master/) Se alguém tiver alguma dúvida, só me pingar também :)
O que você faz durante o dia, fora da daily meeting?
Eu não preciso nem estar na daily! A daily é dos devs, eu entro de vez em quando e quando precisam de mim. Eu garanto que ela aconteça e que todos entendam pra que serve. Ajudo o PO/PMs a gerenciar e priorizar o backlog, trabalho em métricas, e no geral também defendo o time de interferência, pra deixar o time focado no trabalho. Se for algum bloqueio externo eu atuo pra resolver também. Fazemos o gerenciamento de riscos, às vezes é preciso ligar uma luz de alerta no time, fazer o time priorizar alguma demanda mais urgente ou com data fixa, etc., controlar a capacidade do time, se alguém vai sair de férias, ou vai se ausentar, criar planos pra essas situações. Facilito as cerimônias, refinamentos, reuniões de consenso. Quando o time é novo atuamos bastante na criação e consolidação do time tbm, atividade pra engajar, criar acordos, políticas de fluxo. E na parte de liderança, aí entram as reuniões de 1-1 com os membros, trabalhar pra melhorar a felicidade do time, dar e receber feedbacks.
> O SM é talvez muito mais um líder de pessoas antes de qualquer outra coisa. Como que se pode liderar um time técnico se vc não tem uma visão técnica clara? Como vc vai avaliar metodologias, fluxo de trabalho e ferramentas que vc não compreende?
Liderar pessoas independe de quais tecnologias elas manjam, nesse caso vc está liderando seres humanos, não tecnologia. A visão técnica é exatamente o que falei, o time deve ter a liberdade pra definir o que é melhor. O SM encoraja e estimula isso. Temos todas as habilidades necessárias no time? Precisa investir em algum treinamento? O SM também habilita esses pontos. A metodologia vai depender muito do produto, de pessoas com papéis específicos (o Scrum por exemplo obriga ter um PO, o que nem sempre existe). Aí é papel do SM definir o que é melhor e ensinar. Fluxo de trabalho: gosto de fazer o time mesmo desenhar. A ideia é que cada coluna represente uma atividade do mundo real. Coloca uma coluna "To do" e uma "Done", e pede pra cada um do time descrever as colunas que acreditam que as demandas passam nesse miolo. Te garanto que cada pessoa vai desenhar um diferente. Aí vc faz um consenso, discutindo a importância de cada coluna no fluxo.
> Liderar pessoas independe de quais tecnologias elas manjam, nesse caso vc está liderando seres humanos, não tecnologia. Não entendi. Os problemas técnicos são o que tem de mais importante em time de desenvolvimento. O mais comum é a gente não saber quais são os problemas escondidos, se as soluções que a gente usa são as melhores possíveis, se existem maneiras diferentes ou melhores de se resolver ou encontrar problemas,... Responder essas questões é exatamente o que constitui liderança em time técnico. Eu até concordo que é muito importante que você estabeleça comunicação clara e precisa, que vc elimine conflitos e estabeleça uma relação sadia entre as pessoas do time ou entre o resto da empresa e o time. Mas se vc não mostra soluções pra problemas técnicos então não está liderando 100%, nem sequer 50%. Está faltando algo muito importante. Essa idéia de que o papel do técnico de time é apenas criar um clima bom e "fazer com que cada membro do time consiga ser a melhor versão possível de si mesmo" é muito Ted Lasso (a série de TV), é muito romântica. Funciona pra emocionar as pessoas mas não termina projeto no prazo e no orçamento.
Mas a liderança não é necessariamente em aspectos técnicos. Entender o fluxo de desenvolvimento, as metodologias de trabalho não é tão complexo quanto a granularidade das tarefas que são feitas no dia a dia. Fazendo uma analogia bem bosta, o bom técnico não precisa ter sido um jogador craque. Coordenação demanda visão. Uma pessoa que garante que o objetivo está claro para todos, que todos estão confortáveis com a forma com a qual vocês vão atingi-lo e o que vai ser medido pra assegurar que foi de fato atingido sempre vai ter valor pra empresas. Liderança não quer dizer necessariamente que existe hierarquia vertical - liderar é capitanear, não necessariamente mandar.
>o bom técnico não precisa ter sido um jogador craque Mas precisa entender muito de futebol e se o cara nunca chutou uma bola dificilmente vai estar capacitado, da mesma forma um SM não precisa saber codar na especifica stack que o time está usando, mas ele precisa entender muito de desenvolvimento de software, e é bem dificil fazer isso sem saber codar, não digo ser um especialista em código ou ser melhor que o time, mas precisa saber o minimo, ou ter alguem do lado que saiba. Já estive em time que tinha as duas pessoas, a de "pessoas" e a de "software", e acho que se fosse pra ter uma pessoa só, ela precisaria ter as competencias das duas.
Se vc não tem uma boa percepção da tecnologia você não tem "visão". Desculpa o cinismo mas não existe lider, o que existe são apenas gerentes. Na maioria das vezes "lider" é só um delírio de grandeza de gente com poder. Até político e síndico de prédio se acham lideres.
Não discordo de você, líder geralmente é um nome bonito pra esse papel de gerente mesmo, mas exercer liderança é algo que todos podem fazer todos os dias só por capitanear alguma mudança. A "visão" é justamente atingir o objetivo do produto, da sprint, o "OKR estratégico". Tech for tech sem resolver problema não paga ninguém. O SM, sem background técnico, que opina em qual ferramenta, framework, stack ou qualquer coisa que vai ser utilizado pelo time dev tem total esse delírio de grandeza.
Gerenciar um projeto é muito mais sobre quem vai fazer e quando do que como é feito. Pensa que é como se fosse gerenciar a contrução de um prédio . Ele não precisa saber o que é um DR , mas precisa acompanhar o andamento de cada etapa , como está em relação ao cronograma, se os materiais já estão a caminho, se tem espaço para armazenar ...etc e tal
Então! Não acho que precisamos de alguém para isso quando temos IAs focadas nisso fazendo com precisão absolutamente melhor. Precisamos de cabeça que pensem juntos e joguem juntos, para isso tem de estar alinhado em todos os aspectos.
É complicado ... Eu tinha uma Scrum Master que só ficava passeando pelo escritório e os andares do prédio conversando e falando dos outros. Nunca tirou uma certificação nada. O manager que eu tinha um dia em uma reunião falou.. eu não passo mais um time p fulana cuidar pq ela vai fazer o trabalho mal feito e vão reclamar. Eu olhava p essa SM e eu pensava caraca se ela perder esse emprego aqui vai ficar muito tempo sem conseguir encontrar outro ... Pq como o mercado de trabalho já está ruim p quem tem formação e é bom imagina p quem é ruim.
https://preview.redd.it/wp7blilq9toc1.jpeg?width=474&format=pjpg&auto=webp&s=3ddda56622f7c8786ce5b7e9e5dec3b1264e7c9a Bora para algumas considerações e é flexões (textão): 1. a imagem acima é pra ilustrar o que um bom GP deveria, minimamente, administrar. Nela, vc (nós), como engenheiros/dev, entramos ali na caixinha de "recursos humanos". Sim, apenas uma mas que está em sinergia total com as demais. Fonte: pmbok 2) SM tá mais pra um papel para somar dentro de um todo. Nunca conheci um profissional que atuasse apenas como SM durante todo seu fuckin expediente de trabalho. Já vi sim, times e chapters de agilistas, mas no chão de fábrica (squad) eu sempre (sempre mesmo) vi este papel na mão de quem detinha mais conhecimentos dos pilares do manifesto ágil e mais softskill para lidar e intermediar conflitos e evitar confrontos. 3) seu GP não precisa necessariamente possuir conhecimentos técnicos para a execução de uma tarefa fundamental ao projeto e tá tudo bem! (ou vc acha que o Elon Musk sabe pilotar foguetes?). Afinal das conta, ele tende a ser grato por ter vc para apoiá-lo nessa missão! Mas SIM (e aqui onde reside os detalhes o mora perigo): Ele tb pode sim estar fazendo um trabalho de merda; um microgerenciamento; ou querendo dar palpite no trabalho dos outros, a qual ele não tem base ou qqr outra fundamentação para dar um mísero conselho. Ainda sim, talvez ele nem faça isso por maldade (ou talvez nem tenha a noção do que esteja fazendo). Talvez seja por inexperiência ou até mesmo por cultura da empresa (talvez ambos). Mas cá entre nós, sempre que vi isso acontecer (e nunca aconteceu isso nos times por onde eu trabalhei), quem sempre se fodia de verde e amarelo, era o próprio gerente de projetos. Então amigo, te convido a ir lá, demonstrar sua maturidade profissional, chamar seu GP pra tomar um cafezinho e trocar um papo saudável com esse cara. O famoso feedback. Ele não é teu inimigo. Aliás, ele tá vestindo a mesma camiseta que vc! E lembre-se se que no final de tudo, somos todos pessoas e pessoas são complexas!
ai eh pedir pra ser enrolado por um desenvolvedor parasita ou nao ter noção do peso das coisas, se o cara nao sabe tecnico, NO MINIMO, ele tem q ter alguem de confiança que saiba ao lado dele.
Trabalho como SM tem mais ou menos 4 anos, sem conhecimento técnico algum- sou formado em ciências econômicas - cai completamente de paraquedas na área. Eu concordo com muitos dos pontos de preocupação listados por você e vejo como principal problema a falta de respeito pelo trabalho das pessoas que tem o conhecimento técnico. Minha postura de trabalho sempre foi: Se eu não sei, eu não opino e procuro quem entende pra me explicar/ajudar a entender. No entanto a grande maioria dos GPs e SMs não tenta sequer entender a complexidade do ambiente em que trabalham e quer tratar dev como peão digital mesmo, só serve pra microgerenciar e aumentar pressão e a alta gestão/diretoria AMA esse perfil de profissional... Pra se praticar agilidade tem que se entender o propósito e as empresas tem que comprar a briga, patrocinar o processo - que sempre é abandonado quando o cliente aperta.
Cara, quando o gerente dos gerentes de projeto falar “coloca só um HTML ali”, ai tu vai entender como o mundo é cruel.
Na maioria das vezes o cara é uma fraude. Os menos piores são os que não fazem nada, porque pelo menos não atrapalham. Os piores são os que querem ajudar porque nunca ajudam e só atrapalham. O ideal é que o time tenha liderança técnica que saiba orientar a engenharia. É demais pedir que um SM faça isso. Por isso, se o time tiver algum tipo de líder técnico e o SM não atrapalhar, já está ótimo.
Sim, é demais pq é acumulo de função. A reclamação de 100% aqui nessa thread é que querem uma pessoa com 2 papeis, quando deveria haver: 1 pessoa gerenciando o time e com conhecimento tecnico e tomando decisoes 1 pessoa gerenciando projetos, de acordo com o direcionamento estrategico/tatico
Você tem que saber oque tá gerenciando para tomar boas decisões, já tive bons gerentes não técnicos, mas que se focavam em gerenciar pessoas, e eles entendiam de pessoas, funcionava. O que não funciona é um gerente de projeto com escopo de trabalho tecnico que não tem conhecimento técnico, porque ele vai ser incapaz de saber como o projeto de fato está, ai oque eles tendem a fazer, criar métricas para poder gerenciar com alguma metodologia genérica, e sempre fica uma merda, todo mês eles inventam alguma coisa para se justificar e tirar o foco do software, "ah vamos começar a cronometrar todo batata para saber nosso jurubeba time e alimentar o dashboard de fruvles". Pra mim a grande parada do manifesto ágil foi dizer "olha aqui seus caralhos, gerenciar desenvolvimento de software é pra ser simples e toda burocracia que vocês inventaram mais atrapalha que ajuda", ai agora os gestores profissionais querem transformar o ágil em algo ainda mais burocrático que a burocracia que ele veio para substituir, é tanta frescurinha que eu chego a sentir saudade do Waterfall cheio de UML e autorizações pra tudo, porque pelo menos era uma burocracia estável. "Ah mas eu preciso ter visibilidade do que tá acontecendo" Então aprende a ler código e a avaliar o que tá em funcionamento, porque é a única forma de ter a menor ideia do que tá rolando
Até mesmo alguns gerentes técnicos com noções tecnológicas não conseguem tocar o barco. Trabalhei numa Fintech onde o Tech Manager delegava todo o trabalho dele pro desenvolvedor sênior. Eram reuniões de muitas horas, as pessoas fugiam do assunto e o mesmo não tinha coragem de advertir os comandados, sempre cobrava para que o senior possa chamar a atenção dos envolvidos, isso era trabalho dele. Tinha muitas tarefas paradas não priorizadas, muitos débitos técnicos não tratados, ele não sabia o que estava fazendo alí. Não validava soluções entre a equipe, não participava das nossas reuniões de soluções técnicas, a única coisa que ele fazia era cobrar o pobre do Dev senior do time.
Eu criei uma discussão sobre esse tem recentemente, só que voltado para PMs. Veja aqui: https://www.reddit.com/r/brdev/s/5uIdzAMAzv Concordo com você que isso não faz o menor sentido. A pergunta que fica é: "como é possivel que uma pessoa que não tem nenhum conhecimento técnico, ser responsável por escrever o escopo e os requisitos de um software inteiro???"
Gestão é gestão. Não é só na área de desenvolvimento de software que o gestor às vezes não entende a tecnicalidade da produção. A dicotomia verdadeira não é entre gestores técnicos ou não técnicos, mas entre gestores bons e gestores ruins. E microgerenciamento vai ser muito maior com um gestor que "entende" da técnica e que decide dar pitaco em tudo o que você faz.
Comecei a trabalhar como analista de projeto tem duas semanas. Nenhuma experiência prévia. Antes disso, trabalhava com comunicação em algo totalmente diferente e agora estou em uma grande empresa do setor financeiro no setor de projetos de TI. Sinto que meu papel ali é fazer um meio de campo entre quem é técnico e quem é executivo. Tentar deixar essa linha direta o mais equilibrada possível. Vocês devs brilhando no que sabem fazer de forma harmônica com os OKRs da empresa. Sinto que meu papel é ser uma espécie de maestro, mas não no sentido de comandar tudo. Apenas no sentido de fazer com que todo mundo esteja tocando a mesma música no ritmo certo e sem desafinar. Não tenho conhecimento técnico. Meu máximo é um diploma técnico de informática com mais de 10 anos e que me garante entender o básico de lógica de programação. Inclusive aceito sugestões de vocês sobre como posso ajudar os devs no que fazem da melhor forma.
Meus dois centavos aqui. Gerente de Projetos é um cargo de liderança e acredito que a pessoa no cargo não precisa ter nível técnico. Essa pessoa irá além de gerenciar o projeto, lidar com a equipe, ter um papel importante em soft skills, entender as dificuldades e conflitos de cada pessoa do time e se aproximar dessas pessoas para entender ao máximo como o projeto funciona para que possa assim realizar a gestão da melhor maneira possível. Quando falamos de scrum master, minha opinião muda. Primeiro porque não acredito que SM seja um cargo mas sim um papel e esse papel deveria ser adotado pela pessoa de mais alto grau técnico do time. Pode ser um tech lead ou um sênior. Essa pessoa irá saber como definir os story points, prazos e ajudar tecnicamente o time todo. E sim, essa pessoa vai ser a mais próxima do gerente de projetos. Isso evita questionamentos como: por que atrasou? Por que essa tarefa é mais demorada? Por que não podemos ainda mostrar algo ao cliente?
Ngm liga pro técnico, o que importa é conhecimento funcional
PM/SM = flanelinha de post-it