O Jira e a Sua Arquitetura Escalável
É fato que o Atlassian Jira não é uma ferramenta para gerência de projetos. Ele é uma ferramenta para a gerência de issues (e deixo para o leitor a tradução literal desse termo - embora eu considere uma issue uma coisa qualquer que precisa ser controlada e, obviamente, resolvida em algum momento).Não obstante a isto, eu utilizao o Jira como ferramenta para a gerência de projetos, e o considero superior em muitos aspectos mesmo em relação à ferramentas criadas especificamente para isso, tais como o TraceGP, o DotProject, o MSProject ou mesmo o (caro) Primavera.
Considero o Jira algo como a IDE Eclipse, que ao primeiro contato consideramos insuficiente e rudimentar, mas que para o bom utilizador, facilmente transforma-se naquilo que quisermos e com uma eficiência e eficácia incomparáveis frente a outros produtos.
Isso ocorre porque o Jira - assim com todos os outros produtos da australiana Atlassian - é uma ferramenta com uma arquitetura aberta, escalável e propenso a plugins de quaisquer natureza.
Como características que mais eu gosto no Jira estão seus Workflows e telas (Screens) customizáveis. E são justamente estas características as que exponencializam o seu poder.
Entretanto, este post não fala desses recursos, e sim do uso de campos customizados.
Riscos e Incidentes Através de Tarefas e Campos Customizados
Nos nossos projetos, diversos campos customizados são utilizados em conjuto com tipos de tarefas distintas, criadas especificamente para o nosso modelo de negócio.
Assim, para este post, duas tarefas são de suma importância: tarefas que representam riscos de projeto e tarefas que representam incidentes de projeto.
Risco de projeto é tudo aquilo que, caso ocorra, pode impactuar no aumento do custo (monetário, temporal, de recursos, etc) do projeto.
Incidente de projeto é tudo aquilo que (tenha sido ou não mapeado anteriormente) evento ocorrido ue interfere danosamente no projeto.
Conseguir gerenciar (e contornar) os riscos e evitar os incidentes é uma das tarefas do gerente do projeto.
Outra atividade de gerência importante - porém muitas vezes negligenciada - é co-relacionar os riscos e incidentes, verificando sua causa, responsabilidade, atividades de contorno, impacto e outras ações.
Tudo isso eu faço no Jira, usando:
1. Um tipo de tarefa para registrar riscos: que são convertidos em "horas-de-projeto" para mensurar seu impacto no projeto.
2. Um tipo de tarefa para registrar incidentes: que efetivamente marcam quantas "horas-de-projeto" quando ocorrem.
3. Um campo customizado de issue que indica a responsabilidade do incidente, que eu gosto de vincular a um desses valores: O Cliente (quando o cliente foi responsável pelo incidente); A empresa (quando nós fomos os responsáveis pelo incidente); Terceiro (quando um terceiro - como um outro fornecedor do cliente - foi o responsável pelo incidente). NOTA: Caso seja necessário identificar o nome da pessoa (ou outro recurso) causador do problema, eu opto por usar o campo "Comentários" da tarefa, onde eu posso usar o (ótimo) sistema de segurança do Jira para escolher para quais perfis do projeto (por exemplo, diretores, gerentes, etc) vão saber essa informação.
4. Relacionamentos do tipo (pode ser qualquer tipo, mas eu uso estes) "is derivated from" e "derive to".
5. Uma matriz de relacionamento entre tarefas do projeto que são do tipo "Risco de Projeto" e "Incidente de Projeto", a qual mostra os pontos onde os riscos transformaram-se em incidentes.
Aqui, tento mostrar isso:
Informações Úteis
Juntando tudo isso, eu posso facilmente localizar todos os riscos do projeto e mostrar para diretoria, indicando "olha, se isso ocorrer, o impacto no projeto vai ser tantas hora a mais ou então tando $ a mais" ou mesmo "olha, esses riscos existem, e podem ser contornados, cada um, dessa forma" ou ainda "olha, esses riscos existem, e a maioria deles é de origem interna nossa, onde nossos desenvolvedores precisam um treinamento maior na tecnologia X".
Outra coisa que dá para mostrar, é a relação entre Riscos e Incidentes, como "olha, mesmo nós tendo mostrado lá no início do projeto que existiam X riscos no projeto, os Y incidentes ocorreram derivados desses riscos, sendo que a maioria foi em consequência da falta de segurança no componente Z do projeto, que era gerenciado pela pessoa P, a qual (hoje sabemos) não nunca tinha trabalhado com isso antes".
Resumindo
Queria escrever muito mais sobre técnicas que usamos sobre o Jira para mantermos nossos projetos e que, como disse, ao usuário de primeira viagem, passam despercebidas nessa maravilhosa ferramenta.
Como disse, outras ferramentas como as comentadas acima têm módulos para conseguir essas informações, mas a flexibilidade (nem entrei no mérito de criar fluxos - Workflows - customizados para gerenciar cada um desses Riscos ou Incidentes) que o Jira possui.
Em suma, o Jira é muito show :)
Como características que mais eu gosto no Jira estão seus Workflows e telas (Screens) customizáveis. E são justamente estas características as que exponencializam o seu poder.
Entretanto, este post não fala desses recursos, e sim do uso de campos customizados.
Riscos e Incidentes Através de Tarefas e Campos Customizados
Nos nossos projetos, diversos campos customizados são utilizados em conjuto com tipos de tarefas distintas, criadas especificamente para o nosso modelo de negócio.
Assim, para este post, duas tarefas são de suma importância: tarefas que representam riscos de projeto e tarefas que representam incidentes de projeto.
Risco de projeto é tudo aquilo que, caso ocorra, pode impactuar no aumento do custo (monetário, temporal, de recursos, etc) do projeto.
Incidente de projeto é tudo aquilo que (tenha sido ou não mapeado anteriormente) evento ocorrido ue interfere danosamente no projeto.
Conseguir gerenciar (e contornar) os riscos e evitar os incidentes é uma das tarefas do gerente do projeto.
Outra atividade de gerência importante - porém muitas vezes negligenciada - é co-relacionar os riscos e incidentes, verificando sua causa, responsabilidade, atividades de contorno, impacto e outras ações.
Tudo isso eu faço no Jira, usando:
1. Um tipo de tarefa para registrar riscos: que são convertidos em "horas-de-projeto" para mensurar seu impacto no projeto.
2. Um tipo de tarefa para registrar incidentes: que efetivamente marcam quantas "horas-de-projeto" quando ocorrem.
3. Um campo customizado de issue que indica a responsabilidade do incidente, que eu gosto de vincular a um desses valores: O Cliente (quando o cliente foi responsável pelo incidente); A empresa (quando nós fomos os responsáveis pelo incidente); Terceiro (quando um terceiro - como um outro fornecedor do cliente - foi o responsável pelo incidente). NOTA: Caso seja necessário identificar o nome da pessoa (ou outro recurso) causador do problema, eu opto por usar o campo "Comentários" da tarefa, onde eu posso usar o (ótimo) sistema de segurança do Jira para escolher para quais perfis do projeto (por exemplo, diretores, gerentes, etc) vão saber essa informação.
4. Relacionamentos do tipo (pode ser qualquer tipo, mas eu uso estes) "is derivated from" e "derive to".
5. Uma matriz de relacionamento entre tarefas do projeto que são do tipo "Risco de Projeto" e "Incidente de Projeto", a qual mostra os pontos onde os riscos transformaram-se em incidentes.
Aqui, tento mostrar isso:
Informações Úteis
Juntando tudo isso, eu posso facilmente localizar todos os riscos do projeto e mostrar para diretoria, indicando "olha, se isso ocorrer, o impacto no projeto vai ser tantas hora a mais ou então tando $ a mais" ou mesmo "olha, esses riscos existem, e podem ser contornados, cada um, dessa forma" ou ainda "olha, esses riscos existem, e a maioria deles é de origem interna nossa, onde nossos desenvolvedores precisam um treinamento maior na tecnologia X".
Outra coisa que dá para mostrar, é a relação entre Riscos e Incidentes, como "olha, mesmo nós tendo mostrado lá no início do projeto que existiam X riscos no projeto, os Y incidentes ocorreram derivados desses riscos, sendo que a maioria foi em consequência da falta de segurança no componente Z do projeto, que era gerenciado pela pessoa P, a qual (hoje sabemos) não nunca tinha trabalhado com isso antes".
Resumindo
Queria escrever muito mais sobre técnicas que usamos sobre o Jira para mantermos nossos projetos e que, como disse, ao usuário de primeira viagem, passam despercebidas nessa maravilhosa ferramenta.
Como disse, outras ferramentas como as comentadas acima têm módulos para conseguir essas informações, mas a flexibilidade (nem entrei no mérito de criar fluxos - Workflows - customizados para gerenciar cada um desses Riscos ou Incidentes) que o Jira possui.
Em suma, o Jira é muito show :)
0 comentários:
Postar um comentário