Menu

ADOTE?

  • A adoção contínua de contêineres para implantação, especialmente Docker, fez do escaneamento de segurança de contêiner uma técnica obrigatória, e movemos esta técnica para o anel Adote para refletir isso. Especificamente, os contêineres introduziram um novo caminho para questões de segurança, e é essencial que você use ferramentas para escanear e verificar contêineres durante os deploys. Preferimos usar ferramentas de escaneamento automatizadas, que rodam como parte da pipeline de implantação.

    Histórico
  • Hoje em dia, a resposta de muitas organizações para destravar dados para uso analítico é construir um labirinto de pipelines de dados. Pipelines recuperam dados de uma ou múltiplas fontes, limpam e então os transformam e os movem para outro local para uso. Essa abordagem para gerenciamento de dados frequentemente deixa as pipelines de consumo com a difícil tarefa de verificar a integridade dos dados de entrada e construir uma lógica complexa para limpar os dados e atender o nível necessário de qualidade. O problema fundamental é que a fonte dos dados não tem incentivo e responsabilidade por fornecer dados de qualidade para seu público consumidor. Por isso, defendemos fortemente a integridade dos dados na origem , ou seja, qualquer fonte que forneça dados consumíveis deve descrever suas medidas de qualidade de dados explicitamente e garanti-las. A principal razão por trás disso é que os sistemas e times de origem são mais intimamente ligados com seus dados e mais bem posicionados para corrigir na fonte. A arquitetura de malha de dados vai um passo além, comparando dados consumíveis a um produto, onde a qualidade de dados e seus objetivos são atributos integrais de cada conjunto de dados compartilhado.

    Histórico
  • Temos visto significativos benefícios de se introduzir microsserviços, que permitiram que times escalassem a entrega de serviços mantidos e implantados independentemente. Infelizmente, também vimos muitos times criarem um monólito de front-end – uma grande aplicação de navegador confusa que fica em cima de serviços de back-end –, neutralizando fortemente os benefícios dos microsserviços. Os micro-frontends continuaram a ganhar popularidade desde que foram introduzidos. Temos visto muitos times adotarem alguma forma dessa arquitetura como uma maneira de gerenciar a complexidade de múltiplos desenvolvedores e times contribuindo para a mesma experiência do usuário. Em junho deste ano, um dos criadores dessa técnica publicou um artigo introdutório que serve como uma referência para micro-frontends. Ele mostra como esse estilo pode ser implementado usando-se vários mecanismos de programação web e constrói uma aplicação de exemplo usando o React.js. Estamos confiantes de que este estilo vai crescer em popularidade à medida que grandes organizações tentam dividir o desenvolvimento UI entre múltiplos times.

    Histórico
  • O uso de pipelines de entrega contínua para orquestrar o processo de release para software se tornou um conceito comum. Ferramentas de CI/CD podem ser usadas para testar a configuração do servidor (ex.: cookbooks do Chef, módulos Puppet, playbooks do Ansible), construção de imagem do servidor (ex.: Packer), provisionamento de ambiente (ex.: Terraform, CloudFormation) e a integração de ambientes. O uso de pipelines para infraestrutura como código permite que você encontre erros antes das mudanças serem aplicadas em ambientes operacionais – incluindo ambientes usados para desenvolvimento e teste. Elas também oferecem uma maneira de assegurar que o ferramental de infraestrutura seja executado consistentemente, usando agentes de CI/CD em vez de estações de trabalho individuais. Nossos times têm tido bons resultado adotando essa técnica em seus projetos.

    Histórico
  • Automatizar a estimativa, rastreamento e projeção do custo de execução de uma infraestrutura de nuvem é necessário para as empresas de hoje. Os modelos de precificação sagazes dos fornecedores de nuvem, combinados com a proliferação dos parâmetros de precificação e a natureza dinâmica da arquitetura atual podem levar a um custo de execução surpreendentemente caro. Por exemplo, os preços de arquiteturas sem servidor baseadas em chamadas de API, soluções de streaming de eventos baseadas em tráfego ou clusters de processamento de dados baseados em trabalhos em execução, todos têm uma natureza dinâmica que muda com o tempo à medida que a arquitetura evolui. Quando nossos times gerenciam infraestruturas na nuvem, implementar custo de execução como função de aptidão arquitetural é uma das primeiras atividades. Isso significa que nossos times podem observar o custo de executar serviços em relação ao valor entregue. Quando observam divergências em relação ao que era esperado ou aceitável, discutem se é hora de evoluir a arquitetura. A observação e o cálculo do custo de execução são implementados como uma função automatizada.

    Histórico
  • Ao adotarem a entrega contínua com sucesso, os times se esforçam para deixar os vários ambientes de teste o mais parecidos possível com o de produção. Isso os permite evitar um grupo de bugs que, caso contrário, apareceria apenas no ambiente de produção. Isso também vale para software desenvolvido para sistemas embarcados e Internet das Coisas. Se nós não executarmos nossos testes em ambientes realistas, podemos encontrar alguns bugs pela primeira vez somente em produção. Testar usando dispositivos reais ajuda a evitar esse problema ao assegurar que os dispositivos certos estão disponíveis na pipeline de entrega contínua.

    Histórico

EXPERIMENTE?

  • O poder e a promessa do aprendizado de máquina criaram uma demanda por expertise que ultrapassa a quantia de cientistas de dados que se especializam nessa área. Em resposta a essa lacuna de habilidades, temos visto o aparecimento de ferramentas de aprendizado de máquina automatizado (AutoML) que têm como objetivo tornar mais fácil para quem não é especialista automatizar o processo de ponta-a-ponta de seleção e treinamento do modelo. Exemplos incluem o AutoML do Google, o DataRobot, e a interface H2O AutoML. Embora tenhamos visto resultados promissores com essas ferramentas, aconselhamos as empresas a não vê-las como a soma total necessária em sua jornada em aprendizado de máquina. Como dito no site do H2O, “ainda há um bom pedaço de conhecimento e background em ciência de dados que é necessário para produzir modelos de aprendizado de máquina de alta performance”. Confiar cegamente em técnicas automatizadas também aumenta o risco de introduzir vieses éticos ou tomar decisões que colocam minorias em desvantagem. Embora as empresas possam usar essas ferramentas como ponto de partida para gerar modelos úteis, treinados, encorajamos que elas procurem cientistas de dados com experiência para validar e refinar os resultados.

    Histórico
  • À medida que o uso de contêineres, a implantação de grandes frotas de serviços por times autônomos e a velocidade aumentada da entrega contínua vão se tornado uma prática comum para muitas organizações, surge a necessidade de controles de segurança de software automatizados para o momento da implantação. O atestado binário é uma técnica para implementar controle de segurança para a implantação, verificando criptograficamente que uma imagem binária está autorizada para implantação. Usando essa técnica, um atestador, um processo de compilação automatizado ou um time de segurança podem aprovar os binários que passaram nos testes e verificações de qualidade requeridos e estão autorizados para implantação. Serviços como o GCP Autorização Binária, ativado pelo Grafeas, e ferramentas com in-toto e Docker Notary suportam a criação de atestados e a validação de assinatura de imagens antes da implantação.

    Histórico
  • Com a popularidade crescente das aplicações baseadas em aprendizado de máquina e a complexidade técnica envolvida na sua construção, nossos times dependem fortemente de entrega contínua para aprendizado de máquina (CD4ML) para entregar tais aplicações com segurança, rapidez e de maneira sustentável. CD4ML é a disciplina de trazer princípios e práticas da entrega contínua para aplicações de aprendizado de máquina. Ela remove ciclos longos entre treinar modelos e colocá-los em produção. A CD4ML remove as entregas manuais entre diferentes times, pessoas engenheiras de dados, cientistas de dados e engenheiras de aprendizado de máquina no processo ponta-a-ponta de construir e implantar um modelo atendido por um aplicativo. Usando CD4ML, nossos times têm implementado com sucesso versionamento, testes e implantação automatizados de todos os componentes de aplicativos baseados em aprendizado de máquina: dados, modelo e código.

    Histórico
  • Um dos principais pontos de atrito para cientistas de dados e analistas em seu fluxo de trabalho é localizar os dados de que precisam, entendê-los e avaliar se são confiáveis para uso. Isso permanece um desafio devido aos metadados faltantes sobre as fontes de dados disponíveis e falta de funcionalidade adequada para pesquisar e localizar os dados. Encorajamos times que estão fornecendo conjuntos de dados analíticos ou construindo plataformas de dados a tornar a detecção de dados uma função de primeira classe de seus ambientes, para fornecer a habilidade de localizar facilmente dados disponíveis, detectar sua qualidade, entender sua estrutura e linhagem e ter acesso a eles. Tradicionalmente, essa função tem sido fornecida por soluções de catalogação de dados inchadas. Nos últimos anos, temos visto o crescimento de projetos de código aberto que estão melhorando a experiência de desenvolvimento tanto para fornecedores quanto para consumidores de dados para fazer uma coisa muito bem: tornar os dados detectáveis. O Amundsen, da Lyft, e o WhereHows, do Linkedin, estão entre essas ferramentas. O que gostaríamos de ver é uma mudança no comportamento dos fornecedores para compartilharem intencionalmente os metadados que ajudam na descoberta em favor de ferramentas de detecção que inferem informações de metadados parciais de silos de bases de dados de aplicações.

    Histórico
  • Muitos times e organizações não têm uma maneira formal ou consistente de rastrear dependências técnicas em seu software. Esse problema frequentemente aparece quando esse software precisa ser alterado, momento em que o uso de uma versão desatualizada de uma biblioteca, API ou componente vai causar problemas ou atraso. A função de aptidão para controle de dependências é uma técnica para introduzir uma específica função de aptidão de arquitetura evolutiva para rastrear essas dependências com o tempo, dando assim um indicativo do possível trabalho necessário e se um problema em potencial está melhorando ou piorando.

    Histórico
  • À medida que o desenvolvimento de aplicativos se torna cada vez mais dinâmico e complexo, é um desafio alcançar a entrega eficaz de produtos acessíveis e utilizáveis que sejam consistentes em estilo. Os sistemas de design definem uma coleção de padrões de design, bibliotecas de componentes e bons designs e práticas de engenharia que asseguram essa consistência no desenvolvimento de produtos digitais. Achamos que sistemas de design são um acréscimo útil a nossa caixa de ferramentas quando trabalhamos com múltiplos times e disciplinas em desenvolvimento de produto, porque permite que times foquem em desafios mais estratégicos acerca do produto em si, sem a necessidade de reinventar a roda toda vez que precisam de um componente visual. Os tipos de componentes e ferramentas que você usa para criar sistemas de design podem variar imensamente.

    Histórico
  • O trabalho diário em aprendizado de máquina frequentemente inclui uma série de experimentos na seleção de uma abordagem de modelagem, topologia de rede, treinamento de dados e várias otimizações ou ajustes no modelo. Pelo fato de muitos desses modelos serem ainda difíceis de interpretar ou explicar, cientistas de dados devem usar sua experiência e intuição para criar hipóteses de mudanças e então medir o impacto que essas mudanças têm no desempenho global do modelo. Conforme esses modelos se tornam cada vez mais comuns nos sistemas de negócios, várias ferramentas de rastreamento experimentais para aprendizado de máquina surgiram para ajudar investigadores a monitorar esses experimentos e trabalhar neles metodicamente. Embora não tenha surgido uma vencedora, ferramentas como MLflow ou Weights & Biases e plataformas como Comet ou Neptune introduziram rigor e repetibilidade em todo o fluxo de trabalho do aprendizado de máquina. Elas também facilitam a colaboração e ajudam a ciência de dados a se transformar de uma empreitada solitária em um esporte coletivo.

    Histórico
  • Redes neurais profundas têm demonstrado desempenho e precisão notáveis em uma gama ampla de problemas. Dada a quantidade suficiente de dados de treinamento e uma topologia escolhida adequadamente, esses modelos atendem e excedem as capacidades humanas em certos espaços de problemas específicos. Contudo, eles são inerentemente obscuros. Embora partes de modelos possam ser reusadas por meio da transferência de aprendizado, raramente somos capazes de atribui significado inteligível por pessoas para estes elementos. Em contraste, um modelo explicável nos permite dizer como uma decisão foi tomada. Por exemplo, uma árvore de decisão produz uma cadeia de inferência que descreve o processo de classificação. A explicabilidade se torna crítica em certas indústrias reguladas ou quando nos preocupamos com o impacto ético de uma decisão. À medida que estes modelos são incorporados mais amplamente a importantes sistemas de negócios, é importante considerar a explicabilidade como critério de seleção de modelo de primeira classe. Apesar de seu poder, redes neurais podem não ser uma escolha adequada quando os requisitos de explicabilidade forem rigorosos.

    Histórico
  • Políticas de segurança são regras e procedimentos que protegem nossos sistemas de ameaças e interrupções. Por exemplo, políticas de controle de acesso definem e fazem cumprir quem pode acessar quais serviços e recursos sob quais circunstâncias; já políticas de segurança de rede podem dinamicamente limitar a taxa de tráfego de um serviço específico. A complexidade do cenário de tecnologia atualmente exige o tratamento das políticas de segurança como código : definir e manter as políticas sob sistemas de controle de versão, validá-las automaticamente, implantá-las automaticamente e monitorar suas performances. Ferramentas como a Open Policy Agent, ou plataformas como Istio oferecem maneiras flexíveis de definição e execução de tais políticas e suportam a prática de políticas de segurança como código.

    Histórico
  • Muitas das soluções técnicas que construímos hoje rodam em ambientes cada vez mais complexos de polycloud ou nuvem híbrida com múltiplos componentes e serviços distribuídos. Sob essas circunstâncias, usamos dois princípios de segurança no começo de uma implementação: rede com zero confiança, ou seja, nunca confie na rede e sempre verifique; e o princípio do mínimo privilégio, dando o mínimo de permissões necessárias para realizar um trabalho em particular. Os sidecars para segurança de terminal são uma técnica comum que usamos para implementar esses princípios para aplicar controles de segurança em cada terminal de componente (ex.: APIs de serviços, armazéns de dados ou interface de controle Kubernetes). Fazemos isso usando um sidecar fora do processo – um processo ou um contêiner que é implantado ou agendado com cada serviço, compartilhando o mesmo contexto de execução, hospedagem e identidade. Open Policy Agent e Envoy são ferramentas que implementam essa técnica. Sidecars para segurança de terminal minimizam a área de cobertura confiável para um terminal local, em vez do perímetro de rede. Gostamos de ver a responsabilidade da configuração da política de segurança do sidecar com o time que é responsável pelo terminal e não um time centralizado separado.

    Histórico
  • Zhong Tai é um chavão na indústria de TI chinesa há anos, mas ainda não se popularizou no Ocidente. Em essência, Zhong Tai é uma abordagem para entregar modelos de negócios encapsulados. É projetada para ajudar uma nova classe de pequenos negócios a entregar serviços de primeira classe sem os custos de umas infraestrutura empresarial tradicional, permitindo que organizações existentes tragam serviços inovadores para o mercado em uma velocidade vertiginosa. A estratégia Zhong Tai foi originalmente proposta pelo Alibaba e logo foi seguida por muitas empresas de Internet chinesas, pois seu modelo de negócio é digitalmente nativo para se replicar para novos mercados e setores. Hoje em dia, mais empresas chinesas estão usando Zhong Tai como uma alavanca para a transformação digital.

    Histórico

AVALIE?

  • BERT significa Bidirectional Encoder Representations from Transformers. É um novo método de pré-treino de representações de linguagem que foi publicado por pesquisadores do Google, em outubro de 2018. BERT alterou significativamente o panorama do processamento de linguagem natural (NLP, em inglês) ao obter resultados de ponta em NLP. Baseado na arquitetura Transformer, ele aprende com contexto do lado esquerdo e do lado direito de um token durante o treinamento. O Google também lançou modelos BERT de uso geral pré-treinados em um grande corpo de texto sem tags, incluindo a Wikipedia. Pessoas desenvolvedoras podem usar e ajustar esses modelos pré-treinados em seus dados para tarefas específicas e conseguir grandes resultados. Falamos sobre transferir aprendizado para NLP em nossa edição de abril de 2019 do Radar. O BERT e seus sucessores continuam a fazer da transferência de aprendizado para NLP uma área muito empolgante, com significativa redução do esforço para usuários lidando com classificação de texto.

    Histórico
  • A malha de dados é um paradigma arquitetônico que destrava dados analíticos em escala, rapidamente desbloqueando o acesso a um número cada vez maior de conjuntos de dados de domínio distribuído, para uma proliferação de cenários de uso, tais como aprendizado de máquina, analytics ou aplicações com uso intensivo de dados em toda a organização. A malha de dados aborda os modos que comumente falham no tradicional e centralizado lago de dados ou na arquitetura de plataforma de dados, com uma mudança do paradigma centralizado de um lago ou seu predecessor, o armazém de dados. A malha de dados muda para um paradigma baseado na arquitetura moderna distribuída: considerar domínios como a principal preocupação, usando mentalidade de plataformas para criar uma infraestrutura de dados de autosserviço, tratando dados como um produto e implementando a padronização padrão para permitir um ecossistema de produtos de dados distribuídos interoperáveis.

    Histórico
  • No último ano, temos visto uma mudança no interesse pelo aprendizado de máquina e redes neurais profundas, em particular. Até agora, o desenvolvimento de ferramentas e técnicas tem sido guiado pela empolgação gerada pelas capacidades notáveis desses modelos. Atualmente, contudo, há uma preocupação crescente de que esses modelos possam causar prejuízo não-intencional. Por exemplo, um modelo pode ser treinado para tomar decisões de crédito lucrativas simplesmente excluindo pessoas candidatas desfavorecidas. Felizmente, estamos vendo um interesse crescente em testes de viés ético , que ajudarão a descobrir decisões potencialmente prejudiciais. Ferramentas, tais como lime, AI Fairness 360 ou What-If podem ajudar a descobrir imprecisões que resultam de grupos sub-representados em dados de treinamento, enquanto ferramentas de visualização como Google Facets ou Facets Dive podem ser usadas para descobrir subgrupos dentro de um conjunto de dados de treinamento. Contudo, esse é um campo em desenvolvimento e esperamos que os padrões e práticas específicas para testes de viés ético surjam com o tempo.

    Histórico
  • Treinamento de modelo geralmente requer coleta e transporte de dados de sua fonte para uma localização centralizada onde o algoritmo de treinamento é executado. Isso se torna particularmente problemático quando os dados em treinamento consistem de informações pessoalmente identificáveis. Estamos otimistas com o aparecimento do aprendizado federado como um método de treinamento que preserva a privacidade em um grande conjunto de dados relacionados a indivíduos. As técnicas de aprendizado federado permitem que os dados permaneçam no dispositivo do usuário, sob seu controle, e ainda contribuindo para um conjunto de dados de treinamento. Assim, cada dispositivo do usuário atualiza um modelo independentemente; então, os parâmetros do modelo, em vez dos dados em si, são combinados em uma visualização centralizada. Largura de banda e limitações computacionais do dispositivo apresentam desafios técnicos significativos, mas gostamos da maneira que o aprendizado federado deixa o usuário no controle de sua própria informação pessoal.

    Histórico
  • A tendência que começou como backend como serviço para aplicações mobile nativas muitos anos atrás está agora se tornando popular nas aplicações web. Estamos vendo frameworks como Gatsby.js, que combina geração de site estático com renderização do lado do cliente com APIs de terceiros. Chamado de JAMstack (o JAM significa: J avaScript, A PI, e M arkup), essa abordagem pode fornecer experiências ricas para o usuário em aplicações web que dependem, na maioria das vezes, de APIs e ofertas SaaS. Pelo fato de o HTML ser renderizado tanto no browser de web ou no momento da compilação, o modelo de implantação é o mesmo de sites gerados de forma totalmente estática, com todos seus benefícios: a superfície de ataque no servidor é pequena e uma ótima performance pode ser alcançada com baixo uso de recursos. Essas implantações são também ideais para uma rede de entrega de conteúdo. Na verdade, brincamos com a ideia de rotular essa técnica como aplicações CDN first.

    Histórico
  • Parear registros de diferentes fornecedores de dados na presença de uma chave compartilhada é algo trivial. Contudo, nem sempre você vai ter uma chave compartilhada e, mesmo que tenha, pode não ser uma boa ideia expô-la por questões de privacidade. O pareamento de registros para preservação de privacidade usando o filtro Bloom (uma estrutura de dados probabilísticos com eficiência de espaço) é uma técnica estabelecida que permite pareamento probabilístico de registros a partir de diferentes provedores de dados sem expor dados pessoais privados identificáveis. Por exemplo, ao parear dados de dois provedores de dados, cada um vai encriptar seus dados pessoais identificáveis usando o filtro Bloom para obter chaves de registro criptográficas de cada provedor. Entre outras técnicas, achamos que o pareamento de registros para preservação da privacidade usando filtros Bloom é escalável para grandes conjuntos de dados.

    Histórico
  • Loops de aprendizado semissupervisionados são uma classe de fluxos de trabalho de aprendizado de máquina iterativo que tiram vantagem das relações encontradas em dados não-rotulados. Essas técnicas podem melhorar modelos ao combinar conjuntos de dados rotulados e não-rotulados de várias maneiras. Em outros casos, eles comparam modelos treinados em diferentes subconjuntos de dados. Diferente tanto do aprendizado não-supervisionado, em que uma máquina infere classes em dados não-rotulados, ou técnicas supervisionadas em que o conjunto em treinamento é totalmente rotulado, as técnicas semissupervisionadas levam a vantagem de um pequeno conjunto de dados rotulados e um conjunto bem maior de dados não-rotulados. O aprendizado semissupervisionado também se aproxima de técnicas de aprendizado ativo, em que um humano é direcionado a rotular seletivamente pontos de dados ambíguos. Já que humanos especialistas que podem rotular precisamente dados são um recurso escasso, e rotulagem é frequentemente uma atividade que consome muito tempo no fluxo de trabalho no aprendizado de máquina, as técnicas semissupervisionadas baixam o custo do treinamento e tornam o aprendizado de máquina possível para uma nova classe de usuários.

    Histórico

EVITE?

  • O velho termo pessoas engenheiras 10x esteve sob escrutínio nos últimos meses. Uma thread amplamente compartilhada no Twitter basicamente sugere que empresas perdoem comportamentos antissociais e prejudiciais para manter pessoas engenheiras que são percebidas como tendo imenso rendimento individual. Felizmente, muitas pessoas nas mídias sociais fizeram piada com o conceito, mas o estereótipo de “pessoa desenvolvedora rockstar” ainda é universal. Em nossa experiência, grandes pessoas engenheiras são guiadas não apenas pelo rendimento individual, mas por trabalhar em times incríveis. É mais eficaz construir times de indivíduos talentosos com experiências mistas e históricos diversificados e fornecer os ingredientes certos para o trabalho em equipe, aprendizado e melhoria contínua. Estes times 10x podem se mover mais rápido, escalar mais rapidamente e são muito mais resilientes – sem precisar ceder a maus comportamentos.

    Histórico
  • Quando times adotam o conceito de micro-frontends, eles têm um número de padrões ao seu dispor para integrar os micro-frontends individuais em uma aplicação. Como sempre, há antipadrões também. Um comum neste caso é a integração de front-end por meio de artefato. Para cada micro-frontend um artefato é construído, normalmente um pacote NPM, que é colocado num registro. Um passo depois, às vezes em uma pipeline de build diferente, então combina os pacotes individuais em um pacote final que contém todos os micro-frontends. De uma perspectiva puramente técnica, essa integração na hora do build resulta em uma aplicação funcionando. Contudo, integrar via artefato implica que, a cada mudança, o artefato todo precisar ser reconstruído, o que consome tempo e provavelmente terá um impacto negativo na experiência da pessoa desenvolvedora. Ainda pior, este estilo de integrar front-ends também introduz dependências diretas entre os micro-frontends no momento da compilação, causando, dessa forma, uma considerável sobrecarga de coordenação.

    Histórico
  • Temos construído arquiteturas sem servidor em nossos projetos há alguns anos, e percebemos que é bem fácil cair na armadilha de construir um monolito distribuído. As arquiteturas Lambda pinball caracteristicamente perdem de vista importantes lógicas de domínio na rede emaranhada de lambdas, buckets e filas à medida que os requisitos oscilam em gráficos cada vez mais complexos de serviços de nuvem. Normalmente, eles são difíceis de testar como unidades, e a aplicação precisa ser testada como um todo integrado. Um padrão que podemos usar para evitar essas arquiteturas pinball é fazer uma distinção entre interfaces públicas e publicadas e aplicar os bons e velhos limites de domínio com interfaces publicadas entre eles.

    Histórico
  • Estamos descobrindo que mais e mais empresas precisam substituir sistemas legados envelhecidos para acompanhar as demandas de seus clientes (tanto internos quanto externos). Um antipadrão que continuamos vendo é a paridade de funcionalidades em migração de legados , o desejo de manter a paridade de funcionalidades com os sistemas antigos. Vemos isso como uma grande oportunidade perdida. Frequentemente, os sistemas antigos têm inchado com o tempo, com muitos recursos não usados pelos usuários (50%, segundo um relatório de 2014 do Standish Group) e processos de negócios que evoluíram com o passar do tempo. Nosso conselho: convença seus clientes a dar um passo atrás, entendendo o que seus usuários precisam atualmente e priorizando essas necessidades, de acordo com resultados de negócios e métricas – isso é muitas vezes mais fácil de falar do que de fazer. Isso significa conduzir uma pesquisa sobre o usuário e aplicar práticas modernas de desenvolvimento de produto em vez de simplesmente substituir as práticas existentes.

    Histórico
Não encontrou algo que você esperava achar?

Cada edição do radar inclui blips que refletem nossas experiências nos seis meses anteriores. Talvez já tenhamos falado sobre o que você procura em um radar anterior. Às vezes, deixamos coisas de fora simplesmente porque há muitas a serem abordadas. Também pode estar faltando um tópico específico porque o radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.

Novo ou modificado,Sem modificação