Gestão científica de equipes e projetos

Na escola, já aprendemos que o engenheiro estadunidense Frederick Taylor é considerado o pai da administração científica pela invenção do modelo de administração cunhado como taylorismo. Apesar de essa linha de abertura ser demasiado entediante por trazer consigo um breve flashback do sofrimento psicológico para os que, assim como eu, foram alunos de escolas estaduais, relembrá-la é importante. Taylor tem muito o que nos ensinar no que diz respeito ao gerenciamento de equipes de engenharia de software.

Apesar de o livro Princípios da Administração Científica ter sido publicado há mais de um século, trazendo um enorme avanço para a eficiência de empresas do mundo todo, muitos dos gerentes, nos dias atuais, continuam atrasados em mais de um século quanto às suas práticas de gestão de equipes e projetos. Apesar também de a obra citada ter sido escrita com foco na indústria do início do século XX e conter diversas dicas voltadas para a produção industrial que não são aplicáveis à engenharia de software dos dias atuais, ela ensina que devemos estudar nosso trabalho cientificamente.

Se você está com sua memória dos tempos de escola afiada, já deve ter se lembrado de que o modelo de Taylor foi tão bem sucedido no aspecto da produtividade que teve um efeito negativo para a indústria estadunidense com a criação de estoques de produtos que superava a demanda pelos mesmos, o que levou os japoneses a inventarem um modelo mais eficiente no que diz respeito ao equilíbrio entre oferta e demanda, que foi apresentado para nós nas escolas brasileiras como Sistema Toyota de Produção, ou simplesmente Toyotismo. Uma vez que os japoneses introduziram o modelo de administração científica na Toyota, conseguiram, por meio desse processo, evoluir rapidamente e tornaram obsoleto o então modelo de produção mais avançado. Uma das principais conclusões que podemos tirar desse evento e dos que deram sequência é que uma vez que colocamos o nosso trabalho sob o microscópio e uma abordagem científica, somos capazes de alcançar um estado de melhoria contínua. Os japoneses não demoraram para perceber isso após o sucesso do Toyotismo, cunhando então o Kaizen.

Quando o assunto é engenharia de software, devemos nos lembrar de que a engenharia mecânica está presente no mundo desde o século XVIII, naturalmente sendo muito mais avançada e madura em suas práticas do que a engenharia de software. Por isso, devemos olhar com cuidado para esses eventos históricos em torno da engenharia mecânica para que possamos absorver o máximo de aspectos e princípios que possam ser adaptados para a nossa realidade de engenheiros de software. Foi exatamente o que Jeff Sutherland fez com o desenvolvimento do Scrum, que apesar de tratar de diversos aspectos da construção de uma aplicação, aqui iremos abordar apenas o aspecto oferecido por ele no que diz respeito ao estabelecimento de um método científico para a análise do trabalho de sua equipe. O objetivo é entender a importância que esse processo tem para o nosso trabalho e como devemos agir para desfrutar o máximo dele.

Medição dos fatores de sucesso

Toda equipe de engenharia de software possui objetivos e toda vez que nos propomos a executar um projeto, assumimos que seremos então capazes de executá-lo até o fim e entregá-lo no prazo esperado de acordo com todos os requisitos especificados, isto é, se tudo correr bem. A frase “se tudo correr bem” tem uma grande importância para a execução de qualquer tipo de projeto, portanto devemos ser capazes de desenvolver mecanismos para medir e traduzir esse termo para uma linguagem mais científica. Cada projeto tem um conjunto de variáveis distintas que juntas irão definir o que é o famoso “se tudo correr bem” daquele projeto em questão. Seu trabalho como gestor é identificar quais são esses fatores e criar mecanismos para os medir. Fatores relacionados ao sucesso de um projeto que são fáceis de se medir e normalmente medidos podem ser o número de bugs encontrados por período de tempo, quantidade de trabalho realizado em um dado período de tempo e nível de satisfação de clientes e usuários do seu produto. Uma vez que você começar a acompanhar esses tais indicadores, você poderá ver quando eles irão oscilar e então poderá ir para a fase seguinte, que é associação de causas e efeitos. Para um maior aprofundamento nessa atividade, recomendo a verificação do PMC (Project Monitoring and Control), uma process area muito importante do CMMI (Capability Maturity Model Integration) que explora esse conceito ao extremo para as mais variadas necessidades da indústria de desenvolvimento de software.

Uma vez que você identificou os fatores de sucesso mais importantes a serem medidos, irá notar no que diz respeito ao desenvolvimento contínuo que todos esses fatores deverão ser medidos em duas dimensões, sendo uma delas o tempo e a outra a quantificação do fator em si. Isso ocorre, dado que o filósofo alemão Martin Heidegger estava corretíssimo, nós somos seres temporais e portanto no que diz respeito à indústria as coisas não são diferentes. Nós somos bons ou ruins em uma dimensão temporal, logo todos seus indicadores de sucesso devem ser medidos contra o tempo para que você consiga entender se você está melhorando ou piorando com o passar dele e não existe uma melhor forma de medir esses indicadores contra a dimensão temporal do que por meio de sprints, isto é, que eu saiba. Particularmente gosto do conceito de sprints, pois todo o time é envolvido no processo de identificação das causas de oscilação dos indicadores, tornando o processo muito mais eficiente já que iremos reunir diversas perspectivas e promover o debate entre a equipe.

É importante manter em mente que os seus indicadores devem buscar representar a relação direta que a engenharia de software tem com o sucesso do seu negócio, portanto se você acredita que a produção de mais funcionalidades irá ajudar na retenção ou aquisição de consumidores novos, é necessário então que você busque um meio de associar a relação de causa e efeito que seu software tem com seu negócio. Um erro que já cometi foi o de me importar somente com a entrega do produto no prazo especificado, sem muito me importar com o negócio que iria se beneficiar daquele produto. Quando fazemos isso, inevitavelmente o produto entregue dificilmente estará otimizado em seu potencial máximo para o negócio em questão, na verdade, toda otimização aplicada foi feita somente para reduzir o tempo de entrega e ficar dentro do orçamento planejado. Portanto, tenha em mente que indicadores genéricos como número de funcionalidades ou story points entregues por período de tempo são essenciais, mas se você se mantiver preso somente a esses indicadores genéricos, não será capaz de utilizar o método científico para entender a totalidade da relação entre software e o sucesso do seu negócio.

Estabelecendo o método científico

Uma vez que você tem suas medições configuradas e operando, vem então a hora de aplicar o método científico. Sempre que houver uma mudança nos indicadores, você irá junto da sua equipe tentar entender o motivo de determinada mudança. Produzirão então uma tese e, em seguida, tentarão verificar se o resultado é verdadeiro por meio da escolha de um experimento. Essa mudança pode ser para melhor ou para pior, não importa, o que importa é que você e sua equipe estarão utilizando o método científico para entender o que funciona, o que não está funcionando muito bem para vocês e os motivos por trás disso. Essa é a forma reativa de trabalhar com o método científico e esse é um dos mais importantes princípios do desenvolvimento ágil de software: responding to change over following a plan. Você também poderá utilizar o método científico em seu favor de uma maneira mais proativa, isto é, aplicando teses encontradas em literatura e demais meios de comunicação e acompanhando como os indicadores irão reagir a essas mudanças.

Um bom mecanismo para estabelecer a relação entre causa e efeito no que diz respeito aos indicadores de sucesso são as sprint reviews e as sprint retrospectives, cerimônias presentes no Scrum Framework. Ao término de cada sprint, você irá se reunir com sua equipe e juntos irão fazer uma revisão de todo o trabalho realizado, apresentando os objetivos alcançados, as novas funcionalidades e explicando como as coisas se deram durante a sprint. A revisão é uma cerimônia mais informal e normalmente os stakeholders do projeto são convidados para fazer parte da revisão dos trabalhos executados na sprint. Em seguida, você e seu time abandonarão a informalidade da revisão e entrarão na formalidade da retrospectiva, em que vocês irão analisar os indicadores, estabelecer relações entre causa e efeito e desenvolver teses que terão como objetivo tornar a equipe mais produtiva na próxima rodada de trabalho. Uma ferramenta que pode ajudar sua equipe no processo de retrospectiva é o EasyRetro, em que você tem um modelo de board para ser utilizado pela sua equipe. Antes de conhecer o EasyRetro, eu escreveria a opinião de cada um dos membros da equipe em um documento word, por exemplo, e disponibilizaria o documento para todos no fim da cerimônia para que tudo ficasse arquivado caso fosse necessário no futuro ou para consulta na próxima sprint, o que geralmente é necessário.

Conclusões

Aplicar o método científico para gestão de sua equipe não é algo de outro mundo. Apesar de exigir um determinado trabalho para estabelecer indicadores eficientes que incluirão algumas consultas no banco de dados e sincronização com alguma ferramenta para apresentação de gráficos, como algum BI, Google Sheets ou Microsoft Excel, uma vez que esse trabalho for feito, você não irá se preocupar muito com a manutenção de indicadores e irá focar mais no desenvolvimento de teses para tornar sua equipe mais eficiente, o que é fantástico. Embora muitas equipes se coloquem com os pés entre as mãos enquanto tentam estabelecer um determinado processo de gestão, recomendo inicialmente o foco exclusivo no método científico, pois esse em si é mais simples do que implementar o Scrum ou Kanban à risca, por exemplo, e irá lhe permitir identificar de antemão qual metodologia ágil é a mais eficiente para a sua equipe. Além disso, se você mantiver seus indicadores de uma forma transparente para sua equipe, será mais fácil lidar com as opiniões adversas de seus colaboradores, pois sempre que alguém tiver uma ideia nova, as decisões não serão tomadas com base em influência política de um membro de lábia afiada ou então em emoções irracionais. Elas serão tomadas com base na análise fria e calculista dos indicadores que demonstram o que é ou não melhor. Além de um resultado para a gestão de sua equipe a curto prazo, a utilização do método científico irá lhe garantir uma forma robusta de adquirir conhecimento ao longo de sua carreira, tornando-o um gestor mais eficiente e fazendo também com que os membros da sua equipe evoluam constantemente.

Evitando um código-fonte complexo

Criar uma aplicação na qual a execução de rotinas de manutenção é uma tarefa simples e objetiva não é uma atividade das mais fáceis e o problema torna-se ainda maior quando essa aplicação precisa de uma arquitetura escalável onde diversas mudanças no código irão ocorrer quase que de forma constante de acordo com as demandas de mercado. Quando não possuímos experiência no desenvolvimento de aplicações em um paradigma específico, tal como funcional ou orientado a objetos, é normal que nossa aplicação fique com um código-fonte muito limpo e simples durante os estágios iniciais de desenvolvimento, mas conforme novas funcionalidades são adicionadas o código começa a se tornar cada vez mais difícil de entender e consequentemente de se manter. O código-fonte de uma aplicação nasce como uma cidade e cresce da mesma forma, com pessoas diferentes juntas trabalhando para construir coisas ao mesmo tempo, que estarão de uma forma ou outra entre si conectadas. Em uma cidade onde falta um plano de desenvolvimento sustentável é normal que após um tempo a locomoção torne-se inviável ou ao menos difícil, junto também com a modificação das estruturas existentes e adição de novas estruturas, enquanto em uma cidade com um bom planejamento o crescimento não é um inimigo da qualidade de vida.

Definindo o que é um código complexo

Complexidade é tudo aquilo que torna um software difícil de se manter ou adicionar novas funcionalidades. Um software criado para detectar mísseis balísticos que se aproximam do espaço aéreo de um país são complexos devidos à natureza do problema, portanto essa não é a sua inimiga. Quando tratamos de complexidade de software é importante saber diferenciar aquilo que é a complexidade natural do problema e aquilo que é a complexidade adicionada e também a complexidade consequente. A complexidade adicionada ocorre quando são criadas mais estruturas na aplicação para resolver o problema do que aquilo que é necessário, esse tipo de complexidade é fruto do overengineering. A complexidade consequente surge pelo motivo oposto, isto é, quando você precisa fazer determinadas modificações na aplicação que não são suportadas pela sua estrutura, que fora planejada com demasiada simplicidade enquanto uma maior robustez era necessária. Quando uma estrutura é criada de forma demasiada simples é normal que as mudanças subsequentes tornem-se mais complexas do que deveriam a cada novo evento de mudança que ocorre, até chegar ao ponto de que não é mais possível de se manter a aplicação de forma sustentável. Quando o nível de complexidade da sua aplicação está desbalanceado em relação à complexidade natural, seja para mais ou para menos, os seguintes sintomas passam a se tornar recorrente durante suas atividades:

  • Change amplification: quando você precisa fazer alterações em diversos pontos da aplicação para introduzir uma mudança simples. É muito importante que seu código seja coeso, e que os pontos que relacionados uns aos outros estejam próximos e sejam fáceis de ser encontrados por quem quer que seja que esteja realizando a manutenção.
  • Cognitive load: quanto mais conhecimento específico sobre o sistema é necessário para fazer uma mudança mais complexa a aplicação se torna de se manter, por isso é muito importante que os design patterns sejam aplicados sempre que possível, pois esta é uma linguagem universal utilizada por engenheiros de todo o mundo para resolver problemas padrão. Aplique design patterns em tudo onde for plausível e limite-se à receitas secretas de família somente onde for necessário.
  • Unknown unknowns: geralmente você precisa saber de algumas coisas para realizar a manutenção de uma aplicação, e este fenômeno ocorre quando você sequer sabe que coisas são essas que você precisa saber. Um software precisa ser dedutível, capaz de facilmente ser analisado através da engenharia reversa. Quando mais fácil for realizar engenharia reversa do seu código, melhor, e isso inclui material de apoio e documentação, entretanto esforce-se para que seu código seja tão fácil de ser compreendido que materiais de apoio se tornarão desnecessários. Um bom material de apoio para desenvolver-se nesse sentido é o livro Clean Code.

E por fim, a complexidade de um código-fonte não é determinada pelo autor do código, mas sim pelo leitor, portanto a opinião de quem escreve um código não é muito relevante, pois seja la qual foi o erro cometido pelo autor ele ao menos tem a informação necessária para navegar em seus próprios erros, enquanto um leitor descontextualizado precisa aprender tudo que o autor já sabe de antemão.

É muito difícil acertar a arquitetura de primeira

O primeiro passo para construção de uma aplicação com uma boa arquitetura é entender que se você está lidando com um problema pela primeira vez há uma grande chance de você não acertar de primeira. Se você está desenvolvendo uma aplicação para cobrança de dívidas por exemplo e essa é sua primeira vez com uma aplicação do gênero você irá obter determinadas informações por parte do seu cliente ou chefe com as especificações do problema, mas assim que a aplicação entrar em produção e os usuários começarem a testar as funcionalidades você irá descobrir coisas novas junto do seu product owner que ambos não esperavam. É uma tendência natural que um sistema de informação irá replicar as estruturas de relacionamento humanas existentes entre seus usuários e essas estruturas humanas são complexas de se presumir pois elas surgem das mais variadas formas e pelos mais variados motivos. Imagine que você irá emitir cobranças e existe uma taxa de juros que é praticada para determinados seguimentos, mas para uma loja específica existe um contrato diferente, pois o dono da empresa que está a contratar seu serviço também é sócio da outra empresa a ser cobrada. Essa é uma estrutura de relacionamento hipotética, mas elas podem vir a existir pelos mais variados motivos e você precisará de um determinado tempo de profissão para aprender quais são as possíveis formas de se fazer negócio na área que você está atuando, portanto, esteja preparado para jogar código-fonte fora e trabalhar duro na reescrita de módulos a camadas da sua aplicação sempre que necessário para evitar que as coisas cresçam de forma descontrolada.

Agilidade é mais importante que velocidade

Nem tudo que é veloz é necessariamente ágil, um exemplo grotesco é o foguete que leva os astronautas à estação espacial internacional, ele é extremamente veloz, mas não é mais ágil do que uma bicicleta. Sua velocidade é determinada pelo tempo que você leva para chegar de um ponto ao outro, enquanto sua agilidade é determinada pelo tempo que você leva para se ajustar à uma mudança no seu trajeto de forma que poderá desenvolver sua velocidade máxima no menor espaço de tempo possível novamente. Sempre que os objetivos dos seus usuários mudam seu software também necessitará mudança e quanto menos ágil você e seu time forem maiores serão as chances de que vocês irão precisar implementar uma solução inadequada. Uma equipe ágil busca sempre se antecipar aos problemas mantendo-se atenta ao que está acontecendo no mercado no qual ela está inserida, no seu contexto corporativo, na demografia dos seus usuários e assim por diante. Quanto mais ágil sua equipe se tornar vocês poderão responder com maior precisão e força às mudanças necessárias. Lembre-se que a agilidade não se refere só ao caso de ser ágil em reescrever o código, mas também se refere à agilidade com a qual sua equipe é capaz de assimilar o problema, planejar a alteração necessária e realizar a execução. Normalmente equipes que não desenvolvem agilidade de assimilação e planejamento costumam pular essas etapas, o que contribui para a evolução da complexidade do código fonte.

Testes unitários são mais do que necessários

Além de garantir a que as coisas estão funcionando, quando bem escritos os testes unitários irão também atuar como uma documentação das funcionalidades do seu sistema, explicando como as coisas deveriam e não funcionar. Embora eles não sejam muito eficientes para explicar o motivo de as coisas serem daquela forma, uma tarefa para a engenharia de requisitos, eles são ótimos para descrever o estado atual das coisas. Os testes unitários irão ajudar você a descobrir informações necessárias sobre o funcionamento do sistema, evitando os unknown unknowns, e também irá te ajudar a ter uma noção científica a respeito do nível de change amplification do seu software. Além disso os testes unitários evitam a complexidade consequente, fruto do processo da criação de estruturas simplistas demais, uma vez que para escrever software possível de ser testado é necessário que determinados padrões de engenharia sejam seguidos.

Modularize seu sistema

Do ponto de vista do leitor, você acha que é mais fácil adquirir o conhecimento que você procura em uma livraria onde tudo é catalogado e devidamente categorizado ou em uma onde os livros estão aleatoriamente dispostos nas prateleiras? Com certeza é mais fácil para quem está colocando os livros no lugar não se importar em colocar no lugar certo, mas para quem precisa se servir do acervo encontrar a informação que deseja se torna um processo doloroso. Quando o assunto é software as coisas não são diferentes, por isso inclusive utilizamos o termo library para nos referir à uma coleção de códigos.

Além de deixar o seu código mais organizado em categorias e subcategorias a modularização irá lhe proporcionar um efeito chamado information hiding, que é quando classes e módulos tratam de problemas específicos de forma centralizada não fazendo com que outras partes do seu código precisem ter essa informação, para não confundir as coisas é importante ter em mente que a obscuridade surge quando você não consegue encontrar uma informação que busca, enquanto information hiding tem como objetivo esconder as informações desnecessárias de estarem presentes em um determinado trecho de código.

Imagine que você está indo para o módulo de cadastro de usuário de uma aplicação, naquele módulo você está procurando detalhes referentes somente ao cadastro dos usuários, não quer saber de outros detalhes tais como taxas de comissão, regras de autenticação e assim por diante. Esses outros devem estar centralizados em seus módulos específicos. A modularização torna-se muito eficiente nesse sentido quando você está desenvolvendo um sistema que cuida de diversas áreas de processos dentro uma mesma empresa e você divide seus módulos baseando-se em nessas áreas, assim sua regra de negócio ficará organizada na aplicação de forma coerente. Além disso, David Parnas têm um artigo muito bom onde ele busca definir os critérios para modularização de uma aplicação com o objetivo de aumento de produtividade. Apesar de o artigo ter sido publicado na década de 70 este continua ainda muito atual.

Evite classes muito pequenas ou extensas

Quanto maior for uma classes mais informações ela irá esconder que outras classes não precisam saber, possuir classes com diversos métodos não é algo necessariamente ruim, entretanto como uma regra geral é importante que suas classes não possuam mais do que duas mil linhas ao mesma tempo que não devem possuir menos de duzentas linhas. Quando uma classe é demasiadamente grande é muito difícil gerenciar a sua complexidade e quando ela é muito pequena seu código está provavelmente distribuído de uma forma demasiadamente granular, o que por sua vez irá aumentar a obscuridade da sua aplicação. Encontrar um bom balanceamento do que deve estar escondido em suas classes e módulos é uma tarefa que exige um bom julgamento do desenvolvedor e difícil de por em um padrão, mas uma vez que você tem em mente qual objetivo busca-se alcançar com esse princípio então você estará pronto para fazer o julgamento.

Voto impresso e cédula de voto são coisas diferentes

Quando o assunto é eleição os Estados Unidos não são um dos países mais modernos, ao menos de forma uniforme entre os seus estados. Muitos estados ainda utilizam cédulas de papel para registro dos votos permitindo até que estes sejam enviados por correios e isso levou o atual presidente Donald Trump à fazer alegações de que votos registrados dessa forma não haviam sido devidamente autenticados e por conta disso não deveriam ter sido registrados. A direita do Brasil que apoia o candidato republicano naturalmente embarcou nessa onda, alegando que o processo eleitoral foi fraudado e pedindo recontagem dos votos.

Embora a direita brasileira não exale inteligência e tem se mostrado bem mediocre por esses dias ainda é muito difícil tomar o monopólio da burrice da esquerda marxista, que já vem dominando nesse quesito por mais de um século com fracasso seguido de fracasso em diversas áreas, tais como cultura, filosofia, direito e principalmente economia. Não importa o quanto a direita brasileira tente ser burra, a esquerda sempre irá superar, e agora a nova moda é fazer piada a respeito da direita ter feito alegações supostamente hipócritas de fraude no sistema eleitoral americano, que usa cédulas de papel em alguns estados, por conta da direita ter exigido o voto impresso nas últimas eleições nacionais.

Primeiramente, gostaria de deixar claro que imprimir o voto não é o mesmo que votar por cédulas de papel. Por mais claro que isso pareça para mim, aparentemente isto ainda não está claro para todas as pessoas, o que infelizmente mostra que as pesquisas que apontam a taxa de analfabetismo funcional no Brasil como próxima à 29% estão corretas. Já que cerca de 60 milhões de pessoas no Brasil não entendem o que estão lendo, devemos explicar as coisas com muito cuidado e também re-explicar quando necessário. Sendo assim, cédula impressa de voto é aquela que substitui a urna eletrônica, enquanto voto impresso funciona como um recibo que confirma o candidato no qual você votou, registrando seu voto tanto na forma eletrônica como também na forma física.

Quando o assunto é segurança da informação existe uma área chamada autenticação. Autenticação é um termo que vem do grego authentes, que significa autor. Um processo de autenticação busca determinar se um indivíduo é realmente o autor de um dado ato. Um conhecido mecanismo de autenticação por todos os brasileiros é o cartório. Os cartórios possuem fé pública, o que significa que o estado em nome da população brasileira confia no juízo emitido pelo cartório de que um documento realmente foi assinado por um indivíduo. Sendo assim, além de contar com a sua assinatura o documento irá também contar com um outro fator de autenticação que é o reconhecimento do cartório.

Como todo processo de autenticação seja por físico ou eletrônico possui vulnerabilidades, faz-se necessário que mais fatores sejam adicionados para aumentar a segurança daquele processo, e quanto mais importante a informação, mais fatores normalmente são adicionados tal como a assinatura sendo um fator e a autenticação do cartório sendo outro. Além disso, você também já deve estar familiarizado com múltiplos fatores de autenticação eletrônicos para acessar seu e-mail ou conta no Facebook por exemplo, onde além do seu usuário e senha também é necessário confirmar um número recebido por SMS ou um número gerado de forma pseudo-randômica pelo seu aparelho celular.

Dito isso, a impressão do voto não visa substituir a urna eletrônica, mas sim adicionar mais um fator de segurança à ela. Recentemente o governo brasileiro implementou a biometria por impressão digital no processo eleitoral para tentar evitar que um eleitor se passe por outro, o problema é que a biometria não garante que o governo não está mentindo para a população a respeito do processo eleitoral, isto é, a população não tem como fiscalizar de forma efetiva os votos contabilizados. Se após registrar o voto na urna eletrônica, uma cédula for impressa para o eleitor a inserir em uma urna para cédulas de papel, o processo eleitoral então poderá ser verificado de uma outra forma, que visa determinar se os votos foram de fato contabilizados de forma autêntica ou não.

Espero que esse texto ajude algumas pessoas a entenderem a diferença entre o voto impresso proposto pelos eleitores brasileiros e a cédula de papel utilizada nos Estados Unidos.

Simples receita para melhorar a segurança da suas aplicações web, e acessível

Segurança da informação é sempre um tópico sensível, principalmente para micro, pequenos e médios negócios. Devido à falta de pessoas qualificadas no mercado e por conta da complexidade natural do assunto, quem entende, cobra caro. A coisa também não é diferente quando estamos tratando de ferramentas de segurança. Se profissionais apenas de segurança são escassos, aqueles que entendem de segurança e também de engenharia de software ao mesmo tempo são mais escassos ainda, e isso naturalmente acaba fazendo com que o custo de produção de ferramentas de segurança da informação seja algo relativamente custoso. E para piorar (ou melhorar) a história, além da responsabilidade que uma empresa possui de proteger os dados de seus clientes e os impactos negativos que uma invasão podem causar, o risco aumentou mais ainda com a introdução da lei geral de proteção de dados, que estipula multas para empresas e pode gerar até prisão para quem lida com a segurança de informação de seus usuários de maneira irresponsável.

Dado o cenário atual, os empresários precisam fazer uma escolha de como este irão abordar o problema de segurança. Muitos preferem o caminho da ganância e irresponsabilidade, apostando que tudo irá sempre correr bem, sem saber ao certo qual o seu nível de exposição e pior ainda, sem considerar como sua irresponsabilidade pode afetar a vida das pessoas envolvidas. Outros entretanto são responsáveis, entendem muito bem os impactos da questão, mas entretanto estão desamparados pois simplesmente não conseguem arcar com os custos de construir um programa de segurança da informação completo, com auxílio de consultorias e profissionais especializados. Se você se enquadra no perfil da segunda afirmação, foi exatamente para você que eu resolvi escrever esse texto de apoio, pois apesar de cada empresa ser um mundo à parte existem problemas de segurança que são genéricos, e nos podemos começar a resolvê-los desde já.

Modelagem de ameaças

O primeiro passo para o desenvolvimento de um programa de segurança, mesmo que genérico, é entender qual é o perfil daqueles que posam como uma ameaça para a sua empresa. Apesar de bancos, militares e organizações políticas serem os alvos prediletos dos APTs isso não quer dizer que sua empresa não possui ninguém de olho nela por não fazer parte desses setores. O desenvolvimento das atividades normais da sua empresa são incentivo suficiente para motivar um ataque, como concorrer com outra empresa, demitir e contratar funcionários, ou até mesmo ter como cliente alguma pessoa ou organização importante que também pode tornar-se um alvo por conta dos mais variados motivos. Sendo assim é importante que você dedique um tempo à pratica de modelagem de ameaças para entender bem quais são os setores da sua empresa que possuem a maior relação de risco versus probabilidade quanto o assunto é um ataque. Esse primeiro passo irá permitir que você foque no que é importante, permitindo obter uma alta efetividade em segurança com o possível baixo investimento. E lembre-se: a lei geral de proteção de dados deve ser incondicionalmente levada em consideração durante essa análise.

Um exemplo muito didático é o das Forças Armadas do Brasil em comparação com as Forças de Defesa de Israel. Enquanto o território do Brasil é de um tamanho absurdo, de topologia difícil de se navegar e separado por mar de todos os países que possuem poder militar suficiente para representar um risco frente ao poder brasileiro, as forças armadas podem dar-se ao luxo de desenvolver um programa mais relaxado, focado em tipos de ameaças específicas. Já em Israel a história é muito diferente, pois rodeados de nações hostis e não possuindo um grande território, o mínimo descuido pode ocasionar em uma completa conquista do país por forças estrangeiras, sendo assim o investimento que eles fazem em defesa é muito maior, exigindo que o serviço militar seja obrigatório até para as mulheres, e operando quase que constantemente próximos de cem porcento de sua capacidade militar. Tendo isso em mente, você precisa entender em qual parte desse espectro você está e quais são os riscos que você pode se dar ao luxo de correr para manter o equilíbrio orçamentário de sua empresa.

Web Application Firewall

Um web application firewall é basicamente um sistema de defesa que fica entre à sua aplicação e a internet. Todo o contato que seus usuários possuem com a sua aplicação serão interceptados pelo firewall, que irá decidir quais ele irá bloquear ou não baseado em regras de detecção de ataques. WAFs como CloudFlare são completamente genéricos, fáceis de usar e podem ser instalados em qualquer aplicação web tendo um custo muito baixo. Custando atualmente a partir de vinte dólares por mês, R$ 115,00 na cotação atual, essa é uma solução acessível para quase todas as empresas eu iria dizer, além do mais que não é necessário contratar um profissional especializado em segurança para realizar o setup desse produto, pois a documentação que eles disponibilizam permite que qualquer pessoa com conhecimentos básicos de servidores web e configuração de domínios faça sua configuração e instalação.

Os WAFs irão tornar sua aplicação segura contra a maioria dos tipos de ameaças eu diria, mesmo que sua aplicação possua vulnerabilidades de segurança ele tentará identificar e barrar qualquer exploração dessas vulnerabilidades, entretanto tipos de ameaças que possuem conhecimento mais avançado podem ainda burlar os WAFs para que esses não detectem seus ataques a partir de técnicas evasivas. Essas tais técnicas evasivas irão fazer com que o WAF pense que a requisição é legítima e não irá bloquear ela. Aqui está uma lista com técnicas evasivas, e pessoalmente dizendo, eu conheço muito mais técnicas do que as que estão presente nessa lista, e um dos grandes problemas dos WAFs é que uma vez que você conseguiu burlar eles e estabelecer uma comunicação cifrada com um backdoor instalado em sua aplicação eles tornam-se inúteis, sendo incapazes de reconhecer e decodificar até sistemas criptográficos de chave pública, como base 64 por exemplo. Em outras palavras, eles não são muito bons contra ameaças internas à sua aplicação, mas lembre-se, os WAFs ainda são eficientes contra a maioria dos tipos de ataques e mesmo ameaças avançadas são incapazes de burlar a maioria das regras dos WAFs quando essas estão externas à sua organização.

Treinamento em desenvolvimento seguro

Caso você acredite que poderá estar na mira de algum tipo de inimigo mais avançado, então está na hora de aprender a identificar e corrigir vulnerabilidades de segurança, e o verbo aprender está diretamente ligado à pagar cursos para que seus desenvolvedores aprendam a lidar com os problemas mais comuns de segurança de aplicações web, como os listados no projeto OWASP Top 10. Felizmente o pessoal do projeto é muito generoso e no website deles você pode encontrar muitos materiais que ensinam a respeito de desenvolvimento seguro, mas esses não são muito fáceis ou didáticos. Em compensação, empresa como a Udemy permitem que cursos como este, que são muito mais didáticos e voltados ao ensino do que os documentos da OWASP tornem-se acessíveis. Investir no seus funcionários nesse caso torna-se barato e os benefícios serão muito bons para ambos os lados, pois o funcionário irá expandir seu leque de conhecimentos enquanto a sua empresa irá tornar-se mais segura, podendo também expandir suas operações com mais tranquilidade e menor risco. No topo de tudo isso eu também gosto de lembrar que não ir para a cadeia é um dos grandes motivadores para manter-se de acordo com a LGPD, ainda mais se assim como eu você não possuir diploma de ensino superior e tiver que aguardar seu julgamento em cela comum.

Ferramentas de análise estática de código-fonte

Quando você treinar seus funcionários eu garanto que eles irão ser capazes de identificar diversas vulnerabilidades em seu sistema e corrigir a maioria delas, entretanto não pense que isso irá resolver todos seus problemas. Apesar de ser essencial treinar seus funcionários, esses ainda não serão capazes de identificar todos os problemas de segurança existente em seu código, até pelo fato de que muitas vulnerabilidades são descobertas em linguagens de programação com o passar do tempo, e também porque olhar para o código tendo em mente os problemas de negócio já é difícil o suficiente, levar em conta segurança ao mesmo tempo e todas a formas possíveis de exploração se torna humanamente impossível eu diria, se você quer ter um bom output produtivo. Nesse caso você pode contar com ferramentas que irão analisar o código de sua aplicação de forma automática, que irão gerar relatórios mostrando todos os pontos vulneráveis da sua aplicação e provendo material de apoio para que seus funcionários consigam corrigir os problemas. Essas ferramentas possuem seu preço liberado somente mediante consulta, mas como um insider eu antecipo que o custo gira em torno ao de um ou dois salários mínimos nos planos iniciais, que normalmente cobrem com folga as necessidades de micro, pequenos e médios negócios. A empresa que possui o melhor custo benefício é a RIPS. Eles estão na Alemanha, e você irá precisar desenrolar o inglês para entrar em contato com eles e solicitar o atendimento de um consultor na América Latina, se você não mencionar que está na América Latina eles normalmente irão te cobrar um valor mais caro, voltado ao mercado europeu.

Além das ferramentas de análise estática de código-fonte, você poderá também contar com as ferramentas de análises de dependências, pois grande parte das vulnerabilidades da sua aplicação estão relacionadas à bibliotecas ou plugins que você utiliza em seu sistema. Sendo assim, você pode contar com ferramentas como a fornecida pela empresa Snyk por exemplo, que cria até pull requests automáticas corrigindo as vulnerabilidades encontradas em seu sistema. Essa ferramenta, levando em conta a cotação atual do dólar, irá custar algo em torno de três ou quatro salários mínimos para empresas que possuem até dez desenvolvedores, porque claro, seu valor está voltado para outros mercados.

Agora cabe à você escolher a partir da sua modelagem de ameaças qual a solução que possui o melhor custo-benefício para sua empresa, e se caso você tenha a condição orçamentária de implementar todas as sugestões dessa postagem, você já estará à frente da grande maioria das empresas que atuam no mercado brasileiro por uma boa margem, falando por experiência própria.

[]´s

Um ano de Suécia

Na primeira vez em que vim para a Suécia foi em outubro do ano passado para uma entrevista de emprego na Klarna – a maior fintech de todo o continente europeu nos dias atuais. Quando desci do avião confesso que me apaixonei pelo lugar. O clima e a tranquilidade de Estocolmo são realmente uma terapia para os que buscam fugir do dinamismo e hiperatividade das cidades brasileiras. Por aqui a capital possui ares de hotel fazenda para os que estão habituados com São Paulo – um atrativo e tanto para mim. Já na Klarna durante as entrevistas eu entendi que além da marca deixada no currículo eu também teria a oportunidade de aprender muito trabalhando em um ambiente internacional, tanto por estar ao lado de pessoas fantásticas no dia-a-dia tal como por sair da zona de conforto e se atirar em uma experiência completamente nova. Quando recebi enfim uma oferta de trabalho formal não hesitei na hora de assinar, apesar do peso no coração por conta do distanciamento das pessoas queridas eu sabia que eu nunca iria me perdoar se eu abrisse mão de um sonho de longa data como o da vida no exterior.

Em Janeiro me mudei para cá e assim como muitos brasileiros em minha posição senti o peso da distância das pessoas queridas e do escuro do inverno escandinavo, o clima que no início foi um atrativo durante a visita no outono não foi tão agradável no inverno, onde o sol se põe por volta das quatro da tarde e nasce somente em torno das nove da manhã. Apesar da alegria da estar vivendo uma experiência que a maioria das pessoas não tem oportunidade, os primeiros meses de adaptação foram muito difíceis, ainda mais por conta do fato que nós brasileiros somos um dos povos mais receptivos e abertos do mundo, o que faz com que as chances de ir para um país de melhor receptividade seja muito baixa. O estilo de vida mais fechado dos europeus exige de nós que usemos o máximo de simpatia, empatia e paciência para fazer amigos por aqui, mas assim que se torna amigo de um sueco provavelmente será um amigo para toda a vida. Uma coisa que aprendi é que muitas pessoas por aqui mudam-se por conta do trabalho assim como eu, o que faz com que seja muito fácil de se conhecer pessoas de outros cantos do mundo como França, Alemanha, Rússia, Estados Unidos, Austrália, Itália, Brasil e assim por diante, pois elas estão mais abertas. Os suecos no entanto são um pouco mais inacessíveis, pois já possuem seus círculos de amigos e família definidos.

No trabalho uma das grandes lições que tive foi em relação ao pragmatismo sueco, eu sendo quase que um romântico em relação ao trabalho que faço aprendi uma nova abordagem para fazer as coisas, o equilíbrio, ou melhor, o lagom. Por conta de marcas famosas como Volvo, Saab, Scania, Ikea, e Ericson você deve saber que os suecos são muito preocupados com qualidade e experiência do usuário, mas de uma forma bem diferente da qual as referências mundiais em qualidade como japoneses e alemães abordam o problema. Por aqui a palavra da vez é equilíbrio, e o nível de custo a ser adicionado à um projeto por conta da qualidade deve ser exatamente o essencial, e quando eu digo exatamente eu digo que você precisa estudar e aprender exatamente qual exatamente o nível exato de qualidade que o seu projeto precisa para evitar desperdícios. Essa cultura pode ser visualizada em diversas áreas da vida na Suécia, por aqui não existem catedrais extravagantes, as pessoas normalmente vêem com maus olhos qualquer forma de ostentação e a administração pública é extremamente eficiente em garantir os serviços essenciais. Por aqui as terras não são férteis, tampouco existem boas rotas de comércio que passam pela Suécia, estamos literalmente em um pedaço de terra perdido ao norte do planeta onde tudo costumava ser muito difícil anos atrás. A fauna é limitada assim como a flora, fazendo com que a escassez de recursos torna-se os povos escandinavos verdadeiros mestres da administração.

Outra coisa que tenho aprendido melhor por aqui é o uso do relógio, essa magnífica ferramenta. Assim como os suecos administram muito bem seus recursos materiais eles também administram seu tempo e seu esforço da mesma maneira. Por aqui se trabalha menos horas que no Brasil, as férias são mais generosas e a cultura de trabalho é mais voltada para resultados do que para o tempo gasto no escritório. Se por conta de emergências você precisar atender um chamado fora de horário de trabalho você irá receber uma sexta-feira de folga como compensação pelo distúrbio, além do adicional de horas extra. Por aqui a vida pessoal é levada muito a sério e não se tolera gastar mais tempo no trabalho do que aquilo que é exatamente necessário para atingir os objetivos estipulados. Não há muita tolerância para atrasos e falta de pontualidade. Os suecos são também muitíssimo dedicados à suas vidas em família e gostam de dedicar uma boa parte do seu dia para atividades com os filhos, o cônjuge e hobbies. Por aqui eles fazem de tudo para trabalhar para viver ao invés de viver para trabalhar. No Brasil ainda somos ineficientes no gerenciamento do nosso tempo e recursos, o que faz com que o exato oposto se apresente em nossas vidas onde tempo livre é raríssimo.

Além dos aprendizados relacionados à vida profissional e social a vida no exterior tem me ensinado muito sobre a minha pessoa e sobre o nosso país. Vivendo em outra cultura te permite ter uma visão mais precisa do que significa ser brasileiro e no que somos diferente do povo com o qual o nosso está sendo comparado. Muito daquilo que eu acreditava ser natural ao ser humano na verdade não é, e muito daquilo que eu achava ser minha personalidade não tem nada de personalizado, mas sim é uma herança cultural do nosso povo. Além dos ritos culturais, por assim dizer, também aprendi o quanto a língua portuguesa está ligada à minha personalidade e o quanto dela não se é possível mostrar quando estou me comunicando em outro idioma. As palavras, a forma gramatical e as expressões existentes em outras línguas são construções culturais atreladas à um povo específico, portanto assim não é possível ser brasileiro em inglês, tampouco em sueco, de forma plena. Em outros idiomas somos capazes de transmitir com eficiência apenas alguns traços genéricos de nossa personalidade, mas torna-se impossível ou quase de dar mais informações sobre a sua pessoa quando estas estão diretamente associadas à sua cultura e a história do seu povo e expressas unicamente em sua língua nativa, pois todo o contexto que carregamos em nossa comunicação diária precisa ser transmitido à eles.

Apesar das diferenças, por aqui continuarei aprendendo e evoluindo até quando o coração me convidar a voltar para casa, pois apesar do país ser muito menor que o nosso, ainda há muito para explorar e absorver por aqui. Minha intenção a partir de agora é de documentar e também compartilhar ao máximo os meus aprendizados para que isso sirva de inspiração ou orientação para pessoas que visam uma vida no exterior.

[]’s