Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas

Como podemos e devemos proceder se em uma das priorização surge obstáculos e empecilhos que não depende de ações minhas

Por exemplo: eu fiz uma de lista de tarefas e atividades pendentes e desejadas por mim seguindo o exercício do curso e depois classifiquei no na matriz de Eisenhower por priorização. Porém se algo em uma dessas priorizações não depende de mim para que eu conclua o objetivo final como devo e posso proceder? Levando para o lado profissional se em um projeto eu tenho uma lista de funcionalidades e cada funcionalidade tem sua priorização já analisada se em algum momento eu dependa do cliente, ou de um design, etc para concluir tal funcionalidade e objetivo... como deve me posicionar? Não basta nossa empresa aderir modelos ágeis se o cliente não acompanhar a evolução e o ritmo.

2 respostas
solução!

Natthy, tudo bom? No Ágil temos algumas abordagens para esses casos. No Scrum, por exemplo, existe um papel que fica responsável por tirar esses bloqueios: o Scrum Master (SM). Quando estamos lidando com tarefas pessoais, somos nosso próprio SM e precisamos entender e ter planos para esses bloqueios. Estabeleça prazos, cobre, converse no caso de atrasos e escale se for necessário. O importante é você ter o controle sobre essas tarefas e prazos, sabendo que nem tudo vai sair como você espera. Em relação ao cliente é sempre uma relação de transparência. Algo muito comum, você faz um backlog para a Sprint com os itens que serão entregues. Durante a Sprint o cliente (ou outro cliente) fica indo direto nos desenvolvedores pedindo outras tarefas. Ao final da Sprint ele reclama que nada do que ele pediu foi entregue. Nesse momento, como temos o controle, mostramos exatamente o que aconteceu e pq não foi entregue. Acho interessante o curso de comunicação da #alura. Lá você tem algumas dicas de negociação, habilidade muito importante para quem lida com esse tipo de situação.

Eu imagino que o tipo de impeditivo que a @natthypaulaborges está falando é algo técnico, como é o caso do design. Nesse caso, não acho adequado que seja associada a figura do SM para resolver esse problema.

Uma das bases do ágil é que o time seja autogerenciado, e para isso é importante que o time tenha engajamento e segurança para comunicar e negociar com seus pares. Por isso incentivo que você mesma comunique sua necessidade e negocie uma solução. Se for algo que não possa ser feito sem onerar o trabalho durante a sprint/iteração atual, isso deve ser comunicado aos envolvidos, e em comum acordo repriorizado.

Um papel que surge em alguns times para suprir essa necessidade é o do Tech Lead, que é, geralmente, um dos devs do projeto e responsável por transmitir a opinião e necessidades técnicas do time. Dessa forma ele também é um dos Stakeholders do projeto.

Já o Scrum Master, é também um papel que pode ser assumido por um dos integrantes do time, como devs ou designers, mas que fica responsável por facilitar o entendimento e uso do Scrum. Misturar a responsabilidade de tomar decisão ou resolver impedimentos de execução do projeto com a facilitação do Scrum pode comprometer um das duas coisas, pois no meu entendimento elas podem ser antagônicas.