Seja especialista no problema e não em soluções

ProblemSolution_MODIFICADO_ok

A frase que dá título a este post não é a minha. Eu a ouvi na palestra Desenvolvendo Aplicações de Comunicação com Asterisk apresentada na Campus Party 6 em 2013 pelo colega Dougas Conrad. Ela contém uma recomendação muito importante para os profissionais da área de TI, especialmente programadores e DBAs: é preciso se concentrar mais no problema e nas suas características do que na solução.

Durante toda a minha experiência na área tenho visto muitos profissionais que se interessam mais pela solução, ou seja, pela ferramenta, plataforma, IDE, linguagem de programação, software ou tecnologia específica, do que no problema em si. E isso fica claro e evidente quando analisamos o conteúdo de muitos eventos técnicos de comunidades que se concentram muito mais em aspectos técnicos da solução (nova funcionalidade X, dá para fazer Y agora) do que discutir os tipos de problema para qual a tecnologia é utilizada. Não me entendam errado: realmente é importante aprender a ter proficiência e produtividade com certas ferramentas e recursos para encontrar a solução, porém cada vez menos vejo pessoas se preocupando com o domínio do problema, suas características, implicações e embasamento teórico necessário não apenas para compreender o problema como também para resolvê-lo.

Aqui faço mea culpa: durante muito tempo (e até hoje) publico material sobre ferramentas e recursos específicos para soluções. Isso é devido à minha larga experiência no mercado que me fez ser um especialista em determinadas tecnologias e não tanto em determinados problemas. Mas recentemente teve revisto esta postura e destaco que cada vez mais tenho escrito artigos sobre modelagem para a revista SQL Magazine e também direcionando as pautas do DatabaseCast para tópicos concentrados no problema ao invés da solução.

Há uma enorme pressão do mercado por especialistas em soluções ao invés do problema. No meio de currículos e vagas que cada vez mais dão valor para certificações e experiência com certa tecnologia, a capacidade de analisar, compreender, estudar e se especializar em problemas acaba ficando para escanteio. De fato, acho pouco provável que alguém da área técnica coloque especialista em resolver certo problema em um currículo. O mais como é encontrar afirmações do tipo gosto de aprender ou consigo compreender rapidamente novos conceitos. Aqui fico a pensar que se você é um especialista em uma solução isso pode lhe garantir o emprego hoje em uma empresa ou conjunto de empresas, mas se você resolver se especializar no problema isso pode lhe garantir um emprego hoje e no futuro em um grupo de empresas que tenham passado por problemas semelhantes.

Do ponto de vista acadêmico, geralmente o enfoque é voltado para o problema, metodologia, implicações, análise e outros aspectos em conjunto com treinamento em ferramentas para obter a solução. Basta analisar qualquer lista de disciplinas de uma faculdade de tecnologia. Isso não está errado, mas quando vejo certos conteúdos programáticos em faculdades cujo objetivo é apenas preparar o aluno para o mercado de trabalho sinto que os alunos que se concentrarem mais no problema ao invés da solução vão ter algum tipo de vantagem e diferencial não na contratação, mas no dia a dia.

Uma das dicas que recebi em uma palestra do professor Clovis T. Fernandes do ITA me ajudou um pouco a enxergar este paradigma e formalizar este tipo de atitude. Era uma palestra sobre escrita de artigos e ele falou de um esquema de quatro sentenças para descrever bem um problema. Abaixo cito as sentenças com alguns comentários meus.

1. Declare o problema

Saber declarar o problema é fundamental, pois com isso podemos falar a mesma língua com os especialistas do domínio e limitar o escopo. Note que esta declaração deve ser relativamente simples e contextualizar o problema. Pode ser que muita gente não enxergue o problema apenas com a declaração e por isso que as próximas sentenças são necessárias.

Muitas pessoas consideram esta a parte mais importante. Uma vez ouvi de um professor que saber encontrar um problema representa mais da metade do que precisa ser feito e essa não é uma tarefa trivial. Além disso, temos a máxima que são as perguntas que movem o mundo e que estamos cada vez mais em busca não apenas de respostas para nossas questões mais de novas perguntas para nos impulsionar para frente.

2. Declare porque o problema é um problema

É crucial dizer por que um problema é um problema, pois alguns podem achar que não vale a pena resolver esta questão. Aqui cabe fornecer números, detalhes de pesquisas, medidas de métricas obtidas em experimentos e argumento válidos e justificáveis para conversar e blindar qualquer ataque que questione a validade e a necessidade de resolução do problema.

3. Escreva a frase que captura a essência da sua solução/contribuição

É nesse ponto que entra a solução e todo o detalhamento técnico. Note que é preciso justificar porque tal tecnologia, abordagem, método ou ferramenta deve ser empregada para a solução ao invés de outras. É cada vez mais comum encontrar a palavra americana tradeoff neste ponto, pois ela basicamente expressa a seguinte característica: se você escolher uma abordagem para solução ela vai possuir pontos positivos e pontos negativos. E você deve indicar qual é a troca, ou seja, o que você vai ganhar com a solução e o que você vai perder ao utilizá-la. Por exemplo: se você utilizar o software X você conseguir ganhar desempenho Y, mas vai perder o poder Z de customizar a solução.

4.Declare a implicação/consequência da terceira declaração

É preciso declarar as implicações e consequências da solução que estamos propondo. Além do tradeoff as soluções tecnológicas tem um impacto grande em diversos aspectos. Utilizou a tecnologia T? Talvez isso impacte em treinamento para todo mundo que precisar utilizar a tecnologia T mas não a conhece, sem contar com custos (o TCO), atualizações, etc. Muita gente, especialmente o pessoal de marketing e profissionais que querem ‘empurrar’ certa tecnologia, convenientemente deixam de lado ou minimizam o impacto a médio e longo prazo de certas implicações ou consequências da solução, o que pode gerar algum tipo de inconveniência no futuro.

Por fim, queria destacar que é muito comum encontrar pessoas empolgadas, motivadas e que realmente gostam de certas tecnologias novas ao ponto de ficarem imaginando como ela pode ser utilizada. Isso é OK e pode gerar muita inspiração, mas acredito que pesquisar e conhecer bem o problema primeiro antes de tentar encaixar uma tecnologia existente ou nova é mais adequado para o processo como um todo, especialmente quando as soluções propostas tentem a ser mantidas por um longo período de tempo.



Esta entrada foi publicada em Uncategorized e marcada com a tag , , , , , , . Adicione o link permanente aos seus favoritos.

4 respostas a Seja especialista no problema e não em soluções

  1. Pingback: Vícios e manias de quem aprende a programar sozinho | Blog do Mauro Pichiliani

  2. Pingback: Vícios e manias de quem aprende a programar sozinho |

  3. Pingback: Melhores de 2014 - Vícios e manias de quem aprende a programar sozinho -

  4. Pingback: Melhores de 2014 – Vícios e manias de quem aprende a programar sozinho - Reader

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *