Conselhos de um velho programador antissocial e ranzinza

Assuntos Gerais
#1

[quote]
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.[/quote]

Ó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:

#2

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.

#3

[quote=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.[/quote]

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

#4

[quote=Impossivel][quote=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.[/quote]

Acho que você e o Erick estão falando de coisas diferentes.[/quote]
Blz, entendi na frase citada que ele quis valorizar mais o atendimento ao cliente do que ficar só em itens de TI.

#5

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

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

#6

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

#7

[quote=Impossivel][quote=javaflex]
Blz, entendi na frase citada que ele quis valorizar mais o atendimento ao cliente do que ficar só em itens de TI.[/quote]

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[/quote]
É, 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 anual e demandar necessidades, é um dos principais usuários do sistema.

#8

Pois é, para TI somos bem velhos.

#9

[quote=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.[/quote]

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?

#10

[quote=Impossivel][quote=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.[/quote]

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?
[/quote]
Pela parceria, por exemplo a análise da experiência de uso do processo junto ao cliente.

#11

[quote=javaflex]
Pela parceria, por exemplo a análise da experiência de uso do processo junto ao cliente.[/quote]

Não entendi. Que parceria seria essa?

#12

[quote=Impossivel][quote=javaflex]
Pela parceria, por exemplo a análise da experiência de uso do processo junto ao cliente.[/quote]

Não entendi. Que parceria seria essa?[/quote]
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.

#13

[quote=javaflex][quote=Impossivel][quote=javaflex]
Pela parceria, por exemplo a análise da experiência de uso do processo junto ao cliente.[/quote]

Não entendi. Que parceria seria essa?[/quote]
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.[/quote]

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.

#14

[quote=ErickRAR][quote]
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.[/quote]

Ó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/[/quote]

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.

#15

[quote=YvGa][quote=ErickRAR][quote]
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.[/quote]

Ó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/[/quote]

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.[/quote]
Bons padrões sempre são bem vindos quando necessário para atender mais confortavelmente as evoluções do projeto. Não é para ser 8 ou 80, mas para evitar esforço ou desgaste com o que não é necessário e ter mais tempo para enxergar o lado humano das coisas.

#16

[quote=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.[/quote]

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…

#17

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 []

#18

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 []

#19

[quote=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.[/quote]

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

[quote=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 [] [/quote]

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?

#20

[quote=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.[/quote]

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

[quote=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.[/quote]

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

[quote=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 [][/quote]

???