Como sair da rotina de suporte e começar a pagar a dívida técnica!

Eu tenho um amigo". Sim, bom começo, eu sei, mas honestamente, este não sou eu!

Basicamente, ele está trabalhando em um projeto de sucesso há cerca de 4 anos, a dificuldade é que a dívida técnica aumentou e ele está achando quase impossível parar de apoiar o produto (aprimorando isso e aquilo) e realmente seguir em frente com o desenvolvimento real .

Fiz várias sugestões, registrei todo o seu tempo, crie tickets, não respondo e-mails etc. O problema é que isso parece servir apenas como um lembrete de que ele não está conseguindo fazer nada "útil".

A dívida técnica ocorreu em grande parte porque, em primeira instância, era um grande benefício para o produto receber solicitações e telefonemas dos usuários e implementá-las rapidamente.

O que eu gostaria de saber é que alguém tem alguma sugestão de como ele pode sair dessa rotina, em grande parte alterando as percepções dos usuários, para que eles não pensem que podem simplesmente ligar e esperar que algo aconteça. ser feito então e ali.

Tudo indica muito bem planejar melhor, embora eu entenda que é muito difícil planejar o desenvolvimento real, dado o requisito de suporte e as pressões relativas dos usuários (veja acima).

A organização de seu amigo precisa desesperadamente de alguém para fazer o gerenciamento de alterações. Essa pessoa ou grupo pegaria solicitações de alteração e correções de bugs e as priorizaria de acordo com o impacto nos negócios e a quantidade de esforço necessário. Dessa forma, as tarefas que são mais importantes para a organização como um todo seriam executadas primeiro, em oposição às tarefas que são mais importantes para quem está incomodando seu amigo no momento.

EDIT: Como um exemplo de como isso funcionaria, a maioria das organizações tem uma escala de gravidade. O nível de gravidade mais alto é um aplicativo ou função crítica para os negócios que não funciona. Se houver algo que a empresa possa fazer para solucionar o problema, isso reduz a gravidade para o próximo nível. Se o aplicativo não for crítico para os negócios, isso reduzirá ainda mais a gravidade. Normalmente, as solicitações de novos aprimoramentos são priorizadas separadamente.

Faça alguém atender as chamadas e faça com que a linha mude de

Nós vamos chegar a isso imediatamente.

para

Muito boa sugestão. Vou criar uma solicitação de recurso para começar a trabalhar nele o mais rápido possível. Se você deseja acompanhar o andamento da sua solicitação, pode acompanhar aqui: [link para o ticket do rastreador de caso]. No futuro, você também pode enviar solicitações de futuros da mesma forma que eu estou aqui: [link para rastreador de casos]

Essa é provavelmente a maneira mais simples e eficaz de fazer isso na minha opinião. O último bit tenta reduzir o estresse dessa pessoa que atende as chamadas ao longo do tempo.

O problema que você está vendo com o atual sistema de 'prioridade' é que, quando tudo é uma prioridade, nada é uma prioridade . Para isso, seu amigo precisa desesperadamente seguir os conselhos de @Larry Coleman - pessoas separadas do desenvolvimento que gerenciam solicitações de mudança. Idealmente, seu amigo nem deveria saber sobre uma solicitação de recurso, até que esse grupo separado concordasse que deveria ser priorizada para o trabalho. Pode até ser essa nova pessoa que está atendendo as chamadas agora que as prioriza - desde que entendam o negócio e entendam o desenvolvimento.

Eu já passei por uma situação semelhante. O produto foi construído sobre cordas de sapatos e foi o primeiro em seu mercado no lançamento. Foi inicialmente bem-sucedido (para um negócio solo-pré-juramentado), mas suponho que tudo funcionou de 2003 a 2007. Eu procurei contratá-lo, mas aprendi da maneira mais difícil que contratar bons funcionários é caro e de maneira alguma fácil. Presumo que seu amigo esteja em uma situação semelhante.

No meu caso, ficou claro desde o início que as coisas declinariam em algum momento. O negócio ainda estava crescendo, mas a concorrência estava aumentando, o mercado parecia encolher, havia sinais iniciais (meados de 2006) de que uma desaceleração econômica estava surgindo etc. Basicamente, vários fatores levaram eu decidir que o produto acabaria morrendo; quanto mais tarde, melhor (para os clientes e para mim).

Em retrospecto, eu provavelmente tomei tantas decisões boas quanto as ruins, mas aqui está um breve resumo:

1. Equipe corretamente e cedo. Obtenha financiamento, se necessário. (Não procurar nenhum foi o meu maior erro.) Se você tiver vendas, encontrará dinheiro.

2. Use o controle de versão / testes de unidade / todos os argumentos relacionados às melhores práticas. Todos eles parecem bobos / ridículos / desinteressantes quando ensinados na universidade, mas geralmente são as melhores práticas por boas razões.

3. Contrate pelo menos um profissional de vendas / marketing, especialmente se você é orientado para a tecnologia. (Porque, nesse caso, você terá uma tendência natural a gastar mais tempo em questões de tecnologia do que em marketing, mesmo se tiver uma rede de afiliados).

4. Multidão de apoio seu. Crie um fórum, para que os usuários possam se ajudar. Configure um sistema de emissão de bilhetes e convide seus usuários especializados (geralmente usuários frequentes do fórum) a entrar em uma seção especial como assistentes virtuais. Deixe que eles cuidem da multidão de clientes que precisam dessa pequena tarefa por alguns dólares, para que você possa se concentrar no cenário geral.

5. Maximize seus esforços para reduzir a quantidade de suporte que você está oferecendo. Quanto menos apoio você tiver, mais tempo terá para fazer coisas mais interessantes. No momento em que o produto for uma prova fictícia, os clientes ficarão agradecidos e suas vendas e sua equipe de suporte também.

6. Faça com que os desenvolvedores reais façam parte do suporte (uma ou duas horas por dia, para que não percam o contato com a realidade) e dê a eles uma mão livre para sugerir qualquer re-engenharia / alteração do produto (interface do usuário, funcionalidade) se eles identifique qualquer coisa que os faça gastar menos tempo em suporte. A idéia é que, se eles são incomodados pelos usuários repetidamente pelos mesmos motivos, eles desejam corrigir as coisas o mais rápido possível para que possam se livrar das chamadas de suporte. E os mais inteligentes realmente o fazem, e é exatamente isso que você deseja.

7. Se você sentir que o produto vai morrer, decida matá-lo aqui e ali e trabalhe no próximo passo. Deixe morrer, realmente. Uma vaca leiteira é uma vaca leiteira; quando cumprir seu objetivo, envie-o ao açougueiro. Faça isso com cuidado (para os clientes), mas não deixe que sua sobrevivência prolongada consuma muito do seu tempo se a sobrecarga de manutenção for tal que sua concorrência, com o benefício de ser retardatário e ter acumulado alguma dívida técnica , implementará novos recursos mais rapidamente do que você pode.

Uma linha de cada vez. Leve um pouco mais de tempo para cada correção, limpando hacks e adicionando testes automatizados à medida que avança. Muitas vezes, fazer algo certo acaba sendo muito mais rápido do que adicionar outro hotfix. Se o gerenciamento leva o seu amigo a trabalhar mais rápido, como ele costuma fazer, ele deve deixar a pele mais grossa e entrar no modo "quando terminar".

A chave é que tipo de metodologia de desenvolvimento ele possui para protegê-lo até certo ponto? Por exemplo, no Scrum, existe a ideia de que o trabalho que será feito não muda normalmente durante o sprint. Portanto, existem algumas regras sobre o que será feito e o que pode não ser feito imediatamente. A outra pergunta é até que ponto a gerência apóia seu desejo de não estar em uma rotina de suporte? Isso também pode ser importante, pois um gerenciamento apático pode ser um pouco mortal para o projeto de seu amigo.

A melhor coisa a fazer é parar o ônibus e olhar para trás. Seu amigo deveria

• Elabore um relatório de cada problema no sistema e os motivos por que eles são ruins. Os problemas de projeto devem ser destacados e a quantidade de refatoração necessária.
• Devem ser definidos cronogramas aproximados para corrigir os problemas
• O relatório deve ser entregue aos seus gerentes e, em seguida, às partes interessadas no sistema
• Todos os desenvolvimentos de recursos devem ser interrompidos durante o período de fixação.

Muitos projetos fazem isso. Se a gerência não puder ser convencida, é um caso perdido, mas se eles concordarem, o sistema poderá ser restaurado a longo prazo.