Quando usar mecanismos de fluxo de trabalho?

Já trabalhei em alguns dos mecanismos de fluxo de trabalho como programador, mas nunca tive uma clareza sobre por que escolhemos os mecanismos de fluxo de trabalho em primeiro lugar. E como programador eu sei que existem pelo menos 100 maneiras de fazer qualquer coisa quando você está escrevendo código, mas apenas algumas são as melhores!

Ainda não entendo quais casos de uso são melhor resolvidos pelos mecanismos de fluxo de trabalho (ou melhor, pelo conceito deles) do que projetando um bom aplicativo habilitado para DI. Estou procurando por características gerais de casos de uso neutros em domínio, nos quais os mecanismos de fluxo de trabalho são uma das melhores opções.

Portanto, minha pergunta é: quais são as características gerais de um requisito que podem ser tomadas como um sinal para optar por um bom mecanismo de fluxo de trabalho e codificá-lo?

Um mecanismo de fluxo de trabalho é útil quando você precisa ir do início ao fim, mas existem muitos caminhos / lógica / regras diferentes para chegar lá.

Por exemplo, digamos que eu escreva um programa que publique conteúdo. Portanto, no meu caso, a publicação passa por um processo de revisão, legal e depois pela aprovação final. Escrevo o programa implementando minha lógica e etapas do processo. Agora, este trabalho é ótimo para mim e minha empresa. Então, eu decido que outros devem usar meu programa.

Infelizmente, nem todo mundo publica conteúdo usando o mesmo processo; portanto, em vez de escrever processos separados para cada caso diferente, implementaríamos um processo de fluxo de trabalho para que o programa seja flexível para acomodar todos. Não importa quantas etapas, regras ou lógica estejam entre esses dois pontos, o resultado será o mesmo.

Portanto, se você tiver processos variáveis ​​do início ao fim, use um fluxo de trabalho. Se o mesmo processo puder ser usado por todos, você não precisará de um fluxo de trabalho.

Sei que você pediu casos de uso, mas é mais fácil listar as vantagens do que imaginar todos os casos de uso possíveis. As vantagens, é claro, dependem do mecanismo e do idioma que você está comparando, mas em geral:

1. Manter regras como dados em vez de código significa que você não precisa recompilar, portanto, você pode testar as alterações rapidamente, alterar no tempo de execução, etc. Não há muita vantagem se você não precisar recompilar em primeiro lugar.

2. É mais provável que os usuários editem as regras. Eles podem mexer com eles interativamente de maneiras que não são viáveis ​​quando um programador escreve um código para eles.

3. Manter regras como dados permite que ferramentas sejam escritas para visualizar e alterar os dados.

4. Manter as regras como dados permite a metaprogramação com mais facilidade - você pode escrever um código para analisar os dados e inserir mais de uma maneira complexa, o que seria muito difícil para o código.

É possível fazer todas essas coisas diretamente com o código (por exemplo, escreva um analisador de C # para encontrar todas as regras de um determinado tipo e gere código para mais regras, insira-o dinamicamente em um assembly de uma maneira que permita o descarregamento do conjunto, escreva ferramentas para os usuários podem fazer isso também usando o visualizador e o editor), mas pode ser muito mais difícil dependendo do seu idioma (os programadores que usam um Lisp podem se referir aos itens de 1 a 4 como "programação").

No entanto, o único caso em que você deve usar esse tipo de coisa é quando ele pode ser configurado por usuários menos valiosos. Se você puder resolver seu problema, fornecendo uma ferramenta, voltando a trabalhar em outra coisa mais importante, use uma.

Se você ainda precisar configurá-lo para eles, imagino que você possa pensar em 10 maneiras diferentes de obter o mesmo resultado com uma ferramenta que você conhece e será muito mais fácil oferecer suporte e personalização.

Parece uma pergunta antiga, mas surge várias vezes na natureza. Eu concordo com a resposta de Jon . Eu achei os mecanismos de fluxo de trabalho altamente produtivos nos seguintes cenários:

1. Existe um processo comercial subjacente que você está tentando representar / implementar por meio do seu software.
2. Existe uma única entidade comercial (talvez composta) que é trabalhada em todos ou alguns dos estágios do processo. No exemplo que Jon deu, essa entidade ou Item de Fluxo de Trabalho seria conteúdo ou um artigo. Considere o rastreamento de erros como outro exemplo de um fluxo de trabalho, um Bug transita entre vários estados, com base em uma ação que um usuário executa.
3. Use os Fluxos de trabalho para modelar seus processos, apenas se você espera que o processo de negócios mude. Por mudança, quero dizer a sequência ou ação executada como resultado de uma ação ou transição do usuário.

Seja muito cuidadoso e crítico para verificar se o domínio / requisitos do seu problema tem um processo de negócios, não tente "ajustá-lo" a um fluxo de trabalho.

Eu tenho algumas diretrizes que eu uso para sugerir mecanismos de fluxo de trabalho.

1) Quando os analistas de negócios não têm formação em codificação, mas podem desenhar diagramas.

Os modernos mecanismos de fluxo de trabalho usam a notação de modelagem de processos de negócios ou as versões menos capazes disponíveis no SharePoint e sistemas similares. Isso permite que membros da equipe tecnicamente competentes e com dificuldades de codificação projetem e desenvolvam muitos fluxos de trabalho.

2) Quando você precisar monitorar o andamento dos trabalhos, faça escalações, alterne entre processos controlados por computador e processos controlados por humanos.

Monitoramento e auto-referência são características dos modernos mecanismos de fluxo de trabalho.

Da perspectiva dos negócios de RH, os mecanismos de fluxo de trabalho são muito importantes.

1. Eles fornecem um processo estruturado, mesmo que seja sempre o mesmo.

2. Eles fornecem transparência

   • Quem solicitou a alteração,
   • Quando foi solicitado,
   • Quem aprovou etc.

   Essa transparência ajuda a conduzir o processo e promove a propriedade.

Supondo que os formulários sejam integrados e inteligentes, suportando a lógica de negócios, ele também tem um efeito dramático na linha do tempo, na eficiência do processamento e na qualidade dos dados. A segurança também é uma consideração e é muito preferível conter informações confidenciais em um sistema seguro do que ter formulários em papel aguardando a assinatura. Também é muito mais móvel. Após uma implementação recente, um gerente me disse que isso evitava muitas dificuldades ao publicar as coisas para ele assinar, enquanto viajava muito.

Em nome do RH: Viva o fluxo de trabalho !!!