Arquivo Discussoes de Programacao e Tecnologia 
Olá
Segundo Joel Spolsky, o objetivo real de companhias desenvolvedoras de software deve ser converter capital em software que funciona e isto pode ser resumido pela seguinte trilha:
As melhores condições de trabalho --> os melhores programadores --> o melhor software --> lucro
Vale a pena dar uma olhada no último artigo do Joel Spolsky em http://www.joelonsoftware.com/articles/HighNotes.html
Ver também: http://jroller.com/page/cpurdy?entry=joel_s_semi_annual_post
[]s
Luca
E complementando este artigo: Software Team Turnover: Why Developers Leave (And What You Can Do About It)
E então, você contrataria 5 programadores médios ou 1 programador bom?
É o papel do analista?? Será que 1 analista bom e 5 programadores mediocres não resolveria o caso??
Eu acho que focar na analise deixa o trabalho mais interessante ao passo que os programadores precisam apenas ler um documento e fazer :).
Uma vez fui numa palestra de um individuo conceituado e ele disse:
Nessa sala com 50 pessoas se voce for focar na programação voce pode pegar as 45 dessas pessoas como programadores e os 5 como analise. Se voce for focar na analise voce pode pegar 15 dessas pessoas como analistas 5 como programadores e mandar o restante embora. 
Ai eu me perguntei … do que adiante ser O PROGRAMADOR se por traz não tem um grande analista. Programadores no meu modo de ver estão se tornando figuras mecanicas que de posse de um grande documento de analise não precisa de mais nada alem de fazer!
Quem sou eu para dizer alguma coisa mas reformulanda a ideia do grandioso resulmidamente seria:
Melhores condiçoes de trabalho (foco nas pessoas não na tarefa) — melhores analistas ---- melhor software (qualidade, menor custo) ----- mais lucro.
Olá
Trunk, este ambiente onde o analista só faz análise e o programador apenas codifica está acabando. Hoje o analista programa e o programador que só codifica é o estagiário.
A questão se é melhor contratar mais gente barata do que um caro é abordada em seu blog pelo Cameron Purdy (JCache spec lead, founder of Tangosol).
[]s
Luca
Isso é ilusão.
Analistas como pregados na faculdade não existem. Esse papo de entregar tudo pronto pro programadornunca foi verdade.
No papel tudo funciona. Olhando um documento de requisito de uma página ou mais, o cliente acha que está tudo bem. Quando se percebe que a implementação não pode ser feita como o “analista” ou o “arquiteto” ou o “projetista” especificou, quando o cliente v~e depois de meses que o sistema não faz o que ele quer, aí sim você entra no mundo real.
Esse carinha da palestra ou não conhece o mercado ou quis passar uma visão romântica e obsoleta.
Separar analistas de programadores é , para mim, um erro. Acredito em desenvolvedores, com mais ou menos experiência.
Um grande analista que não programa é como um grande cirurgião que não faz cirurgia. Alguém conhece algum ? Alguém se submeteria a uma cirurgia definida por um grande cirurgião e realizada por “programadores” ?
Márcio
Posso falar por mim: eu sempre sou chamado pra resolver problemas provocados por essa abordagem de contratar um monte de gente barata, com pouca experiência.
No penúltimo projeto em que trabalhei o problema era o seguinte: a empresa que me contratou havia iniciado o projeto com uma equipe de 3 programadores júniores e 2 programadores plenos.
O projeto, que era pra durar 4 meses, já estava 3 meses atrasado. E quando eu assumi, juntamente com mais um analista sênior. Jogamos praticamente tudo fora e fizemos em 3 meses. Ou seja, o projeto acabou demorando 10 meses pra sair por conta de um estratégia inicial errada.
No meu projeto atual, iniciamos do zero, e entregamos a primeira fase no prazo e com qualidade.
Como o Luca disse, o papel do “analista” e do “programador” está sumindo. Atualmente, o cara tem que fazer as duas coisas.
Creio que, quando falamos em melhores programadores, estamos nos referindo a pessoas capazes de recolher uma série de informações e abstrair esse conjunto, transformando-o em software funcional. Pra isso, minha opinião é que não basta ser analista e não basta ser programador. E é isso que as empresas estão procurando agora, creio.
[]´s
Na boa, quantos professores de universidade vocês conhecem trabalham “na rua”?
Eu só conheço 3 por aqui.
Separar analistas de programadores é , para mim, um erro. Acredito em desenvolvedores, com mais ou menos experiência.Um grande analista que não programa é como um grande cirurgião que não faz cirurgia. Alguém conhece algum ? Alguém se submeteria a uma cirurgia definida por um grande cirurgião e realizada por “programadores” ?
Márcio
Lindo!!! Concordo plenamente… e Tipo quanto ao estagiario codifica (eu) é uma meia verdade, prq o analista sempre ajuda, se ele não programar que ajuda os estagiarios??
Fala galera,
Programo desde 90, quando comecei com clipper,é já pude desenvolver diversos sistemas em diferentes áreas de atuação, o que me deu um grande flexibilidade no tocante a analise/programação.
Acredito que um programador, por melhor que seja, se não conseguir entender o negócio do cliente não vai desenvolver um bom projeto, falo por experiência, pois já errei muito. Você acaba deixando o sistema funcional, rápido, tecnologicamente avançado, mas o danado não faz o que realmente o cliente queria.
Esse é um erro cometido por uma grande parte de programadores que já conheci, pois apesar de manjarem muito da linguagem, não conseguiam entender o que o cliente queria.
Conselho: se vc já é um programador médio, tente virar um analista médio, pois se tornar um ótimo programador sem sacar de analise não da muito resultado. 
[]s
Na boa, quantos professores de universidade vocês conhecem trabalham “na rua”?Eu só conheço 3 por aqui.
\0/ Falou é disse!!!
Bom galera, o cara do artigo falou numa forma, que ele mesmo não sabe se funciona, de “ganhar dinheiro”. :lol:
Quem sou eu para tentar dar uma solução dessa, mas eu não culpo a oposição afinal de contas isso que eu falei não é para todos! Se fosse para todos seguir essa forma não existiria programadores pobres.
Existe um ISO que é dado a empresas de qualidade. Na epoca que estava atualizado com os dados tinha nada mais nada menos que 3 empresas na america latina que detinha um nivel de qualidade 5 (ultimo) - Tinha alguma relação com PMI. Por incrivel que pareça essas empresas seguem a linha de raciocinio que eu falei. Agora não intendi onde voces querem chegar porque até agora eu so vi falar de programadores e linha de codigo sendo que a parte mais essencial de um projeto é o seu projeto :).
Eu sei que doi, mas o projeto determina uma infinidade de coisas.
Determina se o projeto esta dentro do orçamento, se o projeto tem qualidade, se o projeto vai ser entregue a tempo, se o projeto está gastando os recursos esperados, etc… etc… ESSE É O DIFERENCIAL. Programar até meu sobrinho de 12 anos programa.
Eu sou analista, trabalho na area a algum tempo e por mais que o cara saiba de programação ele nunca sai com nada. Eu mesmo ja tentei fazer um programa assim do nada, o programa apresenta muito mais erros, o programador se perde completamente na hora de fazer manutenção, o programador leva muito muito mais tempo para entregar, e se algum dia outro alguem for mecher é preferível começar do zero. E incrivel como os programadores tem preguiça de ir no cliente e falar com ele.
Enquanto a essa ideia ser ultrapassada, acho que não afinal de contas o curso de sistema de informação esta nem a dois anos formando alunos em algumas faculdades do brasil.
Gente isso é obvio demais ??? Os filosofos ja definem isso a muitos anos atras. É o que eles chamam de Etica Profissional!!! Um profissional deve exercer bem sua profissão de forma a contribuir para a sociedade MAS nunca deve deixar de transitar pelas outras areas do conhecimento.
Um ultimo argumento definido por um outro grande amigo. Programar por mais que o cara saiba tem um limite. O seu limite é o limite que os cientistas que modelaram a linguagem tem, ou seja, os programadores são limitados. Os analistas não, eles lidam com pessoas, definem diferentes problemas e seu limite esta sendo superado a cada dia que passa. Para conferir isso é so olhar a faixa salarial dos profissionais de analise e de desenvolvimento.
So para constar… Um dos melhores profissionais da area que eu conheço e que hoje trabalha na borland ja cansou de me afirmar que o brasil tem serios problemas nessa area. Em uma de suas palestras ele me revelou um dado interessante. As empresas de desenvolvimento do brasil, as de melhor qualidade chegam a ficar no maximo no nivel 3. Existem empresas que fazem um software lindo e maravilhoso mas na hora de passar o preço vão pelo impulso. Alguns até utilizam linhas de programação como base na hora de dar o preço. UhuAuhAUh Do que adianta???
Cansei … numa proxima oportunidade eu escrevo mais … Desculpa pelo portugues eu penso mais rapido que escrevo ai erro muito…
Minha experiência:
Recebi de um analista um documento de Word (que o analista chamou de pré-análise) que continha um desenhinho de uma tela e uma especificação viajante do que deveria ser feito. Prazo estimado pelo analista: 1 semana.
Falei para ele que pela especificação eu levaria 2 meses para fazer aquilo.
(…)
O cliente me chamou para uma reunião. Compreendendo a verdadeira necessidade do cliente e retirando toda a perfumaria e deixando outras coisas de lado, especifiquei o que eu serei uma proposta factível e cheguei a conclusão que poderia fazer o requerimento em duas semanas (levei um dia para fazer este levantamento).
20:00 horas da noite recebo um telefonema do meu chefe falando que eu precisava ler meu email… O cliente tinha falado (por email) com o gerente fabril sobre a solicitação que levou 2 semanas do nosso analista e que ele havia garantido que em 1 semana o projeto estaria em fase de aceitação; que eu revisei os documentos de pré-análise e conclui que seria preciso 2 semanas e que isto era inaceitável! etc, etc…
Conclusão: Fiz o projeto em uma semana … das 9:00 às 21:00 todos os dias e … louco para quebrar a cara daquele analista que não fez droga de especificação que prestasse.
Ao invés do cara desenhar uma solução para o problema (coisa que ele não tinha a menor idéia do que estava dizendo) por que simplesmente ele não escreveu a necessidade do ciente ???
Em resumo, isto foi uma grande cirurgia definida por um cara que nunca fez uma.
Bom galera, o cara do artigo falou numa forma, que ele mesmo não sabe se funciona, de “ganhar dinheiro”. :lol:Existe um ISO que é dado a empresas de qualidade. Na epoca que estava atualizado com os dados tinha nada mais nada menos que 3 empresas na america latina que detinha um nivel de qualidade 5 (ultimo) - Tinha alguma relação com PMI. Por incrivel que pareça essas empresas seguem a linha de raciocinio que eu falei. Agora não intendi onde voces querem chegar porque até agora eu so vi falar de programadores e linha de codigo sendo que a parte mais essencial de um projeto é o seu projeto :).
Você está fora e muito fora de sintonia …
O cara do artigo é o Joel Spolsky, dono de uma empresa onde ele aplica esse conceito como está escrito no artigo (que você não deve ter lido ou entendido direito) e também está escrito que com esse modelo ele conseguiu ser rentável desde o início.
Outro ponto que você não pescou nos artigos é que não é qualquer programador, são os bons que merecem toda essa atenção e valem esse esforço. É por isso que existem programadores pobres, porque a grande maioria (também está nos artigos, leia de novo) é mediano pra baixo.
A ISO com nível 5 na verdade chama-se CMM (Capability Maturity Model) e não tem nada a ver com a ISO … é aplicável apenas em fábricas de software e afins que por definição atraem os programadores medianos que não são muito chegados em pensar e os analistas que não sabem programar. (claro que estou generalizando, mas esse modelo é um pé)
Não se engane, há várias empresas que tem esse pensamento (do artigo) e estão muito bem, obrigado!
Gente do Céu!! Ha analistas e ha analistas, ha programadores e ha programadores. O que vocês não podem e querer comparar gato com lebre. Eu acabei de mencionar que isso não e para qualquer quer um senão todo mundo estaria rico … sera que tem alguma dificulade nisso?
Se for assim … Fizemos um analise completissima demos para para o gerente da equipe de desenvolvimento. O gerente por sua vez dividiu a tarefa entre seu programadores. Dos 12 programadores apenas 2 conseguiram ler o documento e resolver o problema é os demais??? Eu vi um deles jogando futebol no campinho junto com seus amigos UAHuAUhA.
Outro caso … Fizemos uma analise e passamos para a equipe de desenvolvimento … os caras pegaram a analise e quiseram infeitar, acharam que o jeito deles era o correto. Resultado … o cliente reclamou porque o que eles não fizeram o que o cliente queria, reclamos porque tivemos de pagar a mais pq o cara quiz fazer a mais, o projeto foi entregue atrasado porque os cara falam que nao dava tempo!!!
Historias e mais historias!!
analista é um programador frustrado. :mrgreen: :mrgreen:
Você está confundindo análise e projeto de software.
Um analista de negócios é muito importante, alguém com muito conhecimento do domínio, tanto que metodologias ágeis extrapolam e mandam você colocar o cliente na sua equipe (quem melhor que ele?).
Ética profissional não é isso.
E se alguém acha que projeto de software e programação são coisas diferentes…deve ler e programar mais.
O programador está limitado pela linguagem. O que seu analista usa, UML? Sabia que ela é uma linguagem limitada?
Desenvovler software é resolver problemas. Um analsita se preocupa com processos, técnicos se preocupam com a implementação de processos em sistemas computacionais.
Nível 3 de que, CMM?
E desde quando isso define a qualidade (ah, esquece, CMM de novo não!)?
Realmente LoC não é boa métrica para nada, o que você sugere?
Programadores são limitados e os analistas não ??? Não te conheço, mas se vir alguém voando pelo céu com uma capa vermelha, concluo que pode ser o super-homem ou um analista !
Posso te dizer que sou um ótimo desenvolvedor com vinte e dois anos de estrada ( aprendi perfurando cartões ) e a cada dia meus limites ficam mais claros. E esta conciência contribui para o sucesso dos projetos nos quais participo.
Paz a todos,
Márcio
Olá
Trunk
O que você está dizendo me soa muito antigo. Parece ambiente de empresa pública ou no mínimo de economia mista com programador que programa e analista que analisa. Isto faz tempo que não vejo.
Quando eu falei estagiário que só programa quiz me referir a alguns estagiários porque conheço outros que vão ao cliente, analisam, modelam banco de dados, dialogam com a diretoria e outras coisas mais.
Que adianta a gente contratar um cara formado em uma universidade que aprendeu tudo o que disse acima para deixar o cara só codificando?
Me dá a impressão que a sua empresa agiu como citado no blog do Cameron Purdy onda a tal empresa preferiu quantidade a qualidade.
Em tempo: cuidado ao elogiar muito CMM aqui porque tem muita gente como eu que acredita em meios mais fáceis de atender requisitos de qualidade de serviços desenvolvendo software. Veja os links abaixo para contrapor com seu elogio ao CMM:
http://www.xp-rs.org/3oEncontro.htm
http://www.xp-rs.org/arquivos/3o_Encontro_XP-RS-16_10_2004.ppt
http://www.informit.com/articles/printerfriendly.asp?p=26057
[]s
Luca
Trunk, a quanto tempo você está na sua empresa atual?
Qual a área de atuação da sua empresa? (se disser que trabalha com o Richard tá tudo explicado)
(perguntas para desenvolver uma teoria sobre porque você tem essa posição tão simplista e distorcida do mundo do desenvolvimento)
A dificuldade que eu estou tendo é em entender porque cargas d’água você supõe que:
Rapaz, no dia que programar for mecânico, as ferramentas de UML vão gerar o programa, o programador não vai mais existir. Mas isso parece meio longe de acontecer… :lol:
Quem sou eu para dizer alguma coisa mas reformulanda a ideia do grandioso resulmidamente seria:Melhores condiçoes de trabalho (foco nas pessoas não na tarefa) — melhores analistas ---- melhor software (qualidade, menor custo) ----- mais lucro.
O analista que não consegue (ou não quer, por se sentir “superior”) se comunicar com a equipe de desenvolvimento já deu o primeiro vacilo. A análize deveria congregar todos os envolvidos se possível até o cliente. Melhor ainda, todos deveriam ter contato com tudo o tempo todo, a análize não deveria acontecer apenas uma vez, ela deveria ser diária.
A parte mais importante de um projeto de software é aquela que resolve o problema do cliente, o resto é penduricalho de árvore de natal 8)
Se o projeto conseguisse definir tudo isso, até a Microsoft fazia software de qualidade, barato e sem bug. Você acha que é melhor que os caras que trabalham lá? Tenta fazer uma entrevista.
Pergunta ao teu sobrinho de 12 anos se ele sabe utilizar uma ferramenta de indexação como o Lucene (é só utilizar, não precisa fazer uma não.
Assim, nunca ouvi falar que “começar do nada” funcionasse, mas pode ser que funcione né. Em XP o pessoal fala em “começar com o mínimo necessário”. Se só você não conseguiu fazer, se perdeu, deixou o programa cheio de erros e não conseguia fazer a manutenção, é porque você não sabe fazer, simples assim.
Programar tem um limite? Rapaz, acho que você realmente não é programador, o pessoal que faz a biblioteca GTK conseguiu fazer C ficar “meio” orientado a objetos, C é orientado a objetos? Os criadores do C imaginavam a orientação a objetos?
Você realmente precisa ler mais e programar mais.
Minha experiência:Recebi de um analista um documento de Word (que o analista chamou de pré-análise) que continha um desenhinho de uma tela e uma especificação viajante do que deveria ser feito. Prazo estimado pelo analista: 1 semana.
Falei para ele que pela especificação eu levaria 2 meses para fazer aquilo.(…)
O cliente me chamou para uma reunião. Compreendendo a verdadeira necessidade do cliente e retirando toda a perfumaria e deixando outras coisas de lado, especifiquei o que eu serei uma proposta factível e cheguei a conclusão que poderia fazer o requerimento em duas semanas (levei um dia para fazer este levantamento).
20:00 horas da noite recebo um telefonema do meu chefe falando que eu precisava ler meu email… O cliente tinha falado (por email) com o gerente fabril sobre a solicitação que levou 2 semanas do nosso analista e que ele havia garantido que em 1 semana o projeto estaria em fase de aceitação; que eu revisei os documentos de pré-análise e conclui que seria preciso 2 semanas e que isto era inaceitável! etc, etc…
Conclusão: Fiz o projeto em uma semana … das 9:00 às 21:00 todos os dias e … louco para quebrar a cara daquele analista que não fez droga de especificação que prestasse.
Ao invés do cara desenhar uma solução para o problema (coisa que ele não tinha a menor idéia do que estava dizendo) por que simplesmente ele não escreveu a necessidade do ciente ???
Em resumo, isto foi uma grande cirurgia definida por um cara que nunca fez uma.
Ficar “brigado” com o analista não resolve o seu problema, vocês deveriam sentar e conversar sobre o que deve ou não ser feito. Esse tipo de atitude só vai piorar o relacionamento, o seu trabalho, o trabalho dele e o resultado final.
Isso não é concorrência, estamos todos tentando fazer software de qualidade!
Ficar “brigado” com o analista não resolve o seu problema, vocês deveriam sentar e conversar sobre o que deve ou não ser feito. Esse tipo de atitude só vai piorar o relacionamento, o seu trabalho, o trabalho dele e o resultado final.Isso não é concorrência, estamos todos tentando fazer software de qualidade!
Sim!!! Este é um ponto chave … acho que alguém da área técnica (com bons conhecimentos) deve participar da DEFINIÇÃO da solução!!! Ele deve ser envolvido no começo do processo e não no final (construção em diante).
Quantas vezes um arquiteto (ou desenvolvedor mais experiente) você já viu ser envolvido no começo do processo ?
Quantas vezes um arquiteto (ou desenvolvedor mais experiente) você já viu ser envolvido no começo do processo ?
Se ele não tá querendo se envolver durante todo o projeto, XP nele:
http://en.wikipedia.org/wiki/Extreme_Programming
Se mesmo assim ele não quer cooperar, o ego dele é grande demais pra trabalhar em grupo, é melhor ele ir virar ermitão numa montanha do Himalaia :mrgreen:
Quando ouço o título “Analista de Sistemas” a primeira coisa que me vem à cabeça é um cara de óculos de aros grossos, camisa branca e gravata preta, sentado à frente de um terminal IBM 3270 com tela de fósforo verde numa sala ultra-iluminada e gelada, numa empresa com organização taylorista da década de 1970.
O que é, afinal, um “Analista de Sistemas”?
O que é, afinal, um “Analista de Sistemas”?
- Muito bem, Sistema, deite-se ali no divã e conte-me todos os seu bugs…
Essa foi d+ :lol:
Balela,
Excelentes programadores sempre serão necessários. E excelentes analistas também.
Se fosse assim era só mandar o Zé fazer um curso técnico que tudo estaria resolvido.
Wander
Olá
Você leu os artigos que justamente dizem que muitas empresas preferem não pagar muito por um cara excelente? A maioria das empresas que trabalhei é assim e acabam se ferrando.
E viu como este tópico mudou de rumo quando o trunk disse que analista só analisa e programador só programa? Eu, como desenvolvo sistemas desde 1969, acho que isto não existe mais. Com os programadores vindo de cursos superiores com boa base, não vejo ninguém mais contratando programador só para escrever código.
Qual tema achou balela?
[]s
Luca
Imagina só:gastar 10-20 horas para fazer um programa de milhares de linhas, apenas adaptando templates de outros programas/projetos já feitos e cobrar como se tivesse demorado 160, ainda inventar a necessidade de gasto extra com suporte e etc.E, por outro lado, demorar
200 horas em um algoritmo de criptografia(Tah, não é beem assim mas “façamos de conta”) mas q no final após árduo estudo/refactoring ficou com menos de 1000 linhas e se obrigado a cobrar um preço de 10?
:roll:
CMM é apenas mais uma sigla para onerar o tempo de quem projeta software e “adubar” o curriculum e o salário.É como EJB.A diferença é que EJB´s tem 1% comprovado de utilidade… :twisted:
Acho engraçado essa discussão…o que é um bom programador/analista?
Para mim é o que consegue entregar o que o cliente pediu…(ou o que consegue convencer ao cliente que o que ele fez é o que ele-o cliente- pediu.Mesmo não sendo!)
Pô, na minha CLT está escrito “Analista Programador”. E agora, o quê eu sou? 
Humm… entaum há quem defenda que programador deve programar e analista deve projetar…
legal…
O analista vai lá, faz um projeto perfeito, e ai, o programador meia boca implementa um pedaço de código, e sai dando control C e control V pra tudo quanto é lado!
Acho que este é um bom motivo para que uma empresa contrate um bom programador, e nao vários programadores medianos! Digo por exepriência própria. Num tenho nem um ano e meio de experiência em desenvolvimento e já enjoei de corrigir bugs intermináveis por causa desses copias e colas!
Acho que tem profissional pra tudo quanto é gosto. Tem tanto programador ruim tão bém empregado. Vão lá, falam de OO super bém e blá blá blá, mas na hora H, é só anti boas práticas! Um desastre!
Quanto aos analista, sei lá se realmente precisamos deles! Talvez, analista seja últil para alguns projetos de empresas que pensam que software pode ser contruído da mesma forma que se contrói um carro! Nestes tipos de empresa eles são úteis.
Mas a realidade não é essa. Percebo claramente que os profissionais que vem se destacando são aqueles que buscam boas práticas de programação, buscam ter uma boa gama de conhecimento tecnológico e de suas artimanhas, e que ainda assim, buscam conhecer profundamente ou o suficiente o problema do cliente.
Thiago
Uma conclusão pode-se tirar disso tudo:
Vc tem nascer da barriga da sua mãe como
"ANALISTA SENIOR" para trabalhar e dar bons resultados p a empresa.E para ganhar bem tb.Acho q pelas opiniões é isso…rssss…
Bom mas deixando um pouco de lado a brincadeira acho q a tendência é existir analista programador.Vc tem q entender bem das coisas p programar…Eu tenho trabalhado como “programador” e como n são esclarecido bem as coisas nas empresas e vários problemas nascem no caminho tenho q me comportar como analista muitas vezes…
A realidade é q desenvolvimento de software n é sempre numa fábrica,num lugar lindo e com tudo programado.E a analise, os processos são definidos não como deveriam e no tempo q deveriam.
Enfim, infelizmente o caminho é um programador ser analista também.
E discordo q programador deveria ser “estagiário”.
Este tem seu valor…
O que é, afinal, um “Analista de Sistemas”?
- Muito bem, Sistema, deite-se ali no divã e conte-me todos os seu bugs…
-Bom, eu preciso de um sistema bem simples de processamento de imagens com redes neurais junto com cálculos de pesquisa operacional e usando também cadeias de Markov.
-Tranquilo… uma semana dá pra fazer. Hum, acho melhor duas pois o nosso estagiário estuda na parte da manhã.
-Há, preciso que a aplicação funcione no desktop, na internet e no meu palm. Vai precisar aumentar o tempo?
-Claro que não, esses detalhes o programador faz no final de semana!
:mrgreen:
Olá
Leandro, na verdade isto foi uma brincadeira (de gosto duvidoso) pois o que tenho visto nas empresas é estagiário trabalhando 8 horas por dia desenvolvendo produtivamente igual a qualquer um. Isto é mais uma maneira do patrão economizar. Muitas vezes no fim do estágio, o cara que fez a faculdade meia boca, se sacrificando pensando que no fim iria ser efetivado, leva um pontapé na bunda. Resultado: nem aprende na faculdade e nem fica com o emprego.
[]s
Luca
Isso é ilusão.Analistas como pregados na faculdade não existem. Esse papo de entregar tudo pronto pro programadornunca foi verdade.
No papel tudo funciona. Olhando um documento de requisito de uma página ou mais, o cliente acha que está tudo bem. Quando se percebe que a implementação não pode ser feita como o “analista” ou o “arquiteto” ou o “projetista” especificou, quando o cliente v~e depois de meses que o sistema não faz o que ele quer, aí sim você entra no mundo real.
Esse carinha da palestra ou não conhece o mercado ou quis passar uma visão romântica e obsoleta.
tirou as palavras da minha boca… esse cara com certeza nao conhece o mercado ou vive outra realidade… se algum dia algum programador pegar uma especificação perfeita vai virar feriado! A verdade que sempre vi foi: quem realmente FAZ é o programador, que pega um monte de ideias que sequer pode ser feitas e faz milagre.
Então lá vai uma outra frase contra analistas:
"Um software não se constroi, se converge"
para quem não entendeu, não adianta tentar prever tudo antes, imaginar, especificar se no momento em que vai desenvolver percebe-se que não pode ser feito e ai sim, começa a convergir para outras opções.
esse ideia teoricamente e no papel são lindas, na prática…
este é o típíco tópico que deveria ser transformado em PDF e imortalizado em algum lugar 
OláLeandro, na verdade isto foi uma brincadeira (de gosto duvidoso) pois o que tenho visto nas empresas é estagiário trabalhando 8 horas por dia desenvolvendo produtivamente igual a qualquer um. Isto é mais uma maneira do patrão economizar. Muitas vezes no fim do estágio, o cara que fez a faculdade meia boca, se sacrificando pensando que no fim iria ser efetivado, leva um pontapé na bunda. Resultado: nem aprende na faculdade e nem fica com o emprego.
[]s
Luca
Discordo!
Se ele tem produtividade igual a qualquer um, é porque ele é um bom programador.
Então, na teoria, ele terá facilidade de conseguir emprego, pois é um bom profissional, só precisa achar alguem que queira pagar o valor dele ao invés de contratar outro estagiário e lhe ensinar tudo de novo.
concordo em string, numero, data!
Analista é um ex-programador que não acompanhou a evolução tecnológica.
Acho que hoje o conceito de Analista Programador(ou Desenvolvedor) é o típico profissional que conhece um pouco da tecnologia, consegue entender o negócio e aplicar a tecnologia para resolver aquele problema.
Por mais que gastemos horas e horas de análise e projeto, se os desenvolvedores não entenderem o contexto, dificilmente teremos um bom sofware.
O papel do Analista é absorver os requisitos do Cliente e formatá-los de modo que o projetista possa transforma-los em funcionalidades computacionais, criando o projeto para que o Desenvolvedor possa implementá-lo.
A separação destas etapas não é desculpa para que o Analista não entenda de tecnologia nem o Desenvolvedor não entenda o negócio.
Acho que “Analista Programador” se encaixa perfeitamente nesse cenario, um cenario real.Talvez o maior problema quanto ao estipular os prazos nem seje o analista, e sim o vendedor de software…Acho engraçado essa briga entre analista e programador, tenho amigos na faculdade que odeiam analistas pelo fato de serem analistas. Essa briga vem de tempos em que muitas dessas pessoas não estavam nem em projeto de nascer. Quando o analista não sabia escrever uma linha de código, trocaram de tecnologia e ele não se preocupou em se atualizar e passou a somente fazer analise, e em função disso os programadores tinham que ficar “arrumando” os furos de analise fora que a comunicação era zero, a hierarquia era algo que incomodava e por ai vai.
Uma conclusão pode-se tirar disso tudo:
Vc tem nascer da barriga da sua mãe como
"ANALISTA SENIOR" para trabalhar e dar bons resultados p a empresa.E para ganhar bem tb.Acho q pelas opiniões é isso…rssss…
Bom mas deixando um pouco de lado a brincadeira acho q a tendência é existir analista programador.Vc tem q entender bem das coisas p programar…Eu tenho trabalhado como “programador” e como n são esclarecido bem as coisas nas empresas e vários problemas nascem no caminho tenho q me comportar como analista muitas vezes…
A realidade é q desenvolvimento de software n é sempre numa fábrica,num lugar lindo e com tudo programado.E a analise, os processos são definidos não como deveriam e no tempo q deveriam.
Enfim, infelizmente o caminho é um programador ser analista também.
E discordo q programador deveria ser “estagiário”.
Este tem seu valor…
Acho que vocês estão esquecendo só de uma coisa: “relativizar”.
Por exemplo na Índia, existem tantos programadores, que a regra lá é essa. Os projetos são sempre inchados, as pessoas são super especializadas, etc. Analista fazem análise… e programadores programam. Sem choro nem vela. Parece que nos países de primeiro mundo, também existe uma divisão clara entre programadores e analistas, como descreve a reportagem do Guilherme sobre a experiência que ele teve na Alemanha.
Para a maioria dos problemas de TI de hoje a complexidade é pequena, mas a dimensão pode ser bastante grande. Daí a idéia de fábrica de software, a última palavra em “comodities” e o CMM 5.
Mas, não existe nenhum processo que faça uma pessoa medíocre vencer uma partida de xadrez com o Kasparov. Assim como existem problemas na informática realmente difícies… (alguns exemplos: BI, otimizações, CG) Em geral, quanto mais inteligente um programa é mais difícil é escrevê-lo, não só pelo problema em si, mas pela dificuldade em encontrar pessoas capacitadas.
Neste aspecto acho que o brasileiro tem uma vantagem. Nós somos acostumados a fazer de tudo. A ser analista programador dba e admin. Temos uma versatilidade e pensamos que isto é a coisa mais normal do mundo. NÃO É! E acho que precisamos encontrar nosso próprio caminho e não seguir o caminho do CMM 5 + mão-de-obra escrava. É certo que a produtividade média do brasileiro é bem maior que a do indiano (considerando que temos uma política de profissional (CLT) bem paternalista). Mas não devemos simplesmente desconsiderar o CMM; precisamos entender onde se aplica e por que e daí criarmos a alternativa nossa.
Seu amigo é o Fred Brooks? :mrgreen:
Pra quem não entendeu, a frase é dos ensaios reeditados neste livro:
Onde tambéme stá o artigo original que diz: No Silver Bullets.
¬¬
Chega a doer (…)
Quer dizer que eu sou um louco varrido, fora da realidade, alucinado. 
Eu não sou o dono da verdade, se eu estou errado o que eu posso fazer?? (Sem machucar blz!!)
Enquanto ao ler é programar mais … isso serve para todos :).
Ponto positivo:
Puxa vida, isso deve estar sempre bem claro … acho até que eu exagerei nas minhas palavras mas concerteza o trabalho em grupo é a melhor solução. E engana-se quem pensa que so programador resolve o problema, e preciso alguem que sabe inclusive de administração.
Voltando ao tema principal do topico eu gostaria de dizer o seguinte. O Senhor J mencionou um fato que N Teorias Administrativas ja provaram, vocês podem perceber que a figura do dito GENINHO sumiu do mapa, nem se fazem mais filmes dos ditos cujo :). Ele estava certissimo falando de trabalho em equipe, eu quiz complementar que somente programadores não resolvem e nem têm tempo suficiente para resolver tudo de um projeto. Eu não culpo ninguem afinal voces se formaram para ser cientistas da programação e estarem sempre em busca de melhoria nos codigos.
Pena … que pelo que li, a grande maioria so quer entregar o projeto, se funcionou otimo. Lembre-se que muita das vezes o cliente nem sabe mecher com computador direito, muita das vezes aquilo tudo é tao diferente que está otimo. O que eu quiz pregar é que precisamos nos unir (um gerente cuidaria bem disso), e analises bem feitas com uma equipe de programação unida vai proporcionar muito mais aos seus clientes. Esse é o seu diferencial. Buscamos ser diferentes, a mesmisse seus concorrentes também pode fazer!! Quantos aqui não fazem a mesma coisa que voce?? Quantos aqui programam java??
Conto.
Era uma vez um Senhor chamado David, um “João ninguem” que está em apuros financeiramente. Resolveu virar camelo, e gastou seus ultimos tostoes montando sua humilde barraca, tirou o da boca da familia o sustento do dia :(. O cara simplismente inovou, buscou não somente entregar ao seus clientes sua mercadorias, mas tambem uma forma de faze-lo querer sempre os seus produtos. Era com muita satisfação que ele incrementou suas vendas com um toque de simpatia, alegria. Esse notorio fato fez dele uma figura muito conhecida é hoje sua banca vende ate pela internet. Ele é consagrado pelas grandes multinacionais e sempre e convidado para dar palestras motivacionais. O cara não quiz somente vender, ele aplicou a tudo isso formas, estrategias, riscos e muitos outros requisitos que formam muito bem controlados.
(Recordo que a historia era mais ou menos assim)
http://www.bancadodavid.com/
Um Zé bombinha uma vez me disse. Eu não quero mais sair de porta em porta fazendo esse meu serviço, sinto que preciso ir mais alem. Não quero mais ser um zé bombinha, eu sou impulsivo, aplico preços pela direção do vento, forneço um serviço tao comum que se meus clientes PENSAREM BEM eles podem comprar o remedio e misturar na bomba e fazerem o serviço eles mesmo. Através desse pensamento (E é pensando que evoluimos) o senhor zé resolveu aprimorar mais. Contratou um profissional para realizar o serviço de jardinagem enquanto ele fazia o serviço do zé bombinha. Depois ele contratou um profissional para realizar serviços mais tecnicos como esterelização de ambientes. Hoje o ze bombinha ganha muito muito mais fazendo o mesmo serviço :).
(…)
Etica profissional é uma coisa que precisamos sempre ter em mente.
É claro que eu não ia escrever isso ao pé da letra né. Interprete e me diga se não é a mesma coisa? Detalhe … a etica profissional envolve 3 pontos fundamentais. Eu so mencionei o ponto de vista tecnico (conhecimento tecnico) porque era o mais inerente ao caso.
É muito fácil juntar uma galera do mesmo lado e pisar em cima. Precisamos sair dessa inercia e começar a olhar para os lados. Buscar … buscar …o quê?? porque?? será??
Obs: Não tente pegar o topico pela metade, leia tudo antes de PUM PAH TIBUM, SPLAT.
Onde? Aqui, Aqui ou Aqui?!? :shock:
Vamos recapitular … ninguém disse que não existe analista que presta, existe (posso ser só eu que nunca vi um)!
Assim como existe a necessidade de análise do problema … mas essa análise não pode e não deve ser feita por alguém apenas com esse fim já que ele não poderá adicionar nada as próximas etapas ESSENCIAIS ao resultado final … tem que have um balanço das forças e compreensão que só existe resultado final com código/
Pois é isso que fazemos no forum, ninguém aqui está te batendo. Pergunta pro Richard o que é discutir sobre CMM
Acho que já temos argumentos suficientes pra ler, reler e pensar … cada um segue sua linha mesmo de qualquer jeito.
Só quer entregar o projeto?
Acho que você ainda não entendeu. Ninguém aqui está dizendo que é só entregar e pronto, o que quase todo mundo está dizendo é que análise não é uma coisa que deva acontecer uma vez e pronto. Você não pode simplesmente pegar o cliente disse uma vez, montar uma análize perfeita e entregar pros programadores fazerem um sistema perfeito. Isso simplesmente não existe.
Não devem existir “fases” no desenvolvimento, todo deve ocorrer junto o tempo todo. Nós devemos estar o tempo todo em contato com o cliente, devemos estar o tempo todo corrigindo falhas ou adicionando novas idéias a análize, devemos tentar melhorar tudo o tempo todo!
Você entrega uma análise “perfeita” na primeira tentativa? Eu duvido.
Na boa, quem precisa sair da inécia é você que ainda acredita em “ideais” que são da época do nascimento da computação e já foram mais do que comprovados como errados. Dê uma olhada em métodos ágeis, como Extreme Programming e tente ter um relacionamento mais respeitoso com os “programadores”, você vai ver como isso pode ajudar no seu trabalho.
Na verdade essas ideias nao nasceram com a computaçao. O papel de analsita foi criado para tentar analisar o problema antes de sair codificando como um louco, so que no decorrer ele foi se especializando demais, a ponto de acreditar que o codigo eh algo futil, documentaçao e o que vale. Eu ouvi isso aos doze anos de um analista.
Dez anos depois, as cosias mudaram. Muitas empresas simplesmente ignoram a divisao ee stao voltando para uma versao do metodo nike (lembra disso, linhares?) “Just do It”, so que eles exigem que voce faça um pouco diferente: documente e especifique como um doido, depois programe. O que o cliente quer e o de menos.
Quem le bastante sabe que em 99% dos livros de grandes autores nao-ligado a RUP ou UP ou outra metodologia engessada (e mesmo nos mais recentes destas) as pessoas pregam os valores ageis. E interessante que mesmo livros muito antigos ja faziam isso antes de se ter um termo “agil” para invocar.
Essas pessoas sao os grandes pensadores do software, e seguem estes principios. O Joel e um caso excelente, ele ja trabalhou na Microsoft e em lugares onde se pensa da maneira antiga (quem acompanha lsitas internacionais de agile sabe que a MSFT esta mudando de perfil, dando MUITO apoio a agilidade, inclusive com seminarios online gratuitos sobre o tema) e quando abriu sua emrpesa, ele colocou o que acredita nela. Convido a dar uma olhada nos artigos de gerencia dele.
Existe sim um analista. A principal tarefa dele e ajudar ao cliente no que ele quer, e em muitos casos ser o “cliente interno” (um proxy pro cliente). Ele escreve requisitos, responde pergutnas e avalia o que e produzido.
Dai para a frente, tudo e projeto.
Trunk, o que um analsita faz exatamente para voce que um programador nao faz? O que capacita este analista a fazer isso?
Pois é, sabe que esse ainda é o pior problema que eu tenho pra explicar XP, todo mundo sempre diz que XP prega “faça e pronto” (como o pessoal falou lá no Java-BR). Mas a galera tá começando a entender, já consegui converter um pessoal daqui da universidade a trabalhar com testes unitários e as coisas estão indo bem melhor do que eu imaginava, até mesmo pra mim :mrgreen:
Só falta convencer os professores que seria ótimo a cadeira de “Análise e projeto de sistemas” ser feita com XP ou pelo menos falasse tanto de XP quanto eles falam de RUP 8)
Ta bom, eu sou um lunatico mesmo :). Pelo menos tem alguns que embora acanhados seguem a mesma ideia.
Vamos recapitular … ninguém disse que não existe analista que presta, existe (posso ser só eu que nunca vi um)!
Eu pensei porque esses caras acham isso tão atrasado. Me lembrei de alguns fatos e fui fazer uma garimpagem. Acessei o site do mec (www.mec.gob.br) para saber quantos cursos oficializados de sistema de informação existem. Ate hoje foram devolvidos 28 universidades. Tirando as que usam o nome mas que na verdade é administração não passa muito de 15. Algumas que eu acessei os dados comprovei que nem chegaram a formar turmas.
Está explicado porque programador acaba tendo de fazer tudo mesmo!
Ai veio outro estalo e lembrei de uma reportagem feita pelo programa Fantastico um tempo atraz. Estavam eles falando mais uma vez sobre o desemprego e estavam eles mostrando uma parede em São Paulo onde é afixado vagas de emprego. Logo pela manha fica um monte de gente nessa parede verificando as vagas. Por sorte do destino pegaram um cara que estava tentado logo uma vaga de analista. Acompanharam o cara e talvez por estar sendo acompanhado por uma camera o contratante acabou cedendo uma chance para o individuo. Coisa em, ai frusta mesmo … olha onde voces vão procurar analistas :).
Ai, ja ouvi uma coisa que acho meio ficção que agora até faz um certo sentindo levando em conta o que o amigo rodrigousp disse.
Em relação ao que é proposta la fora gasta mais ou menos dois anos para chegar no brasil. Se for verdade ta explicado tambem! (leia o ultimo tipo do rodrigo).
AHHHhhhh, Mauricio Linhares …
Musiquinha do Detonaltas para voce:
(…)É a dúvida entre o que é realmente bom e o que é realmente ruim
Porque o certo pra você pode não fazer o mesmo efeito em mim
E se tratando de habitantes do mesmo planeta isso pode ser fatal
É a escolha entre seguir com o bem sem saber direito o que é o mal
Chega desse assunto!! \0/ <0> .
Detonautas? Blergh! :oops:
Mas dê uma olhada em XP e métodos ágeis, os livros são pequenos, se não ajudar também não atrapalha :thumbup:
Discordo!
Se ele tem produtividade igual a qualquer um, é porque ele é um bom programador.
Então, na teoria, ele terá facilidade de conseguir emprego, pois é um bom profissional, só precisa achar alguem que queira pagar o valor dele ao invés de contratar outro estagiário e lhe ensinar tudo de novo.
O problema é que hoje em dia o estagiário serve basicamente de bode espiatório, o contrato pode ser desfeito a qualquer instante, não precisa ter carteira assinada, quando demitido, o empresário não precisa pagar fundo de garantia, e mais uma série de coisas…
Bom, se este gerente for tão brasileiro como eu e qualquer um aqui, ele vai aprender a mecher na raça, assim como muitos outros milhões de brasileiros!
Sim, no país de Alice no Páis das Maravilhas isso é perfeitamente possível!
Trunks, o fato é q isso varia muito de equipe para equipe. Se isso fosse real, e se as pessoas realmente trabalhassem em equipe, não haveriam tantos softwares ruins por ai!
Eu digo isso pq trabalhei em uma equipe, e tem algum pedaços de software desenvolvidos por alguns integrantes que eu fico resolvendo bugs nestes códigos até hoje. Enquanto alguns programadores fizeram um bom serviço, um outro foi lá e fez de qualquer jeito.
Por isso Trunks, é que eu concordo plenamente com o que foi escrito no artigo. É melhor 1 programador bom, do que 3 medianos.
Eu ainda vou além, sou mais 4 programadores bons, do que 6 programadores bons e 1 médio! (a não ser que este programador mediano fosse esforçado e autocrítico!!!)
Esse é o seu diferencial. Buscamos ser diferentes, a mesmisse seus concorrentes também pode fazer!!
Humm… Programar em java, qualquer um programa, mas poucos programam que nem eu! Apesar de inexperiente, sou sempre autocrítico, e estou sempre de pouco em pouco tentando fazer melho o que faço!
Se todos os programadores fossem iguais, não precisariamos mais de programadores, bastaria um idiota que ficasse dando control C + control V para ficar copiando código de um lado para outro!
Abraços!
Thiago Senna
uma coisa é certa…
O artigo de otimos x bons eu achei meio sem sentido. É chover no molhado discutir isso…
Já o artigo do Phillip é realmente muito interessante !!!
Money, Moral, Burnout
Dos três eu achei Burnout o mais difícil de resolver.
Mas um problema mais foda ainda, que o cara não fala é:
Freedom: Poder fazer as coisas da sua maneira, sem ter um gerente centralizador e pentelho no seu ouvido a cada nova linha de código que vc escreve.
uma coisa é certa…
Nem sempre, “Trazer novas pessoas pra um projeto atrasado, só faz com que ele atrase mais ainda”.
Freedom: Poder fazer as coisas da sua maneira, sem ter um gerente centralizador e pentelho no seu ouvido a cada nova linha de código que vc escreve.
Se cada um fizer “à sua maneira”, não estão trabalhando em grupo.
Se cada um fizer “à sua maneira”, não estão trabalhando em grupo.
Cada pessoa do grupo pode fazer a sua parte a sua maneira. Não que não devam discutir sadiamente as questões, mas eu decido como eu vou fazer a minha parte.
Se as minhas decisões não estão de acordo com a filosofia ou metodologia da empresa, então algo está errado. Melhor arranjar outro emprego…
Se as minhas decisões não estão de acordo com a filosofia ou metodologia da empresa, então algo está errado. Melhor arranjar outro emprego…
Aí sim :mrgreen:
Mas eu ainda acho que existem muitas coisas que devem ser acordadas, como ferramentas de build, servidores de deployment, controles de versão, padrão de documentação, não acho que isso deva ficar a cargo de cada um não.
Por isso que eu gosto do Maven, já padroniza um bocado :lol:
Tudo pode ser feito a maneira que o programador se sinta a vontade.
Acho errado impor usar uma ferramenta para build específica sendo q o cara pode produzir o mesmo resultado com a sua própria.
O correto em uma empresa grande, é se padronizar, para ser mais fácil dar manutenção.
Cada um fazer a sua maneira pode ser bem complicado se não houver acordos. Isso cheira a macorronada com churrasco.
Tudo isso que vc falou eu concordo que tem que padronizar. Coisas que não concordo e que já briguei com a diretoria:
:arrow: IDE (gosto muito do Jext)
:arrow: Cliente CVS (gosto muito do Tortoise)
Não concordo que o programador possa ser livre e usar a ferramenta de build que quiser!
Se for para trabalhar em equipe, então a equipe deve fazer uma reunião, e definir entre eles qual é a ferramenta de build mais apropriada para o projeto, e não para os indivíduos!
Um bom programador deve aceitar as decisões cedo e se adaptar o mais rápido possível!
Mas eu ainda acho que existem muitas coisas que devem ser acordadas, como ferramentas de build, servidores de deployment, controles de versão, padrão de documentação, não acho que isso deva ficar a cargo de cada um não.
Tudo isso que vc falou eu concordo que tem que padronizar. Coisas que não concordo e que já briguei com a diretoria:
:arrow: IDE (gosto muito do Jext)
:arrow: Cliente CVS (gosto muito do Tortoise)
Rapaz, padronizar o controle de versão é bom, mas padronizar o cliente é d+
Eles pelo menos tinham um motivo pra isso?
Tudo pode ser feito a maneira que o programador se sinta a vontade.
Acho errado impor usar uma ferramenta para build específica sendo q o cara pode produzir o mesmo resultado com a sua própria.
Quando você pegar um projeto onde gente usa Maven, outro usa Ant, outro usa direto na IDE e ainda outro usa uma ferramenta que ninguém conhece, você vai entender isso.
Especialmente quando for fazer um deployment :lol:
Sem contar as estruturas de diretórios completamente diferentes, que são uma maravilha pra integrar, especialmente em projetos que tem dependências :mrgreen:
Um bom programador é capaz de produzir o que está sendo esperado, independente de ferramentas. Levando em conta os padrões de nomenclatura de classes, metodos, variaveis locais, etc … etc… por exemplo.Mas se o cara produz mais usando a ide X, pq impor ele usar a ide Y ?
Não estou falando por mim, pois em relacao a IDE, utilizava o JDev e entrei no projeto onde a maioria usava o eclipse, e a empresa estava querendo migrar. Logo, testei, comecei a usar em casa, e tals … e estou usando o eclipse sem problemas, mas existem outras pessoas no projeto q estao com o Jdev(depois q a oracle anunciou q seria free), eles continuaram com o jdev, e nao esta tendo problema algum.
Aí não … estrutura de diretório DEVE SER ÚNICA.
Mas ferramentas PARA se fazer o q foi especificado não deve ser única, seria bom que fosse, pois a equipe estaria mais integrada.
São como frameworks , uns gostam do struts, outros do ww, outros preferem criar o seu , … ja imaginou reunir essas cabecas numa equipe soh ? Não rola.
Tem coisas que deve definir, outras vc pode deixar a pessoa escolher.
Um dos benefício de se usar ferramentas de build é de certa forma vc ganhar um pouco mais de independência no seu projeto, sendo possível assim desacoplar seu projeto de uma IDE específica!
Se for para usar uma IDE por ordens superiores, fazer o que né! Mas acho interessante padronizar ao menos a ferramenta de build assim como suas operações possíveis, ai fica a critério do programador qual IDE irá usar.
A IDE se torna apenas uma ferramenta de desenvolvimento, no entanto, integrada com a ferramenta de build!
O programador até pode inventar algumas rotininhas, alguns scripts facilitadores, desde que não afete a arquitetura e estrutura do projeto que foi definido pela equipe!
Aos poucos, se algum programador tem um script não adotado no projeto e que só ele usa, e se este script for realmente interessante para a equipe, a tendência é que ele apresente esta solução para a equipe, e esta solução venha a fazer parte do projeto!
Nem sempre, as vezes se tem um ótimo programador, mas o resultado final, não bem o que o cliente esperava… :lol:
Vc já brincou de telefone sem fio qdo era pequeno ?
Pois é, as vezes a informação chega ao programador de forma incompleta, ou interpretada de n formas diferentes… mas se o programador é bom, ele deveria fazer parte de todas as fases, entendendo o que o cliente quer.
Fala galera,Programo desde 90, quando comecei com clipper,é já pude desenvolver diversos sistemas em diferentes áreas de atuação, o que me deu um grande flexibilidade no tocante a analise/programação.
Acredito que um programador, por melhor que seja, se não conseguir entender o negócio do cliente não vai desenvolver um bom projeto, falo por experiência, pois já errei muito. Você acaba deixando o sistema funcional, rápido, tecnologicamente avançado, mas o danado não faz o que realmente o cliente queria.
Esse é um erro cometido por uma grande parte de programadores que já conheci, pois apesar de manjarem muito da linguagem, não conseguiam entender o que o cliente queria.
Conselho: se vc já é um programador médio, tente virar um analista médio, pois se tornar um ótimo programador sem sacar de analise não da muito resultado.
[]s
Sou da seguinte filosofia: o profissional da informática deve conhecer as ferramentas e deve conhecer o negócio (afinal, TI é uma atividade meio).
Bom galera, o cara do artigo falou numa forma, que ele mesmo não sabe se funciona, de “ganhar dinheiro”. :lol:Existe um ISO que é dado a empresas de qualidade. Na epoca que estava atualizado com os dados tinha nada mais nada menos que 3 empresas na america latina que detinha um nivel de qualidade 5 (ultimo) - Tinha alguma relação com PMI. Por incrivel que pareça essas empresas seguem a linha de raciocinio que eu falei. Agora não intendi onde voces querem chegar porque até agora eu so vi falar de programadores e linha de codigo sendo que a parte mais essencial de um projeto é o seu projeto :).
Você está fora e muito fora de sintonia …
O cara do artigo é o Joel Spolsky, dono de uma empresa onde ele aplica esse conceito como está escrito no artigo (que você não deve ter lido ou entendido direito) e também está escrito que com esse modelo ele conseguiu ser rentável desde o início.
Outro ponto que você não pescou nos artigos é que não é qualquer programador, são os bons que merecem toda essa atenção e valem esse esforço. É por isso que existem programadores pobres, porque a grande maioria (também está nos artigos, leia de novo) é mediano pra baixo.
A ISO com nível 5 na verdade chama-se CMM (Capability Maturity Model) e não tem nada a ver com a ISO … é aplicável apenas em fábricas de software e afins que por definição atraem os programadores medianos que não são muito chegados em pensar e os analistas que não sabem programar. (claro que estou generalizando, mas esse modelo é um pé)
Não se engane, há várias empresas que tem esse pensamento (do artigo) e estão muito bem, obrigado!
Um programador bom, deve conhecer de engenharia de software e também do arcabouço envolvido: MPS-BR, CMMI, PMBOK, COBIT, RUP. Tudo isso facilita a vida do profissional de informática.
Eu sou analista, trabalho na area a algum tempo e por mais que o cara saiba de programação ele nunca sai com nada. Eu mesmo ja tentei fazer um programa assim do nada, o programa apresenta muito mais erros, o programador se perde completamente na hora de fazer manutenção, o programador leva muito muito mais tempo para entregar, e se algum dia outro alguem for mecher é preferível começar do zero. E incrivel como os programadores tem preguiça de ir no cliente e falar com ele.
Você está confundindo análise e projeto de software.
Um analista de negócios é muito importante, alguém com muito conhecimento do domínio, tanto que metodologias ágeis extrapolam e mandam você colocar o cliente na sua equipe (quem melhor que ele?).
Ética profissional não é isso.
E se alguém acha que projeto de software e programação são coisas diferentes…deve ler e programar mais.
O programador está limitado pela linguagem. O que seu analista usa, UML? Sabia que ela é uma linguagem limitada?
Desenvovler software é resolver problemas. Um analsita se preocupa com processos, técnicos se preocupam com a implementação de processos em sistemas computacionais.
Nível 3 de que, CMM?
E desde quando isso define a qualidade (ah, esquece, CMM de novo não!)?
Realmente LoC não é boa métrica para nada, o que você sugere?
Eu sou a favor das seguintes métricas para software:
Também deve estar no pensamento diário do programador, os Padrões de Projeto… Design Patterns
Adriano Paulino Menezes tu foi o campeão em ressucitar tópicos… desde de ontem que tu vem ressucitando tópicos de 2005 com comentários sem fundamentos e inúteis… evite fazer isso.
Leia o How To -> http://www.guj.com.br/java/287476-gujnautas-how-to
Acima de tudo os seres humanos envolvidos satisfeitos, principalmente o cliente claro.
Não sei nem quem é esse palhaço,
só conheço Sputnik, desse aí nunca ouvi falar.
Empresa grande analista é de negócio, nível mais alto e corporativo. Programador e analista de SISTEMAS não éo mesmo que analista de negócio.
Vai na VIVO, telecom gigantesca vai ver se existe isso de programador e analista de sistema.
Uma vertical grande tem de ter especialista no negócio que demanda sistema, o sistema adequa-se ao negócio.
Vão procurar empresas que não são de fundo de quintal como modelo.
VIVO, PETROBRAS, VOTORANTIM, empresas desse naipe pra cima. sem falar tambem dos bancos BRADESCO, ITAÚ E HSBC.
ISSO AÍ É TUDO CONVERSA DE MENINO.
Isso é ilusão.Analistas como pregados na faculdade não existem. Esse papo de entregar tudo pronto pro programadornunca foi verdade.
No papel tudo funciona. Olhando um documento de requisito de uma página ou mais, o cliente acha que está tudo bem. Quando se percebe que a implementação não pode ser feita como o “analista” ou o “arquiteto” ou o “projetista” especificou, quando o cliente v~e depois de meses que o sistema não faz o que ele quer, aí sim você entra no mundo real.
Esse carinha da palestra ou não conhece o mercado ou quis passar uma visão romântica e obsoleta.
Pelos 5 anos de faculdade que fiz, nunca vi essa profissão sendo citada nas disciplinas. Sei que na prática é assim, mas errado são os programadores que começaram a fazer esse papel também!!!
Não sei nem quem é esse palhaço,
só conheço Sputnik, desse aí nunca ouvi falar.
Empresa grande analista é de negócio, nível mais alto e corporativo. Programador e analista de SISTEMAS não éo mesmo que analista de negócio.
Vai na VIVO, telecom gigantesca vai ver se existe isso de programador e analista de sistema.
Uma vertical grande tem de ter especialista no negócio que demanda sistema, o sistema adequa-se ao negócio.
Vão procurar empresas que não são de fundo de quintal como modelo.
VIVO, PETROBRAS, VOTORANTIM, empresas desse naipe pra cima. sem falar tambem dos bancos BRADESCO, ITAÚ E HSBC.
ISSO AÍ É TUDO CONVERSA DE MENINO.
Já tive exériências em duas dessas empresas e pelo que percebi os cenários são caóticos.
Isso de acúmulo de função só faz aumentar custos.
Dá certo nessas empresas, pois se tem dinheiro para investir.
Mas os custos são elevadíssimos.
O que percebi é o grande retrabalho e alta-rotatividade que existe nessas empresas.
O separação radical das funções realmente não deve existir (programador, analista, tester), mas definir corretamente responsabilidades é coerente.
Esse coisa também de que o negócio deve estar na cabeça dos programadores é papo furado, pois cria a “armadilha” da dependencia das pessoas no processo.
E no ponto de vista da gestão isso é muito maléfico…
Um conhecimento de um sistema deve ser algo tangível, deterministico e tranparente para todos e não uma caixa preta.
Hoje, tenho o seguinte cenario aonde trabalho:
Tem um novo projeto onde existira um modulo web, um desktop e um no celular.
Vou ser o responsavel por sentar com o cliente, entender o que ele quer, o que ele precisa e em quanto tempo. Depois disso, vou documentar, analisar, reunir novamente com o cliente, ver se o que elaborei esta de acordo com as necessidades dele.
Feito isso, vou sentar na minha maquina e começar a desenvolver, entregar aos poucos e recebendo a aprovação do cliente.
Acho que “Analista Programador” se encaixa perfeitamente nesse cenario, um cenario real.
Acho engraçado essa briga entre analista e programador, tenho amigos na faculdade que odeiam analistas pelo fato de serem analistas. Essa briga vem de tempos em que muitas dessas pessoas não estavam nem em projeto de nascer. Quando o analista não sabia escrever uma linha de código, trocaram de tecnologia e ele não se preocupou em se atualizar e passou a somente fazer analise, e em função disso os programadores tinham que ficar “arrumando” os furos de analise fora que a comunicação era zero, a hierarquia era algo que incomodava e por ai vai.
Não tenho como objetivo virar O PROGRAMADOR e depois passar para O ANALISTA e parar de desenvolver e projetar.
Os dois caminham junto e acho que todos devem saber ambos os lados.