1
resposta

Criando uma Dev Team

  1. A Dev Team poderia ser uma squad dentro de uma empresa que não é da área de tecnologia?

  2. Trabalho na área de Atendimento ao Cliente aonde temos informações dos nossos clientes pela nossa Central de Atendimento, assim conseguimos saber quais processos os clientes mais entram em contato, quais estão mais insatisfeito e quais geram mais ocorrências. Estou querendo propor a criação de uma squad para a melhora dos processos mais críticos, onde diversas áreas da empresa, que estejam envolvidas dentro do processo, participem da squad. Mas tenho uma grande dúvida sobre os papéis dos envolvidos. Quem seria o PO? A área responsável pelo processo já que tem maior conhecimento ou eu da área de Atendimento? Quem seria o "cliente" - a pessoa que solicita os requisitos do que deve ser feito dentro do projeto? A área que é dona do processo, já que ela saberia o que deveria ser melhorado dentro do processo, algum gerente que tem uma visão mais macro do negócio ou a área do atendimento que possui informações dos clientes?

  3. Ao que vejo do curso, parece que a dev team, PO, Scrum Master ficam envolvidos em apenas um único projeto - é isso mesmo?

  4. Se sim, como fazer dentro de uma organização onde ocorrem vários projetos e atividades ao mesmo tempo? Possuem algum case para compartilhar?

  5. A metodologia ágil frisa muito a questão da priorização, mas até mesmo dentro de organizações "não tradicionais" é comum ocorrer vários projetos ao mesmo tempo ou não? O ideal é a empresa focar em um coisa, direcionando a empresa como um todo?

1 resposta

Olá Daniela.

Tudo bom?

Em relação às suas perguntas:

  1. Sim, inclusive você pode conferir dois podcasts para ter essa noção: Scrum e Agile para além de Tecnologia e Squads e Agilidade no Magazine Luiza.
  2. Existem diferentes frameworks ágeis e acredito que antes de pensar no P.O ou na figura do Scrum Master, próprios do Scrum, seja necessário, por parte de quem conhece as particularidades e circunstâncias da empresa, entender quais são os pontos engessados que não permitem respostas ao fluxo de novas informações e adaptação às mudanças. Isso é essencial antes de tudo. Além disso, no caso da figura do P.O no Scrum, existem responsabilidades muito específicas: ter visão do cenário macro; compromisso; uma boa comunicação, e claro, ser capaz de dizer o famigerado "não". Na sua pergunta você coloca "algum gerente que tem uma visão mais macro do negócio ou a área do atendimento que possui informações dos clientes?" Seria esse o caminho, pois o P.O representa o cliente no time scrum, por exemplo.

Mas, eu penso que é essencial pensar a agilidade dentro do contexto do seu trabalho, não necessariamente pegar termos como P.O dará certo para entender o que deve ser feito. Há um artigo que explora a adoção da metodologia ágil no atendimento ao cliente, acredito que possa te ajudar bastante!

Bons estudos e abraços =)