Transformação Ágil: Passo a Passo

Conforme a agilidade vai devorando o mundo, muitas corporações estão se deparando com a necessidade de uma transformação ágil. Para a maioria, este é um grande desafio, envolvendo muitas mudanças ao longo de vários anos. Se a organização tem sido gerenciada de maneira tradicional, a jornada irá incluir mudanças radicais em atitudes, valores, mindsets, jeitos de pensar e jeitos de interagir com o mundo, ou seja, uma mudança na cultura organizacional.

Transformação Ágil: Passo a Passo é uma série de artigos que será publicada ao longo das próximas semanas que tem como intuito auxiliar quem está pensando ou iniciando este processo. Não tenho como pretensão esgotar este assunto, mas sim dar uma luz ao tema com as minhas experiências e com diversos cases que conheço.

Comentários, dúvidas e sugestões são bem vindas na seção de comentários ao final do artigo.

O mundo corporativo atual

A maioria das corporações atuais não são ágeis. Uma pesquisa recente da Deloitte com mais de 10.000 executivos revelou que menos de 10% deles vêem sua organização como realmente ágil.

Por outro lado, mais de 90% deles diz que “agilidade e colaboração” são fatores críticos para o sucesso da sua empresa. Isto reflete as descobertas da McKinsey & Company de que unidades que usam métodos ágeis dão melhores resultados financeiros do que as tradicionais.

O resultado esperado de uma gestão ágil é claro: a habilidade da empresa de se renovar, adaptar, mudar rapidamente de curso e ser bem sucedida no mundo VUCA em que vivemos, para aproveitar melhor as oportunidades.

No entanto, implementar agilidade é um meio, não o fim. O objetivo é permitir que a organização gere valor em escala com a menor fricção possível, de maneira customizada e incremental, livre de riscos e que as recompensas financeiras sejam equivalentes às obtidas pelas empresas de maior e mais rápido crescimento do planeta: Amazon, Apple, Facebook, Google e Microsoft.

Alguns agilistas não esperam pela alta gestão e começam suas jornadas sem uma autoridade central ou recursos. No entanto, esse não é o melhor jeito de começar, sendo o jeito mais difícil de conseguir todo o conhecimento organizacional e capital social para causar um grande impacto. Quem trabalha ou já trabalhou em corporações sabe do que estou falando: a boa e velha política tem um papel fundamental nesse tipo de iniciativa. Implementações ágeis limitadas a pequenas partes da empresa (como alguns times de desenvolvimento) rapidamente entram em conflito com outras partes da organização que estão se movendo mais devagar e algumas vezes são esmagadas antes que possam tomar maiores proporções.

Não é de se admirar que o progresso de agilidade nos negócios está diretamente relacionado com o nível de liderança dos engajados na transformação ágil. Glória Abreu, Master Coach que foi minha orientadora durante uma de minhas formações, fala que “a melhor estratégia é a do chuveiro, nunca a do bidê”. Quem não sabe ou não lembra, os bidês eram aqueles antigos lavatórios de “baixo pra cima”, para limpeza íntima. Sim, é uma analogia sofrível, a Glória adora fazer o pessoal rir, mas é a mais pura verdade.

Transformações ágeis não são feitas por lobos solitários, você irá precisar de uma matilha, e com machos-alfa…digo, executivos junto. Isso se você não quiser que seja apenas fogo em palha.

Quando iniciei uma de minhas transformações mais bem sucedidas eu tinha o patrocínio do diretor de TI e, mais tarde, do CEO da empresa. Jamais teria tido tanto sucesso sozinho.

Pensando na transformação

Por onde começar? A alta gestão precisa começar considerando como a própria gestão da empresa se relaciona com o mundo da agilidade e quais desafios despontam à frente em uma jornada ágil. Isso irá envolver a absorção de alguns exemplares da vasta literatura sobre este assunto e entender a essência da agilidade.

Isso incluirá descobrir quais princípios ágeis já começaram a enraizar em partes da organização, mesmo sob outros nomes. Embora o movimento Agile seja extremamente abrangente em escopo, a maioria das organizações de todos os tamanhos possuem ao menos alguns focos de agilidade, como um ou outro time. Em 2017, eu liderava um destes times ímpares em um dos bancos gaúchos que trabalhei, responsável pelos Canais Digitais da empresa, por isso que fui “encontrado” e recebi o “chamado” para fazer algo maior.

A alta gestão precisa encontrar esses focos e aprender sobre o progresso que eles fizeram até agora e quais problemas estão enfrentando. A alta gestão precisa celebrar quaisquer sucessos que aconteceram para estabelecer as fundações para o futuro. Os líderes desses esforços iniciais são potenciais aliados e campeões para a jornada ágil que se avizinha.

Citando outro exemplo, quando a alta gestão do Barclays começou a olhar para agilidade em 2014, els descobriram que já existia um movimento alternativo de praticantes ágeis dentro da empresa. Em março de 2015, quando os times de operações e tecnologia anunciaram que se tornar ágeis era uma iniciativa estratégica importante, as muitas ilhas de agilidade dentro da Barclays foram convidadas a saírem das sombras e se tornarem campeões da transformação ágil do banco.

Fazer este estudo também ajuda que a alta gestão aprenda com quaisquer falhas em esforços anteriores antes de lançar uma jornada do tipo na companhia. Por que estes esforços falharam? Quais passos necessitarão ser tomados para prevenir esse tipo de falha recorrente? Quais novos riscos devem ser endereçados?

A organização está preparada?

Os patrocinadores também precisarão entender os riscos e benefícios de iniciar uma transformação ágil exatamente agora.

A escala dessa missão pode ser assustadora. Mas a alternativa – morte corporativa através de falha em adaptar-se continuamente ao mercado – pode ser ainda mais arrepiante. Existe um consenso quase geral de que a única opção real é QUANDO mudar, e não SE devemos mudar.

Também é necessário que seja avaliado o risco do formato de implantação. Se for decidido implementar agilidade como uma “receita de bolo”, forçando as pessoas a adotarem processos ágeis porque os executivos ouviram que funciona na empresa X ou porque eles ouviram isso de alguma consultoria, o risco de resistência institucional aumentará consideravelmente. Em mudanças profundas como agilidade, copiar e colar não funciona. Ao invés disso, a empresa precisa fazer a mudança organicamente de dentro pra fora, para que faça mais sentido. A oposição é inevitável em qualquer mudança organizacional, mas ela será ainda maior se vista como uma iniciativa imposta do topo.

Ou seja, além de considerar quando é o melhor momento para começar a transformação, tem de ser verificado o tamanho e intensidade das batalhas que serão travadas internamente.

Não obstante, tem de ser entendidos os conflitos que possam haver entre os objetivos da agilidade – obsessão em entregar valor ao cliente, por exemplo – e a forma como a empresa funciona hoje. Por exemplo, muitas empresas listadas em bolsa trabalham única e exclusivamente para aumentar o valor das ações e/ou o retorno para acionistas.

A alta gestão também tem de decidir como lidarão com a burocracia tradicional de áreas como orçamento, controladoria, compliance, etc. Embora não seja necessário lutar todas estas batalhas no “dia um” da transformação, a alta gestão precisa saber o que enfrentará à frente, incluindo uma ideia de quando estas batalhas serão travadas.

Algumas empresas decidem, depois de considerar todos os riscos, que não é o momento de iniciar uma transformação agora. Esta decisão não é exatamente ruim, afinal é melhor não ir adiante do que começar uma transformação sem estar 100% comprometido, o que geralmente traz implantações falsas de agilidade, que são ágeis apenas no nome e que geralmente bloqueiam iniciativas futuras de uma real transformação.

Buscando ajuda

Ao ponderar se deve prosseguir, os líderes da transformação podem aprender a partir de outras empresas que estão envolvidas em transformações ágeis. Eles podem visitar empresas que já são bem sucedidas em suas jornadas e aprender sobre práticas-chave que valem a pena ser emuladas e quais que evitar. Eventos podem ser úteis para fazer contatos, embora as apresentações costumem apresentar somente o lado bom destas iniciativas, então foque no networking.

Na prática, o que se vê no mercado é que as jornadas ágeis bem sucedidas estão diretamente ligadas à adoção de um mindset ágil, ao invés de um processo ou metodologia específicos. As visitas realizadas pelo SD Learning Consortium mostraram que algumas empresas estavam implementando todas práticas ágeis “by the book”, mas não estavam obtendo muitos benefícios delas. Por outro lado, algumas empresas estavam demonstrando agilidade nos negócios e obtendo benefícios, mesmo que não estivessem rodando as práticas famosas à risca. O fator de diferenciação entre essas empresas não está nas práticas escolhidas mas no fato das pessoas estarem realmente comprometidas a uma ideia diferente de como o trabalho deveria ser feito. É um jeito diferente de pensar, entender e agir no ambiente de trabalho.

Os executivos tem de aprender que uma transformação ágil não é um projeto ou uma iniciativa, ou um novo processo ou nova estrutura organizacional, mas sim uma jornada sem fim, é empreender com um jeito de pensar que é fundamentalmente diferente da hierarquia top-down de comando e controle típica das empresas do século 20.

Além de tudo isso é importante levar em consideração qual terminologia ágil será encorajada. É comum as empresas descobrirem que existem muitos termos diferentes e confusos no mundo ágil. A empresa precisa decidir quais termos não são interessantes para serem utilizados no seu ambiente, incluindo o próprio termo agilidade, além de todo o vocabulário comum como Scrum, Scrum Master, Lean Startup, Kanban, etc. Pode parecer bobo, mas realmente faz a diferença definir os termos que serão utilizados.

No banco que mencionei antes quisemos descolar de uma série de terminologias e principalmente de um método específico, para evitar ranços e discussões no estilo “sexo dos anjos”. Sendo assim, criamos um framework de agilidade em escala feito sob medida e que era composto por um guarda chuva de práticas definidos por uma comunidade interna de agilistas. Isso nos permitiu por quase dois anos avançar na adoção e transformação, sem os reveses de estar preso a uma única terminologia ou processo, como o proposto pelo SAFe.

No próximo artigo da série, vou continuar o passo a passo. Até lá!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto, onde ensino algumas dinâmicas que você pode fazer com seu time!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Dicas para eventos de Team Building

Team Building no Banco Topázio
Team Building no Banco Topázio

Você sabe o que é Team Building?

Team Building ou Construção de Times é o nome dado a várias atividades com o objetivo de integrar mais as pessoas e melhorar os seus relacionamentos em ambientes profissionais. Basicamente elas ajudam a transformar um grupo de pessoas em um time.

Embora construir times possa ser tão simples quanto organizar churrascos e jogos de futebol, a arte de conduzir dinâmicas específicas para team building aumenta e muito os resultados obtidos quando o assunto é construir times vencedores. Quando são bem executadas, é claro.

Com isso em mente e com a experiência de alguns eventos dedicados a esse assunto no currículo, o artigo de hoje foca em ajudar quem esteja buscando organizar.

Nós vamos falar sobre:

  • Preparação
  • Agenda
  • Local
  • Energyzer e Ice Breaker
  • Objetivo Central
  • Feedback
  • Repertório

Vamos lá!

Preparação

Eu dou aulas e treinamentos profissionalmente desde 2010. Certa vez me perguntaram como que eu conseguia fazer com que meus treinamentos durassem exatamente o tempo combinado, como que eu organizava tudo para que não sobrasse e nem faltasse tempo. A resposta é: planeje para o pior, espere o melhor. E isso começa com a preparação.

Absolutamente todas ocasiões que envolvam diversas pessoas sob sua responsabilidade (afinal, esperam que você conduza tudo com maestria) envolve muita preparação. E um team building não é diferente.

O primeiro passo é entender o objetivo do team building. Claro que, de maneira genérica, sempre podemos citar “construção de times”, mas dependendo do momento do time, você pode querer focar em um ou mais dos objetivos abaixo:

  • fazer as pessoas se conhecerem;
  • definir/redefinir papéis e responsabilidades;
  • aumentar a confiança/segurança/união;
  • aumentar a moral/motivação;
  • aumentar o foco na estratégia/negócio;
  • gerar aprendizados sobre um tópico em ambiente controlado;
  • remover crenças limitantes;
  • ressignificar problemas que o time esteja passando;

Com base no objetivo definido, você irá fazer o seu tema de casa usando os tópicos deste artigo como base. Obviamente nada substitui a sua experiência e minha ideia é apenas lhe ajudar com dicas. Certifique-se não apenas de ler todo este artigo e garantir que fez todo tema de casa citado em cada tópico, mas de realmente colocar o seu coração no team building, pois faz toda a diferença e engaja mais as pessoas nas dinâmicas.

Com base no que você irá fazer, liste todos os materiais necessários (muitas atividades exigem material de papelaria, por exemplo) e compre-os com antecedência. Se o evento durar mais que algumas horas, não esqueça de um pequeno coffee, mesmo que seja apenas água, café preto e biscoitos.

Faça um checklist de tudo que é necessário para o seu team building acontecer com 100% de sucesso. Coloque no papel inclusive o que você espera que gere de resultados no final do dia. Se prepare para imprevistos como ausência de algumas pessoas, estouro de timebox ou dinâmica que acaba antes do que o esperado.

O ritmo de um bom evento de team building é intenso, então prepare-se para poder beber bastante água (eleve uma garrafinha) e usar roupa confortável (principalmente tênis). O evento depende que a sua saúde e disposição estejam 100% e por causa disso, uma outra recomendação que eu deixo para você é pedir ajuda de alguém, não apenas para organizar mas para conduzir no dia.

Se você quiser investir, eu recomendo ter um apito, um passador de slides com laser e um cronômetro de LED. Eu uso os três em meus eventos e faz toda a diferença no profissionalismo e na praticidade.

Agenda

Estruturar uma boa agenda, independente da natureza da ocasião (team building, treinamentos, etc), é como escrever uma boa história. Deve ter início, meio e fim. Deve ter uma introdução que prepare as pessoas para que o vai vir, deve ter o clímax e deve ter um fechamento que maximize a experiência como um todo. Já ouviu falar na Jornada do Herói ou Monomito de Joseph Campbell? Ou então nos 3 Atos de Aristóteles? São estruturas de narrativa para construir boas histórias e podem lhe ajudar com o team building também.

Basicamente construir a agenda consiste em responder às seguintes perguntas:

  • como que vamos explicar o evento?
  • como que vamos começar o evento?
  • como que vamos tirar as pessoas da sua zona de conforto?
  • o que vamos focar neste team building?
  • o que queremos melhorar neste time?
  • teremos alguma pausa para descanso (geralmente no meio)?
  • como que vamos fechar o evento?
  • como que vamos re-energizar as pessoas se for necessário?

Com essas perguntas respondidas, fica bem mais fácil de construir a agenda. Você terá de fazer umas contas de padeiro: pegue o total de tempo que terá disponível e quebre em no mínimo 3 partes: início, meio e fim. Não precisam ser blocos de tamanho idêntico, mas o tempo que você determinar deve ser adequado para a condução de cada atividade, embora muitas atividades sejam “flexíveis”.

Eu costumo colocar esta agenda em um PPT e apresento ela logo no início do evento, para deixar todos cientes e para mostrar que o tempo de execução de cada bloco importa, ou seja, que você vai ser um tanto rígido para que consigam cumprir todos objetivos.

Tempo recomendado?  Você pode combinar atividades de team building simples em todo tipo de evento do seu time, mas se quiser fazer algo dedicado a team building, sugiro no mínimo um turno (manhã ou tarde) inteiro e no máximo um dia inteiro de trabalho. Imersões de mais de um dia são possíveis, mas tendem a diminuir os resultados lá pela metade do segundo dia. Experiência de quem já participou de algumas imersões, de até 4 dias.

Você pode aproveitar a apresentação da agenda para mostrar os combinados do evento também. Não julgar, foco nas dinâmicas, sair do local para atender celular, etc. O que é combinado com antecedência não fica chato de cobrar depois.

Local

Via de regra, sair do local de trabalho é sempre uma boa se você quiser que as pessoas realmente estejam “presentes” no team building.

Falando de infraestrutura, varia muito conforme as dinâmicas que for fazer. Um Marshmallow Challenge, por exemplo, exige mesas. Já um Jogo dos Símbolos, exige cadeiras e um espaço aberto para montar o esquema do jogo. Estude bem as dinâmicas que pretende aplicar para que possa escolher o local adequadamente.

É bom que neste local você tenha um canto para deixar água, café e talvez algo para “beliscar” sempre próximo das pessoas, o que evita que elas se ausentem frequentemente por motivos simples como se hidratar ou se “cafeinar”.

Energyzer e Ice Breaker

Existem dois tipos de dinâmicas que são presença obrigatória em Team Buildings: energyzers e ice breakers.

Os energyzers são para levantar o astral, fazer o pessoal se mexer e geralmente são utilizados quando o dia está meio parado demais, quando sente-se que o ânimo da galera está baixo ou apenas quando se quer “quebrar o padrão”. Qualquer atividade que faça as pessoas levantarem de suas cadeiras e mexerem um pouco (ou muito) o corpo, já resolve. Atividades como Corrente Humana, Campeonato de Jo-Ken-Pô ou dinâmicas com balões já resolvem.

Já os ice breakers possuem o intuito de fazer as pessoas darem risadas, conhecerem umas às outras e criar algum tipo de sinergia entre os participantes, mesmo que seja o primeiro dia deles juntos. Ao contrário dos energyzers que podem ser usados a qualquer momento, ice breakers costumam ser usados no início do dia apenas. Dinâmicas como o Brasão Pessoal, Paulo Pontual o até 2 Verdades 1-Mentira dão conta do recado.

Inclua uma quantidade suficiente destas dinâmicas conforme a duração do seu team building. A sugestão é ter uma de cada, no mínimo, para cada dia de team building. O ice breaker no início da manhã e o energyzer na volta do almoço.

Objetivo Central

Cada team building deve ter um objetivo claro, como já citei lá na preparação. Baseado nesse objetivo você vai construir o núcleo central do evento, geralmente executado após alguma apresentação ou dinâmica menor, que serve de aquecimento.

Para que o objetivo central seja alcançado com sucesso, é importante que a dinâmica escolhida seja poderosa, provoque nos integrantes os sentimentos, situações, conflitos e aprendizados que você deseja para alcançar o objetivo central. Sua escolha é crucial para o sucesso do mesmo.

Com a(s) dinâmica(s) escolhida(s), tenha muita atenção ao briefing que você vai dar, como vai explicar a dinâmica para todo o grupo. Muitas dinâmicas excelentes produzem resultados desastrosos se não forem bem explicadas. Se envolverem algum tipo de competição, pior ainda.

Além do briefing, é importantíssimo o debriefing ao final da dinâmica. Dinâmicas sem aprendizados compartilhados em uma boa sessão de debriefing (boa, não necessariamente longa) acabam virando apenas diversão. E diversão pode até fazer parte do team building, mas não é o objetivo central.

Questione o que eles aprenderam. Como se sentiram. O que fariam de diferente. O que podem fazer de analogias com o que acontece no dia a dia da empresa. O que notaram agora que não tinham notado antes. O seu papel enquanto facilitador aqui é fazer as perguntas certas, para que as pessoas se exponham e todo o grupo ganhe com os aprendizados coletivos.

Marshmallow Challenge
Marshmallow Challenge

Feedback

Pensando em melhorar continuamente (kaizen na veia), é muito importante coletar o feedback dos participantes. Tanto na hora, ao encerrar o evento, quanto mais tarde, com mais calma, via surveys online ou similares.

Nada de mirabolante aqui. Faça um mix de perguntas abertas e fechadas que não tem erro. Agradeça todo tipo de feedback, positivo ou negativo, aprenda com seus erros, considere as sugestões e melhore no próximo.

Repertório

Você deve ter notado que mais de uma vez eu falei nomes de dinâmicas. Talvez você conheça algumas que citei, talvez não. O fato é que ter um bom repertório de dinâmicas é essencial para um agilista (Scrum Master, Agile Coach, etc) ou para qualquer pessoa em função de facilitação, como treinadores, professores, consultores e por aí vai.

O repertório de dinâmicas do facilitador é que nem uma caixa de ferramentas. Quanto mais equipada ela estiver, em mais situações diferentes ela se tornará útil. Abaixo, listarei algumas fontes de inspiração para dinâmicas e ferramentas que uso e se tiver outras sugestões, deixe nos comentários!

Você não precisa saber de cor estas dinâmicas, mas sim saber onde procurar. Pelo menos é a forma como eu trabalho a construção de meus eventos de team building e treinamentos em geral. Espero que esse artigo tenha lhe ajudado a organizar os seus.

Um abraço e até a próxima!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto, onde ensino algumas dinâmicas que você pode fazer com seu time!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

O guia completo do package.json do Node.js

NPM
NPM

O package.json é um elemento-chave em muitas aplicações do ecossistema Node.js. Se você trabalha com JavaScript, ou se você já interagiu com um projeto JavaScript antes, Node.js ou front-end, você certamente já se deparou com um arquivo package.json.

Para quê ele serve?

O que você deveria saber sobre ele e que coisas legais pode fazer com ele?

O package.json é uma espécie de manifesto do seu projeto. Ele pode fazer várias coisas, completamente não relacionadas. Ele é um repositório central de configurações de ferramentas, por exemplo. Ele também é onde npm armazena os nomes e versões dos pacotes instalados.

Neste artigo você vai ver:

Vamos lá!

A estrutura do arquivo

Aqui temos um exemplo de arquivo package.json válido:

Está vazio Não existem exigências fixas do que deve estar em um arquivo package.json para uma aplicação. O único requisito é que ele respeite o formato JSON, de outra maneira ele não poderá ser lido pelos programas que tentarem acessar suas propriedades programaticamente. Se você está construindo um pacote Node.js que você quer distribuir através do npm, as coisas mudam radicalmente e você deve ter um conjunto de propriedades que ajudem outras pessoas a usá-lo. Veremos mais sobre isso mais tarde. Este é outro package.json válido:

Ele define uma propriedade name, que diz o nome da aplicação ou pacote, que está contido na mesma pasta onde o arquivo vive. Aqui temos um exemplo muito mais complexo, o qual eu extraí de uma aplicação Vue.js de exemplo:

Existem muitas coisas acontecendo aqui:

  • name define o nome da aplicação ou pacote;
  • version indica a versão atual;
  • description é um resumo da sua aplicação/pacote;
  • main define o ponto de entrada da aplicação;
  • private (true) previne a sua aplicação de ser publicada acidentalmente no npm;
  • scripts define um conjunto de scripts Node para você executar;
  • dependencies define uma lista de pacotes npm instalados como dependências;
  • devDependencies define uma lista de pacotes npm instalados como dependências de desenvolvimento;
  • engines define quais versões de Node este pacote/aplicação funciona;
  • browserslist é usado para dizer quais browsers (e versões) você quer suportar;

Todas estas propriedades são usadas tanto pelo npm quanto por outras ferramentas que podemos usar.

Detalhando as propriedades

Esta seção descreve as propriedades que você pode usar em detalhes. Eu refiro várias vezes a pacote, mas a mesma coisa se aplica a aplicações locais que você não use como pacote. A maioria destas propriedades são usadas somente no site do npm. Outras são usadas por scripts que interagem com seu código, como npm ou outros. name Define o nome do pacote. Ex:

O nome deve ser menor que 214 caracteres, não pode ter espaços e somente pode conter letras minúsculas, hífens (-) ou underscore (_).

Isto tudo porque quando um pacote é publicado no npm, ele ganha sua URL baseado nesta propriedade. Se você publicou este pacote publicamente no GitHub, um bom valor para esta propriedade é o nome do repositório. author Exibe o nome do autor do pacote. Ex:

Também pode ser usado neste formato:

contributors

Assim como o autor, o projeto pode ter um ou mais contribuidores. Esta propriedade é uma array que os lista:

Pode também ser ussado neste formato:

bugs

Links para o issue tracker do pacote, geralmente uma página de issues no GitHub. Ex:

homepage

Define a página inicial do pacote. Ex:

version

Indica a versão atual do pacote. Ex:

Esta propriedade segue a notação semântica de versionamento (semver), o que significa que a versão é sempre expressada com três números: x.x.x.

O primeiro número é a versão principal, o segundo é a versão secundária e o terceiro é a versão do patch.

Existe um significado nestes números: uma release que somente corrija bugs é uma release patch, uma release que introduza mudanças na compatibilidade retroativa é uma release secundária e uma release principal é aquela que pode quebrar compatibilidade.

license Indica a licença do pacote. Ex:

keywords Esta propriedade contém um array ou palavras-chave associados com o que seu pacote faz. Ex:

Isto ajuda as pessoas a encontrar o seu pacote quando estiverem procurando pacotes similares ou quando navegam pelo site do npm.

description

Esta propriedade contém um resumo do pacote. Ex:

Isto é especialmente útil se você decidir publicar seu pacote para o npm, visando que outras pessoas possam descobrir o que este pacote faz.

repository Esta propriedade especifica onde o repositório do pacote está localizado. Ex:

Note o prefixo github. Existem outros serviços populares também:

Você pode explicitamente definir o controle de versão do sistema:

Você também pode usar diferentes sistemas de controle de versão:

main Define o ponto de entrada do pacote. Quando você importa este pacote em uma aplicação, é essa aplicação que a aplicação irá buscar pelo module.exports. Ex:

private Se definido como true, previne que a aplicação/pacote seja acidentalmente publicada no npm. Ex:

scripts Define um conjunto de scripts node que você pode executar. Ex:

Estes scripts são aplicações de linha de comando. Você pode rodá-los usando npm run XXXX, onde XXXX é o nome do comando. Ex:

Você pode usar qualquer nome que você quiser para um comando, e os scripts podem ser literalmente qualquer coisa que você quiser.

dependencies

Define uma lista de pacotes npm instalados como dependências. Quando você instalar um pacote usando npm:

o pacote será automaticamente inserido nesta lista. Exemplo:

devDependencies

Define uma lista de pacotes npm instalados como dependências de desenvolvimento. Eles diferem de dependencies porque eles serão instalados somente em máquinas de desenvolvimento, não necessárias para executar o código em produção.

Quando você instalar um pacote usando npm:

o pacote será automaticamente inserido nessa lista. Exemplo:

engines

Define quais versões de Node.js e outros comandos que este pacote ou aplicação suporta. Exemplo:

browserslist

É usado para dizer quais browsers (e suas versões) você quer suportar. Ele é referenciado pelo Babel, Autoprefixer, e outras ferramentas, para somente adicionar os polyfills e fallbacks necessários aos navegadores-alvo. Exemplo:

Esta configuração significa que você quer suportar ao menos as duas versões principais de todos os browsers com ao menos 1% de uso no mercado (as estatísticas são do CanIUse.com ), exceto IE8 e inferiores (saiba mais no browserslist do NPM).

Comandos específicos de propriedades

O arquivo package.json também pode hospedar configurações de comandos específicos, por exemplo Babel, ESLint, e muito mais.

Cada um possui uma propriedade específica, como eslintConfigbabel e outros. Estes são comandos específicos e você pode encontrar como usá-los na documentação do respectivo comando ou projeto.

Versões de Pacote

Eu já falei sobre isso extensivamente neste artigo aqui.

O arquivo package-lock.json

Na versão 5 o NPM introduziu o arquivo package-lock.json, que é automaticamente gerado quando você instala pacotes Node.

O que ele faz? Você provavelmente sabe tudo sobre o arquivo package.json a essa altura, o que é bem mais comum e está aí há bem mais tempo.

O objetivo deste arquivo é manter registro das versões exatas de cada pacote que é instalado para que um produto possa ser 100% reproduzível da mesma maneira mesmo se os pacotes forem atualizados por seus mantenedores.

Isto soluciona um problema bem específico que o package.json não resolvia. No package.json você pode definir quais versões você quer atualizar, usando a notação semver, por exemplo:

  • se você escrever ~0.13.0, você quer somente atualizar patch releases: 0.13.1 está ok, mas 0.14.0 não.
  • se você escrever ^0.13.0, você quer atualizar patches e minor releases: 0.13.10.14.0 e assim por diante.
  • se você escrevere 0.13.0, você somente usará esta versão exata do pacote.

Você não commita no Git a sua pasta node_modules, uma vez que ela é geralmente muito grande, e quando você tenta replicar o projeto em outra máquina usando o comando npm install, se você especificar a sintaxe ~ e uma patch release de um pacote tiver sido lançada, ela será instalada. O mesmo para  ^ e minor releases.

Se você especificar as versões exatas, como 0.13.0 neste exemplo, você não sofre desse problema.

Além poder ser um problema para você, pode ser um problema para outra pessoa qualquer querendo rodar o seu projeto com npm install, podendo acontecer do seu projeto original ficar diferente da nova instalação. Isto implica obviamente em possíveis bugs, mesmo que seja um patch ou minor release.

O arquivo package-lock.json define as versões instaladas de cada pacote de maneira irreversível e o npm usará exatamente estas versões quando você rodar npm install.

Este conceito não é novo e outros gerenciadores de pacotes de linguagens de programação (como o Composer do PHP) usam um sistema semelhante por anos.

O arquivo package-lock.json precisa ser commitado no Git para que possa ser baixado por outras pessoas. E se precisar atualizar as versões das dependências no package-lock.json, basta rodar npm update.

Espero que este artigo tenha sido útil para você que está aprendendo Node.js Para conteúdo mais aprofundado, recomendo meus livros. Para videoaulas, recomendo o meu curso online.

Curso Node.js e MongoDB
Curso Node.js e MongoDB