Logo Tech Writers

Tech writers

Esse é o nosso blog para apaixonados por tecnologia! Aqui, softplayers e outros especialistas compartilham conhecimentos fundamentais para o desenvolvimento dessa comunidade.

SEJA UM TECH WRITER
Desenvolvimento Ágil de Software no segmento de Construção Civil da Softplan
Tech Writers Maio 02, 2022

Desenvolvimento Ágil de Software no segmento de Construção Civil da Softplan

No ano de 2016, o segmento de Construção Civil da Softplan tomou a decisão estratégica de mudar seu modelo de negócios.  Assim, a empresa substituiu a comercialização de Licenças de Uso Perpétuo de Software (LUs) pela distribuição no modelo de Software como Serviço (Software as a Service – SaaS).  Naquele momento, foi identificado que seria necessário criar e aprimorar competências internas  na nossa área responsável pelas soluções para a Indústria da Construção . Em um modelo tradicional de licenças de uso, é normal que o cliente aguarde meses para receber uma nova versão de seu sistema.  Já um sistema do tipo SaaS libera as atualizações de software constantemente. Seja para corrigir falhas e vulnerabilidades, ou para disponibilizar funções novas ligadas às inovações tecnológicas ou de negócio. No modelo SaaS, com pagamento de assinatura recorrente, o cliente não precisa realizar grandes investimentos iniciais para adquirir as licenças de uso de software. Ao mesmo tempo em que isto facilita a entrada de um cliente, também facilita sua saída.  Isto porque o cliente não desembolsou um grande montante financeiro que ainda precisará gerar Retorno Sobre Investimento (Return Over Investment – ROI).  Portanto, investir nas soluções de software é uma forma de facilitar a retenção de clientes, visto que tem como foco a sua satisfação.   Identificamos dois grandes objetivos. São eles: liberações frequentes de software e garantia de satisfação do cliente a partir da qualidade do mesmo. Para alcançar os objetivos acima, algumas mudanças seriam necessárias. São elas: Melhorias de código; Melhorias na documentação; Modernização de práticas de engenharia de software; Melhoria nos processos que regiam o desenvolvimento do Sienge – sistema especializado de Construção Civil.  A fim de promover essas melhorias, o segmento de Construção Civil da Softplan investiu no Desenvolvimento Ágil de Software.  Nesse conteúdo, vamos explicar o que é o Desenvolvimento Ágil de Software, como realizamos o processo, resultados obtidos e muito mais sobre o tema. Continue a leitura! Desenvolvimento Ágil de Software O Desenvolvimento Ágil de Software corresponde a comportamentos, processos e práticas utilizadas na criação de software, que tem como objetivo serem mais leves ou ágeis que os processos “tradicionais”.  A maior parte dos “frameworks” de processos para desenvolvimento ágil de software considera a entrega de pequenos incrementos do sistema em períodos curtos e delimitados de tempo.  Este período compreende todas as etapas do ciclo de vida de um software necessárias à entrega desses incrementos:  Planejamento; Análise; Programação Testes; Documentação.  O objetivo do período em si é realizar esses complementos graduais no sistema.  O Desenvolvimento Ágil de Software é um processo empírico: entregas curtas visam viabilizar ciclos curtos de obtenção de feedback, aprendizado e adaptação (dos requisitos, do design da solução e do planejamento). Dessa maneira, a solução que está sendo desenvolvida surge durante o desenvolvimento a partir desses ciclos. Outra característica é a ocorrência mais direta e constante de comunicação e colaboração entre o desenvolvimento e o negócio/cliente no entendimento, validação e desenvolvimento da solução. As práticas ágeis de desenvolvimento ágil de software  As práticas ágeis de desenvolvimento de software evoluíram a partir dos anos de 1990, identificadas inicialmente como métodos “leves”, em oposição aos métodos tradicionais e “pesados”. Na primavera do ano 2000, líderes da comunidade de Extreme Programming (XP) se reuniram para discutir as práticas desta metodologia.  Também discutiram a relação do XP com os demais métodos “leves”. Estes métodos incluíam o Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e outros. Eles foram discutidos em conjunto porque eram entendidos como uma alternativa aos métodos pesados. A partir deste momento, Robert Cecil Martin resolveu criar um encontro com pessoas interessadas em Métodos Leves. O evento ocorreu em fevereiro de 2001, em Utah, nos Estados Unidos. Nele, 17 profissionais de programação e especialistas em tecnologia se reuniram e criaram o que hoje conhecemos como Manifesto Ágil. Os métodos ágeis compartilham algumas características, como o desenvolvimento interativo. Eles são mais adequados quando os requisitos de um produto mudam com frequência. Recomenda-se também para projetos com times pequenos, pois, com o aumento de tamanho, a comunicação face a face se torna mais difícil.  Além disso, é necessário que alguns fatores chave de sucesso sejam garantidos:  Uma cultura organizacional que suporte os métodos;  A confiança das pessoas;  Autonomia e apoio às decisões tomadas pelos times técnicos; A presença de um ambiente que facilite a comunicação entre os membros. Desenvolvimentos de Software para a Construção Civil em 2016 na Softplan Em 2016, a solução de software produzida pelo segmento de Construção Civil da Softplan – o Sienge – liberava versões a cada 45 dias para entrega de funcionalidades novas, e versões menores para correção de bugs.  O ciclo de vida de desenvolvimento de um software adotava uma abordagem mais tradicional, do tipo cascata.  Os times de desenvolvimento eram grandes, tendo em média 20 integrantes. Estes times eram compostos por papéis especializados, citados a seguir. Gerente de Desenvolvimento: Responsável pela gestão funcional dos times e pela gestão técnica / evolutiva do produto; Coordenador de Desenvolvimento: Responsável por auxiliar o gerente de desenvolvimento na gestão funcional dos times; Analista de Requisitos: Responsável pela escrita detalhada da especificação dos requisitos das funcionalidades a serem implementadas; Programador: responsável pela codificação do sistema; Testador: responsável pela condução dos testes em suas diferentes camadas. À época, a maior parte dos testes era conduzida de forma manual. Também havia uma boa cobertura de testes automatizados na camada da interface gráfica do sistema. A evolução do produto era guiada principalmente a partir das solicitações dos clientes e dos prospects. O projeto Jano A primeira tentativa de adoção de agilidade na área de soluções para a Indústria da Construção ocorreu em 2010, com o framework Scrum.  Naquela situação, times pequenos que desenvolviam funcionalidades do sistema, como os times de Engenharia e de Suprimentos, foram unificados para estarem mais aderentes à proposta Scrum. O papel de PO havia sido introduzido em uma adoção anterior do Scrum no ano de 2010, mas acabou sendo esquecido ao longo do tempo. Na prática, o coordenador de desenvolvimento junto ao cliente decidia as funcionalidades do produto.  Como dito anteriormente, as equipes possuíam papéis especializados. Havia um atrito entre os papéis do analista de requisitos e do programador.  Os programadores reclamavam de não possuírem qualquer autonomia sobre a especificação das funcionalidades, visto que recebiam o Use Case completo e pronto dos Analistas de Requisito.  Visando minimizar este atrito, além de atingir outros objetivos, o projeto “JANO” substituiu os Use Cases por User Stories. O projeto HAT Em 2016, uma nova iniciativa de agilidade foi lançada, com total patrocínio da gestão da unidade. Este projeto foi denominado HAT.  O sucesso do projeto HAT seria crucial para o êxito da mudança no modelo de negócio da unidade, passando da modalidade de venda de licenças perpétuas (LUs) para o modelo SaaS. Assim, um comitê de agilidade foi formado. Este comitê era composto principalmente por profissionais técnicos de desenvolvimento de software, mas incluía até o diretor de operações da área, com participação ativa nas discussões. O grupo atuava no papel de coach para adoção de agilidade. Os grandes times foram divididos, adequando-se aos padrões de tamanho sugeridos pelos frameworks ágeis. Cada time era responsável por um módulo principal do Sienge e também por alguns módulos secundários.  Times não funcionais e funcionais Também foram estabelecidos dois times não funcionais, que atuavam dando suporte aos demais: os times de infraestrutura e arquitetura. Cada time funcional passou a contar com um Scrum Master, que era também um integrante do comitê de agilidade.  Acreditava-se que o papel de Scrum Master seria temporário, pois seu objetivo era ensinar o time a ser ágil, tornando sua própria existência dispensável no futuro. Os coordenadores de desenvolvimento passaram a desempenhar o papel de Product Owner, migrando de um cargo de gestão funcional para um cargo mais técnico.  Os papéis especializados de Analista de Requisitos, Programador e Testador deixaram de existir.  T-shaped professional A partir da diretriz de tecnologia de garantir a perenidade do Sienge como sistema SaaS, o papel de Desenvolvedor de Software passou a adotar um perfil conhecido no mercado como “T-shaped professional”.  É esperado que este profissional apresente desempenho avançado em uma área de competência e, também, desempenho básico ou médio em áreas de competência complementares.  As áreas de competência estabelecidas para o Desenvolvedor de Software (Software Developer) do Sienge foram as seguintes: Análise e projeto: envolve a capacidade analítica sobre a necessidade (requisito) a ser implementada no sistema; Programação: envolve a codificação de software que atenderá os requisitos levantados pela Análise e projeto; Qualidade/Testes: incentiva a correta adoção das diferentes camadas da pirâmide de testes na entrega de cada funcionalidade; Times e Processos: envolve conhecimentos e habilidades para potencializar o trabalho em time (condução de cerimônias, técnicas de facilitação, técnicas estruturadas de feedback) e domínio de frameworks para auxílio na organização e produtividade (Scrum, Kanban, XP, etc); DevOps: inclui conhecimentos técnicos relacionados ao movimento DevOps e também a preocupação com os aspectos não funcionais do código a ser produzido: segurança, capacidade, alta disponibilidade, recuperação de desastres, etc. Esta alteração do perfil do desenvolvedor foi explicada a todos os integrantes da área de tecnologia.  Os perfis especializados deixariam de existir e as pessoas precisariam buscar os conhecimentos esperados para o “perfil em T”.  O maior desafio, em geral, recaiu sobre aqueles que não programavam. Existiam então duas opções: o profissional precisaria aprender a programar, contando com o auxílio da empresa, ou optar por deixá-la.  Ambos os casos ocorreram, mas a maioria optou por permanecer na organização, aprendendo programação. Horizontalização na hierarquia de tecnologia da unidade Durante o projeto HAT, o Gerente de Desenvolvimento deixou de conduzir a gestão funcional dos colaboradores. Ele ficou focado na gestão técnica e de evolução do produto.  Ocorreu, por consequência, um achatamento, ou horizontalização, na hierarquia de tecnologia da unidade.  Onde antes existia um diretor, um gerente, coordenadores e os times, restaram apenas os times ligados diretamente ao diretor. O achatamento da hierarquia deu mais autonomia aos times de desenvolvimento. Entre as mudanças, todos passaram a contar muito mais com o feedback dos pares e não somente com o feedback da gestão. Essa autonomia dos times podia ser observada em diferentes situações: Durante um processo de contratação Existe uma fase de entrevista do candidato pelo time o qual ele fará parte. A gestão do segmento de Construção Civil acredita que o “team building” deve iniciar pela oportunidade de o time escolher seu novo integrante. Assim, a equipe tem autonomia e poder de veto ou aprovação do candidato. Desligamentos Desde 2017, a empresa desligou três colaboradores. Destes três desligamentos, o próprio time decidiu por dois, por não enxergar mais cooperação dos profissionais desligados. Escolha de processos e metodologias  Os times têm autonomia e liberdade na escolha das metodologias de desenvolvimento que adotam. Alguns times respeitam mais fielmente o framework Scrum, alguns optam pelo Scrumban, e alguns trabalham em um modelo de esteira contínua, característico do Kanban.  Até mesmo o período de interação não é padronizado e varia entre os times. Alguns adotam interações de uma semana, outros de duas semanas. A partir de um processo de avaliação 180º (entre pares), os desenvolvedores promovem as ações salariais de seus colegas. Este processo, denominado Apex Dev, será tema de outro artigo. Acompanhe o blog para conferir! Os resultados obtidos com as inovações tecnológicas na construção civil Além da adoção de práticas de agilidade na readequação dos times, as práticas técnicas também evoluíram. A união das práticas processuais e técnicas permitiu alcançar uma grande mudança na frequência de liberações do Sienge.  Desde o ano de 2017, o Sienge passou a liberar versões novas quase que diariamente. No ano de 2020, que possuiu 253 dias úteis, 207 versões do Sienge foram liberadas. Aplica-se cada uma dessas versões a todo o datacenter Sienge, gerando a atualização de milhares de clientes. Elas são também disponibilizadas para que clientes on premise possam aplicá-las. O novo modelo de negócios baseado em SaaS atingiu seus objetivos estratégicos. Além disso, a transição da Cultura Tradicional para a Cultura Ágil alcançou seu objetivo ao suportar este novo modelo de negócios. Gostou de conhecer a Adoção de Agilidade no segmento de Construção Civil da Softplan? Confira mais conteúdos como esse em nosso Blog! Quer ser nosso próximo Tech Writer? Confira nossas vagas na página Carreira! Até a próxima!

Conheça um dos princípios SOLID mais importantes: Single Responsibility Principle
Tech Writers Abril 21, 2022

Conheça um dos princípios SOLID mais importantes: Single Responsibility Principle

Um dos princípios SOLID mais importantes é o Single Responsibility Principle (SRP), ou Princípio da Responsabilidade Única (em português).  De acordo com Robert C. Martin (Uncle Bob) em seu livro Clean Code, uma função deve ter apenas uma responsabilidade. Durante a leitura do livro, me deparei com um caso onde o autor aplicou técnicas de refatoração em um código legado, deixando uma função o mais enxuta possível.  Para o autor, aquela função, após ser refatorada, passou a fazer apenas uma ação. Veja: A questão é que, analisando a função, identifiquei que ela executa três ações: Verifica se é uma página de teste;  Caso seja uma página de teste, inclui setups e teardowns;  Retorna o html da página. Níveis de abstração A partir desse momento, o autor passa a discutir os  “níveis de abstração” do Single Responsibility Principle (SRP). Ele afirma que: “Uma função faz apenas uma única coisa se todas as instruções dentro dela estão no mesmo nível de abstração”. Confesso que, mesmo após ter lido várias vezes essa frase, não compreendi como aquela função fazia apenas uma coisa. Até que decidi colocar a mão na massa. Foi aí que tudo fez sentido! Para explorar um pouco mais o SRP, vamos utilizar um exemplo fictício: Considere que, em uma das classes do nosso sistema, existe uma função responsável por processar a aprovação de alunos. O processamento da aprovação consiste em atualizar os dados do aluno e enviar um e-mail notificando que o estudante foi aprovado. Abaixo, o código que representa essa função: Conforme podemos conferir na imagem, a função acima executa mais do que uma ação. Para evidenciar isso, separei elas por comentários: Nessa etapa, ficou muito óbvio que a nossa função faz mais de uma coisa. Porém, a pergunta é: será que a função consegue perceber os diferentes níveis de abstração que ela possui? O objetivo dessa função é processar a aprovação. “O processamento de aprovação consiste em atualizar os dados do aluno e enviar um email notificando que o aluno foi aprovado”. Ou seja, enviar e-mail faz parte das responsabilidades da nossa função. Porém, colocar a frase “Bom dia” no corpo do e-mail já é um detalhe que a função não precisa saber. Ou melhor, ela não precisa saber se o e-mail deve começar com “Bom dia” ou “Olá”. Isso está em um nível mais baixo de abstração. Separação dos níveis A ideia, agora, é separar cada nível de abstração por uma nova função. Aplicando a técnica de extração de métodos, podemos extrair a atualização dos dados do nosso aluno para outra função: Aplicando a mesma técnica, podemos extrair também o envio do e-mail por diferentes níveis de abstração: Perceba que criei uma função para montar o e-mail colocando os destinatários e o conteúdo do mesmo e outra função somente para montar esse conteúdo. Isso porque as duas “tarefas” estão em níveis diferentes de abstração. Com isso, a nossa função principal ficou da seguinte forma: Agora, se eu te perguntar “quantas coisas essa função faz?”, é provável que você responda: “duas coisas: ela atualiza os dados do aluno e envia o e-mail”.  Se essa for sua a resposta, você não está errado, mas também não está certo. Vou te explicar o porquê. Lembra dos requisitos da nossa função? “O processamento da aprovação consiste em atualizar os dados do aluno e enviar um e-mail notificando que o aluno foi aprovado”. Ou seja, atualizar os dados e enviar o e-mail estão no mesmo nível de abstração. Portanto, podemos concluir que a nossa função faz apenas uma única coisa: processa aprovação de alunos. Gostou de aprender um pouquinho mais sobre Single Responsibility Principle? Confira mais conteúdos como esse em nosso Blog! Quer ser nosso próximo Tech Writer? Confira nossas vagas!

Slow Query: entendendo os seus limites!
Tech Writers Abril 18, 2022

Slow Query: entendendo os seus limites!

No conteúdo de hoje vamos falar sobre um assunto muito relevante para otimizar o trabalho dos desenvolvedores: Slow Query. Há muito tempo existe a preocupação com otimização de consultas nas aplicações. Mas você sabe dizer quais são os limites aceitáveis?  Nesse artigo, vamos te explicar como determinar o que é uma consulta lenta (Slow Query)  e quando otimizá-la. Como base, vamos usar o livro de Jakob Nielsen sobre Engenharia de Usabilidade. Fique com a gente  até o fim do conteúdo e entenda tudo sobre o tema.  Percepção Humana em Slow Query Existem três limites de tempo principais, determinados de acordo com as habilidades de percepção humana. Eles devem ser mantidos em mente na hora de otimizar o desempenho. O conselho básico sobre os tempos de resposta se divide da seguinte maneira: 0,1 segundo é o limite para que o usuário sinta que o sistema está reagindo instantaneamente, o que significa que nenhum feedback especial é necessário, exceto para exibir o resultado; 1,0 segundo é o limite para o fluxo de pensamento do usuário permanecer ininterrupto, mesmo que o usuário perceba o atraso. Normalmente, nenhum feedback especial é necessário durante atrasos de mais de 0,1 mas menos de 1,0 segundo. O usuário perde a sensação de operar diretamente os dados; 10 segundos é o limite para manter a atenção do usuário focada. Para atrasos maiores, os usuários vão querer realizar outras tarefas enquanto esperam o computador terminar. Dito isso, vamos determinar o Tempo de Resposta do Servidor (SRT) e iniciar boas práticas e processos para melhor experiência da aplicação. Determinando o tempo de resposta em Slow Query Embora o embasamento teórico para as diretrizes de tempo de resposta feitas por Nielsen seja antigo e a partir de aplicações baseadas na WEB, essas orientações ainda são recomendadas para qualquer aplicação desenvolvida nos dias atuais.  Portanto, independente da tecnologia que venha a ser implementada ao longo dos anos, a diretriz será a mesma. Desta forma, quando encontrar uma situação na qual  precise definir os tempos de respostas das Slow Queries, procure algum especialista para otimização de sua arquitetura e desempenho.  A sugestão a seguir demonstra boas referências de tempo: 1000 ms ou menos – Bom desempenho; 1000-2000 ms – Otimização é recomendada; Mais de 2000 ms – Baixo desempenho, a otimização é necessária. É muito importante a definição desta “régua” de tempo como requisito não funcional. Estes números foram determinados de acordo com as indicativas e diretrizes especificadas por Nielsen. Para ajudar, você pode monitorar sua estrutura baseado nas coletas de tempos de resposta recebidos ao longo do tempo. A partir disso, pode realizar ajustes.  Isso tudo implica em diversas melhorias para o ambiente como um todo, como por exemplo: Diminuição dos custos do Data Center; Melhoria da experiência do usuário Final; Maior sustentabilidade ao seu projeto ao longo dos anos. E então? Conseguiu entender os limites do Slow Query e como utilizá-lo? Continue acompanhando o nosso blog. Nos próximos artigos, traremos mais dicas de otimização que são importantes, mas muito esquecidas, até  mesmo por profissionais experientes.  Fonte: NNGROUP  Gostou de aprender um pouquinho mais sobre Slow Query? Confira mais conteúdos como esse em nosso Blog! Quer ser nosso próximo Tech Writer? Confira nossas vagas na página Carreira! Até a próxima!

O que é design organizacional e como ele estimula a inovação nas empresas?
Tech Writers Abril 04, 2022

O que é design organizacional e como ele estimula a inovação nas empresas?

Chip Conley, um dos antigos conselheiros estratégicos do Airbnb, utiliza uma analogia interessante para explicar porque precisamos da inovação. Num cenário lúdico, nós somos os surfistas (os empreendedores) monitorando o mar (o mercado). Os bons surfistas conseguem de longe saber se vale a pena pegar uma onda que passa, ou se é melhor deixá-la passar. É como um novo negócio, buscando investidores: você deve saber avaliar se aquela empreitada vale mesmo a pena. O surfista que avaliar da maneira certa “qual a melhor onda”, vai pegá-la primeiro. Ou seja, os empreendedores mais antenados se aproveitam do oceano azul e saem na frente dos concorrentes.  Da mesma forma, o surfista também precisa aprender a reconhecer o perigo no mar e escolher quando não encarar o risco. Manter o negócio estável é também uma opção e posicionamento no mercado. O problema é que alguns surfistas sequer percebem a onda chegando, sendo então engolidos pela água. Eles não percebem que a inovação nas empresas, especialmente de tecnologia, são uma estratégia de sobrevivência.  Afinal de contas, quem está no mar precisa acompanhar a maneira como ele se move. E a inovação é uma das melhores estratégias para seguir o seu movimento. Promover inovação nas empresas (seja incremental ou disruptiva) exige: alinhamento, comunicação, capacitação, implementação e avaliação. Agir de forma assertiva em todas essas etapas é o que define o desempenho da inovação e os resultados obtidos. De acordo com Bignetti (2002), é importante também que, para inovar, a estratégia seja um processo dinâmico.  Já entendemos que a inovação é essencial para se aproveitar as melhores oportunidades. Mas como podemos concretizar tais mudanças em empresas Tech, com cenários sempre tão complexos e ágeis?  Utilizando técnicas e métodos focados na otimização dos processos, reorganizando a estrutura do negócio, dentre outros pontos abordados no conceito de design organizacional.  O design organizacional é uma das formas de fomentar a inovação nos negócios, sendo uma “onda” que deve ser aproveitada pelos empreendedores. Por isso, vamos explicar tudo sobre o tema nesse artigo, além de te ensinar boas práticas para a implementação do mesmo.  Afinal: o que é o design organizacional? O design organizacional, ao ser aplicado em uma organização, implementa melhorias relevantes no desempenho do negócio. Ele é um caminho interessante na promoção da inovação. Seus principais objetivos são:  Promover a otimização dos processos e a agilidade na tomada de decisões; Reestruturar (funcional e até mesmo fisicamente) equipes e lideranças para implementar as mudanças necessárias; Indicar a estratégia de gestão e engajamento das pessoas para absorção da nova cultura e monitorar os impactos destas mudanças.  Assim, o design organizacional revisa os processos e concretiza novos padrões focados nas mudanças desejadas. Esse conceito tem como pilares de sustentação as pessoas, as tecnologias e a visão estratégica da empresa.  É simples: o ser humano age como o ator central da mudança, dominando as tecnologias para concretização dos objetivos estratégicos. Assim, é sempre importante nos questionarmos, o quanto nós, como participantes de uma organização, entendemos nosso papel como agentes de transformação rumo a uma cultura inovadora. Além disso, os principais benefícios do design organizacional são:  O aumento da eficácia organizacional; Maior produtividade das equipes; Redução do turnover; Retenção de talentos; Mapeamento das habilidades e dos conhecimentos essenciais da organização;  O impulsionamento da inovação nas empresas como reflexo de todos os itens anteriores.  Quais seriam os passos para a implementação do design organizacional?  Como tudo na vida presume um caminho para se chegar a um objetivo, alguns passos são necessários para implementar o design organizacional no seu negócio. Listamos eles a seguir:   Elaboração da visão de futuro da organização; Identificação de cenários e padrões atuais de trabalho; Revisão do propósito e da direção do negócio (novo posicionamento); Revisão da estrutura organizacional de acordo com os três primeiros itens; Identificação dos entraves da operação que impedem a inovação; Promoção de uma nova cultura e de novos comportamentos; Investimento em pessoas, da capacitação ao reconhecimento; Estabelecimento de espaços para colaboração e ideação; Eliminação de barreiras entre setores e equipes; Preparação das lideranças para um novo modelo de gestão. Ao definir uma estratégia do processo de design, é preciso avaliar profundamente o cenário atual da organização. Alguns pontos devem ser levantados: seus pontos fortes e fracos, a necessidade de recursos, as expectativas de prazo e as opiniões dos gestores.  Só então se deve elaborar uma visão da “nova organização”.  Planejar esta nova visão é um grande desafio. Demanda revisar a estrutura organizacional, simplificar o negócio, reorganizar os times, levantar os recursos necessários e melhorar sistemas e modelos de gestão.  Os diferentes tipos de estrutura dos modelos empresariais (funcional, divisional, matricial, em rede e por projetos) exigem atuações diferentes para a promoção de um design organizacional mais fluido e inovador.  Rever o modelo mental que orienta a atuação de cada área da empresa se faz necessário nesse processo. A partir dessa ação será possível: Eliminar silos organizacionais;   Preparar gestores antes distantes da linha de frente do negócio; Descartar ineficiências;  Otimizar as equipes com transparência de responsabilidades e a ruptura da cultura do engajamento pelo poder. O design organizacional é, portanto, contínuo e gradual, exigindo a sustentação do novo modelo implementado.  A colaboração de todos os níveis da estrutura, da gestão à operação, é essencial para que todas as opiniões sejam consideradas em busca de consenso, responsabilização e complementaridade quanto ao escopo dos novos processos realizados.  A liderança deve promover a clareza de papéis e o empoderamento das equipes, equilibrando responsabilidade e autonomia.  Você sabe o que é holocracia? O americano Brian Robertson descreve a holocracia como uma nova forma de administrar uma organização. Nessa administração, o peso do poder é eliminado em uma estrutura hierárquica, então substituída por um sistema de distribuição da autoridade. As empresas Globant e Airbnb adotaram essa nova forma de gerenciar. Para aproximar essa realidade do Brasil, podemos falar sobre o Letras, uma empresa do país que adota práticas diferenciadas de administração. Você sabia que a empresa Letras, sediada em Belo Horizonte/Minas Gerais, adotou um layout inovador para revisitar, inclusive fisicamente, seu modelo de trabalho?  O escritório ocupa uma área de aproximadamente 500m2, contendo os diferenciais: salas para reuniões ou trabalhos que exigem maior concentração; espaços com propostas mais colaborativas para reuniões informais; espaços de alimentação e descompressão, que tem como extensão natural um terraço-jardim.  Sobre a Letras: Seu principal produto, o site que guarda as letras e cifras de músicas do mundo todo, conta com um acervo de 2.5 milhões de músicas. A cada mês, recebe mais de 90 milhões de visitas por pessoas diferentes.  Confira os cases completos nos links: Letras – Brasil; Airbnb – Estados Unidos; Globant – Colômbia. Conheça boas práticas de um projeto de design organizacional Qualquer estratégia de design organizacional exige uma prévia contextualização. É comum e natural que um projeto de design esteja associado a algum outro projeto da empresa, como, por exemplo, a implantação de um novo sistema, internacionalização do negócio, criação de uma rede de franquias, dentre outros. Por este motivo, aqui estão as boas práticas de um projeto de design organizacional: Alinhe a proposta de design ao planejamento estratégico: quando o design está “deslocado” do objetivo do negócio, o mesmo não perdura; Garanta a transparência do processo e a comunicação entre todos os níveis: um design “obscuro” e mal comunicado não convence; Remodele a cultura considerando os dois primeiros pontos: o design tem como ponto crítico o engajamento das pessoas, e este só acontece quando estas são participadas da mudança e reconhecem os valores da organização como seus próprios valores; Conheça o case da iQmetrix Software A Qmetrix Software, empresa canadense sediada em Vancouver, é uma das maiores fornecedoras de soluções de software para mercados de varejo especializados na América do Norte. Em 2017, a gestão foi confrontada com o desafio de continuar crescendo, porém mantendo o modelo aberto e não hierárquico. O objetivo era manter a transparência e a discussão de ideias como propulsores da inovação. Assim, a iQmetrix optou pela implementação da holocracia, garantindo uma estrutura organizacional fluida e com liderança compartilhada.  A consultoria especializada contratada pela iQmetrix utilizou diferentes ferramentas e métodos para estruturar uma nova proposta de design organizacional.  No entanto, para a surpresa de muitos, as ferramentas são mais tradicionais do que o próprio design em si: análise SWOT, análise das forças de Porter, análise da cadeia de valor, análise da matriz BCG, análise da matriz Ansoff e análise do mix de marketing da empresa. Mas não se iluda. Como já relatei, o design organizacional é um processo contínuo, colaborativo e evolutivo. Ao optar por um design estruturado pelo conceito da holocracia, a iQmetrix trouxe para sua operação rotineira o uso constante de ferramentas de modelo estratégico para garantir o alinhamento desta mudança organizacional ao objetivo do negócio e a adaptação aos fatores externos que podem impactar na gestão do negócio.  O case da iQmetrix, citado na Harvard Business Review e descrito no livro “Organizational Design at iQmetrix: The Holacracy Decision” (dos autores Ann Chris Street, Ann e Clayton Caswell Frost), é um exemplo de aplicação do design organizacional para manter o cerne inovador do negócio, especialmente durante a sua expansão, garantindo um modelo sustentável de operação através do viés holocrático.  A iQmetrix comemorou 20 anos em 2019, contando com uma rede de mais de 1000 lojas e atendendo a mais de 20 mil pontos de venda do varejo. O negócio realizou mais de 90 milhões de transações em 2019.  Conheça também o case da Oticon! Além disso, conheça a lista de pioneiros registrada pelo time da Corporate Rebels! E então chegamos à grande pergunta… O design organizacional pode estimular a inovação? Quando o planejamento estratégico de uma organização tem como ponto central a inovação, sua estrutura deve corresponder a este objetivo. Esta resposta passa por redesenhar a operação, a gestão, a cultura e as equipes visando um novo patamar de agilidade e resposta a um mercado cada vez mais competitivo.  Portanto, a resposta é: sim!  Quer ser uma empresa mais competitiva? Garanta um modelo facilitador da criação e discussão de ideias.  Quer ser uma empresa mais transparente na tomada de decisões? Elimine as barreiras de comunicação, reajuste hierarquias e transforme as decisões em planos colaborativos. Quer promover o aprendizado contínuo da organização? Estabeleça processos de gestão do conhecimento e valorize as comunidades de prática sufocadas por uma operação sem tempo para olhar para o futuro. Afinal de contas, conforme pontua Francischeto et. al (2019), é importante investir na cultura organizacional, e não somente em infraestrutura para fomentar a atividade inovadora.  Em 2016, um grupo de “rebeldes corporativos” criou uma empresa de consultoria especializada em romper com os modelos tradicionais instaurados em diversas organizações. O design organizacional se consolidou como uma das ferramentas mais aplicadas pelo time da “Corporate Rebels” com o discurso “Make work more fun”. Parece divertido demais para ser uma iniciativa corporativa séria? A “Corporate Rebels” conquistou clientes como Microsoft, SAP, Gucci, Hugo Boss E Daimler.  E qual era um dos princípios centrais de trabalho destes agentes “rebeldes”?  As abordagens flexíveis estimulam o empreendedorismo e a responsabilidade dos próprios colaboradores. Em um de seus artigos, o consultor da Corpora Rebels Joost Minnaar enfatiza:  “Organizações rígidas pertencem ao cemitério.” Modelos como a pirâmide invertida, equipes autônomas e em rede, são abordados como visões realistas do design organizacional focado na inovação e na fluidez do modelo de negócio.  “A cultura orientada para a inovação é definida como um conjunto de valores, normas e artefatos culturais organizacionais que sustentam a capacidade de inovação de uma empresa” (STOCK et al.,2013). Quando o CEO da Oticon, uma fabricante de aparelhos auditivos da Dinamarca, trouxe para a pauta a mudança radical que a empresa precisava, ainda nos anos 90, seu primeiro passo foi trabalhar o modelo de liderança.  E, assim, Lars Kolind criou o “modelo espaguete”: qualquer pessoa com uma boa ideia é livre para puxar uma equipe e atuar como líder do seu próprio projeto inovador, seja de processo, serviço ou produto.  No entanto, cada projeto precisa competir com todos os outros projetos que tentam decolar. Os colaboradores devem atrair recursos e apoio suficientes para que sua ideia prospere, senão, ela irá perecer.  “When I started at Oticon I felt a huge desire and need to design an innovative, fast moving and efficient organization. And that is what I did.” – Lars Kolind.  Inovação nas empresas: o limite entre o caos e a energia dedicada O design organizacional se apresenta então como uma prática capaz de reestruturar modelos de negócio para que incorporem a inovação como estratégia definitiva.  Esse processo exige equilíbrio entre a energia gerada por um ambiente fomentador de novos conhecimentos e o foco nas ações planejadas. Isso porque, a inovação, sem a devida execução, não é produtiva nem rentável. Além disso, o clima estabelecido pela nova cultura deve garantir a segurança psicológica para a proposição das inovações, sem que se confunda criatividade com ausência de alinhamento com os objetivos estratégicos.  Assim como ambientes sustentados pela diversidade, que promovam o intercâmbio entre culturas, precisam ser acompanhados para que a pluralidade não se transforme em conflito. A orientação à inovação é definida pelo grau em que os componentes favorecem a transformação organizacional. Assim, o design organizacional segue propondo uma revolução no mundo corporativo.  Em tempos de inteligência artificial, big data, e outras tecnologias poderosas, o design organizacional mantém em pauta a importância dos modelos organizacionais e da gestão de pessoas para garantir todo o potencial criativo do ser humano como vantagem competitiva.  Referências bibliográficas: BIGNETTI, Luiz Paulo. O processo de inovação em empresas intensivas em conhecimento. Rev. adm. contemp., Curitiba ,  v. 6, n. 3, p. 33-53,  Dec.  2002. Available from http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1415-65552002000300003&lng=en&nrm=iso. access on  09  Feb.  2020.  http://dx.doi.org/10.1590/S1415-65552002000300003.  FRANCISCHETO, LEELA L.; NEIVA, ELAINE R.. INNOVATION IN COMPANIES AND CULTURAL ORIENTATION TO INNOVATION: A MULTILEVEL STUDY. RAM, Rev. Adm. Mackenzie,  São Paulo ,  v. 20, n. 3,  eRAMG190135,    2019.   Available from http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1678-69712019000300304&lng=en&nrm=iso. access on  09  Feb.  2020.  Epub July 10, 2019.  http://dx.doi.org/10.1590/1678-6971/eramg190135. Stock, R., Six, B., and Zacharias, N. (2013). Linking multiple layers of innovation-oriented corporate culture, product program innovativeness, and business performance: A contingency approach. Journal of the Academy of Marketing Science, 41(3), 283-299. Gostou de aprender um pouquinho mais sobre design organizacional? Confira mais conteúdos como esse em nosso Blog! Quer ser nosso próximo Tech Writer? Confira nossas vagas na página Carreira! Até a próxima!

Conhecendo o Terraform (IAC – Infrastructure As Code)
Tech Writers Março 07, 2022

Conhecendo o Terraform (IAC – Infrastructure As Code)

IAC Terraform o que é Você conhece ou já ouviu falar sobre o IAC Terraform? O significado de IAC Terraform é, basicamente, modelar um planeta, lua, ou qualquer outra estrela, para que a atmosfera, temperatura, topografia ou ecologia desse lugar fique similar ao ambiente da Terra. Terraform é uma ferramenta open source de provisionamento de infraestrutura, criada pela Hashicorp em Golang. É uma ferramenta de código aberto, que possibilita a criação de uma infraestrutura ou serviço como código (IAC – Infrastructure as Code) de forma segura e eficiente, utilizando o HCL – Hashicorp Configuration Language. Ela é muito parecida com JSON, sendo uma mistura de linguagens de Ruby e YAML, dividida em blocos. Formato e criação de um arquivo Infrastructure As Code Terraform O formato do arquivo que o Terraform espera é “.tf” , além do arquivo “.tfstate”. Diferente de outras ferramentas de IaC, não é preciso se preocupar com a estrutura de pastas. O que é diferente de não organizar seu código, já que o Terraform vai compilar todos os arquivos .tf do diretório atual e suas sub pastas, antes de executá-lo. Para iniciarmos a criação de um arquivo .tf, precisamos identificar o provedor a ser utilizado. Ou seja, em qual fornecedor de cloud será realizado o deploy da infraestrutura. Um provedor é responsável por entender as interações da API e expor recursos. A maioria dos provedores configura uma plataforma de infraestrutura específica (nuvem pública ou privada).  Os provedores também podem oferecer utilitários locais para tarefas, como, por exemplo, gerar números aleatórios para nomes de recursos exclusivos. A coisa mais importante que você configura com o IAC Terraform são os recursos, sendo de baixo nível, como um servidor físico, máquina virtual ou contêiner, ou de nível superior, como um provedor de e-mail, registro DNS ou provedor de banco de dados. Comandos básicos do IAC Terraform Para utilizarmos o IAC Terraform no dia a dia, é importante conhecermos os seus comandos básicos. A seguir, vamos listar quais são eles:  Terraform init:  Inicializa o ambiente com o provedor utilizado. Responsável por fazer o download dos plugins e demais arquivos necessários para  a correta execução; Terraform plan: Faz a leitura dos arquivos TF, testa as configurações, e monta o plano de execução do Terraform; Terraform apply: Executa a “criação” dos recursos (instâncias/objetos) no provider indicado nos arquivos TF; Terraform show: Mostra informações dos recursos criados e um status da infraestrutura Terraform; Terraform output: Mostra o valor de uma determinada variável, facilitando a identificação da informação desejada. Ex: “public_ip”; Terraform destroy: Executa a “remoção” dos recursos (instâncias/objetos) no provider indicado nos arquivos TF. Conclusão do Terraform (Hashicorp) Por fim, o Terraform permite criar, alterar e destruir recursos em nuvem pública ou privada, utilizando uma linguagem de configuração de alto nível. Dessa maneira, essa ferramenta pode tornar a sua vida muito mais tranquila. Gostou de aprender um pouquinho mais sobre IAC Terraform?  Confira mais conteúdos como esse em nosso Blog! Quer ser nosso próximo Tech Writer? Confira nossas vagas! Referências bibliográficas: HASHICORP, Terraform Documentation. (2021): ttps://www.terraform.io/  LINUXTIPS, Conheça o Terraform | Semana DevOps #3. (2019, Agosto 21): https://www.youtube.com/watch?v=lrAycU7_XnQ   LINUXTIPS, Lucas Souza – Terraform além do básico. (2020, Abril 11): https://www.youtube.com/watch?v=P3aY4_vxzWQ  BROCK, Will. What is Terraform? | Terraform Tutorial. (2020, Junho 14): https://www.youtube.com/watch?v=vwn77cUarTs&list=PL8HowI-L-3_9bkocmR3JahQ4Y-Pbqs2Nt 

DevOps: desafios além do código!
Tech Writers Fevereiro 21, 2022

DevOps: desafios além do código!

O DevOps se tornou um dos termos mais discutidos entre as empresas de tecnologias dos últimos anos. Seja pelo hype, ferramentas, cargos ou pela promessa de tornar seu produto mais ágil, performático, e, ao final, seu cliente mais satisfeito Mas, além disso, de um ponto de vista teórico, o que mais temos para dizer do DevOps? Certamente, há muito o que se falar. Tentaremos, de maneira resumida, falar um pouco da literatura por trás deste tema tão importante. Definição do DevOps Dentre as várias definições e termos que existem para descrever o DevOps, destaco a minha preferida,atribuída a Amazon: “O DevOps é a combinação de filosofias culturais, práticas e ferramentas que aumentam a capacidade de uma empresa de distribuir aplicativos e serviços em alta velocidade: otimizando e aperfeiçoando produtos em um ritmo mais rápido do que o das empresas que usam processos tradicionais de desenvolvimento de software e gerenciamento de infraestrutura. Essa velocidade permite que as empresas atendam melhor aos seus clientes e consigam competir de modo mais eficaz no mercado.” Essa é uma definição relativamente simples, mas que resume bem o que é trabalhar com DevOps (ou, poderíamos dizer, trabalhar à maneira DevOps). Algumas métricas DevOps Segundo o “State of DevOps – Marketing Segmentation Report (2019)”, criado pela Puppet, times de alta performance que praticam o DevOps na íntegra, têm as seguintes métricas: Frequência de implantações 46x maior; Tempo médio de recuperação 96x maior; Lead Time do commit  ao deploy 440x mais rápido; Taxa de Falha 5x menor; “Dev + Ops” ou “Dev vs Ops”? Desde os primórdios do processo de desenvolvimento de software, podemos dizer, de forma cômica, que uma batalha épica vem sendo travada entre dois mundos. De um lado,  desenvolvedores e programadores (Dev) com algumas tarefas a cumprir: Gerar valor para o negócio com novas funcionalidades a serem desenvolvidas a todo vapor, ou seja, requisitos funcionais. Do outro lado, a equipe de infraestrutura e arquitetura (Ops), também possuindo uma difícil missão: Proteger e sustentar o valor do negócio, que cresce a nível frenético, ou seja, requisitos não funcionais. Certamente,  todos nós, profissionais, buscamos a primeira opção informada no título: “Dev + Ops”. E, para alcançarmos o melhor resultado com essa união, o DevOps prega alguns pilares. Veremos um pouco sobre eles a seguir:  Os Pilares DevOps Dentre os vários conceitos que existem quando falamos de DevOps, podemos destacar: Comunicação; Colaboração; Automação; Monitoração. Comunicação e Colaboração De forma resumida, dentro destes temas, algumas disciplinas aparecem, como: Visibilidade: informar os estados do software a quem é de direito; Rastreabilidade: identificação do processo de ponta-a-ponta (do levantamento de requisitos ao deploy);  Compartilhamento de conhecimento: difundir conhecimento entre as mais diversas áreas. Automação Dentro de automação, podemos destacar: Infra as a Code: provisionamento automatizado de recursos de infraestrutura; Feedbacks constantes: aprendizagem e agilidade nos ajustes; E tudo mais que possa ser automatizado a fim de evitar retrabalho. Monitoração Para finalizar, aqui podemos destacar alguns pontos que a monitoração nos ajuda: Rastreamento: resgate de histórico para investigação e solução de problemas; Alertas: proatividade na resolução de possíveis problemas; Compartilhamento da saúde das aplicações. Outros pontos importantes de serem destacados são: Os times precisam entender do negócio para que um monitoramento efetivo seja feito. Um dashboard que emite um alerta e ninguém verifica não é nada funcional e nem deveria existir; Proatividade ao invés de reatividade: podemos sim ser proativos a ponto de entender que algo está acontecendo e agir antes que o cliente sinta o efeito colateral. É um trabalho árduo, mas possível! Conclusão Os desafios para a implantação de uma cultura DevOps são grandes. No entanto, tendo em mente pontos como colaboração, aprendizagem contínua, feedback e segurança, podemos colocar nossas aplicações em um patamar muito elevado! Em breve teremos mais artigos sobre a literatura DevOps! Gostou de aprender um pouquinho mais sobre esse tema?  Confira mais conteúdos como esse em nosso Blog!