Se devo ensinar a usar, então meu SW não existe

     Minha proposta não é analisar a existência física das linhas de código escritas e sim a aderência destas ao mundo real, aquele vivido por nosso usuário no seu dia a dia quando planeja, executa, avalia, e onde o sistema não o ajudando pode ser apenas um fardo a mais a ser carregado.    

     Muitas vezes participei de desgastantes e cansativas reuniões na busca de culpados, onde transferimos para os usuários via crédito na conta "uso incorreto do software" nossos problemas, se tem algo que foge da responsabilidade de quem utiliza nosso produto é o seu conhecimento do mesmo, o sistema oferecido é quem deve conhecer as necessidades do utilizador.

     Meu cliente, por óbvio, não tem nada a aprender sobre o software que disponibilizo, sua tarefa é conhecer o próprio negócio, suas principais regras e funcionalidades e é nesta direção que deve ser feito todo e qualquer investimento de tempo e treinamento, aparecendo o software apenas como um recurso de otimização do trabalho.

     O profissional no processo de informatização, independente do setor, concentra seus recursos em investimentos necessários para aumentar sua produtividade, utilizando sistemas que devem ser naturais, navegados de maneira intuitiva, com conceitos e símbolos usuais na sua comunidade.

     Somos tentados a propor sistemas que pecam pela falta de simplicidade, onde mostramos nosso apego à tecnologia que bem serve nossa vaidade, porém pouco compatível com as necessidades do usuário, de alavanca passamos a objetivo e com isso estamos roubando precioso tempo de nosso cliente.

      

     Ter um software vivo no mercado significa evitar somar obrigações para seu utilizador, significa simplificar tarefas agregando potência a cada uma delas, significa via bons resultados acrescer alegria e autoestima.

     Traçando um paralelo com o Futebol onde falamos que um bom juiz é aquele que não aparece durante o jogo, poderíamos na informática dizer: "Quanto mais transparente ao usuário, melhor é o software".  

TI parceira na luta contra o talento pessoal

     A maioria dos agentes financeiros e suas áreas de TI inibe o talento nas suas empresas, Daniel, você enlouqueceu? Nunca se investiu tanto em linhas de código para agentes financeiros, em aplicações web, em redes locais de agências e em quiosques eletrônicos.

     Fracasso na utilização de talentos? Nunca agentes financeiros obtiveram tanto lucro, arrecadações tão espetaculares como hoje no Brasil, calma deixa eu me explicar, analisem comigo as situações que vivenciei.

     Adolescente eu pude testemunhar, em cidade pequena, vinte mil habitantes, a agência local conseguiu o maior valor em números absolutos de depósitos juvenis entre todas as agências do banco no país, fato improvável, só explicado por existir autonomia local, com suas iniciativas e responsabilidades.

     Nos tempos atuais a cada visita ao banco encontro um interlocutor totalmente dependente de um programa de computador, de um lado eu e minhas necessidades e de outro um gerente de conta sem autonomia, sem caminhos para mim e consequentemente para a instituição.

     Os resultados positivos da área financeira, sustentados por sistema definido pelo privilégio, não escondem uma gestão que engessa os profissionais, regras definidas de cima para baixo apoiadas por um software destruidor de talentos.

     A simples análise da premiação dos funcionários, conhecendo um pouco o sistema, atesta o que afirmo, paga-se comissão o que os define como vendedores e não como gestores, que por seus méritos e talentos seriam contemplados por um plano de carreira.

     Tenho absoluta certeza de que poderíamos ter um software que permitisse via indicadores alavancar decisões por parte dos gerentes, adubando seus talentos pessoais, para obter os melhores resultados tanto para o agente financeiro como para o cliente. Lutar por isso é também uma obrigação nossa, da área de TI.

     Imagino que todos vocês devem ter vivenciado o por mim relatado, aposto por nossa já famosa "falta de competitividade Brasil" no mundo globalizado que esse exemplo é reproduzido nas mais diferentes atividades exercidas na sociedade e o fato de seus gestores serem os principais avalistas do problema não isenta de responsabilidade os profissionais de TI.

Casa de ferreiro espeto de pau

     O que é bom para meu cliente não serve para mim? Vendo a ideia que ele vai ganhar produtividade automatizando seus processos, por que o mesmo não seria válido para o meu processo de desenvolvimento de sistemas? Fugir da automação do meu dia a dia nada mais é do que "casa de ferreiro, espeto de pau", como se diz aqui no sul entre nós gaúchos.

     O que quero dizer com essa frase popular é que advogo uma causa que não adoto, e tenho encontrado na comunidade de informática, que tem como missão aumentar a produtividade de seus usuários através da automação de seus processos de trabalho, dificuldade em aceitar que sua produtividade pode ser aumentada pela automação do seu trabalho de codificação.

         

     Obviamente que uma parte dos desenvolvedores trabalha na produção de ferramentas de produtividade para a própria comunidade de TI, estes certamente escolhem a linguagem mais apropriada para desenvolvimento dessas ferramentas, porém eu como analista de negócio que vai informatizar o usuário final, tenho obrigação de utilizar todos os recursos possíveis para atender meus clientes com mais qualidade e produtividade evitando penalizá-los em tempo e valor.

     Lembro novamente Warnier, o tempo tem comprovado acerto de suas pesquisas quando afirmava que no desenvolvimento de sistemas dez por cento de nosso tempo é dedicado à solução do problema e noventa por cento à tarefa enfadonha de escrever código, defendendo a ideia de que deveríamos separar o analista de negócio do codificador, inclusive salientando que após a solução do problema durante a codificação a tendência é de perda de foco, e por isso nessa hora geramos ao escrever o código a maior quantidade de erros, nossos famosos bug's.

     Felizmente evoluímos, hoje podemos descrever a solução do problema e automatizar a tarefa de codificar substituindo-a por ferramentas, com a vantagem de estas serem construídas por especialistas que para cada diferente regra de negócio escolhe as linhas de código mais adequadas para cada linguagem e banco de dados.

     Em mais de vinte anos, convivendo com uma grande comunidade distribuída por todo o mundo utilizando uma destas ferramentas, o Genexus, não encontrei desafios, independente de complexidade, que não pudesse resolver com sua utilização liberando em tempos consideravelmente menores excelentes aplicativos.

Seguir as "tábuas da lei" é certeza de sucesso para meu projeto?

     Posso ser tentado a procurar um Moisés, com seus dez mandamentos gravados na Pedra, e seguindo-o passo a passo obter o paraíso para meu negócio? Seria possível assim chegar aos melhores resultados? Parece-me difícil aceitar que entre tantos outros que seguirão as mesmas leis terei algum diferencial que me permita o tão almejado sucesso.

     O mercado nos apresenta inúmeras receitas, sempre receitas de sucesso garantido, sempre escritas depois do sucesso alcançado, curioso é que enquanto estou atrás da receita do momento, sempre um não seguidor atinge seus propósitos e por seu êxito gera uma nova receita.

     A melhor imagem que vi retratando com força essa opção decadente é a crítica ao sistema educacional no filme "The Wall", em que aparece uma animação mostrando milhares de estudantes todos iguais gerados a partir de uma máquina de moer carne que os põe a marchar em enormes filas indianas.

     Parece-me óbvio que o bom caminho só pode ser criado, nunca copiado, muito mais importante do que seguir as trilhas já percorridas é refletir sobre o contexto, sobre os desafios enfrentados e detectar onde se manifesta a criatividade, quais e que talentos humanos participam do processo.

     Como desenvolvedor, tanto em uma casa de software como em uma corporação, o processo envolve não só a área de Tecnologia da Informação, mas a organização como um todo, certamente não adianta ser criativo para informatizar um negócio preso a uma camisa de força.

     Por isso acredito na gestão horizontal através das pessoas com seus pontos fortes e fracos, na estrada construída sob medida para cada organização, caso a caso, aproveitando o conjunto de recursos humanos internos e externos disponíveis, buscando o tal do "encaixe", figura de linguagem muito utilizada no futebol que identifica os times ganhadores.

Bom, postei e então, calma, me explico.

     Depois de três textos postados, me senti na obrigação de explicar-me, sim não é de hoje que tenho este projeto, pois finalmente resolvi colocar em prática, espero que as linhas que seguem sejam claras. 

     Observando uma impressora 3D, camada a camada compondo um objeto novo em três dimensões, revi como em um flashback, um processo similar compondo o que hoje sou também: os projetos, consultorias, treinamentos, churrascos e conversas de bar foram aos poucos construindo o meu pensamento.

     A comunidade, vista pelo seu aspecto mais amplo como encontro de seres vivos, foi e sempre será o agente provocador da construção de um pensamento atuante, como me classifico, graças a inegável influência das pessoas com quem convivi, isto é, de vocês.

     Assim como me defini no Twitter: "Sim pistas, paixão, livros, pessoas, tecnologia da informação, sim vida; Apenas personagens sobrepostas no tempo de mim mesmo e seus rastros", esse resultado é o que me proponho deixar por aqui.

     Bom, ficou fácil adivinhar porque resolvi postar um ou dois textos por semana, nada mais é do que devolver para vocês algo do qual são coautores.

     Transparência, eu nunca acreditei nas ideias como um tesouro a ser guardado e sim sempre as vi como um bem a ser compartilhado, compartilhar é um privilégio para quem disponibiliza, e sou grato pela possibilidade de talvez alguém ler, comentar, contestar ou simplesmente ignorar.

     Pretendo através de uma linguagem simples, direta escrever estas linhas sem que pensem que tenho algo a demonstrar, nem mesmo a propor, apenas quero deixar registrado o que tenho conversado com vocês nas muitas ou poucas vezes que nos encontramos, ou seja, nada mais que um log embaralhado na sua cronologia.

Desenvolvendo software e talentos

     Participando de projetos, independente do grau de envolvimento como desenvolvedor, analista ou consultor, sempre me atraiu as questões referentes a prazos e qualidade, pois confirmando as estatísticas quanto ao sucesso dos projetos de Tecnologia da Informação sempre enfrentamos dificuldades para que o usuário tenha a solução no momento que lhe é mais conveniente e que atenda as suas expectativas.

     Sou tentado a considerar indicadores como falta de talento, equivocada metodologia de trabalho ou ainda as ferramentas de trabalho adotadas como causa de insucesso quanto às metas de prazo e qualidade, certamente as diversas combinações possíveis desses três itens aparecerão na avaliação.

     Treinamento é o item que sempre tenho identificado como deficiente, não temos cultura de investir no treinamento, o que nos custa prazo e qualidade no projeto, obviamente essa deficiência não é privilégio da área de TI, também os usuários dos nossos projetos não são treinados, ou seja, estamos potencializando o problema.

     Treinamento deve ser um processo contínuo e multifacetado, estamos falando de considerar no projeto horas de treinamento como subconjunto das horas de desenvolvimento e atendendo todos os componentes como ferramentas, metodologia, tecnologia e negócio alvo, e todos envolvidos no projeto devem ter a visão global independente de suas especializações.

     A maneira convencional que utilizamos para treinamento, estudar um conjunto de temas completamente desvinculados das tarefas do nosso dia a dia, nos serve como referencial para quando enfrentarmos os problemas termos segurança para assim apreender resolvendo o problema real.

     Tem se mostrado muito mais eficiente distribuirmos o treinamento durante o processo de desenvolvimento, ou seja, à medida que assumimos as tarefas incluímos também como tarefa os módulos desejáveis de treinamento, associando a teoria à prática da maneira mais adequada ao problema que está sendo resolvido.

     Este conceito de treinamento contínuo representa garantia de acréscimo de qualidade, pois aumenta em muito a reflexão sobre as melhores práticas para resolver um problema específico e real.

     O acréscimo de pequenos turnos de treinamento (normalmente duas horas por tema) indicaria a princípio um tempo maior de projeto, porém na prática, o fato de eliminar dificuldades e rescritas devido a erro por deficiência de formação acaba garantindo os prazos desejados.

     Importante salientar que acreditamos em gestão distribuída o que permite que o time identifique, à medida que assume as responsabilidades do desenvolvimento, os conteúdos nos quais deverão ser treinados na tecnologia, nas ferramentas, na metodologia e no próprio negócio, neste último item sendo extremamente desejável a participação do usuário.

Estou escrevendo um Software que nasce morto?

     Sim, penso que sim, certamente não nos seus componentes, não no desenho de suas funcionalidades, mas na maneira como o concebo, na sua capacidade de aderência a organizações eficientes em uma sociedade globalizada, conectada e altamente competitiva.

     O que foi desejável por muito tempo, postos de trabalho disciplinados, comprometidos com processos repetitivos, trabalhando no conceito de linha de produção, hoje as organizações estão os substituindo por operadores que tenham talento, que tomam decisões, que sejam criativos.

     A tecnologia com seu avanço em velocidade geométrica tem possibilitado isso via automação de todas as tarefas repetitivas e substituição desses postos de trabalho.

     Estamos investindo muito dinheiro em linhas de código destinadas a engessar os operadores no dia a dia com regras e mais regras que inviabilizam a criatividade e o talento destes.

     Talento que cada vez mais é oportunidade única de promover a organização ao seleto grupo das bem-sucedidas.

     Quando penso que este tipo de organização está destinada a reorganizar-se ou desaparecer, estou dizendo que todo o investimento que faço em Software nessa organização está morto, isto é, estou sim construindo um Software que nasce morto, a empresa necessitará de um Software adequado à mudança ocorrida que a viabilize no mercado, sendo que, caso venha a sucumbir, não precise mais do Software.

     Como desenvolvedor, como analista, como consultor preciso escrever Software já pensando na empresa do amanhã onde quem vai utilizá-lo são talentos, tomadores de decisão, distribuídos por toda a organização, não no Software que os conduz por um caminho único pensado de cima para baixo. Tenho que oferecer muitas opções com alto grau de interação, oportunizando que a organização seja o conjunto criativo de seus colaboradores.

Eliminar complexidade e Orientação a Dados

     Quando escrevo software, seguindo conselho de DESCARTES busco eliminar a complexidade, ou seja, divido o complexo em suas unidades mais simples, obtenho através desse método um código enxuto e ganho produtividade.

     Se estivermos falando em escrever aplicações de TI, certamente podemos colocar a lógica como a principal qualificação desejável ao desenvolvedor, logo o ferramental disponibilizado nas ciências exatas nos parece o mais adequado para garantir o sucesso das mesmas.

     Desenvolvendo aplicações adequadas à sociedade conectada (Web 2.0, SaaS, mobilidade), reencontro na orientação a dados o caminho científico para o melhor código, WARNIER e sua Lógica de Construção de Programas mais atual do que nunca.

     Sim, Warnier tem como pilares da sua teoria a construção dos Diagramas de Entrada e de Saída de Dados, diagramas estes baseados na teoria dos conjuntos e na obtenção de unidades simples e indivisíveis de dados, por conseguinte de código.

     Estamos claramente falando em orientação a Dados, estamos falando em um método científico de saber qual código escrever, o que nos dá suporte a automatizar esta tarefa, pois se os dados nos orientam sobre o código a ser escrito podemos ter um programa que analise esses dados e escreva o código adequado.

     Na indústria de TI temos um exemplo prático na Tecnologia Genexus, em que utilizamos o objeto declarativo "Data Provider", no qual apenas descrevo a estrutura de dados de entrada e de saída com o programa oferecido pela Genexus. Escrevendo na linguagem que escolhemos o procedimento correto para percorrer as diversas tabelas, gera-se o resultado esperado sem que se necessite de nenhuma linha de código procedural.