No mundo de desenvolvimento não deveria ser diferente. Devería-mos constantemente gritar: próximo. Mas isto não acontece. Porque? Vou tentar elencar algumas razões com base na minha própria dificuldade em gritar “próximo”.
Num primeiro momento, é preciso entender a concepção que se tem de realização profissional. O que é estar-se realizado profissionalmente? Um bom salário? Poucas horas de trabalho? Dinheiro na conta? Fazer o que gosta?
É de cunho muito pessoal, portanto, acredito que seja uma questão sem importância. Sim, sem importância mesmo. O que a realização pessoal tem haver com um produto desenvolvido para outrem? É justamente este o ponto. E acredito que ele possa estar naquela máxima “não há mérito no cumprimento do dever”.
Bom, se isto é natural para o leitor, sugiro que passe para uma outra leitura. Próxima!
Se não, vamos continuar: que mérito há no cumprimento do dever? Se o dever é seu, pessoal, a realização do mesmo diz respeito a você mesmo. O empenho e desempenho na sua produção não seguem com o produto pronto, ficam com você. A qualidade o segue, mas o desenvolvimento da mesma permanece com o criador. Este é o mérito que se herda no dever cumprido.
Quando se valoriza aquilo que agrega o desenvolvimento, o mérito esta na vitória de se aplicar aquilo em que se acredita. E como prêmio: conhecimento. Um exemplo: qual programador não se sentiu satisfeito no seu primeiro “Hello World”. Independente da linguagem, do código, do paradigma. Falo daquela satisfação, do monólogo: eu consegui! E que todos dizer depois? Hora de fazer o “próximo” passo.
Houve um tempo em que minha maior preocupação estava na segmentação de um software, na sua continuidade como programa e na minha como empregado. Hoje fico agradecido que esta preocupação se foi com meu primeiro emprego na área de informática. Neste tempo, conheci muita gente que aplicava técnicas de “defeito previsto”. Situações que obrigariam a intervenção do programador e consequentemente a geração de um custo para o cliente.
Também convivi com as chamadas licenças de uso. Um valor pago mensalmente para o programador não fazer nada. Muitos, acreditem, diziam que era o pagamento da propriedade intelectual. Era uma coisa mais ou menos assim: o cliente dizia ao programador o que fazer, o cara fazia o que o cliente queria menos um (defeito previsto) e depois cobrava a patente para o idealizador do programa. Eram vendidos programas e não soluções.
Devo admitir que parti para soluções parametrizáveis como um diferencial no mercado. E sendo novo, não tive retorno financeiro, mas tive a satisfação de aprender métodos que pude aplicar em soluções duráveis. E estas sim, são as que interessam no mercado.
Entregar uma solução que se auto-gerencie não é o fim de um trabalho, mas o início de vários outros. O cliente prefere conhecer que fez a solução ao programa que resolve. Porque? Porque não existe apenas um problema no mundo.
Nem é preciso dizer que meu trabalho era solitário. Assim, entregar algo que estivesse bem ao meu ponto de vista e ao mesmo tempo que atendesse às expectativas do cliente era penoso e demorado. Foi então que eu percebi que o problema maior estava na expectativa causada no cliente. Vejamos um cálculo não oficial:
quebra de expectativa = ((frustração) ^ dias de espera ) * 2
Onde 2 representa você mais o cliente.
Assim, quanto mais fazer esperar, maior a probabilidade de decepcionar. O que fazer então? Causar menos expectativa? Pode ser. Mas também se pode causar expectativa à prestação. Quando desenvolvi um software para a área de segurança do trabalho, prometi um gráfico em que o técnico seria capaz de fazer mais de 1000 análises que o ajudariam no seu dia a dia. Entreguei, com atraso, claro. E onde ficou a decepção? Esta estava no fato de o técnico não usar mais do que três análises do gráfico. A que que fazia mais de mil... A expectativa que eu havia causado não estava no software, mas na alteração de um modelo de trabalho que não ocorreu. A frustração ficou lá, no dia a dia do técnico. Depois deste episódio entendi o que significavam as frases “canhão para matar formiga” e “máquina de fazer sombra”.
Por outro lado, posso elencar as expectativas que quero causar (entenda por ideias, inovações) e as distribuir mediante a entrega. Podemos descobrir que algumas são apenas inúteis, outras perigosas, a maioria inatingível. Devemos atuar como num jogo de xadrez, imaginando no mínimo uns cinco movimentos à diante. E sempre atentos aos movimentos que não devemos fazer. A expectativa deve ser compartilhada e moderada. Jamais deixe que o cliente tenha mais expectativas do que você. A expectativa causa uma cobrança de resultados às vezes até incompreensíveis. Se você, por sua própria expectativa se cobra, imagine também sendo cobrado por seus clientes por algo que eles nem sequer lhe pediram.
Aliás, quem são seus clientes? Se esta pergunta é difícil resolução, ou pior, se for uma resposta curta, então é hora de repensar no assunto. Mas podemos resumir: todos são meus clientes. Num processo comunicativo, todos, por uma razão ou outra sugerem oferecer uma satisfação, um feedback.
--- E aí, cara, tudo bem?
--- Beleza e você?
--- Bem também.
Neste diálogo curto, houve uma satisfação de fatos (estado) dos dois lados. Agimos assim, é natural da comunicação. É preciso entender somente que tipo de satisfação dar e cobrar de seus clientes.
O conflito de egos também é um grande vilão na história do “próximo”. O cliente sempre tem certeza do que está pedindo e o programador sempre sabe o que está entregando. Assim, caímos nos três lado de uma mesma moeda: a sua versão, a minha versão e a versão correta. Se enfileirarmos um monte de moedas deitadas, ora cara, ora coroa, consumiremos um grande espaço físico e a última moeda, a palavra final, será de quem tiver mais poder de se impor, ou cara ou coroa.. Se as enfileirarmos de pé, todas os lados que vão aparecer são as laterais, sempre iguais e com um espaço muito reduzido.
O que quero dizer é que o esforço deve estar direcionado à comunicação, à análise e ao consenso.
Próximo = !retrabalho
Retrabalhar aquilo que já foi solicitado causa frustração, não gera conhecimento, gera custos e causa decepção no cliente. Assim, a ortografia de uma aplicação solicitada deve falar a linguagem do cliente e não a sua. A não ser, claro, que você mesmo seja o cliente. Quando não se tem retrabalho, se tem oportunidade de resolver outros problemas. No entanto, uma coisa fique bem clara: os outros problemas não podem, jamais, ser novos problemas causados por sua aplicação. Lembre-se, produzir soluções é diferente de produzir programas.
A diferença está justamente no fato de que programas independem de interpretações humanas. Por mais protegido com alertas que um programa esteja, o usuário pode simplesmente ignorar e executar.
Solução significa entender se o usuário poderia ou não executar tal programa, se este mesmo programa é de fato necessário. É falar a mesma língua, deixar claro o que se está executando. É a comunhão do conhecimento.
Relembrando Paulo Freire: “Ninguém educa ninguém, ninguém se educa a si mesmo, os homens se educam entre si, mediatizados pelo mundo”. Ou seja, é preciso partilhar e compartilhar conhecimento.
Tenha uma equipe, mesmo que trabalhe sozinho. A quem você recorre nas suas dificuldades? Ou acredita não tê-las? Faça testes, conheça novas modalidades de testes, abandone preconceitos de linguagens e paradigmas. Já acreditei que visual basic resolveria até meus problemas sexuais. O que aprendi com isto? Que ao invés de ser expert nesta linguagem, era um nada nas outras linguagens.
Todas as linguagens possuem defeitos e qualidades Mas antes de tudo, todas possuem aplicabilidade. Estude cada uma, as velhas, as novas, entenda antes suas aplicabilidades. Acredite, isto é fundamental para se dizer: próximo.
Faça tentativas, invista no conhecimento. Ele não tem valor se não for aplicado. “Não enterre seus talentos”. Neste momento, vou adotar com minha equipe um grito de guerra: próximo! Com apenas uma certeza: será mais uma experiência ganha. Qual é o seu grito de guerra?
Postagens
