Como salvar um projeto jovem e moribundo?

Estou postando isso anonimamente porque não quero entrar em um problema em potencial.
Eu tenho um grande problema.
Recentemente, entrei para uma equipe com menos de um ano de idade. Estou aqui há um mês para o início do projeto. A estrutura da empresa fica assim:

• Proprietário (não técnico)
  • Gerente de projetos (não técnico)
    • Desenvolvedor Líder (Técnico, mas ruim nisso)

Este projeto é um site usando o ASP.Net para o qual o Desenvolvedor Líder projetou uma arquitetura horrível. Você terá que aceitar minha palavra, mas basicamente, a maneira como somos obrigados a criar páginas da web está nos fornecendo mais de 3 minutos de carregamento em uma única página da Web através da VPN no modo Debug.

Ele chegou ao ponto em que outros colegas de trabalho concordam que passam mais do dia esperando o carregamento das páginas do que o desenvolvimento real.

Agora o grande problema é esse. O gerente de projetos não conhece a tecnologia e a admite. Ele declarou especificamente que confia no desenvolvedor líder para fazer as escolhas corretas na arquitetura do aplicativo.

Ninguém na equipe sabe qual seria a opinião dos Proprietários, mas todo mundo tem medo de criar ondas nessa economia (especialmente eu).

O que você faria?

Esse problema pode ser demonstrado ao gerente de projeto em termos muito não técnicos. Coloque seu site em uma janela do navegador em frente ao PM e peça para ele brincar com ele por um tempo. Após cerca de duas páginas carregadas, o desenvolvedor líder deve ser chamado no tapete, se as coisas estiverem tão ruins quanto você diz.

O PM pode não ter o conhecimento especializado em desenvolvimento para entender por que isso é ruim, mas ele pode ver por si mesmo como um usuário geral do site. Outros sites que exibem informações semelhantes são carregados em uma fração do seu tempo e o seu está sendo carregado na rede local a partir do servidor na sala ao lado.

Se isso não acontecer, vá para o proprietário. O proprietário é um cara de dinheiro, mas rapidamente verá um site lento que ninguém visitará == sem dinheiro. Faça a mesma demonstração e, antes que a primeira página seja carregada, ele deverá ligar para o PM e o Lead em seu tapete muito mais fino.

Se você está preocupado com um cara que está agitando, considere mais de um desenvolvedor disposto a expressar suas preocupações. Honestamente, em uma empresa tão plana quanto a sua, se o produto que você está desenvolvendo for uma bomba, você estará sem trabalho, seja falando ou se calando. Então, olhando dessa maneira, você não tem nada a perder além de algumas semanas ou meses extras com a empresa. Se isso for um problema, programe algumas "consultas de dentista" e procure um novo emprego antes de expor suas preocupações. Portanto, se você perder este emprego, começará na próxima segunda-feira.

Supondo que suas declarações sejam precisas, você tem um desenvolvedor líder que é incompetente e um gerente de projeto que é incompetente (pelo menos na medida em que ele não pode avaliar as habilidades da equipe). Bem. Você tem exatamente as mesmas opções que os desenvolvedores em todas as equipes do mundo.

1. Você trabalha sem cuidar da saúde da empresa.

2. Procure trabalho em outro lugar.

3. Faça sugestões razoáveis ​​ao Líder, Primeiro Ministro e Proprietário e espero que sejam adotados.

Você é livre para fazer qualquer combinação dos itens acima simultaneamente.

Se você deseja garantir agressivamente a saúde do projeto, precisará trabalhar com os outros desenvolvedores para criar uma nova estrutura em seu tempo livre e demonstrar ao restante da equipe por que ela é superior e o trabalho antigo deve ser abandonado em favor dele.

Eu trabalhei em uma situação semelhante, onde o desenvolvedor líder que era realmente um parceiro da empresa havia criado o "núcleo" do software e, com exceção de um amigo próximo que trabalhava diretamente com ele, outros desenvolvedores não tinham permissão para tocar no testemunho.

Os "poderes que existem" também criaram regras como cada módulo, podendo ter apenas uma tabela de banco de dados, porque é mais limpo assim. E, como resultado disso, as listas suspensas existentes foram criadas selecionando "DISTINCT" nas tabelas do banco de dados, em vez de ter uma tabela separada.

Havia uma série de patches ruins flutuando porque a equipe de implementação tinha que fazer o trabalho e o produto não funcionava imediatamente. Esses patches causavam tantos problemas quanto eles corrigiam e eram personalizados (hackeados) para cada instalação.

Minha abordagem foi pegar uma pequena parte da especificação que o núcleo não suportava e escrever um patch pequeno, bom e genérico para ela. Algo que satisfez a equipe de implementação, mas não era tão ameaçador quanto "Precisamos mudar completamente nosso pensamento". Devido à animosidade entre a equipe de implementação e os desenvolvedores principais, levou meses para convencer a equipe de implementação de que minha abordagem era melhor do que os hacks deles. Mas uma vez que eles viram que eu os ouvia e implementei ajustes adicionais para apoiá-los, eles ficaram encantados e do meu lado. Demorou mais um mês para o desenvolvedor líder aceitar o patch, mas uma vez que ele fez isso realmente abriu a comunicação entre todos nós sobre melhores maneiras de projetar outras partes do sistema.

Nunca é um caminho curto para mudar o pensamento das pessoas, especialmente se você precisar manter um relacionamento civil com elas. Mas, se você agir da maneira certa, poderá ganhar respeito sem insultar seu chefe.

Espero que ajude!

Resposta e solução muito simples. Parece que todos estão cientes do problema. Assim, você sair por aí apontando o problema não tem valor para ninguém. Na verdade, apenas faz você parecer um chorão. Se você deseja agregar valor, precisa apontar a solução e criar o business case para mudar para sua solução. Em seguida, você pode apontar o problema com uma solução correspondente. Uma demonstração também ajudaria bastante a provar sua solução. Claro, isso pode significar trabalhar no seu próprio tempo, mas tudo depende de quão importante é você também.

Antes de tudo, sugiro enfaticamente que você verifique seus fatos, pois é um problema de arquitetura de aplicativo e não algo na configuração da VPN. Vi VPNs mal configuradas causar esse problema exato. Você tem certeza de que o aplicativo é tão lento dentro do escritório?

Se você descartou a rede, eu aceitaria a sugestão do KiethS e solicitaria que o PM abrisse a página.

Parece o negócio, ou pelo menos o projeto vai falir em algum momento em breve. Antes de desistir, eu tentaria me distanciar dele o mais rápido possível, por exemplo. voluntário / solicite trabalho em outros projetos em andamento. Com sorte, com o tempo, você estará gastando menos tempo com esse desastre e mais em outros projetos que têm chance de funcionar. Você não quer ser visto como 'o cara que trabalhou no projeto que não deu certo'. É tudo sobre como proteger sua reputação.

O proprietário quer um bom produto ou não? Eu suspeito muito que a resposta seja "Sim" ... e, portanto, você precisa se manifestar. Você precisa documentar a arquitetura atual e, em seguida (com bons dados imperiais), mostrar como o produto não atende às expectativas de desempenho adequadas. Você diz que todos os seus colegas sabem que o desempenho é ruim - bem ... e o cliente? O que estão dizendo? Use uma ferramenta de medição de desempenho e determine o que está demorando tanto. Muitas ferramentas até mostram quanto tempo leva cada chamada de função. De todos esses dados, você deve ter munição suficiente para conversar com o gerente de projeto e o líder técnico sobre por que as coisas não estão do jeito que deveriam e como alguma refatoração importante pode ser necessária para acelerar o produto.

Então (somente depois de conversar com o PM e o líder), isso DEVE ser suficiente para começar a fazer algumas alterações. Se o PM não está convencido nesse momento, você precisa decidir se esse é realmente o lugar que você quer estar. Se sim, então possivelmente uma reunião com o proprietário. Caso contrário, prepare esse currículo.

Certifique-se de documentar tudo em todas as etapas.

Em termos técnicos, concordo com as sugestões acima. Por outro lado, sinto que é mais uma questão de relação do que técnica.

Se você quiser seguir o caminho tranqüilo, conversar com o desenvolvedor líder será uma escolha adequada. Eu não falaria no escritório. Tomar um café lá fora tornará as coisas um pouco informais e mais relaxadas.

Se isso não funcionar, você pode tentar conversar com o PM e depois com o proprietário.

Se não funcionar, sugiro que procure um novo emprego.

Honestidade - e o máximo de tato possível.

Comece com o desenvolvedor líder e suba se for necessário. Tente envolver os lados melhores de sua personalidade - Se você lidera os desenvolvedores, gosta de resolver problemas / gosta de salvar o dia / gosta de ser eficiente / etc., expresse o problema nesse assunto - Não será ruim apontar casos em que eles tiveram sucesso no passado como motivação adicional.

Se você não está fazendo algumas ondas, provavelmente está morto na água.

Seria possível trazer os problemas de volta a um nível mensurável e de maneira não técnica, para que o gerente e o proprietário do projeto possam entender.

Por exemplo, você mencionou o tempo de carregamento lento de mais de 3 minutos, presumo que exista um requisito de desempenho em algum lugar da especificação, algo tão simples quanto "página a ser carregada em 1 segundo". Algo assim é mensurável e não pode ser refutado. Se a causa raiz desse problema for a arquitetura desonesta, o gerente do projeto e / ou o proprietário deverão entrar em cena para forçar algumas alterações.

Caso contrário, você tem um problema sistemático em sua empresa, onde a análise inicial foi mal realizada e não há processo suficiente para detectar esse tipo de problema. Considere saltar navio!

Homens de verdade falam sem ressentimento ou emoção. Esse é o truque.

A única razão válida pela qual alguém pode estar chateado com você por se manifestar é se você se mostra ressentido:

O DESENVOLVEDOR Líder não tem pistas do que está fazendo. Eu sabia que isso ia acontecer, mas ninguém me ouviu blá blá blá.

enquanto que

O modelo de código está incorreto porque é difícil de manter e lento. Precisamos ser estratégicos quanto a esse avanço e corrigir esses dois problemas.

O primeiro é uma batalha para destruir, o segundo é uma batalha pela paz e, a longo prazo, conquistará o respeito de uma pessoa por ser honesto.

Se o líder do projeto considerar isso como um problema, o que ele certamente pode considerar que pode ser demitido, basta dizer:

Não me responsabilize por coisas que não fui responsável por implementar. Eu só estou sendo honesto.