Gerência de Projetos

Ξ 5 comentários

O conflito interpessoal dos membros nos projetos de TI

publicado por Flávio Horita

Durante os últimos meses, tem sido cada vez mais comum encontrarmos artigos que comentam sobre a importância dos recursos humanos para o sucesso ou fracasso no desenvolvimento de um projeto de software (Melissa AdimariRodrigo Distasio, Erik Bertelli, Melissa Adimari, Alexandre Fernando, Rafael Meneses, são apenas alguns dos exemplos). Isso por que, muitos deles comprovam através de estudos de casos e relatos de experiências, que são estes recursos que gerem e fortalecem a inovação, que produzem, tomam decisões, lideram, motivam, comunicam, supervisionam, gerenciam e dirigem os negócios das organizações.

Neste contexto, um dos problemas que tem-se tornado cada vez mais comum é conflito interpessoal consequente da necessidade em executar diversos papéis durante o desenvolvimento no projeto. Um mesmo membro atuando como desenvolvedores, testes e suporte. Minha experiência me faz crer que este é um problema mais comum em pequenas e médias empresas do que em grandes corporações. No entanto, o que vale ressaltar, é a mentalidade de gestores e diretores que acreditam que esta política pode representar uma grande economia financeira para sua organização; quando, na verdade, este fator reflete consideravelmente na diminuição da qualidade do produto causada pelas constantes alterações em seu foco de desenvolvimento e perda da credibilidade com a demora ou não realização das atividades propostas.

Aliado a isso, um termo, apresentado como uma nova metodologia de desenvolvimento chamou muito minha atenção e me fez refletir durante os últimos dias, o ironicamente nomeado Desenvolvimento Baseado no Telefone (DBT). Seu principal jargão é o conhecido “se der problema, o cliente liga”. Brincadeiras a parte, em um período dominado pelas constantes exigências por qualidade de produtos e serviços onde tecnologias e metodologias mudam quase diariamente, infelizmente, é cada vez mais comum encontrarmos empresas de software que tem “adotado” esta “metodologia” como seu principal processo de desenvolvimento.

Antes de apontarmos seus culpados, cabe fazer uma breve, mas importante, ressalva. Em muitos casos, ao tratamos de pequenas e médias corporações, é comum trabalharmos com recursos financeiros, físicos e organizacionais limitados. No entanto, vale lembrar que, controlar uma empresa requer acima de tudo habilidades gerenciais, comerciais, financeiras, interpessoais e, principalmente, estratégicas. Pois, sem elas, facilmente seus membros estarão sujeitos a realizarem escolhas conflitantes com seu foco (entenda-se objetivo da empresa), perdendo, consequentemente, o mais importante, o foco do negócio. Portanto, em um nível mais corporativo, o básico do planejamento estratégico e financeiro em uma empresa é fundamental para que ela alcance seu sucesso.

Agora, vamos aqueles que particularmete atribuo como culpados por este problema. Lembre-se estou focando no conflito interpessoal para execução de diversos papéis no desenvolvimento e não em um nível gerencial (possivelmente, tema para outro post). Credito-o a três papéis, o desenvolvedor, o cliente, mas, principalmente, ao gerente ou responsável pela área de TI da organização. Ao desenvolvedor que sempre anseia por conhecimento e desafios constantes mesmo que eles possam levar mais tempo para realizar do que o previsto. Ao cliente que, em muitos casos, solicitam customizações que contrapõe suas reais necessidades e, se não houver uma pessoa especializada neste etapa, faltamente haverão re-trabalhos. Por fim, e mais importante, ao gerente ou responsável pela área de TI, pois este papel deve saber como trabalhar sua equipe, seus pontos fortes, fracos, benefícios, dificuldades e, a partir disso, atribuir tarefas, atividades e papéis. Sempre atuando em pró da qualidade e credibilidade da equipe e, consequentemente, da empresa.

Lembrando que não acho esta prática aceitavél. Mas, sendo ela realidade em muitas empresas, torna-se imprescindível que suas tarefas (sejam de desenvolvimento, suporte ou testes) sejam controladas e atribuídas aos membros, ciente de suas dificuldades e problemas. Além disso, institucionalizar uma ferramenta para seu acompanhamento é essencial para identificar como está seu andamento.

Como sei que este é um tema muito polêmico e gera diferentes opiniões. Gostaria de saber se esta é sua realidade?! O que acha deste ponto de vista?! A quem credita este problema?! Deixe seus comentários e opiniões.

Autor

Graduado em Sistemas de Informação. Especialista em Engenharia de Software com UML e mestrando em Ciência da Computação. Atuo há 4 anos com desenvolvimento de sistemas web, sendo 3 anos utilizando Java e Flex. Nestes anos, ocupei cargos como Programador, Analista de Sistemas e Analista Desenvolvedor Java/Flex. Atualmente, faço parte da equipe de desenvolvimento da empresa LidaWeb atuando como Analista Desenvolvedor Java/Flex. E, além disso, tenho uma empresa que desenvolve e presta consultoria no desenvolvimento de softwares web e mobile, a STILL IT. Na parte acadêmica, ministro cursos e palestras focados nos seguintes assuntos: Adobe Flex, Swiz Framework, Flex Mobile, Business Intelligence (mais especificamente, Pentaho), Metodologias e Processos de Engenharia de Software, tais como SCRUM, MPS-BR e RUP. Twitter: @flaviohorita www.flaviohorita.com feahorita@gmail.com

Flávio Horita

Comentários

5 Comments

  • Assunto bem polemico! Mas não deixa de ser uma verdade.
    Quanto menor a empresa, maior a probabilidade de uma pessoa fazer tudo (famoso bombril ou mais conhecido como bater o escanteio e ele mesmo correr para ir fazer o gol).
    Quando maior a empresa, maior sera a probabilidade de ter colaboradores mais especialistas, cada um com seu escopo mais definido de atuação.

    • Fernando,

      Como não atuei em uma empresa de grande porte, passo a experiência adquirida através de conversas com amigos.

      Apesar de ser mais comum encontrarmos profissionais mas especializados; mesmo assim, a alternância de foco no desenvolvimento é muito presente, no entanto, em menor escala.

      Não quero dizer, que não tem que ter, o problema é quando isso passa a acontecer diariamente e, principalmente, por falta de gerência. Pois, facilamente, podemos perder o controle das necessidades e evoluções da ferramenta.

      Flávio

  • Flavio, participei como gerente de ti em alguns projetos grandes (2,5 milhões de orçamento inicial) de desenvolvimento de software e acredito que do tripé Cliente x Desenvolvedor x Gerente de TI (ou de projeto) considero “mais responsáveis pelo sucesso/fracasso” o Desenvolvedor e o Gestor da Equipe.

    Penso que cabe ao Gestor da Equipe controlar o Cliente e envolve-lo no Projeto de tal forma que ele compreenda os impactos de Prazo e Custo em cada solicitação feita. Este é um ponto fundamental para o sucesso. Indicativos de que o cliente não está totalmente envolvido no projeto de software são: pedidos de mudança de escopo constantes ou ausência total do cliente (não acompanha o projeto).
    É papel do Gestor de Equipe, por outro lado, controlar o desempenho e a avidez de conhecimento dos Desenvolvedores que, em todos os projetos que participei, não se preocupavam com o custo e às vezes nem com o prazo. Ficavam tão empolgados em implementar tecnologia X, Y ou Z ou ainda, aplicar abordagem/metodologia 1, 2 ou 3, que se esqueciam que o próprio salário dependia do sucesso do projeto. Sempre repetia para a equipe “a melhor implementação é aquela que aplicada corretamente sob o ponto de vista tecnológico mantém-se viável financeiramente”.
    Se de um lado temos o Gestor de TI (ou de Projetos) como grande responsável e timoneiro dos projetos de software, de outro, temos os Desenvolvedores – motores da máquina – que precisam respeitar e compreender as orientações que vem daqueles que têm uma visão mais ampla do caminho a ser seguido.
    Já fui desenvolvedor por mais de 10 anos e sei bem como me comportava (como um Deus às vezes). Hoje, do outro lado da moeda, compreendo o porque as pessoas que me lideravam pediam esforços sobrenaturais e dedicação sobre-humana: basicamente, porque eu não fazia o que era melhor financeiramente – apenas tecnicamente. Eu simplesmente não dava ouvido a eles.
    Ahh se soubesse naquela época, o que hoje!! Teria dormido mais, escrito menos código e ganhado mais dinheiro! E a Terra continua girando…

    • Ricardo,
      No fundo, quem tem a maior parcela de culpa, a meu ver, apesar de sobrecarregado, é o Gerente. Pois, é ele quem tem que controlar a equipe, dando o caminho, controlando, medindo, planejando e etc. E tem que saber como chamar o cliente para auxiliar o dev. Por que, se uma destes fatores são falhos, possivelmente, ou o projeto permanece em eterno processo de manutenção ou ele fracassa!
      O que acha?!
      Flavio

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes