Desenvolvedores não pensam, desenvolvedores seguem casos de uso

Há algum tempo atrás eu participei de um projeto que se encontrava dentro de um processo absolutamente waterfall, para falar a verdade, a maioria dos softwares desenvolvidos aqui no mercado local seguem o processo em cascata, em sua grande maioria, através de fábricas de software. Bem, durante um certo dia na fase de codificação eu acabei tendo uma dúvida num caso de uso que me foi entregue, para ser mais exato a dúvida era em relação ao negócio da aplicação, ótimo, mesmo dentro de um processo em cascata ainda assim o analista de sistemas (negócios?) estava próximo da equipe de desenvolvedores, fui até ele conversar sobre o que não havia entendido no caso de uso, e ao debater com ele sobre o problema que não estava claro -pelo simples fato de não haver uma linguagem comum entre a equipe- eu ouço da boca do analista o seguinte comentário:

Para que tu quer entender isso? Desenvolvedores não pensam, desenvolvedores seguem casos de uso. Programadores só deveriam pegar o caso de uso, ler e seguir o que ele diz, nada mais. Não há porquê entender as regras de negócio, o caso de uso tem tudo que se precisa saber. Blah blah blah..

Wow! Depois de ouvir isso eu me calei por alguns segundos e pensei comigo mesmo, “Será que ele tem noção do que acabara de me dizer?”, e o pior é que este analista disse isso com uma certa arrogância, na frente de outros analistas (que calados pareciam concordar), logo começamos a discutir, eu tentando dizer que não havia fundamentos no comentário dele e que eu não entendia como ele acreditava naquilo.. depois de alguns minutos eu resolvi encerrar a discussão para evitar constrangimentos para ambos (pois estávamos no cliente).

Parece brincadeira, mas aquilo aconteceu mesmo (eu deveria estar realmente surpreso?!). Pergunto-me como em pleno ano da graça de 2008 um analista com anos de experiência em diversos projetos, formado em uma das melhores universidades do estado, e com certeza com mais alguns (ou até vários) diplomas e certificados debaixo do braço consegue verbalizar tamanha asneira. Mais incrível ainda é como um analista desses consegue acreditar tão fervorosamente que está certo, como ele consegue acreditar que um desenvolvedor é apenas mais um recurso comum para um trabalho manual, e facilmente substituível dentro da famigerada fábrica de software que ele tanto venera, alias, qual é a dificuldade em compreender que um programador não é um “digitador de luxo”? Será que depois de tanto tempo de profissão ele ainda não entendeu que desenvolver software é essencialmente um ato de criação? É, parece que não.

Um desenvolvedor mais do que ninguém deve entender sobre o negócio do cliente, um desenvolvedor deve estar mergulhado no negócio na qual pretende desenvolver o software ou parte dele, de fato, como será que este analista imagina que um desenvolvedor pode implementar algo minimamente decente sem entender o problema? Através da ajuda de alguma entidade sobrenatural?

No fundo, acho que ouvir isso de qualquer profissional no ramo de desenvolvimento de software é um absurdo, e para mim está óbvio que esta pessoa precisa urgentemente voltar a estudar sobre o assunto (pois ela parou de estudar há muito tempo, 10 anos talvez), e claro, mais do nunca ela precisa de uma “reciclagem”.

Engraçado é que este fato me fez lembrar de um acontecimento um tanto quanto embaraçoso interessante que ocorreu no inicio da minha carreira como desenvolvedor, há mais de 3 anos, eu possuía menos que um ano de experiência na época, e havia enviado o currículo a uma empresa que estava ofertando uma oportunidade para desenvolvedor Java, parecia uma boa empresa, depois de enviado o currículo eu recebi uma ligação alguns dias mais tarde para uma entrevista, na época eu fiquei super excitado, e parei para rever meu currículo cuidadosamente, ao reler o currículo vi que não sabia exatamente sobre o que se tratava 2 (dois) projetos na qual havia participado na primeira empresa que trabalhei, eu tinha uma vaga e distante idéia do que havia desenvolvido (em termos do negócio do cliente), mas ainda assim eu não conseguiria explicar a alguém (principalmente a quem fosse me entrevistar) sobre a finalidade dos projetos.

Então durante a semana, eu -na minha mais pura ingenuidade- enviei um e-mail ao meu antigo chefe (que além de ser um empresário, ele também era um talentoso desenvolvedor e amigo) pedindo informações sobre o que se tratavam os projetos que eu havia participado. A resposta dele não foi bem a que eu esperava [rs], porém me abriu os olhos na época. Alguns trechos do e-mail seguem abaixo:

De:rponte@gmail.com Para:boss

Fala amegão,

[…] Seguinte, tu pode me passar um resumo pequeno mesmo, porém decente das aplicações que eu participei ai na empresa para que eu possa colocar no currículo, pode? :))) […]
De ante mão eu te agradeço, abraços.

De:boss Para:rponte@gmail.com

Você não sabe pra que serviam os projetos que participou? rs Então não vale a pena colocar no currículo né? Você coloca que nesses projetos só fez programação pura.

Depois desse e-mail eu fiquei realmente envergonhado, vi que por mais que gostasse de desenvolver software eu não me interessava pelo negócio do cliente, eu não me interessava em entender e aprender sobre ele, o que sempre me interessava eram as tecnologias e os frameworks mais “hypes” do mercado. Entendendo como funcionava o mais novo framework da época já valia a pena estar desenvolvendo algo.

A partir dai, eu resolvi mudar isso, foi um processo lento mas contínuo, graças a certos amigos, blogs (Shoes, Guilherme etc), discussões em listas e fóruns, e muitas linhas de código mal implementadas (claro, como eu poderia implementar algo decente sem entender o problema?) eu procurei compreender sobre o problema do cliente e como expressa-lo em código, eu procurei ler sobre metodologias agéis, abordagens e boas práticas de design de software, maneiras de melhorar a comunicação entre os membros da equipe e várias outras coisas que me ajudaram e me ajudam até hoje.

Depois de tudo que eu estudei e procurei aprender eu ainda tenho que ouvir de um analista que eu não preciso entender sobre o negócio do cliente? Ah, por favor, eu não sou um “programador” que não pensa e simplesmente segue algumas folhas de papel com vários diagramas UML e fluxos alternativos escritos por analistas de sistemas, eu -como desenvolvedor- devo estar tão próximo do negócio quanto for necessário, mas isso é bem complicado quando trabalhamos num modelo em cascata em que a comunicação entre os membros da equipe ocorre através da troca de documentos e diagramas, e pior, quando trabalhamos com “profissionais” que acreditam que isso funciona.

Enfim, já basta os softwares bolovos e sem testes que temos que manter, já basta os processos burocráticos que temos que participar, já basta estarmos rodeados de fábricas de software e code-monkeys preguiçosos, já basta a desvalorização e os péssimos salários pagos aos desenvolvedores, e agora me vêm com analistas de sistemas retrógrados (oops!, pareço redundante) ? Por favor, me perdoem, mas as vezes acho que o mercado local está caminhando para trás quando se fala em desenvolvimento de software, mesmo conhecendo algumas poucas empresas, grupos e bons profissionais dispostos a mudarem isso.

44 thoughts on “Desenvolvedores não pensam, desenvolvedores seguem casos de uso

  1. É Rafael, infelizmente isso acontece muito. O pior é que essas pessoas com o tom arrogante não se interessam nem por estudar um pouco mais sobre a profissão delas. Já cansei de ver “gerentes de projetos” que não sabem nem o que se propõe o desenvolvimento ágil, ou mesmo iterativo-incremental em geral. São pessoas que fizeram a cadeira de Engenharia de Software na faculdade, um ou outro curso de PMP, RUP, Levantamento de Requisitos ou algo do tipo e acham que podem parar no tempo. E o pior não é nem o fato desses caras existiram, é a cegueira deles e principalmente de quem os contrata. Tomara que nosso mercado local um dia chegue a um mínimo de nível de maturidade para que coisas assim não sejam tão comuns. Parabéns pelo post.

  2. Até que fim você escreveu esse post. Estou pensando em copiar o seu post e colar no meu blog, modificando apenas algumas palavras. São tantos posts de excelentes blogueiros e profissionais da área que estão em atualização constante que eu me pergunto: será se vale a pena bater sempre nessa mesma tecla?

    Eu acredito que sim, pois pelo menos os desenvolvedores irão ler esse tipo de post, assim como leram os posts do Shoes, do Guilherme e de outros profissionais “atualizados”. Na verdade, como você mesmo mencionou, esses profissionais não se atualizam, então não conhecem a febre e a vantagens de blogs, que nos dias de hoje são o melhor local para se atualizar.

    Estou fazendo uma disciplina de Engenharia de Software e o conteúdo da disciplina basicamente é escrever documentos. Não culpo o professor, até porque o conheço e sei que ele é bom. Eu culpo a forma com que a academia e o mercado engessaram o estilo de ensinar Engenharia de Software, pois todo mundo está careca de saber que os alunos precisam ir além da faculdade, precisam ser auto-didatas e não passar informações que estão desatualizadas, jogando no mercado esses analistas de sistemas. O modelo interativo do RUP não é waterfall, mas a maioria das empresas insistem em fazer com que seja. Portanto, a academia pode ajudar o mercado fazendo com que a sua grade de disciplinas que circundam a análise de sistema mude de cenário, para melhor.

    A internet (em blogs) está repleta de casos de sucesso com a inclusão de métodos ágeis, então, você, analista, leia, se atualize e veja que o cenário está mudando, já! Primeiro, leia o blog inteiro, de cabo a rabo, do Vinícius Manhães. Depois, acesse (diariamente) blogs como o do Shoes, do Guilherme, do Yoshima e outros.

  3. É Ponte, é difícil. No trecho que você tenta descrever “como o analista pode ser tão arrogante sendo que estudou numa universidade excelente, fez diversos cursos, etc…” você já explicou por que ele é arrogante. Falta humildade nesse ser, e isso acontece em qualquer área, não só na nossa.
    Mas é engraçado seu post, pois no meu ver, o principal problema dos desenvolvedores que sempre convivi, é que tem muita gente que nem se interessa pelo problema que está tentando solucionar, as vezes ao entender um problema vemos que o posicionamento de um botão faz toda a diferença, que ele não faz sentido nenhum onde está.

  4. Slap, slap, spla(palmas).
    Desceu uma lágrima agora, você ta ficando bom nisso de blogar :D.

    Cara é realmente até revoltante, mas vejo uma razão das várias que existem.

    O Analista está preso no tempo, no tempo de projetos em cascata, ele acha que o Caso de Uso dele é perfeito, que expressa tudo que tem que ser feito. Mas ele esquece de um detalhe, ele não sabe programar 😀 e ele não pensou em tudo.

    Observe que 99% dos analistas não programam, não tem idéia as vezes nem da plataforma que o projeto dele participa(lembra daquele projeto ?), tudo bem, UML não é para ser voltada a plataforma, mas ora, isso poderia ajudar e muito, até para ele mesmo.

    Esse pensamento IDIOTA que programador deveria apenas seguir o caso de uso é algo até estúpido de dizer, me dá até vergonha de repetir.

    Agora sabe o que seria interessante, já pensou se realmente fizermos isso ? Se realmente fizessemos tudo que está no caso de uso exatamente como está sem “pensar” e corrigir as asneiras que SEMPRE tem no caso de uso ?

    hauhauhauahua iria ser show, os projetos iriam duplicar de tempo, atrasar, e sempre estaríamos fazendo “alterações” e pra variar o analista ainda iria culpar o desenvolvedor(isso te lembra alguém ?).

    É, o mercado de fortaleza tem que se ATUALIZAR, temos vários gerentes e vulgos analistas que precisam urgentemente voltar a estudar, é uma VERGONHA.

    O que me deixa mais revoltado lendo seu post é tentando imaginar a cara e a forma como esse vulgo analista deve ter falado para você, quanta arrogância, prepotência e BURRICE juntas, meu Deus.

    Mas isso é bom ponte 😀 concorrente a menos :D, por isso sempre crescemos, além das nossas capacidades, a maioria dos nossos concorrentes, são esse tipo de “profissional”, é até covardia :D, é nessas horas que vejo como estamos adiantados aqui, e como devemos nos valorizar ainda mais.

    Abraços e belo post.

  5. Engraçado, passei anos sendo chamado de intolerante, agressivo, xiita, arrogante e mais alguns adjetivos tão lindos porque sempre entrei dando chute na porta contra esse tipo de profissional. Contra essa mentalidade, contra esse atraso, contra esse tipo de gente… anos lutando sozinho no CEJUG e em outros grupos. Passo a bola, continuem…

  6. So uma coisa a dizer.

    Ótimo post.

    E o pior é que isto é extremamente corriqueiro em nosso dia dia. Mas, so uma coisa da a real lição a profissionais desse tipo… o tempo!

    []s

  7. Excelente post Rafael,

    sempre vejo esse tipo de engessamento, mas por ambas as partes: Analistas e Desenvolvedores (não por todos, é claro).

    Muitas vezes o desenvolvedor pouco questiona o négocio e o analista sente-se confortavelmente bem para detalhar seus casos de uso enquanto não é questionado a respeito deste.

    O envolvimento de todos no projeto é essencial para a evolucao do processo :)

    abraços!

  8. Uma das minhas maiores esperanças é que pessoas com sua mentalidade chegem logo aos cargos de gerência das empresas. Ou até mesmo criem empresas baseados nessas experiências.

    Força sempre !

  9. Muito bom! Acredito que o DESENVOLVEDOR precisa ser melhor reconhecido pelo que faz. As qualidades de software mais comentadas, tais como reusabilidade e manutenabilidade( so para citar algumas), são efetivamente colocadas em um software atraves do gerente do projeto? do analista de negócio?
    Na concepção do software temos uma equipe e todos tem um papel fundamental no produto final.

    abraços

  10. Infelizes os que tem que aturar isso diariamente…

    Incrível como ainda tem gente ignorante quanto as vertentes da engenharia de software.

    Tudo bem que equipes devem ser divididas, e cada qual ter suas responsabilidades, mas ficar alienado quanto ao fim/uso do que se vai fazer é um absurdo.

    Eu acho que o fato de se chegar a Analista de Sistemas deveria implicar diretamente que se sabe programar, ou ao menos bem familiarizado com o processo, para que se possa desenvolver um bom trabalho.

    Imagino que se deveria seguir uma hierarquia onde um programador/desenvolvedor foi promovido, ou então foi contratado diretamente para Analista de Sistemas baseado em experiências prévias adquiridas em vários processos de desenvolvimento de sistemas, incluindo a programação.

    Como foi dito na palestra de Maurício, ninguém pode chegar do nada e simplesmente ditar a um programador o tempo exato que se levaria para criar uma classe ou qualquer outro requisito, afinal de contas, quem vai saber exatamente como se faz e o quão complicado se torna chegar ao resultado final é ninguém menos que o próprio programador.

    No máximo, um Analista de Sistemas bem familiarizado com o processo de desenvolvimento poderia estipular um determinado tempo baseado em suas próprias experiências como programador.

  11. Obs.:

    Por “Palestra de Maurício” quis dizer uma palestra sobre Processos e Pessoas, apresentada por Maurício Linhares, co-fundador do PBJUG – Paraíba Java User Group.

    Este post foi citado por Milfont no grupo :)

  12. Esqueceu de dizer pra esse analista que vc participa do mesmo projeto o tanto quanto ele??

    Vamos supor(bem hipotético) vc é um mecânico, e precisa instalar um sistema de ar-condicionado no carro do cliente e seu chefe escreve um documento dizendo os passos para se fazer isso. Supondo agora que vc descobriu, na hora da instalação, que o modelo do ar ao qual vc teve que instalar não é compatível com o modelo do veículo. Vc vai ao seu chefe e diz: “Nao entendo como isso aqui tem q ser instalado. Não cabe no veículo do cliente! Preciso entender melhor o que ele quer!”. E como resposta o seu chefe diz: “Quero nem saber, apenas faça como ta escrito no documento e deixe funcionando. Isso não faz parte do seu trabalho.”. Aí vc: “Tudo bem.”. E isso cheira a que?? Gambiarra aqui, Gambiarra ali… Pronto!! Funcionando… Um mes depois chega o dono do carro esculhambando a sua empresa dizendo que o carro deu prego, pois deu um curto-circuito com uma outra peça e o conserto vai custar muito caro!.. Quem vai ser o culpado??? Quem paga a conta??

    Será que o mecanico nao precisa tb saber das necessidades do cliente e indicar uma melhor solução para ele?

    Isso aí é mentalidade idiota, de quem quer ser o sabidão e na realidade não sabe P**** nenhuma!

    Parabéns pelo Post… Abraço Ponteenho

  13. Muito bom.
    Me lembra uma frase que eu vi um alguém dizer uma vez para um estudante trazia uma sugestão inteligente:
    – Você não está aqui pra pensar, você está aqui pra obedecer.
    No caso, era um militar old-school. Mas isso é um paralelo.
    Abraços.

  14. Parabéns Ponte. Excelente post!
    E parabéns Handerson! Excelente post “incrustrado” em comentário de blog. 😀
    É triste implementar (digitar?) código sem saber a finalidade.
    Acho que o próprio analista que deveria se preocupar com isso. Acho que ele quem deveria querer e gostar que o desenvolvedor tenha conhecimento do negócio. Ou ele pensa que é perfeito? Ele não está interessado na QUALIDADE? Isso exite pra ele? Pelo visto… não! Dessa forma, como ele pode se denominar um analista?
    Se EU fosse um cliente, odiaria saber que quem está desenvolvendo a minha aplicação é alguém que não entende do negócio.
    Existe VÁRIAS peculiaridades de uma aplicação que só um desenvolvedor conhecendo bem as regras de negócio pode validar como prontas para uso.
    []s.

  15. Antigamente queria até ser um analista, hoje percebo que não passa de um repasse de trabalho para o cliente, e no final das contas não há uma colaboração real direta dentro do processo de construção a partir da arquitetura definida.

    Passei por estas situações e outras e dentro do triângulo amoroso, desenvolvedores x analistas x gestores, a maior resistência estão por parte dos gestores, e posteriormente analistas entenderem que é necessário identificar os aspectos de mudança que favorecem o processo de desenvolvimento.

    Não adiata eles quererem escolher e definir tudo, deve-se existir um trabalho de colaboração para que a própria equipe que irá executar aquela iteração do projeto que escolha a melhor forma de ser implementada. A equipe deve-se ajudar por completo e não um repasse de processo desacordado com diversos artefatos com coisas a serem corrigidas, ajustadas, especificação inconsistente, e por aí vai.

    Uma apresentação que presenciei de Maurício Linhares do PBJUG sobre processos ou pessoas mencionavam aspectos de desperdícios, e estes e outros que acredito você não ter citado, são verdadeiros e acabam como um custo e impactam na qualidade do produto/serviço.

    Parabéns e não desista!!!

  16. Eh mesmo concordo ….
    Eh retrógrado alguns comentários como o exposto e ateh depreciativo para a figura do Desenvolvedor também.
    A mentalidade de muitas pessoas eh realmente de naum valorizar o desenvolvedor … e ateh se cria a cultura de que um desenvolvedor precisa se tornar um analista para se reconhecido ou mesmo respeitado na equipe, que o desenvolvedor eh desenvolvedor pq naum teve opções ou pq naum tem qualificações pra analista de sistema.
    Acredito, e tento, entender do negócio antes de desenvolver. Isso gera segurança no que faço e qualidade de software.

    ótimo post Rafael,
    :)

  17. Pow Rafael, realmente excelente post! Parabéns! Tomara que você não sofra represálias… 😀

    Espero que essa mensagem chegue aos analistas que seguem esse tipo de filosofia.

    Acho que seu post serve tb não só como reflexão para os analistas mas também para todos nós desenvolvedores que precisamos criar o hábito de ENTENDER do negócio do sistema. Como você citou, também já participei de projeto que eu não sabia nada sobre o que ele se propunha a fazer. Mas será que a culpa foi só do analista? Nesse caso, eu tenho certeza que não (talvez uma exceção :)) .

    Grande Abraço,

  18. Parabéns pelo Post, Rafael.

    Você soube com maestria expor um problema que, como podemos notar em quase todos os comentários, é conhecido de todos aqui. Então, acho que não temos com que nos preocupar ou revoltar… Esses Analistas, com o perfil descrito por você, estarão naturalmente fadados a desaparecer à medida que as técnicas de Engenharia de Software se modernizam e cheguem nas empresas.

  19. Os desenvolvedores são pessoas de alto intelecto que se aprofundam no conhecimento das tecnologias usadas pra desenvolver softwares, entender o negócio é fundamental para encontrarmos incoerências no projeto, que geralmente não são visíveis pela análise (como por exemplo limitações tecnológicas). Já executei analise de requisitos junto a clientes, e também projetei sistemas os quais também desenvolvi, e pude perceber que conhecer as tecnologias envolvidas é fundamental para uma boa análise. A soberba derruba um homem dos mais altos lugares.

  20. Rafael, muito legal sua iniciativa em divulgar este tipo de coisa muito comum na nossa profissão. O que mais me entristece é que estes relatos continuam acontecendo, ou seja, nossos “superiores” não conseguem aprender com os próprios erros e ainda continuam pensando da mesma maneira waterfall.

    Se tiver tempo dá uma olhada no nosso blog (http://1up4dev.org/) que tem alguns relatos sobre waterfall e algumas dicas sobre agilidade também.

    []’s

  21. Cara, que história sinistra! Isso me lembra o século passado de 1998 (rs). De tão incrível acontecer isso hj que me parece um filme de ficção científica de volta no tempo!

  22. Sensacional ! Parabéns pelo post !

    Seguindo a linha do “[…] Desenvolvedores não pensam, desenvolvedores seguem casos de uso. […]”, eu já cheguei a escutar, de consultor “renomado” aqui em Sampa que, “desenvolvedor tem de montes por ai, é só balançar a arvore que cai um monte” … Depois dessa, aproveitei pra acordar pra vida, e acabei seguindo o mesmo “processo” (amigos, blogs, livros) que citou !

    Sucesso!

  23. Para mim simplesmente, esse tipo de resposta do analista, quando é uma pessoa arrogante faz isso, quando é uma pessoa política simplesmente dá aquela resposta vaga tipo adivinhador do futuro, mas dá pra perceber que, ou ele não soube te explicar, ou não você o colocou em uma posição incômoda(para ele) por não saber te responder. Quem é já passou por esse problema sabe que tem pessoas que simplesmente não sabe dizer que não sabe e preferem rebaixar as pessoas que o perguntam a procurar a resposta, que pode ser crucial para o término do projeto. Não tem nada haver com formação, certificação o diplomas e reconhecimento, tem haver com o caráter da pessoa em querer melhorar, o fato de ser analista antigo pode demonstrar isso

  24. Muito bom Rafael, excelente.
    Espero que muitos e muitos Analistas vejam esse seu post e no fundo de suas almas descubram as besteiras que andam falando por ai. É impressionate que em todo e em qualquer lugar (nao so em Fortaleza) existam profissionais desse tipo. Entao meu amigo, vc nao esta sozinho e graças ao mundo bloggers temos uma arma fundamental para combater esses tipos de Heresias.

    []’s

  25. Parabéns pelo post Rafael!
    Na empresa que trabalho eles nos obrigam a entender as regras do negócio…rs…tivemos até que tirar uma certificação do google e tals, mas ja foi diferente em uma gestão anterior, com certeza entendendo as regras do negócio podemos desenvolver melhor.
    É triste saber que para alguns “profissionais” somos meros “programadores de luxo” como disse.

    Abraços,

  26. Muito bom o post, já passei por isso.. Hoje em dia estou mais profissional neste aspecto. Acho que na vida o maior problema é sempre acharmos que estamos certos, onde na verdade a convivência é a essência de tudo. Saber entender o limite mental das outras pessoas é saber respeitar e conviver com elas amistosamente, se você não respeitar este limite as pessoas podem tomar como uma afronta e acaba virando um problema de convivência para todos.. seja a pessoa um analista, ou outro desenvolvedor, um gerente ou chefe.. Saber lidar com o conhecimento e não estrapolar no comportamento diária é um exercício afterwards, sacou?

    Continue estudando um dia você será recompensado, nunca o resultado pode ser imediato.. tem que ser no tempo de casa.. carreira e vida.

    Abs,

  27. Discordo de várias afirmações tuas.

    Primeiro de tudo, quando um profissional é ruim ele não é parâmetro. O analista que tu citaste não sabe o que está falando, não sabe sobre processo e não sabe modelar.

    Outra coisa é que mesmo com a modelagem o implementador (isso em processos prescritivos e não em agéis) ele vai conceber a aplicação com base nos requisitos funcionais, mas dando soluções de acordo com o seu conhecimento e experiência. A documentação e um processo prescritivo não tem nada haver com a questão do desenvolvedor não pensar.

    Na verdade essas opiniões como a tua que foi expressada aqui acontece por falta de implementação de modelos de processos corretos. Com certeza nesta instituição que citaste o processo não funciona da maneira que deveria funcionar. O ideal realmente seria o implementador ter o mínimo de esforço pra enteder o negócio e os requisitos funcionais e implementar de acordo com as melhores técnicas e da melhor maneira possível. Esse é o objetivo da documentação/modelagem. No momento que o implementador não entende a documentação e o negócio, a documentação está mal feita ou há furos no processo. E tudo isso não tem haver com o processo cascata, só em instituições que utilizam este processo.

    Trabalho em uma fábrica caso queiras qualquer relato sobre como funciona aqui posso passar. Aqui, com certeza, os implementadores conhecem o negócio e participam ativamente da concepção da solução, mesmo sendo um processo prescritivo.

    Mas enfim, acho importante relatos como este teu.

  28. Vamos por partes…

    1) A arroância é inerente às pessoas, também já conheci desenvolvedores com ego maior que a fábrica de software, onde repetiam aos 4 ventos que não precisavam de caso de uso, nem de qualquer outra documentação, que eles eram os tais, e que o projeto não precisava de mais ninguém, além deles. Resumindo, não atrele arrogância ao analista, e sim àquela pessoa específica. Isso também vale para gerentes de projeto. Todos, desde o cara da limpeza até ao diretor da empresa, devem ser humildes. Todos devem admitir seus erros e suas limitações.

    2) A burrice tb é inerente às pessoas, também já conheci vários analistas que são burros… isso mesmo… burros… que não têm competência na escrita o suficiente para elaborar uma documentação decente! Pois é claro, se há mtas dúvidas, é pq o caso de uso não foi detalhado o suficiente, isso é óbvio. A incopetência pode ser técnica também, o analista pode “achar” que conhece alguma metodologia, mas não conhece, pois todo processo/metodologia/boa_prática sempre tem uma atividade/tarefa/procedimento que é tipo uma “reunião de entendimento do caso de uso” com todo mundo (projetistas, desenvolvedores, analistas de teste, etc.), justamente com o objetivo de dirimir estas possiveis dúvidas que possam surgir, pois, por mais perfeito que seja o caso de uso, ele sempre terá alguma “falha”.

    Então, caro Rafael, na minha opinião, vc deu azar de pegar um analista burro e arrogante em sua trajetoria profissional. Isso acontece mesmo. Paciência, né?! Eu imagino que o mercado inteiro não esteja assim, espero que isso seja exceção, pq se não for, estamos perdidos. :)

    []’s
    Ronald.

  29. já faz 1 ano do post,
    e hoje mesmo, estou passando por isso.
    Não que nunca isso tenha acontecido,
    mas acho essa situação insustentável, de que vários analistas pensem dessa forma.

    Ainda existe um agravante: até o “scrum master” pensa assim!
    Mas ai já é outra história.

    Pode apostar, eu como desenvolvedor não vou aceitar isso.
    Comportamentos como esse com certeza levarão qualquer projeto ao fracasso.

    Uma coisa é verdade: ganhamos muitos inimigos quando queremos trabalhar direito. irônico, não…

  30. Cara, não participo ainda de uma equipe…. mas na boa, espero não ter que ouvir isso um dia e se meu rumo for outro, já sei o que não devo falar, pensar, etc…

Leave a Reply to Rodrigo Panachi Cancel reply

Your email address will not be published. Required fields are marked *