Vi no exemplo a hierarquia com Diretoria, Gerente do Produto e Dono do Produto, onde abaixo dele estariam o Scrum Master e Time de Dev. Se o PO é mais focado em negócio, como ele poderia ser um líder do time de desenvolvimento sem conhecimento técnico? Vim de empresas que sempre existiram cargos de Coordenador de Desenvolvimento de Sistemas onde alguns eram muito fracos em diversos quesitos inclusive tecnicamente. Mas por outro lado, já tive coordenador com habilidades técnicas fantásticas, na qual exercia liderança servidora, professoral, delegadora e sempre focado em atingir a excelência da equipe e entrega dos projetos. O foco na qualidade do código, capacitação técnica e vida pessoal eram muito bem balanceada e com isso ele tinha o respeito e a equipe toda a seu favor, sem contar o cliente (empresa) que adorava porque as entregas eram sempre com alta qualidade. Um PO conseguiria exercer esse tipo de coordenação? Assisti as aulas de Scrum e não vejo um papel técnico para colocar ordem na maneira como os sistemas são codificados. Programador não pode desenvolver como quer. Ele deve programar para o time de modo que seja fácil a manutenção do código, seguindo melhores práticas, padrões de mercado, segurança, etc.
Solucionado
(ver solução)
respostas
Perfil de Coordenador de Desenvolvimento de Sistemas
Carlos, o PO não é o líder da equipe, por definição a equipe não teria um "líder", todos possuem exatamente a mesma responsabilidade sobre a entrega, o que o PO faz é definir quais são as estorias que serão priorizadas para atingir um determinado objetivo que é de conhecimento da equipe, porem se ocorrer algum problema na entrega o time todo é responsável igual, pois como time um deve ajudar o outro.
Exemplificando: No time de futebol o tecnico não é mais e nem menos importante que o goleiro e o atacante, porem se o time perde uma partida todos tem a mesma responsabilidade.
Referente ao ponto que levantou que normalmente é bem polemico sobre a orientação de boas práticas, isso realmente é um caso mais complexo de se resolver, mas normalmente é direcionado na criação da equipe, onde pode ser apresentado todas as restrições / direcionadores da empresa para poder ter uma padronização de linguagens, codificação e etc, porem tome bastante cuidado com esse ponto, pois se tentar direcionar tudo como deve ser feito, terá programadores "pedreiros", ou seja, eles vão fazer apenas o que está sendo pedido sem qualquer aspecto de inovação e isso pode gerar desmotivação da equipe, alem de tirar de certa forma a responsabilidade da equipe.
Acredito que o melhor nesse caso é definir as restrições, ou seja, o que ele não pode fazer, pois assim consegue evitar "absurdos" e por outro lado deixa o poder criativo com o time que é extremamente importante.
Excelente pergunta! Espero ter ajudado.
Olá Vitor, não consigo imaginar um time de desenvolvimento sem uma liderança técnica. Em desenvolvimento, os desenvolvedores podem chegar a um resultado final de maneiras bem diferentes. Um pode programar de maneira limpa, clara, seguindo padrões de nomenclatura, designs apropriados e de maneira segura, mas em compensação outros podem não ser tão profissionais ou experientes e no pior dos casos, podemos ter adeptos do Extreme Go Horse no time na qual usa as piores práticas de programação. Um desenvolvedor não pode programar do modo que ele quer (principalmente geração Y e Z). Ele precisa entender que está em um time. Se somente ele entender o código dele e amanhã ele mudar de emprego, como fica o time? O direcionamento não significa que eles serão "pedreiros". Porém é inadmissível permitir que o desenvolvedor utilize qualquer arquitetura, framework de desenvolvimento ou componente que ele desejar. Muitos jovens são guiados por tecnologias da moda onde muitas não vingam. Ou simplesmente utilizam arquitetura incorreta para determinado tipo de projeto e até mesmo componentes open source que não estão consolidados e podem trazer problemas futuros por descontinuidade ou até mesmo por falha de segurança. Sem alguém para determinar certas diretrizes, o time de desenvolvimento pode construir um sistema que atenderá o cliente sob o olhar de negócio, mas por dentro pode haver um "pão bolorento" e que causará transtornos para a empresa. Falha de segurança, complexidade de código, código Go Horse, arquitetura ou framework indevido são cenários críticos para qualquer desenvolvimento de software. E não adianta pensar em ter um arquiteto ou lider técnico na squad porque os itens que falei devem ser pensados em nível mais amplo porque os mesmos itens precisarão ser respeitados em demais times ou equipes. Negligenciar o papel de um coordenador de sistemas que deveria garantir que estes itens sejam respeitados, seria como deixar os "pedreiros" tocarem uma obra sem a necessidade de mestre de obra ou engenheiro. Além dos itens que citei, enxergo o coordenador também como responsável por motivar por exemplo com liderança servidora e professoral, participando de soluções, incentivando qualidade e planejando a capacitação contínua do time de desenvolvimento para as visando tecnologias definidas baseado nos tipos de projetos aprovados pela diretoria. Já participei de time com um coordenador de sistemas muito técnico. O cara era um exemplo, várias certificações, dava muita importância na qualidade do código, performance e manutenibilidade do código e testes. Todo o esforço era reconhecido pelo cliente (empresa) e pelo próprio time. Esse tipo de perfil hoje não é importante? Se ainda for, como se encaixa em metodologias ágeis como Scrum?
A orientação/evolução dos desenvolvedores é sempre importante, porém nesse caso o "coordenador" pode ficar fora do time, na verdade deve funcionar CROSS para todos os times de desenvolvimento, vou até um pouco mais além, nesse caso em vez de ter um coordenador geral de sistemas, deveria ter vários coordenadores especializados em cada função (design, desenvolvimento, QA, SM e PO), pois eles são as referencias para cada função do time, mas vejo isso fazendo mais sentido se a empresa tiver vários times e a função dos coordenadores seriam cross.
Se a empresa for pequena e tiver apenas um time, o desenvolvedor sênior pode ir orientando o time.
Mas pegando carona no que falou, se o desenvolvedor faz um trabalho ruim , em algum ponto vai ser pego , seja no teste, no bug ou na evolução e nesse momento deve ser levado para o time a qualidade do código (em uma retrospectiva por exemplo).
Para finalizar, o papel do "coordenador" seria ele capacitar o time de forma que não tivesse que ficar explicando o básico, vejo que uma vez que o time teve amadurecimento para desenvolver sozinho, o coordenador tem que fazer o papel de buscar inovação no mercado e verificar o que pode ser aplicado e compartilhar com o time, é importante fazer de alguma forma que o time tenha segurança no desenvolvimento e não fique refém do coordenador, isso deixará sempre o time mais motivado.
Espero ter ajudado e entendo bem o que vc está falando, até pq tenho problemas similares ao que vc falou em um dos times da minha área, assim como tenho um time maduro que consegue fazer tudo sozinho de forma bem feita, então é sempre importante ver o quanto o time é maduro e dar a autonomia conforme a experiência de cada time.
Obs: no meu caso existe a figura do Enganheiro de Software que da sempre o direcionamento das coisas mais impotente e verifica se esta sendo feito, além de ter os líderes de cada função (design, desenvolvimento, ux, po, sm) para trazer as novidades para cada perfil