Alguns meses atrás comecei a refletir bastante sobre a importância de processos bem definidos. Quando se fala em processos organizacionais talvez algumas pessoas relacionem com estruturas engessadas e planos e estratégias burocráticas dentro de uma organização. Pra mim processo é um plano que organiza e orienta as pessoas no entendimento de suas atividades e do negócio da empresa. Isso não significa que não possa mudar e adaptá-lo a realidade ágil do mercado mas temos que levar em consideração que os atores que dão sentido a existência aos processos são justamente as pessoas que o executam.
No que se refere a desenvolvimento em TI, processos ao meu ver precisam ser ágeis e coerentes com a realidade e cultura organizacional para que se obtenham os resultados esperados. Parece óbvio mas muitas empresas ignoram ou não dedicam tempo suficiente para amadurecer e definir seus processos justamente por acreditar que o conceito de ser ágil é não ter processo.
Não existe certo ou errado nesse quesito e se sua empresa está dando certo sem processos claros e definidos certamente ela ganhou um grau de maturidade elevado que já não faz mas sentido focar seus esforços em amadurecer processos. Porém, acredito não ser essa a realidade de muitas empresas de TI considerando altos índices de queixas de atrasos de projeto, rotatividade de funcionários e clientes insatisfeitos.
As contra-indicações da ausência ou um processo ineficiente são:
- Culpar os colaboradores por ações que deveriam ser realizadas mas são completamente obscuras
- Desorganização
- Ruídos na comunicação
- Frustração
- Atrasos nas entregas
- …
Mas afinal quem define os processos?
Talvez se essa pergunta fosse feita alguns anos atrás a resposta seria o gerente, o departamento de processos, o diretor, o dono da empresa… e pode até ser que em alguns lugares ainda funcione dessa forma. Mas o fato é que todos os colaboradores independente de sua posição hierárquica influenciam e refinam os processos. Quanto mais uma organização investe em discutir e adaptar processos de modo colaborativo, mas fácil fica para os colaborares acreditarem na sua real eficiência pois mais próximo será da realidade vivida diariamente. Além disso,
é discutindo e testando processos que são descobertas formas mais ágeis para uma tarefa ser executada que talvez no final sejam o diferencial para entregar o projeto ou funcionalidade no prazo acordado.
Vamos pensar que temos um projeto de desenvolvimento de software para executar e que parte do time está trabalhando remotamente. O time é composto de programadores, designers, analistas e arquitetos que estão trabalhando juntos pela primeira vez. Ou seja, o time não tem maturidade suficiente para executar o projeto sem pelo menos uma noção do processo a ser seguido. Por isso, dentre as principais dúvidas que podem emergir:
- Como essas pessoas irão se comunicar? Para organizar a comunicação entre os membros do time é preciso ter bem definido quais são os principais canais de comunicação e em que momento serão utilizados.
- Quais são as pessoas chave do projeto e quais são suas responsabilidades? É preciso ter claro o fluxo de comunicação e para isso cada colaborador deve ter claro seu papel no projeto. É preciso definir quem é o contato com o cliente/atendimento, o responsável por dar suporte ou ainda qual o papel de cada desenvolvedor. Esses papeis e posições precisam estar claro para todos, para que se tenha conhecimento de quem acionar quando um problema surge.
- Quem é o líder? A posição de liderança é uma das mais difíceis de ser conquistada e é justamente o líder a figura responsável por incentivar o aprimoramento do processo, durante o desenvolvimento, através de retrospectivas e feedbacks constantes com o time.
- Qual é o fluxo? Pra mim essa parte é o cérebro do processo pois ela delimita a entrada e saída da informação. Por onde as demandas entram? Quais são os departamentos acionados? Qual o tempo de resposta? Quais são as ações da linha de frente e de suporte a serem tomadas.
As respostas a todas essas perguntas permitem aos membros dos times um controle e organização maior de suas atividades e se bem liderado respostas e entregas mais rápidas. A visão é ampliada pois agora o time tem um mesmo objetivo e caminho a ser seguido e por isso são um time. As individualidades são deixadas de lado pois as pessoas conhecem e sabem a quem se reportar em momentos críticos, sabem qual o caminho da informação e os canais de comunicação a serem utilizados para que os requisitos e solicitações do cliente não caiam no esquecimento. Por isso, pensando em processo estamos também pensando na experiência do cliente que muitas vezes é ignorada ou esquecido no decorrer do projeto.
Service blueprint
Utilizando uma ferramenta de design thinking, o service blueprint, é possível organizar fluxos e mapear processos. No modelo abaixo, foquei em um processo que era ignorado por uma empresa onde trabalhei e que gerava demandas de desenvolvimento. As solicitações de melhorias, nada mais eram que pedidos de clientes para ajustes e sugestões de melhorias para o software desenvolvido pela empresa. Se pensarmos que clientes de forma totalmente espontânea estavam oferecendo feedbacks sobre os produtos da empresa e que muitas vezes esses pedidos ou sugestões eram ignorados, vemos uma fonte de informação que pode gerar um conhecimento mais amplo do negócio sendo jogada fora.
Assim, no modelo abaixo buscamos entender e propor canais oficiais de comunicação na tratativa dessas demandas. Também destacamos o fluxo da demanda, sua origem e os times que deveriam e poderiam ser acionados para a solução dos problemas levantados. Esse processo entendia a importância da resposta e foi concebido e adaptado colaborativamente entre todos os envolvidos. Ele não é perfeito e nem definitivo mas é de valiosa ajuda quando exposto de forma visual para que as pessoas entendam e visualizem o caminho seguido, afinal quando reconhecemos nossas falhas é quando as mudanças mais significativas acontecem.
Curtiu? deixe seu comentário