[enquete] Você tem acesso aos servidores de produção?

[psevestre]

Nos casos que eu passei e vi, não era dessa forma. O cliente já disponibilizava um ambiente pronto. Bastava trabalhar em cima.

Por “ambiente”, estou me referindo a um pouco mais do que apenas SO/AppServer/etc. É tambem toda configuração do mesmo que é necessário para uma aplicação rodar: datasources, diretórios específicos, parâmetros de configuração, etc.

A infra básica realmente costuma ser uma condição de contorno, e, via de regra, é razoavelmente conhecida do desenvolvedor tb. (vai ser oracle ou sqlserver ? Java ou PHP ou ASP ?)

Isto não isenta o desenvolvedor de passar o as informações de configuração específicas da aplicação para a produção e, neste contexto, já vi muita besteira sendo feita por programadores que colocavam senhas, endereço de servidor, diretórios, etc, travados no código, só para citar um erro comum.

E se seu log mostra o erro corretamente, vc argumenta cheio de razão, vê que a causa do problema está mais do que clara e o time de produção singelamente tira o corpo fora?

Estava claro para você. Será que estava claro para um leigo ? Mesmo que estivesse, seres humanos nem sempre respeitam a lógica. Nestas horas você deve ser menos analista e mais terapeuta de sistemas ;^).

Pra vc ter uma idéia mínima, uma das coisas que aconteceu: o servidor de testes era win2000srv e o de produção era win2003srv, que têm diferenças consideráveis entre os IISs, e o cliente jurava de pés juntos que era o mesmo sistema operacional.

Seu caso apenas reforça minha tese. Um checklist de ambiente embutido na aplicação certamente teria poupado horas e horas de discussão inútil. Se a aplicação assumia 2K e está rodando em 2K3, e este ambiente não foi homologado, era obrigação da aplicação recusar-se a rodar, dando uma mensagem bem berrante: “Esta aplicação não pode ser executada neste ambiente. Motivo: O sistema operacional para o qual foi homologado é W2K. Sistema operacional atual: W2K3. Cabeção.”. Tudo bem, eu tiraria na versão final o “Cabeção” ;^).

[MarcioTavares]

[quote=“psevestre”]Isto não isenta o desenvolvedor de passar o as informações de configuração específicas da aplicação para a produção e, neste contexto, já vi muita besteira sendo feita por programadores que colocavam senhas, endereço de servidor, diretórios, etc, travados no código, só para citar um erro comum.[/quote]Concordo.

[quote=“psevestre”]Estava claro para você. Será que estava claro para um leigo ? Mesmo que estivesse, seres humanos nem sempre respeitam a lógica.[/quote]Como eu falei antes, os problemas que eu passei não aconteceram de um dia pro outro. Não foi um só problema. E quem lidava com os servidores de produção não eram leigos não. Eu entendo a sua questão de generalizar a situação pra mostrar que a vida de quem “vive em produção” não é fácil. Ninguém disse o contrário. Como eu falei, eu mesmo já cometi muitos erros, já vi muita gente cometendo erros, mas isso não significa que só existam santos no time de suporte. Pelo contrário.

[quote=“psevestre”]Nestas horas você deve ser menos analista e mais terapeuta de sistemas ;^).[/quote]Pois é, foi o que eu falei do costume de sempre tentarem achar um culpado pra tudo. Antes de mais nada temos de ter um acusado. Ninguém assume nada e o outro está sempre errado. Da mesma forma que eu deveria ser mais “terapeuta”, quem lida com fornecedores poderia ser só um pouco menos estúpido. Já melhoraria muito.

[quote=“psevestre”]Seu caso apenas reforça minha tese. Um checklist de ambiente embutido na aplicação certamente teria poupado horas e horas de discussão inútil. Se a aplicação assumia 2K e está rodando em 2K3, e este ambiente não foi homologado, era obrigação da aplicação recusar-se a rodar, dando uma mensagem bem berrante: “Esta aplicação não pode ser executada neste ambiente. Motivo: O sistema operacional para o qual foi homologado é W2K. Sistema operacional atual: W2K3. Cabeção.”. Tudo bem, eu tiraria na versão final o “Cabeção” ;^).[/quote]Tese? Que tese? Leia o meu post anterior novamente com mais atenção. No caso que eu exemplifiquei ninguém fazia idéia de que o sistema operacional de produção era win2003. Até mesmo boa parte dos intermediários de dentro do cliente não sabiam. O próprio pessoal técnico do cliente dizia que o sistema era win2000. E mesmo assim, só foram “descobrir” o problema meses depois de esgotarmos todas as possibilidades. Como eu falei, não foi com uma empresa pequena que isso aconteceu e não foi com gente inexperiente. E sim, eles tiveram que enfiar o rabo entre as pernas e assumir a culpa.
Repetindo: da mesma forma que eu deveria ser mais “terapeuta”, quem lida com fornecedores poderia ser só um pouco menos estúpido. Já melhoraria muito. E isso só reforça a minha tese de que, se hoje em dia existe um estigma com times de suporte, não é à toa.

[Luca]

Olá

Se o servidor de produção está dentro da empresa que eu trabalho então ainda posso tentar mudar alguma coisa. Mas se está no cliente que paga meu projeto e se a diretoria da empresa em que eu trabalho aceitou este modo de trabalhar, só resta me adaptar.

Acho que esta discussão acaba inóqua porque não vai fazer o desenvolvedor entender as dificuldades do operador e nem o operador perceber a necessidade de alterar o modo de trabalhar que aprendeu nos treinamentos.

Quando um programador tem algum problema para implantar alguma coisa em um ambiente de homologação ou de produção, basta colocar ppr escrito suas dificuldades e passar a bola para quem tem mais condições de resolver. Só não pode criar stress com o cliente.

[]s
Luca

[psevestre]

[quote=MarcioTavares] mas isso não significa que só existam santos no time de suporte. Pelo contrário.
[/quote]

Nem santos nem demônios. Apenas gente, e certamente falível, como no “outro lado”.

quem lida com fornecedores poderia ser só um pouco menos estúpido. Já melhoraria muito.

Mesmo face a atitudes estúpidas, é a forma como se apresenta a situação e a postura, que sempre deve ser colaborativa e não majestática, que pode contribuir para a solução.

É delicado, pois o cenário típico envolve três atores distintos: o time de produção, desenvolvimento e o cliente de negócio, que paga a conta dos dois.

Pressionando por resultados, a tendência do cliente é suspeitar, e muito, do desenvolvimento, especialmente se ele não tiver perfil técnico e tiver participado do projeto desde sua concepção.

Explico: a produção é vista como algo mais próximo da realidade concreta. Afinal, o cliente vê servidores, equipamentos de rede, etc e tem impressão de uma certa “robustez”. Software, por outro lado, é algo meio esotérico, imaterial e - principalmente - caro.

Ah, sem contar que 75% dos projetos de software não atendem às necessidades do cliente e estouram em 100% o tempo estimado, entre outras estatísticas desagradáveis (gg: Software Crisis).

Tese? Que tese? Leia o meu post anterior novamente com mais atenção. No caso que eu exemplifiquei ninguém fazia idéia de que o sistema operacional de produção era win2003.

A tese de que a aplicação tem que estar preparada para um ambiente “hostil”. No seu caso, a aplicação seria capaz e, em minha opinião, teria o dever de informar claramente que o ambiente estava incorreto.

Nesta linha, sugiro uma pesquisa em alguns casos bem documentados de prejuízos gigantescos causados por software.

Como contra exemplo, tem um que gosto de citar para meu pessoal, que é o do computador de bordo da 1a nave que pousou na lua. Pelo que li, (uma DDJ, se não me engano), uma determinada rotina responsável pelo cálculo da quantidade de potência a aplicar nos retrofoguetes usava uma fórmula qualquer que incluia uma divisão. A especificação da rotina não falava nada sobre o tratamento a dar em caso de divisão por zero. O programador, por conta própria, resolveu colocar um tratamento. Resultado: na aproximação final, aconteceu a divisão por zero e, se não fosse o tratamento colocado, a nave abriria mais uma cratera na lua…

E isso só reforça a minha tese de que, se hoje em dia existe um estigma com times de suporte, não é à toa.

O estigma existe entre os desenvolvedores, e garanto que é recíproco por parte da produção - até aí dá empate ;^).

Nos níveis superiores, onde as áreas convergem, o que chega são os números, e estes não são muito favoráveis para o desenvolvimento.

Eu sei que são disciplinas diferentes e que não se pode medir as duas áreas da mesma maneira, afinal a produção de TI pode ser tratada com o ferramental clássico de engenharia de processos por ser mais “quadrada” (e tem que ser !). Já o desenvolvimento de software ainda é algum um tanto - como direi ? - imprevisível.