Fazer login no IT Mídia Redefinir senha
Bem-vindo de volta,
Digite seu e-mail e clique em enviar
Ainda não tem uma conta? Cadastre-se
Salvar em Nova pasta de favoritos

+

Criar pasta
Salvar Escolher Pasta
5 coisas que os CIOs desejam dos desenvolvedores de aplicativos
Home > Gestão

5 coisas que os CIOs desejam dos desenvolvedores de aplicativos

Equilibre as compensações entre inovação e confiabilidade, mantendo o código estável, encantando os usuários e evitando a tecnologia pela tecnologia

Isaac Sacolick

16/10/2020 às 13h00

Foto: Adobe Stock

CIOs e líderes de TI estão presos em um paradoxo de prioridades concorrentes em relação ao desenvolvimento, aprimoramento e modernização de aplicativos. Por um lado, eles buscam inovação, experiências que encantem os usuários finais e práticas de desenvolvimento agile que permitam a entrega rápida de novos recursos de negócios. Por outro lado, eles estão preocupados em acumular dívidas técnicas, garantindo que os aplicativos passem pelas devidas validações de segurança e demonstrando se os protótipos podem ser executados e escalados em ambientes de produção.

Sim, CIOs e líderes de TI querem ter seu bolo e querem comê-lo também. Eles sabem todas as suas vontades, itens obrigatórios e listas de desejos de seus desenvolvedores e líderes de entrega. Mais tempo para desenvolver o código "da maneira certa", mais pessoas na equipe, melhor treinamento, infraestrutura de desenvolvimento mais ágil, ferramentas modernas de desenvolvimento de aplicativos, melhor envolvimento das partes interessadas e prioridades bem definidas estão na lista de todos.

Os líderes de TI estão alinhados com suas equipes em relação às necessidades, mas também devem enfrentar as realidades de negócios para impulsionar a transformação digital, trabalhar com restrições orçamentárias e atender aos requisitos de conformidade.

Os CIOs querem que as equipes de desenvolvimento de aplicativos saibam como tomar decisões prudentes em torno de compensações, quais etapas devem ser executadas para garantir que o que é desenvolvido seja suportável e por que a colaboração com usuários finais, partes interessadas, arquitetos e operações é tão importante quanto obter o aplicativo feito.

CIO2503

E-book por:

Para lidar com esses paradoxos, os CIOs esperam que suas equipes de desenvolvimento entendam os princípios de desenvolvimento e as compensações. Aqui estão cinco a serem considerados.

Equilibrar dívida técnica e inovação

É muito fácil para as equipes de desenvolvimento se empolgarem perseguindo inovações ou adicionando picos em torno de novas tecnologias ao backlog. CIOs e líderes de TI querem inovação, mas também se preocupam quando as equipes de desenvolvimento não tratam da dívida técnica. Uma lista de pendências ágil saudável deve mostrar as equipes agiles concluindo um equilíbrio de picos, débito técnico, nova funcionalidade e melhorias operacionais.

A priorização em equipes agiles deve recair sobre o proprietário do produto (Product Owner). Mas os líderes de TI podem estabelecer princípios se os proprietários do produto não conseguirem priorizar a dívida técnica ou se eles forçarem as prioridades de recursos sem considerar os picos de inovação recomendados pela equipe agile.

O CIO e os líderes de TI também são realistas e sabem que as novas implementações provavelmente acarretam dívidas técnicas adicionais. Eles entendem que às vezes os desenvolvedores devem economizar para cumprir prazos ou identificar opções de codificação mais eficientes durante a implementação. É razoável esperar que a dívida técnica recém-criada seja codificada no código-fonte e nas pendências agiles e que as equipes procurem resolvê-las com base nas prioridades.

Sempre desenvolva código seguro e sustentável

As equipes de desenvolvimento estão sob pressão significativa para fornecer recursos e capacidades aos usuários finais rapidamente. Essa é certamente uma das razões pelas quais as equipes criam novos débitos técnicos, mas é uma péssima desculpa para desenvolver um código que não é sustentável ou que ignora os padrões de segurança.

Os líderes de TI não querem um código espaguete, nem um código excessivamente complexo que requer engenheiros avançados para manter. Os líderes de TI são responsáveis pela manutenção de longo prazo do código que entregam, sabendo que os desenvolvedores e as equipes são realocados para novos projetos. Eles esperam que o código siga os padrões de arquitetura, padrões de codificação, convenções de nomenclatura, padrões de registro e tratamento de exceções.

Eles também esperam que as equipes de desenvolvimento colaborem na definição e evolução dos padrões. À medida que a tecnologia, as plataformas e as práticas recomendadas continuam a evoluir, as organizações não podem contar com os arquitetos para possuir e especificar todas as diretrizes.

Crie experiências de usuário agradáveis com desempenho e escala

No início do desenvolvimento da Web, as equipes de software enfrentavam dificuldades em termos de arquitetura e design de aplicativos.

Uma abordagem fez com que o processo de desenvolvimento começasse com equipes projetando o banco de dados back-end e codificando a lógica de negócios. Os engenheiros criaram soluções reutilizáveis e escaláveis, mas a implementação frequentemente restringia a experiência do usuário e os designs.

Na outra abordagem, as equipes de desenvolvimento da Web começam com os designs de front-end e oferecem ótimas experiências aos usuários finais. Mas esses projetos frequentemente implementavam lógica de negócios dentro de modelos de server-side ou faziam chamadas de serviço frequentes, resultando em aplicativos que não funcionavam bem ou não eram escalados conforme necessário.

Os CIOs precisam oferecer ótima experiência e desempenho. Hoje, as equipes de desenvolvimento podem utilizar ferramentas de wireframing, plataformas de low-code, capacidades de sinalização de recursos, padrões de design de microsserviço, melhores práticas de desenvolvimento, automação de teste e arquiteturas de nuvem para fornecer ambos.

Evite programar para resolver problemas de tecnologia por amor à tecnologia

Quando me sento com equipes de desenvolvimento durante suas sessões de planejamento agile, ouço as declarações de problemas subjacentes e as coloco em uma das várias categorias. Os melhores recursos e histórias têm como objetivo fornecer ou aprimorar recursos para um grupo específico de usuários finais. Também posso ver picos dedicados para testar novas soluções ou criar protótipos de novos recursos. Às vezes, o débito técnico é resolvido na implementação de uma história de usuário. Outras vezes, o trabalho é significativo o suficiente para exigir várias histórias dedicadas no backlog. Todos esses são bons exemplos de trabalho que o product owner deve revisar e priorizar.

Às vezes vejo trabalho direcionado para resolver uma necessidade de tecnologia. Na extremidade inferior, podem ser classes de utilitário para oferecer suporte a configurações e conexões de serviço. Eu também vi equipes tentando construir soluções de gerenciamento de microconteúdo, recursos de low-code e ferramentas de gerenciamento de API.

A maioria das equipes de desenvolvimento deve evitar construir recursos de tecnologia que resolvam problemas de tecnologia. Soluções robustas para problemas técnicos geralmente estão disponíveis por meio de bibliotecas de código aberto, serviços de computação em nuvem pública, recursos de low-code e serviços de software comercial. Arquitetos e equipes de desenvolvimento devem avaliar essas opções antes de se inscreverem para desenvolver soluções de "tecnologia pela tecnologia".

Siga os padrões de governança de dados

A última coisa que os CIOs e líderes de TI desejam ver quando as equipes de desenvolvimento criam ou aprimoram os aplicativos são mais silos de dados, fontes de dados duplicadas ou estruturas de dados mal projetadas. Para a maioria das organizações, o tamanho do débito de dados geralmente excede o débito técnico e o impacto nos negócios é significativo. Basta pedir a qualquer cientista de dados para entender a expansão urbana de fontes de dados que vivem em data warehouses e data lakes corporativos.

É incrivelmente fácil hoje criar novos bancos de dados relacionais, NoSQL datastores e data lakes. Isso é uma bênção e uma maldição, e a questão é como ajudar as equipes de desenvolvimento a saber quais fontes de dados estão disponíveis e a melhor maneira de interagir com elas. A revisão de catálogos de dados, portais de API e fontes de dados principais deve ser a primeira etapa para as equipes de desenvolvimento antes de criar novas estruturas de dados.

Se novas estruturas de dados forem necessárias, as equipes devem usar ferramentas de modelagem de dados e seguir os padrões de governança de dados como práticas não negociáveis.

Para resumir, os CIOs e líderes de TI querem inovação, velocidade, usuários finais satisfeitos e equipes de desenvolvimento entusiasmadas para resolver os desafios de negócios. Mas eles também precisam de confiabilidade, desempenho, eficiência, escalabilidade, segurança e aplicativos que possam ser mantidos por longo prazo. Essas não são metas mutuamente exclusivas, mas compensações práticas surgem a cada lançamento, sprint e história de usuário. As organizações de TI devem definir princípios de engenharia e debater suas implementações como parte de seu processo de desenvolvimento.

Vai um cookie?

A CIO usa cookies para personalizar conteúdo e anúncios, para melhorar sua experiência em nosso site. Ao continuar, você aceitará o uso. Para mais detalhes veja nossa Política de Privacidade.

Este anúncio desaparecerá em:

Fechar anúncio

15