O que fazer quando o seu projeto “com falha” é realmente “bem-sucedido”?

14

O que você faria se estivesse em uma situação onde o projeto no qual você está trabalhando é obviamente mal construído e terá fracassos no futuro e será um pesadelo para se manter ... mas é considerado um "sucesso" pela gerência porque os clientes estão felizes?

Eu não deveria me importar? Está certo que os clientes nem percebem que poderiam ter uma aplicação melhor que essa?

Em que ponto eu paro de pensar em construir direito e seguir com o fluxo?

    
por James P. Wright 01.08.2011 / 22:25
fonte

7 respostas

37

Se os clientes estão felizes, você está fazendo algo certo. Muita gente gosta de cachorro-quente sem saber como eles são feitos ...

Se o aplicativo for uma boa solução para o problema, mas você estiver preocupado com a falha da fundação, descubra como melhorar as coisas incrementalmente e defina um plano para implementar essas melhorias à medida que você atualiza produtos. Incremental é a chave: se você está ansioso para reescrever partes inteiras dele, seu gerente dirá que isso é irracional. O perfeito pode ser inimigo do bem. Consulte a história do jwz de como o Netscape permite que o IE assuma a liderança porque eles "tiveram que" reescrever o Navigator.

Se a interface do usuário do aplicativo for uma bagunça, os clientes ainda podem estar felizes porque estão comparando com o "caminho difícil" e até um programa com erros pode ser um pouco melhor do que isso. Você está comparando-o a um ideal que você pode imaginar por causa de sua experiência e habilidades. Mais uma vez, considere como você pode melhorar as coisas de formas incrementais e defina isso como parte do plano.

Não pare de se importar: você quer que seu trabalho seja o melhor possível. Mas lembre-se também que é o cliente que paga suas contas e você está escrevendo software para eles, não para você.

    
por 01.08.2011 / 22:36
fonte
4

Não é um pesadelo para eles. Será um pesadelo para você e eles parecem pensar que você sabe o que está fazendo, então será consertado. Você prefere pessoas que não entendem e programam que seu aplicativo é pior do que realmente é? Esta não é a exceção. Aproveite isso enquanto você pode. É melhor você esperar que o cliente ultrapasse esse aplicativo. Eles podem ir tão longe em outra direção como um negócio que isso é absolutamente inútil. Você poderia reescrevê-lo por um conjunto totalmente diferente de razões que você pensa.

    
por 01.08.2011 / 22:40
fonte
3

Eu não acho que você deveria parar de se importar, mesmo que pareça que a alta administração parou. Acho que o importante a tirar dessa experiência é lembrar e documentar todas as coisas que você acha que deram errado. Evitar esses erros no futuro acabará sendo reconhecido, se não for esse grupo atual de gerentes, talvez o próximo grupo de gerentes para o qual você trabalha.

    
por 01.08.2011 / 22:59
fonte
2

Eu começaria a apresentar ideias para as próximas etapas do desenvolvimento que incluem o refatoração para melhorar a qualidade do código. Evite aprofundar-se nos detalhes técnicos, mas indique como as correções sugeridas vão significar continuidade satisfação do cliente. Esteja preparado para misturar a limpeza com novos recursos, pois a gerência sempre estará procurando algo novo para vender.

Em geral, os clientes não se preocupam com a manutenção até que algo dê errado. Idealmente, sua empresa se preocuparia com sua reputação e desejaria protegê-la mantendo o código.

No entanto - se este produto for visto como muito curto prazo, pode não haver realmente um valor agregado para fazê-lo corretamente. Nesse caso - procure as soluções baratas - as coisas com pouco esforço que têm um grande valor para a sanidade do desenvolvedor.

    
por 01.08.2011 / 22:31
fonte
2

Você não faz. Você usa o sucesso para garantir financiamento / permissão / buy-in para iniciar a refatoração para tecnicamente correto e fácil de manter. Ou você usa o sucesso para ser promovido do departamento "Consigo manter o velho código base".

    
por 01.08.2011 / 22:31
fonte
0

Talvez sua prioridade / ponto de vista esteja errado.

O mais importante sobre qualquer projeto de software é satisfazer os requisitos do usuário.

Isso é um zilhão de vezes mais importante do que estar "correto" de acordo com os meses de moda do projeto C / S.

Sim, você deve usar padrões de design corretos, usar a tecnologia corretamente etc.etc. mas apenas na medida em que torna mais fácil implementar os requisitos dos usuários de uma maneira robusta e sustentável.

Um sistema realmente mal escrito, que realmente atende a uma necessidade comercial, é sempre melhor do que um pedaço de código maravilhosamente escrito e bem documentado, que ninguém quer ou tem algum motivo para usar.

    
por 02.08.2011 / 09:24
fonte
0

Tente se comunicar com os usuários atuais e pergunte quais aspectos eles acham que precisam ser melhorados. Então você poderia melhorar alguns aspectos que você acha que precisa melhorar e melhorar também os aspectos que os usuários propuseram. Você pode justificar suas melhorias como "necessárias para implementar melhorias propostas pelo usuário"

Por exemplo: se os usuários acharem que a função de pesquisa é lenta. Você pode melhorar isso criando uma camada de dados melhor que, obviamente, serve mais do que apenas a pesquisa, mas você pode justificar o tempo gasto.

    
por 02.08.2011 / 10:04
fonte