Um órgão de auditoria seria apenas para enxugar gelo. Afinal, se o cliente não consegue avaliar uma boa consultoria para si, porque avaliaria bem uma empresa de auditoria? E outra, quem fiscaliza a auditoria? A empresa D?
A relação só vai mudar quando mexerem na raiz do problema: a cobrança de software por horas trabalhadas, que valoriza sempre os profissionais medíocres e projetos de software insignificantes (como atualização de ERP ou projetões SOA). Quando se passar a vender software pelo valor que agrega, será um passo rumo a uma melhor qualidade.
Hummm… quem controla o Procon ? Qual é o cliente que sabe escolher um produto para si na prateleira do supermercado corretamente ?
Essa conversa de controle é que destroi todo o conceito. Ninguem tem que controlar. aliás o proprio conceito de auditoria implica que seja um orgão independente.
Isso é tudo verdade. Mas veja bem, porque a empresa vai faturar um milhão quando pode faturar 2 ? Para o “mercado” não importa o lucro, e sim o faturamento. Esse é o problema.
Muitas pessoas sem conceitos de TI acham que a Accenture é o máximo e ninguem se importa de pagar 60 horas para alterar um ponto-e-virgula. O cliente fala que precisa de mudar e é cobrado por isso.
No mundo real quando vc vai numa loja e o preço é o quadruplo do resto das loja vc vai embora.
O problema é que software é considerado artigo de luxo, ou seja, quanto mais caro, melhor.
Os diretores não estão preocupados em ter boas soluções e sim em ter bodes espiatórios. Se a empres cobra caro é porque ela assume o risco das asneiras do cliente.
Mas mesmo na ferrari ou na rolls royce , cliente é cliente, e a qualidade do produto é a empresa produtora que define, é a reputação da empresa que está em jogo.
Para empresas que têm desenvolvimento interno ( ou seja, produzem o seu proprio produto , ou ferramentas, mas o seu business core não é vender software) o problema é ainda pior. Tudo fica dentro de 4 paredes e não ha para quem apelar. é uma especie de trabalho escravo. É preciso que algo dê muito errado (tipo falencia) para que o modelo seja repensado por esse tipo de empresas. Algumas simplesmente treceirizam, mas a terceirização da produção de software é simplesmente um erro estratégico quando o seu negocio depende daquele software. Por exemplo, vc tem um site de e-comerce e a sua empresa só ganha dinheiro através do site. Vc vai terceirizar o seu ganha pão? É diferente de um ERP que não é o business core da empresa.
Ha duas frentes aqui: os desenvolvedores e os clientes. É pela pressão de ambos que as empresas mudarão.
Algumas empresas com diretores e gerentes visionários já entenderam o conceito e estão ajudando os desenvolvedores, mas falta respingar isso nos clientes para que eles exigem qualidade e saibam ver quando estão sendo enganados. Como ?
quando vc vai comprar um diamante ou uma casa, vc leva um avalista. Ele irá verificar a autenticidade e estado do objeto. Ele vai ajudar vc a fazer a compra certa. O mesmo pode ser feito para software. O cliente contrata uma empresa de avalismo de software. Os representantes dessa empresa vão na produtora de software e veêm se dá. Como ? participando do dia-a-dia da empresa durante um tempo. Se o aval for negativo o contrato cai. Repare que a produtora tem que aceitar a presença do avalista , caso contrario não ha contrato com o cliente.
Existem vários tipos de auditoria possível.
Agora, do outro lado. quem faz essa auditoria? Obviamente pessoas que tendam de criação de software, mas, vc deixaria um Martin Fowler ou um James Glosing meter o bedelho no seu codigo ? Ser famoso não significa ser bom de auditoria… E além disso ha as diretrizes, mas comumente chamadas normas. Não ha norma ISO para como um bom software deve ser. Existem algumas normas ISO para como o processo deve ser (deve ser documentado, por exemplo, mas não diz em que midia ) Se essas regras todos temos as mãos atadas.
Mas temos algo suficiente próximo. Temos convenções e congressos onde as pessoas discutem padrões. Dos mais vários níveis. Pattern, Anti-Pattern, boas prática, etc… essas coisas são reais e funcionam como guias para o que é certo e o que é errado.
Fundamentalmente a comunidade de desenvolvimento (todas as linguagens) tem que adotar Principios e aplicá-los.
Algumas coisas que eram boas no passado ( como a nomenclatura hungara usada no windows) sabemos que não são. Vamos falhar em algumas coisas, mas se 80% estiver bom, já é um avanço extraordinário.
Eu fico emocionado quando alguem usa o padrão Money ou tem a sua própria API de tratamento de datas e tempos ou usa BigDecimal em vez de double ou se vejo alguem usar Produtor-Consumidor ou decorator… o problema é que não vi isso até hoje. As pessoas tendem a pensar “vamos usar o framework X , o Y e o Z e misturar tudo no caldeirão, se daqui a 10 anos a tecnologias mudar, quem vier atrás que feche a porta, o meu já tá ganho”
[quote=Rubem Azenha][quote=luistiagos]
Na grande maioria das vezes… o cliente nem sabe oq e scrum ou metodoligias… nem mesmo sabe o que é programar… ele pensa que se faz software magicamente com o poder da mente… que é so pensar eu quero um software magico e ele simplismente aparece… o cliente só quer seu software magico que resolva todos os seus problemas… em um prazo impossivel e por uma merreca de preço… o grande X da questão é como vender um software para um cliente que tem esta mentalidade?
se alguem souber me falem…[/quote]
Cara… depende do cliente. Embora existam muitos clientes completamente leigos, muitas empresas tem equipes de TI internas (com CIOs, Diretores de TI, Superintendentes de TI, Gerentes de TI) justamente pra cuidarem da aquisição ou desenvolvimento de sistemas de software (entre muitas outras coisas). Essas equipes, teoricamente, deveriam estar capacitadas para pelo menos discutir uma metodologia com o fornecedor.
É claro que em muitos casos que existe essa equipe, a equipe não é muito bem qualificada ou simplesmente esta desatualizada…
Mas se você for no mercadinho da esquina ou na loja de doces do bairro, dificilmente você vai encontrar uma equipe de TI
Mas em empresas de tamanho razoável, sempre tem uma equipe de TI.[/quote]
Tem muita empresa grande que sua equipe de TI é a pirralhada que cuida de suporte e infra-estrutura ou uns pseudo-analistas de sistemas mas que são formados em administração que não sabem nem o que é um select… dai discutir metodologias com este pessoal é o mesmo que discutir com um leigo… o que eles vão querer é simplismente o software magico ou que a gente de uma de Shiryu do CDZ e faça a cascata mudar de lado com um “Colera do dragão”…
[quote=sergiotaborda][quote=luistiagos][quote=Rubem Azenha][quote=asaudate]Mas como alguém conseguiria vender um projeto se alguma coisa não estivesse definida (seja prazo, custo, escopo) ? Acho (veja bem, acho!) que um cliente não gostaria de ouvir “olha, nós temos um prazo XYZ pra isso. Selecione o que você quer, marque o que é mais importante,que nós vamos usar somente esse prazo XYZ pra isso”.
[]´s[/quote]
Eu nunca precisei vender isso, quando participei dum projeto utilizando Scrum, o cliente havia se dado conta das vantagens de um projeto desenvolvimento de forma iterativa e incremental e ele decidiu usar Scrum.[/quote]
Na grande maioria das vezes… o cliente nem sabe oq e scrum ou metodoligias… nem mesmo sabe o que é programar… ele pensa que se faz software magicamente com o poder da mente… que é so pensar eu quero um software magico e ele simplismente aparece… o cliente só quer seu software magico que resolva todos os seus problemas… em um prazo impossivel e por uma merreca de preço… o grande X da questão é como vender um software para um cliente que tem esta mentalidade?
se alguem souber me falem…[/quote]
Esse tipo de situação tem que ser tratada do mesmo jeito que o cara que dizia que podera fazer pontes apenas com a canalização das energias sem usar pilares ou sustentação. Ou com o cara que não deixa que o seu filho leve uma trasnfusão de sangue por causa da religião dele ( dele, não do filho, entenda-se). Vc simplesmente os ignora.
O problema é quando algum idiota lhes dá ouvidos e entra na onda.
Existe o conceito de cliente saudável. Este é aquele que vc quer ter. Essas antas sem cabeça vc quer ficar é longe.[/quote]
O problema e que 99% dos clientes são estas antas… pois geralmente são da area administrativa… gerente de não sei o que la… diretor de não sei o que la… alias ja vi até gerentes de TI que tem esta mentalidade… dai é complicado…
De fato, a mentalidade corporativa esta mais voltada para um modo de operação fixa e repetitiva deixando a desejar quando o assunto é saber tirar proveito das inovações tecnológicas.
O que eu acho curioso é a quantidade de gente querendo matar o monstro com receitas as mais “criativas”, como essa da auditoria, ao invés de simplesmente evitá-lo. Porque não voltam pro seu software e invistam a mesma energia para agregar valor a ele e depois va procurar outros mercados!
em conversa com o colega Rubem Azenha, cheguei à seguinte conclusão: que engenharia de software é o caos que é hoje porque não existe metodologia adequada, até o momento. Quer dizer, temos metodologias tradicionais (iterativo, incremental, etc.) que trabalham com dados (tempo, escopo, custo) definidos, que poderiam muito bem “acertar” estimativas de tempo desde que o escopo se mantenha fixo (coisa que , dificilmente, acontece). Já metodologias agile deixam o escopo aberto , às custas do tempo (mantenha o escopo do jeito que o cliente quer. Ou o tempo será fechado e não serão desenvolvidas todas as funcionalidades, ou mantenha o tempo em aberto e demore mais do que o cliente gostaria).
Então, gostaria de saber de vocês… O que vocês consideram que seria uma solução para o problema?[/quote]
Acho que sua analise não faz sentido.
Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.
em conversa com o colega Rubem Azenha, cheguei à seguinte conclusão: que engenharia de software é o caos que é hoje porque não existe metodologia adequada, até o momento. Quer dizer, temos metodologias tradicionais (iterativo, incremental, etc.) que trabalham com dados (tempo, escopo, custo) definidos, que poderiam muito bem “acertar” estimativas de tempo desde que o escopo se mantenha fixo (coisa que , dificilmente, acontece). Já metodologias agile deixam o escopo aberto , às custas do tempo (mantenha o escopo do jeito que o cliente quer. Ou o tempo será fechado e não serão desenvolvidas todas as funcionalidades, ou mantenha o tempo em aberto e demore mais do que o cliente gostaria).
Então, gostaria de saber de vocês… O que vocês consideram que seria uma solução para o problema?[/quote]
Acho que sua analise não faz sentido.
Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.[/quote]
Assim… só para a gente se situar… qual é a sua experiencia com desenvolvimento e que empresas são essas em que as metodologia funcionam? Já agora, quais são essas metodologias que funcionam ?
em conversa com o colega Rubem Azenha, cheguei à seguinte conclusão: que engenharia de software é o caos que é hoje porque não existe metodologia adequada, até o momento. Quer dizer, temos metodologias tradicionais (iterativo, incremental, etc.) que trabalham com dados (tempo, escopo, custo) definidos, que poderiam muito bem “acertar” estimativas de tempo desde que o escopo se mantenha fixo (coisa que , dificilmente, acontece). Já metodologias agile deixam o escopo aberto , às custas do tempo (mantenha o escopo do jeito que o cliente quer. Ou o tempo será fechado e não serão desenvolvidas todas as funcionalidades, ou mantenha o tempo em aberto e demore mais do que o cliente gostaria).
Então, gostaria de saber de vocês… O que vocês consideram que seria uma solução para o problema?[/quote]
Acho que sua analise não faz sentido.
Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.[/quote]
Assim… só para a gente se situar… qual é a sua experiencia com desenvolvimento e que empresas são essas em que as metodologia funcionam? Já agora, quais são essas metodologias que funcionam ?
[/quote]
Bom, as metodologias foram citadas por quem criou o topico. Basicamente são duas como ele explicou.
em conversa com o colega Rubem Azenha, cheguei à seguinte conclusão: que engenharia de software é o caos que é hoje porque não existe metodologia adequada, até o momento. Quer dizer, temos metodologias tradicionais (iterativo, incremental, etc.) que trabalham com dados (tempo, escopo, custo) definidos, que poderiam muito bem “acertar” estimativas de tempo desde que o escopo se mantenha fixo (coisa que , dificilmente, acontece). Já metodologias agile deixam o escopo aberto , às custas do tempo (mantenha o escopo do jeito que o cliente quer. Ou o tempo será fechado e não serão desenvolvidas todas as funcionalidades, ou mantenha o tempo em aberto e demore mais do que o cliente gostaria).
Então, gostaria de saber de vocês… O que vocês consideram que seria uma solução para o problema?[/quote]
Acho que sua analise não faz sentido.
Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.[/quote]
Assim… só para a gente se situar… qual é a sua experiencia com desenvolvimento e que empresas são essas em que as metodologia funcionam? Já agora, quais são essas metodologias que funcionam ?
[/quote]
Bom, as metodologias foram citadas por quem criou o topico. Basicamente são duas como ele explicou.[/quote]
Você conhece algum lugar (de preferência, consultoria) em que as metodologias (agile ou não agile) funcionam? O projeto sai no prazo , do jeito que o cliente quer?
Existe sim uma metodologia adequada para prever custos e desenvolver software. A essa metodologia se chama experiência e auto-melhoria.
Você só vai conseguir prever e lidar com os problemas que surgirem, e dar um preço para o software se a tua equipe já tiver passado pela situação antes, tê-la revisto, entendido, classificado e quantificado o que ela fez, naquele momento e contexto em que ela fez. E com tudo isso, a equipe define o que ela fez de errado e o que fez de certo, e põe em prática as melhorias, para que ela faça melhor na próxima vez. Esta é a visão estratégica do processo.
A visão tática é o que acontece dentro do próprio projeto em desenvolvimento, estas melhorias ainda acontecem, mas num escopo muito menor. A solução aqui é adotar um processo iterativo de desenvolvimento no escopo do projeto, a cada semana você revê o que fez, entende, classifica, quantifica, e se melhora para a próxima semana.
O que resultado físico de tudo isso são boas práticas, padrões a serem adotados, e a maior eficiência possível.
Seja desenvolimento de software, engenharia civil, medicina, qualquer coisa, esta é o princípio a ser seguido por todas as áreas. A diferença de maturidade é que as outras vem fazendo isso há milhares de anos.
[quote=Bruno Laturner]Existe sim uma metodologia adequada para prever custos e desenvolver software. A essa metodologia se chama experiência e auto-melhoria.
Você só vai conseguir prever e lidar com os problemas que surgirem, e dar um preço para o software se a tua equipe já tiver passado pela situação antes, tê-la revisto, entendido, classificado e quantificado o que ela fez, naquele momento e contexto em que ela fez. E com tudo isso, a equipe define o que ela fez de errado e o que fez de certo, e põe em prática as melhorias, para que ela faça melhor na próxima vez. Esta é a visão estratégica do processo.
A visão tática é o que acontece dentro do próprio projeto em desenvolvimento, estas melhorias ainda acontecem, mas num escopo muito menor. A solução aqui é adotar um processo iterativo de desenvolvimento no escopo do projeto, a cada semana você revê o que fez, entende, classifica, quantifica, e se melhora para a próxima semana.
O que resultado físico de tudo isso são boas práticas, padrões a serem adotados, e a maior eficiência possível.
Seja desenvolimento de software, engenharia civil, medicina, qualquer coisa, esta é o princípio a ser seguido por todas as áreas. A diferença de maturidade é que as outras vem fazendo isso há milhares de anos.[/quote]
em conversa com o colega Rubem Azenha, cheguei à seguinte conclusão: que engenharia de software é o caos que é hoje porque não existe metodologia adequada, até o momento. Quer dizer, temos metodologias tradicionais (iterativo, incremental, etc.) que trabalham com dados (tempo, escopo, custo) definidos, que poderiam muito bem “acertar” estimativas de tempo desde que o escopo se mantenha fixo (coisa que , dificilmente, acontece). Já metodologias agile deixam o escopo aberto , às custas do tempo (mantenha o escopo do jeito que o cliente quer. Ou o tempo será fechado e não serão desenvolvidas todas as funcionalidades, ou mantenha o tempo em aberto e demore mais do que o cliente gostaria).
Então, gostaria de saber de vocês… O que vocês consideram que seria uma solução para o problema?[/quote]
Acho que sua analise não faz sentido.
Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.[/quote]
Assim… só para a gente se situar… qual é a sua experiencia com desenvolvimento e que empresas são essas em que as metodologia funcionam? Já agora, quais são essas metodologias que funcionam ?
[/quote]
Bom, as metodologias foram citadas por quem criou o topico. Basicamente são duas como ele explicou.[/quote]
Você conhece algum lugar (de preferência, consultoria) em que as metodologias (agile ou não agile) funcionam? O projeto sai no prazo , do jeito que o cliente quer?[/quote]
Esta perguntando se conheco algum lugar onde software agrega valor ao negócio do cliente? A resposta é claro que sim!
Não entendi o que consultorias tem a ver com a discussão.
Só o CMM? Acho que citei a história da humanidade aqui.
Todos aqui estão carecas de saber disto? Estão. Isto funciona? Funciona, é o melhor a ser feito. E por que ainda perguntam o que fazer? Parece até que querem um método mágico, que resolva todos os problemas, sem ninguém mover um dedo.
em conversa com o colega Rubem Azenha, cheguei à seguinte conclusão: que engenharia de software é o caos que é hoje porque não existe metodologia adequada, até o momento. Quer dizer, temos metodologias tradicionais (iterativo, incremental, etc.) que trabalham com dados (tempo, escopo, custo) definidos, que poderiam muito bem “acertar” estimativas de tempo desde que o escopo se mantenha fixo (coisa que , dificilmente, acontece). Já metodologias agile deixam o escopo aberto , às custas do tempo (mantenha o escopo do jeito que o cliente quer. Ou o tempo será fechado e não serão desenvolvidas todas as funcionalidades, ou mantenha o tempo em aberto e demore mais do que o cliente gostaria).
Então, gostaria de saber de vocês… O que vocês consideram que seria uma solução para o problema?[/quote]
Acho que sua analise não faz sentido.
Basta observar os lugares onde engenharia de software não é um caos que as mesmas metodologias são utilizadas e com exito. Pense mais um pouquinho, o problema deve ser outro.[/quote]
Assim… só para a gente se situar… qual é a sua experiencia com desenvolvimento e que empresas são essas em que as metodologia funcionam? Já agora, quais são essas metodologias que funcionam ?
[/quote]
Bom, as metodologias foram citadas por quem criou o topico. Basicamente são duas como ele explicou.[/quote]
Você conhece algum lugar (de preferência, consultoria) em que as metodologias (agile ou não agile) funcionam? O projeto sai no prazo , do jeito que o cliente quer?[/quote]
Esta perguntando se conheco algum lugar onde software agrega valor ao negócio do cliente? A resposta é claro que sim!
Não entendi o que consultorias tem a ver com a discussão.[/quote]
Porque você respondeu a pergunta errada. O tópico discute sobre tempo de entrega com qualidade. Não sobre valor agregado. Obviamente, um software (atrasado ou não) tem que agregar valor, senão o cliente não tem porque contratar.
Só o CMM? Acho que citei a história da humanidade aqui.
Todos aqui estão carecas de saber disto? Estão. Isto funciona? Funciona, é o melhor a ser feito. E por que ainda perguntam o que fazer? Parece até que querem um método mágico, que resolva todos os problemas, sem ninguém mover um dedo.[/quote]
Não sei, funciona?? Estou de saco cheio de trabalhar em projetos que a consultoria ganha porque joga o tempo de desenvolvimento lá embaixo - e depois, os desenvolvedores têm que correr atrás do prejuízo.
Entretanto, as consultorias continuam fazendo isso - e essa é a idéia do tópico, pensar em maneiras de coibir esse tipo de atitude.
Só o CMM? Acho que citei a história da humanidade aqui.
Todos aqui estão carecas de saber disto? Estão. Isto funciona? Funciona, é o melhor a ser feito. E por que ainda perguntam o que fazer? Parece até que querem um método mágico, que resolva todos os problemas, sem ninguém mover um dedo.[/quote]
Não sei, funciona?? Estou de saco cheio de trabalhar em projetos que a consultoria ganha porque joga o tempo de desenvolvimento lá embaixo - e depois, os desenvolvedores têm que correr atrás do prejuízo.
Entretanto, as consultorias continuam fazendo isso - e essa é a idéia do tópico, pensar em maneiras de coibir esse tipo de atitude.[/quote]
Elas continuam fazendo isso porque os desenvolvedores continuam sendo capachos. Vc conhece o conceito de greve? Ups… o pessoal é PJ…
Se vc está insatisfeito vc vai embora. Mas um cara de cada vez não afeta em nada a empresa. Apenas se todos boiotarem o processo é que funciona. Tem uns juniors por aqui que acham que fazer hora extra é excelente porque ganham mais dinheiro. E isso faz com que o gerente ache que pode cortar o tempo do projeto para metada porque a equipa vai trabalhar o dobro. Afinal eles não são pessoas, a privação de sono e diversão não afeta a eficiencia deles.
O que falta , caros, é tomates. É coragem de dizer não. Quer que eu faça horas proque ? Porque o cronograma está atrazado ? E quem fez o cronograma ? vc ? E porque vc não seguiu as orientações e estimativas que lhe dei ?
Porque vc não quiz? bom, agora eu tb não quero trabalhar extra. Vai me despedir ? o problema é seu, menos um na sua equipa, mais atrazo no cronograma.
É por isso que o mais importente para um desenvolvedor é ter ética e uma conta bancária que lhe permita o risco de mandar o gerente passear.
Só o CMM? Acho que citei a história da humanidade aqui.
Todos aqui estão carecas de saber disto? Estão. Isto funciona? Funciona, é o melhor a ser feito. E por que ainda perguntam o que fazer? Parece até que querem um método mágico, que resolva todos os problemas, sem ninguém mover um dedo.[/quote]
Não sei, funciona?? Estou de saco cheio de trabalhar em projetos que a consultoria ganha porque joga o tempo de desenvolvimento lá embaixo - e depois, os desenvolvedores têm que correr atrás do prejuízo.
Entretanto, as consultorias continuam fazendo isso - e essa é a idéia do tópico, pensar em maneiras de coibir esse tipo de atitude.[/quote]
Consultorias jogam o tempo de desenvolvimento lá embaixo porque o negócio delas não é criar software, e sim vender contratos de prestação de serviços nos moldes que o cliente corporativo esta acostumado para contratar um serviço pra arrumar o telhado, por exemplo. Para elas não interessa a metodologia ou engenharia de software, enquanto houverem programadores dispostos a serem recrutados pra fazer o trabalho pesado.
Não chega ser um problema de metdologia X ou Y, muito menos que “a engenharia de software” está um caos.
Acontece que as consultorias vão continuar fazendo isso pra sempre, enquanto não houver meios de lutar contra isso. Se é um problema de engenharia de software propriamente dito ou não, não sei responder. Mas o atual estado das coisas é esse.
E não acho que uma greve vá resolver, simplesmente porque esse tipo de coisa é organizada por um sindicato. E todo mundo sabe que o sindicato dos trabalhadores de TI (daqui do Brasil, pelo menos) é uma piada, daquelas bem ruins.
Só o CMM? Acho que citei a história da humanidade aqui.
Todos aqui estão carecas de saber disto? Estão. Isto funciona? Funciona, é o melhor a ser feito. E por que ainda perguntam o que fazer? Parece até que querem um método mágico, que resolva todos os problemas, sem ninguém mover um dedo.[/quote]
Não sei, funciona?? Estou de saco cheio de trabalhar em projetos que a consultoria ganha porque joga o tempo de desenvolvimento lá embaixo - e depois, os desenvolvedores têm que correr atrás do prejuízo.
Entretanto, as consultorias continuam fazendo isso - e essa é a idéia do tópico, pensar em maneiras de coibir esse tipo de atitude.[/quote]
Elas continuam fazendo isso porque os desenvolvedores continuam sendo capachos. Vc conhece o conceito de greve? Ups… o pessoal é PJ…
Se vc está insatisfeito vc vai embora. Mas um cara de cada vez não afeta em nada a empresa. Apenas se todos boiotarem o processo é que funciona. Tem uns juniors por aqui que acham que fazer hora extra é excelente porque ganham mais dinheiro. E isso faz com que o gerente ache que pode cortar o tempo do projeto para metada porque a equipa vai trabalhar o dobro. Afinal eles não são pessoas, a privação de sono e diversão não afeta a eficiencia deles.
O que falta , caros, é tomates. É coragem de dizer não. Quer que eu faça horas proque ? Porque o cronograma está atrazado ? E quem fez o cronograma ? vc ? E porque vc não seguiu as orientações e estimativas que lhe dei ?
Porque vc não quiz? bom, agora eu tb não quero trabalhar extra. Vai me despedir ? o problema é seu, menos um na sua equipa, mais atrazo no cronograma.
É por isso que o mais importente para um desenvolvedor é ter ética e uma conta bancária que lhe permita o risco de mandar o gerente passear.[/quote]
A única vez que vi isso foi numa consultoria que trabalhei, tinha um gerente que fez todo mundo fazer hora extra e a galera não recebeu o salário depois. No dia seguinte, ninguém apareceu. ninguém. Só ai a diretoria quiz saber o que tava acontecendo, chamou os desenvolvedores pra conversar, acertar os valores e etc. Pior é que da equipe foi todo mundo embora, e o gerente continua lá até hoje.
[quote=mario.fts][quote=sergiotaborda]
É por isso que o mais importente para um desenvolvedor é ter ética e uma conta bancária que lhe permita o risco de mandar o gerente passear.[/quote]
A única vez que vi isso foi numa consultoria que trabalhei, tinha um gerente que fez todo mundo fazer hora extra e a galera não recebeu o salário depois. No dia seguinte, ninguém apareceu. ninguém. Só ai a diretoria quiz saber o que tava acontecendo, chamou os desenvolvedores pra conversar, acertar os valores e etc. Pior é que da equipe foi todo mundo embora, e o gerente continua lá até hoje.[/quote]
Então, o problema é esse. Como as coisas são organizadas hoje em dia o gerente haje como um buffer. Seja ele ruim ou bom, nada do que acontece na equipa ou com a equipa vaza para o resto da empresa. A equipa não é livre de ir ao superior do gerente e se queixar ou ir no RH e se queixar (que seria o natural em empresas onde o RH é sério). Então é como no exercito. Se o teu superior te manda fazer algo e tu não obdeces é desacato (dá cadeia e castigos militares… no nosso caso vai para a rua. O que pode ser bom ou mau).
mas quando o chefe dá uma ordem “inobedecivel” qual é a reação que se espera? no mundo militar é seguir e logo se vê pois os subalternos nunca são prejudicados pelas decisões dos chefes, mas no mundo de desenvolvimento no brasil é ao contrário. Vc tem que seguir porque senão o gerente vai convencer o diretor que a culpa é sua, ou da equipe com um todo.
Porque os diretores são mais alienados que os gerentes e muitas vezes estão de conluio com eles (afinal se o gerente nunca reportar problemas eu sou otimo diretor) essa hierarquia nunca muda. É por isso que o Scrum tem tão pouca penetração, porque ele destroi a hierarquia e se o gerente é ruim isso transparece nos primeiros meses. Ai ele tenta dizer que scrum é que é culpado, e não funciona, mas é ele que “não funciona”.
Se vc é CLT , infelizmente, vc está vinculado pelas mesmas regras que no exercito. Vc tem que obedecer. Mas se vc é PJ, vc não tem que aturar isso, e vc vai falar com quem vc quiser. Quem não gostar que grite. Vc pode sempre ir embora.
Quando a equipa reage e os diretores mantém o gerente ou as práticas, a mensagem é :“quem não goste que se mude” e é por isso que todo o mundo acaba indo embora. Ninguem observa a estratégia por detrás. Ninguem aufere o risco de perder todo o know-how de uma vez só. E ninguem está preocupado. Se eles não estão, porque estamos nós? Porque temos ética. E a ética é uma doença incurável. Então parte em busca de um ambiente melhor.
Quando o cinto aperta quem vc acha que será sacrificado primeiro ? o desenvolvedor de quem depende o sucesso do projeto ou o gerente que na realidade não faz nada ?
