Fui propositalmente exagerado, como deve ter sido possível perceber.
É claro que há nichos e nichos, em qualquer área. Mesmo quando se fala de desenvolvimento, há uma gama de funções cujo perfil ideal é bastante variado.
No entanto, quando se trata de projetos de alta tecnologia, onde os paradigmas mudam dia a dia, o perfil da equipe é determinante para o sucesso ou fracasso. E ser auto-didata é uma das características mais desejáveis nesse perfil. Acredito que não haja treinamento que mude isso (mas aí já entramos num campo antropológico demais pra prosseguir).
Pessoalmente, acho que cortar os pulsos é uma solução um tanto quanto dramática. Sugiro tentar buscar outra área, onde ser auto-didata não seja um requisito tão presente e forte.
Não creio que não ser auto-didata seja uma restrição muito grande. Realmente não existe treinamento para que uma pessoa seja auto-didata, mas se o seu projeto vai ser desenvolvido no Jboss Seam você que é auto-didata pode aprender a tecnologia em 3 dias e fazer um treinamento para as outras pessoas que não são auto-didata.
Talvez uma dessas pessoas seja um code hose que depois que aprender o Seam vai implementar 3 casos de uso por dia, enquanto você só implementará 1.
[quote=rodrigoy]nunca ví processo prescritivo funcionar direito.[/quote]Tb não, mas ajuda. Não sou ingênuo e sei bem que sempre existem as malditas exceções que ficam sempre fora do processo. 18 anos de praia ganhando mal …
[quote=rodrigoy]Sei que para nossa área parece irresistível tentar controlar como a equipe vai se comportar. As pessoas tem medo quando um caso de uso fica ligeiramente diferente um do outro. Ficam incomodadas quando um diagrama está de um jeito e outro de outro. Esse “medo” é natural, mas o custo para você eliminar esse medo é alto demais![/quote]Concordo, mas acho que isso tudo é um pouco de falta de bom senso e excesso de academissismo. O quê interessa mesmo é algo que esteja no meio termo.
[quote=rodrigoy]Vou falar uma coisa muito importante: a maioria das vezes que o gestor covarde diz que quer um processo se você pesquisar a fundo você vai ver que as pessoas da equipe não sabem levantar requisitos, eleger uma arquitetura, programar OO, definir estratégia de teste e gerenciar o projeto. O processo de maneira alguma vai suplantar deficiências no skill das pessoas. Não é função do processo ensinar ninguém.[/quote]Também concordo, mas lembro um pouco do quê o PMI diz sobre isso: se o projeto não vai bem há uma grande chance de ser culpa desse mesmo gerente …
[quote=rodrigoy]Um processo altamente prescritivo é motivado pelo medo, esse medo vai levar você a montar uma área SQA que vai te custar caro, o medo vai levar você ao vício do controle e você vai precisar de um PMO. O medo vai levar você ao lado negro da força.[/quote]Não é nosso caso. Hoje nosso problema principal é: quanto custa esse projeto? Fora o quê vc mencionou antes: gente que não sabe levantar requisito, analista de mentirinha, arquiteto de playmobil, etc.
[quote=Taz]Concordo com a maior parte do que vc disse, mas discordo quando vc afirma que “as pessoas da equipe não sabem levantar requisitos, eleger uma arquitetura, programar OO, definir estratégia de teste”.
9 de cada 10 projetos afundam por incompetência GERENCIAL e não por incompetência técnica.[/quote]Não concordo muito não. Cansei de ver gente incompetente (ou apenas desmotivada) botando a culpa do fracasso desses projetos em ferramenta xyz, falta de treinamento, etc. Todos esses ítens são difíceis de avaliar. Como saber que o requisito foi mal levantado? O quê é uma boa arquitetura? Não é justo responder isso sem participar do projeto e nem tam pouco saber as motivações dessa arquitetura.
Pode até ser incopetência gerencial, mas trabalhamos em time não é? quer dizer que se o projeto afunda a culpa toda é do gerente? putz, me lembre de nunca ser seu gerente!!!
Lembre que o gerente vive re-negociando os prazos que nem sempre conseguimos cumprir (lembra daquele requisito que vc disse que fazia em 3 dias???)
E o coitado acaba sendo obrigado a acreditar naquele mané que ficou o dia inteiro acessando internet …
[quote=bzanchet]No entanto, quando se trata de projetos de alta tecnologia, onde os paradigmas mudam dia a dia, o perfil da equipe é determinante para o sucesso ou fracasso. E ser auto-didata é uma das características mais desejáveis nesse perfil. Acredito que não haja treinamento que mude isso (mas aí já entramos num campo antropológico demais pra prosseguir).[/quote]Assino em baixo.
[quote=rodrigoy]Não creio que não ser auto-didata seja uma restrição muito grande. Realmente não existe treinamento para que uma pessoa seja auto-didata, mas se o seu projeto vai ser desenvolvido no Jboss Seam você que é auto-didata pode aprender a tecnologia em 3 dias e fazer um treinamento para as outras pessoas que não são auto-didata.[/quote]Ser auto-didata não significa necessariamente ser bom instrutor. Se não te entenderem vc só vai saber depois que fizerem m. O ser humano tem uma forte tendência de dizer sim quando na verdade deveria dizer não. Por mais que vc tente ajudar a galera sempre quer aprender sozinha,mostrar que é bom e tal (perfil, de novo).
Infelizmente não saímos de fábrica com tecla SAP (e algumas mulheres com mute)
Alguém possui este arquivo (e os outros que estavam neste site)? O site não existe mais e pela descrição parece que o conteúdo é bom…[/quote]Tb quero, please …
[quote=Luca]Agodinhost, seu tópico ficou excelente. Aprendi muito com ele.[/quote]Valeu!!! Eu também!!!
[quote=Luca]Quanto ao PDF, baixe do excelente blog do Mueller e aproveite para ler mais um bocado por lá e ainda visitar outros bons blogs com links lá.[/quote]Gostei!!! +1 estrelinha, foi pro favoritos.
[quote=rodrigoy]Código Coletivo.[/quote] … livrai-nos do merge (e da gerência de configuração), amém!!!
[quote=rodrigoy](não vai existir maneira prescritiva de limitar esse risco. DESENVOLVIMENTO DE SOFTWARE = ATIVIDADE SOCIAL INTENSA)[/quote]IMO: Desenvolvedor é, por natureza, um bicho anti-social e isso é diretamente proporcional à qualidade do código produzido. A grande maioria daqueles que tem uma atividade social intensa não precisa desenvolver software.
Discordo. Isso pra mim é mito. Desenvolvedor em si e no geral não costuma ser anti-social, até porque se o fosse, dificilmente estaria empregado. Creio que as práticas do XP ajudam muito a superar a preguiça e possessividade de alguns desenvolvedores (esse sim é o problema quando se fala de código coletivo).
[quote=BiraBoy]Creio que as práticas do XP ajudam muito a superar a preguiça e possessividade de alguns desenvolvedores (esse sim é o problema quando se fala de código coletivo).[/quote]Realmente torço pra que isso seja verdade, principalmente na parte da possessividade!!! Quando se fala em QA ou peer review a galera sempre reclama!!!
[quote=agodinhost][quote=Luca]Agodinhost, seu tópico ficou excelente. Aprendi muito com ele.[/quote]Valeu!!! Eu também!!!
[quote=Luca]Quanto ao PDF, baixe do excelente blog do Mueller e aproveite para ler mais um bocado por lá e ainda visitar outros bons blogs com links lá.[/quote]Gostei!!! +1 estrelinha, foi pro favoritos.
Houve algum problema com o wordpress e ele estava dando o link como “not found”, contudo já está funcionando normalmente
E agradeço o elogio do Luca ao meu blog
Edit: o wordpress este mostrando “not found” novamente, vou hospedar o arquivo em outro lugar e depois eu aviso
)