Blog do Andre Fonseca

A pouco tempo consegui um brecha com ajuda da minha colega Arlene para implantarmos no projeto que estou trabalhando teste automatizados.  Com a carta de alforria em mãos partimos para pesquisar no mercado qual seria a melhor que se encaixaria em nosso contexto de aplicação.  Para que entenda,  trabalhamos com desenvolvimento de portal usando a ferramenta Lumis (eu trabalho na Lumis!!!).  Portais são aplicações bastante difíceis de serem testadas de forma automática; devido a questão do conteúdo dinâmico e pouco previsível não existe muita margem para que busque por padrões.

Com estas limitações em mãos, acabamos nos deparando com a api WebDriver . A um tempo atrás eu já tinha mexido um pouco com o selenium e adorei. Com isso, tentei achar algo que se assemelhasse a ele mas que me facilitasse a vida em relação a portais ( não tem muito como usar ids dos elementos no html, url não fixas, etc) . O webdriver, ao contrário do selenium, não é um javascript que executa dentro de uma página simulando a navegação… o webdriver é realmente um “envelope” em cima do seu navegador.  No caso do Firefox ele é uma extensão, no caso do Internet Explorer (blargh) ele usa as chamadas de control que ele proporciona, e por ai vai. Com isso, os teste ficam mais próximos da realidade de uso do usuário, e a api para escrever  os cenários mais simples.  Veja o trecho:

Pelo exemplo acima fica fácil de ver o quão fácil é criar um teste em webdriver.  Recomendo experimentar

Jack Milusnk, em seu blog The Agile Buddy Blog, escreveu um excelente post sobre a questão da histórica técnica. Em tomei a liberdade de escrever uma versão (não tradução) em português do texto. Para quem quiser ler o texto original, acesso o post aqui. Comentários com ajuda na tradução e opiniões são bem vindo.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>

A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog.

Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:

“O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”

Então, qual é a resposta correta?

Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.

Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:

Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

Se você ainda não é um membro do grupo de desenvolvimento SCrum do yahoo, você deve considerar se juntar rapidamente. Existe, no fórum, uma verdadeira fortuna de informação que a todo tempo muda de mão e, você pode muito nas interação que acontecem ali. Inclusive, recentemente  houve um intenso e caloroso debate sobre a questão das histórias “técnicas” (talvez aqui fosse melhor o termo – backlog técnico;<em>technical stories</em>A questão acima foi se um débito técnico deveria ou não aparecer no backlog do time. Se eles aparecem no backlog, significa que coisas técnicas podem ser priorizadas pelo P.O. (product owner – dono do produto). Isto não parecer ser uma boa ideia pois, o PO, na maioria dos casos, irá dar mais valor para as funcionalidades e <em>features</em> do sistema dele em detrimento a parte técnica. Um exemplo disso, histórias técnicas, seria : “Instalar o Cruise Control”; alterar o banco de dados de MySQL para Oracle, configuração do VMWare etc. A maioria dos grandes pensadores e formadores de opinião do fórum, argumentaram que histórias técnicas de forma alguma deveriam aparecer no backlog. Mas tudo que precisa de recurso de desenvolvimento deveriam aparecer no backlog. Se der uma olhada na definição vind do guia do Scrum (scrum guide no scrum.orgs), encontrará o seguinte:”O backlog do sprint consiste nas tarefas que o time deve realizar para incrementar o backolog do produto na direção do status pronto… Isto é, todo o trabalho que o time identifica como necessário para atingir o objetivo do sprint.”Então, qual é a resposta correta? Minha resposta é que depende… depende do contexto. Por exemplo, se a definição de pronto leva em conta ter testes unitários, testes de aceitação automatizados, etc, então estes itens não precisam estar explicitamente identificados no backlog. Isto é, coisas que são feitas pelo time e não existe negociação. Assim, as estimativas precisam incluir o tempo necessário para completar todos estes elementos que fazem parte do conceito de pronto.Naquelas situações, onde um dos membros sugere – “Como membro da equipe de desenvolvimento, eu quero que os testes unitários existentes devem ser executados pelo Cruise Control ( integração contínua) de modo que eu sei quando algo quebra”. Bem, esta é uma história bem escrita e que define bem a necessidade, mas ela não tem nenhum valor final para o usuário (PO), pelo menos não diretamente. Neste caso específico, eu sugiro o seguinte:Este tipo de história, definitivamente, não pertence ao backlog do produto, mas pode ser uma tarefa que existiria no backlog do sprint. Alguns amantes de XP poderiam dizer que não faz sentido por trabalharem sempre no nível de histórias, para o planejamento, enquanto que o Scrum fala mais em tarefas.  Se o time estiver trabalhando com tarefas, este tipo de atividade – histórias técnicas – devem aparecer no backlog e ter o esforço estimado. A maioria das pessoas de XP vão dizer que é isso é micro-gestão.

E dando seguimento a serie sobre algumas coisas interessantes sobre o desenvolvimento, vamos para mais um novo capítulo.  [OFF] São tantas histórias vou acabar escrevendo um romance [/OFF].   Após a repercussão do primeiro artigo de mesmo nome, alguns conhecidos me procuraram para dizer que, existiam outras situações que poderia abordar dentro da série.  Uma dessas situações foi sobre estruturas de equipes de desenvolvimento e  com isso, acabei  me lembrando de uma época,  numa dada empresa, em que tínhamos a figura do revisor de códigos. É isso mesmo que você leu, meu amigo …revisor de código.

O revisor de código é o cara que após você ter implementado toda  a solução, antes de você colocar as sua alterações no CVS  (meu deus, antigo), ele vem e verifica se o seu código está bom, onde bom, significa dentro de um padrão que não está em lugar que não na cabeça dele.  Antes que me apedrejem em praça pública,  sei que nem todos são assim, e que em muitos tinha ou tem, regras de estilo bem claras e até automatizadas através de plugins em suas IDEs.

Revisar o código não é uma atividade ruim. Ter premissas de estilo e formatação é algo interessante pois padroniza e pode facilitar qualquer pessoa, que esteja acostumado com os padrões da empresa, ler o fonte e entender.  Essa preocupação, inclusive,  tem sido tema de discussões muito atuais e serve até de argumento para definir o uso ou não de linguagens ( sendo mais específico, são questões como expressividade, legibilidade, etc – suggar sintaxe) . A questão que eu coloco é isso passar o limite do bom senso e do razoável e se tornar uma ditadura sem direito de questionamento.

A própria situação de ter uma única pessoa responsável por zelar pela qualidade do código para mim já é algo péssimo.

Mas então? Qual é o melhor cenário?  O que pode ser feito, já que eu disse que qualidade e estilo são bons, se ter alguém revisando é péssimo?

Alguém aí, por acaso, disse … Programação em par!?!?!? Bingo!!!   Essa, no meu entender, é um bom caminho.  É bom, pois permite a troca, a interação. É bom, pois permite, que a responsabilidade seja de todos e não somente de uma única pessoa. Tira gargalos ( quem nunca ficou parada esperando o revisor ter tempo para ver e validar a implementação).  O time como um todo decide o que é melhor.

Nesse cenário as chances das coisas serem menos impostas e mais consenso são grandes. Não existe um ponto único e sim diversidade de visões.  O time fica aberto e sempre como abertura para melhorar ou experimentar, desde que todos concordem ou pelo menos seu par, que aquilo traz algum valor.

Observem – bem lembrado por um colega – que nem toquei no fato de revisão de tecnologia, arquitetura.  Na velhas e empoeiradas estruturas de fábrica,  tem casos em que além do revisor, tem ainda o grande e todo poderoso arquiteto que decide quais tabelas, quantas classes, como as classes são, qual linguagem, api, framework, qual papel higiênico, que  todos devem usar.  Para mim isso consegue ser pior que o revisor. Pois ele tolhe a inovação, o salto para frente.  não quero dizer com isso, que devemos fazer de nossos projetos um laboratório de novas linguagens e etc… estou dizendo que se existe algo que venha a facilitar porque não pelo menos olhar o que é …

Novamente transferir essa “responsabilidade ” para o time é a melhor coisa.  Pois se discute. Todos tem voz.  A chance de escolher algo interessante é maior… não fica a cargo de um louco que pode ser um tarado por novidades ou um louco que nunca deixará de usar Java 1.3.1 pois sempre funcionou e “não se mexe em time que está ganhando”.

Bem esse era meu recado… aguardo as opiniões de vocês.

Mais uma vez, devido a uma outra troca de e-mails,  vi um outro assunto super legal que gostaria de dividir com vocês.  A um certo tempo atrás, no blog do Calcado, li um artigo sobre o fato de objetos não serem atributos + funções. Neste artigo, o Calcado, mostra que os objetos ao invés de possuírem atributos e funções, eles na verdade possuem estados e comportamentos.  Reproduzindo um trecho do artigo :

Objetos não possuem propriedades + funções, eles possuemestado + comportamento. Você provavelmente vai usar atributos (i.e. variáveis de instancia) e funções (de instancia também) para implementar isso mas é um detalhe de implementação, não algo que deva ser exposto [sic]

Uma outra coisa que penso é que além disso que ele comentou, uma outra dificuldade que vejo no pessoal que está “montando” a arquitetura de sistemas, é definir como será a interação entre objetos.  Quem nunca ficou horas pensando onde colocar determinado método – “o método calcular preço  é da loja ou do produto?“; nome do método,  se deveria expor dados por get e set, etc .  Essa dúvidas vem da nossa visão equivocada da troca de dados entre objetos.

Se considerarmos que objetos não possuem métodos ou funções( função me parece tão modular e não OO) e sim “portas de entradas”.   Essas portas são como caixas de correio por onde enviamos e/ou recebemos mensagens com pedidos ou informações.  Para ficar mais fácil de entender,  imaginemos a situação de uma grande rede de lojas.  Esse grande rede possui diversas lojas, que possuem diversos produtos e clientes.  De cara, podemos dizer que temos 3 entidades :  Cliente, Produto e Loja.

Agora a pergunta: como você implementaria a lógica de obter preço – o cliente vai na loja, pega um produto e quer saber o preço.  Tenho certeza que alguns diriam que colocariam um método getPreco na classe de produto.  Outros fariam um PrecoControlador que pegaria o custo do produto e faria a operação de cálculo pegando a margem de lucro da loja, custo da loja e por seguiria…. Outros inventariam a classe preço que diante a loja e produto se calcularia….  De novo fazendo assim ainda estamos pensando em objetos como conjunto de funções e atributos e esquecendo da troca de mensagens.

Uma forma que vejo mais simples e mais expressiva de fazer (logo fica mais claro para entender o sistema) seria de perguntar para a loja o preço. Sendo assim, o cliente teria um produto e perguntaria a loja o preço. A loja consulta sua tabela de preço e responde.

Cliente  – pega produto —  > Produto

Cliente — informa o produto a loja –> Loja

Loja — consulta tabela –> Tabela

Loja — responde ao cliente –>

Fica bem elegante não… Mas se ainda não conseguiu ver:

class Andre  extends Cliente

…

Produto lapis = new Lapis();

double preco = lojaAbobrinha.qualEhOPreco(lapis);

..

Abobrinha extends Loja

…

double qualEhOPreco(Produto produto)

minhaTabelaPreco.qualPrecoAtual(produto);

Quem for fazer a manutenção do código,  só de ler, já começa a entender oque está acontecendo e começa deduzir as demais interações.

Pessoal, hoje li no blog Agile Buddy do Jack Milunsky um interessante e pequeno artigo em que ele reflete sob qual seria um bom dia da semana para começar e terminar o sprint.  Eu tomei a liberdade de escrever uma versão em português para vocês. Caso queiram ler o original cliquem aqui

Primeiro, que fique claro que o tamanho dos sprints sempre devem ser consistentes.De qualquer jeito, experimente 1 fazer sprints com duração de 1, 2 ou 3 semanas mas uma vez que acha o melhor cenário adote-o e siga-o. Isto é importante para definir um ritmo na empresa. Entretanto, a questão é quais dias são os melhores para começar ou terminar o sprint. Até agora, eu tenho sido um fã de começar na segunda e terminar na sexta-feira. Me parece ser uma cadência natural e os dias acabam por se tornar pontos de transição lógica.

Porém, nesta semana, houve uma discussão no forum de desenvolvimento Scrum, e um número razoável de pessoas disseram ser a favor de começar não na segunda e sim na terça; terminar na quarta e não sexta. Os motivos para isso foram os seguintes :

1 – Existem muitos feriados na segunda e sexta que acabam por interromper o ciclo e com isso o ritmo.

2 – Se tiver algum problema no sprint e ele termina na sexta, isto possívelmente forçará o time de trabalhar no final de semana – algo normalmente evitado pela comunidade ágil.

3 – Sexta feira acaba sendo um dia não muito produtivo pois o pessoal tende a se dedicar a demos, restropectivas, etc.

Pelo aprendizado, eu preciso experimentar isso.

Qual tem sido sua experiência?

Jack

Esses dias li um e-mail numa lista de discussão que participo onde a pessoa perguntava como ela deveria fazer para documentar um projeto que ele desenvolveu sozinho. Ainda segundo ele, a ideia é de permitir que num futuro próximo um novo desenvolvedor possa trabalhar no sistema sem traumas e com uma curva de aprendizado rápida.

Antes de tentar responder a pergunta, acredito seja necessário entender a diferença entre análise e documentação.  Muitas pessoas que trabalham com  criação de softwares, acabam confundindo documentar com analisar.  Essa dúvida é normal pois muitas “ferramentas” e “métodos” também se apresentam como opção de documentação, ou o contrário : coisas que deveriam ser usadas para documentar são usadas para fazer análise ( e até acabam com uma má fama sem terem culpa disso – puro mal uso). Um exemplo disso, no meu ponto de vista, é o uml : Muitos usam a UML com o propósito de analisar e modelar. Ela até foi criada com esse intuito pois, quando foi concebida  era bastante custoso codificar e alterar o código feito (lembre-se dos cartões perfurados, cobols da vida, etc) mas hoje isso já não é válido (com linguagens modernas, codificar é rápido e alterá-lo mais ainda). Voltando, UML, no meu ponto de vista, é muito mais documentativa do que modelagem.  Seus diagramas tem um ótimo apelo de representar graficamente um sistema e como diz um ditado: “Uma imagem vale por mil palavras”.

Um outro mito a ser desfeito, insisto, no meu ponto de vista, é de que documentar não agrega valor. Por mais que ninguém diga isso, por mais que ninguém escreva isso, por mais que ninguém assuma isso, muitos de nós considera o ato de documentar como uma atividade secundária, e com isso, delegamos para que outros façam ou, em piores casos, nem o fazemos. A questão que ninguém escreve um sistema para si e, na maioria dos casos, não fazemos isso sozinhos.  Outro ponto é que, possivelmente, não ficaremos para o resto de nossa vidas com aquele projeto, passaremos para outros desafios e aquele sistema deverá ser cuidado por outro pessoa que não necessariamente participou da equipe que o desenvolveu. Tal fato, implica em ter que forma esse pessoa de forma que ela possa dar continuidade ao aplicativo sem comprometer a qualidade dele (estou assumindo que seja aqueles projetos onde temos testes automatizados, linguagens bem expressivas, etc). Logo, tendo todo esse contexto em mente, fica fácil mostrar que documentar, no mínimo, é evitar dores de cabeça futuras.

Mas, enfim, como documentar?

A pergunta poderia ser redigida da seguinte forma para ter mais sentido para nós : Como podemos documentar sem que isso seja uma atividade secundária e agregue mais valor ao sistema? .  A maioria das linguagens modernas oferecem recursos, bastante interessantes, que podem responder essas perguntas. Em Java, nós temos o recurso básico do JavaDoc (comentários em formato especiais que são colocados no código fonte. Depois, através de ferramenta exportamos para um html), em .NET (csharp) temos algo parecido, e por ai segue. Embora isso já seja algo que ajude, considero insuficiente como documentação pois, quem irá ler não terá uma visão do funcionamento ou do comportamento do sistema.

Nesse contexto de comportamento e funcionamento que entram a ajuda primordial dos teste automatizados. Um efeito secundário dos testes automatizados (tanto os teste unitários quando os testes de comportamento) é de, se bem escritos e de grande abrangência,  eles acabam sendo uma boa fonte de consulta para o entendimento da aplicação.  Existe, inclusive, frameworks de teste de comportamento (Behavior Tests) que permitem que se escrevam de forma literal facilitando ainda mais o seu uso como documentação, como por exemplo o Cucumber (Ruby), Pyccuracy ( espero ter escrito certo – Python), etc.

Por fim, eu pessoalmente, acredito que um bom diário de bordo também ajuda bastante. Um diário de bordo, consiste, em algo parecido com um blog ( pode até ser um blog), em que vou escrevendo o dia a dia do desenvolvimento tentando retratar as decisões não técnicas e situações vencidas pela equipe de forma que a pessoa que irá trabalhar com o sistema no futuro tenha também uma visão do por que de certas escolhas, do sentimento da equipe naquele momento, etc.

Foi dada a partida no evento da DevInRio. O evento prometo muita interação. Todos os presentes foram convidados a postar no twitter (usando a hashtag #devinrio). Além o pessoal se superou e mostrou o poder de ser ágil : Foi fixado um quadro do lado de fora para que colocassem sugestões de coisas a melhorar e pontos fortes.
As palestras estão demais. A primeira falou do Joomla e da Open Source Matters (feita pelo Ryan Ozimek). Ele simplesmente arrasou (minha opinião). Sua apresentação mostrou o modelo do Joomla e a forma que a empresa se reestruturou para atender uma nova forma de trabalhar com a comunidade. Com um molho a já boa apresentação, ele mostrou como podemos ver o joomla e o software livre numa visão de negócio.
A palestra seguinte foi a do pessoal da Caelum. Ele falaram sobre a questão da morte do Java. Num keynotes bem fluente, eles passearam pela JVM e as oportunidades de usá-la como plataforma de multilinguagem.
Bem agora está rolando a palestra do Akita sobre ecossistemas em Ruby.
Para terminar quero dizer que não veio está perdendo um evento maravilhoso . Parabéns Guilherme e Henrique… vocês se superaram.

Uma coisa que sempre considero interessante é forma que o ambiente de trabalho influi na qualidade do que ali é feito. No manifesto ágil, dentro da listagem dos princípios, existe um que diz: “Build projects around motivated individuals. Give them the environment and support they need,and trust them to get the job done.(Construir projetos em torno de pessoas motivadas. Dê a eles o ambiente e suporte que necessitam, e confie que eles farão o trabalho)”. Logo, para que um projeto tenha sucesso, no sentido de ROI (Retorno de investimento – qualidade e prazo), a empresa deve propiciar um ambiente ótimo para sua equipe.
Em minhas muitas andanças, vi de tudo um pouco: ambientes que são verdadeiros sonhos de consumo, outras que são a visão do próprio inferno. Já presenciei cenas onde os profissionais se amontoavam em torno de mesas de não mais que 1 metro quadrado, em locais que não permitiam uma boa comunicação entre os membros, iluminação péssima, pessoas que não se entendem, etc. Muitos gerentes, donos de empresa, e tantos outros, podem pensar que, uma vez que somos trabalhadores do pensar, o fato de ter um meio bom não é algo importante, mas, em minha opinião, é justo contrário.
Um espaço bem pensado (em todos aspectos: espaço individual, equipamentos, iluminação, etc) afeta de forma significativa às pessoas que nele convivem. Tal fato pode ser comprovado por várias teorias de arquitetura, psicologia, cromoterapia, etc, e não vou me estender nesses pontos.
A questão que desejo abordar é de ordem prática e próxima aos assuntos de relacionamento e chefias. Não existe como trabalhar e gerar entregas com qualidade num local onde não existe valores como respeito, sentimento de equipe, abertura para diálogos, infrastrutura decente, liberdade de escolha por parte do time, excesso de “politicagem”, etc. O time não precisa estar alheio ao que acontece ao seu redor mas seria, no minímo interessante, que eles pudessem trabalhar se grandes interrupções para tratarem assuntos que não passam de caprichos de alguém.
Imaginemos uma empresa fictícia que seria um bom exemplo de o quanto um ambiente ruim gera resultados ruins. Neste caso, existe burocracia demais e tudo é “engessado”. O espaço para inovação é quase nulo(para não dizer inexistente). A cultura de individualismo é muito forte , onde o sentimento de competição está sempre presente… é um cada por si, ninguém ajuda o outro, mesmo se não tiver nada para fazer. Auto-gerenciamento é palavra proibida e apagada dos dicionários: se o chefe não mandar, nada é feito. O minimo de recursos para realizar um projeto é algo que só vem em última estancia (por várias vezes fiz servidor para sistemas em produção a partir de micros normais até um dia que deu uma pane bizarra e eles compraram mais memória !!!!). Reuniões são intermináveis e sempre não chegamos a conclusão nenhuma.
Todos, nessa nossa empresa fictícia, vivem idéias de 20 anos atrás que o mercado cansou de provar que são falhas (pilhas de documentos, pilhas de formulários, burocracia para tudo, etc). A qualidade não é medida pela satisfação do cliente e sim pela quantidade de documentos e formulários preenchidos, padrões adotadas, horas de “gestão” gastas. O custo de mudança é imenso pois o tempo gasto com papel é quase 50% do tempo total de projeto. PMI é biblia e quem faz MBA é papa.
Muitos podem se perguntar: “Trabalhar numa empresa assim pode ser horrível?”. Primeiro, acredito que “não há mérito em ser bom dentro da igreja”: devemos tentar mudar as coisas, aportar novas idéias, não impô-las, fazer a transformação pelo trabalho de formiguinha. Ser ágil dentro uma empresa que já é ágil é mole.
Concluindo, gostaria de deixar a mensagem de que antes de pensar em burocracias, métodos, formulários, reuniões, é preciso avaliar a equipe, o ambiente, até as mesas e ver se elas estão adequadas a qualidade desejada. Além disso, é preciso mudar a cultura das pessoas, ao invés de impor, convencê-las de que a mudança é boa e que vai trazer benefícios. E claro, quem manda é quem faz !!! Chefe é facilitador e não capataz… Deve ser sensível ao que acontece e blindar a equipe. Claro que não podemos responsabiliza-lo por tudo… A empresa é sempre a maior vilã.
Se você trabalhar numa empresa parecida com a nossa fictícia, e já tentou de tudo para mudar, pode ser que chegou a hora de buscar novos desafios.