Quadro de Tarefas

Se você trabalha na área de tecnologia da informação possivelmente possui ou conhece pessoas que possuem o cargo de Analistas de Sistemas (System Analyst) – pode também ter sido sua formação na graduação. Mais recentemente vemos esta função caindo em desuso e cada vez mais vemos surgir outras denominações, como Scrum Master, Product Owner, Product Manager, Developer, Business Analyst, entre outros. O analista de sistemas está morrendo e você já se perguntou o motivo? Acha que os novos termos são apenas uma hype ou buzzword para dar lugar a quem vende consultoria ou metodologias transformadoras da moda? Trazemos aqui um entendimento sobre o motivo nobre na morte do analista para que você possa buscar seu lugar ao sol e ampliar seu entendimento sobre uma questão muito maior do que estes simples títulos. Na verdade não é sobre morte e sim sobre renascimento de uma forma de trabalho: quem nasceu foi o pensamento sistêmico, que está transformando a atuação deste profissional em algo totalmente diferente do que foi aprendido nas últimas décadas.

Análise de Sistemas e o Pensamento Analítico

Todo analista de sistemas aprendeu nas últimas décadas que seu trabalho consistia em dividir para conquistar, ou seja, o processo de construção de software começava com a quebra do todo em partes que, somadas, resolveriam um problema. Primeiro era feita a elicitação de requisitos, ou seja, um levantamento de tudo que deveria ser feito no software, algo similar ao garçom e ao cliente em um restaurante. Após isso, elaborava-se páginas e páginas de documentação prévia, muitas vezes vista como um entregável por si só (eventualmente até faturável como um entregável). Depois, iniciava-se a análise e projeto, ou seja, elaborava-se diagramas que não necessariamente seriam úteis, mas que descreviam tal qual uma planta de um imóvel as características previstas no software. Então, mão na massa! Desenvolvimento de fato, por meses, às vezes anos. E, por fim, a entrega do produto final para o cliente. Enquanto isso, a gestão do projeto planejava cada etapa com afinco, prevendo o tempo de execução e cadenciando as atividades conforme a precedência entre elas. No final, bastaria compor as partes e entregar o todo. Mas (que surpresa!), ao final o resultado não atendia a necessidade plenamente. O processo seguido à risca; escopo, prazo e custo planejados foram cumpridos; cada parte foi executada perfeitamente seguindo um processo ou método. Como pudemos fazer essa composição e, ainda assim, não entregarmos algo adequado?

Esse formato de trabalho se baseava no pensamento analítico e, por isso, o título Analista de Sistemas. Este modelo de pensamento resolve problemas onde é viável definir uma verdade sobre um assunto a priori. Geralmente, este modelo de pensamento resolve problemas complicados (como uma linha de produção em uma indústria), onde o tipo de problema a ser resolvido tem a característica de possuir uma verdade conhecida e definida desde o início. Por exemplo, para montar um carro deve-se montar as partes e juntá-las. Sabe-se também que neste contexto a forma ideal para fazer um retrovisor é algo procedimental que deve seguir certos passos previamente especificados para garantir a conformidade com o resultado esperado, em menor tempo de confecção e minimizando desperdício (visando maior capacidade de produção e consequentemente maior lucro). Percebe-se que este é um ambiente complicado: causas e efeitos podem ser identificados mas requerem conhecimento especializado para alcançar o melhor resultado. Existe previsibilidade, mas alguém com experiência deve analisar o problema, compará-lo com experiências prévias e situações similares, avaliar boas práticas que levariam ao resultado desejado e elaborar um plano para se chegar ao resultado final. Deste modo, é possível perceber que neste contexto o pensamento analítico resolve o problema pois estrutura-se a priori uma forma de tratá-lo e o melhor resultado (o mais eficiente) é alcançar o resultado previsto.

Podemos resumir então que o pensamento analítico lida com Análise da seguinte forma: Primeiro, divide o objeto de estudo em partes. Depois, entende-se o funcionamento de cada parte em separado. Por último, consolida o entendimento das partes no entendimento do todo. É possível perceber o reflexo do pensamento analítico na gestão através de alguns sinais como metas segmentadas por departamento e/ou individuais, processo prescritivos ou indicação de que toda a organização deve usar um método específico e pasteurizado, uso de cronogramas divididos em atividades, etc.

O “Sintetizador de Sistemas”

Nota-se uma grande diferença do modelo citado acima (de operação) com o modelo que deve ser usado na indústria do conhecimento, onde temos um ambiente complexo, em que as variáveis mudam o tempo todo. Não é possível aplicar relações conhecidas de causa e efeito pois só podem ser conhecidas “a posteriori” – é o mundo imprevisível. Não adianta realizar análises prévias ou buscar especialistas uma vez que não há previsibilidade sobre a solução ideal. As soluções emergem da experimentação e a avaliação sobre o quão adequada elas foram só pode ser feita a posteriori. Por isso alguns métodos citam os ciclos de feedback como ferramenta fundamental, uma vez que é necessário ter ciclos curtos e completos de exploração, análise e solução. Não fazemos mais trabalho de análise e sim um trabalho de síntese. Parte-se do problema a ser resolvido e resolve-se todo o problema, ainda que a primeira forma de resolvê-lo tenha uma forma rudimentar. O problema é quebrado em problemas menores e não em partes, uma vez que o problema deve ser resolvido integralmente.

A melhor maneira de tratar um problema completo (e complexo) é extraindo dele um propósito. A partir daí, deve-se usar ferramentas que permitam compor uma solução (como inception, design thinking, etc). Cria-se então uma solução de baixa resolução, ou seja, apesar de “pouca definição”, é possível “enxergar” o todo, ou resolver o problema completo. Sendo assim, o novo modelo de trabalho da indústria do conhecimento (como o trabalho em TI) precisa de uma dinâmica que encaixa um problema com uma solução.

Assim, o pensamento sistêmico agrega à indústria do conhecimento a capacidade de observar um sistema, ou seja, um organismo, com todas as suas variáveis, dinamismo e integração. Utiliza-se a observação do todo para identificar suas propriedades e comportamentos que afastam ou aproximam do propósito do sistema. É a divergência de propósito sobre o que o sistema faz e o que ele deveria fazer que deve guiar uma solução.

Pensamento Sistêmico

Para entender os novos modelos de gestão e de trabalho no mercado de TI, precisamos ter mais entendimento sobre os sistemas. O que faz o sistema atingir o propósito ou função são as interações entre seus elementos. O comportamento do sistema emerge do próprio sistema – está nas relações e no propósito, não nos elementos, nas pessoas, nos atores dentro dele.

Isso traz um profundo efeito inclusive no modo como pensadores sistêmicos tratam os problemas pois raramente eles culpam pessoas ou medem seus resultados individuais. O fato das pessoas agirem de modo a produzir resultados que ninguém quer, geralmente não é culpa das pessoas (embora haja exceções). A pergunta a ser feita deve ser “o que há de errado com o sistema?” e não “o que há de errado com as pessoas envolvidas no sistema?”. Se algo errado é feito por uma pessoa, deve-se pensar que o evento foi produzido por um comportamento permitido por aquele sistema, ainda que tenha relação direta com as pessoas.

Visão sistêmica é o primeiro passo para a verdadeira gestão, pois começamos a ver como o sistema de trabalho está organizado e paramos de culpar as pessoas. No modelo de pensamento sistêmico, causa e efeito não são mais os conceitos centrais no entendimento do mundo, mas sim padrões, propósito, processo e a mudança permanente. São as interações entre os elementos do sistema que produzem comportamentos, que por sua vez geram eventos detectáveis fora do sistema. O assunto é vasto e pode ser explorado futuramente em outro artigo, mas se você se interessou pelo tema busque pelos trabalhos na área de Systems Thinking da Donella Meadows e não vai se arrepender.

Ainda Precisamos de Conformidade

Obviamente, não se trata de abandonar a forma correta de fazer o trabalho (fazê-lo com eficiência). A indústria do conhecimento ainda espera bons padrões de comportamento e conformidade (clean code, codificação segura, testes, etc), mas tudo isso dentro de um contexto em que exista análise sobre o propósito, ou seja, focado em fazer o trabalho certo (eficácia).

Você vai perceber que não adianta, por exemplo, em uma cadeia de processos, Carla elicitar os requisitos e escrevê-los detalhadamente com o mais perfeito português, João fazer uma análise dentro dos padrões e gerar os melhores e mais completos diagramas de projeto, Adriano fazer a construção nomeando variáveis adequadamente e cumprindo seus casos de teste e Tatiana efetuar a gestão com seu lindo gráfico de Gantt. Isso não significa que o resultado final será bom e atenderá as expectativas ou resolverá o problema do cliente.

Ferramental para Tratar Problemas

Já ouviu falar no Framework Cynefin? Ele pode ajudar a caracterizar o tipo de problema que você está resolvendo e explica um pouco mais sobre o contexto complicado e complexo mencionados neste artigo. Já falamos sobre ele neste artigo.

Em suma, não devemos achar que o pensamento analítico morreu e deve ser substituído pelo pensamento sistêmico. Inclusive você pode continuar dizendo que tem formação em análise de sistemas mas é importante compreender a inadequação do termo no mundo atual. Assim como todo ferramental, framework ou método, estas abordagens de pensamento também endereçam tipos de problemas distintos. Uma não exclui ou é melhor que a outra, mas depende que o profissional entenda o que precisa ser resolvido, o contexto em que se encaixa para, aí sim, definir as ferramentas e o tipo de pensamento que deve guiá-lo rumo à solução.

Deixe uma resposta