A responsabilidade em fazer que dê certo é sempre da TI

Está na hora de discutir o papel na relação entre equipes de TI, seus clientes e usuários. Setenta anos se passaram desde o ENIAC. No início o uso era técnico, matemático, mantendo a galera da computação distante do cliente e usuários, estabelecendo a partir deste distanciamento, contratos cada vez mais detalhados e uma gestão cada vez mais polarizada, baseada em bônus e penalidades.

Por um lado a TI exigindo objetividade e certezas por parte do usuário quanto a sua necessidade em detalhes, por outro os usuários exigindo objetividade e certezas técnicas por parte da TI quanto a estimativas e planos. Uma disputa que gerou décadas de falsas expectativas em projetos, pressupondo de início que não haveriam alterações, mas se houvessem, a solução era apontar um culpado a partir de cláusulas contratuais, explícitas ou tácitas.

Esta questão dialética gerou algumas representações gráficas hilárias com o passar do tempo, representando de forma divertida este problema, como por exemplo:

A imagem abaixo eu vi pela primeira vez em um curso da IBM de CICS/VSAM em 1986, mas acho que foi criado pelo menos 10 anos antes … mesmo assim, para a maioria das empresas ainda não mudou uma virgula, posto que não conseguem entender os porquês disto, tentam encontrar uma solução baseada em termos contratuais, que os proteja, que ao mesmo tempo puna os outros como culpados.

Após 70 anos, está claro que é responsabilidade da TI propôr melhorias no processo, mudanças, esse é um protagonismo para o qual eles estudaram por pelo menos quatro anos, se graduaram, fizeram especializações e MBA’s. O passo inicial nesta mudança é entender que cada projeto de desenvolvimento de software é de “propriedade” tanto do cliente quanto da TI, cabendo à TI encontrar os meios corretos, desde tecnologia, passando por método, técnicas e boas práticas.

Um papel que é melhor exercido se utilizarmos o somatórios dos conhecimentos, know how e expertises de todos os envolvidos em cada projeto, partindo-se da premissa que é possível e necessário estabelecer uma relação de confiança.

Reflexão #1. Quem tem interesse que dê certo?

O interesse é de todos, o cliente quer um custo e tempo justo para receber algo que realmente atenda sua necessidade, a equipe de TI precisa executar o projeto de forma que os resultados valorizem seu trabalho, os stakeholders querem pessoas engajadas de parte-a-parte em gerar valor de forma sustentável. No fundo, todos querem um bom resultado, de forma a gerar satisfação e o desejo de novos projetos, todos querem ter orgulho do que e com quem trabalham.

O problema é o medo de algo dar errado e cair no seu colo, mas o medo não é da empresa, empresas não sentem medo … o medo é das pessoas. Pessoas que querem aumentos, méritos, promoções, querem crescer e por isso (cientes do mindset vigente a mais de cem anos) criam defesas que acabam atrapalhando o interesse das empresas … que é ter uma solução adequada para seu desafio ou problema.

Reflexão #2. Quem é o especialista e precisa conhecer as opções?

Me desculpem pela sinceridade crua, mas é da TI a responsabilidade em utilizar as técnicas certas para cada projeto, isso envolve crenças e domínio. Os especialistas somos nós se o cliente não consegue deixar claro o que precisa com meses de antecedência, usar cláusulas contratuais para punir este fato é oportunismo. Quem precisa usar diferentes técnicas e artefatos, apoiando-se em ciclos curtos de feedback, potencializar o capital intelectual de todos os envolvidos para antecipar riscos e oportunidades, validar hipóteses e ajustar-se às mudanças … é a TI.

O ciclo iterativo-incremental não é uma legalzisse das metodologias ágeis, mas uma realidade suportada pelas Teorias da Complexidade e destacado pelo modelo CYNEFIN. Os profissionais de TI já não estão lá só para desenvolver software, eles estudam para entender este quadro de complexidade, entender o problema, propôr as opções e a best choice. É responsabilidade da TI propôr e lançar mão dos melhores métodos, técnicas, argumentos, poder de negociação, apesar de ser muito mais fácil poder dizer que a culpa é do usuário que é leigo em tudo isso.

Reflexão #3. Será que conseguimos gerar empatia e sinergia?

Está na hora de parar de reclamar do cliente, a não ser que ele seja um psicopata de verdade, cabe a nós propôr um processo de trabalho que o envolva e gere um trabalho pró-ativo, positivo e construtivo. Ficar transferindo, negando, projetando ou racionalizando uma hipótética culpa é pura dissonância cognitiva, defesas psiquicas que não geram qualquer valor e são substrato para zonas de conforto.

Se uma técnica não estiver dando certo, outras tantas devem ser avaliadas e aplicadas, uma delas se encaixará melhor e gerará o substrato no qual os resultados serão conquistados. Há dezenas de opções para elicitação, todas exigem empatia, entendimento do cliente e usuários, para que a partir disto seja possível gerar sinergia entre os envolvidos, com foco na construção daquilo que se precisa.

Reflexão #4. Somos sempre um sistema sócio-técnico complexo:

É preciso entender que engenharia de software não restringe-se a tecnologia que será utilizada, não é o resultado do trabalho de programação, ela começa muito antes e termina depois. O desenvolvimento de software envolve pessoas muito do software, o entendimento das necessidades, sua modelagem de negócio e solução, o próprio domínio e linguagem ubiqua necessária.

Grupos humanos são complexos por não serem previsíveis, por isso times SCRUM se utilizam de ciclos de duas semanas, gestão visual, MVP e antecipação de entregáveis, tudo isso sustentado por muita comunicação e envolvimento de todos, inclusive com o cliente e seus stakeholders.

Reflexão #5. Capacidade de negociação e argumentação em fatos:

Quem será que tem a obrigação de ter um time afinado e que através de seus profissionais possua a capacidade de argumentação construtiva, assertiva, centrada em conceitos que a psicologia, sociologia, as ciências sociais, além é claro da TI. Quem precisa dominar técnicas de elicitação, envolvimento, bem como saber usá-las para fazer um projeto encaminhar-se o melhor possível. Frente a adversidade, é obrigação da TI ter este cenário claro na cabeça e encontrar uma saída, porque reclamar, xingar, largar de mão, não é atitude de um profissional que estudou e trabalha para ser um especialista em projetos de software.

Conclusão

Esta na hora de parar de mi-mi-mi e assumir que a responsabilidade por um mau projeto jamais é do cliente (salvo psicopatas), pois cabe a nós anteciparmos riscos, dificuldades, atritos, para revertê-los e manter um projeto alinhado, a cada desvio trazer de volta para o prumo desejado … este papel e obrigação é nossa, da TI, quem não está pronto para assumir esse fato, ainda dá tempo para tentar turismo, direito, administração, oftalmo ou mesmo ser feliz vendendo pipoca no parque  😉