Gerência de Projetos

Ξ 1 comentário

Papéis Irresponsabilidades

publicado por Mauricio Veneroso

Parece estranho. Será que está escrito errado?

Está sim. E esse erro é proposital.

Claro que o correto é “Papéis e Responsabilidades” mas nesse caso fiz questão de escrever Irresponsabilidades porque é um erro muito comum nos desenvolvimentos de projetos.

E olha que não estamos falando de erros gramaticais!

As necessidades de negócio da empresa e consequentemente as demandas de projetos para a TI, na grande maioria dos casos, impacta um grande número de áreas e não só a área do demandante.

Algumas áreas de Tecnologia da Informação pecam, por mais irônico que possa parecer, achando que quem deve definir papeis e responsabilidades para a nova realidade demandada é o próprio demandante e isso acarreta em diversos problemas não só para a TI mas também para todas as áreas envolvidas e impactadas.

Mas quase sempre a TI é responsabilizada simplesmente porque é ela que implementa as mudanças.

A falta da definição clara de papéis e responsabilidades cria um problema para a própria TI e esse é um dos grandes desafios denominados “culturais” quando se implementa alguma modificação tecnológica ou sistêmica numa empresa.

Isso se deve ao fato de que muitas áreas podem simplesmente recusar-se a aceitar a mudança por justamente não serem a demandante e consequentemente não terem previsto a operacionalização dessa nova realidade e nem mesmo orçamento suficiente para mantê-la. Além disso, a demanda em sí cria um grande problema para tais áreas se justificarem, daquele momento em diante, quando se fala da manutenção das atividades operacionais que antes do projeto não existiam e o respectivo orçamento relativo à tais atividades operacionais.

Ao discutir e estruturar os papeis e responsabilidades em função de uma demanda sistêmica, cria-se a chance do escopo da demanda ser moldado para atender todas as áreas impactadas e até mesmo auxiliar em fomentar um orçamento compartilhado para aquela nova realidade que está sendo demandada.

Certamente que se você tentar atender à todas as áreas pode acabar não atendendo à ninguém e nesse momento é que a TI acaba cedendo às pressões dos que querem em detrimento daqueles que não querem e acaba desenvolvendo uma solução que não consegue agradar gregos e troianos.

Consequentemente, como citado acima, se os gregos ficarem contentes, os troianos ficarão tristes e vice-versa e adivinhe quem vai ter que fazer a atividade operacional dos que ficaram tristes?

Na maioria dos casos a própria TI.

E a briga não pára por ai! A área de TI que já é considerada “cara” para a empresa, continua crescendo e ficando mais cara.

Ao definir-se claramente papeis e responsabilidades bem no inicio de uma demanda evita-se esse tipo de surpresa.

Obviamente, essa postura não quer dizer que a TI ou o demandante vão conseguir convencer as demais áreas que elas terão custos adicionais ou que elas deverão defender um orçamento para algo que elas nem sequer precisavam ou demandaram, mas pelo menos, vai permitir mapear de maneira completa, o esforço para “fazer a roda girar” para essa nova realidade. Também permitirá incluir esse esforço no business plan da demanda deixando claro o custo real para a empresa evoluir seus processos e sistemas que os sustentam.

O que todos concordarão é que não é saudável continuar achando que de um lado da balança, o custo de uma demanda sistêmica restringe-se às despesas para desenvolvê-la e do outro restringe-se aos benefícios e ganhos que o demandante planeja realizar com tal modificação, deixando de lado os custos para operacionalizá-la.

Seria o mesmo que consumir mais calorias do que o corpo precisa e continuar se pesando numa balança quebrada.

E isso é uma irresponsabilidade, não acha?

Autor

Mauricio Veneroso tem mais de 20 anos de experiência na área de TI sendo mais da metade no mercado de telecomunicações. Trabalhou em diversos projetos de desenvolvimento de sistemas. Nos últimos 5 anos sua atuação tem sido voltada para ITSM atuando como Consultor de TI, estruturando equipes de suporte, níveis de serviço e definindo processos de melhoria contínua redefinindo inclusive metodologias de desenvolvimento de sistemas, participando da elaboração de SoWs, RFPs e RFIs para assegurar transições para os times de produção, suporte e sustentação de sistemas com o menor impacto possível para as áreas usuárias e para os times de suporte.

Mauricio Veneroso

Comentários

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