Este tópico está na minha fila de posts há meses, hora de sair algo. Eu vou me basear num e-mail que recebi de uma pessoa do GUJ (cujo nome não será mencionado pois não pedi autorização para tal):
Sobre o “polêmico” manjado tópico de que o java pode acabar.
Você postou o seguinte (na primeira página):
Software é programar. Se você que gerenciar uma equipe de desenvolvimento você tem que estudar matérias relacionadas à gestão de pessoas. Isso não é uma evolução do programador, um desenvolvedor de software é sempre um desenvolvedor de software.
Será que alguém que se forma em Ciência da Computação (como eu, se Deus quiser) não consegue o cargo de gerência de equipe? Eu vejo isso pelo meu tio… ele é formado em Engenharia Química e hoje é gerente de um empesa aqui, mas porquê? Porque ele conhece como as coisas funcionam… todo gerente que conheço ou que já ouvi falar aconteceu o mesmo… gerentes de supermercado geralmente sabem tudo o que se passa dentro do maldito mercado! Concorda? Logo, começa-se como programador, pra depois passar pra cima. Ou não? Você já foi programador? Estou em dúvida porque parece que o salário de um programdor (caso eu seja programdor pra vida inteira, que é algo que eu não quero) é baixo e não dê pra sustentar uma família, entende? Da maneira que eu digo faz parecer que eu não quero ser programador JAMAIS, mas eu quero… putz, amo programar, tenho um tesão gigantesco por programação… mas o problema é se vai me sustentar bem e minha família pro resto da vida, entende? Acredito que se um dia eu chegar a um cargo que não envolva programação eu ainda assim vou programar, pra me divertir mesmo.
E aí, o que você acha?
Este é um problema bem grande. Vamos começar sobre algo que não está explícito no e-mail acima mas que existe: aquilo que alguns chamam de analista de sistemas.
Quando eu estava na faculdade pela primeira vez (ou seja: antes de abandoná-la pela primeira vez) lembro de ter aula com um daqueles professores com anos de COBOL nas costas. Ele se lamentava sobre como o mercado confundia analistas e programadores e como estava surgindo a bizarrice do ‘progranalista’- alguém que combinava os dois papéis. Na comunidade em geral você vê este pensamento, eu tenho muitos conhecidos que querem ser ‘analistas’, e isto para eles significa desenhar UML ou fluxogramas que são passados para os programadores.
Creio que já tenha escrito sobre este assunto neste blog mas, resumindo, não há justificativa para este papel existir no desenvolvimento de sistemas nos últimos dez anos. O papel do analista seria, teoricamente, converter um modelo abstrato (de negócios) em um modelo lógico, geralmente expresso de forma gráfica. O modelo lógico então passa a um modelo físico, que é a implementação.
Agora vamos analisar o caso de uma plataforma moderna de desenvolvimento como Java, .Net ou Ruby - ‘moderna’ aqui significando algo como “inventada nos últimos dez anos”. Um modelo abstrato é composto por conceitos de negócio. Geralmente estes conceitos não possuem uma estrutura que um computador entenda, logo o analista vai traduzir este conceito em lógica, provavelmente usando UML. Ora, UML é apenas uma notação gráfica para classes e objetos, e sua linguagem favorita já trabalha com classes e objetos! A tradução entre um modelo lógico e o modelo físico é desnecessária: o modelo lógico já é o modelo físico. A diferença é que UML não executa, por mais que os evangelistas de MDA cismem do contrário.
A solução? Modele em código. Caso seja necessário gerar diagramas basta utilizar uma das dezenas de ferramentas de engenharia reversa. Modelando em código você tem algo executável, testável e que pode dar feedback ao seu usuário.
“Analista de sistemas” é algo que não existe. Pode ter existido um dia, não sei, mas não faz mais sentido há muitos anos. O modelo lógico é expresso em linguagens de alto nível que modelam muito bem o negócio: Java, Ruby, C#… Quem converte o lógico em físico é o compilador, que traduz as abstrações em código de máquina.
Alguém colocar na sua assinatura de e-mail ou ter a carteira assinada (como eu já tive!) como “Analista Java” está se enganando e colaborando para a criação de papéis que só existem na burocracia das empresas e das pessoas.
Ok, sem diagramas de objetos então, mas e a parte do papel do analista de resolver problemas de negócio? Sinto informar mas se você fazia isso como parte das suas tarefas de “analista de sistemas” você estava ou se enganando ou enganando seu cliente. É certo que muitos clientes precisam entender seus próprios negócios antes de criar um sistema, mas isso não é papel de analista de sistemas, é papel de analista de negócios.
Um analista deste tipo possui capacitação em campos bem diferentes, é completamente possível que um analista de negócios seja um desenvolvedor (vamos abolir o “analista de sistemas” a partir daqui) mas neste caso ele está assumindo duas especialidades. Um analista de negócios possui um perfil não-técnico e provavelmente mais especializado em um domínio como bancos, marketing, telecomunicações e etc.
Mas e o gerente? Uma das piores coisas que podem fazer em uma empresa é promover um bom técnico à gerente (coordenador, o que for) apens porque ele está há muito tempo na casa. Querem estimular a pessoa? Transormem em um líder técnico, aumentem seu salário e o deixem em paz.
Gerência não é brincadeira. Não é porque alguém programa muito bem que vai ser um bom gerente. Se você é desenvolvedor mas sonha em dizer para a paquera no barzinho que é gerente de algo (nem que seja do McDonald’s) invista nisso. Aprenda sobre liderança, sobre mercado, plano de negócios, luxo de caixa, lean e todas as dezenas de disciplinas envolvidas. Vai levar algum tempo.
Só não encare isto como uma evolução. Você não está evoluindo, está mudando de carreira -da área técnica para a gerencial. Considerando que conseguir bons salários como técnico é complicado, pode ser uma boa escolha. Mas não necessariamente é a melhor escolha, se você é um bom técnico e não quer deixar isso de lado existem opções…
Algumas empresa, por exemplo a qual eu trabalho, implementa um metodo de promoção bem legal onde um bom tecnico(desenvolvedor) sempre será, se essa seja sua vontade, ser promovido na sua area, tornando-se um especialista, aumentando assim seus beneficios e responsabilidades. Isto chama-se plano de carreira Y.
Ate certo ponto td mundo é “igual”.Em um determinado momento , vc precisa escolher qual caminho seguir, sendo eles o caminho de Gestão ou Tecnico. Procurem na net por “modelo carreira Y”.
Abraços !
Belo post!
Afirmação Revolucionária
“A solução? Modele em código.”
Frase para continuidade?
“Se você é um bom técnico existem opções…”
Ficou parecendo que haverá continuação…
Eu nunca quis ser analista de sistemas, mas só agora sei com certeza mo porquê. :)
Falo disso com meus amigos há um bom tempo. Até mesmo conversei sobre isso aqui na empresa ontem: o problema do programador que vira gerente.
Há uma cultura enraizada que diz que quando um programador se torna experiente, deve mudar de área se quiser ser bem pago. Muitas pessoas que adoram desenvolver acabam desistindo disso por causa do dinheiro. As empresas não percebem quanto conhecimento e dinheiro estão jogando fora ao fazer isso.
Minha opinião é de que deve haver uma carreira “completa” para o desenvolvedor de software (que é diferente de programador). Se o cara for extremamente competente e experiente, deve chegar a algo como “Desenvolvedor-chefe” e ganhar tão bem quanto um gerente, óbviamente com a responsabilidade tão alta quanto.
Estou com alguns posts sobre isso em rascunho no meu blog há um bom tempo. Vou tentar finalizá-los.
Valeu Phillip! Continue com os ótimos artigos.
Isto já aconteceu comigo. Eu era técnico e fui “promovido” a líder e logo em seguida a gerente. Depois saí da empresa para ser técnico denovo. Quem disse que eu queria ser gerente?
“[...] Caso você precise erar diagramas basta você utilizar uma das dezenas de ferramentas de engenharia reversa. Modelando em código você tem algo executável, testável e que pode dar feedback ao seu usuário.[...]”
Exatemente o que as metodologias ágeis pregam !!
Cliente quer é software. Cliente não quer papel*.
Tá certo que em certos momentos algum artefato tem q ser gerado para auxiliar no desenvolvimento, mas nada impede de se fazer algo “bem” superficial apenas para auxiliar..e dps utilize ferramentas como javadoc e outras existentes ai no mercado..
ótimo post ..parábens
O problema é que acredito que estamos em um momento de turbulência, onde um modelo novo de processos, responsabilidades e papéis está emergindo disso tudo.
Com a maior relevância de processos ágeis nas organizações de hoje em dia, muitos papéis não fazem tanto sentido.
O próprio perfil de “analista/desenvolvedor”, cada vez mais procurado, é uma prova desta maior concientização do mercado de que “analista só analista” e “programador só programa” está com os dias contados
Este post sintetiza tudo o que eu sempre quis dizer sobre este assunto, mas nunca encontrei as palavras que me dessem tanta coesão. Ótimo post!
@Vitor Pellegrino
“O próprio perfil de “analista/desenvolvedor”, cada vez mais procurado, é uma prova desta maior conscientização do mercado de que “analista só analista” e “programador só programa” está com os dias contados”
O mercado atual quase que força as pessoas a se vestirem de “mercado”… tenho um amigo que precisa de um trabalho (récem-formado) , dificilmente ele irá encontrar um trabalho onde as pessoas tem esse nível de consciência, logo ele terá que se vestir de “mercado” para encontrar um trampo…
É complicado, sei que essa consciência parte de nos, mas as vezes nossas realidade de trabalho nos força a usar um vocabulário ou agir como o analista do waterfall times.
Correções…
nossas = “nossa”
nos = “”
Eu acho que a divisão dos papeis existe, porém uma mesma pessoa pode desempenhar vários os papeis, por exemplo o de desenvolvedor, arquiteto e coordenador juntos, sem problemas (meu caso).
Sobre o modelo em código, concordo sobre fazer o modelo em código, via TDD por exemplo. Mas acho que modelar ainda é uma tarefa para os iniciados. Muito estudo é preciso para chegar em modelos bons, que tragam qualidade ao SW (flexibilidade, testabilidade, blabla) e ainda reflita a necessidade do usuário/cliente. Ou seja, analista de sistemas (ou arquitetos) ainda são necessários a meu ver.
Mas talvez numa equipe onde qualquer desenvolvedor tenha acesso ao cliente/usuário e todos tem um bom conhecimento de arquitetura, como ouço o pessoal do XP pregar, talvez o analista realmente não seja necessário. Ou todos o são, mesmo que implicitamente.
[...] bola da vez foi encontrada em um post do Phillip Calçado que trata sobre a existência da famigerada profissão de “analistas de sistemas”, e [...]
Phillip,
gostei muito do seu post. Concordo contigo e me permiti escrever um post no meu blog explicando uma das minhas razões para isso.
Se alguem quiser dar uma olhada:
http://franktrindade.wordpress.com/2008/01/15/sistemas-sistemas-quando-vamos-entender-eles/
Abraco,
Francisco
@Pellegrino
Modelagem ágil tem um papel importante em divulgar isso mas não está tão relacionado. A falta de sentido em termos analistas de sistemas se dá porque os programadores usam linguagens de alto nível ninguém precisa mais traduzir nada. Talvez seja menos polêmico dizer que o cargo de programador acabou, agora somos todos ‘analstas’ (menos polêmico mas menos certo, creio)
@David
Ok, mas existe porquê? Arquiteto é cargo, não profissão.
Se você acha que seus desenvolvedores não são bons modelando cuidado com quem você contrata, escrever código hoje em dia é quase que somente modelar o domínio em termos de software. Para todo o resto temos pacotes na prateleira.
Concordo 100% com este post… Sem contar que é muito comum os “professores” de faculdade venderem a ilusão de que o objetivo dos cursos de sistemas da informação e correlatos é formar “gerentes” e que ninguém da sala precisará colocar a “mão na massa” quando se formarem…. Grande ilusão…
[...] A forma de especialização mais conhecida na área de desenvolvimento é a separação entre analista e programador. O analista é responsável por estudar os requisitos do sistema e gerar artefatos que transmitam a idéia para o programador - estes artefatos geralmente são diagramas UML (diagramas de classes, diagramas de seqüência, diagramas de iteração) e casos de uso. Em posse desses artefatos, o programador apenas “transforma” tudo isso em código. Simples não? Parece ser. Mas então por que isso não funciona? Aliás, acabei de ler mais um ótimo post do Phillip Calçado sobre este assunto: Quando eu crescer quero ser Analista de Sistemas. [...]
Phillip, entendo sua preocupação em relação a modelagem e a “qualidade” das pessoas a envolvidas, mas acho que estamos partindo de princípios diferentes.
Aqui nós contratamos pessoas com _potencial_ e esperamos que elas venham a desenvolver a capacidade de abstração ideal para modelar corretamente. Mas não esperamos que elas cheguem aqui entendendo o que é Design Patterns, UML ou TDD, por exemplo.
Sendo assim, mesmo com os pacotes de prateleira, eles ainda apanham um bocado para conseguir atravessar a barreira do código e conseguir ver ali um modelo abstrato.
Em quanto isso, temos pessoas que já cruzaram essa barreira e modelam, no meu caso via TDD, o código para o pessoal mais novo. Por isso o PAPEL de arquiteto (ou analista) ainda é usado aqui. Alguns, por sorte ou competência, só acumularam esse papel e por isso virou o cargo deles.
Estou assumindo que partimos de princípios diferente pois sempre ouço dizer que para usarmos métodos ágeis precisamos de programadores experientes e capazes de modelarem. E esse é o ponto onde não concordo. Talvez para usar 100% do potencial dos Métodos Ágeis (como fazer um refactoring a qualquer momento do desenvolvimento) é realmente necessário 100% da equipe formada por esse tipo de programador. Mas aqui estamos tentando uma nova abordagem, tentando aproveitar o potencial de programadores juniores também.
Concordo, em parte, com o seu post.
A definição das funções e cargos dentro da área de TI sempre foi muito confusa. Acredito que não necessitamos classificar essas funções, mas sim proporcionar para uma equipe de TI tudo que um perfil de profissional multidisciplinar tem a oferecer.
Quanto a parte de modelagem, descordo. Algumas afirmações feitas no post ( “Modele em código”) não podem ser tratadas de maneira genérica (para qualquer tipo de software).
Para sistemas comerciais simples, sites, workflows, processos de negócios, cadastros, relatórios… Também acredito que a necessidade de modelagem em UML (por exemplo), pode não existir (interessante é que, para sistemas assim, a MDA encaixa como uma luva!). Agora, sistemas mais complexos (exemplo: controle de refinarias de petróleo, controle de tráfego aéreo) e críticos (exemplo: sistemas de UTI de hospitais, controle automático de aeronaves, automatização industrial), apesar de serem raros para a maioria dos profissionais de TI, necessitam de modelagem prévia, e muitas vezes simulação, pois colocam em risco empresas inteiras, e em alguns casos, até vidas humanas.
Além disso, a modelagem UML depende muito do tipo de cliente que você atende. Existem licitações de órgãos públicos e grandes empresas que avaliam a proposta técnica através da modelagem do software em UML. Assim, não adianta você mandar o código-fonte para o pregão da licitação! Projetos assim envolvem muito dinheiro. A empresa que realiza a licitação precisa adquirir confiança na capacidade da empresa que será escolhida através da modelagem prévia do software.
Portanto, modelagem UML e simulações devem ser encaradas como uma ferramenta para o desenvolvimento do software. Muitas vezes são essenciais, outras não. Depende de que tipo de software você precisa fazer e de que tipo de mercado você atende. Modelar é a capacidade de antecipar, através de modelos formais ou informais, algo que ainda não existe no mundo real. Apenas os seres humanos têm essa capacidade. Eu prefiro utilizá-la em situações críticas e complexas…
Só não sei o que é pior:
- tornar gerente seu melhor desenvolvedor, perdendo um bom desenvolvedor e talvez “ganhando” um gerente ruim;
- ou tornar gerente seu pior desenvolvedor, tirando um pedra no sapato pra “ganhar” outra maior que é um desenvolvedor ruim achando que foi promovido pra gerente e que seu papel é ensinar aos outros desenvolvedores a desenvolver e quem sabe chegar aonde ele chegou.
Atire a primeira pedra do sapato quem nunca viu isso.
@David
Fiquei muito curioso agora: os seus recém-contratados, que não possuem capacidade -ainda- de modelar um softwar,e fazem o que? Observam os experientes para aprender o dia inteiro?
Se modelagem ágil é modelagem executável e essas pessoas não estão modelando sozinhas não entendo como isso pode funcionar. Pair programming?
Enquanto desenvolve o programador está modelando, se ele não modela é porque não desenvolve. No seu caso acho que está havendo uma confusão entre coaching/capacitação e papel dentro de uma empresa. uma coisa é ser junior/senior outra é ser ‘analista de sistemas’(sic) Atuar sobre supervisão e/ou revisão de alguém experiente é normal mas chamar o experiente de analista é criar um cargo que não existe.
@Matheus
Por que é preciso gerar um modelo gráfico não executável (i.e. UML)? Se estamos falando de sistemas com alto risco não é aumentar ainda mais este risco modelar o software utilizando uma ferramenta cujo resultado final 9diagrama) não pode ser sequer testado? Se existir a necessidade de haver um diagrama exportar um do código é simples, como o post afirma.
Qual a vantagem em modelar utilizando uma ferramenta não executável e não verificável?
Quanto à proposta técnica e licitação este é outro problema. É um problema no processo que está atrasado mais de dez anos (procure no Google por BDUF) mas é outro assunto.
Qual a vantagem de modelar em UML sem artefatos executáveis? Se eu tenho exatamente o mesmo nível de abstração em código para que eu preciso de um passo intermediário? Se eu posso gerar um modelo UML do código se precisar de visualização gráfica?
Simular é fundamental, concordo, mas como se simula um sistema modelado em UML? Como se verifica algo que não se executa, não se afere? Revisões formais por comitê?
Phillip,
Sobre promover um técnico a cargo gerencial sem que essa pessoa tenha competência pra isso, concordo que é uma grande furada!
Agora, me causa espanto alguém concordar que analista de sistemas não existe mais. Lamento informar, mas o que tem no mercado é analista incompetente. Um bom analista vai criar modelos e documentação de tal forma que não interessa a tecnologia que vai usar. Além disso, é importante que os documentos gerados sejam num nível muito mais abstrato que código, onde uma “pessoa comum” possa entender. Gerar código sem análise prévia é uma burrice MUITO grande!!!
Obs.: Não sou analista, mas não posso concordar com um absurdo desses. Cuidado, um projeto com um analista ruim é furada… sem ele, o projeto já nasceu MORTO!!!
Abraço
A intenção de modelar não está ligada a execução. Está ligado muito mais a antecipação do que será feito… se for feito! Modelagem (seja de qualquer coisa) ajuda a verificar a viabilidade, sem precisar efetivamente de qualquer implementação real. Antecipar o que queremos é benéfico.
Planejar, através de modelagem, não é ruim. Modelando com UML podemos antecipar algumas coisas da execução do software, sem necessariamente executá-la (apesar de já termos avanços com MDA e UML Executável). Isso é uma análise fundamental. Talvez uma das funções de análise de sistemas seja essa: antecipar, através de modelos, o comportamento de execução do sistema. Eu gostaria de ter um profissional assim na equipe.
Quanto as licitações, nosso processo pode estar atrasado, mas este é o nosso processo. Estou no Brasil e atendo clientes com esse perfil. Existe um grande mercado nessa área, que não podemos desprezar. Saber dançar conforme a música é uma capacidade que poucos têm… Alguns adoram modelar, e exageram focando apenas nisso. Outros, acham modelar uma perda de tempo, e preferem o código funcionando como resultado. Eu prefiro um híbrido dos dois. Pessoas são importantes, mas nem sempre trabalhamos com os melhores perfis. Portanto, prefiro ter controle de alguns projetos utilizando mais os modelos e planejamento.
“Se eu tenho exatamente o mesmo nível de abstração em código para que eu preciso de um passo intermediário?”. Não é um passo intermediário. É um passo de análise, independe de plataforma e linguagem. Não vejo isso como uma coisa ruim. Em muitos projetos, modelar antes ajuda até mesmo conversar com o cliente e ajudá-lo a definir melhor suas necessidades (participei de um projeto em que foi mais fácil explicar para o cliente o funcionamento de um web service com um diagrama de seqüência do que mostrando para ele código C#). Ajuda também a equipe prever a dificuldade de implementação, a necessidade de componentes e a definir uma arquitetura.
Quanto a simulação, podemos utilizar UML sim. Diagrama de Objetos, diagrama de atividades e principalmente diagrama de estados (num nível mais baixo, as redes de Petri) ajudam a simular o sistema. E um bom analista de sistemas pode fazer isso.
Na dissertação de mestrado que venho trabalhando, utilizamos UML para modelar um domínio qualquer, com suas entidades, predicados e ações. A partir desta modelagem, conseguimos gerar um plano de forma automática que, a partir de um estado inicial, consiga chegar a um estado objetivo (procura por ItSimple no Google). Por que não utilizar esse mesmo conceito com a execução de processos de negócio, dentro do domínio de uma empresa? BPM e BPEL estão estando ajudando bastante nesse sentido, facilitando o desenvolvimento de aplicações sem a necessidade de implementação.
Não podemos ser extremistas. Não existe apenas um lado com a razão. Temos que ser expertos e aproveitar o que há de melhor nos dois lados. Com eu já disse: modelar significa antecipar algo que não existe no mundo real, de maneira formal ou informal. Se você prefere modelar no código, ótimo. É um modelo formal. Se você prefere modelar com UML, ótimo também. Além de ser um modelo formal, é independente de tecnologia. Gostaria de trabalhar com uma equipe que tivesse profissionais com a capacidade de modelar diretamente no código. O custo seria bem menor e o resultado melhor. Entretanto, nem sempre temos as pessoas que queremos na equipe do projeto.
Phillip, aqui o pessoal “arquiteto-desenvolvedor” desenvolve o TDD e o pessoal que está aprendendo faz parte do “recheio” do código. Com o tempo esse pessoal junior começa a fazer os TDDs e entender o porquê daquilo. Junto vem a capacidade de “modelar via código”.
“Enquanto desenvolve o programador está modelando, se ele não modela é porque não desenvolve.”
Acho que o termo “modelar” é que esta poluindo a nossa comunicação. O meu “modelar” é aquele clássico, sem implementação de código. Talvez usando o TDD, mas também outros modelos. Se quem faz isso tem um cargo ou papel, não estou preocupado. O importante é que tenha o treinamento adequado para fazê-lo. E nem todo mundo o tem ainda.
Sobre o uso de UML, não sou fã não. Mas também não acho que podemos dispensar todos os gráficos e usarmos apenas código para nos comunicar sobre o projeto. Aqui vale a (re)lida do “There is no Silver Bullet” do Brooks, na parte que ele fala sobre a “invisibilidade” do software: “In spite of progress in restricting and simplifying the structures of software, they remain inherently unvisualizable, and thus do not permit the mind to use some of its most powerful conceptual tools. This lack not only impedes the process of design within one mind, it severely hinders communication among minds.”, ou seja, o código é só um ponto de vista de uma abstração mais complexa.
http://en.wikipedia.org/wiki/No_Silver_Bullet
Seria legal se fosse possível usar gráficos (pelo menos um diagrama de classe) no meio do código. Ou pelo menos no XMLDoc. :) Se eu conseguisse colocar pelo menos um diagrama do lado da explicação daquela classe complexa, já seria um grande avanço. Vou ver se faço um post sobre isso, com uns screenshot…
Aliás, fiz um post sobre o Specter, um framework BDD feito em Boo. Falo justamente sobre o que considero um mito das DLs: a facilidade de entender o código fonte.
http://cquesabe.blogspot.com/2008/01/dynamic-languages-leitura-de-cdigo-ou.html
Aproveitando o comment, gostei do ultimo post em inglês e a comparação com a arquitetura convencional.
E já valeu eu ter encontrado seu blog para podermos ter esse nível de discussão. Abs!
Tenho tantos comentarios que nao sei por onde comecar : )
Primeiramente, acho que o proprio fato de se pegar bons programadores e os promover para analistas de sistemas ou gerentes eh um caso classico do Principio de Peter (http://en.wikipedia.org/wiki/Peter_Principle), que afirma que as pessoas sao promovidas ate o seu nivel de incompetencia. Como resultado a empresa perde um bom programador para ganhar um gerente ruim!
Em relacao ao comentario do David, acho que o ponto sendo discutido nao eh esse. Conforme falei no post q criei para comentar esse, o problema de se ter analistas esta no sistema q foi criado, onde analistas modelam e programadores programam!
E isso so se reafirma com o que tu falaste. De que adianta tu contratar “pessoas com potencial”, se elas ficam dai hierarquizadas abaixo dos analistas, tentando aprender com a sabedoria que eles passam atraves de modelos UML? Coloca logo esses potenciais para modelar, se for o caso, junto com pessoas mais experientes que possam mostrar o caminho das pedras, e dai sim fazer todo mundo evoluir junto.
Um abraco,
Francisco
De que adianta eu
Ola Shoes aqui na empresa Analistas de Negocios estão realizando cursos para ter alguma capacitação de Analistas de Sistemas juro que não achei uma razao logica para isso
Nao deveria ser o contrario? , agora Analistas de Negocios poderão arquitetar sistemas ..
Uma amiga que esta participando deste curso que é formado em Computacao entende de UML e blalala me disse que os Analistas de Negócios nao entenderam bulhufas de UML a empresa esta criando um problema para ela mesma , creio eu.
Boa tarde a todos.
Venho lendo os posts e antes de mais nada acredito que este tipo de “discução” é um bom exercício, ajuda a construir opiniões e até nos faz enchergar coisas que sozinhos talvez não tenhamos observado.
Se me permitem um pitaco…
Só para constar trabalho como coordenar de desenvolvimento (acho que isso não faz diferença).
Falando de modelos…
Será que podemos mesmo dizer que TDD , UML, YYY ou ZZZ são legais sem levar em consideração o cenário ?
Será que vale a pena você modelar um projeto a tal ponto de consumir um percentual significativo de horas quando se tem um prazo curto e um “time to market” vital para o sucesso ou fracasso da empresa ?
E se for um banco (trabalhei em projetos no Itaú, CEF,NCNB e Bradesco) , onde nenhuma linha de código costuma ser escrita sem uma documentação rigorosa, será que é possível utilizar uma metodologia simples ? Já pensaram como seria escrever o sistema de Conta Corrente do Itaú utilizando apenas UMA metodologia ?
Não sei. Sinceramente não sei as respostas para as minhas dúvidas. A única certeza que tenho é que sem saber o tamanho do cachorro eu não sei quanto de ração vou gastar por mês.
Falando de cargos/ papéis e funções…
Sem querer polemizar (me perdoem se isso acontecer), mas um profissional que desenvolveu sistemas por muitos anos, para muitos tipos de business diferentes será mesmo que esse cara não tem competência gerencial ? Ou será que ele tem muita competência sim e precisa exercitar estudando , como um MBA por exemplo ?
Para ser um bom gerente, será que o x da questão é a atividade que o profissional exercia até então ou o perfil deste profissional, sendo competente para trabalhar sob tensão, gerenciar pessoas (e humores - isso é uma arte!) e assim por diante ?
Acredito que tudo é possivel. De programador à gerente existe um caminho sinuoso que não está ligado a atividade em si. Não é raro ouvir sobre casos de grandes administradores que cursam faculdade Psicologia…
Por fim, sob o meu ponto de vista, um programador pode sim se tornar um bom gerente em um cenário que ele se identifique.
Francisco,
Legal o Principio de Peter. É isso mesmo.
“Coloca logo esses potenciais para modelar, se for o caso, junto com pessoas mais experientes que possam mostrar o caminho das pedras, e dai sim fazer todo mundo evoluir junto.”
Quem me dera fosse tão simples.
Faz um teste: Pega um monte de gente que acabou de entrar na faculdade de Ciênc. da Computação ou nem terminou o colegial técnico e põe eles para modelar. Uma, duas, três vezes… não adianta. Nesse momento eles estão mais preocupados com a nova versão do framework e como implementar o novo grid. O que é natural. Com o tempo eles (e eu já estive lá) vão começar a olhar tudo isso com um olhar mais genérico e vão prender a se afastar “mentalmente” do código, da implementação. Isso não tem jeito. Leva tempo.
“…se elas ficam dai hierarquizadas abaixo dos analistas”
A idéia não é hierarquizar, e sim apoiar.
“Em relacao ao comentario do David, acho que o ponto sendo discutido nao eh esse.”
Acho que ficou meio off-topic mesmo…. :D
Abs!
@Matheus
Você está defendendo o papel de analista ou a modelagem em geral? Eu não falei nada contra modelagem, falei (1) contra a existência de uma pessa cujo papel é fazer isso e (2) contra o uso de ua linguagem gráfica não executável para isso.
UML é uma ótima maneira de comunicar idéias rapidamente, mas deve ser utilizado como Sketch (http://martinfowler.com/bliki/UmlAsSketch.html). Criar especificações minuciosas de como as coisas funcionam nesta linguagem além de ser iprodutivo não atesta nada. Clientes não validam UML, técnicos não testam UML. É apenas uma noteação gráfica.
Se tenho design e modelagem incremental, se tenho ferramentas de alto nível para programar e se tenho boas práticas de modelagem como Domain-Driven Design para que preciso de especificações funcionais em diagramas? O analista de sistemas antecipa o comportamento do sistemas mas como ele sabe que seu trabalho está correto? O papel do ‘analista de sistemas’ seria então ligado com BDUF? Eu acho que está e como BDUF é uma prática abolida…
Eu passei bons anos no mercado de consultoria brasileiro e fiz muitos projetos para o governo. Todos pediam BDUFs. Eu criei os diagramas que foram devidamente abandonados quando o projeto começou. Ponto. Não é porque o cliente exige que você use uma coisa que ela é útil. basta saber o que e para vender e o que é para fazer.
Seu cliente enende um diagrama de sequência porque ele está acostumado a entender fluxogramas, usamos isso o tempo todo no mundo real. O que ele não está acostumado é com classes e objetos, então UML não ajuda muito quando se comunia com o cliente. Da mesma forma, nada me impede de, modelando diretamente no código e/ou com sketchs UML, gerar em segundos com uma ferramenta gráfica ou não um diagrama de sequência baseado em um metódo, e ainda ter certeza que eu estou mostrando algo que funciona e não apenas um desenho que eu acho que serve. Qual a vantagem de se ter um analista de sistemas nisso? Qual a vantagem de criar diagramas UML antes do código?
Ok, você simula em UML. Como você verifica que a simulação foi bem-sucedida?
Eu não falei sobre o uso de notações gráficas executaveis (ou transformáveis) no desenvlvimento, falei do uso de uma notação gráfica intermediária, não transformavel e não executável. BPEL é executável e verificável.
Um modelo UML é independente de tecnologia exatamente porque ele não vai oferecer a completudo que se espera de um modelo detalhado. UML é ótima, como sketch.
E note novamente que existem diferenças entre modelar, modelar com UML e haver um analista de sistemas. Meu problema não é com a primeira e sim com as duas últimas.
@David
Vocês fazem Big-Test-Up-ront então?
TDD e um processo iterativo e nele os ciclos são muito rápidos. O proramador precisa estar apto à escrever um teste, escrever código, escrever outro teste, modificar os testes. Escrever testes e passar para um programador não é TDD.
@Rodrigo
@Rodrigo
Você está confundindo ‘analista’ com ‘análise’. De qualquer forma você realmente acha que uma pessoa não técnica entende um diagrama UML? Você demorou quanto tempo para entender o que é um objeto?
Burrice é ignorar décadas de avanço na área.
Também concordo que um Analista de Sistema não deve apenas modelar. Acredito que o perfil de um Analista de Sistemas seria o mesmo de um desenvolvedor sênior, com alguns anos e projetos de experiência. Portanto, esse perfil de profissional poderia ser o responsável pela modelagem do projeto e até mesmo pela sua simulação em casos críticos. Esse mesmo analista poderia ajudar na definição da arquitetura (será que vale um artigo com um título “Quando eu crescer, quero ser Arquiteto de Software”) e no desenvolvimento do software.
Como validar a simulação? Respeitando a palavra final do analista que faz a simulação, da mesma forma que aceitamos uma lógica de programação feita por um desenvolvedor (nem sempre tudo o que é compilado, está correto. No final, quem valida é um ser humano). Nos diagrama de estados (redes de petri) podemos fazer essa simulação até mesmo de forma matemática, vericando cada estados depois da execução de ações.
Quanto aos projetos feitos de acordo com licitações, nos projetos que trabalhei alguns artefatos foram mesmo deixados de lado, mas alguns deles (especificação de caso de uso, diagrama de classes e diagrama de sequencia, além de protótipos de tela) foram utilizados até o fim pela equipe de desenvolvimento e teste. Em algumas ocasiões (discussões e reuniões) esses documentos foram muito úteis.
Acredito nos modelos gerados pela UML. É fácil discutir com o cliente com um diagrama de casos de uso e um diagrama de classes de auto nível (modelo de domínio). Acho importante utilizá-la quando for necessário. Acho que não vale a pena entrarmos no mérito da qualidade e controle do que está sendo feito. Isso conseguimos com essas duas abordagens que estamos discutindo.
Essa dicussão a respeito deste post foi muito produtiva. Agora ficou claro que, muito mais do que seguirmos processos ou acreditar no potencial das pessoas, devemos nos adaptar a cada projeto.
Antes de mais nada, já vou avisando que na empresa em que trabalho tenho o cargo de Analista de Sistemas, mas minhas responsabilidades não faço análise somente :)
Concordo com o post. Sobre a questão “Analista de Sistemas” e “Programador”, acredito que o problema acontece porque existe uma corrente que insiste em separar o “pensar” do “fazer”. Assim, o Analista de Sistemas, com toda sua sabedoria e inteligência, concebe todo o sistema, que caberá ao Programador implementar, fazendo o papel de digitador de luxo. Na minha opinião, o pensar e o fazer estão interligados de tal forma que é muito difícil (para não dizer impossível) serem separados. Costumo olhar com desconfiança para Analistas que nunca programaram e para programadores que nem sabem o que estão fazendo. Atualmente, acredito que não há como ser somente Analista ou somente Programador, nos sentidos que essas palavras tinham até um tempo atrás. Acho que uma classificação que faz mais sentido atualmente é “Desenvolvedor”, alguém que mescle várias habilidades, entre elas análise e programação.
Sobre a questão de “evolução” profissional, acredito que o problema esteja relacionado ao fato das pessoas associarem “evolução” ao crescimento no organograma das empresas. O que muitas pessoas não percebem é que não é preciso galgar na hierarquia para crescer como profissional ou se desenvolver. Existem outras alternativas. De acordo com suas realizações no trabalho, você pode se desenvolver muito mais do que alguém que tenha ganho uma promoção de cargo. Infelizmente, acredito que na maioria das empresas, se uma pessoa não se importar em subir na hierarquia, ela é vista como acomodada ou como alguém sem “ambição”, o que não é muito bem recebido, quando na verdade a motivação dela se dá por outros meios.
Uma coisa que percebo é que a maior parte das pessoas querem ser chefes, mas não porque elas tenham perfil ou vontade de assumir as responsabilidades de um chefe (como desenvolver pessoas), mas pelo simples fato de “mandar” e pelo “poder”. A moda é ser “líder”. Ninguém quer colocar a mão na massa, que é considerado um tipo de trabalho de segunda classe , já saem da faculdade achando que merecem ser gerentes. Não sei se isso é um fenômeno do Brasil ou se é meio generalizado. Phillip, aí na Austrália como é esse aspecto?
Oi, Matheus,
Se o analista está mais para um desenvolvedor sênior porque criar este cargo? Por que gerar uma hierarquia que não existe de verdade? Todo desenvolvedor faz análise, sua experiência e competência diz o quanto ele tem autonomia.
Quem valida código não é humano. Décadas de engenharia de software nos deram ferramentas muito úteis: testes. O sistema quando pronto pode ser testado de diversas maneiras, incluindo homologacão formal com QA e cliente, mas enquanto o sistema está sendo desenvolvido nós utilizamos testes unitários para guiar e validar o design. Confiar que ‘compila então funciona’ não é aceitável. Dê uma lida sobre JUnit, NUnit, BDD e demais.
O ponto sobre ‘diagrama de domínio’ é muito interessante. Se você praticar boas práticas de design orientado a Objetos não deveria ter nenhuma diferença entre o diagrama de domínio e a implementação. Se você não tem diferença não precisa do diagrama. Dê uma lida sobre Domain Driven Design para entender a filosofia.
Phillip,
As vezes temos uma equipe com poucos desenvolvedores experientes. Nestes casos, desenvolvedores experientes podem modelar a solução para ajudar que os desenvolvedores menos experientes implementem o software. Enfim, percebemos que essa é uma discussão muito relativa ao projeto e a situação da equipe do projeto.
Em relação a validação do código: ferramentas de testes ainda não refatoram o código de forma inteligente (olha que eu já vi algumas coisas de Programação Genética: o software encontrando a melhor forma de fazer outro software com base no princípio da evolução). Nem sempre a lógica foi implementada da melhor forma, apesar de funcionar. Nem sempre temos o melhor modelo UML, apesar de atender os requisitos.
Quanto ao DDD: utilizamos aqui na empresa… eu também acredito e defendo esta ‘filosofia’. Acharia ótimo se todos os clientes/usuários entendessem modelos de domínio. Mas sabemos que não é bem assim…
Na França existe o GRAFCET. O GRAFCET é semelhante a um diagrama de atividades / estados. O Governo Francês o considera como principal documento para definição e validação dos requisitos do usuário, tanto que tem até valor jurídico. Lá, a modelagem prévia (que é feita de maneira incremental) do software é tão importante quanto a implementação. Para se ter uma idéia, o GRAFCET é ensinado nas escolas francesas desde o ensino fundamental.
Concordo que cada caso é um caso mas ainda defendo que você está criando uma hierarquia desnecessária. Do padeiro ao físico, todas as áreas lidam com aprendizes e sêniors sem problemas.
Não entendi quase nada do segundo parágrafo e, principalmente, não entendi o que você falou sobre ferramenta de testes azendo refatoração. Eu nunca vi uma ferramenta de teste que fizesse refatoração, elas não servem para isso.
Se você pratica Domain-Driven Design ter um diagrama de domínio 9citado no post anteior) é tão simples quanto extrair via engenharia reversa automática um diagrama das classes do sistema. Eu já fiz muitos projetos para todo tipo de empresa e não lembro de lugares onde não pudesse aplicar os princípios basicos de Domain-Driven Design. Com o que seus clientes implicam?
E porque o governo francês seria referência em alguma coisa relativa a desenvolvimento de sotware?
“Vocês fazem Big-Test-Up-ront então?
TDD e um processo iterativo e nele os ciclos são muito rápidos. O proramador precisa estar apto à escrever um teste, escrever código, escrever outro teste, modificar os testes. Escrever testes e passar para um programador não é TDD.”
Mais ou menos. Não é BDUF, seria mais um LDUF (L de Little) :D
A gente aqui só não segue as regras “by the book” em 100% dos casos. Mas como disse, alguns programadores-arquitetos aqui fazem dessa maneira o trabalho deles (Test + Refactoring). A outra parte é só o preparo da especificação (o test case) e espera pelo preenchimento. Sejamos práticos: muitas das partes de um sistema de business é commodity (CRUD, por exemplo), mas consomem um tempo considerável de desenvolvimento. Do ponto de vista de gerenciamento, o nosso programador-arquiteto é caro. Ou seja, existem lugares onde a mão de obra mais barata é bem aproveitada, além de treinarmos o recurso. Do ponto de vista da eng. de software, essas partes “comuns” do software precisam de poucos (geralmente um) ciclos de iteração pois o modelo já foi testado à exaustão.
Então você joga a ‘análise’na mão do mais experinte e a ‘implementação’ na mão do mais barato? Você está perdendo dinheiro em dois lugares:
1) Você não precisa do menos exeriente, demita-o. Se a especificação for minimamente útil ela vai ser exeutável e, veja só, seu ‘analista’já vai escrever código sem precisar do intermediário.
2) Se você tem problemas com CRUD certamente está usando tecnoloias e técnicas pouco produtivas. Considere reavaliar suas ferramentas, tenho certeza que pode eliminar o passo intermediário substituindo-o por algo mais eficiente.
De onde você tirou este ‘ponto de vista da engenharia de software’?
Phillip,
imagine uma ferramenta de teste que, além de validar a exicução do software, verifica se a solução foi implementada da melhor forma possível (sem gambiarras, por exemplo). Identificando isso, a própria ferramente de teste poderia refatorar o código… Nem sempre o desenolvedor escreve o código da melhor forma.
Geralmente, os clientes que tenho contato são pessoas que possuem uma verba disponível para implementar um software, e precisam usar essa verba de qualquer jeito, senão podem perdê-la. Além disso, clientes assim, muitas vezes, não possuem um conhecimento, nem mesmo básico, em TI.
Quanto ao GRAFCET, citei apenas para exemplificar o uso de modelos, para complementar nossa discussão. Se a França é ou não um exemplo a ser seguido na indústria de Software, é um outro assunto. A França é um país que possui uma cultura muito evoluída, e alguns dos maiores pesquisadores em Ciência da Computação estão lá.
E onde existe essa ferramenta? Existem barreiras seríssimas para que isso seja viável, pelo menos emg rande escala. Você consegue indentificar através de pattern matching e estatística algumas má-práticas mas não vai sair muito disso. para entender o porque ler sobre Intentional Software ajuda.
Sim, seu cliente não possui conhecimento básico em TI. Por isso que ele contrata uma consultoria e por isso que a consultoria deve atuar com maior profissionalismo e eficiência possível, eliminando passos intermediários inúteis.
A França não é referência mundial em desenvolvimento de software e, mesmo que fosse, governos são péssimas refer6encias quando estamos falando em eficiência e objetividade. Se a frança não é referência no assunto do debate não vejo porque foi introduzida, é como eu dizer que no Azerbaijão software precisa ter um selo holográfico.
Phillip,
pois é… essa ferramenta de teste não existe. Aí que está o ponto. Quem garante a qualidade do código? O desenvolvedor. Quem garante a qualidade do modelo? O desenvolvedor (ou analista de sistemas para alguns). Sempre em conjunto com o cliente. A validação da implementação ou da modelagem é muito mais humana do que pensamos.
Não entendi seu ponto. Você não precisa desta ferramenta para ter verificação da implementação, basta ter testes. Posso estar errado mas me pareceu que você disse algo como: ‘a ferramenta perfeita ainda não surgiu então não adianta usar ferramentas’.
A tecnologia atual já te da o suficiente, pode melhorar-é claro- mas te dá o suficiente. Ao contrário de modelos gráficos código -e modelagem ágil- é executável e verificável, como já repeti aqui algumas vezes.
O desenvolvedor, como qualquer profissional ético, faz seu serviço com boa-fé. Verificar a boa-fé é trabalho de testes unitarios, testes de interação, QA e métricas.
Ok.
Essa discussão não vai ter fim. Vamos parar por aqui.
Vamos continuar essa nossa discussão em outros posts, senão esta página vai ficar muito pesada para abri!
Phillip,
1 - Existem tarefas que consomem tempo e desmotivam os mais experientes: Fazer telas, fazer classes de serviços menos importantes, etc. Dependendo do sistema, isso pode consumir uma boa parte do tempo. Para os novatos, isso não é desmotivador, pelo contrário.
2 - Será? Ainda não encontrei nenhuma ferramenta que, por exemplo, monte telas baseadas em um determinado repositório, com um mínimo de customização. ActiveRecord não vale, muito pobre. Só vale ORMs de Hibernate pra cima.
Lendo seus blogs, vi que usa Ruby. Pelo que li e por raros testes que fiz, não estou convencido que essa linguagem (e outras DLs) vão resolver esses problemas.
“De onde você tirou este ‘ponto de vista da engenharia de software’?”
Nem te conto…. HA!
Sobre a discussão com o Matheus, vou adicionar uma detalhe a mais: se você conseguir mais de 60% do seu código testável via ferramentas, se considere com sorte.
http://cquesabe.blogspot.com/2008/01/mitos-sobre-os-mtodos-geis-unit-test-ou.html
E não me peçam evidencias. Nem métodos ágeis têm estudos suficientes mostrando o quão ágil eles são.
Mas veja bem Phillip, estou aqui para me mostrarem que estou errado. Tentando aprender e tentando achar soluções justamente para esses problemas.
E mudar para outro post não seria uma má idéia… :)
E ai Philip, tá curtindo a ThoughtWorks? Espero que sim…
Cara, o papo aqui tá rolando sobre PAPEIS x CARGOS, certo? Eu li o seu post e achei muito, muito legal.
Uma dúvida…
Na CPM você era arquiteto, certo? Na Globo.com, você era arquiteto, certo? Na sua apresentação em palestras você diz ser arquiteto certo? Agora, me diga, na ThoughtWorks tem esse papel de “arquiteto” bem definido? Como é que funciona isso ai?
Tô perguntado por curiosidade mesmo, porque está empresa é referencia, né?
Valeu cara, boa sorte!
@David
1 - ‘Classes de serviço’ não deveriam existir num projeto OO (elas até podem exsitir mas são minoria). Se estamos falando de fora da Camada de Negócios provavelmente você pode reaproveitar alguma biblioteca, se estamos falando de dentro me parece um problema de design. Pode elaborar?
2 - Eu não sei qual tipo de aplicação você desenvolve logo não posso te dar recomendações. So estou alertando que se isso for um problema você deve rever seus conceitos.
Ruby não é uma DSL e eu nem cheguei a recomendá-la neste caso exatamente porque não conheço seu problema.
Sobre coverage eu não entendi. Além de coverage não ser a única métrica de testes (você pode ter alta cobertura e péssimos testes) isso de menos de 60% simplesmente não é verdade. Pegue qualquer relatório de emma de um projeto open-source. O autor do artigo que voê linkou não parece conhecer muito sobre testes unitários ou sobre engenharia de testes em geral, vou comentar alguns pontos lá.
Agora me entristece saber que você não pretende mudar de opinião. Se você não debate e se questiona não evolui. A solução para seus problemas começa por questionar o que esta fazendo hoje.
@Philip
Acho que o David quis dizer que ele quer mudar de opiniao, afinal ele disse que esta discutindo para provarem que ele esta errado : ) .
@David
“Existem tarefas que consomem tempo e desmotivam os mais experientes: Fazer telas, fazer classes de serviços menos importantes, etc. Dependendo do sistema, isso pode consumir uma boa parte do tempo. Para os novatos, isso não é desmotivador, pelo contrário.”
No livro sobre Lean Software Development, a Mary Poppendieck fala exatamente sobre isso. Nao sao os programadores que nao gostam de testar, que nao gostam de documentar, etc… As pessoas que nao gostam de fazer tarefas repetitivas e burras.
Em relacao ao CRUD, é exatamente isso. Tem que se dar um jeito de eliminar (ou tornar eficiente ao maximo) a tarefa de criar esse tipo de funcao.
Em relacao aos analistas mais experientes, que eles usem essa experiencia magica q eles tem (o q pode ser visto como soberba) pra fazer isso muito mais rapido, ou pra desenvolver uma biblioteca que torne isso automatico.
Abracos,
Francisco
Phillip,
Concordo com tudo que vc falou no post. Só queria levantar um ponto. No pensamento Lean, uma das principais atribuições de um gerente é treinar e capacitar seus subordinados, que são as pessoas que trabalham na linha de frente. Para fazer isso bem, o gerente deve ter larga experiência na função desses subordinados, ou seja, deve ter trabalhado - e se destacado - nessa função. Sob essa ótica, o cargo de gerente pode ser considerado uma evolução natural de um cargo mais técnico. Obviamente, esse gerente é bem diferente de um gerente mais “tradicional” que estamos acostumados a ver por aí.
De qualquer forma, excelente post!
[...] não tenham perfil ou não gostem, escolhem ir para gerência ou são empurrados para isso ou para outros cargos. Isso rola sempre nas empresas de 3 [...]
Trabalhei em varios projetos em conjunto com Analistas, porem nunca funcionou; geralmente os analistas não realizam bem sua função e culpam que o programador não tem ideias de como melhorar o sistema.
Honestamente atualmente estou a procura de um metodo eficiente de levantamento de dados, pois não acredito que Analistas de Sistemas sejam a solução para tal.
E como essas fabricas de sw (ou outras ideias bizarras) fariam sem o papel do analista de sistemas?
A adocao de DSLs nao seria a solucao para o vacuo criado? Ou voCê tem alguma novidade por aí?