[quote=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.[/quote]
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 [] [/quote]
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.[/quote]
É 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.
[quote=Luiz Augusto Prado][quote=Impossivel]
Tu parece tão preocupado em atribuir tarefas e culpas que não percebeu que software não é cimento ou tem engrenagens.
[/quote]
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:
[quote]É 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.[/quote] 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.
[/quote]
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.
[quote=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. [/quote]
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.
[quote=javaflex]
Só para deixar claro que costumo falar relacionado ao cenário de sistemas de informações.[/quote]
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.
[quote=Impossivel][quote=javaflex]
Só para deixar claro que costumo falar relacionado ao cenário de sistemas de informações.[/quote]
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.[/quote]
Não entendi o que você quis dizer. Só deixei especificado para não considerar outros cenários que tendam a ser bem mais técnicos.
[quote=Impossivel][quote=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. [/quote]
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.
[/quote]
Na verdade… vc falou pra focar em produto sim:
[quote=Impossivel]
Sendo assim, podemos concluir que o papel do responsável pelo produto geralmente É muito mais importante do que quem foca apenas no desenvolvimento.[/quote]
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:
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.
[quote=Impossivel][quote=javaflex]
Só para deixar claro que costumo falar relacionado ao cenário de sistemas de informações.[/quote]
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.[/quote]
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?
[quote=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.
[/quote]
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.
[quote=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?[/quote]
Esse algoritmo que colequei no projeto era uma parte que o produto exigia pra funcionar como o idealizado por ele. Provavelmente ele não sabe o que seja isso muito menos que isso faria parte projeto. Só disse isso ai acima no post pra que entendam que a “idéia do produto” não é o mesmo que “produto final”. Mesmo que a ideia e a vontade sejam muito fortes, existem pre-requisitos a serem cumpridos para que elas saiam do papel. Esta era a melhor solução para a criação das grades horarias dos professores e alunos que pensei.
[/quote]
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.
[quote=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.
[/quote]
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.
Ok, boa sorte na sua busca.
Quando tiver tempo sugiro ler sobre a selagem de conhecimento citadas acima.
[quote=Luiz Augusto Prado][quote=Impossivel]
Como falei anteriormente, precisamos de um processo diferente disso, software não é cimento ou engrenagem.
[/quote]
Ok, boa sorte na sua busca.
Quando tiver tempo sugiro ler sobre a selagem de conhecimento citadas acima. [/quote]
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.
[quote=javaflex][quote=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.
[/quote]
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.[/quote]
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?
[quote=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.[/quote]
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.
[quote=Impossivel]Isso está na Bíblia…
Why should fools have money in hand to buy wisdom, when they are not able to understand it?[/quote]
Eu busco valores maiores que poder e dinheiro. Só a boa companhia já vale muito mais.
[quote=Luiz Augusto Prado][quote=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.[/quote]
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.
[/quote]
Por favor, cite empresas conhecidas por criarem software de qualidade e que usam ITIL.