Por que a manutenção de aplicativos da Web deve ser mais importante

Os desenvolvedores de software tradicionais têm escondido um segredo de nós à vista de todos. Não é sequer um fato contestado. Faz parte do modelo de negócios deles.

Não importa se estamos falando de fornecedores de software corporativo de ponta ou de software houses menores que escrevem as ferramentas que todos nós usamos no dia a dia em nossos trabalhos ou negócios, como um gerenciador de syslog gratuito. É bem ali na frente e no centro. Custos adicionais que eles não escondem e que nos acostumamos a pagar.

Então, qual é esse segredo?

Bem, muitos fornecedores de software tradicionais ganham mais dinheiro com a manutenção do software que escrevem do que na venda inicial.

Não convencido?

Uma pesquisa rápida sobre o termo “Total Cost of Ownership” fornecerá muitas definições semelhantes, como esta do Gartner (ênfase minha):

[TCO é] o custo de implementação, operação, suporte e manutenção ou extensão e desativação de um aplicativo.

Além disso, este artigo da Universidade de Stanford afirma que a manutenção normalmente equivale a 60% a 90% do TCO de um produto de software.

Vale a pena deixar isso afundar por um minuto . Eles ganham bem acima do preço de compra inicial vendendo planos de suporte e manutenção contínuos.

Nós não empurramos a manutenção

O problema que vejo é que no setor de desenvolvimento web, a manutenção de aplicativos web não é algo em que nos concentramos. Podemos colocá-lo em nossas propostas porque gostamos da ideia de um retentor mensal, mas eles provavelmente cobrirão tarefas simples de limpeza ou solicitações de novos recursos.

Não é inédito ocultar atualizações e otimizações essenciais em nossas cotações para iterações posteriores, porque não temos certeza de que o cliente desejará pagar pelas coisas que consideramos melhorias essenciais. Tentamos fazê-los entrar pela porta dos fundos. Ou seja, não somos abertos e transparentes que, assim como os softwares mais tradicionais, esses aplicativos precisam de manutenção.

Independentemente das razões, está ficando claro que estamos acumulando problemas para o futuro. Os aplicativos de software que estamos construindo estão aqui para o longo prazo . Precisamos pensar como fornecedores de software tradicionais. Nosso software ainda estará funcionando por 10 ou 15 anos a partir de agora, e deve ser mantido bem mantido.

Então, como podemos mudar isso? Como todos nós, como indústria, garantimos que nossos clientes estejam protegidos para que as coisas permaneçam seguras e atualizadas? Da mesma forma, como podemos obter uma parte do bolo de manutenção ?

O que é manutenção?

Em seu artigo de 2012 Effective Application Maintenance, Heather Smith e James McKeen definem manutenção como (a ênfase é minha):

A portabilidade de um aplicativo para um novo servidor, a interface com um sistema operacional diferente, a atualização para uma versão mais recente, a alteração de uma tabela de impostos ou a conformidade com novos regulamentos – tudo isso exige manutenção do aplicativo. Como resultado, a manutenção é focada na atualização de um aplicativo para garantir que ele permaneça produtivo e/ou econômico . A definição de manutenção de aplicativo preferida pelo grupo de foco é — qualquer modificação de um aplicativo para corrigir falhas; para melhorar o desempenho; ou para adaptar o aplicativo a um ambiente alterado ou requisitos alterados. Assim, adicionar novas funcionalidades a um aplicativo existente (ou seja, aprimoramento) não é, estritamente falando, considerado manutenção .

Em outras palavras, a manutenção é um trabalho essencial que precisa ser realizado em um aplicativo de software para que ele continue a funcionar de maneira confiável e segura.

Não está adicionando novos recursos. Não está verificando os arquivos de log ou garantindo que os backups foram executados (essas são tarefas de manutenção). Ele está trabalhando no código e na plataforma subjacente para garantir que as coisas estejam atualizadas, que funcione como seus usuários esperariam e que as luzes permaneçam acesas.

Aqui estão alguns exemplos:

• Mudanças de tecnologia e plataforma
  Bibliotecas de terceiros precisam ser atualizadas. A linguagem subjacente requer uma atualização, por exemplo, PHP 5.6 para PHP 7.1 Os sistemas operacionais modernos enviam atualizações regularmente. Manter o controle disso é manutenção e, às vezes, também exigirá alterações na base de código, pois as antigas maneiras de fazer certas coisas se tornam obsoletas.

• Escala
  À medida que o aplicativo cresce, haverá problemas de recursos. Rotinas dentro do código que funcionaram bem com 10.000 transações por dia lutam com 10.000 por hora. O aplicativo precisa ser monitorado, mas também ações precisam ser tomadas quando os alertas são acionados.

• Corrigindo erro
  Óbvio, mas vale a pena tornar explícito. O software tem bugs e eles precisam ser corrigidos. Mesmo que você inclua um pequeno período de correções gratuitas de bugs após o envio de um projeto, em algum momento o cliente precisará começar a pagar por elas.

Difícil de vender?

Curiosamente, quando discuto isso com meus colegas, eles sentem que é difícil convencer os clientes de que precisam de manutenção. Eles estão preocupados que seus clientes não tenham o orçamento e eles não querem parecer muito caros.

Bem, aqui está a coisa: é realmente uma venda muito fácil. Estamos lidando com empresários e simplesmente precisamos conversar com eles sobre manutenção em termos comerciais. Os empresários entendem que os ativos exigem manutenção ou se tornarão passivos. É apenas mais uma sobrecarga mensal contínua padrão. Um custo de fazer negócios. Nós só precisamos colocar isso em nossas propostas e garantir que vamos dar seguimento a isso .

Um método extremamente eficaz é oferecer um retentor que incorpore a manutenção em seu núcleo, mas também agrega muito valor extra para o cliente, coisas como:

• Relatórios de progresso x KPIs (por exemplo, tráfego, conversões, volumes de pesquisa)
• Tempo 'livre' limitado a cada mês para pequenos ajustes no site
• Relatórios sobre tempo de inatividade, atualizações de servidor ou trabalho de desenvolvimento concluído
• Acesso a você ou a membros específicos de sua equipe por telefone para responder a perguntas

Na verdade, você pode fazer o retentor economizar o dinheiro do cliente e pagar por si mesmo. Um bom exemplo disso seria o requisito de um cliente para obter um relatório simples ou exportar do banco de dados todos os meses para processamento offline.

Você pode cotar vários dias de desenvolvimento para criar uma interface de usuário de relatórios – provavelmente mais complexa do que inicialmente previsto – ou, alternativamente, apontar o cliente para seu retentor. Inclua nela uma tarefa a cada mês para um desenvolvedor executar manualmente uma consulta SQL predefinida para fornecer manualmente os mesmos dados.

Uma tarefa trivial para você ou sua equipe; muito valor para o seu cliente.

Um exemplo prático

Você, é claro, terá sua própria maneira de escrever propostas, mas aqui estão alguns trechos de um exemplo de apresentação.

Na seção de sua proposta onde você pode pintar sua visão para o futuro, você pode adicionar algo sobre manutenção. Use isso como uma oportunidade para plantar a semente sobre a formação de um relacionamento de longo prazo.

Você está procurando minimizar o risco a longo prazo.

Você quer garantir que seu aplicativo tenha um bom desempenho, que permaneça seguro e que seja fácil de trabalhar.

Você também entende a importância da manutenção para qualquer ativo de negócios.

Mais tarde, na seção de entregas, você pode adicionar uma parte sobre manutenção como uma opção independente ou empacotada com um retentor contínuo.

No exemplo a seguir, simplificamos e o agrupamos com um retentor de desenvolvimento pré-pago:

Defendemos fortemente que todos os clientes considerem a manutenção uma sobrecarga essencial para seu site. As aplicações web modernas requerem manutenção e tal como a sua casa ou o seu carro; você mantém seus ativos mantidos para reduzir o risco tangível de que eles se tornem passivos mais tarde .

Como um cliente que está sensatamente interessado em manter-se atualizado sobre a manutenção do aplicativo, bem como adicionar novos recursos, sugerimos N dias por mês (como ponto de partida) para manutenção geral e retenção de desenvolvimento.

Divulgaríamos as coisas para que um desenvolvedor trabalhasse em seu sistema pelo menos [algum período por semana/mês], dando a você a vantagem distinta de ter um desenvolvedor capaz de mudar para algo mais importante caso surjam problemas durante o [mesmo período] . Dependendo de suas prioridades, esse tempo pode ser gasto no trabalho de novos recursos ou dividido com manutenção, a decisão é sua. Normalmente sugerimos uma divisão de 75%/25% entre novos recursos e manutenção importante.

Como mencionado anteriormente, essa também é uma ótima oportunidade para agregar a manutenção a outros serviços contínuos de valor agregado, como relatórios de desempenho, realização de tarefas de manutenção, como verificação de backups e talvez uma ligação mensal para discutir o progresso e as prioridades.

O que você provavelmente descobrirá é que depois de conseguir o trabalho, o retentor não é mencionado novamente. Isso é compreensível, pois há muito para você e seu cliente considerarem no início de um projeto, mas, à medida que o projeto está terminando, é um ótimo momento para reintroduzi-lo como parte do processo de desligamento do projeto.

Seja falando sobre a fase 2 ou simplesmente apresentando faturas finais e entregando, lembre-os sobre manutenção. Lembre-os de treinamento contínuo, relatórios e disponibilidade para suporte . Faça a pressão para um retentor, lembrando-se de falar nos mesmos termos comerciais: seu novo ativo precisa de manutenção para permanecer brilhante .

A manutenção pode ser irritante?

Um equívoco comum é que os retentores de manutenção podem se tornar um fardo adicional. A preocupação é que os clientes estejam constantemente ligando para você e pedindo pequenos ajustes como parte de seu retentor. Esta é uma preocupação particular para equipes menores ou consultores individuais.

Não é geralmente o caso, no entanto. Talvez no início, o cliente tenha uma lista de problemas que precisam ser resolvidos, mas isso é normal; se você é experiente, então você está esperando por isso. Eles são facilmente gerenciados melhorando os canais de comunicação (use um rastreador de problemas) e agrupando todas as solicitações, ou seja, trabalhando nelas em um único hit.

À medida que o aplicativo amadurece, você entrará no modo tick-over. É aqui que o retentor se torna particularmente valioso para ambas as partes. Obviamente, depende de como você estruturou o retentor, mas da sua perspectiva, você está se esforçando para lembrar ao cliente a cada mês o quão valioso você é. Você pode enviar a eles seu relatório mensal, dizer a eles como você corrigiu uma lentidão nessa rotina e que o servidor foi corrigido para a exploração global do SO desta semana.

Obviamente, você também estava disponível para trabalhar em vários novos recursos solicitados que eram cobrados adicionalmente . Do ponto de vista do seu cliente, ele vê que você está lá, vê o progresso e remove a “preocupação com o site” da lista. Claramente, existem 'esses clientes', portanto, o mais importante é acertar a redação do seu retentor e gerenciar as expectativas de acordo.

Se o seu cliente está esperando a lua no pau por uma taxa mensal baixa, recue ou renegocie. Pagar-lhe para fazer — digamos — duas horas de manutenção e limpeza por mês entre fornecer um relatório mensal e outras tarefas auxiliares é exatamente isso; não é um cheque em branco para fazer muitas mudanças ad-hoc. Lembre-os do que está incluído e do que não está.

Como Facilitamos a Manutenção?

Por fim, para garantir o melhor valor para seus clientes e facilitar sua vida, use algumas dessas táticas ao construir seus aplicativos.

Suporte de longo prazo (LTS)

• Use plataformas de tecnologia com versões LTS bem documentadas e caminhos de atualização.
• As atualizações contínuas de SO, linguagem, estrutura e CMS devem ser esperadas e levadas em consideração para todos os projetos, portanto, rastrear uma versão LTS é um acéfalo.
• Tudo deve estar rodando em uma versão suportada. Grandes sinos de alarme devem soar se não for o caso.

Higiene do bom projeto

• Tenha tarefas de manutenção publicamente em sua lista de pendências de recursos ou sistema de rastreamento de problemas e acorde as prioridades com seu cliente. Não esconda as tarefas de manutenção.
• Testes funcionais e de nível de código permitem que você fique de olho em códigos particularmente problemáticos e ajudarão ao retirar módulos para refatoração.
• Monitore a aplicação e entenda onde estão os gargalos e erros. Quaisquer problemas podem ser adicionados ao backlog de desenvolvimento e priorizados de acordo.
• Monitorar solicitações de suporte. Os usuários finais estão fornecendo feedback útil que pode indicar requisitos de manutenção?

O aplicativo deve ser portátil

• Qualquer desenvolvedor deve ser capaz de colocar o sistema em funcionamento localmente facilmente - não apenas você! Use servidores ou contêineres virtuais para garantir que as versões de desenvolvimento dos aplicativos sejam idênticas à produção.
• A aplicação deve ser bem documentada. No mínimo, os fluxos de trabalho de provisionamento e implantação e quaisquer encantamentos especiais necessários para implantar ao vivo devem ser anotados.

A manutenção é um ganho genuíno

Manutenção é o trabalho que precisamos fazer em um aplicativo para que ele possa ficar parado com segurança. É um custo comercial padrão. Em média, 75% do custo total de propriedade durante a vida útil de um aplicativo de software.

Como profissionais, temos o dever de educar nossos clientes sobre manutenção desde o início. Há uma enorme oportunidade aqui para renda adicional, proporcionando valor tangível para seus clientes. Você consegue manter um relacionamento comercial contínuo e será a primeira pessoa a quem eles recorrerão quando tiverem novos requisitos.

Continuar a fornecer valor por meio de seu retentor aumentará a confiança do cliente. Você terá uma plataforma para sugerir melhorias ou novos recursos. Trabalho que você tem grandes chances de ganhar. Seu cliente reduz seus custos de vida útil, reduz seus riscos e deixa de se preocupar com desempenho ou segurança.

Faça um favor a si mesmo, ao seu cliente e a todo o nosso setor: ajude a tornar a manutenção de aplicativos da Web mais importante.