A Culpa é da TI?

por Cláudio Barizon
13 comentários 4 minutos leia
A Culpa é da TI?

A Culpa é da TI?Entregas não realizadas, prazos não cumpridos, usuários insatisfeitos, oportunidades de mercado perdidas, executivos pressionando, cobrança, equipe desmotivada. Normalmente, sempre por “culpa da TI”. Este cenário é muito comum e a “necessidade” de se encontrar um culpado faz a corda arrebentar para o lado mais fraco. Este lado quase sempre é a equipe de Tecnologia, que muitas vezes, não é vista ou tida como estratégica e funciona como uma anotadora de pedidos, que precisa fazer as entregas a qualquer custo.

Nem sempre prazos apertados ou impossíveis, falta de definição dos requisitos, mudanças de escopo constantes e falta de comprometimento de outras áreas envolvidas são levados em consideração para se avaliar o melhor direcionamento para o projeto. Nada! O importante é encontrar logo o culpado e “passar o mico”. A bomba vai estourar na ponta e a ponta é exatamente quem vai fazer a entrega final, a TI. Estas equipes, muitas vezes, atuam com seus “heróis”, tentando recuperar o tempo perdido. Fazem de tudo, viram a noite, perdem os finais de semana e feriados. Mas, no final, não entregam, perdem o prazo ou geram produtos sem qualidade. O maior problema, porém, é a insistência em repetir esta sistemática. E isso se repete e se repete e se repete… Não vai dar certo! Vai dar problema de novo e mais cobranças e desconfianças sobre a área de Tecnologia.

É isso que temos visto nas empresas por onde passamos. É um padrão. Obviamente, os CIOs se preocupam com esta situação, pois é sempre a sua área que está em xeque. Mas, como dizia o poeta: “os heróis morreram de overdose”. A solução não está por aí. Por mais preparados que sejam os profissionais de tecnologia, é melhor deixar as missões impossíveis para os Vingadores nas salas de cinema.

Para obtermos resultados diferentes, precisamos fazer diferente! É importante olhar todo o processo e comprometer todos os envolvidos (e não apenas a TI), fazendo com que as áreas trabalhem e funcionem de forma colaborativa. Não é fácil na cultura de empresas que ainda insistem em encontrar culpados e, por isso, o trabalho precisa ser mais profundo. Ele passa por uma transformação e mexe na cultura, nas pessoas, e nos processos, para que todos entendam seu papel e se comprometam com a entrega final como uma equipe, independentemente da área em que atuam.

Parece simples, mas sabemos que não é tão fácil assim. Existem muitas questões envolvidas no ambiente corporativo: política, vaidade, metas dos executivos (normalmente, não convergentes), orçamento e etc., que acabam inibindo o comportamento desejado de colaboração e comprometimento com o mesmo fim. Muitas vezes, as equipes recebem a solução pronta a ser implementada. E este é o pior dos mundos. É muito importante que o time conheça a direção, a estratégia e tenha um propósito. Reunindo as competências corretas e, com o direcionamento adequado, a equipe vai encontrar as melhoras soluções. Ao fazer isso, conquista-se um dos maiores ingredientes do sucesso: engajamento.

O caminho para esta mudança passa por quebras de paradigmas e uso de práticas menos intuitivas, que compõem o arsenal existente de práticas ágeis. Desde que passamos a usá-las ou introduzi-las nas empresas, a realidade mudou para estas equipes. Mas, ainda assim, existe certa desconfiança sobre a utilização destas práticas: parecem frágeis, feitas “nas coxas” e soam como brincadeira – é “aquela turma dos post-its”. Afinal, as metodologias tradicionais de gestão de projetos ou de desenvolvimento de software estão aí há décadas, geram uma incrível quantidade de documentação e não deve haver nada mais robusto que isso, não é mesmo? Bem, não é bem assim. Apesar de simples (muitos simples!), as práticas ágeis requerem muita disciplina e processos estruturados para garantir as entregas periódicas. Requerem ainda transparência e muita interação com o cliente, que acaba se envolvendo de tal forma com o método de trabalho e com o produto a ser entregue, que passa a ser o primeiro a defender a equipe de Tecnologia. Ele não é mais aquele “inimigo”, que fica mudando o escopo a cada instante e culpa o desenvolvimento pelo não cumprimento de prazo. A entrega é tão dele quanto de qualquer outro no time e a colaboração flui. Além disso, as mudanças, antes tão indesejadas pela TI e sempre motivo de conflitos, passam a fazer parte do processo de trabalho, direcionando as entregas para o maior valor agregado ao produto final.

Estas mudanças culturais, processuais e de foco não estão limitadas ao ambiente de Tecnologia, ali na ponta, onde o produto ou sistema será desenvolvido. Ao contrário, precisa ocorrer em todo o “value stream”, desde seu início nas definições estratégicas e a escolha correta do portfólio (“o que fazer”). O foco é no valor a ser gerado pelo que se está entregando. Então, entender como captar este valor e medi-lo passa a ser de grande relevância e chave em todo o processo. A entrega (o desenvolvimento) também precisa ser bem feita, é claro!, e é importante ter este fluxo estruturado (o “como fazer”). Mas, a esta altura, o trabalho colaborativo já está estabelecido: uma transformação em todos os níveis, através da criação de uma cultura de participação, autonomia, engajamento, responsabilidade, transparência com muito trabalho em equipe para entrega de valor para o negócio. Simples assim.

[Crédito da Imagem: TI – ShutterStock]

Você tabém pode gostar

13 comentários

Aline Fabricia 26 de fevereiro de 2015 - 12:28

O artigo estava indo bem, mas quando começou o levantar da bandeira pelas metodologias ágeis em detrimento a metodologia tradicional, percebi que o foco não era mais TI e sim uma divisão de grupos por metodologia utilizada. Bem encontrado em desenvolvedores que acabaram de sair de um estágio e não acreditam no benefício de uma documentação. Cada uma tem seus prós e contras, e não saber disso é uma ingenuidade sem tamanho.

Pior artigo que li no TI Especialistas até hoje.

Cláudio Barizon 27 de fevereiro de 2015 - 9:59

Oi, Aline. Obrigado pelo feedback. Lamento você não ter gostado do texto. Sem problemas! O objetivo do artigo foi escrever um pouco sobre a minha experiência. Tive resultados excelentes ao mudar a abordagem. Vi também várias empresas nesta situação e as mudanças implantadas fizeram toda a diferença. Acredito tanto nisso, que deixei o mercado corporativo para auxiliar as empresas a descobrirem novos caminhos, levando, por exemplo, as práticas pragmáticas utilizadas por startups para as corporações, que podem reduzir muito seus custo e o time to market para extrair valor de seus produtos e serviços.

Na verdade, mais do que os métodos ágeis, estamos falando de conceitos, que requerem uma mudança cultural muito grande. E está aí o grande benefício: esta transformação (porque é uma transformação!) precisa acontecer a partir das áreas de negócio. E ela acontece, tornando o trabalho muito mais colaborativo. Existe a empatia entre as áreas, que começam a entender os problemas umas das outras e a trabalhar para o bem comum em prol dos resultados. Não se trata de comparação entre as metodologias e nem se está discutindo a importância da documentação. Ao contrário até… A documentação é muito importante e é possível “embuti-la” no processo, tornando-o ainda mais robusto e com maior valor. Se você quiser, podemos trocar ideias a respeito. Posso te apresentar cases muito interessantes, mesmo em grandes corporações. Fique com o meu email: claudio.barizon@teamware.com.br

Alexandre Epelbaum 27 de fevereiro de 2015 - 11:55

Interessante e oportuno o artigo.

Cláudio Barizon 2 de março de 2015 - 16:53

Obrigado, Alexandre. As TIs estão mudando e é importante encontrar e conhecer novos caminhos.

Fernando Palhares 2 de março de 2015 - 19:05

Olá Cláudio! Parabéns pelo artigo.

É interessante observar que não é fácil agradar a todos quando o assunto é tão oportuno em sua variação. Gostaria de concordar com a Aline, mas também entender quais experiencias negativas permitiram a conclusão apresentada para realmente conseguir comparar o proposto versus realizado. A variação de posicionamento talvez esteja no complexo entendimento da palavra “adaptação” para contemplar as varias metodologias ou regras de negócio.

O texto é bem objetivo Claudio, mas também é bem genérico no que pretende apresentar aos leitores. Se o seu objetivo era transmitir suas experiencias, faltou embasar com fatos para comprovar os sucessos alcançados.

Novamente parabéns pelo texto e ficam as minhas considerações.

Abs.

Cláudio Barizon 3 de março de 2015 - 18:31

Caro Fernando, obrigado pelo feedback. Sem dúvida, o texto é um pouco genérico, pois o seu objetivo foi instigar… Postamos outros artigos que complementam este primeiro, entrando mais em detalhes: https://www.tiespecialistas.com.br/2015/02/praticas-ageis-para-cada-tipo-de-paciente-uma-dose-do-remedio/, que aborda uma situação em uma empresa de mídia; ou este outro que conta um pouco da utilização destas práticas “lean” mesmo para gerenciar demandas para um sistema como o SAP (https://www.tiespecialistas.com.br/2015/02/sap-e-kanban-um-case-pioneiro-no-brasil/; ou este mais voltado para as equipes de desenvolvimento e qualidade (https://www.tiespecialistas.com.br/2015/02/como-controlar-a-qualidade-no-mundo-agil/). Tivemos ótimos resultado, principalmente na entrega de valor ao negócio. No entanto, o grande ganho para a empresa foi a mudança cultural que foi possível implantar nas áreas e na relação com a TI: uma grande transformação, mudando a atitude e o entendimento do trabalho colaborativo para o atingimento de mais valor. Se você quiser conhecer mais detalhes, podemos trocar ideias. Fique com o meu email: claudio.barizon@teamware.com.br.

Luiz 6 de março de 2015 - 12:01

Com certeza é isso mesmo o que ocorre, criam prazos irreais e depois estoura no colo da equipe de desenvolvimento, quem tem experiencia na área sabe bem disso, mas pra mim é mais a culpa da equipe de requisitos que com a gana de agradar o cliente esquece que não é eles que vão botar a mão na massa, eu mesmo tive inumeros problemas com isso até que passei a rejeitar esses prazos e passar por cima das equipes de requisito, pra evitar esses contratempo, no final é a equipe de desenvolvimento que fica mal vista e isso pode chegar até dar demissões.

Cláudio Barizon 9 de março de 2015 - 16:06

Caro, Luiz. Obrigado pelo seu comentário. E ele é muito oportuno. Sem dúvida, muitas vezes os problemas acontecem como você citou. E é exatamente neste ponto em especial que uma abordagem diferente pode contribuir bastante. Existem práticas e técnicas que mexem o modelo de atuação em todo o “value stream”, transformando o trabalho, nomalmente sequenciado, em um trabalho colaborativo com foco no valor. Se você quiser conhecer e discutir mais sobre estas abordagem pragmática, mande-me uma mensagem> claudio.barizon@teamware.com.br.

Cláudio Barizon 9 de março de 2015 - 16:06

Caro, Luiz. Obrigado pelo seu comentário. E ele é muito oportuno. Sem dúvida, muitas vezes os problemas acontecem como você citou. E é exatamente neste ponto em especial que uma abordagem diferente pode contribuir bastante. Existem práticas e técnicas que mexem o modelo de atuação em todo o “value stream”, transformando o trabalho, nomalmente sequenciado, em um trabalho colaborativo com foco no valor. Se você quiser conhecer e discutir mais sobre estas abordagem pragmática, mande-me uma mensagem: claudio.barizon@teamware.com.br.

Robson Marinho 19 de março de 2015 - 13:46

Interessante as ponderações, seu artigo me passa um campo de ideias, ou seja, não se atém para com cenários específicos, porém, aborda algo que é primordial para os casos de sucesso: O ato de delegar também as decisões quanto as definições continuamente de maneira de colaborativa, o que é bem diferente de apenas trabalhar de maneira colaborativa e nada mais. O que tento citar é que realmente não adianta uma elaboração de requisitos ter sido coletada para com um auditório (Áreas de principais interesses) e depois disto, tornasse algo como: Faça sua parte que o outro faz a dele, “apenas”.

Na verdade o segredo de qualquer engajamento se dá quando todas as etapas são participativas integralmente e continuamente afinal, o que retrata a melhor elaboração é o aprimoramento continuo e consensual tido por todos os colaboradores em cada linha de progresso, de cada etapa.

Compartilho do raciocínio semelhante ao seu, parabéns pelo artigo.

Abs

Cláudio Barizon 19 de março de 2015 - 19:47

Perfeito, Robson! É isso aí!

Deixe um comentário