+-+Copy.jpg)
Todos nós notamos que atualmente o mercado não está mais tão disposto a pagar por qualidade quanto a quinze anos atrás. Na verdade o cliente exige a qualidade a baixo custo, exige que o fornecedor conheça seu negócio e o negócio do seu cliente, exige que a solução, serviço ou produto a ser entregue seja aderente, flexível, robusto e estável. Os tempos são outros, a concorrência aumenta e os modelos de gestão por projetos em alguns mercados se consolida a cada dia como a solução para atingir os resultados pretendidos. Parece quem, enfim, a era industrial passa o bastão para a era do conhecimento.
Exemplos de empresas desta nova era são as muitas empresas de Softwares e soluções de TI. Elas são uma vanguarda no que diz respeito a produtos, serviços. Não apenas por trabalharem com tecnologia, mas por estarem mais aptas a adorem modelos de gestão onde o gerenciamento do conhecimento deve ser utilizado.
Mas por que este é um tipo de negócio tão diferente das empresas do passado? Uma frase que escutei a algum tempo atrás: “empresa de software não tem estoque”.
Sua matéria prima são idéias, conhecimentos tecnológicos e outros conhecimentos específicos relativos aos produtos da empresa além do conhecimento do negócio dos seus clientes: hoje em dia não conseguimos desenvolver nada realmente útil se não obtivermos a satisfação do usuário na prática do negócio.
Por este motivo muitas destas empresas estão buscando novos modelos de gestão dos seus processos e dos seus projetos. Modelos que dão ênfase para o foco aos clientes, mas sem submeter os membros da equipe a qualquer formato de controle autoritário ou de supervisão. Muitas empresas de software (pelo menos as que já perceberam que uma gestão mais sustentável e participativa é urgente para sua sobrevivência!) passam a delegar ao invés de centralizar, buscar a discussão produtiva para sanar os problemas ao invés de apontar alguém como responsável. Por qual motivo? Porque é a decisão mais assertiva a ser tomada! As burocratizações impostas por alguns modelos não tem força de influência na cultura destas empresas. Nelas a pesquisa por novas tecnologias e modelos não se prendem a obrigatoriedades: elas implementam o que é saudável e põem de lado o que não lhes serve para o momento. Estas são as famosas “learning organizations” profetizadas por Peter Senge e companhia. Elas buscam modelos para reter e desenvolver a capacidade de suas equipes em criar soluções cada dia mais avançadas, atrativas e baratas, que agreguem real valor aos seus clientes, fidelizando-os.
Este fato faz com que muitas destas empresas trabalhem dentro de um modelo projetizado de trabalho. Mas qual seria o modelo de gerenciamento de projetos mais viável e interessante?
Temos o PMI e toda a metodologia clássica de gestão de projetos que, por muitas vezes, dá ênfase ao processo e ao planejamento e ao controle em detrimento à execução e a pragmática e assertividade da interação com o cliente (característica do modelo de Gerenciamento Ágil de Projetos).
Prós e contras
O Gerenciamento Clássico de projetos (proposto pelo PMI) faz com que o planejamento seja obrigatoriamente realizado de forma detalhada logo no início. Basicamente tudo estará contido no escopo do projeto (o que será feito e o que não será feito muitas vezes).
Este formato funciona muito bem para a construção de um prédio ou de uma ponte, onde as necessidades de customização não são mandatórias (mesmo que desejáveis). Já para o gerenciamento de uma fábrica de software este modelo pode gerar muito retrabalho, negociações, controles de aceites e por conseqüência gerar alongamento de prazos e desconfiança (Imagine-se recebendo um documento com 180 páginas para ser lido e aceito em uma semana: o cliente não tem tempo de parar sua operação para analisar um bloco de informações tão grande e também não está disposto a correr o risco de aceitar um recurso que não lhe atenderá plenamente): precisaríamos de pessoas chaves do cliente (conhecedoras profundas das regras de negócios e posicionamento estratégico atual e futura da empresa) muito disponíveis e dispostas a participar do processo de criação da solução. Com este envolvimento e participação os próprios usuários se comprometem de forma mais profunda com o projeto e seus resultados do que quando não é valorizado e considerada sua participação ativa. Precisamos também de pessoas com profundo conhecimento dos produtos e da tecnologia envolvida para as customizações, além, é claro, de habilidades de relacionamento e negociação com os envolvidos. O modelo de gerenciamento ágil tem uma perspectiva mais dinâmica de pesquisa e, por envolver muito o cliente, pode apresentar atividades pouco objetivas no que diz respeito a conclusão de entregáveis. Neste não temos um escopo fechado e completamente detalhado mas uma visão (por muitas vezes subjetiva) sobre o que deve ser contemplado no projeto, a especulação sobre possíveis soluções alternativas, novas tecnologias e formas de se chegar aos resultados pretendidos (sempre envolvendo o cliente no aceite destas possibilidades) , a adaptação das soluções planejadas em conjunto, remetendo possivelmente a novos ciclos de especulação e a adaptação até que seja definido o encerramento do projeto após o recebimento e validação das soluções propostas em produção.
Teoricamente parecem ser incompatíveis os dois modelos, mas na prática ocorrem naturalmente muitas vezes. Quando a empresa de TI não é bem estruturada em gerenciamento de projetos (pelo menos nenhuma estruturação visível ou perceptível) ela sente através da sua demanda de trabalho a natural necessidade de organizar equipes e pacotes de trabalho que identifiquem as necessidades dos clientes (em menor grau de detalhamento inicialmente e depois gradativamente melhorando suas forma de solicitar desenvolvimentos, customizações, manutenção e suporte). Os serviços podem ser neste caso naturalmente planejados dentro de períodos curtos (dias ou semanas) para que o coordenador tente antever a necessidade de alocação e capacidade de produção de seus recursos (desenvolvedores, analistas e consultores) – quase como fosse um projeto semanal de tarefas e atividades. Neste caso não existe a possibilidade de determinação de encerramento destas atividades muitas vezes e por isso deixam de ser tratados como mini-projetos (de desenvolvimento) e passam a ser tratados como serviços (de manutenção/suporte).
Dificuldades nos dias de hoje
A demanda por customizações cresce a cada dia. O cliente não quer muitas vezes se adequar a processos pré-determinador, rígidos e pouco aderentes a realidade e maturidade da empresa cliente. Atualmente é entendido e aceito que um pequeno distribuidor (por exemplo) pode ter um processo muito distinto (e não apenas simplificado) em comparação a um grande distribuidor, pois a vertical de negócio já não é suficientemente flexível nos sistemas atualmente existentes para atender a todas as necessidades (e quando são flexíveis passam a ser por muitas vezes complexos, confusos, utilizando termos e conceitos que podem ser diferentes dos utilizados pela cultura no cliente).
Já está claro que o cliente precisa de aderência de suas das regras de negócios (implícitas e explícitas) ao sistema de gestão a ser adotado. A dificuldade que surge em primeiro lugar é o fato de que as pessoas chaves no cliente e outros envolvidos nem sempre conhecem de antemão a solução desejada. Elas tem uma idéia funcional genérica que não chega ao nível de tratamento das informações de entrada e saída de cada processo. Fora isso, a cultura da empresa pode adotar formatos e termos específicos diferentes dos academicamente aceitos e utilizados.
Ocorre também muitas dificuldades de compreensão ou incompatibilidade de significados entre termos como “tipo de pedido” e “operações fiscais” ou “Pedido de clientes” e “Ordens de Vendas”, ou “Orientação à compras”, “Planejamento Logístico” e “Demanda de Suprimentos”. Este alinhamento é necessário entre pessoas com perfil de gestão e negócios e algumas vezes com perfil técnico/especialista.
Além disto o gerenciamento de mudanças torna-se um complicador ao invés de ser uma forma de facilitar a definição sobre o que está e o que não está dentro do previsto ao escopo. Como o escopo é subjetivo (uma visão orientadora sobre as funcionalidades a serem contempladas apenas) não se caracteriza facilmente uma mudança de escopo mas sim uma nova definição específica de customização. Neste caso SLAs podem ser perigosamente danosas.
Qual é a saída?
Depende! Uma forma entre a clássica e a ágil que, adequada pelo bom senso de cada empresa, solução e negócio seja mais aderente a cultura da empresa. Abaixo uma proposta de associação entre práticas clássicas e o modelo ágil de gerenciamento:
- Levantar e mapear de forma macro todos os processos buscando definir um escopo de funcionalidades;
-Definir os processos prioritários e mapeá-los, entender como funciona o cliente e como seus usuários trabalham;
-Sugerir baseando-se nestas informações as soluções que devem ser criadas (em consenso com os usuários chave, gestores e patrocinadores);
-Formalizar a proposta de solução (que pode ser chamada de solicitação, especificação ou customização) e colher o aceite dos envolvidos;
-Detalhar esta especificação funcional juntamente com a área de desenvolvimento (analisando a viabilidade dos requisitos solicitados). Caso seja necessária alguma alteração no escopo desta especificação, levar os pontos críticos aos usuários para nova rodada de criação, negociação e consenso;
-Desenvolver os recursos solicitados, inspecionando a programação e homologando o recurso (primeiro internamente, depois com apoio dos próprios usuários.
Assim a empresa ganha em produtividade de entregáveis, já que as soluções serão realizadas por processos. O entendimento do negócio do cliente é valorizado e os usuários chaves envolvidos se comprometem para a virada do sistema. As margens de lucro ficam mais controláveis e projetos de valor fechado não viram bichos de sete cabeças.
Conclusão: soluções flexíveis e dinâmicas (pela grande capacidade de produção de customizações como é o caso do Microsoft Dynamics AX com seu desenvolvimento orientado a objetos são uma excelente saída quando o assunto é agilidade, conectividade e aderência, se os projetos de implantação forem coordenados por empresas competentes em gerenciamento de projetos.
Espero ter auxiliado com um novo olhar sobre desenvolvimento e implantação de sistemas e seus vários modelos de gerenciamento de projetos. Quem sabe os novos modelos não criem empresas únicas preocupadas com os clientes e suas necessidades.
Cel.: 55 11 9141-9545
http://kleitonkuhn.blogspot.com/
P Antes de imprimir, pense em sua responsabilidade e compromisso com o meio ambiente.
Postagens
Nenhum comentário:
Postar um comentário