Como cumprir prazos de entrega – Parte 1

Um dos maiores desafios que temos hoje em dia é conseguir cumprir datas acordadas para entregas de projetos. Na verdade este é um desafio que cruzou as últimas décadas e que continua nos assombrando nos dias de hoje.

Acredito que nunca iremos eliminar de vez este problema, mas o mais assustador é que os atrasos muitas vezes não são de alguns dias, mas sim de semanas ou até meses.

Preparei este estudo para nos ajudar a mitigar este problema e irei apresenta-lo aqui no blog em 4 posts. O objetivo principal é repensarmos a forma como estruturamos nossos times e como as demandas são distribuídas entre eles.

Como base para este estudo irei abordar os seguintes conceitos:

  • Sistemas Distribuídos
  • Gestão do Conhecimento
  • Kanban

Tenha em mente que toda mudança leva um tempo para ser absorvida pelo time e, as vezes, os benefícios serão colhidos ao longo do tempo. É importante que o gestor tenha esta visão para não trabalhar apenas com o imediatismo. Normalmente resultados rápidos são adquiridos com ações de contorno.

Lembre-se que um dos motivos deste estudo estar bem detalhado é lhe oferecer a possibilidade de poder ajustá-lo para atender um problema específico da sua empresa.

Não se prenda em seguir exatamente o passo a passo que está escrito aqui. Cada empresa tem sua identidade e provavelmente adaptações terão que serem feitas.

Faça bom proveito desta leitura.

  1. Sistemas distribuídos

O objetivo deste tópico não é entrar no detalhe do conceito de Sistemas Distribuídos. Iremos abordar alguns pontos fundamentais para o desenvolvimento deste trabalho e explicar as correlações que fizemos para aplicá-lo na solução proposta.

Caso você queira se aprofundar no assunto lhe indico os seguintes livros que utilizei de apoio:

  • Distributed Systems: Concepts and Design (COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T.; BLAIR, G.)
  • Computer Networks (TANENBAUM, A.S.) – este está disponível em PDF através do link http://www-usr.inf.ufsm.br/~rose/Tanenbaum.pdf
  • Entendendo os Tipos de Estruturas

Vou iniciar com uma pequena introdução teórica, mas prometo que a partir do próximo tópico já vamos pôr a ‘mão na massa’.

O conceito de sistemas distribuídos surgiu durante a Guerra Fria, quando o Departamento de Defesa dos EUA estava em busca de uma estrutura de comunicação capaz de sobreviver a uma guerra nuclear. Paul Baran apresentou um trabalho onde classificou 3 tipos de sistemas de comunicação, sendo eles: sistemas centralizados, sistemas descentralizados e sistemas distribuídos.

 

Tipos de Sistemas

 

Note que os pontos estão distribuídos da mesma forma nos três sistemas, a diferença está como determinamos a comunicação entre eles.

Se traçarmos o paralelo destes 3 modelos em nossas estruturas organizacionais teremos os seguintes resultados:

  • Gestão Centralizada (Sistema Centralizado): corresponde ao modelo antigo de gestão, onde as decisões eram centralizadas em poucas pessoas e cabia as demais seguir as regras definidas por este grupo. Caso o gestor (ponto central) se ausente a companhia fica desorientada. Existe uma forte tendência deste modelo ser extinto, mas ainda pode ser encontrado nos dias de hoje (principalmente em empresas familiares ou de pequeno porte).
  • Gestão Descentralizada (Sistemas Descentralizados): é o mais utilizado nos dias de hoje. A gestão é descentralizada, mas tende a afunilar para um ponto único. Geralmente está representada por gerentes, diretores, vice-presidentes, presidentes e assim por diante. As pontas correspondem aos funcionários das áreas. Para que os funcionários de um determinado setor se comuniquem com os demais setores é necessário seguir uma hierarquia e a negociação entre áreas depende diretamente da negociação de seus gestores. Na ausência de determinados gestores poderemos ter funcionários ou células isoladas, sem comunicação com o restante da estrutura.
  • Gestão Distribuída (Sistemas Distribuídos): mais utilizada por startups ou grandes empresas que trabalham com a cultura de inovação, a Gestão Distribuída garante que todos os pontos se comuniquem. Existem estudos que apontam ganhos de produtividade ao utilizar esta estrutura, pois estimula a todos trabalharem com um objetivo comum, e não mais ilhados em departamentos. A ausência de qualquer pessoa na Gestão Distribuída tende a gerar menos impacto, pois não existem pontos isolados nesta estrutura.

Ok, acho que todos concordamos que a Gestão Centralizada, ou sistema centralizado, não é legal e ninguém está disposto, ou não deveria estar, em apostar nesta estrutura. Também temos uma forte tendência em simpatizar com a Gestão Distribuída, ou sistema distribuído, mas vamos ser sinceros; qual a chance de você conseguir mudar toda a cultura da sua empresa para conseguir implantar este tipo de gestão do dia pra noite?

A Gestão Distribuída é muito bacana na teoria, mas exige uma complexidade enorme para ser implantada. Inclusive foi apontado pelo artigo recente do Harvard Business Review (GULATI. R; DESANTOLA, A; Start-Ups That Last – R1603C) como uma das principais dificuldades na adaptação da cultura de Startups que captam grandes valores e necessitam multiplicar seu tamanho. Neste artigo os autores defendem a necessidade de possuir gestores com conhecimentos específicos em cada área e, de certa forma, caminhar para uma gestão descentralizada. Quanto maior a estrutura, maior a dificuldade em manter uma Gestão Distribuída.

Mas o que aconteceria se você transportasse estes conceitos focando apenas no seu time? Qual seria o resultado?

1.2 – Identificando o Problema

Vamos tomar como exemplo um time responsável por projetos corporativos em sua empresa.

Inicialmente, olhando para dentro deste time, teremos a percepção dele estar estruturados no modelo de gestão distribuída (figura 2). Novos projetos direcionados ao time podem ser consumidos por qualquer analista, todos os analistas possuem comunicação livre entre eles, conhecem os processos que cercam suas atividades e participam das decisões que influenciam seu dia a dia.

Time atuando no modelo de Gestão Distribuída

 

Agora analisem o que acontece se um dos analistas desliga-se da empresa. Provavelmente teremos um grande impacto para absorver o projeto que estava sob sua responsabilidade (figura 3). Por mais que se tenha documentação, apenas este analista tinha conhecimento do seu histórico e acabamos comprometendo datas importantes já alinhadas com os stakeholders do projeto.

O histórico do projeto se perde com o desligamento de 1 analista

 

Notem que no exemplo da figura 3 o ‘Projeto D’ ficou descolado da estrutura após o analista desligar-se. Avaliando sob este ponto de vista percebemos que na verdade este tipo de estrutura estava trabalhando o modelo de Gestão Descentralizada.

Apesar dos projetos poderem ser consumidos por qualquer analista do time, eles são posicionados nas extremidades após serem iniciados. Típico de sistemas descentralizados (figura 4).

Cada analista está dedicado a 1 projeto

 

Como o fluxo de Implantação é bastante complexo, não há como evitar o impacto na transição entre analistas. Mesmo quando são apenas em determinados períodos, como férias ou ausências inesperadas.

Neste momento identificamos o nosso problema. No próximo post irei lhes apresentar como eliminar este risco e mitigar impactos de estouro de datas acordadas em cronogramas de projetos.

 

Artigo elaborado por Rodrigo Muniz, profissional com mais de 20 anos de experiência na área de TI.

Gostou da solução? Nós podemos ajudar!

Conheça nossos conteúdos gratuitos, direcionados aos assuntos de sua preferência!

Enviar

Receba nosso conteúdo

Gostaria de receber de forma gratuita mais conteúdos sobre este ou outros assuntos? Preencha o formulário abaixo e receba nosso conteúdo gratuito!

Parabéns!

Você receberá nosso conteúdo em breve!

Atenção

Tivemos um problema com seu formulário, tente novamente.