Na empresa... como funciona?

Tenho algumas duvidas referentes ao andamento dentro de um estágio ou emprego normal, sei que “teoricamente” seria dado a UML para você(desenvolvedor) e você desenvolveria emcima dessa especificação.

Nem teoricamente muito menos praticamente. São poucas empresas que usam diagramação como forma de comunicar requisitos ao programador, mesmo porque isso é bobagem. De fato, o que tem sido mais usado são casos de uso (e não diagramas de caso de uso, pois são coisas diferentes), user stories, casos de teste e etc. São ferramentas mais modernas e muito mais esclarecedoras.

rmendes08:

Tenho algumas duvidas referentes ao andamento dentro de um estágio ou emprego normal, sei que “teoricamente” seria dado a UML para você(desenvolvedor) e você desenvolveria emcima dessa especificação.

Nem teoricamente muito menos praticamente. São poucas empresas que usam diagramação como forma de comunicar requisitos ao programador, mesmo porque isso é bobagem. De fato, o que tem sido mais usado são casos de uso (e não diagramas de caso de uso, pois são coisas diferentes), user stories, casos de teste e etc. São ferramentas mais modernas e muito mais esclarecedoras.

Diagramação é bobagem? Bem, espero que você não inclua um MER nisso. MER é um diagrama e bem, eu acho a melhor forma de entender um sistema. A minha prática preferida e a que usamos aqui na empresa é MER + casos de tela.

Eu recebo uns requisitos feito por pessoas que entedem do negócio mas nunca escreveram requisitos na vida.

Algo do tipo “manter um cadastro de tal coisa”, mas ninguém nem imagina o que tem que ter nesse cadastro, então antes de eu começar a digitar qualquer código, eu ainda tenho um trabalho árduo de correr atrás dessas inforrmações, organizar os requisitos e completa-lo… Depois disso, eles me dão um baita “SVN” (Se vira, negão!!!), e ai eu faço do jeito que quiser, uso os diagramas que eu quiser, a documentação que eu quiser, a linguagem que eu quiser e os padrões que eu quiser.

O importante é entregar o negócio funcionando…

Sei que é totalmente diferente do que você vê na faculdade, mas é como funciona 90% das empresas…

Abraços e Boa Sorte!!!

AUser:

rmendes08:

Tenho algumas duvidas referentes ao andamento dentro de um estágio ou emprego normal, sei que “teoricamente” seria dado a UML para você(desenvolvedor) e você desenvolveria emcima dessa especificação.

Nem teoricamente muito menos praticamente. São poucas empresas que usam diagramação como forma de comunicar requisitos ao programador, mesmo porque isso é bobagem. De fato, o que tem sido mais usado são casos de uso (e não diagramas de caso de uso, pois são coisas diferentes), user stories, casos de teste e etc. São ferramentas mais modernas e muito mais esclarecedoras.

Diagramação é bobagem? Bem, espero que você não inclua um MER nisso. MER é um diagrama e bem, eu acho a melhor forma de entender um sistema. A minha prática preferida e a que usamos aqui na empresa é MER + casos de tela.

diagramas sim são bobagem para passar informação. Inclusive o MER. Aliás o MER em OO é arcaico. É como usar um computador de furos em cartão. O modelo OO é muito mais relevante , mas não necessáriamente precisa haver um diagrama. Mesmo que o haja ele não deve ser usado para passar requisitos.

Como foi dito, casos de uso, user stories, ou seja TEXTO é a melhor forma de passar pedidos e instruções. É por isso que os manuais são TEXTO e não um bando de diagramas. Os diagramas podem ser utilziados para ilustrar o texto, mas não para substituir o texto.

Ainda bem que aqui onde trabalho ficamos no 90% eheheh.

Aqui vai um pessoal conversar com o cliente, o pessoal que vai é programador/analista, sabe como trabalhar.
Levantam o que o pessoal precisa, e desenvolve os casos de uso ao lado do cliente, levantado os requisitos (nunca é 100% isso, sempre vão faltar campos).
Depois dessa etapa, é modelada a base seguindo os casos de uso.
A equipe toda senta e discute as tecnologias e padrões básico a serem usados no projeto. (Sempre pode ser alterado com o projeto em desenvolvimento).
Criamos a base, e desenvolvemos uma parte do sistema. Ai começa um pedaço de Scrum.
O Cliente, ve na base de teste como esta, e faz suas criticas, alteramos conforme a necessidade, e por ai vai. Sempre o cliente vai corrigir, as vezes deduzir que 6 meses de trabalho não são mais necessarios, por que isso não atende mais .

Tomando uma conclusão precipitada apartir do que vocês disseram acima…
A forma que é passada os requisitos e a maneira que é feita em cada projeto depende exclusivamente da empresa/projeto? Pelo que “leio” apesar de existirem padrões e formas “testadas”, muitas vezes a empresa prefere seguir sua cultura/padrão que acha que funciona, correto?

Então mais uma vez, creio que tenho que “aprender” ou pelo menos “conhecer” um pouco de cada metodologia, uses cases, MER, user stories e etc?

marcio.neto:

Olá, sou novato por aqui, e nunca trabalhei na area de programação/desenvolvimento.

Tenho algumas duvidas referentes ao andamento dentro de um estágio ou emprego normal, sei que “teoricamente” seria dado a UML para você(desenvolvedor) e você desenvolveria emcima dessa especificação.

Mas queria ter uma ideia, ou relato de quem ja passou por isso, principalmente em estágio, de como é… de como é passado, que nivel seria isso… porque não tenho conhecimento sobre isso.

Obrigado desde já, e criei o topico porque não achei nada especifico por aqui, caso alguem tenha um link, fique a vontade em compartilhar…

Att,
Márcio Neto

Só pra complementar…

Acho que vc está com aquela visão de: Analista de Negócio, Analista de Sistemas e Desenvolvedor…

Onde um analista de negócios cria o documento de requisitos, o analista de sistemas cria as documentações e diagramas, e o desenvolvedor desenvolve…

Já trabalhei assim, mas só em bolsa de pesquisa na faculdade. No mercado de trabalho real, vc é o analista de sistemas e desenvolvedor, senão mais que isso…

Existir uma pessoa para criar diagramas e outra pra desenvolve-los é algo muito demorado, um desenvolvedor vai sempre corrigir muita coisa nos diagramas e vai existir muito retrabalho, então é melhor o desenvolvedor já fazer tudo… hehehe!

William Silveira:

marcio.neto:

Tomando uma conclus? precipitada apartir do que voc? disseram acima…
A forma que ?passada os requisitos e a maneira que ?feita em cada projeto depende exclusivamente da empresa/projeto? Pelo que “leio” apesar de existirem padr?s e formas “testadas”, muitas vezes a empresa prefere seguir sua cultura/padr? que acha que funciona, correto?

Nao se iluda , na corporacao voce pode ter todas as responsabilidades como ter responsabilidades especificas o que conta e sua formacao e entendimento na area que vc se candidatou.

Concluindo… tudo vai “depender” de “n” fatores, né?

Não é bem ilusão, é que eu “ouço” muitos professores falarem dessa forma correta, analisar/projetar/desenvolver/testes, e ja sabia que nao funcionava assim, e quero ver pontos de vistas diferentes para me preparar.

E como você mesmo apontou, tambem acho que a melhor forma é o desenvolvedor tambem aderir a outras funções pois ele as vezes vai entender melhor o problema/solução do que quem fez os requisitos, e tem a questão do re-trabalho.

Valeu galera, acho que está dando para ter uma otima noção do que esperar.

sergiotaborda:

AUser:

rmendes08:

Tenho algumas duvidas referentes ao andamento dentro de um estágio ou emprego normal, sei que “teoricamente” seria dado a UML para você(desenvolvedor) e você desenvolveria emcima dessa especificação.

Nem teoricamente muito menos praticamente. São poucas empresas que usam diagramação como forma de comunicar requisitos ao programador, mesmo porque isso é bobagem. De fato, o que tem sido mais usado são casos de uso (e não diagramas de caso de uso, pois são coisas diferentes), user stories, casos de teste e etc. São ferramentas mais modernas e muito mais esclarecedoras.

Diagramação é bobagem? Bem, espero que você não inclua um MER nisso. MER é um diagrama e bem, eu acho a melhor forma de entender um sistema. A minha prática preferida e a que usamos aqui na empresa é MER + casos de tela.

diagramas sim são bobagem para passar informação. Inclusive o MER. Aliás o MER em OO é arcaico. É como usar um computador de furos em cartão. O modelo OO é muito mais relevante , mas não necessáriamente precisa haver um diagrama. Mesmo que o haja ele não deve ser usado para passar requisitos.

Como foi dito, casos de uso, user stories, ou seja TEXTO é a melhor forma de passar pedidos e instruções. É por isso que os manuais são TEXTO e não um bando de diagramas. Os diagramas podem ser utilziados para ilustrar o texto, mas não para substituir o texto.

Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.

UML, faz tempo, muito tempo que não vejo

marcio.neto:

Tomando uma conclusão precipitada apartir do que vocês disseram acima…
A forma que é passada os requisitos e a maneira que é feita em cada projeto depende exclusivamente da empresa/projeto? Pelo que “leio” apesar de existirem padrões e formas “testadas”, muitas vezes a empresa prefere seguir sua cultura/padrão que acha que funciona, correto?

Correto.

Não. Vc tem que saber se adaptar às circunstancias. Isso significa que vc deve saber com um software é feito e a construção do software não depender daquilo que lhe dizem que o sistema deve fazer. No final das contas vc acaba sempre com uma lista de coisas para fazer como essa sua lista é alimentada - casos de uso, user stories, etc… - é irrelevante.

Aqui na empresa eles simplesmente pedem como querem algo, que mude algo mas sempre em pequenas partes.

AUser:

Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.

Em sistemas OO o MER simplesmente não faz sentido.
Se vc me dissesse que usava uma uml de entidades até que vai, mas modelar o sistema pelo banco de dados… muito fora de OO.
A mesmo é claro que vc só faça aplicações orientadas a dados. Ai tudo bem. (mas essa “tecnologia” de aplicações é literalmente do seculo passado)

sergiotaborda:

AUser:

Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.

Em sistemas OO o MER simplesmente não faz sentido.
Se vc me dissesse que usava uma uml de entidades até que vai, mas modelar o sistema pelo banco de dados… muito fora de OO.
A mesmo é claro que vc só faça aplicações orientadas a dados. Ai tudo bem. (mas essa “tecnologia” de aplicações é literalmente do seculo passado)

Opa, não, eu não disse modelar o sistema pelo MER. Isso obviamente não faz sentido hoje em dia. O que eu disse é: entender funcionalidades e como as funcionalidades se relacionam. Ter uma visão geral.

AUser:

sergiotaborda:

AUser:

Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.

Em sistemas OO o MER simplesmente não faz sentido.
Se vc me dissesse que usava uma uml de entidades até que vai, mas modelar o sistema pelo banco de dados… muito fora de OO.
A mesmo é claro que vc só faça aplicações orientadas a dados. Ai tudo bem. (mas essa “tecnologia” de aplicações é literalmente do seculo passado)

Opa, não, eu não disse modelar o sistema pelo MER. Isso obviamente não faz sentido hoje em dia. O que eu disse é: entender funcionalidades e como as funcionalidades se relacionam. Ter uma visão geral.

MER tem algo a ver com DER?

Se sim…

Se os desenvolvedores precisam ter uma visão geral das funcionalidades e como elas se relacionam, e e fosse usado algum diagrama pra isso, o mais lógico e correto seria utilizar UML e não um MER, pois nem sempre (quase nunca) as tabelas do bd mapeiam 1 pra 1 com o modelo de domínio do sistema.

foxpv:

AUser:

sergiotaborda:

AUser:

Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.

Em sistemas OO o MER simplesmente não faz sentido.
Se vc me dissesse que usava uma uml de entidades até que vai, mas modelar o sistema pelo banco de dados… muito fora de OO.
A mesmo é claro que vc só faça aplicações orientadas a dados. Ai tudo bem. (mas essa “tecnologia” de aplicações é literalmente do seculo passado)

Opa, não, eu não disse modelar o sistema pelo MER. Isso obviamente não faz sentido hoje em dia. O que eu disse é: entender funcionalidades e como as funcionalidades se relacionam. Ter uma visão geral.

MER tem algo a ver com DER?

Se sim…

Se os desenvolvedores precisam ter uma visão geral das funcionalidades e como elas se relacionam, e e fosse usado algum diagrama pra isso, o mais lógico e correto seria utilizar UML e não um MER, pois nem sempre (quase nunca) as tabelas do bd mapeiam 1 pra 1 com o modelo de domínio do sistema.

MER é Modelo Entidade-Relacionamento e DER é Diagrama Entidade-Relacionamento. Ou seja, o DER é a representação gráfica do MER, e aqui tem uma confusão. O que a maioria das pesssoas chama de DER na verdade é um esquema de relações, isso porque Modelo ER e Modelo Relacional são duas coisas diferentes. Um DER na verdade deve representar conjuntos de entidades e conjuntos de relacionamentos, diferentementemente de um esquema de relações, que representa tabelas e restrições de chave estrangeira, erroneamente chamadas de relacionamentos.

rmendes08:

foxpv:

AUser:

sergiotaborda:

AUser:

Bom, eu prefiro usar o MER + casos de tela. Obviamente nos casos de tela tem as descrições dos passos corretos. Você pode achar isso uma bobagem, agora o que eu estou dizendo é que o MER sozinho realmente não atende, mas com casos de tela e uma descrição sempre me atenderam muito bem. Eu digo em usar o MER para entender conceitos e relacionamentos.

Em sistemas OO o MER simplesmente não faz sentido.
Se vc me dissesse que usava uma uml de entidades até que vai, mas modelar o sistema pelo banco de dados… muito fora de OO.
A mesmo é claro que vc só faça aplicações orientadas a dados. Ai tudo bem. (mas essa “tecnologia” de aplicações é literalmente do seculo passado)

Opa, não, eu não disse modelar o sistema pelo MER. Isso obviamente não faz sentido hoje em dia. O que eu disse é: entender funcionalidades e como as funcionalidades se relacionam. Ter uma visão geral.

MER tem algo a ver com DER?

Se sim…

Se os desenvolvedores precisam ter uma visão geral das funcionalidades e como elas se relacionam, e e fosse usado algum diagrama pra isso, o mais lógico e correto seria utilizar UML e não um MER, pois nem sempre (quase nunca) as tabelas do bd mapeiam 1 pra 1 com o modelo de domínio do sistema.

MER é Modelo Entidade-Relacionamento e DER é Diagrama Entidade-Relacionamento. Ou seja, o DER é a representação gráfica do MER, e aqui tem uma confusão. O que a maioria das pesssoas chama de DER na verdade é um esquema de relações, isso porque Modelo ER e Modelo Relacional são duas coisas diferentes. Um DER na verdade deve representar conjuntos de entidades e conjuntos de relacionamentos, diferentementemente de um esquema de relações, que representa tabelas e restrições de chave estrangeira, erroneamente chamadas de relacionamentos.

Hum, boa explicação

De qualquer maneira, continuo com minha opnião.

Estudei numa universidade onde a maioria absoluta nunca sujou os dedos num teclado de cubículo de consultoria. E ainda assim, dão pitacos sobre como seria a construção de software no mundo real.

Bom, muitos professores são inteligentíssimos, mas como eles não tem muito contato com o mercado, é bom ouvir desconfiado.

nao trabalho mais em empresas onde UML ou MER é tecnologia alienigena

Leonardo3001:

Estudei numa universidade onde a maioria absoluta nunca sujou os dedos num teclado de cubículo de consultoria. E ainda assim, dão pitacos sobre como seria a construção de software no mundo real.

Bom, muitos professores são inteligentíssimos, mas como eles não tem muito contato com o mercado, é bom ouvir desconfiado.

“Quem sabe faz. Quem não sabe ensina.”

Esta máxima é verdadeira. Considerar que a opinião dos professores é remotamente semelhante à realidade é ingenuidade. Ingenuidade própria de quem é estuande e de certa forma desculpável, mas ingenuidade .

Caramba eu sei que não tem muito a ver com os tópicos porém, lá vai…
Vendo vcs falando sobre diagramas tanto MER quanto UML, me lembrei de um fato que um Professor de Engenharia de Software falou: -Vc pode saber programar muito bem, mas se não souber UML, vc não tem emprego, já o contrário vc pode conseguir algo…0_o, não acreditei nisso,tanto que estudo muito + programação, não que não estude UML, porém com uma dedicação(de tempo) menor.

sergiotaborda:

Leonardo3001:

Estudei numa universidade onde a maioria absoluta nunca sujou os dedos num teclado de cubículo de consultoria. E ainda assim, dão pitacos sobre como seria a construção de software no mundo real.

Bom, muitos professores são inteligentíssimos, mas como eles não tem muito contato com o mercado, é bom ouvir desconfiado.

“Quem sabe faz. Quem não sabe ensina.”

Esta máxima é verdadeira. Considerar que a opinião dos professores é remotamente semelhante à realidade é ingenuidade. Ingenuidade própria de quem é estuande e de certa forma desculpável, mas ingenuidade .

Quando vc se refere a essa frase, você se refere a empresas como a CAELUM e a GlobalCode? Focas na instrução de profissionais.

Isso é completo preconceito, e ideologia de terceiro mundo.
Não estou defendendo o sistema de ensino brasileiro, que possui diversos profissionais defesados, mas essa afimação do sergio é generalizadora, e isso não é verdade.

A diferença é que a globalcode e a caelum não só ensinam como fazem também, tanto é que eles possuem seus próprios frameworks open-source, possuem consultoria e geralmente os professores já são pessoas experientes.

Não é que nem na grande maioria das universidades onde professores são formandos que fizeram uma pós/mestrado e foram dar aula de algo que nunca trabalharam na vida, ensinando exatamente como as coisas estão nos livros, de contos de fadas onde basta dar next, next e finish e o teu sistema está pronto.

Honestamente, até acredito que a frase do sergio foi um pouco preconceituosa, mas ela faz total sentido, não se aplica a todos mas tem um fundo de verdade. Sad but true.

Primeiro tenho que esclarecer que embora eu seja Português e tenha sido nascido e criado lá, eu moro no Brasil e atuo profissionalmente com desenvolvimento de Software no Brasil.

A frase é uma máxima ( o termo “máxima” já significa que é exagerado para dar efeito) , mas eu sempre achei verdadeira.
Não pode extrapolar das minhas palavras que empresas (veja bem,empresas) que têm instrutores de ensino estão inclusas.
A frase não diz nada sobre quem faz e ensina.

tem outra frase semelhante que se aplica nesse caso

“Alguns Fazem. Alguns ensinam. O resto procura nos livros”

Aqui os que fazem e os que ensinam não são grupos excludentes.

O ponto é que acreditar nas pessoas que lhe dizem “isto é sempre assim” sem elas terem feito é ingenuidade.

Para mim “Professor” é uma profissão. Que é diferente de “Instrutor”. Instrutor é instrutor enquanto instrui, lá fora ele é outra coisa.
Professor é sempre professor.

sergiotaborda:

William Silveira:

Agora os problemas do Brasil sao muito mais complexos que os Problemas em Portugal, entretanto eu gostaria que um dia a Caelum ou a GlobalCode convida-se o Sergio Taborda pra palestrar um assunto no Brasil, de preferencia sobre Design Patterns, Agil/XP, com certeza eu iria.

Primeiro tenho que esclarecer que embora eu seja Português e tenha sido nascido e criado lá, eu moro no Brasil e atuo profissionalmente com desenvolvimento de Software no Brasil.

A frase é uma máxima ( o termo “máxima” já significa que é exagerado para dar efeito) , mas eu sempre achei verdadeira.
Não pode extrapolar das minhas palavras que empresas (veja bem,empresas) que têm instrutores de ensino estão inclusas.
A frase não diz nada sobre quem faz e ensina.

tem outra frase semelhante que se aplica nesse caso

“Alguns Fazem. Alguns ensinam. O resto procura nos livros”

Aqui os que fazem e os que ensinam não são grupos excludentes.

O ponto é que acreditar nas pessoas que lhe dizem “isto é sempre assim” sem elas terem feito é ingenuidade.

Para mim “Professor” é uma profissão. Que é diferente de “Instrutor”. Instrutor é instrutor enquanto instrui, lá fora ele é outra coisa.
Professor é sempre professor.

Bom, eu concordo com o Sérgio.

Já tinha ouvido essa frase, mas no meio musical. Era algo tipo: “Quem sabe, faz. Quem não sabe, ensina. E quem nem isso consegue, vira crítico musical.”

E eu concordo plenamente. Professor fica estagnado, não se atualiza, não vive o mercado. A sua profissão já não é mais de desenvolvedor e sim de Professor, seu ofício é lecionar e é nisso que normalmente eles se focam. Infelizmente, muitos se esquecem que não adianta ensinar bem se ensinar o que já não é mais utilizado…

É uma pena, estou terminando minha faculdade e posso dizer que aprendi muito pouco com os professores. Eles abriram alguns caminhos, mas eu que tive que ir atrás sozinho.

Universidade, pra mim, é muito mais o “networking” e as pesquisas do que o ensino em si.

Abraços!

kired:

sergiotaborda:

William Silveira:

Agora os problemas do Brasil sao muito mais complexos que os Problemas em Portugal, entretanto eu gostaria que um dia a Caelum ou a GlobalCode convida-se o Sergio Taborda pra palestrar um assunto no Brasil, de preferencia sobre Design Patterns, Agil/XP, com certeza eu iria.

Primeiro tenho que esclarecer que embora eu seja Português e tenha sido nascido e criado lá, eu moro no Brasil e atuo profissionalmente com desenvolvimento de Software no Brasil.

A frase é uma máxima ( o termo “máxima” já significa que é exagerado para dar efeito) , mas eu sempre achei verdadeira.
Não pode extrapolar das minhas palavras que empresas (veja bem,empresas) que têm instrutores de ensino estão inclusas.
A frase não diz nada sobre quem faz e ensina.

tem outra frase semelhante que se aplica nesse caso

“Alguns Fazem. Alguns ensinam. O resto procura nos livros”

Aqui os que fazem e os que ensinam não são grupos excludentes.

O ponto é que acreditar nas pessoas que lhe dizem “isto é sempre assim” sem elas terem feito é ingenuidade.

Para mim “Professor” é uma profissão. Que é diferente de “Instrutor”. Instrutor é instrutor enquanto instrui, lá fora ele é outra coisa.
Professor é sempre professor.

Bom, eu concordo com o Sérgio.

Já tinha ouvido essa frase, mas no meio musical. Era algo tipo: “Quem sabe, faz. Quem não sabe, ensina. E quem nem isso consegue, vira crítico musical.”

E eu concordo plenamente. Professor fica estagnado, não se atualiza, não vive o mercado. A sua profissão já não é mais de desenvolvedor e sim de Professor, seu ofício é lecionar e é nisso que normalmente eles se focam. Infelizmente, muitos se esquecem que não adianta ensinar bem se ensinar o que já não é mais utilizado…

É uma pena, estou terminando minha faculdade e posso dizer que aprendi muito pouco com os professores. Eles abriram alguns caminhos, mas eu que tive que ir atrás sozinho.

Universidade, pra mim, é muito mais o “networking” e as pesquisas do que o ensino em si.

Abraços!

Concordo.

Faculdade para mim é um mal necessário.

Aprende-se muito pouco, perde-se muito tempo, e caso não seja pública, dinheiro também.

O ruim é que o mercado realmente exige diploma em muitos casos, então é preciso ter um.

(MINHA opinião)

Abraço

Repete-se muito isso, mas eu aprendi bastante na faculdade. E na minha pós também.
Agora, não adianta o professor falar, se o aluno não quer aprender. E o problema, está dos dois lados.

Muitos alunos adotam a postura arrogante de “não vou estudar porque essa matéria não serve para mim”.
“Para que devo estudar estrutura de dados se hoje as linguagens já tem isso tudo pronto?”

Existe muita pesquisa e desenvolvimento em faculdades. Muito conteúdo para aprender, e muitos professores que são também instrutores.
Basta procurar.

Bom isso é verdade, é um problema de postura dos dois lados.

Acho que tenho este pensamento por frustração com professores ruins.

Mas só acho que se poderia aprender muito mais na faculdade pelo tempo que se passa nela.

Não vou negar, também tive esse tipo de frustração. Uma das minhas professoras simplesmente nunca tinha estudado a matéria. Mas toda faculdade também forma alunos excelentes, com altíssimo conhecimento técnico e que, claro, em boa parte foram auto-didatas.

Acho que o segredo está em juntar a empolgação e o auto-didatismo com a experiência de muitos professores. Ao mesmo tempo que temos gente muito ruim, também existem profissionais excelentes, com um conhecimento técnico muito mais aprofundado até mesmo do que vemos na média da indústria.

Não vou negar, também tive esse tipo de frustração. Uma das minhas professoras simplesmente nunca tinha estudado a matéria. Mas toda faculdade também forma alunos excelentes, com altíssimo conhecimento técnico e que, claro, em boa parte foram auto-didatas.

Acho que o segredo está em juntar a empolgação e o auto-didatismo com a experiência de muitos professores. Ao mesmo tempo que temos gente muito ruim, também existem profissionais excelentes, com um conhecimento técnico muito mais aprofundado até mesmo do que vemos na média da indústria.

Eu concordo com isso, mas concordo mais ainda com o que o Frango disse: Faculdade é bom, mas não vale a pena pelo tempo que se perde.

Só pra esclarecer.

Eu não estou dizendo que os professores são ruins, apenas que os professores não sabem o que é o mundo real. É uma coisa diferente.

Acho que muitos conceitos que aprendi na universidade foram importantes para mim. Mas são apenas isso, conceitos, porque a parte “aplicada” só fui conhecer mesmo quando estava no mercado de trabalho.

Concordo plenamente. Cada pessoa tem a forma de comunicação preferida. Alguns compreendem melhor o fluxo do processo em um diagrama, outros em um texto, outros só conversando com alguém. Quantos de vocês já aconteceu de um usuário ligar dizendo que o sistema dava erro e imprimia a mensagem X. Daí quando você repete a mensagem X pra ele, ele entende?

Recomenda-se texto porque a maioria das pessoas preferem texto, mas como não existe uma regra que valha pra todos, tem que ver o que na sua equipe é melhor.

Mas não seria esse o objetivo da faculdade? Para a parte aplicada, existem os programas de estágio, em alguns casos, o projeto final.

Mas não seria esse o objetivo da faculdade? Para a parte aplicada, existem os programas de estágio, em alguns casos, o projeto final.

Talvez seja esse o objetivo. Mas o fato é que muitos cursos prometem o famoso “preparado para o mercado”, e é aí que mora o problema. Muitos dos professores não tem essa vivência de mercado, nem nunca encarou projetos grandes, onde poderia apreender práticas de desenvolvimento de software. Ficando no mundo acadêmico, qualquer metodologia funciona (até mesmo cascata), bastando ter “provas formais”.

Assim, não acho que o objetivo de uma universidade seja tornar o aluno “preparado”. Ao contrário, o aluno precisa aprender teoria, ser auto-didata, e ter pensamento crítico. Porém, seria interessante se os cursos universitários favorecessem o trabalho em equipe, o desenvovimento (e aprendizado) iterativo e incremental, e uma cultura pela qualidade de software.

Eu concordo.

Algumas coisas são complicadas em equipes de faculdade:

a) A equipe dificilmente consegue cobrar do aluno que não produz;

b) O trabalho abandonado depois de entregue (ninguém dará manutenção no software);

c) Não existem membros mais experientes.

A faculdade prepara melhor para o trabalho em centros de pesquisa, na área acadêmica. É um tipo de mercado pouco explorado no Brasil, mas bastante grande. Pelo menos uma vez por mês vejo alguma empresa procurando profissionais e com dificuldades para achar nessa área.

ViniGodoy:

Eu concordo.

Algumas coisas são complicadas em equipes de faculdade:

a) A equipe dificilmente consegue cobrar do aluno que não produz;

b) O trabalho abandonado depois de entregue (ninguém dará manutenção no software);

c) Não existem membros mais experientes.

A faculdade prepara melhor para o trabalho em centros de pesquisa, na área acadêmica. É um tipo de mercado pouco explorado no Brasil, mas bastante grande. Pelo menos uma vez por mês vejo alguma empresa procurando profissionais e com dificuldades para achar nessa área.

Acho que o maior mérito da faculdade é a base teórica e em ensinar o aluno a aprender sozinho. Pelo menos por aqui, as pessoas com curso superior tem muito mais iniciativa de se virar e correr atrás de uma solução ótima para um problema do que uma pessoa sem formação. E também tem maior velocidade em se adequar a uma nova tecnologia.

Mas é claro que existem exceções das duas partes, já que nada impede ninguém em adquirir certas habilidades sozinho. Só que pra muitas empresas, não dá pra avaliar se cada um dos candidatos tem realmente as habilidades necessárias, então elas tendem à amostra mais homogênea: a de quem tem curso superior. Se quem não tem não tiver uma recomendação ou uma oportunidade de mostrar seu trabalho, infelizmente fica de fora.