Como as “empresas de software personalizadas” lidam com dívidas técnicas?

O que são "empresas de software personalizadas"?

Por "empresas de software personalizadas", quero dizer empresas que lucram principalmente com a criação de pedaços de software personalizados e únicos. Exemplo são agências ou empresas de produtos intermediários ou contratados / consultores como a Redify .

Qual é o oposto de "empresas de software personalizadas"?

O oposto do modelo de negócios acima são empresas que se concentram em produtos de longo prazo, sejam eles aplicativos de desktop / móveis implantáveis ​​ou software SaaS.

Uma maneira segura de acumular dívidas técnicas:

Eu trabalho para uma empresa que tenta se concentrar em um conjunto de produtos SaaS. No entanto, devido a certas restrições, às vezes acabamos cedendo à vontade de determinados clientes e acabamos criando bits de software personalizado que só podem ser usados ​​para esse cliente.

Esta é uma maneira segura de incorrer em dívidas técnicas. Agora, temos um pouco de software para manter que não agrega nada ao nosso produto principal.

Se o trabalho personalizado é uma maneira certa de criar dívidas técnicas, como as agências lidam com isso?

Então isso me fez pensar. Empresas que não têm um produto principal como centro de seu modelo de negócios, bem, estão sempre fazendo um trabalho de software personalizado. Como eles lidam com a noção de dívida técnica? Como isso não os leva à falência técnica ?

Se você pode dobrar os requisitos específicos do usuário em algo que será útil para todos, ótimo. Se o cliente estiver disposto a pagar os custos de suporte contínuos pelo recurso, também é ótimo. Mas se você é uma equipe pequena e se esforça para oferecer suporte a todos os seus recursos, não há nada a fazer senão tomar algumas decisões difíceis sobre os recursos de que você menos precisa e depois investir algum tempo tirando-os da sua base de código.

O SaaS coloca você em uma boa posição para coletar estatísticas de uso. Você deve analisar os recursos de seus recursos, se ainda não o fez, para poder acompanhar quem está usando o quê. Nossa experiência é que os clientes mais idiomáticos geralmente também são os mais disfuncionais; aquele cara que bateu os pés e prendeu a respiração até você dar um botão de exportação para MS-Access provavelmente não o usa há mais de um ano. Alguns recursos são mantidos ativos, embora apenas um cliente os esteja usando, porque esse cliente é alto e ameaça levar seus negócios para outro lugar sempre que algo não é para sua satisfação. A interrupção do recurso pode custar a você um cliente agora, mas o tempo gasto no suporte a esse recurso pode custar dezenas de clientes ao longo dos anos. É uma medida da qualidade da sua equipe de gerenciamento,

Ao interromper um recurso, anuncie a decisão aos seus clientes (ou pelo menos aos afetados) com antecedência, entre seis meses e três anos é razoável. De fato, se você concorda em criar recursos específicos para o usuário, tente solicitar à sua equipe de vendas uma data de validade desde o início. Chame de "vida útil do suporte" e deixe claro que quanto mais tempo eles quiserem, mais dinheiro custará. Tente fornecer soluções alternativas para seus clientes, para que eles não fiquem tropeçando quando um recurso for lançado, por exemplo, um script que converta seus arquivos XML exportados em formato de acesso MS, ou um conselho sobre como escolher um RDBMS melhor.

Algo que funcionou para nós como medida preventiva é obter um relatório mensal de nossa equipe de vendas para nossa equipe de desenvolvimento e gerenciamento. Este relatório abrange o feedback dos clientes - quais recursos são mais populares, quais são os mais solicitados, quais recursos propostos estão gerando mais burburinho. Isso é interessante se você é um desenvolvedor, mas o benefício real é para a equipe de vendas, que agora está pensando um pouco mais sobre cada recurso no contexto do cenário geral, em vez de enviar um fluxo interminável de solicitações de recursos e priorizar com base em em qual cliente foi o mais alto. O efeito foi tornar nossa equipe de vendas mais intransigente quando se trata de solicitações de novos recursos em uma negociação, porque elas têm mais consciência de onde cada recurso pode se encaixar na proposta de valor geral do nosso produto.

Ter código modular com muitos testes automatizados ajudará você quando você estiver invadindo recursos do seu produto e recuperando-os novamente, mas, no final das contas, essa não é uma questão de programação, mas de gerenciamento. Escrever código para fazer uma venda é um jogo de tolos.

Quando me deparo com solicitações de desenvolvimento personalizadas, filtro-as pelo filtro legal, que divide as solicitações em 3 pilhas:

1. coisas incríveis que serão úteis para todos e que são relativamente fáceis de implementar
2. coisas incríveis que serão úteis para todos e difíceis de implementar
3. coisas estúpidas que são necessárias apenas para esse cliente que realmente não precisa delas

• A categoria 1 é implementada no atual ciclo de desenvolvimento.
• A categoria 2 é implementada no próximo ciclo de desenvolvimento.
• A categoria 3 obtém uma cotação de 1 homem / mês de tempo de desenvolvimento, após o qual a maioria dos clientes percebe que sua solicitação não vale a pena.

Honestamente, isso nunca falhou e acho que não acabamos implementando nenhum dos recursos da categoria 3. E é claro que nenhum dos clientes andou (as vendas não teriam me permitido fazer isso de outra forma :)

(essa experiência foi em uma empresa ISV)

devido a certas restrições, às vezes acabamos cedendo à vontade de determinados clientes e acabamos criando bits de software personalizado que só podem ser usados ​​para esse cliente.

Seu problema não é que você está criando um código usado para apenas um cliente. O problema é que você está incorporando código usado apenas para um cliente em um produto que está vendendo para muitos outros clientes que não precisam dessa funcionalidade.

Empresas que não têm um produto principal como centro de seu modelo de negócios, bem, estão sempre fazendo um trabalho de software personalizado. Como eles lidam com a noção de Dívida Técnica? Como isso não os leva à falência técnica?

Eles entregam o produto. E então eles seguem em frente. Quando você está desenvolvendo um produto sob contrato, tudo o que você faz nesse projeto é para esse cliente. Qualquer dívida técnica acumulada durante o desenvolvimento torna-se o problema do cliente após o término do contrato e o desenvolvedor passa para outro projeto para outro cliente.

Isso não significa que não há problema em fazer um trabalho ruim, é claro. Seu objetivo número um é fazer com que seu cliente continue trabalhando com você, e fazer um trabalho de qualidade é o caminho para chegar lá. Isso também não significa que a dívida técnica não seja um problema para os desenvolvedores de contratos. Mesmo se você escrever constantemente um código limpo, é provável que você seja contratado em algum momento para trabalhar em um projeto que já acumulou uma pilha de dívidas. Isso pode ser bom (o cliente quer pagar para você limpar a bagunça) ou não (o cliente não tem idéia do quão ruim é o código e não entende por que "apenas" adicionar mais alguns recursos levará tanto tempo )

Não concordo com a premissa de que o trabalho personalizado é garantido para gerar dívida técnica. Evitar dívida técnica não significa evitar certos tipos de funcionalidade - significa evitar rigidez desnecessária, problemas de dependência e coisas que dificultam (ou seja, caro) a base de código. A funcionalidade personalizada não implica nada disso - apenas implica uma base estreita para a funcionalidade. Portanto, a chave é levar em consideração o máximo possível de lógica reutilizável possível da implementação, deixando o material personalizado e único como seu próprio módulo autônomo que pode ser implantado para o cliente solicitante.

Por exemplo, digamos que você tinha um produto que era um aplicativo Web interno que seus clientes instalariam em uma intranet. Um dia, um cliente chega e se oferece para dirigir um caminhão basculante cheio de dinheiro até sua empresa, se você criar uma versão para eles que tenha um aplicativo de desktop "rich client" em vez de uma interface do navegador. Bem, se seu sistema está bem arquitetado e suas dependências bem gerenciadas, é apenas uma questão de reutilizar o domínio, acesso a dados e componentes de serviço enquanto cria um novo componente de apresentação. A dívida técnica não é uma consideração, mesmo que você tenha apenas um cliente que queira retornar a 1999 e tenha um aplicativo de desktop para isso.

Essa é uma pergunta um tanto complexa a ser respondida porque, como muitas coisas, depende realmente das circunstâncias do projeto, do nível de controle da empresa contratada, se o software personalizado foi gerenciado pela empresa contratada durante todo o seu ciclo de vida, a quantidade de "interferência" por outras pessoas com acesso à base de código, a atitude de todas as pessoas envolvidas, a complexidade do projeto e as metodologias utilizadas ... Eu realmente poderia continuar.

Todos os sistemas têm um grau de dívida técnica. Em alguns casos, isso pode não ser particularmente perceptível devido aos esforços diligentes por parte dos desenvolvedores que trabalham para manter sempre uma base de código limpa; no entanto, nenhum sistema é perfeito e uma grande reformulação pode tornar um problema aparentemente inocente e de longa data aparente. Então, como as empresas contratadas lidam com isso?

Em muitos casos, eles não. Geralmente, o software é escrito por uma empresa, depois modificado por outra, e não é incomum ver a base de código ficar realmente confusa, pois cada empresa contratada trabalha com um prazo apertado e não justifica o tempo para manter o código limpo ( e às vezes mal testados) se isso significa que eles podem correr o risco de perder um prazo.

Em outros casos, você encontra empresas que não apenas gerenciam bem seu projeto contratado, mas também encontram tempo para deixar a base de códigos existente em um estado melhor do que o encontrado. Eles fazem isso frequentemente com um planejamento cuidadoso, identificando fontes de dívida técnica - geralmente aquelas que mais impactam em novos trabalhos - e desenvolvem estratégias para fornecer casos de teste e modificações que contribuam para o gerenciamento da dívida técnica e levam tudo isso para o cronograma do projeto .

Ser um software personalizado garante dívida técnica em vez de criar um produto central? A resposta curta é não, mas é provável que a dívida técnica se acumule se não for tratada ativamente. É o mesmo que em qualquer outro projeto de software. Se você controlar o projeto inteiramente durante todo o seu ciclo de vida, terá uma oportunidade melhor de lidar com dívidas técnicas. Caso contrário, será necessário lidar com a dívida técnica que pode ter acumulado do código que a empresa anterior deixou para trás.

Por outro lado, se sua pergunta for perguntar se escrever software independentemente do seu modelo de negócios é uma garantia de dívida técnica. A resposta seria Absolutamente. A verdadeira questão é como qualquer empresa lida com dívidas técnicas. Deixe acumular e lidar com ele em um horário agendado, ou gerencie uma base de código limpa de maneira contínua para pagar as dívidas técnicas o mais rápido possível? Essa resposta se resume às prioridades individuais de uma empresa e se a dívida técnica incorrida é financeiramente relevante.

Software personalizado não é garantia de dívida técnica, mas servir a dois mestres é.

Uma empresa de software personalizada construirá um software exatamente adequado à tarefa em questão, entregará e manterá, se necessário. Software verdadeiramente personalizado geralmente não precisa de novos recursos adicionados com muita frequência.

O problema descrito nesta pergunta é quando as empresas de produtos criam recursos personalizados em um produto genérico. Se o produto fosse totalmente personalizado, ele somente mudaria quando os requisitos de um cliente fossem alterados. Se o produto fosse totalmente genérico, ele seria movido apenas quando novos recursos fossem adicionados para torná-lo mais atraente. Mas quando você tem um recurso personalizado em um produto genérico, há dois blocos de código, em contato próximo, que se movem em velocidades diferentes. Como as placas tectônicas que causam terremotos, a interface entre esses blocos de código é um "ponto quente", propício para problemas.