O velho novo projeto

E então, somos chamados a mais uma daquelas intermináveis reuniões para debatermos qual a melhor forma de se apagar um incêndio no sistema xpto. Claro, há uma eminente determinação de todos os presentes, o problema tem que ser resolvido e rápido. O departamento z não pode ficar sem o sistema xpto.

Em meio a tantas soluções, tantas boas ideias, o que fazer? Assim, um novo debate surge e, agora, o foco é descobrir qual é a melhor ideia. Mas afinal, como se mede uma ideia? O que faz dela boa ou má? O testes, talvez, mas temos tempo e dinheiro para testar todas?

Neste momento fica claro o objetivo, o foco: resolver o problema. Mas o ideal não seria focar em não se ter problema? Toda e qualquer decisão tomada em momentos de tensão, ambientes de stress, têm a tendência de partirem para o caminho mais rápido, não o melhor. As decisões, nesses momentos, fluem como a água, buscando o caminho mais rápido. O que não significa que é o melhor caminho.

Incêndio significa fogo sem controle. Assim, é ilusória a máxima “apagar incêndio” do sistema. Tal como há tantas ideias para solucionar consequências, inúmeros podem ser os focos de problemas. O que somos: bombeiros, programadores ou paramédicos?

Finda a reunião, um novo projeto vai surgir para tentar resolver velhos problemas. É incrível o apego de um desenvolvedor com uma aplicação, ao ponto de invocar emoções que o impeçam de ver que a hora do sistema xpto chegou.

Que ele vá com Deus!

Embora triste, há momentos em que é chegada a hora de se tomar a decisão da morte de um sistema. Até porque, se o desenvolvedor assim não o fizer, o cliente pode declarar a morte de quem o fez. Claro, não devemos defender a certeza do que julgamos conhecer contra a incerteza do novo. É um fanatismo.

Quanto tempo se perde re-projetando? Em relação a algo pronto, nem sempre utilizamos a liberdade que a tecnologia nos propões: a da simplicidade. Fazer um projeto para corrigir algo de um projeto que não foi terminado. Isto não é reinventar a roda, é o equivalente a estar sempre comprando uma mesma roda.

De posse bom e velho novo projeto, somos fadados a querer produzir, aumentar. O termo “projeto” nos induz a isto. São raros os projetos de “limpeza de funcionalidades”, “eliminação de comandos”. Ora, queremos evoluir, e por vezes entendemos (compreendemos?) evoluir como sendo a algo (físico) a agregar. Mas deveria ser mais simples, evoluir deveria ser “adaptar-se”, no nosso entendimento. É preciso adaptar a forma de pensar ao invés de pensar em formas de se adaptar.

Por que é tão difícil recomeçar? Porque somos treinados a crer que se deve recomeçar somente após uma queda. “levanta, sacode a poeira e dá a volta por cima!”. No entanto, a decisão de se recomeçar um projeto falho, significa a maturidade de ver que crescemos. É como olhar o código e se espantar: fui eu quem fiz isto? Sim. Fui eu mesmo. É hora de evoluir meu produto, hora de substituí-lo, hora de encerrá-lo. Não há tombo, não há derrota, apenas crescimento.

Apagar incêndios é cíclico e consequencial. Nunca termina. E o pior: sempre sobram cinzas impossíveis de se limpar. E quando acredita estar tudo limpo, ainda resta o cheiro de fumaça.

É hora de olhar para o cliente sob o olhar dele, e não do nosso. Quando deveríamos negar funcionalidades fantasmas, as agregamos, pois somos treinados a produzir funcionalidades e não a interpretá-las. Quando devemos ouvir o cliente sobre o seu negócio, seu domínio, o negamos, pois somos treinados a crer que conhecemos o produto melhor que o cliente e não a produzir em conjunto.

Somos mal treinados? Seguimos uma tendência? Somos egoístas? Não deve haver uma resposta plausível para tal questão, no entanto, sempre há lugar para pensar diferente, agir diferente. Projeto novo, que seja mesmo novo.

De quem é o seu conhecimento?

Por vezes sou tentado a questionar-me sobre a quem pertence o meu conhecimento. Não a informação, pois esta é deveras transitória em minha mente, mas o conhecimento. Aquela coisa que nos faz interagir com a linguagem, a informação, o ambiente e o raciocínio. Sim, pois creio raciocinar de acordo com um certo conhecimento que define as diretrizes do meu pensar.

Dia desses, lendo o livro Getting real, escrito pelo pessoal da 37signals, percebi a necessidade de compreender o pragmatismo americano. Entendi que era necessário, ao menos para mim, compreender o pensamento de quem escreveu o livro, se é que isto é possível.

Logo de cara, percebi que, pelo momento pessoal em que vivo, o livro foi bastante claro, entendi de cara. Mas depois, conversando com meus botões, imaginei estar caindo numa armadilha: entendimento versus compreensão.

Segundo o dicionário online priberam (http://www.priberam.pt/DLPO/), entendimento significa

entender (ê) - Conjugar

(latim intendo, -ere, estender, pretender, estar atento)

v. tr.

1. Apossar-se do sentido de (o que ouvimos ou lemos).

2. Ser de opinião; julgar.

v. intr.

3. Ser entendedor.

4. Superintender.

5. Infrm. Contender, armar rixas.

v. pron.

6. Compreender-se (a si mesmo).

7. Referir-se; ser concernente.

8. Estar de acordo (duas ou mais pessoas).

9. Combinar.

s. m.

10. Maneira de pensar ou de ver. = entendimento, juízo, parecer, opinião

e compreender

compreender (ê) - Conjugar

v. tr.

1. Abranger.

2. Encerrar.

3. Conter.

4. Entender.

5. Alcançar com a inteligência.

6. Perceber.

7. Notar.

8. Depreender.

9. Saber apreciar.

10. Ant. Achar (alguém) incurso em, ou culpado de.

11. Estar incluído ou contido.

Achei bastante interessante “entender”, como apossar-se dos sentidos e “compreender”, estar incluído, ou contido. Claro, não é possível compreender sem antes entender. Compreender é tal qual uma tarefa dependente de entender. Porem, percebe-se que é possível apenas entender.

Assim, fico a imaginar o quanto somos obrigados a apenas entender. Imagine um trabalho onde as tarefas são passadas como certas, e você até tem a liberdade de questionar, mas a premissa já fora definida e é irrevogável, ou seja: questione, mas tera que obedecer.

Sem nenhum incentivo ao anarquismo, mas de que vale o entendimento neste caso? A simples base para a sequência de um roteiro? E o pior: cremos na falsa liberdade do questionar. Esta liberdade, falsa, nos ilude no aspecto de que fazemos parte de um conhecimento que não é nosso e que pode jamais ser, uma vez que somos obrigados a encerrar nosso exercício mental na fase do entendimento.

Por fim, seremos responsabilizados pelo resultado do produto e não somente pela resolução do mesmo. Algo como: empregado, faça “A”. E o pobre até questiona: “A” com acento ou sem acento? Empregado, faça “A” com trema. E dá-lhe esforço, trabalho, dedicação. Tudo tem que ser rápido, pois o chefe que solicitou não possui todas as noções necessárias de como produzir “A”, ainda mais com trema.

Trabalho realizado, vem a surpresa: “A” com trema não é capaz de realizar o que se necessita.

Um momento. Quando foi questionado o que “A” deveria fazer? Apenas se entendeu que produto seria realizado, mas o que o produto faz? Para que serve? Compreendo bem a necessidade? Consigo conversar com o produto? Compreendo sua linguagem.

Já dizia o Bituca (Milton Nascimento): “minha casa não é minha, nem é meu este lugar.” Este fragmento deveria ser o hino da frustração. É qual entender onde estou, como estou, mas não compreender quem eu sou.

Quando somos forçados a apenas entender, cumprimos o imediatismo das corporações e apresentamos resultados rápidos. Mas nem sempre satisfatórios a estas corporações e sempre infelizes para nós mesmos. O que é um resultado? É simplesmente entregar o que se pede? Na forma que se pede? O que é pedido afinal? Quem o sabe?

Não vamos atravessar a linha filosófica do Cogito, ergo sum ("penso, logo existo") – Rene Descartes. Mas nos estacionemos por hora no Dubito, ergo cogito, ergo sum, ("Eu duvido, logo penso, logo existo"). Quando realizamos algo que simplesmente entendemos, significa que alguém compreendeu este algo anteriormente a nós. E se não compreendermos este algo doravante, ou nos contentamos a simplesmente entender ou somos impelidos a tal.

Desta forma, chegamos na questão do título: a quem pertence o nosso conhecimento? No caso citado acima, sequer chegamos na esfera do conhecer. Então, não nos há conhecimento. Mas e quando podemos adentrar o espaço do conhecer enquanto produzimos? De quem será o conhecer?

Nosso!

Meu, seu, do chefe, da corporação, nosso. Caso compartilhado, digo, encerrado. No entanto, sabemos, as coisas não são bem assim. Há hierarquias, segmentos, regras incompreensíveis que todos os dias enfrentamos. Porém, se o conhecer é algo que podemos personificar em nossa centelha intelectual, não há impedimento para o alcançarmos. Ou melhor, é uma tarefa que depende unicamente de nós mesmos.

É preciso duvidar para entender, entender para conhecer, conhecer para se satisfazer, estar satisfeito para duvidar. Sim, porque, do que adiantaria duvidar num momento em que não há satisfação? Nada. É preciso estar cheio para duvidar do que possui e assim começar e/ou recomeçar o eterno ciclo do conhecer, do amadurecer. E este conhecimento é somente seu. Não há corporação, regra, modo ou situação que o tire de você. É a sua conquista.

Esperança

Tenho esperança que este texto fique bom.
Bom, ainda continua medíocre, poucas palavras, objetivo obscuro. Mas ainda tenho esperanças. E aguardo...
Continua na mesma. Talvez o tenha piorado. Acho que vou partir para um plano “B”. Porém não há plano “B” e o meu texto continua ruim. Porque eu não fiz um plano “B”? Será que esperei demais?
Nestas minhas andanças pelo vale da programação, sempre me deparei com a tentação de esperar que tudo se ajeitasse. Com isto, acabava por desconsiderar questões básicas como planejamento, estratégias de exceção, análises, saídas alternativas. Excesso de confiança? Com toda certeza.
Não que eu não merecesse tal confiança, mas o caso é que por inúmeras vezes acreditei que era capaz de realizar o impossível e esperava, como sempre, de fato conseguir. E esperava, esperava e apenas confiava, sem nenhum trabalho extra.
Uma ilusão, pois sempre trabalhei mais para não realizar absolutamente nada. Um exemplo, um certo cliente pediu-me que desenvolvesse toda uma aplicação de gestão de Planos de Ação, mas havia um problema: como haveria uma auditoria, era necessário que o sistema estivesse disponível em duas semanas. Fora isto, o cliente ficava 80% do tempo indisponível para levantamento de informações e havia uma distância geográfica considerável. Estava em Minas e ele no Mato Grosso.
Não é necessário estender a história ou detalhar fatos. O sistema não ficou pronto a tempo. Precisei ir ao MT e lá trabalhar por cerca de 15 horas por dia e, não entregar um sistema funcional, mas um amontoado de protótipos que iam do nada a lugar nenhum. Atendeu à auditoria, mas corroeu-me por dentro. Senti-me frustrado. O tempo todo tinha esperanças que terminaria, mas isto não aconteceu. E eu não tinha um planejamento, uma plano de contingência, nada. Apenas esperança.
Não posso entrar no mérito da fé, isto muito íntimo de cada um. Porém, no mundo da responsabilidade, a ação é o que vale. Você pode até esperar ser um programador melhor, uma pessoa melhor, ter mais grana. Espere o quanto quiser. Se não agir, será apenas mais um a esperar.
Hoje, reconheço que precisarei reescrever este texto inúmeras vezes até que o mesmo possa ter um mínimo de aceitabilidade pelo leitor. Hoje reconheço e assumo o compromisso de agir em função daquilo que produzo, e não o contrário. Por todo o tempo que esperei minha produção agir a meu favor ela sequer foi produzida. Sim, porque algo mal feito não se difere de algo não feito.
Para que um coisa, um programa exista, é necessário que ele saia do mundo das ideias. É preciso se esforçar, limpar a forma, manuseá-la com cuidado, agradar Platão. Não se deve esperar que fique pronto. Um programa não é um bolo. É a sua ideia, a sua produção.
Mas o que diferencia o trabalho que realizo enquanto espero e confio, de um trabalho de ação que atinja o objetivo esperado? Ora, não estou trabalhando da mesma forma? A resposta é não. Manipular conhecimento é diferente de produzi-lo. Ajuntar códigos com o objetivo de simplesmente entregar algo pronto, é muito diferente escrever um login pensando em quem vai utilizá-lo.
Vou revelar um medo que guardo comigo: de que os programadores se tornem digitadores. Não possuo fontes sobre esta vertente, nem posso provar que ela ocorra. Mas guardo um medo de que isto possa acontecer. Sempre me pergunto quanto de mim está presente num programa, numa análise. Não é uma questão de uma assinatura, mas simplesmente de personalidade.
Assim como eu, minhas produções possuem defeitos, qualidades. Mas quanto destes defeitos são meus? E as qualidades? Não que seja errado aplicar algo de bom encontrado na net, mas o que qualifica este algo como algo bom? A minha análise, o meu conhecimento conversando com o conhecimento do outro e formando um novo conhecimento.
Para isto, algumas horas de leitura sempre ajudam. Debates em foruns, com colegas de trabalho sempre acrescentam. Por isto não posso apenas esperar que algo dê certo, é preciso compreender o que é o certo para este algo e suas implicações.
Mas não vou conseguir saber tudo. E isto é o que há de melhor. Sempre há oportunidade para um novo conhecer. Trazer uma ideia do mundo das formas para o mundo real é um processo. Fazer o mundo real compreender esta ideia é um progresso. Levar esta compreensão à origem, ao mundo das ideias para que as novas formas já a tenham impressa, é partilhar conhecimento.
Hoje, sempre que penso em esperar, em ter esperança sobre algo, começo logo a planejar; boto o meu conhecer para “papear” com o conhecimento de outros. E você, o que espera para si? Ou já está agindo?

Próximo!

Às vezes fico imaginando a satisfação de um médico, quando a secretária, sem sequer levantar o olhar atendo à sua sua agenda, grita: próximo! Um cliente atendido, outro a caminho, mais uma experiência ganha e mais um desafio a caminho. Bom, assim imagino.
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?