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]
Cláudio Barizon é formado pela PUC-RJ com MBA pelo IBMEC e MBI em Gestão Estratégica de TI pelo NCE/UFRJ. Carreira de 25 anos na área de Tecnologia, sendo 15 em Gestão, desenvolvida em empresas de grande e médio porte: Infoglobo, Origin Brasil, Casas Sendas, Mills Equipamentos, entre outras. Experiência na gestão e implementação de portfólio de projetos corporativos, com metodologias PMI e ágeis (Scrum/Kanban); e desenvolvimento de produtos digitais (web sites, sites móveis, aplicativos para smartphones e tablets) com Lean Startup e Business Model Generation (Canvas), UCD (User Centered Design) e foco em sua usabilidade (UX).
You must be logged in to post a comment.
12:28:04 pm
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.
9:59:54 am
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
11:55:16 am
Interessante e oportuno o artigo.
4:53:25 pm
Obrigado, Alexandre. As TIs estão mudando e é importante encontrar e conhecer novos caminhos.
7:05:42 pm
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.
6:31:19 pm
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: http://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 (http://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 (http://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.
12:01:21 pm
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.
4:06:09 pm
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.
4:06:45 pm
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.
1:46:38 pm
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
7:47:45 pm
Perfeito, Robson! É isso aí!