Veja o caso de usabilidade, em software temos que ver fatores como, facilidade de uso, de aprendizado, de obter resultados, de navegação, simplicidade, etc. Em arquitetura, circulação, iluminação, ventilação, conforto, etc.
Não tem nada a ver?
É muito tosco ficar na comparação dos produtos finais, ou não.
[quote=A H Gusukuma]Não me constava que no mercado se compara construção civil com desenvolvimento de software no sentido que estão falando.
Nunca, em muitos anos de carreira, alguém citou alguma coisa nesse sentido. Nem usuário nem pessoal de TI.
[/quote]
Mas já deve ter ouvido falar de projetos que degeneraram em caos e produto final que foi recusado pelo cliente porque era difícil de usar ou simplesmente não atendia as reais necessidades do cliente?
[quote=lkbm][quote=A H Gusukuma]Não me constava que no mercado se compara construção civil com desenvolvimento de software no sentido que estão falando.
Nunca, em muitos anos de carreira, alguém citou alguma coisa nesse sentido. Nem usuário nem pessoal de TI.
[/quote]
Mas já deve ter ouvido falar de projetos que degeneraram em caos e produto final que foi recusado pelo cliente porque era difícil de usar ou simplesmente não atendia as reais necessidades do cliente?
[/quote]
É claro, mas o que isso tem a ver com a nossa discussão? Um projeto mal encaminhado, de qualquer área que seja, será problemático. Isso não é exclusividade de TI, mas acontece muito em TI quando se ignora as características próprias da área.
O lance de nunca ter ouvido citar comparação nesse sentido com construção civil em TI pode ser porque é um assunto inconveniente para quem toma as decisões na empresa, logo aqueles que são pagos por eles (usuários e pessoal de TI) não tem mesmo incentivo pra falar no assunto. Mas o resultado dessa comparação se manifesta claramente na quantidade projetos de TI que fracassaram.
Agora eu não concordo em querer mudar como as empresas pensam. Quanto mais elas comprarem sua idéia que TI é similar com construção civil e fracassarem, mais fácil pra mim, e outros programadores que realmente entendem de software, se destacarem no mercado. 
[quote=lkbm]
O lance de nunca ter ouvido citar comparação nesse sentido com construção civil em TI pode ser porque é um assunto inconveniente para quem toma as decisões na empresa, logo aqueles que são pagos por eles (usuários e pessoal de TI) não tem mesmo incentivo pra falar no assunto. Mas o resultado dessa comparação se manifesta claramente na quantidade projetos de TI que fracassaram.[/quote]
Sinceramente, quando projetos fracassam ou sejam sucessos, eu costumo procurar os reais motivos para o ocorrido. Colocar a culpa das incompetências ou competências dessa maneira simplista é o caminho para o auto-engano.
[quote=lkbm]
Agora eu não concordo em querer mudar como as empresas pensam. Quanto mais elas comprarem sua idéia que TI é similar com construção civil e fracassarem, mais fácil pra mim, e outros programadores que realmente entendem de software, se destacarem no mercado. ;)[/quote]
Cara, ou eu não sei expressar minhas ideias (o que é bem possível), ou você tem problemas de entendimento, ou os dois…Mas quem sou eu, para discutir com quem entende tanto de software.
PS: caso se disponha a expor suas ideias sobre como desenvolver software, sou sempre interessado em aprender.
Desculpa, mas não vejo como dizer que existem vários incentivos e conflitos de interesse envolvidos seja mais simplista pra você do que achar que existe um, e apenas um, motivo para projetos falharem.
Minha desconfiança se confirma, o problema é de entendimento!
Deixa eu explicar:
“Sinceramente, quando projetos fracassam ou sejam sucessos, eu costumo procurar os reais motivos para o ocorrido.”. Ponto. “Colocar a culpa das incompetências ou competências dessa maneira simplista” (como você colocou em: “Mas o resultado dessa comparação se manifesta claramente na quantidade projetos de TI que fracassaram.”) " é o caminho para o auto-engano."
Deu para entender?
Minha desconfiança se confirma, o problema é de entendimento!
Deixa eu explicar:
“Sinceramente, quando projetos fracassam ou sejam sucessos, eu costumo procurar os reais motivos para o ocorrido.”. Ponto. “Colocar a culpa das incompetências ou competências dessa maneira simplista” (como você colocou em: “Mas o resultado dessa comparação se manifesta claramente na quantidade projetos de TI que fracassaram.”) " é o caminho para o auto-engano."
Deu para entender? [/quote]
Bom, você não disse porque esses motivos que citei não podem ter sido os reais causadores de fracasso nos projetos que participei, nem quais “reais” motivos você encontrou nos projetos que participou. Isso é uma anti-resposta, no sentido que fornece a ilusão de uma resposta quando na verdade ela não existe.
Se considerar que estou pelo menos apontando um motivo, enquanto você diz que o motivo é “mal-encaminhamento”, não acho que estou sendo tão simplista quanto você até agora.
,[quote=lkbm]
Bom, você não disse porque esses motivos que citei não podem ter sido os reais causadores de fracasso nos projetos que participei, nem quais “reais” motivos você encontrou nos projetos que participou. Isso é uma anti-resposta, no sentido que fornece a ilusão de uma resposta quando na verdade ela não existe.
Se considerar que estou pelo menos apontando um motivo, enquanto você diz que o motivo é “mal-encaminhamento”, não acho que estou sendo tão simplista quanto você até agora.[/quote]
Dessa vez fui eu que não entendi direito. Não estava considerando que na sua resposta eram projetos que você participou, não me pareceu ser essa situação. Quando disse “na quantidade [de] projetos…”, deu-me a impressão de que estava falando “muitos”, daí pensei que estava falando de forma mais genérica, desculpe-me a falha.
No meu caso, de todos os projetos que participei, apenas um projeto não foi ok. Mas, eu me incluo como um dos responsáveis pelo insucesso. Avaliamos mal o escopo e os recursos, mas abortamos logo após o início.
Se detectou o problema no início e abortou o projeto, não é um exemplo de projeto mal encaminhado na minha compreensão.
[quote]Mas já deve ter ouvido falar de projetos que degeneraram em caos e produto final que foi recusado pelo cliente porque era difícil de usar ou simplesmente não atendia as reais necessidades do cliente?
[/quote]
Até onde sei, não é possível detectar problemas de usabilidade do software, ou software que não faz o que o cliente pediu, na fase inicial do projeto. Logo, podemos deduzir pela sua resposta que nunca ouviu falar de projetos assim?
[quote=lkbm][quote=A H Gusukuma]
No meu caso, de todos os projetos que participei, apenas um projeto não foi ok. Mas, eu me incluo como um dos responsáveis pelo insucesso. Avaliamos mal o escopo e os recursos, mas abortamos logo após o início.
[/quote]
Se detectou o problema no início e abortou o projeto, não é um exemplo de projeto mal encaminhado na minha compreensão.
[/quote]
O erro foi ter deixado iniciar, poderia ter optado por não iniciar se tivesse feito uma análise mais cuidadosa da situação.
Até onde sei, não é possível detectar problemas de usabilidade do software, ou software que não faz o que o cliente pediu, na fase inicial do projeto.[/quote]
Concordo, é claro.
[quote]
Logo, podemos deduzir pela sua resposta que nunca ouviu falar de projetos assim?[/quote]
Já ouvi, sim. Mas, não vejo como, por alguma resposta minha, se pode deduzir que não.
Se foram apenas problemas que puderam ser detectados no início, da entender que nunca teve projetos com problema de usabilidade ou de produto não atender as expectativas do cliente, já que essas situações não podem ser detectadas no início, mas não fica claro, não da pra deduzir. Por isso minha pergunta. rs
Em outras palavras, se tivesse antecipado o problema. Acho que estou começando a entender porque acha desenvolvimento de software similar a engenharia.
Mas e quanto a problemas de usabilidade, de não fazer o que se pede, e tantos outros problemas que podem surgir durante a implementação de um software, e que não podem ser detectados e corrigidos no início como seria por um engenheiro numa obra?
[quote=lkbm][quote=A H Gusukuma]
O erro foi ter deixado iniciar, poderia ter optado por não iniciar se tivesse feito uma análise mais cuidadosa da situação.
[/quote]
Em outras palavras, se tivesse antecipado o problema. Acho que estou começando a entender porque acha desenvolvimento de software similar a engenharia.
Mas e quanto a problemas de usabilidade, de não fazer o que se pede, e tantos outros problemas que podem surgir durante a implementação de um software, e que não podem ser detectados e corrigidos no início como seria por um engenheiro numa obra?[/quote]
Creio que continua sem entender, eu vou repetir: eu não disse que desenvolvimento de software é similar a engenharia.
O grande diferencial de desenvolvimento de software é o fato de que ele deve ser flexível, engessar o projeto pela inflexibilidade é um dos fatores que mais inviabilizam o desenvolvimento de bons produtos.
[quote=A H Gusukuma]
Creio que continua sem entender, eu vou repetir: eu não disse que desenvolvimento de software é similar a engenharia.[/quote]
Mas as pessoas que tomam as decisões nas empresas dizem: e o motivo que elas dizem isso é porque querem acreditar que fazendo uma análise mais cuidadosa da situação antes, eles podem evitar os problemas surgirem durante a implementação no futuro.
O problema com isso é que o conhecimento sobre o software muda enquanto esta sendo implementado, diferente da engenharia, onde o conhecimento da ponte não muda enquanto os pedreiros estão construindo.
Ser flexível ou ser bom, são coisas tão subjetivas que vou considerar essa como mais uma das suas anti-respostas que não dizem nada.
[quote=lkbm][quote=A H Gusukuma]
Creio que continua sem entender, eu vou repetir: eu não disse que desenvolvimento de software é similar a engenharia.[/quote]
Mas as pessoas que tomam as decisões nas empresas dizem: e o motivo que elas dizem isso é porque querem acreditar que fazendo uma análise mais cuidadosa da situação antes, eles podem evitar os problemas surgirem durante a implementação no futuro.
O problema com isso é que o conhecimento sobre o software muda enquanto esta sendo implementado, diferente da engenharia, onde o conhecimento da ponte não muda enquanto os pedreiros estão construindo.
Ser flexível ou ser bom, são coisas tão subjetivas que vou considerar essa como mais uma das suas anti-respostas que não dizem nada.[/quote]
É claro que precisamos definir bem os termos, para equalizar entendimentos, e evitar dubiedade.
Mas quando eu disse, por exemplo, “flexível” envolve o fato de que muitas vezes por ser único, e não uma linha de produção, o conhecimento sobre o software acompanha o seu desenvolvimento, inclusive podendo alterar radicalmente, por mudanças no mercado ou leis.
Quando eu disse “bom”, a maioria deve ter entendido como “atende as necessidades”, “funciona” e é “usável”. Considerar outro entendimento, é no mínimo, má vontade. Ou, achar que tem uma capacidade meio que esotérica de ler pensamentos.
Eu poderia fazer considerações sobre o seu conhecimento de construção civil, mas, não vou fazer isso para não dar mais motivos para confusões.
Agora, como minhas (anti)respostas não lhe dizem nada, para que continuar com as argumentações? De minha parte, deu para conhecer um pouco como pensa.
A idéia que o conhecimento sobre o software é único deve explicar porque alguém considera similar a engenharia. Afinal, como uma ponte seria erguida ou produto fabricado numa linha de montagem, se o conhecimento sobre o que deve ser construído mudasse a cada etapa do processo? Não seria possível, de maneira eficiente, gerenciar uma equipe de operários e obreiros assim.
Mas isso não quer dizer que software é similar a engenharia, apenas que alguém decidiu usar engenharia e técnicas de gestão tradicional (mão de obra), pra desenvolver software.
Por outro lado, a idéia que o conhecimento sobre o software não é estático, mas dinâmico, e esta em constante mudança, me parece mais correta. Inclusive é uma das premissas básicas das metodologias consideradas “ágeis”.
[quote=lkbm]A idéia que o conhecimento sobre o software é único deve explicar porque alguém considera similar a engenharia. Afinal, como uma ponte seria erguida ou produto fabricado numa linha de montagem, se o conhecimento sobre o que deve ser construído mudasse a cada etapa do processo? Não seria possível, de maneira eficiente, gerenciar uma equipe de operários e obreiros assim.
Mas isso não quer dizer que software é similar a engenharia, apenas que alguém decidiu usar engenharia e técnicas de gestão tradicional (mão de obra), pra desenvolver software.
Por outro lado, a idéia que o conhecimento sobre o software não é estático, mas dinâmico, e esta em constante mudança, me parece mais correta. Inclusive é uma das premissas básicas das metodologias consideradas “ágeis”.[/quote]
Recomendo que releia o que escrevi, ou, verifique se o seu entendimento sobre o escrito possa ter outra interpretação, senão fica parecendo conversa de doido!
De fato, a princípio ficou um pouco estranho porque se alguma coisa é única, não pode ser flexível, já que o que é único não muda, ou seja, é estatico.
Mas ficou mais claro do que o primeiro post que não estava acompanhado do que quer dizer por flexível.