Transformar uma empresa em uma organização de projetos e uma organização de suporte não é

incomum. Existem várias razões para que isso aconteça, mas essa mudança definitivamente não é
a solução para orçamentos restritos.

Considerações básicas

- Modificar a estrutura da sua empresa deve ser a última opção a se levar em conta.

- Habilidades e disposição são mais importantes do que uma estrutura teoricamente perfeita.

Recomendações

- Não faça mudanças organizacionais para resolver falhas de processo. Foque no procedimento
antes de tudo.

- Alterne tarefas, por exemplo, para estimular a disposição dos funcionários caso opte por um
modelo de segmentação.

- Verifique se os contratos entre provedor e clientes (em inglês service-level agreements –

SLAs) continuam válidos antes de dar início à mudança organizacional.

O que você precisa saber

Os clientes normalmente perguntam se deveriam dividir sua equipe em projetos (a que

normalmente se referem como desenvolvimento, mas na verdade são estratégias de
aperfeiçoamento e para obter novos contatos) e suporte.

Empresas que já seguem esse modelo de estrutura questionam se esta é a melhor escolha ou se
deveriam retornar a um estilo de organização mais diversificado. Essa é uma decisão do tipo “
será que a grama do vizinho é mais verde?”. A maioria das companhias que consideram a
possibilidade de organizar sua estrutura dessa maneira estão na verdade tentando solucionar
um de diversos problemas de processo.

- Os projetos estão atrasados (embora nunca estourem o orçamento) porque os recursos

destinados a eles acabam sendo gastos com suporte.

- Funções de suporte exigem habilidade para lidar com múltiplas tarefas ao mesmo tempo.

- Recursos de suporte costumam ser fragmentados.

- Habilidades de suporte ou estão indisponíveis ou deixarão de existir em breve devido à

transferencias ou a aposentarias.

- Relações disfuncionais entre grupos levam a conflitos morais e de gerenciamento.

Apenas modificar a estrutura da empresa não vai resolver nenhum desses problemas. Ao
contrário, se esta for a única mudança da situação, eles ficarão mais graves em seis a 18
meses, simplesmente porque além de apresentar processos falhos a empresa terá de lidar com a
ruptura de um padrão. Há bons motivos para alterar o modelo estrutural de uma companhia (esta
não é uma pesquisa sobre quando mudar, mas sim sobre como mudar), porém essa decisão deve ser
tomada cautelosamente, se levando em conta o potencial de solucionar problemas com novos
processos.

ANÁLISE

A primeira regra para mudar o design de uma organização: não faça isso!

Nem sempre isso é verdade, obviamente. Entretanto, mexer constantemente nas relações
hierárquicas essenciais ao bom funcionamento da companhia é um dos erros corporativos mais
comuns. Essa é uma saída relativamente fácil porque os gerentes influenciam diretamente essas
estruturas. Além disso, é um tipo de mudança que rapidamente se pode notar. Mas há dois
inconvenientes:

- Mudar a estrutura de uma empresa implicará de seis a 18 meses de adaptação. Alguns

funcionários se sentirão bem com seus novos chefes, outros nem tanto. Quando essas
hierarquias são modificadas, há sempre um período posterior de familiarização. Haverá ainda
uma fase na qual as tarefas deverão se encaixar ao novo modelo estrutural.

- Os processos falhos permanecem ineficazes. Esse é o ponto crucial. Muitas companhias tentam
alterar sua estrutura porque precisam resolver problemas de processo, mas isso não funciona.
Primeiro solucione a falha no procedimento, depois avalie se vale a pena implementar uma
mudança estrutural.
Grande parte da atividade em que se fundamenta uma organização se origina de relacões
informais e processos implícitos. As estruturas atribuem status ou poder a determinados
cargos. Muitas empresas não estão cientes desse elemento subliminar e normalmente os
prejudicam ou destroem durante restruturações. Justamente as estruturas e processos que
precisam ser eliminados costumam sobreviver às mudanças. Várias empresas almejam solucionar
problemas de planejamento e de recursos humanos segmentando suas estruturas. Vamos supor que
essa separação é válida. Como ela deve acontecer?

Fundamentos de uma separação de projetos e suporte

Se você pretende segmentar sua empresa, precisa seguir os seguintes passos:

- Definir claramente o que é um “projeto” e quais atividades estão relacionadas com o “

suporte”. Isso pode parecer simples, mas as empresas costumam chamar de projeto conjuntos
amorfos de tarefas ou qualquer atividade que precise ser coordenada. Suponhamos que um
projeto é uma tarefa que exige no mínimo 320 horas. Há uma explicação para isso. Baseando-se
nas oito horas do plano de tarefas do Instituto de Gerenciamento de Projetos, chegamos a
conclusão de que um projeto inclui cinco fases (demanda, avaliação/planejamento, organização,
testes e implementação), e cada fase implica três atividades. Cada atividade envolve três
tarefas (cinco fases: três atividades por fase e três tarefas por atividade), o que nos leva
a um total de 320 horas. Todo o restante é suporte. Normalmente, há três tipos de suporte:
reparação de falhas, pequenas mudanças ou aperfeiçoamento e questões relacionadas com as
SLAs. Temas regulatórios entram em ambas as categorías. Caso a demanda por pequenas mudanças
seja constante, deve ser incluída em suporte; senão devem ser classificadas como projetos e
receber prioridade máxima.

- Para cada demanda, crie uma SLA. Recapitulando: suporte é solução de problemas,
aperfeiçoamentos simples e outras atividades relacionadas com SLAs (responder a dúvidas de
clientes, analisar possibilidades e assim por diante). Essas demandas precisam ser claramente
definidas e traduzidas para uma SLA que eficazmente permita que a empresa ofereça o nível de
serviço a que se propõe.

- Com base nas SLAs e na demanda, classifique a organização. Infelizmente a maioria das
empresas que querem segmentar sua força de trabalho começam por essa etapa. Saber quantas
pessoas devem ficar no setor de suporte é impossível antes de: 1 perceber a gravidade e a
frequência das falhas dos projetos 2 quantas pessoas a empresa pretende pagar para
implementar melhorias 3 quais outros serviços devem ser oferecidos, quando e como. Pode ser
que tudo isso pareça simples. Mas agora devemos prestar atenção no principal desafio da
mudança: as pessoas envolvidas nesse processo. Reparação de erros é uma atividade que exige
profissionais que se sentem confortáveis trabalhando sob pressão e que são pragmáticos. Essas
habilidades podem não ser raras, mas é comum haver pessoas dispostas a trabalhar no setor de
suporte que não possuem essas habilidades básicas. O principal problema, entretanto, é que a
maioria dos profissionais de TI não quer realizar apenas tarefas de suporte. Eles interpretam
essa atividade como algo sem futuro e limitado. Além disso, os profissionais de
desenvolvimento tendem a se considerar superiores aos do setor de suporte. Quando uma empresa
segmenta sua estrutura, precisa pensar em como fazer com que seus funcionários se sintam
confortáveis com tarefas de suporte e inclusive queiram realizá-las. Existem alguns truques
para isso:

- Pague bônus à equipe de suporte. Muitas empresas rejeitam essa ideia, principalmente porque
subvalorizam o trabalho que esses profissinais desempenham.

- Crie o hábito de delegar tarefas diferentes ou mais complexas a membros da equipe de

suporte por um período, seguindo um rodízio. Tipicamente, esses períodos duram de 12 a 18
meses. Não deixe que sejas mais longos. Quando isso acontece, se perde toda a credibilidade
do processo de rodízio. Com o tempo, esses períodos podem se tornar mais curtos.

- Convença profissionais a desempenharem funções de suporte dizendo a eles que após

concluírem o rodízio poderão se aperfeiçoar em tarefas que lhe interessam.

Faça a mudança acontecer

Uma empresa não precisa ser completamente segmentada. Há ocasiões em que apenas alguns
setores precisam adotar esse modelo estrutural:

- Quando um único projeto grande tem uma trajetória de implementação dividida em fases e a
empresa quer estabelecer sua estrutura logo no início para conseguir alcançar seus objetivos
a longo prazo. Nesse caso, se a estrutura de longo prazo for segmentada, é melhor começar o
processo criando um grupo de suporte separado logo após a instalação. Esse grupo deve ser
formado por membros da equipe de desenvolvimento que realizam diferentes tarefas seguindo um
esquema de rodízio.

- Desenvolvimentos rápidos ou repetitivos podem resultar em diferentes mesclas de recursos.

Projetos rápidos normalmente exigem tarefas de tempo integral e monopolizam os recursos; não
é aconselhável que esses mesmos recursos atendam às atividades de produção. Portanto, a
equipe de desenvolvimento poderia lidar com falhas e aperfeiçoamentos simples enquanto um
outro grupo seria responsável por necessidades de suporte críticas.

- Em algumas empresas, há certas atividades nas quais a demanda de recursos para suporte é
mínima. Ou seja, normalmente uma única pessoa é responsável por essa tarefa. Treinar outros
profissionais parece desnecessário e às vezes acabam utilizando recursos externos.

- Em muitas companhias, a necessidade de dar suporte a aplicações ERP exige segmentação,

porém o modelo segmentado se baseia em escalas, independentemente de elas serem suficientes
ou não.

Em seguida, é preciso organizar o tempo disponível. Mudanças impactantes têm consequências

impactantes. Tente implementá-la por partes. Também é necessário tomar uma decisão de
recursos muitas vezes difícil: em alguns casos, as empresas optam por terceirizar
completamente o setor de suporte, e fazem isso por motivos realmente válidos. Embora essa
decisão esteja fora da abrangência desta discussão, externalizar os processos é algo a ser
analisado, planejado e executado cuidadosamente.

Conclusão

Separar uma empresa em uma de projetos e outra de suporte não otimiza recursos e atividades.
Se essa mudança é implementada sem que se leve em consideração as questões aqui expostas, as
falhas de recursos permanecerão e serão agravadas pela ruptura do fluxo de trabalho e de
relações hierárquicas. Frequentemente, os problemas de planejamento de recursos podem ser
resolvidos sem uma mudança estrutural. No caso de a separação ser a melhor alternativa, o
planejamento e a execução detalhados serão a diferença entre obter um bom resultado ou apenas
criar um novo conjunto de padrões ineficazes.