Documentação de processos - por onde eu começo?

Que tal discutir um pouco sobre como documentar os processos? Em primeiro lugar, para documentar, o processo já deve ter sido discutido com o time, os especialistas, os consultores (se aplicável), enfim, todos os envolvidos. É comum ter um esboço de um fluxo que representa o processo. Particularmente, gosto do diagrama de atividades UML para isso, que é simples, permite representar desvios, paralelismo e atende bem. Mas o mais importante é escolher alguma forma de diagrama que o time compreenda. Se for um padrão de mercado, ótimo. No entanto, é essencial que as pessoas que precisem entender do processo saibam compreender perfeitamente o desenho.

Critérios para escolher uma ferramenta:

  • Facilidade de uso, inclusive de dar manutenção no que já foi gerado - essa particularidade é especialmente importante, já que o processo é vivo e sempre, sempre evolui
  • Custo 
  • Qualidade da exportação do conteúdo - eu prefiro as que exportam em HTML e eu possa gerar um portal, acessível a todos
  • Possibilidade de customizar e adequar a particularidades do seu cenário
Uma vez escolhida a ferramenta e partindo do princípio que o processo já foi minimamente definido, é preciso registrar tudo formalmente. No post anterior eu comentei a respeito do composer, do EPF. Gosto muito dele, mas apenas uma das opções. Você deve escolher a ferramenta que achar melhor para o seu cenário.

A documentação pode ser tão complexa quanto a sua imaginação permitir, mas sugiro que a faça de uma forma simples e direta. Essa documentação deve ser de fácil interpretação e vai ser constantemente modificada. Se for feito algo muito burocrático e complexo, ninguém vai querer ler ou modificar - o que vai condenar todo o trabalho. Para ficar simples, sugiro o básico: documentar quatro elementos:
  • Tarefas
  • Produtos de trabalho
  • Material de apoio
  • Papeis
Em poucas palavras: um processo é decomposto em pequenas partes, chamadas tarefas. Cada caixinha do fluxo desenhado representa uma tarefa e cada tarefa tem um conjunto de entradas e saídas, bem como um responsável. A tarefa contém uma lista de papeis envolvidos na sua execução, e, conceitualmente, pode ter mais de um responsável, mas vá por mim: coloque apenas um papel responsável por cada tarefa. Já ouviu falar que cachorro com dois donos morre de fome? Pois é. 

Tudo o que uma tarefa gera de resultado é produto de trabalho. O produto de trabalho de saída de uma tarefa pode ser insumo para a seguinte. As tarefas devem ser associadas a papeis (uma pessoa tem um cargo, mas pode assumir vários papeis no seu trabalho). Na definição de cada papel são determinadas as responsabilidades do mesmo.

Materiais de apoio são guias, manuais e quaisquer outros documentos que ajudem na execução da tarefa.

Para o processo ficar minimamente decente, basta indicar o sequenciamento das tarefas. Pense: quais podem ser executadas em paralelo? Quais precisam esperar outra(s) acabar(em)?
Se o portal de processo permitir a publicação da versão final do seu diagrama e fazer o link com o que foi documentado, então o trabalho vai ficar bem profissional. 

Bom, converse com o comitê de processos de sua empresa e ajude a garantir a formalização e a boa documentação dos processos. Em breve, mais posts sobre processo e qualidade de software em geral.


Provocações finais

Se você não tiver processos formalizados na minha empresa, vai conseguir resolver os seu problema apenas instalando uma ferramenta para documentar processos?
Tem como falar de formalizar e documentar processos dentro da empresa sem antes criar um comitê (costumamos chamar de Grupo de Engenharia de Processos, ou EPG, que é a sigla em Inglês)?
Criei o portal de processos. Posso dizer que os processos estão implantados?
Tenho que treinar o time para usar os processos?
Processos fazem a gente trabalhar mais?
Por que que precisaria documentar os papeis e responsabilidades? Cada um não sabe o que fazer?
Por que eu precisaria me preocupar com qualidade, afinal, se alguém está fazendo algo muito errado, não é só mandar embora? Não é obrigação de todos trabalhar com qualidade?

Comentários

Postagens mais visitadas deste blog

Brilho nos olhos

Um breve olhar do que já foi escrito

Requisitos conflitantes e dilemas no projeto de software