Conselhos de um velho programador antissocial e ranzinza

Excelente a matéria! A vida é maior que TI.

Também sempre vejo por esse lado para quem trabalha com sistemas de informações, focar para atender o cliente/negócio, evitando “complicações bonitas” de TI a qual sejam desnecessárias. Quanto menos problemas melhor.

Importante também a análise/desenvolvimento mais humanizada, orientada mais a parceria do que “siglas”. Buscar a cultura de manter uma equipe de confiança ao invés de buscar confiança mais em siglas. Por outro lado, as siglas são bem vindas quando realmente ajudam para o resultado real. Enfim, importante são todas as partes buscarem harmonia para um dia a dia feliz. O código é só “um meio” do que esperam de nós.

javaflex:

Excelente a matéria! A vida é maior que TI.

Também sempre vejo por esse lado para quem trabalha com sistemas de informações, focar para atender o cliente/negócio, evitando “complicações bonitas” de TI a qual sejam desnecessárias. Quanto menos problemas melhor.

Importante também a análise/desenvolvimento mais humanizada, orientada mais a parceria do que “siglas”. Buscar a cultura de manter uma equipe de confiança ao invés de buscar confiança mais em siglas. Por outro lado, as siglas são bem vindas quando realmente ajudam para o resultado real. Enfim, importante são todas as partes buscarem harmonia para um dia a dia feliz. O código é só “um meio” do que esperam de nós.

Acho que você e o Erick estão falando de coisas diferentes.

Impossivel:

javaflex:

Excelente a matéria! A vida é maior que TI.

Também sempre vejo por esse lado para quem trabalha com sistemas de informações, focar para atender o cliente/negócio, evitando “complicações bonitas” de TI a qual sejam desnecessárias. Quanto menos problemas melhor.

Importante também a análise/desenvolvimento mais humanizada, orientada mais a parceria do que “siglas”. Buscar a cultura de manter uma equipe de confiança ao invés de buscar confiança mais em siglas. Por outro lado, as siglas são bem vindas quando realmente ajudam para o resultado real. Enfim, importante são todas as partes buscarem harmonia para um dia a dia feliz. O código é só “um meio” do que esperam de nós.

Acho que você e o Erick estão falando de coisas diferentes.

javaflex:

Blz, entendi na frase citada que ele quis valorizar mais o atendimento ao cliente do que ficar só em itens de TI.

usuário != cliente

Atender o cliente é justamente o que faz as pessoas focarem em frameworks, DAO super genérico, etc.

Pelo menos foi o que entendi… rs

Ele tem 34 e já se intitula velho e ranzinza? Vish, me ferrei.

Impossivel:

javaflex:

Blz, entendi na frase citada que ele quis valorizar mais o atendimento ao cliente do que ficar só em itens de TI.

usuário != cliente

Atender o cliente é justamente o que faz as pessoas focarem em frameworks, DAO super genérico, etc.

Pelo menos foi o que entendi… rs

Pois é, para TI somos bem velhos.

javaflex:

É, esse entendimento pode variar para cada tipo cenário. No meu caso por exemplo o gerente do Negócio é o cliente, que além de liberar verba e demandar necessidades, é um dos principais usuários do sistema.

Ele esta dizendo que é importante se colocar no lugar do usuário focando no produto. Como você concilia o fato de que no seu caso não existe produto, mas prestação de serviço?

Impossivel:

javaflex:

É, esse entendimento pode variar para cada tipo cenário. No meu caso por exemplo o gerente do Negócio é o cliente, que além de liberar verba e demandar necessidades, é um dos principais usuários do sistema.

Ele esta dizendo que é importante se colocar no lugar do usuário focando no produto. Como você concilia o fato de que no seu caso não existe produto, mas prestação de serviço?

javaflex:

Pela parceria, por exemplo a análise da experiência de uso do processo junto ao cliente.

Não entendi. Que parceria seria essa?

Impossivel:

javaflex:

Pela parceria, por exemplo a análise da experiência de uso do processo junto ao cliente.

Não entendi. Que parceria seria essa?

javaflex:

Impossivel:

javaflex:

Pela parceria, por exemplo a análise da experiência de uso do processo junto ao cliente.

Não entendi. Que parceria seria essa?

Ao invés dos analistas/desenvolvedores ficarem sempre isolados recebendo demandas, quando possível eventualmente participar do processo do usuário, buscando melhorar a experiência de uso pelo feeling real, além de agregar para Negócio.

entendi. de fato, focar em produtos só é um “diferencial” pra quem trabalha com produtos. quem trabalha com prestação de serviço faz mais sentido focar nos processos e ferramentas usadas pelo mercado, do que em produtos e usuários que como vc disse, tendem a ficar em segundo plano.

ErickRAR:

Você precisa, antes de tudo, mudar o seu foco para produtos. Pensar em soluções simples para problemas existentes. Pensar em interfaces, em interações, em processos. Pensar na experiência que o seu usuário vai ter no seu sistema/aplicativo. Isso é uma coisa que pouquíssimos desenvolvedores fazem: se colocar no lugar do usuário. E isso é um grande diferencial.

Ótimo texto para refletir. Pararmos de pensar um pouco em framework, DAO super ultra genérico e pensar mais nos usuários.
Muitas pessoas param de mexer em uma função apenas por estar funcionando, não importa como esteja. Mesmo que o usuário tenha um trabalho enorme para utiliza-la.

Texto completo:
http://gizmodo.uol.com.br/conselhos-de-um-velho-programador-antissocial-e-ranzinza/

O que uma coisa tem a ver com a outra?

O cliente é sempre o foco principal e a única coisa que importa, mas desenvolver software vai muito além de fazer uma telinha pro fulano usar. Cada parte do desenvolvimento precisa estar redonda para que o tal foco no usuário não passe de conversa fiada.

A escolha de um framework pode ser decisiva para para um produto de qualidade no prazo e no custo esperado pelo cliente. E isso é se colocar no lugar do cliente. Saber diferenciar se é melhor optar por algo próprio ou utilizar algo já existente é se por no lugar do cliente e avaliar qual dessas decisões fará o melhor produto em menos tempo.

Se utiliza ou não tal ou tal padrão, quando usar, quando não usar, qual usar para cada caso tem impacto no produto final, e principalmente na manutenção e melhorias desse produto, então de novo o usuário é o centro das decisões, mesmo as mais técnicas e aparentemente distantes do usuário.

Esse “que se danem os padrões e vamos focar no usuário” dá medo, até porque essa é uma das principais desculpas que eu já vi pra sistemas mal feitos, difíceis de manter e bugados. “Ah, vc acha que o cliente se importa com pattern?” Lógico que ele não se importa, mas quando ele descobrir que algo que leva uma semana pra ser feito poderia levar um dia, e com qualidade melhor, ele vai começar a se importar.

YvGa:

ErickRAR:

Você precisa, antes de tudo, mudar o seu foco para produtos. Pensar em soluções simples para problemas existentes. Pensar em interfaces, em interações, em processos. Pensar na experiência que o seu usuário vai ter no seu sistema/aplicativo. Isso é uma coisa que pouquíssimos desenvolvedores fazem: se colocar no lugar do usuário. E isso é um grande diferencial.

Ótimo texto para refletir. Pararmos de pensar um pouco em framework, DAO super ultra genérico e pensar mais nos usuários.
Muitas pessoas param de mexer em uma função apenas por estar funcionando, não importa como esteja. Mesmo que o usuário tenha um trabalho enorme para utiliza-la.

Texto completo:
http://gizmodo.uol.com.br/conselhos-de-um-velho-programador-antissocial-e-ranzinza/

O que uma coisa tem a ver com a outra?

O cliente é sempre o foco principal e a única coisa que importa, mas desenvolver software vai muito além de fazer uma telinha pro fulano usar. Cada parte do desenvolvimento precisa estar redonda para que o tal foco no usuário não passe de conversa fiada.

A escolha de um framework pode ser decisiva para para um produto de qualidade no prazo e no custo esperado pelo cliente. E isso é se colocar no lugar do cliente. Saber diferenciar se é melhor optar por algo próprio ou utilizar algo já existente é se por no lugar do cliente e avaliar qual dessas decisões fará o melhor produto em menos tempo.

Se utiliza ou não tal ou tal padrão, quando usar, quando não usar, qual usar para cada caso tem impacto no produto final, e principalmente na manutenção e melhorias desse produto, então de novo o usuário é o centro das decisões, mesmo as mais técnicas e aparentemente distantes do usuário.

Esse “que se danem os padrões e vamos focar no usuário” dá medo, até porque essa é uma das principais desculpas que eu já vi pra sistemas mal feitos, difíceis de manter e bugados. “Ah, vc acha que o cliente se importa com pattern?” Lógico que ele não se importa, mas quando ele descobrir que algo que leva uma semana pra ser feito poderia levar um dia, e com qualidade melhor, ele vai começar a se importar.

YvGa:

O que uma coisa tem a ver com a outra?

O cliente é sempre o foco principal e a única coisa que importa, mas desenvolver software vai muito além de fazer uma telinha pro fulano usar. Cada parte do desenvolvimento precisa estar redonda para que o tal foco no usuário não passe de conversa fiada.

A escolha de um framework pode ser decisiva para para um produto de qualidade no prazo e no custo esperado pelo cliente. E isso é se colocar no lugar do cliente. Saber diferenciar se é melhor optar por algo próprio ou utilizar algo já existente é se por no lugar do cliente e avaliar qual dessas decisões fará o melhor produto em menos tempo.

Se utiliza ou não tal ou tal padrão, quando usar, quando não usar, qual usar para cada caso tem impacto no produto final, e principalmente na manutenção e melhorias desse produto, então de novo o usuário é o centro das decisões, mesmo as mais técnicas e aparentemente distantes do usuário.

Esse “que se danem os padrões e vamos focar no usuário” dá medo, até porque essa é uma das principais desculpas que eu já vi pra sistemas mal feitos, difíceis de manter e bugados. “Ah, vc acha que o cliente se importa com pattern?” Lógico que ele não se importa, mas quando ele descobrir que algo que leva uma semana pra ser feito poderia levar um dia, e com qualidade melhor, ele vai começar a se importar.

Focar no produto te garante usuários satisfeitos, que em ultima instância, é o que vai garantir a permanência deles usando o seu produto e o sucesso do mesmo. Afinal, de que adianta um código redondo e de fácil manutenção, mas que não é usado por ninguém porque não resolve problema nenhum, ou porque tem uma interface horrível?

Mas como falei, pra quem não trabalha com produtos e apenas faz o que um cliente deseja, a idéia de criar produtos que resolvem problemas reais não é tão prioridade assim…

Achei sua definição perfeita… Nem é pra se focar só nisso, nem pra esquecer de vez. Por isso dá pra entender a preocupação do Yvga, pois se preocupar com manutenção de baixo custo e fácil escalabilidade é também pensar no seu cliente.

A verdade é que a complexidade de se gerar software de qualidade está realmente em ENCONTRAR esse equilíbrio entre o que fazer e o que não fazer e também o quão fundo ir em direção a requisitos não funcionais.

Todavia, esse discurso de “o que importa é fazer algo que o cliente usa” apesar de BEM verdadeiro pode ser perigoso se cair em mãos erradas.

Abs []

E fazer isso desenvolvendo bem e mantendo um tempo de manutenção aceitável, garante mais ainda. Fazer software certo não implica não focar no produto. Não são excludentes.

De fato, não adianta nada, mas como falei acima, o fato do código estar bem feito quer dizer que não houve foco no produto? São excludentes? Ainda continuo não vendo essa relação obrigatória de exclusão entre o que se produz e como se produz.

Já trabalhei com produtos e fazendo “apenas o que o cliente deseja” e no final das contas, ambas as formas necessitam dos 2 requisitos:

• Software que agregue valor;
• Software de fácil manutenção, pois essa custa 80% do valor total de um Software (podendo até aumentar dependendo do tempo de vida do mesmo). Grandemente dificultada por código mal escrito e “fedendo”;

Claro, o autor do texto não disse que é pra fazer software assim e nem muito menos você falou, assim como Yvga também não quis dizer que o Produto deve ser esquecido enquanto o código deve ser venerado… Nem 8, nem 80, a definição do Javaflex foi perfeita.

Abs []

adriano_si:

De fato, não adianta nada, mas como falei acima, o fato do código estar bem feito quer dizer que não houve foco no produto? São excludentes? Ainda continuo não vendo essa relação obrigatória de exclusão entre o que se produz e como se produz.

E você diz isso pra mim que estou defendendo a idéia que o programador tem que fazer os dois?

adriano_si:

Já trabalhei com produtos e fazendo “apenas o que o cliente deseja” e no final das contas, ambas as formas necessitam dos 2 requisitos:

• Software que agregue valor;
• Software de fácil manutenção, pois essa custa 80% do valor total de um Software (podendo até aumentar dependendo do tempo de vida do mesmo). Grandemente dificultada por código mal escrito e “fedendo”;

Claro, o autor do texto não disse que é pra fazer software assim e nem muito menos você falou, assim como Yvga também não quis dizer que o Produto deve ser esquecido enquanto o código deve ser venerado… Nem 8, nem 80, a definição do Javaflex foi perfeita.

Abs []

vários tipos de software não precisam manutenção constante, o caso de jogos por exemplo.

sua lista pode se resumir a apenas agregar valor. Por que se o software não agrega valor que diferença faz se ele é de fácil manutenção?

adriano_si:

Achei sua definição perfeita… Nem é pra se focar só nisso, nem pra esquecer de vez. Por isso dá pra entender a preocupação do Yvga, pois se preocupar com manutenção de baixo custo e fácil escalabilidade é também pensar no seu cliente.

Falando como se todo software fosse precisar escalar e sofrer manutenção constante…

adriano_si:

A verdade é que a complexidade de se gerar software de qualidade está realmente em ENCONTRAR esse equilíbrio entre o que fazer e o que não fazer e também o quão fundo ir em direção a requisitos não funcionais.

Concordo. E focar no produto ajuda encontrar esse equilíbrio mais do que um especialista em quando usar framework X ou Y.

adriano_si:

Todavia, esse discurso de “o que importa é fazer algo que o cliente usa” apesar de BEM verdadeiro pode ser perigoso se cair em mãos erradas.

Abs []

???

Impossivel:

adriano_si:

Achei sua definição perfeita… Nem é pra se focar só nisso, nem pra esquecer de vez. Por isso dá pra entender a preocupação do Yvga, pois se preocupar com manutenção de baixo custo e fácil escalabilidade é também pensar no seu cliente.

Falando como se todo software fosse precisar escalar e sofrer manutenção constante…

Vc inclui o software pra pizzaria ou boteco do vizinho neste ‘todo’? Porque se sim, está correto, pois o software é muito simples e pequeno. Não compensaria investir tempo em arquitetar algo que vai ficar na mesma sempre. Mas em se tratado de softwares mais robustos, pensar em escalabilidade e manutenção de baixo custo é certíssimo. Um desenvolvedor Jr. (uns 3 anos de experiência no máximo) é capaz de determinar o contexto em que se encontra.
Mesmo falando de jogos, se tivermos falando de bubble witch (comparável a pizzaria ou boteco) ou War Thunder (toda semana recebo pelo menos uma atualização). i.e. vale a regra acima.
O cliente realmente não tá nem ai pro pattern que será utilizado pra desenvolver seu produto, mas existirem técnicas boas à serem escolhidas pra se fazer qualquer coisa e bem feita.
Em vários casos, quando o analista pega o programa pra desenvolver e entende o que deve ser executado, seu conhecimento, se bem propagado dentro da empresa, pode trazer melhora até para os processos internos dentro da empresa. e.g. quem trabalha com workflow, certamente já deve ter sentindo falta de algum processo ou encontrado algo desnecessário em alguma sequencia de eventos. Algo que quando informado dentro da empresa certamente traz valor.
Supondo que seja um desenvolvedor com experiência de pelo menos 5 ou 6 anos à desenvolver um software, creio que ele já deva conhecer os instrumentos e tecnicas basicas de desenvolvimento de softwares ao ponto de desenvolver com boa qualidade. Neste caso, para um software agregar valor, na maioria das vezes depende da idéia do cliente. Raramente o desenvolvedor é culpado do software não agregar valor. Desconsiderando os insumos da produção, a culpa de um software não agregar valor só é do desenvolvedor quando a usabilidade do software se torna muito complexa, não otimizada (lenta) ou pouco instintiva. Realmente, se a manutenção não melhorar a usabilidade ou corrigir bugs, pra que falar de ‘agregar valor’?

Bom, você estava falando de desenvolver produto e de repente me diz que os produtos que você desenvolve não escalam e não sofrem manutenção constante?

Então realmente não temos o que discutir aqui.

Por isso trabalhamos em equipes. Existem pessoas para os 2 papéis que são de extrema importância. Mesmo uma Startup que nasceu em um concurso de universidade e foi campeã com sua ideia inovadora, terá muita dificuldade de crescer somente com aquele único desenvolvedor RoR que teve a ideia. COm o tempo ele terá que crescer e trazer pessoas (tanto as que focam no produto, quanto as que focam do desenvolvimento).

Claro que o cenário do autor é pra freelancer, e aí olha que engraçado, já estamos falando 90% em manutenção. Não? É pra desenvolver um produto freelancer? E esse produto não vai crescer e escalar??? Sei não hein.

Eu lhe respondi a um Quote anterior, então sim, disse pra você… Talvez se reler pode ver que posso estar reforçando ou completando sua frase.

Confirmando minha opinião = Javaflex: Nem 8, nem 80. Se essa também é a sua opinião, estamos concordando.

Só pra ficar claro, trabalho e sempre trabalhei com Softwares que vivem em manutenção constante, quer por mudanças de mercado, quer sejam por leis. Até mesmo quando trabalhei com Sistema de Escola de Caixinha, ele ficava em constante manutenção tendo em vista novas necessidades do cliente, portanto, eu realmente fico totalmente VOANDO quando o assunto é Sistema que não escala, não evolui e não muda.

Abs []

Luiz Augusto Prado:

Vc inclui o software pra pizzaria ou boteco do vizinho neste ‘todo’? Porque se sim, está correto, pois o software é muito simples e pequeno. Não compensaria investir tempo em arquitetar algo que vai ficar na mesma sempre. Mas em se tratado de softwares mais robustos, pensar em escalabilidade e manutenção de baixo custo é certíssimo. Um desenvolvedor Jr. (uns 3 anos de experiência no máximo) é capaz de determinar o contexto em que se encontra.
Mesmo falando de jogos, se tivermos falando de bubble witch (comparável a pizzaria ou boteco) ou War Thunder (toda semana recebo pelo menos uma atualização). i.e. vale a regra acima.

Pizzarias e botecos ainda usam software!!! Achei que estavam usando facebook…

sabe, aquele site feito por um programador PHP e nenhum padrão GoF?

Luiz Augusto Prado:

O cliente realmente não tá nem ai pro pattern que será utilizado pra desenvolver seu produto, mas existirem técnicas boas à serem escolhidas pra se fazer qualquer coisa e bem feita.

Concordo. Mas o que está sendo dito é que o desenvolvedor não esta nem ai pro produto que está sendo desenvolvido porque ele acha que pode fazer a coisa bem feita apenas focando nas técnicas e frameworks que existem. Disso não estou convencido.

Sinceramente parece mais uma desculpa conveniente pra quem é anti-social continuar isolado e não ter que interagir com outras pessoas!!

Luiz Augusto Prado:

Em vários casos, quando o analista pega o programa pra desenvolver e entende o que deve ser executado, seu conhecimento, se bem propagado dentro da empresa, pode trazer melhora até para os processos internos dentro da empresa. e.g. quem trabalha com workflow, certamente já deve ter sentindo falta de algum processo ou encontrado algo desnecessário em alguma sequencia de eventos. Algo que quando informado dentro da empresa certamente traz valor.
Supondo que seja um desenvolvedor com experiência de pelo menos 5 ou 6 anos à desenvolver um software, creio que ele já deva conhecer os instrumentos e tecnicas basicas de desenvolvimento de softwares ao ponto de desenvolver com boa qualidade. Neste caso, para um software agregar valor, na maioria das vezes depende da idéia do cliente. Raramente o desenvolvedor é culpado do software não agregar valor. Desconsiderando os insumos da produção, a culpa de um software não agregar valor só é do desenvolvedor quando a usabilidade do software se torna muito complexa, não otimizada (lenta) ou pouco instintiva. Realmente, se a manutenção não melhorar a usabilidade ou corrigir bugs, pra que falar de ‘agregar valor’?

Resumindo, não tenho a mínima idéia do que estou falando.

Ache um trecho sequer onde alguém disse isso. Mas QUOTE o trecho.

https://www.google.com.br/?gws_rd=ssl#q=site:guj.com.br+melhor+framework

Bom… Acho que ficou claro. Com essa eu me retiro… Bom texto do cara, eu particularmente gostei e boa colocação do Yvga.

Abs []

adriano_si:

Por isso trabalhamos em equipes. Existem pessoas para os 2 papéis que são de extrema importância. Mesmo uma Startup que nasceu em um concurso de universidade e foi campeã com sua ideia inovadora, terá muita dificuldade de crescer somente com aquele único desenvolvedor RoR que teve a ideia. COm o tempo ele terá que crescer e trazer pessoas (tanto as que focam no produto, quanto as que focam do desenvolvimento).

Claro que o cenário do autor é pra freelancer, e aí olha que engraçado, já estamos falando 90% em manutenção. Não? É pra desenvolver um produto freelancer? E esse produto não vai crescer e escalar??? Sei não hein.

Abs []

A importância do papel depende da facilidade em substituir aquela pessoa por outra, sem causa transtornos ou atrasos significantes no projeto.

Sendo assim, podemos concluir que o papel do responsável pelo produto geralmente É muito mais importante do que quem foca apenas no desenvolvimento.

adriano_si:

Bom… Acho que ficou claro. Com essa eu me retiro… Bom texto do cara, eu particularmente gostei e boa colocação do Yvga.

Abs []

Nada como um exemplo do mundo real para demonstrar o que estou dizendo né mesmo?

Sério? Eu lhe peço um exemplo de onde que alguém na discussão em questão afirmou o que você disse aí em cima e você me vem com um link do Google de pessoas perguntando qual o melhor framework e tals.

Pra mim o exemplo foi de que além de não saber interpretar um texto, você não sabe discutir a um nível aceitável sequer tendo em vista que tira conclusões do que os outros dizem, sem que eles tenham dito.

Talvez haja um mundo aí só seu, onde você lê o que quer e escuta o que quer. Como seu nick diz, realmente é Impossível vencê-lo com argumentos tão sólidos dentro do seu Fantástico mundo ilusório.

Sem mais.

Até que você seja homem e ponha a sua cara a tapa (e não esse fake que nasceu na discussão do PJ), simplesmente você pra mim é troll que se esconde sobre uma máscara pra cuspir asneiras.

Abs []

Quanto mais saber… melhor. Pra qualquer caso. Com isso também concordo.

É claro que a forma como o produto ou serviço oferecido deve funcionar vai refletir no software desenvolvido. A abstração do produto ou serviço deve corresponder com as abstrações do funcionamento dos softwares. O arquiteto de software é quem deve estar capacitado à fazer estas correlações e é o responsável por decidir como e o que seria melhor utilizar. Muitas vezes, quem desenvolve, não tem a visão do todo (negócio), mas é capaz de executar as tarefas que lhe foram delegadas. Por que o desgosto com isso? Isso vai ocorrer sempre porque as empresas visam economia. Então, por que contratar Analista Sênior pra fazer o trabalho de Júnior sendo que podemos alocar a concentração dos sêniores por um preço maior em gargalos mais genéricos e impactantes e alocar vários júniores por preços menores para trabalhos mais localizados e de menores riscos?
Os motivos de existir cargos como por exemplo de analista de requisitos, desenvolvedores de softwares… é para que a transferência das demandas sejam filtradas e delegadas à pessoas capacitadas da empresa (toda a engrenagem pode ser encaixada). Juniores só viram seniores com tempo de experiência. Erros vão ocorrer. Se o resultado não foi o esperado, a culpa não é das técnicas ou frameworks e sim de quem as escolheu.
Se vc passa uma tarefa para um pedreiro construir sua casa, vc iria à construção somente de 4 em 4 meses pra ver como tá ficando a obra?
Atenção deve ser constante. Não existe bala de prata.
Frameworks e até técnicas vc mesmo pode criar.

talvez vc esteja se referindo a isso:

deve existir feedback pra que o sistema não deixe o funcionário como um zumbi.

Sério? Eu lhe peço um exemplo de onde que alguém na discussão em questão afirmou o que você disse aí em cima e você me vem com um link do Google de pessoas perguntando qual o melhor framework e tals.

Pra mim o exemplo foi de que além de não saber interpretar um texto, você não sabe discutir a um nível aceitável sequer tendo em vista que tira conclusões do que os outros dizem, sem que eles tenham dito.

Talvez haja um mundo aí só seu, onde você lê o que quer e escuta o que quer. Como seu nick diz, realmente é Impossível vencê-lo com argumentos tão sólidos dentro do seu Fantástico mundo ilusório.

Sem mais.

Até que você seja homem e ponha a sua cara a tapa (e não esse fake que nasceu na discussão do PJ), simplesmente você pra mim é troll que se esconde sobre uma máscara pra cuspir asneiras.

Abs []

Bom, esse é o argumento do tópico, que o programador deveria focar mais no produto.

O fato de que você precisa de ajuda pra entender quem disse o que mostra quem tem a dificuldade de entender textos aqui.

Tenha um ótimo dia.

https://www.google.com.br/?gws_rd=ssl#q=site:guj.com.br+melhor+framework

Ninguém discute a importância do cliente ou usuário final para o sistema. Isso é tão óbvio que sequer precisa ser mencionado.

O problema é que eu já vi muito, sob a desculpa de “o usuário não tá nem aí pra qualidade de código”, muita porcaria ser escrita, ir pra produção com bug e levar semanas pra fazer alterações que poderiam ser feitas em horas.

Vale sempre a pena estudar pra saber o que melhor se encaixa para cada situação. Se um desenvolvedor não têm o discernimento do que e quando usar e tenta por uma estrutura de aplicação monstruosa para uma agenda telefônica, isso é um problema dele, e do cliente dele e essa “inexperiência” não invalida tudo que se aprendeu sobre padrões de projetos, de arquitetura e frameworks.

E outra coisa a ser lembrada é que muita gente considera que código bom só traz vantagem para dar manutenção num sistema, que antes dele ir pra produção não faz diferença. Mais uma afirmação que indica inexperiência, porque a manutenção em trechos de código já implementados, normalmente começa muito antes do sistema entrar em produção.

Pra alguns sim e é sobre isso que o texto diz. Há pessoas, e não poucas que isso precisa ser mencionado.

E é pra esses a quem o texto se direciona. Trabalhei recentemente em uma ideia onde um colega queria porque queria fazer com mean stack, sendo que nem eu e nem ele tínhamos a experiência no negócio.

Depois de algumas conversas e brainstormings, cheguei em um protótipo em Java mesmo, a fim de colocar pra alguns conhecidos (potenciais usuários validarem) e ele passou uma tarde tentando me convencer o “porque” de usar mean seria melhor.

No final das contas, seguimos vertentes separadas e passado algumas semanas, ele ainda está apanhando pra fazer a POC dele enquanto as telas JSF já estão sendo criticadas e melhoradas.

Pra esse meu conhecido, esse texto será útil, pois na cabeça dele, a ferramenta e o produto ainda são 1 só. Não que não sejam, mas se o Mean vai realmente resolver o meu problema no futuro, eu primeiro preciso garantir esse meu futuro.

Por isso digo e repito, nem 8, nem 80. Poderia estar até agora fazendo estudos da melhor arquitetura ou tecnologia, mas fiz no que eu sabia e já estamos validando. Claro que esse é 1 cenário isolado e pode haver casos onde a decisão de usar o mean se encaixe melhor desde o início.

O texto é exatamente pra essa galera que não enxerga mais nada a não ser “o que vamos usar pra fazer isso?” e não pra quem já transcendeu dessa ideia.

Abs []

Pra alguns sim e é sobre isso que o texto diz. Há pessoas, e não poucas que isso precisa ser mencionado.

E é pra esses a quem o texto se direciona. Trabalhei recentemente em uma ideia onde um colega queria porque queria fazer com mean stack, sendo que nem eu e nem ele tínhamos a experiência no negócio.

Depois de algumas conversas e brainstormings, cheguei em um protótipo em Java mesmo, a fim de colocar pra alguns conhecidos (potenciais usuários validarem) e ele passou uma tarde tentando me convencer o “porque” de usar mean seria melhor.

No final das contas, seguimos vertentes separadas e passado algumas semanas, ele ainda está apanhando pra fazer a POC dele enquanto as telas JSF já estão sendo criticadas e melhoradas.

Pra esse meu conhecido, esse texto será útil, pois na cabeça dele, a ferramenta e o produto ainda são 1 só. Não que não sejam, mas se o Mean vai realmente resolver o meu problema no futuro, eu primeiro preciso garantir esse meu futuro.

Por isso digo e repito, nem 8, nem 80. Poderia estar até agora fazendo estudos da melhor arquitetura ou tecnologia, mas fiz no que eu sabia e já estamos validando. Claro que esse é 1 cenário isolado e pode haver casos onde a decisão de usar o mean se encaixe melhor desde o início.

O texto é exatamente pra essa galera que não enxerga mais nada a não ser “o que vamos usar pra fazer isso?” e não pra quem já transcendeu dessa ideia.

Abs []

Concordo com seu comentário, o que eu queria dizer é que isso nem deveria precisar ser mencionado. Mas existem desenvolvedores que não tem realmente essa visão. O meu comentário, o primeiro, não foi contra o texto do blog, mas contra o comentário de quem postou, sugerindo que não devemos nos preocupar com padrões e frameworks e sim com somente com o usuário. Uma coisa não exclui a outra e conhecermos padrões, frameworks e qualquer outra ferramenta que nos ajude a desenvolver, assim como quando e qual usar, está diretamente ligado ao foco no usuário.

Voltei! Entrei de férias e esqueci do post.

YvGa:

Concordo com seu comentário, o que eu queria dizer é que isso nem deveria precisar ser mencionado. Mas existem desenvolvedores que não tem realmente essa visão. O meu comentário, o primeiro, não foi contra o texto do blog, mas contra o comentário de quem postou, sugerindo que não devemos nos preocupar com padrões e frameworks e sim com somente com o usuário. Uma coisa não exclui a outra e conhecermos padrões, frameworks e qualquer outra ferramenta que nos ajude a desenvolver, assim como quando e qual usar, está diretamente ligado ao foco no usuário.

“Contra quem postou” você diz eu? Então acho que fui mal interpretado. Não me expressei direito.

Lógico que framework e padrões são importantes para o projeto, mas acho que muitos param de tentar melhorar o sistema quando ele está estabilizado. Não ligam para a interação do usuário com o sistema, quantos clicks você pode reduzir para ele fazer algo ou o workflow.

YvGa:

O problema é que eu já vi muito, sob a desculpa de “o usuário não tá nem aí pra qualidade de código”, muita porcaria ser escrita, ir pra produção com bug e levar semanas pra fazer alterações que poderiam ser feitas em horas.

Se você é o comandante do navio que pode afundar, culpar a tripulação não vai ajudar muito sua causa.

YvGa:

Vale sempre a pena estudar pra saber o que melhor se encaixa para cada situação. Se um desenvolvedor não têm o discernimento do que e quando usar e tenta por uma estrutura de aplicação monstruosa para uma agenda telefônica, isso é um problema dele, e do cliente dele e essa “inexperiência” não invalida tudo que se aprendeu sobre padrões de projetos, de arquitetura e frameworks.

A questão é: se ele é um dos tripulantes do seu navio, acha que o problema é dele também?

YvGa:

E outra coisa a ser lembrada é que muita gente considera que código bom só traz vantagem para dar manutenção num sistema, que antes dele ir pra produção não faz diferença. Mais uma afirmação que indica inexperiência, porque a manutenção em trechos de código já implementados, normalmente começa muito antes do sistema entrar em produção.

Nunca precisei dar manutenção em um sistema antes mesmo de ir entrar em produção.

Imagino que você possa ter um problema de processo se precisa fazer isso com frequência.

YvGa:

Concordo com seu comentário, o que eu queria dizer é que isso nem deveria precisar ser mencionado. Mas existem desenvolvedores que não tem realmente essa visão. O meu comentário, o primeiro, não foi contra o texto do blog, mas contra o comentário de quem postou, sugerindo que não devemos nos preocupar com padrões e frameworks e sim com somente com o usuário. Uma coisa não exclui a outra e conhecermos padrões, frameworks e qualquer outra ferramenta que nos ajude a desenvolver, assim como quando e qual usar, está diretamente ligado ao foco no usuário.

É perfeitamente natural se preocupar com o que conhece menos, e “relaxar” com o que já conhece.

Com relação a “conhecer” os padrões, frameworks e técnicas usadas no mercado de TI. Isso não está diretamente ligado a foco no usuário, mas poderia se a comunidade discutisse mais sobre isso.

Não tenho “desgosto” por quem desenvolve software como se fosse uma fábrica. Nem pra quem desenvolve com foco no produto, que convenhamos, também sempre vai ocorrer porque cada vez mais desenvolvedores visam design e usuários visam economia (pergunte para as empresas que vendem software para pizzarias e botecos da esquina!).

Luiz Augusto Prado:

Então, por que contratar Analista Sênior pra fazer o trabalho de Júnior sendo que podemos alocar a concentração dos sêniores por um preço maior em gargalos mais genéricos e impactantes e alocar vários júniores por preços menores para trabalhos mais localizados e de menores riscos?
Os motivos de existir cargos como por exemplo de analista de requisitos, desenvolvedores de softwares… é para que a transferência das demandas sejam filtradas e delegadas à pessoas capacitadas da empresa (toda a engrenagem pode ser encaixada). Juniores só viram seniores com tempo de experiência. Erros vão ocorrer. Se o resultado não foi o esperado, a culpa não é das técnicas ou frameworks e sim de quem as escolheu.
Se vc passa uma tarefa para um pedreiro construir sua casa, vc iria à construção somente de 4 em 4 meses pra ver como tá ficando a obra?
Atenção deve ser constante. Não existe bala de prata.
Frameworks e até técnicas vc mesmo pode criar.

Tu parece tão preocupado em atribuir tarefas e culpas que não percebeu que software não é cimento ou tem engrenagens.

Não caro colega. Só to lhe dizendo que não dá pra focar apenas em produto e os porques de não (Claro, mesmo com a experiência que tenho não deixo de perguntar pra outros colegas, amigos e mesmo no forum). E sobre cimento e engrenagens vou negritar o que disse em um post anterior, pois vale para contexto:

É claro que a forma como o produto ou serviço oferecido deve funcionar vai refletir no software desenvolvido. A abstração do produto ou serviço deve corresponder com as abstrações do funcionamento dos softwares. O arquiteto de software é quem deve estar capacitado à fazer estas correlações e é o responsável por decidir como e o que seria melhor utilizar.

Já vi cliente apresentar partes de software desenvolvido por mim como se fosse ele quem o tivesse feito só por ter sugerido. A idéia de um(ns) processo(s), é totamente diferente do software que vair organizar e executar tal(is) processo(s). Então, não dá pra falar em focar apenas em produto ou em apenas em tecnicas de desenvolvimento. “Parafrazeando” algo que ví sobre ITIL:
Felizmente, não é necessário saber tudo sobre ITIL para tirar benefícios, nem é preciso saber como compreender tudo para retirar valor.
E que lembra algo que li no GEB ( ver imagem ou link: niveis de descrição e computadores - selagem - selagem do conhecimento. visivel neste link da descrição da imagem)

Vc pode conseguir fazer seu software sem o uso de orientação a objeto? Pode, mas corre o risco de ter trabalho triplicado. Mas se já conhece bastante, e tem ideias inovadoras… tenta! Quem sou eu pra lhe dizer como deve delegar suas demandas? As faculdades e mentes brilhantes e fermentantes de mais de 100 milhões de desenvolvedores vão criar tecnicas inovadoras a uma taxa maior do que qualquer um possa atualizar-se.

Luiz Augusto Prado:

talvez vc esteja se referindo a isso:

deve existir feedback pra que o sistema não deixe o funcionário como um zumbi.

Neste link acima, que mostra o desenvolvimento em cascata, cada conhecimento detalhado fica selado dentro de seu nível. Cabe aos mediadores (o arquiteto por exemplo) manter informações desnecessárias a outros níveis isoladas e tranferir apenas o Essencial.

Pra alguns sim e é sobre isso que o texto diz. Há pessoas, e não poucas que isso precisa ser mencionado.

E é pra esses a quem o texto se direciona. Trabalhei recentemente em uma ideia onde um colega queria porque queria fazer com mean stack, sendo que nem eu e nem ele tínhamos a experiência no negócio.

Depois de algumas conversas e brainstormings, cheguei em um protótipo em Java mesmo, a fim de colocar pra alguns conhecidos (potenciais usuários validarem) e ele passou uma tarde tentando me convencer o “porque” de usar mean seria melhor.

No final das contas, seguimos vertentes separadas e passado algumas semanas, ele ainda está apanhando pra fazer a POC dele enquanto as telas JSF já estão sendo criticadas e melhoradas.

Pra esse meu conhecido, esse texto será útil, pois na cabeça dele, a ferramenta e o produto ainda são 1 só. Não que não sejam, mas se o Mean vai realmente resolver o meu problema no futuro, eu primeiro preciso garantir esse meu futuro.

Por isso digo e repito, nem 8, nem 80. Poderia estar até agora fazendo estudos da melhor arquitetura ou tecnologia, mas fiz no que eu sabia e já estamos validando. Claro que esse é 1 cenário isolado e pode haver casos onde a decisão de usar o mean se encaixe melhor desde o início.

O texto é exatamente pra essa galera que não enxerga mais nada a não ser “o que vamos usar pra fazer isso?” e não pra quem já transcendeu dessa ideia.

Abs []

Concordo com seu comentário, o que eu queria dizer é que isso nem deveria precisar ser mencionado. Mas existem desenvolvedores que não tem realmente essa visão.
É preciso mencionar pois não é tão difícil um dia saber de situações do tipo, com mais chances de encontrar em lugares que arquitetos vivem no mundo da Lua da TI, definindo padrões sem envolvimento com a realidade do dia-a-dia do desenvolvimento x usuário.

O que na prática tenho passado e achado ideal, é a equipe poder definir junto, isso leva mais ao equilíbrio. Claro que os seniors vão naturalmente ter maior grau de contribuição e peso, mas nada impede do júnior de repente saber de uma novidade técnica que resolva melhor uma nova funcionalidade que o usuário precisa, onde a maioria aceita e depois passa pela prova de conceito. Além claro, da soma de ideias poder formar uma grande ideia. Assim todos vão estar mais envolvidos para o mesmo objetivo, que é o atendimento das necessidades dinâmicas do usuário.

Só para deixar claro que costumo falar relacionado ao cenário de sistemas de informações.

Luiz Augusto Prado:

Impossivel:

Tu parece tão preocupado em atribuir tarefas e culpas que não percebeu que software não é cimento ou tem engrenagens.

Não caro colega. Só to lhe dizendo que não dá pra focar apenas em produto e os porques de não (Claro, mesmo com a experiência que tenho não deixo de perguntar pra outros colegas, amigos e mesmo no forum). E sobre cimento e engrenagens vou negritar o que disse em um post anterior, pois vale para contexto:

É claro que a forma como o produto ou serviço oferecido deve funcionar vai refletir no software desenvolvido. A abstração do produto ou serviço deve corresponder com as abstrações do funcionamento dos softwares. O arquiteto de software é quem deve estar capacitado à fazer estas correlações e é o responsável por decidir como e o que seria melhor utilizar.

Entender os contextos…

Já vi cliente apresentar partes de software desenvolvido por mim como se fosse ele quem o tivesse feito só por ter sugerido. A idéia de um(ns) processo(s), é totamente diferente do software que vair organizar e executar tal(is) processo(s). Então, não dá pra falar em focar apenas em produto ou em apenas em tecnicas de desenvolvimento. “Parafrazeando” algo que ví sobre ITIL:
Felizmente, não é necessário saber tudo sobre ITIL para tirar benefícios, nem é preciso saber como compreender tudo para retirar valor.
E que lembra algo que li no GEB ( ver imagem ou link: niveis de descrição e computadores - selagem - selagem do conhecimento. visivel neste link da descrição da imagem)

Vc pode conseguir fazer seu software sem o uso de orientação a objeto? Pode, mas corre o risco de ter trabalho triplicado. Mas se já conhece bastante, e tem ideias inovadoras… tenta! Quem sou eu pra lhe dizer como deve delegar suas demandas? As faculdades e mentes brilhantes e fermentantes de mais de 100 milhões de desenvolvedores vão criar tecnicas inovadoras a uma taxa maior do que qualquer um possa atualizar-se.

Certo. você parece estar dizendo porque as empresas não podem focar no produto, enquanto o texto está dizendo que desenvolvedores podem, aliás não só podem, como devem. entende a diferença?

Não, eu disse que a empresa deve focar no produto e no conhecimento dos métodos e das tecnicas basicas.
So um ou so o outro é arriscado.

O que o texto diz é que o conhecimento tem suas camadas e níveis e que as vezes o funcionário que tiver desenvolvendo alguma parcela do produto não irá precisar saber a origem da materia prima, como e onde seu trabalho será utilizado.

Luiz Augusto Prado:

eu disse que a empresa deve focar no produto e no conhecimento dos métodos e das tecnicas basicas.
So um ou so o outro é arriscado.

O que o texto diz é que o conhecimento tem suas camadas e níveis e que as vezes o funcionário que tiver desenvolvendo alguma parcela do produto não irá precisar saber a origem da materia prima, como e onde seu trabalho será utilizado.

Certo, mas ninguém fez nenhum argumento contrário a isso, nem falou nada de empresa focar ou não no produto, e sim desenvolvedores individuais, portanto o seu argumento de que empresas não podem focar no produto, ainda que faça sentido porque realmente empresas tem muito mais que se preocupar (economia de $) do que com usuários estúpidos, ele é irrelevante para essa discussão.

javaflex:

Só para deixar claro que costumo falar relacionado ao cenário de sistemas de informações.

Sério, todos esses sênior, júnior e equilíbrio… por um momento achei que estivesse falando de uma reunião de família na yoga.

Impossivel:

javaflex:

Só para deixar claro que costumo falar relacionado ao cenário de sistemas de informações.

Sério, todos esses sênior, júnior e equilíbrio… por um momento achei que estivesse falando de uma reunião de família na yoga.

Impossivel:

Luiz Augusto Prado:

eu disse que a empresa deve focar no produto e no conhecimento dos métodos e das tecnicas basicas.
So um ou so o outro é arriscado.

O que o texto diz é que o conhecimento tem suas camadas e níveis e que as vezes o funcionário que tiver desenvolvendo alguma parcela do produto não irá precisar saber a origem da materia prima, como e onde seu trabalho será utilizado.

Certo, mas ninguém fez nenhum argumento contrário a isso, nem falou nada de empresa focar ou não no produto, e sim desenvolvedores individuais, portanto o seu argumento de que empresas não podem focar no produto, ainda que faça sentido porque realmente empresas tem muito mais que se preocupar (economia de $) do que com usuários estúpidos, ele é irrelevante para essa discussão.

Na verdade… vc falou pra focar em produto sim:

Impossivel:

Sendo assim, podemos concluir que o papel do responsável pelo produto geralmente É muito mais importante do que quem foca apenas no desenvolvimento.

Talvez esteja interpretando mal suas colocações, mas pelo andar da carruagem, já sei onde vai dar.
Então, vou vestir a carapuça do tópico e agir como um programador antissocial e ranzinza.
Só pra iniciar, vou contar uma experiencia que tive sobre qual a visão de “foco em produto” que aparentemente vc está me dando e já dar uma dica do que poucos como eu tem coragem:

1. fui chamado em uma escola de medicina pra desenvolver um sistema on-line de cadastro de professores, alunos, geração de grades e turmas. Até ai, tudo bem, só que apos desenvolver o projeto vem o retardado do dono (esta é a visão que tenho de alguem que age como ele agia) apresentando meu piloto como se ele fosse o autor do programa sem nem citar os desenvolvedores. Não vou nem falar como ele tratava mal os desenvolvedores. Bom, ele teve a idéia do produto. Só que eu gostaria de saber como ele teria a idéia sobre o algorítmo genético pra geração das grades horarias para os alunos e para os professores! Era só mais um retardado com dinheiro na mão que acha que uma porra de uma idéia na cabeça é o suficiente pra mover um negócio e precisava constantemente insinuar que o que vale é apenas o produto. [Fácil né! to com uma idéia… de um algortimo pra me dizer instantaneamente se um número é primo ou não.]
   A sorte desse palhaço é que infelizmente vivemos em uma terra de gente que é constantemente chantageada. O que tem acontecido neste país, infelizmente é isso. Um monte de gente necessitada que aguenta o fedor putrido de patrões que só querem ouvir que estão cheirosos. Conhece a história do rei nú? Não sei se realmente este tipo de patrão está focado no produto quando vejo este tipo de atitude. Realmente espero que eu tenha lhe entendido errado.

O valor que eu cobro não é caro e o que eu faço funciona, seguindo ou não os protocolos.
Eu moro em uma Torre de Marfim porque eu posso. Qualquer um pode, mas se quer as coisas funcionando, tem que respeitar e remunerar bem quem vai fazer pra vc.

Impossivel:

javaflex:

Só para deixar claro que costumo falar relacionado ao cenário de sistemas de informações.

Sério, todos esses sênior, júnior e equilíbrio… por um momento achei que estivesse falando de uma reunião de família na yoga.

Vc ainda quer trocar idéia com alguem?

O que disse quando ele te perguntou: Como seu algorítmo genético pra geração das grades horarias seria melhor para alunos e professores que usam o sistema?

Luiz Augusto Prado:

Na verdade… vc falou pra focar em produto sim:

Essa foi resposta para outro usuário que disse que só trabalha em equipe.

O texto fala pro desenvolvedor individual focar no produto.

A atitude a qual me referi é a de desvalorizar o trabalho dos outros e a tratar mal os funcionarios com o intuito de pagar mal. Receita ideal para uma porcaria.

Impossivel:

O que disse quando ele te perguntou: Como seu algorítmo genético pra geração das grades horarias seria melhor para alunos e professores que usam o sistema?

A atitude a qual me referi é a de desvalorizar o trabalho dos outros e a tratar mal os funcionarios com o intuito de pagar mal. Receita ideal para uma porcaria.

É de esperar que o software desenvolvimento em um esquema de “fábrica” (onde existe a separação de idéia e produto final) seja uma porcaria.

Como falei anteriormente, precisamos de um processo diferente disso, software não é cimento ou engrenagem.

Impossivel:

É de esperar que o software desenvolvimento em um esquema de “fábrica” (onde existe a separação de idéia e produto final) seja uma porcaria.

Como falei anteriormente, precisamos de um processo diferente disso, software não é cimento ou engrenagem.

Ok, boa sorte na sua busca.
Quando tiver tempo sugiro ler sobre a selagem de conhecimento citadas acima.

Luiz Augusto Prado:

Impossivel:

Como falei anteriormente, precisamos de um processo diferente disso, software não é cimento ou engrenagem.

Ok, boa sorte na sua busca.
Quando tiver tempo sugiro ler sobre a selagem de conhecimento citadas acima.

Eu li mas se puder explicar melhor porque eu não entendi onde quer chegar usando física nuclear pra defender ITIL e outras práticas antigas da indústria de software.

javaflex:

Impossivel:

É de esperar que o software desenvolvimento em um esquema de “fábrica” (onde existe a separação de idéia e produto final) seja uma porcaria.

Como falei anteriormente, precisamos de um processo diferente disso, software não é cimento ou engrenagem.

Não sei se o caso do Luiz é isso que você fala, nem vou entrar nessa questão, e se for, sem problemas se estiver dando certo para o cliente dele. Mas concordo plenamente com essa questão do esquema de fábrica geralmente ser uma porcaria. Os clientes que buscam economia real com qualidade deveriam acordar para não aceitar esse esquema. Os clientes que entram nesse esquema geralmente caem numa economia burra, que lá na frente pode se tornar mal investimento.

Muitos clientes acreditam na idéia de trabalhar seguindo os padrões de excelência manifestado em outras áreas, onde artefatos duram por séculos sem falhar, há divisão de idéia de produto…

Portanto boa sorte tentando convencer que estão errados do alto de sua torre de marfim.

Na verdade são tolos e não devem ter dinheiro pra comprar conhecimento (software).

Isso está na Bíblia…

Why should fools have money in hand to buy wisdom, when they are not able to understand it?

Impossivel:

Eu li, mas se puder explicar melhor, porque eu não entendi onde quer chegar usando física nuclear pra defender ITIL e outras práticas antigas da indústria de software.

Impossivel:

Isso está na Bíblia…

Why should fools have money in hand to buy wisdom, when they are not able to understand it?

Eu busco valores maiores que poder e dinheiro. Só a boa companhia já vale muito mais.

Luiz Augusto Prado:

Impossivel:

Eu li, mas se puder explicar melhor, porque eu não entendi onde quer chegar usando física nuclear pra defender ITIL e outras práticas antigas da indústria de software.

Em nenhum momento defendi ITIL ou disse que vc precisa conhecer sobre física nuclear, cimento ou engrenagens. O que to lhe falando não são praticas antigas. Na verdade, focar em produtos sem valorizar os pré-requisitos, é que são práticas antigas.
ITIL é uma biblioteca de boas práticas para gerenciamento de organizações focadas em TI.
Se o estudante desta biblioteca for esperto o suficiente (abstrair para outros contextos, algo que normalmente muitos tem dificuldade), pode implementar alguns conceitos de ITIL não só para serviços de TI, mas para gestão de qualquer outro tipo de empresa. De alguma forma ou de outra as empresas de sucesso utilizam alguns deles pra manter o ciclo de vida de sua empresa.
Entenda bem, eu não defendo o modelo fordista de produção.
O que o texto citado exemplifica é que um biólogo não precisa entender profundamente sobre química, que um químico não precisa entender profundamente sobre física nuclear e que um um físico nuclear não precisa entender profundamente sobre quântica.
O cliente foca no produto, desenvolvedores focavam em técnicas e o arquiteto intermedia cliente e desenvolvedores.
O dono da faculdade não sabe o que é um algoritmo genético. O Arquiteto sabe, mas não sabe como foi implementado. Já os desenvolvedores sabem como foi implementado.
Concordo com vc que quanto mais cada funcionário souber sobre os processos de produção melhor, mas em um projeto grande, com um modelo de produção já consolidado (camadas e patterns), isso vai se tornar impossível.
Abstraindo para outro contexto:
A montadora de carros não precisa conhecer o processo de produção do aço que será utilizado nem a usina precisa saber pra que serão utilizados. Mas a montadora tem que exigir as especificações e as usinas informarem suas limitações.
O problema na produção do software (que eu acho que é o que está se referindo) é que ele é muito mais flexível que aço e concreto, podendo sofrer alterações constantes nos requisitos. Algo que pode esbarrar nos limites dos desenvolvedores (arquitetura, patterns, frameworks escolhidos…). Só que quando isso acontecer, é porque o cliente ainda não sabe o que quer. E quando isso acontecer, sugiro criar algo bem simplista. Um projeto piloto. Que não trabalhe diretamente com web, banco de dados, frameworks pesados… Para que somente depois da aprovação, seja mandado para a produção.

Por favor, cite empresas conhecidas por criarem software de qualidade e que usam ITIL.

Luiz Augusto Prado:

Eu busco valores maiores que poder e dinheiro. Só a boa companhia já vale muito mais.

O dia que uma burocracia “bem estruturada” como vc fala, conseguir criar software de qualidade eu vou acreditar.

Impossivel:

Nunca precisei dar manutenção em um sistema antes mesmo de ir entrar em produção.

Imagino que você possa ter um problema de processo se precisa fazer isso com frequência.

Se você não precisa alterar funcionalidades antes mesmo do sistema entrar em produção, você tem a solução de todos os nossos problemas. Sugiro sinceramente que publique e espalhe esse seu conhecimento. Você vai ficar milionário.

Existe hoje toneladas de artigos, publicações, técnicas, justamente para facilitar a alteração de código pronto, mesmo antes de ser lançado. Técnicas e ferramentas que facilitam nossas vidas, deixando o código preparado para as mudanças de requisitos que costumam ser constantes em sistemas de médio porte pra cima.

Se você tem a solução definitiva pra isso, você tem o Santo Graal da engenharia de software. Por favor, compartilhe desse conhecimento conosco.

Só não me venha com o velho planejamento detalhado e levantamento completo e cuidadoso dos requisitos.

Só por no google:
pinkverify certified itil

Esxemlo que aparece:
http://www.cherwell.com/product/pink-verify-itil-processes
http://www.bmc.com/news/press-releases/2012/bmc-softwares-remedy-it-service-management-suite-awarded-itil-v3-certification.html
.
.
.
Uma das empresa onde trabalhei tem preferencia por certificados nesta bilioteca. Central IT
http://www.centralit.com.br/2_2-Certificacoes.html

Na minha opinião, se estão em primeiro no google, é porque tão dando certo.
Falou! boa sorte

Impossivel:

Luiz Augusto Prado:

Eu busco valores maiores que poder e dinheiro. Só a boa companhia já vale muito mais.

O dia que uma burocracia “bem estruturada” como vc fala, conseguir criar software de qualidade eu vou acreditar.

como que se relaciona o quote que fez com ‘burocracia “bem estruturada”’?
se, pra vc burocracia “bem estruturada” é o que pra mim é “cooperação” então é possível sim.

YvGa:

Se você não precisa alterar funcionalidades antes mesmo do sistema entrar em produção, você tem a solução de todos os nossos problemas. Sugiro sinceramente que publique e espalhe esse seu conhecimento. Você vai ficar milionário.

Existe hoje toneladas de artigos, publicações, técnicas, justamente para facilitar a alteração de código pronto, mesmo antes de ser lançado. Técnicas e ferramentas que facilitam nossas vidas, deixando o código preparado para as mudanças de requisitos que costumam ser constantes em sistemas de médio porte pra cima.

Se você tem a solução definitiva pra isso, você tem o Santo Graal da engenharia de software. Por favor, compartilhe desse conhecimento conosco.

Só não me venha com o velho planejamento detalhado e levantamento completo e cuidadoso dos requisitos.

Não é que não preciso alterar funcionalidades antes mesmo de entrar em produção, é que se precisar fazer na versão em desenvolvimento, não vai afetar em nada o build que está sendo testado pra entrar em produção.

Talvez você esteja falando de alguma situação específica e não esta sabendo ser claro. Talvez uma situação que tem que lidar com algum tipo de software (ou banco de dados no caso de CRUDs) legado? Não sei, desculpa por não ter a bala de prata que vc busca. Como falei, eu trabalho com jogos. Minha engenharia é investida no produto, e não com atualização e legados.

Sobre a internet, existem toneladas de artigos publicados sobre basicamente tudo que se pesquisar, isso não quer dizer que as pessoas escrevendo esses artigos estão milionárias.

Luiz Augusto Prado:

Por favor, cite empresas conhecidas por criarem software de qualidade e que usam ITIL.

Só por no google:
pinkverify certified itil

Esxemlo que aparece:
http://www.cherwell.com/product/pink-verify-itil-processes
http://www.bmc.com/news/press-releases/2012/bmc-softwares-remedy-it-service-management-suite-awarded-itil-v3-certification.html
.
.
.
Uma das empresa onde trabalhei tem preferencia por certificados nesta bilioteca. Central IT
http://www.centralit.com.br/2_2-Certificacoes.html

Na minha opinião, se estão em primeiro no google, é porque tão dando certo.
Falou! boa sorte

Se estão em primeiro no google para “ITIL” é porque o software é bom?!

#fail

Me avisa quando uma empresa de software ou tecnologia de ponta usar ITIL. Até lá não vejo porque um desenvolvedor precisa se importar com isso.

Luiz Augusto Prado:

Impossivel:

Luiz Augusto Prado:

Eu busco valores maiores que poder e dinheiro. Só a boa companhia já vale muito mais.

O dia que uma burocracia “bem estruturada” como vc fala, conseguir criar software de qualidade eu vou acreditar.

como que se relaciona o quote que fez com ‘burocracia “bem estruturada”’?
se, pra vc burocracia “bem estruturada” é o que pra mim é “cooperação” então é possível sim.

O problema que pra funcionar, seu método depende em separar o trabalho entre “mentes superiores” (os clientes e Arquitetos) e pessoas com menos QI (desenvolvedores).

Obviamente que o arquiteto só tem a ganhar nessa configuração. Mas não acho que teria algo de errado em ganhar, se funcionasse…

O motivo que não funciona é porque burocracias são frágeis.

Nada a ver. tá viajando de novo. Onde eu disse isso de QI? Um dia um pode assumir um papel e outro outro. Vai depender da confiança que o funcionário merece.
Já ví muitos Juniores com 200 de QI e estão onde estão por pouca experiência e (ou) pouca confiança da empresa, mas que depois de 2 anos já são tão capazes de assumir a gestão de um projeto quanto qualquer outro sênior com menor QI que é sênior por experiência. Quem vai determinar quem vai ficar onde é o gestor e se existir acordo com o funcionário. E, por mais QI que um funcionário tenha, se ele for novato em desenvolvimento, deve começar por baixo. Como um júnior, se não tiver experiência nenhuma ou como pleno se tiver alguma experiência. Mas nunca como sênior, pois provavelmente não conhece o negócio. Quem for assumir a gestão, deve conhecer bem o negócio além de ter muita experiência com desenvolvimento.

Sobre ITIL, novamente, informo que não to defendendo que só empresas de sucessos a utilizam. O que to dizendo é que se vc não sabe muita coisa e tem pouca experiência em gestão de serviços, a leitura de ITIL (e se possível experiência pratica como estagiário) vai ser melhor que nada. Claro que nos anos 80, quando não existia ITIL, os gestores pensavam em manter o ciclo de vida dos processos internos de suas empresas vivos, só que agora, a ITIL reúne praticas de sucesso que estas empresas utilizam. A ITIL com certeza não é completa e nunca vai ser, porque obviamente mundo evolui. cada empresa adapta os métodos que acha que lhes convêm.

Impossivel:

Não é que não preciso alterar funcionalidades antes mesmo de entrar em produção, é que se precisar fazer na versão em desenvolvimento, não vai afetar em nada o build que está sendo testado pra entrar em produção.

Isso depende da qualidade do código escrito, depende do quanto de duplicação de código existe, do quanto a intenção do código é clara. Se um programador tem que levar horas pra ler e entender um código feito por outro, ou por ele mesmo as vezes, isso causa efeito na data de entrega e atinge diretamente o cliente. Por isso ter código de qualidade faz diferença. Um código difícil de entender ou cheio de duplicações pode causar efeitos inesperados, mesmo em partes que já se consideravam prontas.

É isso que eu quero dizer com “dar manutenção em código antes dele entrar em produção”. Não sei como é nos games, mas não deve ser tão diferente. Muitas vezes o cliente muda de ideia, outras nós não conseguimos entender o que ele queria a princípio, outras ele lembra de algo que havia esquecido de dizer, outras vezes ele tem uma ideia maravilhosa que não pode ficar de fora (e que muitas vezes é fantástica mesmo e faz todo sentido que seja feita naquela hora).

E assim vamos, e pra que nós possamos dar aos nossos clientes essa possibilidade precisamos manter um código limpo, usando da melhor forma que podemos todas as ferramentas que temos em mãos. Isso também faz parte de “ter o cliente como foco principal”.

O que eu disse desde o princípio, e talvez não tenha sido claro realmente é: Conhecer ferramentas, técnicas, frameworks e saber a hora de usá-los e não usá-los faz parte do pacote “Foco no cliente.”

Digo e repito, eu já vi muita coisa mal feita sob a desculpa de que o cliente não se importa com nada disso. Vai se importar quando refletir nele o problema.

O texto é enorme.
Se refere ao eleito Lindy um fator para quebrar a ordem interna?
“eventos inesperados em um mundo imprevisível e que elas tenham a consciência e aceitem que esses eventos, uma hora ou outra, acontecerão”.
Riscos, todos temos. Podemos sair hoje de casa e amanhã de tarde estarmos enterrados.
Se puder explicar melhor… em resumo.

Em ITIL, por exemplo, um estágio do ciclo de vida do serviço: “Estratégia do serviço” é o responsável por fazer a análise de mercado e avaliar os riscos.

javaflex:

Concordo com seu comentário, o que eu queria dizer é que isso nem deveria precisar ser mencionado. Mas existem desenvolvedores que não tem realmente essa visão.
É preciso mencionar pois não é tão difícil um dia saber de situações do tipo, com mais chances de encontrar em lugares que arquitetos vivem no mundo da Lua da TI, definindo padrões sem envolvimento com a realidade do dia-a-dia do desenvolvimento x usuário.

O que na prática tenho passado e achado ideal, é a equipe poder definir junto, isso leva mais ao equilíbrio. Claro que os seniors vão naturalmente ter maior grau de contribuição e peso, mas nada impede do júnior de repente saber de uma novidade técnica que resolva melhor uma nova funcionalidade que o usuário precisa, onde a maioria aceita e depois passa pela prova de conceito. Além claro, da soma de ideias poder formar uma grande ideia. Assim todos vão estar mais envolvidos para o mesmo objetivo, que é o atendimento das necessidades dinâmicas do usuário.

Só para deixar claro que costumo falar relacionado ao cenário de sistemas de informações.

Também sou adepto deste pensamento. Desta forma cada um pode dar contribuição em qualquer parte que entenda. O modelo fordista já é mais paranoico. Quer apenas que os funcionários saibam apenas uma fração do processo. Esta é uma estratégia que considero ruim porque se torna igual a um formigueiro. Se a rainha morre, toda a colônia morre. A idéia da internet é genial pela forma como se pode contornar este tipo de problema. Difundindo o conhecimento dentro do sistema além de gerar mais confiança nos colaboradores, garantimos que não existam gargalos em uma única pessoa. O conhecimento, assim como ovos, não devem ser guardados em uma única cesta.

Na verdade o texto é um resumo, você pode pesquisar sobre o autor se quiser…

O importante é que o autor provou matematicamente que estruturas como as que você sugere são menos efetivas e quando tem algum erro, se espalha rapidamente provocando caos (basta uma decisão errado do arquiteto para haver deterioramento da qualidade do produto final).

Sem falar na necessidade que essas empresas tem de externalizar os riscos no cliente.

Talvez isso explica porque a CentralIT tem tantos clientes no governo, mesmo não sendo empresa que seja conhecido por criar software de qualidade?

Luiz Augusto Prado:

Riscos, todos temos. Podemos sair hoje de casa e amanhã de tarde estarmos enterrados.

Interessante, porque nessa thread você insinuou que desenvolvimento de software devia ser livre de riscos para os desenvolvedores.

Está pedalando pra trás agora?

Ok, não é baseado no QI… mas sim quem lambe melhor a bunda do gestor.

Saquei.

YvGa:

Isso depende da qualidade do código escrito, depende do quanto de duplicação de código existe, do quanto a intenção do código é clara. Se um programador tem que levar horas pra ler e entender um código feito por outro, ou por ele mesmo as vezes, isso causa efeito na data de entrega e atinge diretamente o cliente. Por isso ter código de qualidade faz diferença. Um código difícil de entender ou cheio de duplicações pode causar efeitos inesperados, mesmo em partes que já se consideravam prontas.

Então é só contratar programadores que escrevem código de qualidade, e todos vão ficar milionários? Não precisa focar no produto?

Entendo seu ponto de vista, mas discordo.

YvGa:

É isso que eu quero dizer com “dar manutenção em código antes dele entrar em produção”. Não sei como é nos games, mas não deve ser tão diferente. Muitas vezes o cliente muda de ideia, outras nós não conseguimos entender o que ele queria a princípio, outras ele lembra de algo que havia esquecido de dizer, outras vezes ele tem uma ideia maravilhosa que não pode ficar de fora (e que muitas vezes é fantástica mesmo e faz todo sentido que seja feita naquela hora).

É diferente no sentido de que todos os envolvidos precisam saber o que estão fazendo. Não existe “documento de requisitos” pra se apoiar. Você precisa focar no produto.

Você já viu games sendo desenvolvido primeiro coletando requisitos??? hehehe

YvGa:

E assim vamos, e pra que nós possamos dar aos nossos clientes essa possibilidade precisamos manter um código limpo, usando da melhor forma que podemos todas as ferramentas que temos em mãos. Isso também faz parte de “ter o cliente como foco principal”.

O que é ótimo, mas um tanto offtopic, visto que o tópico é sobre focar no produto, e não no cliente.

YvGa:

O que eu disse desde o princípio, e talvez não tenha sido claro realmente é: Conhecer ferramentas, técnicas, frameworks e saber a hora de usá-los e não usá-los faz parte do pacote “Foco no cliente.”

ver meu comentário acima.

YvGa:

Digo e repito, eu já vi muita coisa mal feita sob a desculpa de que o cliente não se importa com nada disso. Vai se importar quando refletir nele o problema.

Novamente. O responsável por algo “mal feito” tem todo o motivo pra ocultar os verdadeiros motivos do seu fracasso e culpar outros de fora da equipe.

Impossivel:

Interessante, porque nessa thread você insinuou que desenvolvimento de software devia ser livre de riscos para os desenvolvedores.

Acho que já lhe falaram umas 3 vezes que ninguém disse isso.
É troll.

Impossivel:

Luiz Augusto Prado:

Também sou adepto deste pensamento. Desta forma cada um pode dar contribuição em qualquer parte que entenda.

Está pedalando pra trás agora?

Não, to dizendo que vc tem que engrenar com o que tem. O ideal é que todo mundo saiba o máximo. Vc vai conseguir isso facilmente? Não. É dificl de conseguir todos da empresa saberem tudo. Então se vira com o que tem e delega no máximo aquilo que cada um é capaz de executar.
é troll.

Impossivel:

Ok, não é baseado no QI… mas sim quem lambe melhor a bunda do gestor.
Saquei. :P

Luiz Augusto Prado:

Impossivel:

Luiz Augusto Prado:

Também sou adepto deste pensamento. Desta forma cada um pode dar contribuição em qualquer parte que entenda.

Está pedalando pra trás agora?

Não, to dizendo que vc tem que engrenar com o que tem. O ideal é que todo mundo saiba o máximo. Vc vai conseguir isso facilmente? Não. É dificl de conseguir todos da empresa saberem tudo. Então se vira com o que tem e delega no máximo aquilo que cada um é capaz de executar.
é troll.

Não creio que seja possível delegar pra um júnior algo como “focar no produto”.

Pra isso ele vai ter que ter o conhecimento que você tem na torre de marfim. Lamento se isso parece ofensivo pra alguns, mas me parece ser o único jeito. Senão, no máximo o júnior estará limitado a tarefas banais que podem ser delegadas, como fazer CRUDs, e implementar DAOs, ou seja, o correspondente a um pedreiro ou técnico de elevadores do mundo digital.

Talvez essa seja a “desvantagem” de focar no produto? Você precisa de uma equipe de profissionais competentes que sabem o que estão fazendo… ou um arquiteto com superpoderes.

Qual dos dois você acha que é mais fácil conseguir não sei, mas sei qual pode criar software com foco no produto. Dica: não é o arquiteto com superpoderes.

Resumo

ué voltou!?

ué voltou!?
Trollzinho querido, você é divertido, eu nunca nem saí… Só não me preocupo mais em tentar te explicar a opinião que já dei e que você insiste em dizer que todos os burros daqui disseram que focar no produto não é importante… Mas estou acompanhando as outras opiniões pois sempre podemos tirar proveito delas.

Já que você é um renomado profissional de games, focado em produtos, talvez se explicarmos a opinião, de que ninguém aqui nesse post disse que “não se deve dar importância e foco no produto” e sim que isso não deve ser desculpa pra se fazer qualquer merda de software, em forma de jogo você vai conseguir entender?

Funcionaria, pois em interpretação de texto já está provado que é “Impossível”.

Aliás conte aí pra nós, quais games você já desenvolveu? Tem um portfólio? Trabalha em alguma empresa com portfólio?

Talvez avaliando o seu trabalho com o “foco no produto”, cheguemos a conclusão de que ainda não temos maturidade o suficiente pra acompanhar suas ideias.

Conta aí… Se apresente e apresente o seu trabalho.

adriano_si:

Já que você é um renomado profissional de games, focado em produtos, talvez se explicarmos a opinião, de que ninguém aqui nesse post disse que “não se deve dar importância e foco no produto” e sim que isso não deve ser desculpa pra se fazer qualquer merda de software, em forma de jogo você vai conseguir entender?

Funcionaria, pois em interpretação de texto já está provado que é “Impossível”.

Seria ótimo.

Quem vai criar o jogo?

adriano_si:

Aliás conte aí pra nós, quais games você já desenvolveu? Tem um portfólio? Trabalha em alguma empresa com portfólio?

Talvez avaliando o seu trabalho com o “foco no produto”, cheguemos a conclusão de que ainda não temos maturidade o suficiente pra acompanhar suas ideias.

Conta aí… Se apresente e apresente o seu trabalho.

Não vejo como avaliando meu trabalho você pode chegar a alguma conclusão sobre sua própria capacidade.

No mais, meus jogos estão disponíveis pra qualquer um. É só pagar o preço de mercado. Porque acha que tenho que te dar alguma coisa de graça?

Longe de mim… Quero somente ver os jogos desenvolvidos e claro, se gostar, pagarei por eles… Já que você trabalha com foco no Produto voltado para seu cliente, você deve ter um Portfólio apresentando seus jogos não?

Sou um cliente em potencial e quero pelo menos ver a apresentação de seus jogos. Ou são jogos do mercado negro que tenho que conhecer alguém que já tenha pra me fazer um convite?

Não pedi seus jogos pra mim, quero ver e avaliá-los. Não tem um site sequer apresentando seus jogos?

É que focos tão grande no produto com resultados tão brilhantes devem fazer com que revejamos nossos conceitos. Não tem nada a ver com capacidade, mas sim com conceitos, afinal qualidade de código, arquitetura de software, ciclo de desenvolvimento, etc. são assuntos discutidos até mesmo por grandes produtoras de jogos como a Blizzard. Elas também tem que lidar com manutenção de Software em produção e coisas do tipo… Coisas que você afirmou nesse post que não precisa por ter foco em produtos.

Então nos mostre seus produtos, seu portfólio, eu quero ver, quem sabe comprar e avaliar o resultado do “foco no produto”. É pedir muito?

Para cada projeto de negócio diferente, ele vai ser assim. Cabe ao analista entender e abstrair em um código fonte o novo negócio, algo que vai realizar com ajuda do cliente, de sua experiência e seus conhecimentos técnicos.

kkkkkkkkkk

Ué? Não vou poder jogar um jogo com foco no produto mesmo? Esperei ontem o dia todo pra adquirir uns produtos de qualidade, se tiver que esperar mais hoje não vou aguentar… Quero passar o final de semana desfrutando dos prazeres e da qualidade do “foco no produto”.

Sem dúvida, me manda uma MP que resolvo pra vc.

Luiz Augusto Prado:

Impossivel:

Interessante, porque nessa thread você insinuou que desenvolvimento de software devia ser livre de riscos para os desenvolvedores.

Onde que eu disse que a cobertura dos riscos é de 100%?
É troll.

Acho que já lhe falaram umas 3 vezes que ninguém disse isso.
É troll.

O Yvga está dizendo que focar numa boa arquitetura significa focar no produto, enquanto você está dizendo que analistas são os banbanbans e que programadores devem ser peões de obra.

Argumentos completamente diferentes, não entendi porque esta misturando minhas respostas para o Yvga com as minhas respostas pra você??

MP enviada. Só acho que poderias divulgar por aqui os jogos, afinal outras pessoas podem querer jogar. Você não tem mesmo um site com o Portfólio?

No aguardo Impossivel.

MP enviada. Só acho que poderias divulgar por aqui os jogos, afinal outras pessoas podem querer jogar. Você não tem mesmo um site com o Portfólio?

Quando foi a última vez que comprou um jogo olhando portfólios? rs

Eu sou assinante Steam: http://store.steampowered.com/

Sendo assim, acho que os últimos jogos que comprei, foram com base em portfólios. rs

No aguardo do da sua empresa

“Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.”

http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

Gosto de pensar que no fim das contas o que importa é dinheiro no bolso. Se para determinado problema, fazer código *elegante e bem testado vai reduzir custos, maravilha. Senão, pragmatismo com soluções simples é mais econômico.

• pela minha experiência, vendo pessoas que vêem código de outrem, noto que a maioria da galera indiretamente tem uma postura onde “o código do outro nunca é elegante. Apenas o meu”. Ou seja, é mais fácil jogar fora e reescrever tudo colocando a culpa no outro para que eu possa escrever um código que entenda: o meu.

Perfeito! Os jogos que fiz, e estão no meu portfólio (impossível, eu também queria ver seu portfólio), são simples assim. Usei as técnicas feijão com arroz que li na internet e na época atenderam a necessidade. Mas, com certeza não poderia ter feito o mesmo se eu fosse produzir um “War thunder” ou um “sniper elite” que são jogos muito complexos.

Perfeito! Os programas que fiz, e estão no site da empresa que trabalhei, são complexos mas usei as técnicas da ITIL pra vencer a licitação pública e agora posso contratar um monte de júnior pra fazer o meu trabalho. Mas, com certeza não poderia ter feito o mesmo se fosse produzir um produto pro mercado consumidor porque além do governo, quem seria estúpido pra pagar por um software feito por júniores?

Luiz Augusto Prado:

leandronsp:

Gosto de pensar que no fim das contas o que importa é dinheiro no bolso. Se para determinado problema, fazer código *elegante e bem testado vai reduzir custos, maravilha. Senão, pragmatismo com soluções simples é mais econômico.

Perfeito! Os jogos que fiz, e estão no meu portfólio (impossível, eu também queria ver seu portfólio), são simples assim. Usei as técnicas feijão com arroz que li na internet e na época atenderam a necessidade. Mas, com certeza não poderia ter feito o mesmo se eu fosse produzir um “War thunder” ou um “sniper elite” que são jogos muito complexos.

Está dizendo que esses estúdios usam técnicas do ITIL, e não técnicas feijão com arroz como “focar no produto”?

Cara, desculpe, de boa, entrar na sua discussão com o Luiz. Eu só quero mesmo ver o portfólio de seus jogos. Se os jogos são da empresa, creio que a empresa tem um site pra vender os jogos não? Ou que empresa é essa que esconde os jogos que tem? Só vende pra selecionados ou pessoas de um mercado obscuro?

Só quero ver os jogos, lembrando que o que quero é comprovar a técnica de “foco no produto” que os reles mortais do GUJ não foram capazes de entender. Como um colega falou, isso deve ser a bala de prata da TI e avaliando a qualidade desse trabalho, podemos chegar a conclusão que estamos todos errados e que o novo programador “não antissocial e ranzinza e focado no produto” seja o cara certo.

Só o portfólio… De boa. Pois já faz semana que estou esperando e não entendo mesmo porque ainda não recebi um link ou que quer que seja pra ver os jogos produzidos com foco no produto.

adriano_si:

Cara, desculpe

Está desculpado!

Impossivel:

adriano_si:

Cara, desculpe

Está desculpado!

adriano_si:

Ficou feio campeão… ;)

Desculpa, você tem algum argumento ou está tentando dizer alguma coisa?

Impossivel:

adriano_si:

Ficou feio campeão… ;)

Desculpa, você tem algum argumento ou está tentando dizer alguma coisa?

Uma pena você não ser homem o suficiente pra colocar o seu nome e assinar suas opiniões.

Agora sim, sem mais.

Parem de brigar e exigir que ele mande algum portfólio! É a opinião dele, em que o mais importante é focar no produto em detrimento de processos burocráticos (se foi isso que entendi).

Na maioria dos projetos de sucesso em que trabalhei, o foco era no produto, mantendo sempre o bom equilíbrio entre onde fazer algo escalável e onde fazer algo ali, simples, em poucas horas, com as ferramentas que tínhamos no momento.
Já projetos burocráricos, com separação de “analista” x “desenvolvedor” (wtf?), follow de práticas etc, bom…no meu caso não tiveram o sucesso que era esperado.

Na minha humilde experiência, o que aprendi sempre foi: pragmatismo dá dinheiro. O resto (técnicas arcaicas de requisitos, se prender a apenas um modelo de desenvolvimento, bibliotecas de boas práticas e whatever) é bullshit. Desculpem a sinceridade.

Alguns links pra enriquecer a discussão:

“O código do outro nunca é bom”
Biases in Software Engineering

“Murro em ponta de faca”
Why Don’t Software Development Methodologies work

“Users valorizam aquilo que (obviamente) produz valor real”
Digital IKEA Effect

“E por último, Just do it!”
Programming, Motherf*cker

leandronsp:

“Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.”

http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

Gosto de pensar que no fim das contas o que importa é dinheiro no bolso. Se para determinado problema, fazer código *elegante e bem testado vai reduzir custos, maravilha. Senão, pragmatismo com soluções simples é mais econômico.

• pela minha experiência, vendo pessoas que vêem código de outrem, noto que a maioria da galera indiretamente tem uma postura onde “o código do outro nunca é elegante. Apenas o meu”. Ou seja, é mais fácil jogar fora e reescrever tudo colocando a culpa no outro para que eu possa escrever um código que entenda: o meu.

Veja que essa postura é justificada se você delega a atividade de codificação para júniores, como foi sugerido nessa thread.

O que define um junior é que ele não ainda não sabe escrever código “elegante” e funcional.

Com certeza o pessoal de lá, mesmo os juniores e os estagiários, dão de 10 a zero em vc pelo simples fato deles darem as caras à tapa. Qualquer um sabe como chegar até mim quando eu fizer ou falar alguma merda e eu estou pronto para assumir qualquer consequência perante meus atos. Mas e vc? Como vai conseguir alguma credibilidade de nós agora? Só quer ver o circo pegar fogo. Acha que tá dando certo? O circo só poderá lhe dar lucro vc se expor. Ai, poderemos avaliar se vc faz ou não parte da estatística do retardado com dinheiro na mão ou é mais um recém formado sem experiência à procura de emprego.
Aparentemente vc faz parte da primeira opção por menosprezar o esforço dos outros (Só o produto importa?) e se esconder. Mas se for da segunda opção, só posso lhe dizer que lhe entendo, apesar de não concordar com a forma como está se referindo aos meus colegas. O que os meus colegas, sendo ou não juniores, tem a ver com o seu problema ou um problema entre eu e vc (só vc tá vendo pq pra mim, eu e mesmo vc tem o direito de pensar diferente)?

Não existe bala de prata.

leandronsp:

Na maioria dos projetos de sucesso em que trabalhei, o foco era no produto, mantendo sempre o bom equilíbrio entre onde fazer algo escalável e onde fazer algo ali, simples, em poucas horas, com as ferramentas que tínhamos no momento.
Já projetos burocráricos, com separação de “analista” x “desenvolvedor” (wtf?), follow de práticas etc, bom…no meu caso não tiveram o sucesso que era esperado.

Na minha humilde experiência, o que aprendi sempre foi: pragmatismo dá dinheiro. O resto (técnicas arcaicas de requisitos, se prender a apenas um modelo de desenvolvimento, bibliotecas de boas práticas e whatever) é bullshit. Desculpem a sinceridade.

Você leu o tópico todo? Se não, vou resumir:

Se leu o post entendeu o que o autor do link original quis dizer. O Yvga complementou dizendo que tem “medo” desse foco no produto, pois ele já viu muita cagada ir pra produção simplesmente com a desculpa de que o foco tem que ser no produto e que na opinião dele, se preocupar com a arquitetura é também focar no produto, tendo em vista que o tempo de manutenção ficará menor, facilitando a resposta à mudanças. E o Javaflex finalizou dizendo que pra ele, nem 8, nem 80, pois também todos já vimos projetos de Software morrerem tentando encontrar o processo ideal, sem desenvolver software.

O amigão aí tentou, porque tentou dizer que o “foco no produto” é tudo o que importa e não concordou com o equilíbrio que propomos à conversa. Pra corroborar sua tese, ele disse que trabalha com Games e que isso era suficiente pra provar que o que ele dizia era a verdade absoluta. Pedí o portfólio de games dele, ou da empresa onde ele trabalha… É pedir muito? Você acha que isso é pedir muito? Não tô enchendo o saco, tô querendo validar uma opinião de alguém que a colocou como verdade absoluta. Nada mais justo do que ele mostrar o resultado do foco no produto.

EU não defendi processos, eu defendi equilíbrio, pois código lixo não te ajuda a responder a mudanças e não interessa onde você está, se no mundo corporativo ou montando sua empresa, se seu software não é adaptável (garantido pela sua arquitetura), não existe o tal “foco no produto”.

Então sim, ainda estou esperando o portfólio, pois ele estufou o peito e gritou aos 4 cantos do fórum que ele trabalha com games e que isso era prova cabal de que estava certo. Quero ver. Posso?

Impossivel:

como foi sugerido nessa thread.

O que define um junior é que ele não ainda não sabe escrever código “elegante” e funcional.

Realmente interpretou bem mal as opiniões.

adriano_si:

Todos os que acompanharam esse tópico até aqui ou o lerão no futuro irão entender o que eu quero dizer

Uma pena você não ser homem o suficiente pra colocar o seu nome e assinar suas opiniões.

Agora sim, sem mais.

Você tem algum argumento pra fazer no presente porque não sei se vou estar acompanhando o tópico no futuro.

ps: vou ignorar os “ataques” a minha masculinidade.

leandronsp:

Parem de brigar e exigir que ele mande algum portfólio! É a opinião dele, em que o mais importante é focar no produto em detrimento de processos burocráticos (se foi isso que entendi).

Entendeu errado.
Tentou curtir com a minha cara e da dos meus colegas… Agora eu quero ver o portfólio dele.

Claro, força!

Concordo que tem de haver o equilíbrio, a teoria do “nem 8 nem 80”, ficar na média, “não existe bala de prata”, enfim…concordo plenamente mas esse equilíbrio é o grande desafio! Eu nunca vi tal equilíbrio na prática, onde na verdade vi equipes que sempre tiveram uma tendência a ir a um dos extremos, dependendo da cultura.

A equipe X tinha uma cultura mais ágil, no início todo mundo naquela ideia do “não existe bala de prata”, mas a cultura da própria foi levando naturalmente aos poucos para um cenário onde “o que importa é o produto apenas”. Códigos sem teste, deploy sem processo decente, tudo rápido, mas com bugs estourando na cara do usuário na bruta.

Já a equipe Y, começou também em cima do muro, mas a cultura defensiva e baseada em processos tanto de hierarquia quanto aplicacionais os levou a um sistema “livre de erros” (mentira, tinha muito bug enrustido), bonito (pesado) e sem (ou nenhum) usuário.

O equilíbrio é lindo, mas (continuando em cima do muro) vai depender da CULTURA da equipe. A cultura leva ao resultado final. IMHO.

adriano_si:

Impossivel:

como foi sugerido nessa thread.

O que define um junior é que ele não ainda não sabe escrever código “elegante” e funcional.

Você não poderia ser mais contraditório amigo. Estamos dizendo que uma boa arquitetura é o equilíbrio necessário para o foco no produto. Isso NÃO PODE ser feito por Juniores.

Realmente interpretou bem mal as opiniões.

Caso não tenha percebido, seus posts não estão acrescentando nada a discussão.

Eu entendo a sua frustração quando não consegue entender alguma coisa, mas não precisa transformar a thread em um drama particular por causa da sua incapacidade de analisar argumentos independente de quem o fez.

Então vai continuar atrapalhando ou vai deixar os adultos conversarem?

Claro, força!

Concordo que tem de haver o equilíbrio, a teoria do “nem 8 nem 80”, ficar na média, “não existe bala de prata”, enfim…concordo plenamente mas esse equilíbrio é o grande desafio! Eu nunca vi tal equilíbrio na prática, onde na verdade vi equipes que sempre tiveram uma tendência a ir a um dos extremos, dependendo da cultura.

A equipe X tinha uma cultura mais ágil, no início todo mundo naquela ideia do “não existe bala de prata”, mas a cultura da própria foi levando naturalmente aos poucos para um cenário onde “o que importa é o produto apenas”. Códigos sem teste, deploy sem processo decente, tudo rápido, mas com bugs estourando na cara do usuário na bruta.

Já a equipe Y, começou também em cima do muro, mas a cultura defensiva e baseada em processos tanto de hierarquia quanto aplicacionais os levou a um sistema “livre de erros” (mentira, tinha muito bug enrustido), bonito (pesado) e sem (ou nenhum) usuário.

O equilíbrio é lindo, mas (continuando em cima do muro) vai depender da CULTURA da equipe. A cultura leva ao resultado final. IMHO.
Perfeito Leandro, no final das contas, temos que continuar sempre o buscando, concorda? Era sobre isso que falávamos até tentar jogar xadrez com o pombo… Ele chegou chutou todas as peças e ainda estufou o peito como vencedor da discussão.

Impossivel:

ps: vou ignorar os “ataques” a minha masculinidade.

Não esse que você quotou, esse foi pra tentar explicar (mais uma vez) o quanto você desvirtuou as opniões dadas até o momento.

Eu imagino o quanto você entende.

Não, vou sair pro parquinho e deixar os adultos conversarem. No mais amigão, você na fase adulta da vida, poderia ouvir a criança aqui.

Profissionais de verdade assinam suas opiniões mostrando seu nome. É assim que homens adultos agem. Eles, quando montam suas empresas e seu negócio, ou até mesmo seus currículos, apresentam seus trabalhos através de portfólios.

Você vomitou que era “O Cara” porque trabalhava com jogos. Estou até agora querendo ver algum produto feito por você. Eu não posso apresentar pra você meu trabalho, pois trabalho prestando serviço para um Banco e realmente, a menos que você venha aqui pra ver, não tem como eu disponibilizar. Mas é realmente estranho, MUITO ESTRANHO eu não consegui ver o que uma empresa de JOGOS produziu. Dá uma dica aí pros adultos da sua empresa, montem um site apresentando o trabalho “focado no produto e totalmente despreocupado com a arquitetura” que vocês desenvolveram.

Valeu tio.

adriano_si:

Perfeito Leandro, no final das contas, temos que continuar sempre o buscando, concorda? Era sobre isso que falávamos até tentar jogar xadrez com o pombo… Ele chegou chutou todas as peças e ainda estufou o peito como vencedor da discussão.

Você representa um grupo de pessoas ou é esquisofrênico? :\

Com certeza o pessoal de lá, mesmo os juniores e os estagiários, dão de 10 a zero em vc pelo simples fato deles darem as caras à tapa. Qualquer um sabe como chegar até mim quando eu fizer ou falar alguma merda e eu estou pronto para assumir qualquer consequência perante meus atos. Mas e vc? Como vai conseguir alguma credibilidade de nós agora? Só quer ver o circo pegar fogo. Acha que tá dando certo? O circo só poderá lhe dar lucro vc se expor. Ai, poderemos avaliar se vc faz ou não parte da estatística do retardado com dinheiro na mão ou é mais um recém formado sem experiência à procura de emprego.
Aparentemente vc faz parte da primeira opção por menosprezar o esforço dos outros (Só o produto importa?) e se esconder. Mas se for da segunda opção, só posso lhe dizer que lhe entendo, apesar de não concordar com a forma como está se referindo aos meus colegas. O que os meus colegas, sendo ou não juniores, tem a ver com o seu problema ou um problema entre eu e vc (só vc tá vendo pq pra mim, eu e mesmo vc tem o direito de pensar diferente)?

Não existe bala de prata.

Por definição, Junior não sabe criar código “elegante” e funcional. Se você acha que isso ofende os juniores não posso fazer nada, porque isso é um fato.

adriano_si:

leandronsp:

Na maioria dos projetos de sucesso em que trabalhei, o foco era no produto, mantendo sempre o bom equilíbrio entre onde fazer algo escalável e onde fazer algo ali, simples, em poucas horas, com as ferramentas que tínhamos no momento.
Já projetos burocráricos, com separação de “analista” x “desenvolvedor” (wtf?), follow de práticas etc, bom…no meu caso não tiveram o sucesso que era esperado.

Na minha humilde experiência, o que aprendi sempre foi: pragmatismo dá dinheiro. O resto (técnicas arcaicas de requisitos, se prender a apenas um modelo de desenvolvimento, bibliotecas de boas práticas e whatever) é bullshit. Desculpem a sinceridade.

Mas quem foi que disse que a opinião dos que aqui escreveram era a de que queríamos nos amarrar a um único processo?

Você leu o tópico todo? Se não, vou resumir:

Se leu o post entendeu o que o autor do link original quis dizer. O Yvga complementou dizendo que tem “medo” desse foco no produto, pois ele já viu muita cagada ir pra produção simplesmente com a desculpa de que o foco tem que ser no produto e que na opinião dele, se preocupar com a arquitetura é também focar no produto, tendo em vista que o tempo de manutenção ficará menor, facilitando a resposta à mudanças. E o Javaflex finalizou dizendo que pra ele, nem 8, nem 80, pois também todos já vimos projetos de Software morrerem tentando encontrar o processo ideal, sem desenvolver software.

O amigão aí tentou, porque tentou dizer que o “foco no produto” é tudo o que importa e não concordou com o equilíbrio que propomos à conversa. Pra corroborar sua tese, ele disse que trabalha com Games e que isso era suficiente pra provar que o que ele dizia era a verdade absoluta. Pedí o portfólio de games dele, ou da empresa onde ele trabalha… É pedir muito? Você acha que isso é pedir muito? Não tô enchendo o saco, tô querendo validar uma opinião de alguém que a colocou como verdade absoluta. Nada mais justo do que ele mostrar o resultado do foco no produto.

EU não defendi processos, eu defendi equilíbrio, pois código lixo não te ajuda a responder a mudanças e não interessa onde você está, se no mundo corporativo ou montando sua empresa, se seu software não é adaptável (garantido pela sua arquitetura), não existe o tal “foco no produto”.

Então sim, ainda estou esperando o portfólio, pois ele estufou o peito e gritou aos 4 cantos do fórum que ele trabalha com games e que isso era prova cabal de que estava certo. Quero ver. Posso?

O mais importante, e que você convenientemente ignorou no seu resumo, é a resposta de quem tem medo, que nunca havia sido perguntado por exemplo como o algorítmo genético pra geração das grades horarias seria melhor para alunos e professores.

Ora… se você não sabe como uma funcionalidade afeta o usuário do software (ou “se por no lugar do usuário” como o autor do texto se refere), como pode dizer que isso é foco no produto?

LOL… não pode… mas pode distorcer os fatos…

boa sorte no seu projeto loser!

EU não defendi processos, eu defendi equilíbrio, pois código lixo não te ajuda a responder a mudanças e não interessa onde você está, se no mundo corporativo ou montando sua empresa, se seu software não é adaptável (garantido pela sua arquitetura), não existe o tal “foco no produto”.

Então sim, ainda estou esperando o portfólio, pois ele estufou o peito e gritou aos 4 cantos do fórum que ele trabalha com games e que isso era prova cabal de que estava certo. Quero ver. Posso?

Não é que estou certo, é que estou apresentando um argumento (de que focar no produto é um caminho pra se desenvolver software que se adapta as necessidades do usuário) que tem algumas similaridades com o do autor.

Você não apresentou argumento nenhum, só que busca o “equilibrio”. rs

Se tem alguém defendendo código lixo é quem disse que codificar é tarefa para júniores, porque júnior não sabe criar código que não é lixo, se soubesse seria pleno, sênior… e não júnior.

Na verdade, não existe qualquer relação entre focar no produto e produzir código lixo, mas é verdade que, baseado na minha experiência, programadores bitolados e que não confiam no seu talento costumam torcer o nariz para o usuário (em outras palavras, são antissociais), então é natural que tais programadores tenham medo de focar no produto e venham até tentar criar alguma relação nesse sentido pra tentar justificar seu medo.

Yvga falou: Não se pode usar a desculpa de que tem que ter mais foco no produto pra poder mandar qualquer porcaria pra produção.

Javaflex complementou: Mas o que autor quis dizer é que o foco em excesso na arquitetura não pode simplesmente tirar teu foco em resolver os problemas do cliente, apesar de crer que o Yvga tem razão, ou seja, não pode ser nem 8, nem 80.

Eu: concordei com o Javaflex…

adriano_si:

Achei sua definição perfeita… Nem é pra se focar só nisso, nem pra esquecer de vez. Por isso dá pra entender a preocupação do Yvga, pois se preocupar com manutenção de baixo custo e fácil escalabilidade é também pensar no seu cliente.

A verdade é que a complexidade de se gerar software de qualidade está realmente em ENCONTRAR esse equilíbrio entre o que fazer e o que não fazer e também o quão fundo ir em direção a requisitos não funcionais.

Todavia, esse discurso de “o que importa é fazer algo que o cliente usa” apesar de BEM verdadeiro pode ser perigoso se cair em mãos erradas.

Você respondeu até que me fazendo pensar sobre algumas coisas e reler algumas opiniões até que começou a disparar:
“Falando como se todo software fosse precisar escalar e sofrer manutenção constante…”

Depois respondeu ao Luiz:
“Concordo. Mas o que está sendo dito é que o desenvolvedor não esta nem ai pro produto que está sendo desenvolvido porque ele acha que pode fazer a coisa bem feita apenas focando nas técnicas e frameworks que existem. Disso não estou convencido.”

Destaco a parte em que diz o seguinte “Mas o que está sendo dito…” onde até então NINGUÉM tinha dito isso. Então pedi um Quote pra você onde que alguém tinha dito isso NESSA DISCUSSÃO e você manda um link com todo o histórico de perguntas de Frameworks do GUJ inteiro. Aí eu desisti tendo em vista que você é um fake que criou um usuário qualquer pra se esconder durante aquela discussão do PJ.

Só que depois eu tive que ler a seguinte resposta ao Yvga: “Não sei, desculpa por não ter a bala de prata que vc busca. Como falei, eu trabalho com jogos”

Aí eu fiquei curioso e pedi o portfólio de sua empresa/seu, tanto faz…

Aí você me chama de loser (o desenvolvedor de jogos que não divulga os jogos que desenvolveu e não possui portfólio, me chamando de loser. Pode?) e responde novamente o que eu quotei lá em cima.

Repetindo o quote:

A discussão começa exatamente com o Yvga falando da importância de uma arquitetura consistente de Software e você vem dizer que o que todo mundo está dizendo é que codificar “é tarefa pra júnior”, quando ninguém falou isso aqui. Enfim.

Bom Winner… Agora o resumo ficou bom, ou você também quer as páginas dos trechos que eu citei?

Exato, ninguém disse que tem. Se você reler a primeira opinião do Yvga ela diz em suma:

Ele disse aqui em algum momento que focar no produto está atrelado a fazer código lixo? Não, mas eu entendi a sua confusão, pois o que ele falou é que há pessoas produzindo “lixo” rápido com a desculpa que está “focando no cliente/produto” ou realmente você não interpretou assim?

Mais uma vez eu peço. QUOTE (DESSA THREAD EM QUE ESTAMOS) um trecho onde alguém defende a ideia que “focar no produto = software lixo”.

Mas você usou de ironia ao afirmar

Como se todo mundo que trabalha para algum cliente estivesse produzindo software que “não resolve problemas reais”.

Losers, sempre vendo o mundo em binário…

Prove. Cite o trecho onde me refiro a “todo mundo”.

Onde pode-se entender que trabalhos “mais genéricos e impactantes” é definir arquitetura, e trabalhos “mais localizados e de menor risco” é escrever código.

Paga teu portfólio troll Até lá, me retiro.

Bom, vou assumir que o desespero já está afetando sua capacidade de compreensão de texto, porque você mesmo citou os trechos onde tentam vincular foco no produto com produzir código lixo várias vezes.

Dito isso, porque ao invés de substanciar seu argumento (se é que tem algum) continua perdendo tempo com quem disse isso, quem defende aquilo. Porque você acha que alguém está interessado nisso?

Ah sim, porque você é um Loser!

adriano_si:

Paga teu portfólio troll Até lá, me retiro.

Acho que é a 4a vez que nos avisa que vai cair fora.

Interessante:

exemplo de projeto onde o líder é responsável por trabalhos “mais genéricos e impactantes”…

Tem que ter equilíbrio, acho que essa é a chave.

douglaskd:

Tem que ter equilíbrio, acho que essa é a chave.

Isso é ótimo, o problema que cada um pode ter uma definição própria do que vem a ser equilíbrio… e como chegar até ele…

Enfim, a menos que você seja mais específico seu post não tem significado nenhum.

Impossivel:

douglaskd:

Tem que ter equilíbrio, acho que essa é a chave.

Isso é ótimo, o problema que cada um pode ter uma definição própria do que vem a ser equilíbrio… e como chegar até ele…

Enfim, a menos que você seja mais específico seu post não tem significado nenhum.

se você não vê significado nisso fica difícil te ensinar, já que é uma frase tão simples…, da uma pesquisada no dicionario sobre as palavras equilíbrio depois chave, “talvez” você entenda algo.

vou facilitar pra você, pois talvez seja dificuldade da sua parte:

http://www.dicio.com.br/equilibrio/

http://www.dicio.com.br/chave/

Se você tem dificuldade de ensinar não é simples.

Talvez simplista, que é quando tendemos a simplificar algo…

Mas da uma pesquisada no dicionário por simples x simplista, talvez você entenda algo.

douglaskd:

Impossivel:

douglaskd:

Tem que ter equilíbrio, acho que essa é a chave.

Isso é ótimo, o problema que cada um pode ter uma definição própria do que vem a ser equilíbrio… e como chegar até ele…

Enfim, a menos que você seja mais específico seu post não tem significado nenhum.

se você não vê significado nisso fica difícil te ensinar, já que é uma frase tão simples…, da uma pesquisada no dicionario sobre as palavras equilíbrio depois chave, “talvez” você entenda algo.

vou facilitar pra você, pois talvez seja dificuldade da sua parte:

http://www.dicio.com.br/equilibrio/

http://www.dicio.com.br/chave/

Equilíbrio e perfeição é ambição daqueles que vivem em torres de marfim.

No mundo real tudo requer imperfeição e diversidade ou a vida não existiria.

Impossivel:

Se você tem dificuldade de ensinar não é simples.

Talvez simplista, que é quando tendemos a simplificar algo…

Mas da uma pesquisada no dicionário por simples x simplista, talvez você entenda algo.

Não preciso de dicionário, “Dificuldade de ensinar” não é simples, muito menos simplista.

O que é simples é a frase que escrevi.

Vou subjugar que você esteja dizendo que eu sou simplista, talvez o fato de você ter dificuldades no aprendizado, transpareça que eu sou simplista, mas tenho em mente que qualquer um exceto você, entendeu claramente o que eu quis dizer.

que seja… se isso te faz sentir melhor…

Está pedalando pra trás agora?

Bonito hein! Cuidado pra não dar Itil… ops tilt

Não amigo. Dos vilões, aquele com o qual mais me identifico é Roy Batty.

hehe

pode ser…

como havia falado:

o problema que cada um pode ter uma definição própria do que vem a ser equilíbrio… e como chegar até ele…

Enfim, a menos que você seja mais específico seu post não tem significado nenhum.

A sua estragégia pra isso é rebaixar programadores a posições inferiores e concentrar o conhecimento sobre o produto na mão de analistas.

Quanto a isso continuo firme na minha posição. Você não vai muito longe em TI, a não ser que encontre muitos trouxas dispostos a pagar pelo seu software produzido por juniores.

Clu:

Quanto a isso continuo firme na minha posição. Você não vai muito longe em TI, a não ser que encontre muitos trouxas dispostos a pagar pelo seu software produzido por juniores.

meh… agora a culpa é minha se nenhum sênior que ser o seu digitador de luxo?

Off topic:

Você deveria atualizar sua assinatura visto que “aquecimento global” já foi provado por cientistas que não passa de uma fraude (existe mais gelo se formando nas calotas polares do que 35 anos atrás).

O termo usado por quem defende socialismo e intervenção estatal agora é “mudança climática”.

Impossivel:

meh… agora a culpa é minha se nenhum sênior que ser o seu digitador de luxo?

Off topic:

Você deveria atualizar sua assinatura visto que “aquecimento global” já foi provado por cientistas que não passa de uma fraude (existe mais gelo se formando nas calotas polares do que 35 anos atrás).

O termo usado por quem defende socialismo e intervenção estatal agora é “mudança climática”. ;)

Hum… Boa ideia:

[youtube]http://www.youtube.com/watch?v=mwQc3DnG7xc&list=UUdGpd0gNn38UKwoncZd9rmA[/youtube]

Clu:

Sério, todos esses sênior, júnior e equilíbrio… por um momento achei que estivesse falando de uma reunião de família na yoga.

fonte do balão:

Uma coisa é concordar que precisa ter equilíbrio no design, outra coisa é dizer que o conhecimento do produto e do design da solução é responsabilidade do analista e afirmar que isso é quanto mais conhecimento melhor.

Enfim, continue postando imagens engraçadinhas, eu não ligo, mas o que eu gostaria é que você explicasse as contradições no seu argumento ao invés de usar minhas frases fora de contexto no seu exercício de comédia.

Lembrando que não existe meio-termo, ou você defende que esse conhecimento é responsabilidade do analista ou da equipe portanto, portanto a desculpa do equilíbrio não funciona aqui.

Engraçado você se referir a essa frase porque o autor dessa frase no livro No Silver Bullet - Essence and Accidents of Software Engineering, Fred Brooks, diz que programadores devem focar na solução, ou seja, o que o produto deve faz (complexidade essencial) ao invés de frameworks e patterns (complexidade acidental).

E aqui estamos ouvindo você dizer a frase dele pra fazer o argumento contrário.

adriano_si:

O amigão aí tentou, porque tentou dizer que o “foco no produto” é tudo o que importa e não concordou com o equilíbrio que propomos à conversa. Pra corroborar sua tese, ele disse que trabalha com Games e que isso era suficiente pra provar que o que ele dizia era a verdade absoluta. Pedí o portfólio de games dele, ou da empresa onde ele trabalha… É pedir muito? Você acha que isso é pedir muito? Não tô enchendo o saco, tô querendo validar uma opinião de alguém que a colocou como verdade absoluta. Nada mais justo do que ele mostrar o resultado do foco no produto.

EU não defendi processos, eu defendi equilíbrio, pois código lixo não te ajuda a responder a mudanças e não interessa onde você está, se no mundo corporativo ou montando sua empresa, se seu software não é adaptável (garantido pela sua arquitetura), não existe o tal “foco no produto”.

Então sim, ainda estou esperando o portfólio, pois ele estufou o peito e gritou aos 4 cantos do fórum que ele trabalha com games e que isso era prova cabal de que estava certo. Quero ver. Posso?

ZZZzzz…zzzZZZzzz…

[quote=Luiz Augusto Prado]

Luiz Augusto Prado:

Quanto mais saber… melhor. Pra qualquer caso. Com isso também concordo.

É claro que a forma como o produto ou serviço oferecido deve funcionar vai refletir no software desenvolvido. A abstração do produto ou serviço deve corresponder com as abstrações do funcionamento dos softwares. O arquiteto de software é quem deve estar capacitado à fazer estas correlações e é o responsável por decidir como e o que seria melhor utilizar. Muitas vezes, quem desenvolve, não tem a visão do todo (negócio), mas é capaz de executar as tarefas que lhe foram delegadas. Por que o desgosto com isso? Isso vai ocorrer sempre porque as empresas visam economia. Então, por que contratar Analista Sênior pra fazer o trabalho de Júnior sendo que podemos alocar a concentração dos sêniores por um preço maior em gargalos mais genéricos e impactantes e alocar vários júniores por preços menores para trabalhos mais localizados e de menores riscos?
Os motivos de existir cargos como por exemplo de analista de requisitos, desenvolvedores de softwares… é para que a transferência das demandas sejam filtradas e delegadas à pessoas capacitadas da empresa (toda a engrenagem pode ser encaixada). Juniores só viram seniores com tempo de experiência. Erros vão ocorrer. Se o resultado não foi o esperado, a culpa não é das técnicas ou frameworks e sim de quem as escolheu.
Se vc passa uma tarefa para um pedreiro construir sua casa, vc iria à construção somente de 4 em 4 meses pra ver como tá ficando a obra?
Atenção deve ser constante. Não existe bala de prata.
Frameworks e até técnicas vc mesmo pode criar.

Clu:

Sério, todos esses sênior, júnior e equilíbrio… por um momento achei que estivesse falando de uma reunião de família na yoga.

fonte do balão:

KKKKKK! ri muito desse Darth Vader! Não podia deixar essa passar. Up!

http://www.guj.com.br/posts/downloadAttach/10082.java